【Istio 控制面】代理身份与订阅：sidecar、ztunnel、waypoint、Gateway 谁在订阅什么
内容提要
本文介绍Istio 1.30.3中四类xDS客户端（Sidecar、Router、Waypoint、Ztunnel）的身份与订阅机制。身份分两层：节点ID是自述，仅认证后的SPIFFE身份可信。订阅范围由类型URL决定，标准Envoy请求LDS/CDS等，Ztunnel请求自定义Address类型，两者生成器路径不相交。NodeType影响推送判定而非订阅权限。Ztunnel用Rust实现，资源占用更优，但需独立维护生成器。
延伸解读
身份自述与可信身份的分层
节点ID和NodeMetadata是客户端自己声明的，未经认证前不可信。只有通过mTLS或JWT认证后，istiod才会将证书中的SPIFFE URI写入VerifiedIdentity。排障时，涉及授权判断应依据VerifiedIdentity，而非节点ID中自称的Namespace或ServiceAccount，否则可能被伪造身份误导。
订阅范围由类型URL决定，而非代理类型
标准Envoy客户端（Sidecar、Router、Waypoint）请求LDS/RDS/CDS/EDS/SDS，ztunnel请求自定义的Address/Authorization，两者在生成器表中天然不相交。NodeType主要影响推送判定（如xdsNeedsPush对ztunnel走独立路径），而非订阅权限。理解这一点有助于避免误以为ztunnel会订阅Cluster等类型。
ztunnel的定制化设计权衡
ztunnel采用Rust实现，使用自定义的Address/Authorization类型，官方文档称相比Envoy通用类型有约十倍体积、内存和CPU优势，但这是官方在特定环境下的实测结论，并非普遍精确倍数。代价是需要独立维护生成器和调试路径。这种设计适合资源受限的每节点代理，但通用性不如标准xDS。
Q&A
Istio 1.30.3 中，xDS 客户端的身份是如何确定的？
身份分两层：节点 ID 和 NodeMetadata 是客户端自述，仅经过 mTLS 或 JWT 认证后写入的 VerifiedIdentity（SPIFFE 身份）才可信。
ztunnel 与标准 Envoy 客户端订阅的 xDS 资源类型有何不同？
标准 Envoy 客户端（sidecar、waypoint、router）订阅 LDS/RDS/CDS/EDS/SDS，而 ztunnel 订阅自定义的 Address 和 Authorization 类型，两者在生成器表中不相交。
NodeType 在 Istio 控制面中起什么作用？
NodeType 影响推送判定而非订阅权限。例如，xdsNeedsPush 对 ztunnel 走独立路径，waypointNeedsPush 让 waypoint 感知 ambient 附着关系。
Istio 1.30.3 中有哪几类 xDS 客户端？它们各自的部署粒度是什么？
四类：Sidecar（每 Pod）、Router（每个 Gateway 部署独立副本）、Waypoint（每命名空间或每 ServiceAccount 一组）、Ztunnel（每节点一个 DaemonSet）。
为什么 ztunnel 选择使用 Rust 实现？
官方在 Rust、Go、Envoy 之间评估后选择 Rust，理由是性能与可控的资源占用，且自定义的 Address/Authorization 类型相比通用 xDS 类型有约十倍的优势（官方实测）。
ztunnel 的身份模型有何特殊之处？
ztunnel 以自己的身份向 CA 认证，但代表节点上其他工作负载请求证书，CA 基于 Kubernetes ServiceAccount JWT 验证其代表权。
通用 xDS 类型与领域特化协议各有何优缺点？
通用类型（如 LDS/CDS）覆盖广、调试工具统一，但表达简单语义成本高；特化类型（如 ztunnel 的 Address）信息密度高、解析成本低，但需单独维护生成器。
