CNI #

CNI（Container Network Interface）是 Kubernetes 的容器网络接口标准，负责为 Pod 分配 IP 地址并实现 Pod 间通信。以下对比四种主流 CNI 插件：Cilium、Calico、Flannel、阿里云 Terway。

四种 CNI 总览对比 #

Flannel #

最简单、最轻量的 CNI 插件，适合入门和小型集群。

工作原理 #

Node A (10.244.1.0/24)          Node B (10.244.2.0/24)
┌──────────────┐                ┌──────────────┐
│ Pod-A  10.244.1.5             │ Pod-B  10.244.2.3
│      │        │               │      │        │
│ flannel.1 (VXLAN) │  ═ VXLAN 隧道 ═  │ flannel.1 (VXLAN) │
└──────────────┘                └──────────────┘

• 每个 Node 分配一个 /24 子网
• 跨 Node 通信通过 VXLAN 隧道封装（或 host-gw 直接路由）
• 不支持 NetworkPolicy，需搭配 Calico 策略组件使用

优点 #

• 部署极简，几乎零配置
• 资源占用低
• 成熟稳定，兼容性好

缺点 #

• 无 NetworkPolicy 支持
• 无高级可观测性
• VXLAN 模式有约 50 字节封装开销
• 大规模集群性能不理想

Calico #

企业级 CNI，基于 BGP 路由，支持丰富的网络策略。

工作原理 #

Node A (10.244.1.0/24)          Node B (10.244.2.0/24)
┌──────────────┐                ┌──────────────┐
│ Pod-A  10.244.1.5             │ Pod-B  10.244.2.3
│      │        │               │      │        │
│  veth pair   │  ══ BGP 路由交换 ══  │  veth pair   │
└──────────────┘                └──────────────┘
        │                               │
   物理网络直接路由（无封装）

• 跨 Node 通信通过 BGP 路由直接转发，无需封装
• 也可使用 VXLAN 或 IPIP 模式（适用公有云不支持 BGP 的场景）
• 支持基于 iptables 或 eBPF 的数据平面
• 完整支持 Kubernetes NetworkPolicy（L3/L4）

优点 #

• BGP 模式无封装开销，性能优秀
• NetworkPolicy 功能完善
• 支持大规模集群（BGP Route Reflector 扩展）
• 可与 Flannel 组合使用（Canal 方案）

缺点 #

• BGP 模式需要底层网络支持（公有云通常用 VXLAN 模式）
• iptables 模式在大规模 Service 时规则链较长
• eBPF 模式功能不如 Cilium 全面

Cilium #

基于 eBPF 的新一代 CNI，无需 kube-proxy，支持 L7 网络策略和全链路可观测。

工作原理 #

                 eBPF 程序（内核态）
    ┌───────────────────────────────────────┐
    │  TC / XDP Hook                        │
    │  ├── Pod 间路由（替代 iptables）       │
    │  ├── Service 负载均衡（替代 kube-proxy）│
    │  ├── NetworkPolicy L3-L7 执行         │
    │  └── 可观测性指标采集                  │
    └───────────────────────────────────────┘
                 │  无需上下文切换
    ┌────────────┴───────────────────────────┐
    │  Pod-A          Pod-B          Pod-C    │
    └─────────────────────────────────────────┘

• 数据平面完全基于 eBPF，在内核态处理数据包
• 替代 kube-proxy：Service 负载均衡直接在 eBPF 中实现
• 支持 L7 NetworkPolicy：可按 HTTP 路径、方法、gRPC 方法等精细控制
• Hubble 提供全链路流量可视化（L3-L7）
• 支持 Cilium Service Mesh（无 Sidecar 架构）

优点 #

• 性能最优：eBPF 绕过 iptables，无规则链遍历开销
• 可观测性最强：Hubble 提供实时流量地图和审计日志
• L7 策略支持（HTTP、gRPC、Kafka 等）
• 无 Sidecar Service Mesh 架构，资源开销低
• 社区活跃，CNCF 毕业项目

缺点 #

• 需要较新内核版本（建议 5.4+，部分功能需 5.10+）
• 配置项复杂，学习曲线较陡
• eBPF 与某些内核模块可能冲突（如 kube-proxy 同时运行需禁用）

阿里云 Terway #

阿里云 ACK 自研 CNI，基于弹性网卡（ENI）直通 VPC，Pod IP 即 VPC IP。

工作原理 #

阿里云 VPC 网络平面
┌───────────────────────────────────────────────────┐
│  ECS Node A                          ECS Node B     │
│  ┌─────────────────┐                ┌─────────────────┐
│  │ ENI-1 (主网卡)   │                │ ENI-1 (主网卡)   │
│  │ ENI-2 (附加网卡) │                │ ENI-2 (附加网卡) │
│  │  ├── Pod-A (ENI IP)              │  ├── Pod-C (ENI IP)
│  │  └── Pod-B (ENI IP)              │  └── Pod-D (ENI IP)
│  └─────────────────┘                └─────────────────┘
│         │                                   │
│         └──── VPC 直接路由（无封装）──────────┘
└───────────────────────────────────────────────────┘

• Pod IP 直接从 VPC 子网分配，与 ECS、RDS 等云资源在同一网络平面
• 跨 Node 通信通过 VPC 弹性网卡直接转发，无 VXLAN / IPIP 封装
• 支持 eBPF 加速协议栈，降低延迟
• 支持 NetworkPolicy 和阿里云安全组双重网络策略

网络模式 #

优点 #

• 无封装开销：Pod IP 即 VPC IP，跨 Node 通信等同于 ECS 间通信
• 高性能：ENI 直通 + eBPF 加速，延迟低、吞吐高
• 云原生集成：与 SLB / NLB / 安全组 / VPC 路由无缝对接
• Pod 与 VPC 内 RDS / Redis 等资源可直接互通，无需 NAT
• ACK 托管版自动安装和维护

缺点 #

• 仅限阿里云，无法在自建 IDC 或其他云平台使用
• 受 ENI 数量配额限制（共享 ENI 模式可缓解）
• 可观测性不如 Cilium Hubble 丰富
• Trunking 功能仅在 ACK 托管版可用

选型建议 #

性能排序（跨 Node Pod 间通信） #

Terway（ENI 直通）≈ Cilium（eBPF）> Calico（BGP 直路由）> Calico（VXLAN）≈ Flannel（VXLAN）

功能丰富度排序 #

Cilium > Calico > Terway > Flannel

Reference #

CNI, CNI-Github

sig-network

Flannel

Calico, Calico Docs

Cilium, Cilium-Github, Hubble

Terway-Github, Terway 文档

Cilium 与 Calico 对比

Kubernetes CNI 对比