K8s网络：CNI、Calico与Cilium

可视化演示

展示CNI插件工作流程、Calico(BGP/iptables)与Cilium(eBPF)数据面对比及大规模集群性能差异。

网络基础模型

市政规划局（Kubernetes）在发门牌号之前，先定了一套全市统一的地名规则：每个片区（Node）领取一段连续的门牌号，比如10.244.1.x到10.244.3.x；每户住户（Pod）入住时，从所在片区段里领走一个唯一号码（IP）。规则写明：任意两户之间，不管是隔壁邻居（同节点）还是城市两端（跨节点），都必须能直通互通，不许经过话务员人工转接。这条规则，就是K8s的“扁平网络模型”。

扁平网络模型是K8s对Pod网络的核心承诺：每个Pod的IP全局唯一；任意两个Pod可以直接通信，不经过NAT。这个承诺本身不含实现细节——K8s把“如何兑现”交给了CNI插件。就像市政只规定“能直通”，但光纤怎么铺、交换机怎么配，由通信公司（插件）负责。

在实现层面，每个节点都有一块PodCIDR网段预留给Pod。kube-controller-manager负责给节点分配网段，Pod的IP由容器运行时从该网段中分配。同节点Pod通过veth网卡对和cni0网桥直接互通；跨节点则依赖CNI插件提供的路由或隧道。此外，Service是K8s额外提供的一个“前台总机”：它给一组Pod一个稳定的虚拟IP（ClusterIP），接收外部访问并转发给背后的Pod，解决了Pod IP会随重建而变化的问题。理解Pod网络和Service网络的分工，是排障的第一步——前者归CNI管，后者归kube-proxy管。

门牌号规则定完，住户们安顿下来。但真正的挑战在“送信”环节——谁来送、走什么路线？这就轮到快递协会（CNI）登场了。

CNI插件机制

市政意识到：不能允许各家快递公司各行其是，否则住户得记住N套寄件流程。于是“快递协会”（CNI）出场，制定了一份统一面单规范：不管哪家公司接单，信封尺寸、面单字段、收寄流程必须一致。这样住户（Pod）只要按标准填单，就能享受任意一家快递（网络插件）的服务。

CNI（Container Network Interface，容器网络接口）是Kubernetes、容器运行时（containerd/CRI-O）与网络插件之间的标准协议。它定义了两个核心操作：ADD（把新Pod接入网络）和DEL（把Pod移出网络）。任何网络插件——Flannel、Calico、Cilium、Weave——只要实现了这两个操作，就能无缝接入K8s。

当用户创建Pod，kubelet通过CRI（容器运行时接口）请求containerd启动容器。containerd发现Pod需要网络，就调用预先配置的CNI插件。插件收到的参数包括容器ID、网络命名空间路径、网卡名等。它负责：创建veth网卡对、把一端塞进容器网络命名空间、分配IP、写路由表、把另一端挂到网桥上。整个过程在容器启动的毫秒级窗口内完成。CNI配置通常存放在/etc/cni/net.d/目录，插件二进制在/opt/cni/bin/。

有了统一面单和标准流程，快递公司可以随时换新：今天用Calico，明天换Cilium，住户无感知。标准带来的自由，正是CNI最大的价值。接下来看两套主流投递系统的内部运作。

Calico数据面

Calico是传统邮政系统的集大成者。每个邮局（节点）定期用BGP广播向全城宣布：“我这栋楼能送到哪些门牌号。”所有邮局收到广播后，各自拼出一张全局投递地图——不需要中央调度员告诉它每封信该走哪条路，地图上写得明明白白。

BGP（Border Gateway Protocol，边界网关协议）是互联网实际使用的“跨网络路由广播语言”。Calico把每个K8s节点当成一个BGP路由器，节点之间直接建立BGP会话（Peer），互相通告Pod网段路由，从而构造出完整的路由表。数据包到达后查表转发即可。

跨节点通信时，Calico面临一个现实问题：目标Pod的IP不一定在物理网络里可路由。解决办法是“封装”：IPIP模式给原始IP包套一个外层IP头（20字节），目标地址是目的节点IP，像把信装进一个普通信封；VXLAN模式则套上UDP+VXLAN头（50字节），像加了防震气泡的信封，适合底层网络不支持IPIP的三层网络。无论哪种模式，封装都会压缩有效负载：物理MTU 1500下，IPIP的有效MTU是1480，VXLAN是1450。Calico还支持eBPF数据面，但标志性路线是BGP路由。

