【Envoy Gateway】东西向接缝：把失败交回 Cilium 五轴而不污染南北向坐标
内容提要
本文讨论Envoy Gateway与Cilium东西向数据面的排障接缝。请求离开网关后，失败可能落在Cilium的identity策略、Service BPF或加密路径。需区分北段（Gateway状态、Envoy日志）与南段（Hubble、identity），禁止交叉解释。固定CNI模式、KPR、加密、Gateway四元组，避免误判。工单改派需明确字段，不伪造证据。
延伸解读
北段与南段：责任切分的关键
文章强调，请求离开Envoy Gateway后，失败可能发生在Cilium的东西向数据面，因此排障必须区分北段（Gateway状态、Envoy日志）和南段（Hubble、identity）。北段证据来自status、IR/xDS和Envoy访问日志，南段则依赖Cilium的identity、Hubble verdict等。跨段解释会污染两套坐标系，导致误判。
两套口令：避免交叉解释
文章提出两套排障口令：北段口令关注EG状态、IR/xDS和Envoy日志，南段口令关注identity、Hubble和Service/KPR。例如，外部404/500应先查EG轴，而不是直接看Hubble deny；网关日志200但客户端超时，则转入南段排查。禁止交叉使用，如用HTTPRoute状态解释Hubble拒绝，或用map压力解释证书问题。
四元组固定：复现与排障的前提
文章强调，在复现或排障时，必须固定CNI模式、KPR、加密和南北向实现这四个维度，否则无法准确归因。例如，KPR半开可能导致网关200但ClusterIP不通，这属于Cilium的Service所有权问题，而非EG的IR问题。四元组应写入变更单，避免现场猜测。
工单改派：语义模板与证据要求
文章提供了工单改派的语义模板：北段关闭时需写明Gateway/Route条件、Envoy日志的response_code和details，以及流量离开Envoy后的下一跳（ClusterIP、Headless或Pod IP）。南段关闭时需提供Hubble verdict或明确的无drop陈述。禁止粘贴HTTPRoute YAML到Hubble工单，或map压力截图到EG工单。
Q&A
Envoy Gateway 与 Cilium 东西向数据面排障时，如何划分北段和南段？
北段指请求到达 Envoy Gateway 及 Envoy 数据面的部分，证据包括 Gateway/Route status、Envoy 访问日志、IR/xDS 等；南段指请求离开网关进入集群后的部分，证据包括后端 Pod identity、Hubble verdict/reason、是否经 ClusterIP、加密路径等。北段用 Envoy Gateway 的排障方法，南段用 Cilium 的排障方法，禁止交叉解释。
当 Envoy Gateway 返回 200 但客户端仍超时，应该怎么排查？
如果 Envoy 访问日志显示 200，说明北段正常，问题可能出在南段。此时应切换到南段排查：检查 identity、Hubble verdict、Service/KPR、加密路径等。不要重新修改 HTTPRoute 重试。
在 Envoy Gateway 与 Cilium 的排障中，哪些字段是禁止交叉解释的？
禁止用 HTTPRoute 的 Accepted 状态解释 Hubble Policy denied，也禁止用 Cilium map 压力解释 Gateway 证书未就绪。北段和南段的证据必须分开使用，不能混用。
工单从北段改派到南段时，需要包含哪些关键信息？
需要包含：北段关闭句（写明 Gateway/Route 条件类型与 reason、Envoy 访问日志的 response_code 和 response_code_details）、切换点（下一跳是 ClusterIP、Headless 还是直连 Pod IP）、四元组快照（CNI 模式、KPR、加密、南北向实现）。禁止粘贴 HTTPRoute YAML 或 cilium_bpf_map_pressure 截图。
在 Envoy Gateway 与 Cilium 集成时，需要固定哪些四元组参数？
需要固定 CNI 模式（chaining 与否、native/tunnel）、KPR（开/关）、加密（WireGuard/IPsec/关）、南北向实现（Envoy Gateway 或 Cilium Gateway 等）。固定这些参数才能避免误判问题归属。
独立 Envoy Gateway 与 Cilium Gateway 在 KPR 前置条件上有什么不同？
Cilium Gateway 要求 KPR=true 才能启用，而独立 Envoy Gateway 不继承这个硬性前置，可以运行在非 Cilium CNI 上。但如果南段是 Cilium，KPR 半开仍可能导致网关 200 但 ClusterIP 不通的问题。
在启用 Envoy Gateway 与 Cilium 接缝前，上线检查单包括哪些项？
检查单包括：北段基线已绿（第 13 篇轴一至四有 runbook）、四元组写死、南段基线已绿（无网关时 Cilium 轴一至四有 Hubble/map 口令）、回程与健康检查无冲突、回滚面（摘掉 HTTPRoute 后东西向五轴仍可独立值班）。
为什么在 Envoy Gateway 与 Cilium 集成时，不能假设问题总有 Policy denied 文案？
因为某些组合（如 Gateway API + 云 CNI chaining + native routing + WireGuard node encryption）可能出现跨节点南北向黑洞且 Hubble 不见 drop。因此不能依赖 Policy denied 作为唯一线索，需要固定四元组进行复现。
