EKS 网络可观测性实战：用 Cilium + Hubble 定位流量与策略拒绝

决策结论：Hubble 不是 Amazon VPC CNI 的旁路插件；只有目标 Cilium release 已存在且目标 Pod 流量确由 Cilium 数据路径接管时，才启用 Hubble。支持结论：替代 CNI/chaining 会改变支持责任与数据路径，生产前必须按 EKS、Cilium 发行方及企业支持约定完成同构验证和回滚演练。版本说明：本文不假定stable、CLI 参数或 Helm key 跨版本不变；所有命令和配置均须绑定团队批准的 Cilium chart、Cilium CLI 与 Hubble CLI 固定版本核验。摘要Kubernetes 网络故障常被概括成“服务访问不了”，根因却可能位于 DNS、TCP 握手、Service 转发、应用七层协议或网络策略中的任意一层。传统排查依赖kubectl exec、抓包和逐层猜测，很难快速回答“谁访问了谁、流量在哪一步被丢弃”。Cilium 在节点数据路径中利用 eBPF 产生网络与安全事件，Hubble 将事件组织为可过滤的 Flow、Service Map 和 Prometheus 指标。但 Hubble 不是能直接加装到 Amazon VPC CNI 上的独立旁路探针：它依赖 Cilium 数据路径，因此必须先明确 CNI 路径、AWS 支持边界和迁移风险。本文先完成架构决策，再给出官方 Helm 启用方法，最后用可复现的过滤方法定位 DNS、TCP、HTTP 和策略拒绝问题。