邮政系统的优势是简单、直接，每条路线都由邮局间“人传人”的广播达成。但节点多了，邮局之间要维持的消息会话（全互联）会飞速膨胀——100个节点就有4950条BGP会话。地图越来越大、越来越贵，这正是Calico在超大规模下要面对的问题。

Cilium数据面

Cilium像新一代智能物业，给每栋楼装上“管家机器人”。这个机器人（eBPF）不住在邮局，而是住在楼宇的“神经系统”（Linux内核）里，每封信只要在收件口一刷，机器人立刻识别出收件人，从楼内直达通道直接送到对方家门口——完全不需要经过邮局分拣中心。

eBPF（extended Berkeley Packet Filter）是Linux内核的一项革命性能力：允许用户在内核中安全运行由内核验证的程序。Cilium把数据包处理逻辑编译成BPF字节码，挂载到网卡收包点，让数据包在进入传统协议栈之前就被识别、决策和转发。

Cilium最典型的能力是SocketLB：当进程发起connect()时，eBPF程序在socket层直接完成ClusterIP到目标Pod IP的负载均衡与转发，完全绕过iptables和conntrack。数据面使用eBPF map（哈希表）做查表，复杂度O(1)，不随规则或服务数量线性增长。此外，Cilium基于eBPF提供透明的带宽管理、DNS可见性和Hubble可观测性。数据包的路径从“进协议栈逐层解析+遍历iptables链”缩短为“网卡收包→eBPF查表→目标网卡”，时延显著降低。

智能管家用“直达通道+秒级识别”换来了极致的投递效率，但也对楼宇“神经系统”的版本有要求——需要内核支持较新的eBPF特性。并不是所有城市（集群）都买得起这台机器人，这为后面的选型埋下伏笔。

网络策略对比

光有投递还不够，城市安全部门要求：某些住户之间的通信必须受控。Calico和Cilium各自拿出了不同的“门禁系统”——一个用纸质花名册逐行核对，另一个用智能闸机刷脸秒过。

K8s NetworkPolicy定义了一组“谁可以访问谁”的规则，CNI插件负责执行。Calico的策略引擎在节点和Pod的veth上安装iptables规则，每条规则描述来源/目的选择器、协议和端口，数据包逐条匹配；Cilium则把每个Pod分配一个32位安全身份ID（Endpoint Identity），策略被编译进BPF map，数据包携带身份ID，一次map查询即得结论。

Calico的网络策略支持K8s原生NetworkPolicy，还提供了更精细的GlobalNetworkPolicy（集群级）和GlobalNetworkSet。iptables匹配顺序是线性的：R条规则最坏情况匹配R次。Cilium的策略不仅覆盖L3/L4，还能解析HTTP/gRPC等L7协议做细粒度控制；BPF map哈希查找不随规则数增长——当然，map容量有上限，超限也会丢包。生产环境中，两种策略引擎都要注意规则数量与误拦截排查：被拒绝的包在Calico里查DROP规则，在Cilium里查policy verdict监控。

门禁系统的选择同样取决于城市规模：小社区一个保安拿花名册就够，超大城市必须上智能闸机。策略性能的差异，直接影响最终选型。

性能与选型

城市最终要在两套投递系统中做决定，是延续便宜可靠的邮政，还是采购成本更高的智能管家？答案永远取决于城市规模、信件流量、预算和物业团队水平。

K8s网络选型没有绝对优劣，只有是否匹配。核心考量维度有四个：数据面性能（PPS、延迟）、功能特性（策略、加密、可观测性）、运维复杂度（部署、排障、团队技能）和生态适配（是否与物理网络集成、是否支持云平台）。

Calico的优势：BGP纯路由模式是与传统数据中心网络（如TOR交换机）集成的天然选择，适合千节点以上、基础设施团队熟悉网络协议的场景；IPIP/VXLAN封装在非直连网络也能跑。Cilium的优势：eBPF带来高PPS、低延迟，对高并发微服务（如网关、实时推荐）增益明显；Hubble提供内核级可观测性；透明加密（WireGuard）开箱即用。双方也在互相融合：Calico推出了eBPF数据面，Cilium也能用BGP做路由广播（BGPControlPlane）。据社区数据，在大量策略规则和高PPS场景，Cilium吞吐量可达iptables方案的数倍；在纯BGP转发场景，两者差距缩小。

没有哪套系统是放之四海皆准的银弹：邮政在城市间穿梭尚可，但面对海量即时信件的CBD也得引入智能管家。选型的关键是把自身集群的规模、流量模式、团队能力放到这张打分表上。

部署与排障

再好的物业也要巡检和应急维修。网络系统上线后，日常监控和故障响应才是住户安心指数的保障：总闸跳了要能快速定位是线路问题还是电表问题。

