【Linkerd】选型收束与开放问题：排除树与系列边界关闭

前 15 篇把 Linkerd 非 xDS 控制面拆到可归因精度：三组件拆分、native sidecar 默认门、identity CSR、destination 按目标流、策略与 ServiceProfile、排障五轴，并对照了 istiod/xDS、Ambient、Cilium L4，划清了制品与观测/安全系列边界。选型若再写成「Linkerd 轻、Istio 全、eBPF 快」，等于把机制丢掉。

本文是终章：用机制排除树收束判断，回收 istio-xds/16 指向的 Linkerd 叶，写明何时不该跑 Linkerd，列出仍开放的问题，并以 ADR 可粘贴的语言关闭「Linkerd 非 xDS 控制面内核」续作边界。不做跨方案延迟或 CPU 排行榜。

本篇在系列中的位置

篇目	核心内容
第 15 篇 · 生态与制品边界	stable / edge / Buoyant
第 16 篇 · 选型收束（终章）	排除树、开放问题、边界关闭
系列目录	全部篇目

版本锚定：Linkerd 2.20（源码 tag version-2.20，2026-06-23；edge edge-26.6.3）。Istio 对照钉 1.30.3；Cilium 对照钉 v1.20.0；Falco 对照钉 0.44.1；Tetragon 对照钉 v1.7.0。OSS stable 安装制品自 2024-02 起不由项目直发（第 15 篇）。

一、机制排除树

排除树每一叶必须回答一个可证伪的机制问题，而不是「看场景」。

flowchart TD
  l7{"Need L7 policy that changes\nindependent of app deploy?"}
  l7 -->|"No"| l4{"Need only L3/L4\nidentity plus policy?"}
  l4 -->|"Yes"| cil["Cilium L4 path\nsee cilium/16"]
  l4 -->|"No"| plain["Plain CNI\nno mesh tax"]
  l7 -->|"Yes"| xds{"Need generic xDS\nmulti-consumer or Envoy filters?"}
  xds -->|"Yes"| istio["istiod / xDS path\nsee istio-xds/16"]
  xds -->|"No"| amb{"Need sidecar-free\nin Istio ecosystem?"}
  amb -->|"Yes"| ambient["Ambient ztunnel plus waypoint\nsee istio-xds/13"]
  amb -->|"No"| staff{"Can staff operate\nLinkerd five axes?"}
  staff -->|"No"| defer["Do not run Linkerd yet"]
  staff -->|"Yes"| tag{"Accept vendor or edge\ntag alignment for install?"}
  tag -->|"No"| defer2["Fix release ADR first"]
  tag -->|"Yes"| linkerd["Linkerd 2.20 path\nthis series"]

排除树与 istio-xds/16 互补：Istio 终章先问「要不要 L7 翻译层、要不要 xDS」；本篇在「需要 mesh 且不必通用 xDS」分支上继续问「能否运维 Linkerd 五轴与制品 tag」。两棵树应先后走，不应把任一叶当成全局默认答案。

甜区：自管 Kubernetes，要把默认 meshed mTLS + destination 流当作一等能力；接受 linkerd2-proxy-api 一对一设计；值班能用第 13 篇五轴说话；机制钉 version-2.20（或 vendor 声明对齐的 stable）；L7 以 ServiceProfile / policy 为主，不依赖自定义 Envoy Filter。

苦区：把 Linkerd 当「轻量 istiod」查 CDS/EDS；无端点先改 ServiceProfile 却不查 Get() 流；trust anchor 轮转无检查单；native sidecar 与 Job 混谈却不分列证据包；用未标定 CPU 海报在 Istio 与 Linkerd 间站队；把 Buoyant Enterprise 宣传语当成开源 tag 能力表。

何时不该跑 Linkerd（否证条件）

下列任一成立，排除树上 Linkerd 叶判负（可写进 ADR）：

1. 编制撑不住五轴——不能用第 13 篇口令区分未 mesh、CSR/anchor 失败、空端点、策略拒、proxy 502。
   
2. 需求停在 Cilium L4 + Hubble——要回答的是 identity 与包路径，不是 meshed mTLS 流（cilium/16）。
   
3. 必须通用 xDS 或多 Envoy 消费者——waypoint/第三方 xDS 代理是硬需求；走 istiod 路径。
   
4. 已在 Istio 存量且 Ambient 满足 sidecar-free——换 Linkerd 的迁移税需单独 ADR，不能靠「更轻」口号。
   
5. 安装 tag 与机制文章不一致且无验收门——2024-02 后 stable 包来自 vendor，未钉 tag 则禁止声称「按 2.20 机制已验收」。
   
6. 把「装了 Linkerd」当成南北向 Gateway 已解决——EG / Gateway API 南北向仍归 envoy-gateway/。

