> 本文是写作规划，不是可发布正文。拆解对象：Linkerd 在 Kubernetes 上的服务网格控制面与数据面内核——以 Linkerd 2.20（2026-06-23 公告；源码 tag version-2.20；对应 edge edge-26.6.3）为主线，把一次出站/入站连接从 proxy-injector…

本文介绍Linkerd 2.20服务网格控制面内核，聚焦非xDS架构。文章定义五条排障坐标系：注入与网格成员、身份与mTLS、destination发现、策略与L7、数据面健康。核心机制包括proxy-injector注入、identity CSR签发、destination按目标流式推送，以及linkerd2-proxy数据面。文章强调与istiod/xDS的机制差异，并提供16篇系列阅读路线，帮助读者定位故障层级。

本文介绍Linkerd 2.20服务网格的网格成员与注入机制。核心是proxy-injector webhook在Pod创建时注入linkerd-proxy，2.20默认采用native sidecar模式（init容器带restartPolicy: Always），替代传统legacy模式（普通容器加linkerd-init）。文章提供排障指南，区分未注入与已注入但重定向未就绪，并说明opaque ports配置及membership失败排查方法，强调先读Pod spec再查配置。

本文介绍Linkerd 2.20中Pod流量如何透明进入linkerd-proxy。默认路径通过linkerd-init容器设置iptables重定向TCP流量；启用CNI插件时由节点级DaemonSet写入规则，无需init容器。opaque端口跳过协议探测但流量仍经proxy，skip端口则完全旁路。排障需先确认重定向机制生效，再检查identity或destination问题。

Linkerd的identity服务负责签发和轮转工作负载证书，通过CSR与Kubernetes ServiceAccount绑定实现mTLS。证书分三层：工作负载证书自动轮转，issuer和trust anchor轮转更重。与Istio SDS不同，Linkerd使用专用gRPC API，排障时先查leaf，再查issuer，最后查anchor，并注意时钟同步和跨集群信任问题。

Linkerd 2.20的destination控制器通过Informer监视Kubernetes API，将EndpointSlice变更经EndpointTranslator转为per-target的gRPC Get()流推送给proxy。Pod内含四容器：destination负责发现、sp-validator校验ServiceProfile、policy求值策略、反身proxy提供mTLS。2.20优化了等价订阅者间共享状态，内存最高降84%，但需按集群实际churn评估。

本文介绍Linkerd 2.20控制面与linkerd2-proxy间的四套gRPC API：destination、identity、inbound和tap。与istiod/xDS通用协议不同，Linkerd采用专用API，按目标服务名流式查询，错误处理基于gRPC状态码而非ACK/NACK。排障时需查destination.Get流，而非EDS快照。文章强调版本锚定v0.20.0，并对比了与Istio在组件拓扑、L7信息和身份路径上的差异。

本文介绍Linkerd 2.20服务发现机制：每个出站目标独立gRPC流，经EndpointTranslator处理EndpointSlice增量，富化身份、zone等元数据。排障需检查流内Update序列，区分no_endpoints的exists语义，注意队列溢出断流信号，与xDS EDS机制不同。

本文介绍Linkerd 2.20策略模型，核心是三类CRD：Server声明端口入站策略，AuthorizationPolicy定义访问授权，MeshTLSAuthentication指定认证身份。policy容器负责入站策略推送，destination控制器处理出站发现。排障时需区分403拒绝、TLS错误、无端点等不同故障域，避免混淆策略与发现问题。

本文介绍Linkerd 2.20中ServiceProfile的L7流量管理机制。ServiceProfile CRD定义路由、重试和超时，由destination控制器通过GetProfile流推送至数据面。sp-validator webhook负责写入前校验，失败时直接拒绝。与Gateway API分工：SP用于网格内路由，GAPI用于南北向。排障时需区分写入失败（validator）、行为失败（Get vs GetProfile）和策略拒绝（403）。