部署阶段，Calico通常用calicoctl或Operator在Kubernetes上安装；Cilium用cilium-cli或Helm一键部署。排障阶段，Calico提供calicoctl node status检查BGP peer状态、calicoctl get wep查看工作负载端点；Cilium提供cilium status、cilium connectivity test一键自检。

四类高频故障：一是MTU不一致，节点间路径最大帧小于容器MTU导致大包黑洞，排查用ping -M do探测；二是BGP peer断连，导致跨节点路由丢失，检查node-to-node mesh或RR配置；三是CNI配置错误，二进制/配置目录版本不匹配，Pod一直Pending或ContainerCreating；四是网络策略误拦截，表现为“部分服务突然不通”，用cilium policy trace或看calico felix日志。监控方面：Prometheus抓取Calico的felix指标、Cilium的agent指标，Hubble可观测Pod级流量，配合Alertmanager配置告警，比如BGP会话down、Packet drop率突增。

物业的底气来自两方面：楼宇本身过硬（MTTF），维修队响应迅速（MTTR）。把监控告警配置好、把排障工具练熟，无论Calico还是Cilium，都能让城市网络平稳运行。

AI 应用场景

Python 演示

"""模拟K8s网络数据面: 对比Calico与Cilium的转发路径开销""" import randomfrom dataclasses import dataclass, fieldfrom typing import Dict, List, Tuple  @dataclassclass Pod:    ip: str    node_id: str    name: str  @dataclassclass Node:    node_id: str    pod_cidr: str    pods: List[Pod] = field(default_factory=list)  def build_cluster(nodes: int = 5, pods_per_node: int = 10) -> Dict[str, Node]:    """构建模拟K8s集群: 每个节点分配一个/24的PodCIDR"""    cluster = {}    for i in range(nodes):        cidr = f"10.244.{i}.0/24"        node = Node(node_id=f"node-{i}", pod_cidr=cidr)        for j in range(pods_per_node):            pod_ip = f"10.244.{i}.{j + 2}"            node.pods.append(Pod(ip=pod_ip, node_id=node.node_id, name=f"pod-{i}-{j}"))        cluster[node.node_id] = node    return cluster  def calico_forward(src: Pod, dst: Pod, use_ipip: bool) -> Tuple[int, int]:    """Calico数据面: BGP路由查表 + 可选IPIP封装"""    hops = 1                      # 查BGP路由表命中    encap_bytes = 0    if src.node_id != dst.node_id:        hops += 1                 # 下一跳转发到目标节点        if use_ipip:            encap_bytes = 20      # 新增外层IP头    return hops, encap_bytes  def cilium_forward(src: Pod, dst: Pod) -> int:    """Cilium数据面: eBPF map哈希查找, O(1)直通转发"""    return 1  def simulate(trials: int = 1000, use_ipip: bool = True) -> None:    """运行模拟并输出对比结果"""    cluster = build_cluster()    all_pods = [p for n in cluster.values() for p in n.pods]    total_calico_hops = total_cilium_hops = total_encap = 0    for _ in range(trials):        src, dst = random.sample(all_pods, 2)        calico_hops, encap = calico_forward(src, dst, use_ipip)        total_calico_hops += calico_hops        total_encap += encap        total_cilium_hops += cilium_forward(src, dst)    avg_calico = total_calico_hops / trials    avg_cilium = total_cilium_hops / trials    print(f"样本数: {trials} 对随机Pod")    print(f"Calico 平均转发跳数: {avg_calico:.2f}, IPIP封装总字节: {total_encap}")    print(f"Cilium 平均转发跳数: {avg_cilium:.2f}")    print(f"Cilium 路径比 Calico 平均少 {avg_calico - avg_cilium:.2f} 跳")  if __name__ == "__main__":    simulate()

1. cidr = f"10.244.{i}.0/24"为每个节点分配一个/24网段，对应K8s中kube-controller-manager的PodCIDR分配
2. def calico_forward(src: Pod, dst: Pod, use_ipip: bool)模拟Calico数据面：跨节点先查BGP路由，再经下一跳转发
3. hops = 1BGP路由表一次命中，像邮局地图一查即得
4. encap_bytes = 20跨节点时IPIP封装多出20字节外层IP头
5. def cilium_forward(src: Pod, dst: Pod) -> int模拟Cilium的eBPF直通，恒为一跳
6. src, dst = random.sample(all_pods, 2)从集群中随机抽取一对Pod模拟通信
7. print(f"Cilium 路径比 Calico 平均少 {avg_calico - avg_cilium:.2f} 跳")输出路径差异，直观体现两种数据面的效率差距

常见误区

面试题