否证触发后应重跑排除树。沉没成本不是机制判据：POC 转正、安全套餐捆绑，都要把现状当假设再走一遍上表。

Cilium CNP 与本系列 AuthorizationPolicy 正交：排除树判负 Linkerd，并不等于东西向已具备 meshed mTLS；若威胁模型仍要每连接证书，需在 Cilium 叶之外单独写加密路径表（cilium/09）。反之，选了 Linkerd 也不替代 CNP——「TLS 绿了」不能证明 identity NetworkPolicy 已审。

对平台团队的务实建议：先用第 13 篇在试验命名空间跑通一次演练故障（至少覆盖「Pod 未 mesh」与「destination 空流但 Service 有 Endpoint」），再决定是否把 Linkerd 定为默认 mesh。若演练里卡在「读不懂五轴」，优先补第 1、2、4、7 篇门禁与编制，而不是先扩 namespace 注解覆盖面。

二、回收 istio-xds/16 Linkerd 叶

istio-xds/16 在排除树与阅读路径里把 Linkerd 标为「非 xDS 对照续作」，并曾写「规划已锁定」指向 linkerd/index。该指针在 Istio 终章交付时是悬空的机制叶：读者知道「xDS 不是唯一解」，但不知道 injector→identity→destination→proxy 如何分列、per-target 流与 type-subscription 排障口令差在哪、何时应离开 Linkerd 叶。

本系列交付后，该叶的机制内容如下——两边终章不再悬空：

给读完两边的人一句分工口令：

• 「NACK / warming / proxy-status」→ istio-xds/15
  
• 「该不该上 istiod / Ambient / eBPF L4」→ istio-xds/16
  
• 「未 mesh / CSR / 无端点 / policy 拒」→ 本系列 13
  
• 「该不该上 Linkerd」→ 本篇排除树
  
• 「Hubble / CNP」→ cilium/

istio-xds 终章承诺的 Linkerd 续作指针，到此关闭悬空状态。不是「永远不再写网格」，而是：同一句「去看 Linkerd 机制」不应再没有可核对篇章。

姊妹终章侧读者若仍只看到 istio-xds/14 一篇对照，应再进 第 1 篇 建立五轴，再回本篇做选型。Istio 侧「专用 gRPC vs xDS」机制对照保留在 istio-xds/14；本系列补的是 Linkerd 侧失败模式全书，两边不应互相改写版本钉。

三、开放问题

关闭条件必须是测量或正式文档/源码变更，不是路线图幻灯片。

3.1 native sidecar 默认与 Job / CronJob

问题：2.20 native sidecar 为默认注入路径时，Job/CronJob 等短生命周期工作负载的成员资格、流量重定向与「Pod 完成」语义是否与 legacy init+sidecar 路径同一套证据包？
为何重要：轴 1 须分列证据包（第 2、3、13 篇）；排障口令不能混用「缺 proxy」与「Job 未退出」。
检验：同一 Job 在 native 与 legacy 路径各跑一次，核对 spec、完成条件与 mesh 指标是否可对比。
现状：机制分叉已钉（2.20 门）；默认策略与平台门禁仍因集群而异，保持开放。Kubernetes native sidecar KEP 与 mesh 注入的交互仍在社区演进——ADR 应写「本集群 Job 默认走哪条注入路径」，而不是假设全局默认。

3.2 Gateway API 与 ServiceProfile 双轨

问题：同一服务同时存在 GAPI HTTPRoute（2.20 支持至 1.5.1）与 ServiceProfile 时，权威路由/超时/重试源是哪一条？冲突时 destination 响应以谁为准？
为何重要：第 9、11 篇分工指针；混用会把 L7 失败误判成「proxy 坏」。
检验：固定一对冲突配置，核对 destination 行为与官方 tag 文档是否给出显式优先级。
现状：GAPI 门已钉；双轨权威源判定仍开放（呼应 istio-xds/16 GAMMA 双轨项，但输入 CRD 不同）。南北向 HTTPRoute 若已归 envoy-gateway/，东西向 mesh 路由仍可能走 ServiceProfile——「同集群两套 L7 作者」必须在 ADR 里分行，不能假设运维凭直觉知道哪条 CRD 生效。

3.3 与 Falco / Tetragon 的联合 runbook

问题：故障时先查 Linkerd 五轴（TLS/无端点）还是 Falco 五轴（规则/输出）或 Tetragon 五轴（TracingPolicy/Override）？ServiceAccount、Pod 身份与 exec_id 如何在同一工单引用？
为何重要：Falco 16 与 Tetragon 16 均把联合 runbook 标为开放；网格与安全事件「看起来像连接失败」。
检验：合成「mTLS 握手失败 + 容器内 suspicious connect」「CNP deny + meshed 正常 TLS」——值班是否落到正确系列。
约束：本系列不裁决安装顺序；两边终章项保持开放，不要互相冒充关闭。同一 incident 里「TLS alert」与「Falco 命中 connect」可能同时出现——工单应拆成两条轴，先判定 transport 是否 meshed，再判定 syscall 是否可疑，而不是合并成一次「重装控制面」。

