【Linkerd】排障坐标系：五轴否证与 native/legacy 证据包
内容提要
本文介绍Linkerd 2.20服务网格排障方法，提出五轴坐标系：注入与网格成员、身份与mTLS、destination发现、策略与L7、数据面健康。排障时先定位症状对应轴，再下钻组件，区分native sidecar与legacy init+sidecar路径。强调按顺序否证各轴，避免混贴证据或误改配置，并对照Istio xDS排障差异。
延伸解读
五轴否证：先定位再下钻
排障时先根据症状映射到对应轴，再按顺序逐轴否证，避免直接修改配置或重装控制面。例如，Pod 未注入优先查轴 1，而非改 destination；TLS 握手失败优先查轴 2，而非改 ServiceProfile。这种系统化方法可防止将可恢复的轴 3 问题误判为双故障。
native 与 legacy 证据包分列
Linkerd 2.20 默认 native sidecar，与 legacy init+sidecar 在注入失败时的证据不同。native 路径需检查 restartPolicy 和启动门，legacy 路径需检查 init 容器退出码和 iptables 规则。混贴证据会导致误判，例如将 native 的启动门问题当作应用 bug。
与 Istio 排障的差异
Linkerd 使用 per-target Get() 流，而 Istio 使用 xDS 订阅。排障时不能将 Linkerd 的“无端点”解释为 Istio 的 EDS 空 cluster，也不能将 Istio 的 xDS NACK 类比为 Linkerd 的 gRPC 状态码。两者“五轴”含义不同，混用会指错组件。
Q&A
Linkerd 2.20 排障时，如何快速定位问题属于哪个轴？
根据症状对照入口表：Pod 无 linkerd-proxy 或未注入对应轴 1；TLS 握手错误或身份不匹配对应轴 2；无端点或发现延迟对应轴 3；403 或策略拒绝对应轴 4；502 或超时先否证轴 1-4 再查轴 5。默认顺序为轴 1 到轴 5，一次否证一轴。
Linkerd 2.20 中 native sidecar 和 legacy init+sidecar 在排障时有何区别？
native sidecar（2.20 默认）在轴 1 需检查 Pod restartPolicy 和启动门；legacy 路径需检查 linkerd-init 完成态和 iptables/CNI。证据包必须标明路径，不可混贴。
Linkerd 中 Pod 未注入 sidecar 应该先检查什么？
先检查 namespace 注解、proxy-injector webhook 是否命中、是否跳过注入，以及注入路径（native 或 legacy）的特定条件。不要直接改 destination 配置。
Linkerd 中 TLS 握手失败可能是什么原因？
可能原因包括工作负载证书未由 identity 签发、issuer 不是当前 trust anchor 签发、trust anchor 轮转未完成或 multicluster 不一致。应先否证轴 1，再查轴 2，不要先改 ServiceProfile。
Linkerd 中 403 错误通常与哪个轴相关？如何排查？
403 错误通常与轴 4（策略与 L7）相关。检查 Server、AuthorizationPolicy、ServiceProfile 或 GAPI HTTPRoute 是否被正确加载和匹配。
Linkerd 中 502 错误如何区分是数据面问题还是 destination 问题？
若 destination 已推送端点且策略允许，但 proxy 仍 502，则查 proxy 与对端 inbound（轴 5）；若 destination 未推送端点，则留在轴 3-4。
Linkerd 排障与 Istio 排障有何关键差异？
Linkerd 使用 linkerd2-proxy-api gRPC 和 per-target Get() 流，排障入口是五轴和 native/legacy 分列；Istio 使用 xDS 和 Envoy，排障关注 Listener/Cluster warming 和 xDS NACK。两者不能混用证据。