本文介绍Linkerd 2.20数据面linkerd2-proxy的机制：协议探测区分HTTP与opaque TCP；入站/出站处理链经destination流获取端点与策略；负载均衡默认用EWMA，2.20新增Load Biaser，通过HTTP 429或gRPC RESOURCE_EXHAUSTED信号注入惩罚延迟，避免限流风暴。排障需先查控制面轴1-4，勿混读Envoy模型。

本文介绍Linkerd 2.20中Gateway API与多集群机制。2.20支持GAPI 1.2.1至1.5.1，推荐安装1.2.1，因Linkerd仅理解该版本字段，未知字段会被忽略。mesh内路由由Linkerd处理，南北向入口归Envoy Gateway。多集群需共享信任根，否则握手失败。未钉入2.20版本的能力不写入正文，排障需检查GAPI版本与资源字段。

本文介绍Linkerd 2.20运维要点：控制面升级需按CRD、控制面、数据面顺序执行；trust anchor轮转必须使用bundle过渡并滚动全网格，否则导致TLS握手失败；2.20优化destination内存，但需先确认版本；文档引用应以tag为准，避免live文档误导。

本文介绍Linkerd 2.20服务网格排障方法，提出五轴坐标系：注入与网格成员、身份与mTLS、destination发现、策略与L7、数据面健康。排障时先定位症状对应轴，再下钻组件，区分native sidecar与legacy init+sidecar路径。强调按顺序否证各轴，避免混贴证据或误改配置，并对照Istio xDS排障差异。

本文对比Linkerd 2.20与Istio xDS、Ambient及Cilium L4的机制差异，聚焦控制面协议、数据面引擎与排障坐标。Linkerd采用专用gRPC API与per-Pod代理，适合接受专用API的团队；Istio xDS适合存量CRD或多客户端场景；Ambient在xDS内去sidecar；Cilium适合仅需L3/L4。不比较性能，仅提供机制选型依据。

本文总结Linkerd 2.20版本（源码tag version-2.20）的制品边界与商业生态。自2024年2月起，开源项目不再直接提供stable安装包，由vendor社区制作；机制结论以源码tag为准，edge版本用于前沿追踪。Buoyant提供企业版打包与支持，但价格合同不属本系列。文章明确排障分工：网格问题归本系列，安全告警归Falco/Tetragon，避免混改配置。开放问题如native sidecar对Job/CronJob影响等留待第16篇收束。

本文为Linkerd非xDS控制面系列终章，通过机制排除树收束选型判断，明确何时该用或不用Linkerd。排除树依据L7策略需求、xDS必要性、运维能力等可证伪问题决策。文章回收istio-xds/16悬空指针，列出native sidecar与Job、Gateway API双轨、联合runbook、内存SLO等开放问题，并以ADR语言关闭系列边界，强调机制而非口号。

本文介绍Linkerd 2.20控制面系列文章，涵盖其非xDS架构、五轴排障坐标系（注入、identity、destination、策略、数据面）及16篇路线图。重点区分native sidecar与legacy路径，对比istiod/xDS和Cilium L4，说明专用gRPC控制面优势，并指导选型与排障，强调基于源码tag而非live文档。

Linkerd控制面与Istio不同，不实现xDS，而是拆分为destination、identity、proxy-injector三个独立组件。其API为linkerd2-proxy定制，按目标服务名查询，身份签发走专用CSR接口。Istio合并进istiod单进程，用通用xDS协议。两者是不同工程取舍，无优劣之分。

本文介绍如何在三个GKE集群上部署Linkerd多集群扩展，实现联邦、扁平镜像和网关镜像三种模式共存。通过共享信任锚、全网格链接和标签配置，联邦服务自动故障转移，扁平镜像支持客户端选择特定集群，网关镜像适用于无扁平网络场景。混沌测试验证了集群故障时联邦服务自动重新平衡，而镜像服务需客户端处理。文章提供完整脚本和操作指南。