3.4 destination 内存与 EndpointSlice churn

问题：2.20 destination 内存优化后，大规模 EndpointSlice churn 下控制面内存 SLO 应如何写进 ADR？
为何重要：第 5、12 篇运维门；与「Linkerd 一定更省内存」口号无关。
检验：声明集群规模与 churn 口径后采样 destination Pod 内存；与 tag 公告对照。
现状：机制重构已公告；本系列不编造百分比；SLO 数字保持开放。

写给后续维护者：升 Linkerd 小版本时，先核 3.1–3.4 是否被 tag 或 vendor 包改变默认语义，再更新本篇「开放/已关闭」表，而不是重写排除树的问题顺序。 live 文档出现、tag 未包含的能力，保持开放项，不悄悄写进甜区。

四、边界关闭

给读完本系列的人三条收束（ADR 友好）

1. 排除树进 ADR：写清卡在哪一叶机制判据；附否证条件（编制减员、需求退回 Cilium L4、必须 xDS、tag 不对齐、误把南北向当 mesh）。示例句：
   「若平台不再维护 Linkerd 五轴值班，或必须通用 xDS 多消费者，则 Linkerd 叶必须重跑排除树，禁止以『服务网格已安装』续跑。」
2. 若选了 Linkerd：第 13 篇五轴进发布门禁；第 2/3 篇 native vs legacy 证据包进变更单；第 4/12 篇 trust anchor 轮转进检查单；第 15 篇制品 tag 进验收门——缺一项降级为试验集群。
   
3. 若没选：用第 14 篇机制表做代际复盘；禁止无口径 CPU 截图重开争论。需要 xDS 时回 istio-xds 终章；需要纯 L4 时回 cilium 终章；需要安全事件归因时回 Falco/Tetragon 终章。

选型复盘会议应带机制表而不是带海报：每一行前提崩了，记录「崩在哪一列」（协议、数据面还是排障坐标），而不是重新收集「听说 Istio 更重」一类无来源句。若组织已装 Linkerd 但排除树重跑判负，迁出税可以写进 ADR，但不能把「历史 POC 已上线」写成机制判据。

终章立场：Linkerd 值得写成非 xDS 控制面系列，是因为失败可命名——未 mesh、issuer/anchor 混谈、Get() 空流、SP 与 GAPI 混配、destination OOM。选型若离开这些名字，讨论退回安装量与「轻量」口号。记住一个动作：先排除，再钉 tag，再开 mesh 扩面——排除自带否证，tag 自带 2024-02 制品边界，扩面自带 native sidecar 与 Job 分列。

回到系列开头的缺口：istio-xds/16 留下的 Linkerd 叶现已有可核对篇章。若读完仍只能复述「不用 xDS」，说明阅读停在对照表；若能在故障里说出「这是 identity anchor 轮转」或「这是 destination 空流而非 CNP」，机制文才算交货。

若读者时间只够两篇：读 01 全景 建立缺口意识，再读本篇排除树；然后按主轴跳进 02/06/13 之一。完整通读的收益是「症状能落格」；跳读的风险是把 legacy init 路径当成 2.20 默认，或把 vendor edge 包当成机制验收 tag。

给维护者：补丁级更新应改版本钉与开放问题进展，而不是重写「先排除再选」的顺序。若 3.2 随 GAPI 标准化关闭，在本篇追加「已关闭项」并链到复盘，避免后人把 HTTPRoute 与 ServiceProfile 优先级写回「从未争论」。

至此，系列在机制层闭合：从注入与重定向，到 identity、destination 流、策略与数据面、对照与制品边界，再到排除树。后续补丁级更新应改版本钉与开放问题进展，而不是重写五轴口令。

参考资料

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

• Linkerd 2.20 / tag version-2.20；Releases 页
• 本系列 PLAN.md §六、§八；第 1 篇 五轴
• Istio 1.30.3 终章：istio-xds/16

站内对照

• 系列目录
• istio-xds/16 · Linkerd 原指针
• 第 14 篇 · 对照
• 第 15 篇 · 生态
• Falco 16；Tetragon 16
• architecture/76 · Service Mesh

实验台账

• 本篇无跨方案 benchmark；选型依据为机制排除。开放问题关闭依赖测量或上游文档，不在此伪造时间线。

上一篇：生态与制品边界

下一篇：系列目录