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

Envoy Gateway通过Translator将Gateway API资源转换为XdsIR和InfraIR两种中间表示，以解耦配置与Envoy资源树。翻译按固定顺序执行，依赖上下文，并在翻译过程中同步计算状态。XdsIR供xDS Translator使用，InfraIR供Infra Manager管理舰队。即使Gateway失败，仍保留其IR槽位，避免误删基础设施。翻译顺序错误会导致hostname交集、Policy附着和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与Cilium、Istio、Ingress注解等替代方案，聚焦翻译内核与排障坐标差异，而非性能。核心观点：各实现虽支持Gateway API，但控制面机制不同，如Cilium嵌入Envoy、Istio用istiod、Contour独立翻译器。选型需考虑团队隔离与观测链需求，避免硬套统一排障方法。

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

Cilium的L7服务网格能力基于BPF处理L3/L4，按需将流量重定向至节点Envoy处理L7语义，与sidecar和Istio Ambient模式不同。它适合以身份和L3/L4策略为主、L7规则较少的场景，但节点Envoy是共享故障域，且不覆盖完整Istio流量管理功能。开启时应渐进验证，避免“假网格”承诺。

本文对比Cilium eBPF与Calico、kube-proxy、Envoy sidecar及Ambient四条数据面路径，强调选型应基于机制而非功能清单。Cilium适合以identity为核心、需统一观测的场景；Calico适合已有BGP运维体系；kube-proxy适合规则简单集群；sidecar/Ambient适合需L7策略。指出混合部署可行，但需明确流量分层与排障坐标，避免投机性迁移。

本文为HAProxy数据面系列终章，通过排除树对比Nginx、Envoy、eBPF选型：HAProxy适合深度L4/L7负载均衡与热改运行态；Nginx偏Web反代；Envoy需API驱动；eBPF仅L3/L4。强调机制优势须支付迁移税，并列出stick-table一致性、QUIC成熟度、运维可观测性等开放问题，建议按排障坐标选型而非品牌口号。

本文介绍Istio控制面排障的五轴核对表：翻译、推送、ACK、warming、身份。每轴对应特定istioctl命令或Envoy admin端点，如analyze查翻译、proxy-status查推送、proxy-config查ACK、config_dump查warming、secret查身份。强调各轴独立，单看任一绿色指标不能确认配置生效，需按序逐层排查，避免误判和跨团队甩锅。

本文详解Istio控制面一次配置变更如何转化为代理收到的DiscoveryResponse，梳理六阶段完整链路：事件汇入、debounce合并、全局重算、按代理排队、生成发送及代理确认。强调PushQueue合并机制、Full决定重算范围、VersionInfo统一生成，并指出xds.Send成功不等于Envoy已生效，排障需区分各阶段。

本文介绍Istio控制面中K8s Service、EndpointSlice和WorkloadEntry如何转换为Envoy的CDS/EDS资源。核心是服务注册聚合层将三种来源统一为model.Service和model.IstioEndpoint，CDS按“Service×端口”生成Cluster，EDS按hostname索引端点。两者通过service_name字符串对齐，WorkloadEntry需特殊开关接入，健康状态无kubelet兜底。

本文分析Istio控制面istiod对Envoy NACK的处理机制：istiod仅记录错误并计数，不重试或回滚；通过PushOrder常量实现CDS→EDS→LDS→RDS的推送顺序，但只保证同批发送顺序；istiod可观测性止步于协议层，warming等Envoy内部状态无法感知，排障需结合控制面与数据面信号。

本文是Envoy数据面代理内核系列的首篇，介绍Envoy作为API驱动、Filter可编程的数据面代理的定位。文章规划了16篇阅读路线，并确立了五条分析坐标系：请求路径、线程快照、匹配改写、xDS一致性及上游资源。同时讨论了与站内其他文章的分工及开放争论，为后续深入解析Envoy机制奠定基础。

本文介绍Envoy HTTP连接管理器（HCM）与编解码器（Codec）的作用：HCM将字节流转为HTTP事件，处理日志、追踪等；Codec屏蔽HTTP/1、2、3协议差异，统一为stream模型。强调区分连接与流生命周期，错误排查需先检查编解码和ALPN，再考虑Router。

Envoy HTTP过滤器链中，Router必须是最后一个终端过滤器，其后的过滤器不会生效。重试和超时配置在路由策略中，由Router执行，总超时包含所有重试，默认不重试。常见误配包括过滤器顺序错误、重试无预算限制等，需注意授权过滤器与路由缓存的一致性。

Envoy中Cluster是上游逻辑分组，路由选定名字后，主机选择按优先级、本地性、子集和负载均衡算法逐层收窄。优先级用超额配置健康分数渗漏流量，子集依赖元数据匹配，错误回退会伪装成无上游。选中主机后，连接池、熔断和异常检测决定是否返回503。

本文探讨Envoy代理中连接池、熔断和异常检测机制如何导致路由正确时仍出现503错误。连接池按线程/协议分池，熔断限额跨Worker共享但最终一致，溢出是503首要嫌疑。异常检测被动摘除异常主机，可与主动健康检查叠加。排障需检查熔断计数、驱逐事件和优先级分流，调参须按优先级独立阈值理解。

本文介绍Envoy xDS配置的资源树结构，核心为LDS→RDS→CDS→EDS（及SDS），通过名称引用形成依赖链。推送顺序至关重要，需遵循make-before-break原则：先CDS/EDS，再LDS，最后RDS，避免黑洞。Warming决定资源何时可用，ACK不等于依赖就绪。控制面需按序推送，确保数据面稳定切换。

本文介绍Envoy数据面代理的扩展机制，涵盖Wasm、Lua、ext_authz和限流过滤器。Wasm提供沙箱隔离但属实验特性；Lua适合可信粘合逻辑但需防路由缓存绕过鉴权；ext_authz将决策移至外部服务；限流分本地和全局两种。选型需权衡隔离性、延迟和信任域，热点路径慎用Wasm。

本文介绍Envoy数据面代理生产排障方法，强调先选坐标系再查admin，避免空转。将常见症状映射到请求路径、线程快照、匹配改写、xDS一致性、上游资源五轴，并给出可核对的admin/观测入口。核心观点：ACK、warming、流量切换是三件事，黑洞多落在中间；无上游、证书、池耗尽、泄漏各有排除树；Hot restart不迁移既有连接，drain参数是发布风险。