Envoy Gateway / Gateway API：从 CR 附着到 xDS
内容提要
本文介绍Envoy Gateway v1.9.0南北向控制面系列文章，聚焦从Gateway API附着、status、Provider watch到XdsIR/InfraIR、xDS Translator及Infra Manager的编译管线。涵盖HTTPRoute、TLS/SDS、L4路由、Policy attachment等主题，提供排障五轴坐标系，并对比Cilium Gateway、Istio等替代方案，指导选型与故障归因。
延伸解读
版本锚定与静默行为
文章强调所有机制结论均基于 Envoy Gateway v1.9.0 源码 tag，而非 latest 文档。特别指出若未安装 Gateway API v1.6 CRDs，TCPRoute/UDPRoute 会静默跳过，这可能导致路由不生效但无显式报错。读者在升级或部署时需核对 CRD 版本，避免因版本不匹配而出现难以排查的故障。
Accepted 状态不等于生效
文章指出 Accepted=True 仍可能出现 404 或无监听器的情况，因为状态与 IR 翻译、xDS 推送、Envoy 实际加载之间存在多个环节。读者应理解 status 只是控制面处理的一部分，最终生效需依赖数据面 ACK 和实际配置加载，排障时需沿五轴逐层检查。
Policy 生效的隐藏条件
文章提到 Policy 不生效可能源于 mergeType 仅允许挂 xRoute、Lua 默认关闭、或 Patch 匹配了旧 xDS 名。这些细节容易被忽略，导致配置看似正确却无效果。读者在配置 Policy 时应确认类型支持、默认开关及匹配目标，避免因默认值或命名问题造成预期偏差。
选型需基于机制而非功能列表
文章对比 Envoy Gateway 与 Cilium Gateway、Istio、Ingress 时，强调基于机制表而非延迟排行。读者在选择路径时应关注控制面编译方式、故障归因难度、与现有 CNI 的接缝等机制差异，而非仅看功能清单，以便在长期运维中降低排障成本。
Q&A
Envoy Gateway 控制面中，从 Gateway API 资源到最终 Envoy 配置的编译管线包含哪些主要阶段？
管线主要包括：Gateway API 资源附着与 status 计算、Provider watch 监听资源变化、Gateway API Translator 生成 XdsIR 和 InfraIR、xDS Translator 将 XdsIR 转换为 LDS/RDS/CDS/EDS/SDS，以及 Infra Manager 管理 Envoy 数据面舰队。
为什么 Gateway API 资源显示 Accepted=True 但实际访问仍可能 404？
Accepted=True 只表示资源被接受，但实际生效还取决于后续阶段：IR 翻译是否正确、xDS 是否成功推送并被 Envoy 加载、以及 Envoy 是否完成 warming。若 IR 为空、xDS NACK 或 Envoy 仍服务旧快照，都可能导致 404。
TCPRoute 或 UDPRoute 在什么情况下会静默消失？
如果未升级 Gateway API CRDs 到 v1.6，TCPRoute/UDPRoute 等 L4 路由会因版本不匹配而被静默跳过，不会报错。
Envoy Gateway 中 Policy 不生效可能的原因有哪些？
可能原因包括：Policy 的 mergeType 仅允许挂载到 xRoute 上，若挂载位置不对则不生效；Lua EEP 默认关闭；或者 Patch 匹配了旧的 xDS 名称，导致修改未应用到当前配置。
Envoy Gateway 与 Cilium Gateway、Istio 相比，在选型时主要考虑哪些方面？
选型需考虑控制面复杂度、南北向 xDS 税、与现有 CNI 的接缝、功能覆盖和运维成本。Envoy Gateway 适合需要精细控制且愿意承担 xDS 复杂度的场景；Cilium Gateway 与 CNI 集成紧密；Istio 提供完整服务网格能力。
排障时如何快速定位南北向请求失败所在的层？
使用五轴坐标系：status、IR、xDS、Envoy 数据面、入口之后的东西向 CNI。先判断故障属于哪一轴，再下钻到具体模块，例如检查 status 是否 Accepted、IR 是否为空、xDS 是否 NACK、Envoy 是否加载新快照等。
