【Linkerd】控制面全景：缺口、五轴坐标系与 16 篇路线

Istio 控制面内核 已把 istiod、xDS 推送、NACK/warming 与 Ambient 多客户端钉到可排障精度；第 14 篇对照 用一篇收住「Linkerd 不是另一个 xDS」。Service Mesh 架构 给过 Sidecar 税与 Ambient 地图。中间仍缺一层：Pod 如何成为 mesh 成员、mTLS 握手失败落在 identity 哪一层、destination 按目标 Get() 流如何推送端点与策略、native sidecar 默认（2.20）与 legacy init+sidecar 如何分列，以及相对 istiod/xDS 与 Cilium L4 何时不该上 Linkerd。

本文只做三件事：钉缺口、定义后续 15 篇共用的五条坐标系，并给出阅读路线。难点不在「会不会 linkerd install」，而在控制面与数据面交界上的可核对字段——Pod 是否被 injector 改过、流量是否经 proxy 重定向、CSR 是否成功、destination 流是否返回端点、策略拒绝与 ServiceProfile 校验是否分列。

本篇在系列中的位置

篇目	核心内容
第 1 篇 · 控制面全景	缺口、五轴坐标系、16 篇路线
第 2 篇 · 网格成员与注入	proxy-injector、native sidecar 默认
系列目录	关键问题、阅读路径、全部价值点

版本锚定：Linkerd 2.20（源码 tag version-2.20，公告 2026-06-23；对应 edge edge-26.6.3）。机制叙述对齐该 tag 与配套 linkerd2-proxy-api / linkerd2-proxy；官方 Architecture 以与 2.20 文档树一致的内容为准。linkerd.io/docs/ live 站点是滚动文档，不以 /latest 冒充本版本。无真实 Linkerd 集群则不粘贴伪造 linkerd check 全绿 / viz 指标。 2.20 起 native sidecar 为默认注入方式（2.15 引入 → 2.19 beta → 2.20 stable 默认）——legacy init+sidecar 仍支持，排障须分列证据包。

一、相对站内已有内容，缺口在哪

下表列出各已有系列的视角，以及本系列补的格子。规则是：不重写已有内容，只填真正空着的格子。

结论：读者知道「Linkerd 不用 xDS、代理是 Rust」，但不知道一次连接卡在注入、iptables/CNI、CSR、destination Get() 流、策略容器还是 ServiceProfile；为何 2.20 默认 native sidecar 后 Job/CronJob 表现与旧路径不同；把 Linkerd 当成「轻量版 istiod」会在第一步指错组件（去查 xDS NACK 而不是 identity 日志）。

与通识教程的差别也在这里：多数「在 K8s 上装 Linkerd」文章停在 linkerd install 与一条 mTLS 演示；本系列追问 meshed Pod 之后「未 mesh / TLS 失败 / 无端点 / 策略拒 / 502」仍落在哪一层，以及 专用 gRPC API 与 xDS type-subscription 排障口令为何不能互换。深度来自可证伪的阶段划分，而不是「Linkerd 更轻」口号。

本系列刻意不写 VirtualService 菜谱、Envoy Filter/HCM 重讲、Cilium eBPF 全书、未实测「Istio vs Linkerd CPU%」排行榜。若目标只是「建立 Mesh 税直觉」，architecture/76 与 istio-xds/14 已够；若目标是「失败落在 injector 还是 destination」，则必须沿五轴下钻。

本系列反复回指的版本门（不当本篇深挖）

二、五条坐标系（后续章节回指）

后面每一篇都落到下面某一条轴上。排障口诀：先点名轴，再下钻模块——不要一上来改 ServiceProfile 或重装控制面。native sidecar 与 legacy 路径在轴 1–2 分列证据包。

官方 Architecture 把控制面拆成 destination（发现、策略、ServiceProfile）、identity（CA/CSR）、proxy-injector（成员资格）；数据面是 linkerd2-proxy，经 linkerd2-proxy-api 专用 gRPC 与控制面通信——不是 xDS。五轴是把这条管线按值班可核对的失败落格切开。

flowchart LR
  k8s["Kubernetes API watches"] --> dest["destination controller"]
  k8s --> pol["policy evaluator"]
  inj["proxy-injector webhook"] --> pod["meshed pod"]
  pod --> init["init or native sidecar"]
  init --> proxy["linkerd2-proxy"]
  ident["identity CA"] -->|"CSR sign"| proxy
  dest -->|"destination.Get stream"| proxy
  pol --> dest
  sp["ServiceProfile plus sp-validator"] --> dest

注入与网格成员轴

定义：Pod 如何被标记为 mesh 成员、proxy 容器以何种形态注入、哪些端口跳过代理。

proxy-injector 是 MutatingAdmissionWebhook：在 Pod 创建时注入 linkerd-proxy（及 legacy 路径上的 linkerd-init）。2.20 默认 native sidecar——利用 Kubernetes 原生 sidecar 容器语义，改善 Job 完成与启动顺序；legacy 路径仍是 init 改 iptables + 普通 sidecar。linkerd.io/inject: disabled 与 opaque ports 决定「看似装了 Linkerd 命名空间注解却未 mesh」的经典坑。

「Pod 里没有 proxy 容器」或「Job 永不 Complete」优先落本轴，而不是先查 destination。展开见 第 2 篇、第 3 篇。

身份与 mTLS 轴

定义：工作负载身份如何经 CSR 绑定 ServiceAccount，证书如何自动轮转，issuer 与 trust anchor 如何分层。

与 Istio SDS 的通用 xDS 资源推送不同，Linkerd 走 identity 专用 gRPC：代理启动时发 CSR，identity 签发短期证书。工作负载证书可自动续期；trust anchor 轮转则要求控制面与全网格代理在过渡期同时信任新旧锚——这是比「单张 cert 过期」更重的运维门。

