Linkerd / 服务网格控制面：非 xDS 的 destination、identity 与 linkerd2-proxy
内容提要
本文介绍Linkerd 2.20控制面系列文章，涵盖其非xDS架构、五轴排障坐标系（注入、identity、destination、策略、数据面）及16篇路线图。重点区分native sidecar与legacy路径，对比istiod/xDS和Cilium L4，说明专用gRPC控制面优势，并指导选型与排障，强调基于源码tag而非live文档。
延伸解读
非 xDS 控制面的排障优势
Linkerd 控制面采用专用 gRPC 服务（destination、identity、inbound、tap），与 Istio 的 xDS 通用协议不同。这种设计让错误定位更直接：例如 mTLS 握手失败可归因到 identity 层，而 destination 空端点则对应服务发现流问题。相比 xDS 的 ACK/NACK 机制，Linkerd 的错误更贴近 gRPC 层，排障时无需理解复杂的 xDS 推送语义。
native sidecar 与 legacy 路径分列
Linkerd 2.20 默认使用 native sidecar 注入方式，与 legacy 路径在流量重定向、证书管理等方面存在差异。排障时需明确当前集群使用的是哪种路径，因为两者的故障表象和排查证据包不同。例如，native sidecar 可能影响 iptables 规则或端口配置，而 legacy 路径则依赖 linkerd-init 或 CNI。
选型对照：何时不用 Linkerd
文章强调 Linkerd 并非适用于所有场景。若需要深度 L7 策略或与 Envoy 生态集成，Istio/Ambient 可能更合适；若仅需纯 L4 网络策略，Cilium 更轻量。选型时应基于具体需求：Linkerd 的专用控制面在简单性和排障友好性上有优势，但功能边界需明确，避免在复杂路由或策略场景下强行使用。
Q&A
Linkerd 2.20 的控制面由哪些组件组成？
Linkerd 2.20 的控制面由三个独立组件组成：destination、identity 和 proxy-injector。它们按故障域分离，而不是像 Istio 那样作为一个轻量级的 istiod。
Linkerd 与 Istio 的 xDS 控制面有何不同？
Linkerd 使用专用的 gRPC 控制面，通过 per-target Get() 流式推送端点与策略，而 Istio 使用通用的 xDS 协议。这导致排障时错误定位在 gRPC 层而非 ACK/NACK，且 Linkerd 不是 xDS 的实现。
在 Linkerd 中，mTLS 握手失败可能由哪些原因导致？
mTLS 握手失败可能源于工作负载证书、issuer 或 trust anchor 的问题。需要区分是证书轮转失败、CSR 校验失败还是信任锚配置错误。
Linkerd 2.20 中 native sidecar 与 legacy 路径有何区别？
native sidecar 是 2.20 的默认注入方式，而 legacy 路径是旧版方式。两者在流量重定向和代理部署上存在差异，排障时需要区分证据包。
如何区分 destination 空端点、策略拒绝和 ServiceProfile 未生效？
需要分别检查 destination 服务的端点发现、策略（如 AuthorizationPolicy）的配置，以及 ServiceProfile 是否被正确应用。每个问题对应不同的排障轴。
在什么情况下应该选择 Linkerd 而不是 Istio 或 Cilium？
当需要轻量级、低资源消耗且专注于服务网格功能时，Linkerd 是合适的选择。如果需求涉及复杂的流量管理或 L7 策略，Istio 可能更合适；如果仅需 L4 网络策略，Cilium 可能更优。
Linkerd 的排障五轴坐标系是什么？
五轴包括注入（injector）、identity、destination、策略（policy）和数据面（proxy）。这五个维度覆盖了从注入到路由的完整链路，帮助定位问题所在层。
Linkerd 2.20 的版本锚定和文档来源有何注意事项？
机制结论应基于源码 tag version-2.20（2026-06-23），而非 live 文档。自 2024-02 起 OSS 项目不再发布 stable 制品，安装包需从官方 releases 获取。
