【Linkerd】策略模型：Server、AuthorizationPolicy 与 policy 容器
内容提要
本文介绍Linkerd 2.20策略模型，核心是三类CRD：Server声明端口入站策略，AuthorizationPolicy定义访问授权，MeshTLSAuthentication指定认证身份。policy容器负责入站策略推送，destination控制器处理出站发现。排障时需区分403拒绝、TLS错误、无端点等不同故障域，避免混淆策略与发现问题。
延伸解读
策略轴与身份轴的分界
排障时需先区分失败发生在哪一轴：入站403/denied属于策略轴，应检查Server是否存在、AuthorizationPolicy的targetRef是否正确、身份是否在MeshTLSAuthentication允许列表；TLS握手错误属于身份轴，需核对CSR、issuer、trust anchor；出站无端点则属于destination轴。混淆这些故障域会导致误改ServiceProfile或重装destination，而问题实际在策略配置。
Server是策略生效的前提
AuthorizationPolicy必须通过targetRef指向一个Server，而Server通过podSelector和port匹配目标端口。若策略“永远不生效”，应先确认目标端口是否有匹配的Server，再检查策略资源。未被子Server覆盖的端口可能不走mesh入站策略链，或与opaque端口注解交互，导致策略被绕过。
策略校验与运行时拒绝的区别
CRD校验失败发生在写入API server时，kubectl apply即报错；连接拒绝发生在运行时proxy入站，Pod已Running但客户端被拒。两者证据包必须分列。另外，policy-validator的failurePolicy若为Ignore，可能静默放过无效CRD，导致策略不生效但无报错，需注意检查webhook配置。
Q&A
Linkerd 2.20 中 Server、AuthorizationPolicy 和 MeshTLSAuthentication 这三个 CRD 分别有什么作用？
Server 用于声明工作负载上哪些端口以 mesh 语义提供服务，是策略的锚点；AuthorizationPolicy 定义谁可以访问哪些 Server，是核心授权对象；MeshTLSAuthentication 声明哪些 mesh 身份（如 ServiceAccount、命名空间）可被视为已认证客户端，供 AuthorizationPolicy 引用。
Linkerd 中 policy 容器和 destination 控制器在策略执行上如何分工？
policy 容器负责 watch policy.linkerd.io 等 CRD，编译入站策略并通过 inbound gRPC 推送给 proxy；destination 控制器负责出站 destination.Get/GetProfile 和端点翻译，不参与入站授权求值。两者独立进程，故障域不同。
在 Linkerd 中遇到入站 403 拒绝时，应该优先检查哪些方面？
应优先检查策略轴：目标端口是否有匹配的 Server、AuthorizationPolicy 的 targetRef 是否正确、客户端身份是否在 MeshTLSAuthentication 允许列表中。
Linkerd 的 AuthorizationPolicy 与 Kubernetes NetworkPolicy 有何不同？
Linkerd 策略在 proxy 入站、mTLS 身份建立之后求值，基于 mesh 身份与 server 绑定；而 NetworkPolicy 是 CNI 四层 iptables 规则，不涉及 mesh 身份。
Linkerd 中 TLS 握手失败和策略拒绝（403）在故障域上有什么区别？
TLS 握手失败属于 identity 轴，涉及证书、trust anchor 等问题；策略拒绝属于策略轴，发生在握手成功但身份不在允许列表时。两者需分开排查。
如果 AuthorizationPolicy 一直不生效，可能的原因有哪些？
可能原因包括：目标端口没有匹配的 Server、AuthorizationPolicy 的 targetRef 指向错误、身份不在 MeshTLSAuthentication 允许列表中，或者 policy 容器故障导致策略未推送。
Linkerd 中 policy 容器故障会导致什么后果？
policy 容器故障可能导致入站策略陈旧或默认拒绝，影响入站连接授权；但出站发现可能仍正常，因为 destination 控制器是独立进程。
