网络策略

背景与问题界定 某跨国电商平台的 Kubernetes 集群同时承载了内部业务、第三方集成和面向公网的 API 网关，租户隔离仅靠 namespace 逻辑分隔。安全审计发现：一个被攻破的博客容器可以通过 Cluster IP 直接访问支付数据库 Pod 的 3306 端口，没有任何网络层面的访问控制。Kubernetes 原生的 NetworkPolicy 提供了五元组规则的抽象语义，但在实际生产环境中面临着性能瓶颈、策略粒度不够精细、日志审计缺失等多重挑战。随着 Cilium 基于 eBPF 的技术路线成为 CNCF 毕业项目，团队需要在 Calico 和 Cilium 之间做出符合长期技术架构方向的选择。 目标拆解与工程约束 高性能策略执行：网络策略的匹配和执行必须对 Pod 间的网络延迟产生小于 5% 的影响，在大规模集群（300+ 节点、5000+ 策略规则）下，策略更新的收敛时间不能超过 10 秒。 L7 层策略支持：除了传统的 IP:Port 五元组控制，需要支持基于 HTTP 方法、路径、gRPC 服务名、Kafka Topic 等七层协议粒度的访问控制，满足微服务粒度的最小权限原则。 日志审计与可视化：被拒绝的流量必须记录完整的客户端/服务端信息、协议类型和拒绝理由，通过标准接口导出到 SIEM 系统，同时提供可视化拓扑图用于策略编排和合规审计。 多云可移植性：网络策略的定义和 API 需要在 AWS、阿里云和自建机房之间保持语义一致，不依赖特定云厂商的网络 overlay 实现，策略即代码（Policy as Code）可版本化管理和 GitOps 化。 方案设计 我们对比了 Calico 和 Cilium 两种方案。Calico 采用基于 iptables 和 IPVS 的数据面，NetworkPolicy 通过 Felix Agent 转换为 iptables 规则链。优势是成熟稳定、社区支持广泛、对传统网络运维友好；但在大规模集群中，iptables 规则链的线性匹配导致性能退化明显，策略变更时需要全量刷新规则，5000 条规则的集群中策略收敛耗时达 30 秒以上。 ...