「meshed 但 TLS handshake failed」或「升级 identity 后全集群红」优先落本轴。展开见 第 4 篇、第 12 篇。

destination / 发现轴

定义：对某一逻辑目标，destination.Get() 长连接流返回哪些端点、协议、mTLS 身份与策略结论。

与 xDS 的「按类型订阅 EDS/CDS」不同，Linkerd 是 per-target 查询 + 流式更新。destination 控制器基于 Informer 监听 EndpointSlice 等对象，经 EndpointTranslator 富化 identity/zone。2.20 对 destination 内部状态管理做了内存优化——大集群 churn 时控制面 OOM 是独立故障面。

「linkerd routes 有路由但连接 refused」或「端点列表空」优先落本轴。展开见 第 5 篇、第 7 篇。

策略与 L7 轴

定义：Server、AuthorizationPolicy、MeshTLSAuthentication 如何决定连接是否允许；ServiceProfile 如何提供 L7 路由/重试/超时。

策略判定在 destination Pod 的 policy 容器 与 sp-validator webhook 分工完成——不是「一条 VirtualService 编译进 RDS」。ServiceProfile 语法错误应在入库前被 webhook 拒绝；策略静默拒绝与 SP 未绑定是不同证据包。

「该通的连接 403」与「重试/超时行为不符合预期」优先查本轴。展开见第 8–9 篇。

数据面与健康轴

定义：linkerd2-proxy 入站/出站如何处理协议、负载均衡与限流；metrics/tap 是否反映真实流量；控制面组件是否健康。

2.20 引入 rate-limit-aware load balancing——在机制上让 LB 识别限流响应，不是未测吞吐排行榜。502/超时可能是 proxy 问题，也可能是上游无端点却被误当成应用 bug。

「viz 无指标但应用能通」或「destination Pod OOM」优先落本轴。展开见第 10–11、13 篇。

三、坐标系背后的三个不变量

1. 控制面协议是专用的，不是 xDS 子集：linkerd2-proxy-api 为 linkerd2-proxy 一对一设计；错误处理落在 gRPC 状态码与重连，而不是 xDS ACK/NACK。代价是不能用 istiod 排障口令套 Linkerd。
2. 三组件拆分，故障域在 Deployment 边界：destination、identity、proxy-injector 可独立扩缩与失败；代价是协作路径比单进程 istiod 多。
3. 成员资格与重定向是独立失败域：injector 成功不等于 iptables/CNI 已把流量送进 proxy；native sidecar 与 legacy 路径证据包不同。代价是「装了 Linkerd」≠「流量经过 mesh」。

排障时先问「哪条不变量被触碰」，再落到对应轴。例如：有 proxy 容器但流量未进 proxy → 不变量 3；CSR 成功但 destination 流空 → 不变量 1 与轴 3 分界。

四、设计谱系：Sidecar 模式与协议通用性分叉

Borg/Omega 运维分离 → Kubernetes Pod 多容器
  → Sidecar 模式（Burns & Beda 等；architecture/76 展开税）
  → 控制面协议分叉：
      Istio：xDS 通用资源类型 → 多数据面（Envoy/ztunnel/waypoint）
      Linkerd：linkerd2-proxy-api 专用 gRPC → 单一 Rust 数据面
  → 仍争：协议可移植性 vs 实现专一化；sidecar 税 vs Ambient vs eBPF L4

不在第 1 篇宣布胜负；选型留给 第 16 篇 排除树。

五、16 篇路线与阅读建议

flowchart TD
  overview["01 Overview"] --> inject["02 Mesh Inject"]
  inject --> redirect["03 Traffic Redirect"]
  redirect --> ident["04 Identity"]
  ident --> dest["05 Destination Arch"]
  dest --> api["06 proxy-api"]
  api --> disc["07 Discovery Stream"]
  disc --> pol["08 Policy"]
  pol --> sp["09 ServiceProfile"]
  sp --> proxy["10 linkerd2-proxy"]
  proxy --> gapi["11 GAPI Multicluster"]
  gapi --> ops["12 Upgrade"]
  ops --> trouble["13 Troubleshoot"]
  trouble --> vs["14 vs Alternatives"]
  vs --> eco["15 Ecosystem"]
  eco --> select["16 Selection"]
  overview --> select

读法：先读本篇；若症状是「Pod 未 mesh」，优先 02→03→13；若是「TLS 失败」，优先 04→12→13；若是「无端点/403」，优先 05→07→08→13。xDS 推送问题回 istio-xds；南北向 Gateway 回 envoy-gateway。

六、本篇不写什么

• VirtualService / DestinationRule 菜谱；istiod 推送图重讲。
• Envoy Filter/HCM 内核；Cilium eBPF 数据面全书。
• 未实测 Istio vs Linkerd CPU%/延迟排行。
• 把 live 文档后版本能力写成 2.20。
• 伪造 linkerd check、viz 截图、跨方案 benchmark。

参考资料

规范 / 官方文档 / 源码（A）

• Linkerd 2.20 公告（2026-06-23）；tag version-2.20
• Linkerd Architecture（destination / identity / proxy-injector / data plane）
• linkerd/linkerd2-proxy-api README；linkerd/linkerd2 BUILD.md
• 本系列 PLAN.md §一、§八

站内对照（A/B）

• istio-xds/14 · Linkerd 对照（Istio 侧）
• istio-xds/16 · 选型收束
• architecture/76 · Service Mesh
• envoy/11 · SDS

博客（B）

• Linkerd, Deep Dive: How linkerd-destination works（2026）

实验台账

• 本篇无集群实测；无伪造 check/viz 输出。

上一篇：系列目录

下一篇：网格成员与注入