本文介绍Envoy Gateway v1.9.0南北向控制面内核，聚焦从Gateway API对象到Envoy数据面的转换路径。提出五轴坐标系：附着/status、IR、xDS、数据面、东西向CNI，用于故障定位。强调三不变量：状态写于对象、必经IR层、推送不等于生效。规划16篇系列文章，覆盖路由、TLS、策略等，并对比Cilium Gateway、Istio等方案，提供排障与选型指南。

本文介绍Envoy Gateway v1.9.0中Gateway API的附着与状态机制。核心是三层资源分离：GatewayClass认领实现，Gateway声明入口并控制允许附着的路由，Route声明规则。关键区分Accepted（配置被接受）与Programmed（已交付数据面），跨命名空间引用需ReferenceGrant授权。排障时先查status条件，注意错误parentRef可能无状态反馈。

Envoy Gateway v1.9.0中Kubernetes provider的资源收集与状态写回机制：一次Reconcile收集整个GatewayClass的输入集，而非单个Route；缺失CRD时跳过watch，跨命名空间引用需ReferenceGrant；Status Manager通过UpdateHandler写回，但cache滞后可能导致状态丢失；静态EnvoyGateway配置仅定义watch范围，不替代动态对象。排障时需检查informer、namespace和CRD是否存在。

Envoy Gateway通过Translator将Gateway API资源转换为XdsIR和InfraIR两种中间表示，以解耦配置与Envoy资源树。翻译按固定顺序执行，依赖上下文，并在翻译过程中同步计算状态。XdsIR供xDS Translator使用，InfraIR供Infra Manager管理舰队。即使Gateway失败，仍保留其IR槽位，避免误删基础设施。翻译顺序错误会导致hostname交集、Policy附着和overlap检查不完整。

本文介绍Envoy Gateway v1.9.0中xDS Translator将XdsIR编译为LDS/RDS/CDS/EDS/SDS资源，Infra Manager将InfraIR转化为Envoy部署舰队。强调“已推送”不等于“在服务”，需区分IR、快照、ACK和warming四层。系统错误不发半棵树，NACK时Envoy守旧配置，排障需先确认基础设施再查xDS指标。

本文介绍Envoy Gateway v1.9.0中HTTPRoute与GRPCRoute的路由机制。核心要点：hostname匹配优先于规则，未命中返回404；多条Route按具体度、时间戳等优先级排序，Envoy按RDS顺序首条匹配；GRPCRoute用service/method匹配，无后端返回UNIMPLEMENTED；v1.9新增RouteRulesOverlap警告，仅针对完全相同匹配条件，不改变Accepted状态。排障时需区分404、500、ResolvedRefs失败及Overlap警告。

本文介绍Envoy Gateway v1.9.0的TLS与SDS机制。核心内容：Gateway listener终止客户端TLS，BackendTLSPolicy管理到后端的上游TLS，两者使用不同证书。v1.9破坏性变更包括：SDS URL必须带unix://前缀，系统CA改为共享system_ca_certificates secret，旧EnvoyPatchPolicy匹配的secret/cluster名失效。升级前需检查patch配置，避免静默失配。

Envoy Gateway v1.9.0 升级后，若未安装 Gateway API v1.6 CRDs，TCPRoute/UDPRoute 会被静默跳过，不返回错误提示。v1.6 起这些路由为 Standard v1，standard channel 中 v1alpha2 不再服务，清单需改用 v1。失败表现为无流量或连接失败，应先检查 CRD 版本与 channel。

Envoy Gateway v1.9.0中五类策略（Security、BackendTraffic、ClientTraffic、EnvoyExtension、EnvoyPatch）的生效机制与常见失效原因。重点：mergeType仅允许在xRoute上声明，挂父资源会被拒绝；Lua默认关闭需显式启用；JWT稳定名、限流布局等xDS变更会使旧补丁失效。策略未生效时需先定位是admission拒绝、IR覆盖还是补丁错位。

本文介绍Envoy Gateway v1.9.0中数据面Pod生命周期管理。EnvoyProxy定义舰队，Infra Manager将InfraIR转为Pod，但路由Accepted不保证舰队存在。GatewayNamespaceMode改变部署位置和xDS认证，v1.9修复认证绕过。Remote provider通过gRPC接管InfraIR执行，官方示例非生产级。mergeBackends默认关闭且为实验性，需用selector渐进启用，与mergeGateways互斥。

Envoy Gateway v1.9.0的可观测性需注意：access log仅证明单跳请求，metrics中的xds_nack_total仅表示Envoy拒绝更新，tracing默认客户端采样率改为0%，需显式设置clientSamplingFraction。控制面与数据面指标分离，不可混用。各信号对应不同排障维度，避免误判。

Envoy Gateway v1.9.0升级需注意：CRD与控制器分离管理，VAP策略移入chart需补Helm所有权或关闭渲染；TCP/UDP路由需先升级Gateway API v1.6否则静默跳过；xDS接收上限增至32MiB，断流可能无NACK。升级需按层检查，避免流量静默中断。

本文介绍Envoy Gateway排障方法，提出五轴坐标系：附着/status、IR、xDS、Envoy数据面、东西向。强调先定位故障轴再处理，避免盲目修改YAML。核心是区分status条件（Accepted/Programmed/ResolvedRefs）与实际数据面状态，注意NACK、IR空、observedGeneration不匹配等陷阱，并指出Programmed不等于流量已切换。

本文对比Envoy Gateway与Cilium、Istio、Ingress注解等替代方案，聚焦翻译内核与排障坐标差异，而非性能。核心观点：各实现虽支持Gateway API，但控制面机制不同，如Cilium嵌入Envoy、Istio用istiod、Contour独立翻译器。选型需考虑团队隔离与观测链需求，避免硬套统一排障方法。

本文讨论Envoy Gateway与Cilium东西向数据面的排障接缝。请求离开网关后，失败可能落在Cilium的identity策略、Service BPF或加密路径。需区分北段（Gateway状态、Envoy日志）与南段（Hubble、identity），禁止交叉解释。固定CNI模式、KPR、加密、Gateway四元组，避免误判。工单改派需明确字段，不伪造证据。

本文是Envoy Gateway系列终章，通过机制排除树收束选型判断，明确何时不应运行Envoy Gateway，并回收Cilium与Tetragon系列指向的南北向内容。文章列出排除树判据、否证条件、四个开放问题（如status是否足以当SLO），并给出ADR友好的收束建议，强调先排除再选择，避免品牌口号式讨论。

本文介绍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等替代方案，指导选型与故障归因。