【Linkerd】选型收束与开放问题：排除树与系列边界关闭
内容提要
本文为Linkerd非xDS控制面系列终章，通过机制排除树收束选型判断，明确何时该用或不用Linkerd。排除树依据L7策略需求、xDS必要性、运维能力等可证伪问题决策。文章回收istio-xds/16悬空指针，列出native sidecar与Job、Gateway API双轨、联合runbook、内存SLO等开放问题，并以ADR语言关闭系列边界，强调机制而非口号。
延伸解读
排除树：用可证伪问题替代“看场景”
本文提出一套机制排除树，每个分支都对应一个可证伪的机制问题，例如是否需要独立于应用发布的L7策略、是否需要通用xDS、运维能否撑住五轴等。这种决策方式避免了“Linkerd轻、Istio全”这类口号式比较，强调选型应基于具体机制而非模糊印象。读者可对照自身需求，逐层回答这些问题，从而得出更严谨的结论。
开放问题：避免将路线图当结论
文章列出四个开放问题，包括native sidecar与Job的兼容性、Gateway API与ServiceProfile的双轨权威、与Falco/Tetragon的联合runbook、以及destination内存SLO。这些问题均需通过测量或官方文档变更来关闭，而非依赖路线图。这提醒读者，在官方明确之前，不应假设这些能力已就绪，应保持谨慎并持续跟踪。
边界关闭：明确系列外内容归属
文章通过边界关闭表，明确将istiod/xDS、Ambient、Cilium L4、Envoy Gateway等主题划归其他系列，本系列只覆盖Linkerd非xDS控制面。这种划分有助于读者按需查阅，避免重复劳动。同时，文章强调未实测跨方案性能，禁止无口径的CPU对比，体现了严谨的技术态度。
Q&A
Linkerd 选型排除树的核心判断依据是什么？
排除树依据可证伪的机制问题决策，如是否需要独立于应用发布变更的 L7 策略、是否需要通用 xDS、能否运维 Linkerd 五轴等，而不是凭“轻量”等口号。
在什么情况下不应该使用 Linkerd？
当编制撑不住五轴、需求只需 Cilium L4、必须通用 xDS、已在 Istio 存量且 Ambient 满足 sidecar-free、安装 tag 与机制文章不一致且无验收门、或把装了 Linkerd 当成南北向 Gateway 已解决时，不应使用 Linkerd。
Linkerd 的甜区（适用场景）是什么？
自管 Kubernetes，需要默认 meshed mTLS 和 destination 流作为一等能力，接受 linkerd2-proxy-api 一对一设计，值班能用五轴排障，机制钉 version-2.20，L7 以 ServiceProfile/policy 为主。
Linkerd 的苦区（不适用场景）有哪些？
把 Linkerd 当“轻量 istiod”查 CDS/EDS、无端点先改 ServiceProfile 却不查 Get() 流、trust anchor 轮转无检查单、native sidecar 与 Job 混谈、用未标定 CPU 海报站队、把 Buoyant 宣传语当开源 tag 能力表。
Linkerd 系列开放问题有哪些？
开放问题包括：native sidecar 默认与 Job/CronJob 的交互、Gateway API 与 ServiceProfile 双轨的权威源、与 Falco/Tetragon 的联合 runbook、destination 内存 SLO 与 EndpointSlice churn。
Linkerd 与 Istio、Cilium 的选型边界如何划分？
需要通用 xDS 或 Envoy Filter 时选 Istio；只需 L3/L4 身份与策略时选 Cilium L4；需要 sidecar-free 且已在 Istio 生态时选 Ambient；需要 meshed mTLS 且能运维五轴时选 Linkerd。
Linkerd 系列如何回收 istio-xds/16 的悬空指针？
通过本系列 01-16 篇展开 Linkerd 机制，包括五轴、API 与发现流、排障等，关闭了 istio-xds/16 中指向 Linkerd 的悬空叶，使两边终章不再悬空。
Linkerd 选型后如何落地 ADR？
将排除树进 ADR，写清卡在哪一叶机制判据，附否证条件；若选 Linkerd，将五轴进发布门禁、native vs legacy 证据包进变更单、trust anchor 轮转进检查单、制品 tag 进验收门；若没选，用机制表做代际复盘。
