【Istio 控制面】Linkerd 对照：非 xDS 的控制面机制
内容提要
Linkerd控制面与Istio不同，不实现xDS，而是拆分为destination、identity、proxy-injector三个独立组件。其API为linkerd2-proxy定制，按目标服务名查询，身份签发走专用CSR接口。Istio合并进istiod单进程，用通用xDS协议。两者是不同工程取舍，无优劣之分。
延伸解读
控制面拓扑：合并与拆分的运维权衡
Istio 将发现、CA、注入合并进 istiod 单进程，简化部署但共享故障域；Linkerd 拆分为 destination、identity、proxy-injector 三个独立 Deployment，故障域更小但组件间依赖通过 gRPC 网络调用，仍存在耦合。选择哪种拓扑取决于运维对故障隔离和部署复杂度的偏好。
协议设计：通用性与复杂度的取舍
xDS 作为通用协议支持多数据面，但需承担 ACK/NACK 状态机复杂度；Linkerd 的专用 API 与 linkerd2-proxy 强耦合，简化了错误处理，但牺牲了多数据面兼容性。这是同一设计选择的两面，并非功能缺失，而是工程取舍。
身份签发路径的差异与运维影响
Istio 通过 SDS 资源推送证书，失败模式内建在 xDS 状态机；Linkerd 使用专用 CSR 接口，证书轮转分层：工作负载证书自动轮转，签发者证书可自动切换，信任锚轮转需重启控制面与代理。排障入口不同，需按各自机制定位问题。
Q&A
Linkerd 控制面与 Istio 在架构上有何主要区别？
Linkerd 控制面拆分为 destination、identity、proxy-injector 三个独立组件，而 Istio 自 1.5 起将 Pilot、Citadel、Galley 等合并进单一的 istiod 进程。Linkerd 的拆分使得每个组件可以独立扩缩和故障隔离，但增加了组件间协作的复杂度；istiod 简化了部署拓扑，但共享故障域。
Linkerd 控制面使用什么 API 协议？与 Istio 的 xDS 有何不同？
Linkerd 控制面使用 linkerd2-proxy-api 中定义的专用 gRPC 接口，为 linkerd2-proxy 量身定制，按目标服务名逐个查询并流式接收更新。Istio 使用通用 xDS 协议，按资源类型和资源名集合订阅，支持全量或增量推送。
Linkerd 和 Istio 在身份签发机制上有何不同？
Linkerd 的代理启动时向 identity 服务发送 CSR，identity 校验后签发绑定到 Pod ServiceAccount 的证书，走专用 gRPC API。Istio 通过 SDS（Secret Discovery Service）以 xDS 资源形式推送证书材料给 Envoy，SDS 是通用 xDS 资源类型之一。
为什么 Linkerd 不需要像 Istio 那样复杂的 ACK/NACK 状态机？
因为 Linkerd 的 API 是专用的，按目标服务名查询，错误处理依赖标准 gRPC 状态码和重连逻辑，不需要资源级别的 ACK/NACK。而 xDS 是通用协议，必须处理任意客户端可能以任意方式拒绝资源的情况，因此需要 ACK/NACK 状态机。
Linkerd 的 destination 组件内部是如何工作的？
destination 部署实际上是一个 Pod 里跑四个容器：Go 写的 destination 控制器（基于 client-go 的 Informer/Reflector，事件驱动）、Service Profile 校验 webhook、独立的 policy 判定容器，以及一个反身注入的 linkerd-proxy（让控制面自身流量也被 mTLS 保护）。
Linkerd 和 Istio 在证书轮转机制上有何不同？
Linkerd 自动轮转工作负载证书（短期证书由代理自主发起续期），签发者证书轮转通常无需重启（代理侦测到 Secret 更新后自动切换），但信任锚轮转必须重启控制面与全部代理。Istio 的证书失败模式内建在 xDS 的通用状态机中，通过 SDS 推送。
Linkerd 和 Istio 的控制面设计哲学有何根本差异？
Istio 押注 xDS 作为可被多数据面复用的通用协议，而 Linkerd 押注专用 API 与专用轻量代理的强耦合，换取更小的 Rust 数据面攻击面与更简单的单一实现路径。两者是不同工程取舍，无优劣之分，评判需依据具体场景。
