Kubernetes 里的 NetworkPolicy说白了就是给 Pod 之间加的一层分布式防火墙。它跟传统“防火墙设备 区域 接口”那套思路完全不同核心是“用标签选择器描述谁可以访问谁”。但在真实集群里你光写 NetworkPolicy 没用底层还是得靠 CNI 插件把这些策略翻译成节点上的实际转发规则。Calico、Cilium、Flannel 这三个最常见的方案翻译方式差别非常大Flannel 自己基本不管策略Calico 用传统的 iptables 规则链模拟防火墙Cilium 则用 eBPF 把策略直接编译进内核数据路径。这篇文章我结合自己搭建和运维集群的实际经历把三者在实现 NetworkPolicy 时的原理、差异、性能影响和踩坑经验完整梳理一遍适合正在做 CNI 选型、或者被“策略不生效”折磨过的人参考。1. 先把 NetworkPolicy 的“防火墙”本质搞清楚1.1 为什么 Kubernetes 的防火墙和传统防火墙长得不一样传统防火墙常见的形态是一台设备上面有物理网口你按“区域”划分信任等级再写“源 IP、目的 IP、目的端口、动作”这种五元组规则。你脑子里会有清晰的拓扑图数据包从哪个口进、从哪个口出一目了然。Kubernetes 里完全不是这个逻辑。Pod 的 IP 是动态分配的随时可能漂移副本数一变IP 列表就全变了。你不可能像传统防火墙那样给每台 Pod 手工配一张“允许访问 10.0.0.5:3306”的表。所以 NetworkPolicy 采用了“声明式描述 动态翻译”的模型它按 namespace 生效用podSelector选中一组目标 Pod。用ingress描述“允许哪些来源访问这组 Pod 的哪些端口”。用egress描述“这组 Pod 允许访问哪些外部目标”。默认情况下没有 NetworkPolicy 选中 Pod 时所有流量都放行一旦有策略选中了某个 Pod这个 Pod 就进入“隔离状态”任何没有被显式 allow 的流量都会被丢弃。这里有个容易误解的点NetworkPolicy 只是“期望状态”的描述真正执行策略的不是某个中心化的防火墙进程而是每个节点上的网络插件组件。每个节点的转发路径上都要挂上策略检查点数据包才能被放行或丢弃。所以不同 CNI 插件的实现差异直接决定了策略的转发性能、规则上限、支持范围以及排障难度。1.2 三个插件的起点就不一样我把三者的定位先做个简单概括Flannel 只解决“连通性”它就是一个 overlay 网络把不同节点上的 Pod 网络打通让流量能到达目的地。它本身不关心“谁访问谁”也不提供策略引擎。Calico 解决“连通性 安全策略”它采用传统的路由和 iptables 方案自带可编程的策略引擎Felix能把 NetworkPolicy 翻译成一组完整的 iptables 规则链。Cilium 解决“连通性 安全策略 可观测性”它用 eBPF 在数据路径上执行策略同时维护 identity身份标识机制把策略规则的规模和查找开销降得很低。这三者起点不同决定了它们在 NetworkPolicy 上的能力差距不是“优化得好不好”而是“有没有原生支持”。Flannel 想支持 NetworkPolicy就得额外挂一个组件Calico 和 Cilium 则是天生就把策略引擎内置在主流程里了。这里顺带提一个选型认知CNI 是否支持 NetworkPolicy是 kubectl 和集群安装工具在“CNI 支持矩阵”里标明的能力不是装了插件就自动具备。你需要先确认插件里有没有 watch NetworkPolicy 对象并下发规则的组件再谈策略能不能生效。2. Flannel网络连通没问题策略天生是“借来的”2.1 Flannel 的工作方式Flannel 最常见的模式是 VXLAN overlay。它会在每个节点上创建一个虚拟网卡flannel.1VXLAN VTEP每个节点分配一个独立的 Pod 网段比如 Node1 分到10.244.0.0/24Node2 分到10.244.1.0/24。跨节点的 Pod 包会从源 Pod 的 veth 进入宿主网络栈再被路由到flannel.1由内核封装成 VXLAN 报文从物理网卡发到对端节点再解封装后进入目标 Pod。这个模型非常朴素它要做的就是“把包送到”就像给每家每户铺了一条路但路上不设任何关卡。流量只要路由可达谁都能互相访问。这也是很多测试环境选 Flannel 的原因简单、稳定、出问题概率低。但正因为如此Flannel 没有实现 Kubernetes CNI 规范里的 NetworkPolicy 能力。它不是“支持得差”而是“根本不参与”。如果你在 Flannel 集群里写了 NetworkPolicy 并发现完全没效果这是正常现象不是配置错误。2.2 Flannel 额外组件的实现方式及代价想用 Flannel 又想要 NetworkPolicy实践中通常有三条路组装 Calico 的 policy-only 模式Flannel 负责网络连通Calico 只跑 Felix 组件由 Felix 去 watch NetworkPolicy 并生成 iptables 规则。这样 Calico 不做路由、不搞 BGP只是“借”给 Flannel 一个策略引擎。使用 kube-routerkube-router 本身用 iptables 实现 NetworkPolicy同时还能用 IPVS 替代 kube-proxy一个组件同时承担服务代理和网络策略。使用 Cilium 的 chaining 模式把 Cilium 挂在 Flannel 之上让 Cilium 通过 eBPF 执行策略网络层仍然由 Flannel 提供。这几条路都能让“Flannel 集群”具备 NetworkPolicy 能力但代价是系统中出现了两套网络组件共存的局面。你不再是维护一个“Flannel”而是在维护“Flannel Calico/Felix”或“Flannel Cilium”的组合。排障时要先确认路径上哪个组件负责策略再看节点上的 iptables 规则或 BPF 程序复杂度至少翻倍。另外要注意Flannel 的 VXLAN 隧道本身会带来额外的封装开销。你在这条隧道上叠加策略规则策略检查点通常位于宿主机网络栈的 FORWARD 链或 INPUT/OUTPUT 链上因此额外组件在 OpenStack、VMware 等环境里还可能跟底层的安全组产生联动问题。我实际见过因为底层安全组把 VXLAN UDP 端口封了导致上层策略“看起来正常”但跨节点流量全断的案例。2.3 Flannel 方案适合谁Flannel 方案适合的场景非常明确单节点测试、小型开发环境、对网络隔离要求不高的集群。如果你是 K8s 新手想先跑通应用Flannel 是很稳妥的起点。但如果你是生产环境有多个业务团队共用集群或者有等保、合规层面的隔离要求我建议直接放弃“Flannel 额外策略组件”的路线换一个原生支持 NetworkPolicy 的 CNI。借用来的策略不仅功能有限而且多一层联动就多一个故障点。如果实在要保留 Flannel并且通过加装 Calico policy-only 组件来支持策略有几个注意点一定要记住放行 kube-system 命名空间里的关键流量否则 DNS 解析会被策略误伤整个集群都会出现“应用起来了但域名解析失败”的诡异问题。不要对节点网段做过于激进的 egress 限制否则 kubelet 健康检查可能无法到达 Pod。VXLAN 默认 MTU 是 1450如果业务层还有 IPSec 或者隧道叠加要把 MTU 调得更小否则大包传输直接卡死。3. Calico把经典防火墙策略翻译成 iptables 规则3.1 Calico 的整体架构和路由机制Calico 是目前生产环境里最主流的 CNI 之一它的架构核心由几个部分组成calico-node这个 DaemonSet 里包含 Felix策略引擎和 BIRDBGP 客户端此外还有 CNI 插件和kube-controllers负责同步一些 K8s 资源。数据存储默认使用 Kubernetes API也可以使用独立的 etcd现在一般建议直接走 K8s API。Calico 在网络连通层面提供多种模式。如果节点之间三层可达它可以用纯 BGP 路由模式每个节点把自己负责的 Pod 网段通过 BGP 广播出去数据包直接通过物理网络路由到目标节点不需要做任何隧道封装。如果底层网络不支持 BGP或者节点跨了不可控的二层网络Calico 也支持 IPIP 封装和 VXLAN 封装功能上类似 Flannel 的 overlay。从“防火墙”角度看真正决定策略能力的是 Felix。Felix 会 watch Pod、命名空间、NetworkPolicy、GlobalNetworkPolicy 等资源把它们翻译成节点本地的数据路径规则。Calico 一直以 iptables 作为主要数据面虽然新版本引入了 eBPF 数据面但大多数生产集群仍然运行在 iptables/nftables 路径上。3.2 Felix 如何把 NetworkPolicy 变形为 iptables 链我在排障时经常需要查看iptables-saveCalico 生成的规则链非常有标志性自带cali-前缀。整体流程可以这样理解数据包从 Pod 的 veth 进入宿主机后会进入 FORWARD 链。Calico 在 FORWARD 链里插入cali-FORWARD再从这里分派到各个工作负载对应的策略链。每个被 NetworkPolicy 选中的 Pod都会有一组策略链链里按顺序排列“来源选择器展开后的 IP 列表 目标端口”规则。规则末尾通常有一条默认 drop用来实现“隔离语义”也就是没被显式 allow 的流量全部丢弃。这里最关键的性能问题是规则数量。比如你有一条 NetworkPolicy“允许来自 appweb 的 Pod 访问 appdb 的 3306 端口”。Felix 会把appweb这个 selector 展开成当前集群中所有满足条件的 Pod IP 列表再生成对应数量的 iptables 规则。如果 web 有 50 个副本就至少产生 50 条 allow 规则。当集群规模增长、策略数量增多时iptables 的线性匹配开销会非常明显因为内核是按顺序逐条匹配的。Calico 的另一个处理细节是连接状态。策略链里会放行ESTABLISHED,RELATED状态的包否则 TCP 的返回包会被自己的策略挡住所有连接都无法建立。这一点跟传统防火墙的“回程包放行”是同一个道理但很多人刚接触 K8s 策略时容易漏掉总以为是规则写错了。3.3 Calico 的命名端口和 Host EndpointCalico 在标准 NetworkPolicy 之上还扩展了不少功能其中比较实用的两个是命名端口和 Host Endpoint。命名端口很好理解Pod 里containerPort可以定义 name比如name: mysql那么在 NetworkPolicy 里可以直接写ports: - port: mysql由 Calico 动态解析成实际端口。这样业务端口调整时只要改 Pod 定义里的 name 对应的 port策略本身不用动。Host Endpoint 是 Calico 特有的概念你可以把节点上的物理网卡也纳入策略管控。比如限制某个节点只能被某些网段的 SSH 访问这在节点被攻破后横向移动的场景里很管用。标准 NetworkPolicy 管不到节点如果你想做“节点级防火墙”这是 Calico 的加分项。如果启用了 Calico 的 eBPF 数据面那么策略执行就不走 iptables 了而是由 BPF 程序直接在包路径上处理。这种模式还有 kube-proxy replacement、DSR 等额外能力。但我在生产里观察到大多数人选择 Calico 还是奔着 iptables 模式去的eBPF 模式的实际落地往往伴随着更严格的 Linux 内核版本要求以及和已有监控、排障工具的磨合成本。3.4 Calico 的优势和坑Calico 最大的优势是“传统思路的延续”熟悉 iptables 的人很容易理解它在做什么排障手段也丰富iptables -L、tcpdump、calicoctl都能用。而且它在纯 BGP 模式下没有隧道封装跨节点转发的原生性能非常好这对延迟敏感的服务很重要。但它也有几个容易踩的坑规则量达到几千条时iptables 匹配延迟会明显上升节点 CPU 也会因为规则安装产生尖峰。IPIP 封装下默认 MTU 是 1440VXLAN 是 1450如果对端物理网络 MTU 是 1500业务层一旦发大包就会分片或丢包。Felix 在做全量规则重算时可能短时间占用大量 CPU如果节点本来就繁忙会出现“策略更新时网络抖动”。BGP 模式需要底层网络允许节点之间的 BGP 连接很多公有云直接把 BGP 禁了导致你只能退回 IPIP/VXLAN 封装。4. Cilium用 eBPF 重写防火墙的执行路径4.1 eBPF 数据路径Cilium 和 Calico 最本质的差异就是它不走传统的宿主机 iptables FORWARD 链。Cilium 会为每个容器对应的 veth 网卡挂载 BPF 程序数据包从容器出来的那一刻就直接进入 eBPF 程序进行处理。eBPF 程序运行在内核态但又不像 iptables 那样按规则链线性匹配。Cilium 把策略数据放在 BPF map 里数据包到达后直接查 map 即可知道该放行还是丢弃。这种“哈希查找”的方式在规则规模变大时性能衰减远小于链式匹配这也是 Cilium 在大规模集群里经常被推荐的底层原因。同时Cilium 使用了自己的连接跟踪机制而不是完全依赖 Linux 内核的nf_conntrack。它会在 BPF map 里维护连接状态并支持在多个节点之间同步所以返回流量、NAT 转换等场景都能被准确处理。对于“防火墙”来说连接跟踪是必须的否则你很难区分“新连接”和“已建立连接”的返回包。4.2 Identity 机制如何大幅缩减规则数Cilium 实现 NetworkPolicy 时最核心的创新是 identity身份标识。每个 Pod 会基于它所属的 labels、namespace 等被分配一个 24 位整数 ID。数据包在进入节点时Cilium 就可以知道这个包的来源身份是什么。传统 iptables 方案中“允许 appweb 访问 appdb”需要把 web 的所有 Pod IP 展开为规则列表而 Cilium 中这条策略只需要表达“允许某个 identity 集合访问另一个 identity 集合”。跨节点转发时Cilium 会在隧道封装或报文中带上源 identity 信息目标节点据此快速决策。因此策略规则数量与 Pod IP 数量解耦就算业务 Pod 从 10 个扩容到 1000 个也不会让规则数量线性暴涨。这一点对大规模集群的 NetworkPolicy 运维非常关键。我在一个大概 300 个 Pod 的测试集群里对比过Calico 的 iptables 规则数量可能是上千条而 Cilium 的 BPF 策略逻辑却非常简洁。当然Cilium 也会把 identity 映射信息同步到每个节点但整体开销和可维护性都更好。4.3 L7 策略和可观测性Cilium 的 NetworkPolicy 能力不止于 L3/L4。标准 NetworkPolicy 只能基于 IP 和端口做允许但 Cilium 扩展支持了 L7 层规则包括 HTTP 方法、路径、gRPC method、Kafka topic、DNS 域名等。比如你可以写一条策略只允许GET /api/v1/health访问某个服务其他 API 全部拒绝。这在微服务场景里很有价值但要注意代价L7 策略通常需要把流量导到用户态的 Envoy 代理进程里做深度解析性能开销明显高于纯 L3/L4 策略。所以我一般建议能靠端口和 IP 解决的不要滥用 L7 规则只有真正需要按业务语义管控时才开启。可观测性方面Cilium 配套的 Hubble 组件可以实时看到每个数据包是被哪条策略允许的、被哪条策略丢弃的丢弃原因是什么。这对排障体验来说是质变因为你不再需要靠猜“是不是某个规则把流量拦了”而是直接能在监控界面里看到 “policy denied” 事件以及具体方向。4.4 Cilium 的限制和运维注意点Cilium 最大的门槛是内核版本要求。eBPF 能力高度依赖内核老旧内核可能连基本功能都用不了。生产环境我建议内核至少在 5.10 以上否则会遇到 BPF map 限制、BTF 缺失、部分特性不可用等问题。Cilium 的组件也比 Flannel、Calico 更复杂cilium-agent、cilium-operator、hubble-relay、可能的envoy升级时还要考虑 BPF 程序的重新加载和连接跟踪迁移。如果团队里没人熟悉 eBPF遇到“升级后策略异常”这类问题时会比较吃力。另一个点是 Cilium 默认会尝试替代 kube-proxy 的部分功能它能直接处理 Service 的 DNAT。如果你已经在集群里部署了 kube-proxy两者功能叠加时可能出现重复 NAT、连接纠缠等问题。安装 Cilium 前要明确要不要启用 kube-proxy replacement不要稀里糊涂把两个组件都留在数据路径上。5. 三者在实现 NetworkPolicy 时的核心差异对照5.1 关键能力对比对比维度FlannelCalicoCilium原生 NetworkPolicy 支持不支持需额外组件支持支持策略执行组件无需外加 Felx/kube-router 等Felixcilium-agent数据面VXLAN/host-gw 等BGP/IPIP/VXLANiptables 或 eBPFeBPF规则存储iptablesiptables/nftables 或 BPF mapBPF map策略匹配方式线性规则匹配线性规则匹配iptables哈希查找扩展策略能力依赖外部组件支持 GlobalNetworkPolicy、HostEndpoint支持 L7、DNS、ClusterMesh性能特征额外组件叠加无优化规则量大时线性衰减明显数据路径短高并发小包性能好运维复杂度组合模式偏复杂中规则链直观偏高依赖内核与组件多这个表里最容易让大家忽略的是“规则匹配方式”那一行。Flannel 配合的 iptables 方案、Calico 的默认 iptables 方案本质上都是线性匹配Cilium 的 BPF map 查找则从数据结构上改变了大规则集下的性能退化方式。5.2 策略翻译模型的不同标准 NetworkPolicy 里的 selector在三个方案里翻译方式完全不同Flannel 配合 iptables 组件时通常把 selector 展开为当前实际存在的 Pod IP 列表再塞进规则里。Calico 的 Felix 同样会把 selector 展开为 IP 集合只不过它把这些集合组织成 iptables 的 ipset 或规则列表从而减少部分规则数量。Cilium 把 selector 映射为 identity 整数集合策略表达天然和 IP 解耦。这带来的运维直觉差异是用 Calico 时你改一个 Deployment 副本数策略规则数量会变化用 Cilium 时副本扩缩不会让策略复杂度线性上涨只要 Pod 的 identity 不变。如果你有大量动态扩容场景Cilium 的优势会放大。5.3 网络层连通和策略层的耦合程度Flannel 的网络层和策略层是割裂的VXLAN 隧道只管通策略组件挂在隧道出口或宿主机转发路径上两层逻辑互不了解。因此你排障时必须先判断问题是“网络层不通”还是“策略层拦截”。Calico 把网络层和策略层放在同一个 agent 里策略规则在转发路径上和路由选择彼此配合。比如 BGP 模式下节点间是纯三层路由包到了目标节点才做策略检查IPIP/VXLAN 模式下则要先解封装再步入策略规则。这种耦合让 Calico 整体一致性好但也要注意底层封装类型和 MTU 会直接影响策略链上的包处理。Cilium 把网络层、服务转发、策略层全部收编到 BPF 数据路径中。这带来的好处是包只经过一次处理就能完成路由决策、DNAT 和策略判断而不是在 iptables 的多条链之间跳来跳去。这也是为什么有人测出 Cilium 在高并发短连接场景下延迟和 CPU 占用都更优的根本原因。5.4 我给出的选型建议不同场景下我的选择倾向是这样的如果你要的就只是一个“能跑 K8s、网络简单、出问题好解释”的方案并且没有强制使用 NetworkPolicyFlannel 完全够用。如果策略需求严格需要将 NetworkPolicy 做生产级落地绝大多数团队建议先用 Calico。它的资料最多、规则透明、iptables 工具链成熟出了问题很容易找到答案。如果集群规模大、业务对网络延迟和吞吐敏感或者需要 L7/DNS 级别的安全策略、需要统一可观测性那 Cilium 是更符合未来需求的选择。如果基础设施团队已经对 eBPF 有一定掌握并且业务有很强的微服务隔离诉求Cilium 值得投入。6. 实际集群里的排查要点与经验6.1 NetworkPolicy 不生效时的通用排查套路遇到“写了 NetworkPolicy 但流量还是通的”这种情况我一般按顺序检查先用kubectl get netpol -A确认策略存在再确认当前选中的 Pod 数量kubectl get pod -l appdb。接着确认你的 CNI 插件是否支持 NetworkPolicy比如 Flannel 默认就不支持。然后看节点上的规则是否生成Calico 就用iptables -t filter -L cali-FORWARD -n -vCilium 就用cilium policy get或者cilium policy trace。最容易犯的错误是命名空间不匹配。NetworkPolicy 是 namespace 级别的资源一个 namespace 里的策略管不到另一个 namespace 的 Pod。如果你把策略写在了productionnamespace但业务在stagingnamespace规则当然不生效。另外要注意NetworkPolicy 的ingress和egress是站在目标 Pod 视角看的。很多人把传统防火墙里“出站入站”的习惯带过来方向经常写反。我建议画一张图客户端 Pod 在左目标 Pod 在右请求从右向左进入目标 Pod那么目标 Pod 上要的就是ingress规则如果目标 Pod 主动访问外部服务那么写的才叫egress规则。6.2 Calico 排障时的重点Calico 集群里我最频繁遇到的三类问题是规则顺序、MTU、以及健康检查被误伤。规则顺序方面iptables 是按顺序匹配的如果某条规则在前、后面的 drop 规则在后即使你后来写了 allow 也可能不会命中。Calico 通常会把不同优先级的策略按order字段排序但如果你手工改过 iptables很容易破坏顺序导致奇怪的现象。健康检查被误伤是另一个高发问题。kubelet 的 liveness/readiness 探测源 IP 是节点 IP不是 Pod IP。如果你写了一条很严的ingress策略只允许来自特定 Pod CIDR 的流量访问业务端口kubelet 的探测包会被拒绝应用“活得好好的”但 K8s 认为它不健康不断重启。排查时看到这个现象要记得放行节点网段。MTU 问题则表现为小包通大包卡。比如下载大文件中断、视频流卡顿但ping正常。这种时候直接检查 Flannel 或 Calico 的隧道接口 MTU和底层物理网卡 MTU 做减法然后给 CNI 配置里设置合适的 MTU 值。6.3 Cilium 排障时的独有工具Cilium 排障最大的优势是有 Hubble 和cilium policy trace。我通常先跑cilium status确认 agent 健康再用cilium policy trace --src-k8s-pod ... --dst-k8s-pod ...模拟一条流量看它会被哪条规则放行或拒绝。如果线上流量已经发生通过 Hubble 可以查看到实时流和丢弃原因。遇到“没有方向、没有原因”的时候往往要查看 BPF map 是否同步可以用cilium bpf policy list检查某个 endpoint 的策略表。Cilium 里还有一点要提防策略依赖 identity 同步。当大量 Pod 同时创建时identity 分配和 BPF map 更新会有短暂延迟可能导致新 Pod 瞬间不能通信。这种情况在大量批量部署时出现过最终解法是控制并发 Pod 创建节奏并升级到新版本获取更完善的 identity 同步逻辑。6.4 升级和迁移中的教训从 Flannel 迁到 Calico或者从 Calico 迁到 Cilium最怕的是“新旧规则残留”。Calico 的规则带着cali-前缀如果 Cilium 安装后没有清理干净两个策略引擎可能同时在处理流量出现策略“时灵时不灵”的现象。我踩过几次坑之后总结出稳妥的迁移步骤先清点现有 NetworkPolicy拍照记录避免迁移后策略丢失。在新 CNI 部署完成后不要急着删除旧 CNI先观察一段时间确认新数据路径和策略都正常。再逐步删除旧 CNI 的 DaemonSet 和相关配置清理掉节点上的遗留网卡和 iptables 链。最后做一轮全量连通性测试包含跨节点、同节点、NodePort、DNS、健康检查等场景。如果你已经在生产环境用 Calico 很久切换 Cilium 前还要注意升级内核并且先在测试环境压测确认 eBPF 模式下的吞吐和延迟符合业务预期再动手。6.5 几个值得长期记住的实操细节最后说几个我觉得非常实用的细节NetworkPolicy 并不会管 Service 的 ClusterIP因为数据包经过 kube-proxy 的 DNAT 后目标是后端 Pod 的 IP。所以你在策略里写 ClusterIP 当 CIDR 是无效的正确做法是关注后端 Pod 的真实 IP 和端口。写端口时要分清是 Pod 的容器端口还是 Service 的端口。很多人写了 ServicePort但 Pod 实际监听在另一个端口策略放行和实际流量对不上最后所有请求都被默认 drop 掉了。不要一上来就全局 Deny All。先把 kube-system 等基础组件的网络放行做好再分业务逐步收窄。临时调试时用kubectl run -it --rm debug --imagenicolaka/netshoot起一个调试 Pod在目标命名空间里直接测试连通性比在节点上用curl猜路径高效得多。我个人实际使用的体会是选 CNI 不能只追新要看你的团队能不能驾驭它的排障工具。Calico 的 iptables 规则虽然“笨重”但透明Cilium 的性能虽然优秀但排障思路完全不同。如果能在小集群里先把 Cilium 的 Hubble 和 policy trace 用熟那自然可以大胆用它做生产底座如果没这个精力Calico 仍然是最稳妥的默认项。Flannel 则安安静静当它的“连通工具”就好NetworkPolicy 这种事别硬凑。