1. 课程导入
云原生技术体系在过去十年间经历了从“容器化改造”到“全面云原生”的演进,Kubernetes 已成为分布式应用编排的事实标准。然而,当我们将成百上千个 Pod 调度到集群中时,一个根本性问题随之浮现:这些动态创建、销毁、迁移的 Pod 如何获得稳定、安全、高性能的网络通信能力?这正是云原生网络(Container Network)要解决的核心命题。本章作为整个课程的开篇,将首先梳理云原生网络的演进背景,明确 CNI(Container Network Interface)标准的设计动机与核心作用,随后对当前生产环境中应用最广泛的两大 CNI 实现——Calico 与 Cilium(基于 eBPF)进行多维度对比,最后给出本课程的学习路径与实战环境准备方案,帮助读者建立全局认知框架。
上图展示了云原生网络 CNI 的整体架构关系。Kubernetes 作为编排层,通过 CNI 标准接口将网络配置下发给不同的插件实现。Flannel 提供最基础的 Overlay 网络,Calico 在路由与策略方面表现突出,而 Cilium 则通过 eBPF 技术将数据面性能与可观测性提升到了新的高度。理解这三者之间的差异与适用场景,是选择集群网络方案的基础。
1.1 云原生网络背景:从传统虚拟化到容器网络的范式转移
传统虚拟化环境中,每台虚拟机拥有独立的虚拟网卡和固定的 IP 地址,网络拓扑相对稳定,运维人员可以基于物理交换机、虚拟交换机(vSwitch)和防火墙规则进行精细管控。但容器化部署彻底改变了这一格局:Pod 的生命周期极短,扩容缩容频繁,IP 地址无法预先规划,服务间的访问关系动态变化。这种“无常”的网络环境,迫使我们必须重新设计网络模型。
Kubernetes 的网络模型提出了四个基本要求:
- Pod 间互通:任意两个 Pod 可以直接通过 IP 地址通信,无需 NAT 转换。
- 节点与 Pod 互通:集群内所有节点(Node)可以访问任意 Pod。
- Pod 与 Service 互通:Pod 可以通过 Service 的 ClusterIP 访问后端服务,实现负载均衡。
- 外部访问:外部流量可以通过 NodePort、LoadBalancer 或 Ingress 进入集群。
这些要求看似简单,但在大规模集群中实现却充满挑战。例如,当集群规模超过 500 节点时,传统的 VXLAN 封装会带来显著的 CPU 开销;当安全策略需要精细化到应用层时,基于 IP 的防火墙规则难以满足需求。正是这些痛点,推动了 Calico 的 BGP 路由方案和 Cilium 的 eBPF 内核编程方案的诞生。
核心认知:云原生网络不是简单的“容器分配 IP”,而是围绕 Pod 生命周期、服务发现、安全策略、流量治理的一整套基础设施。CNI 插件决定了集群网络的性能上限、安全能力和运维复杂度。
1.2 CNI 标准与作用:插件化设计的基石
CNI(Container Network Interface)最初由 CoreOS 发起,现已成为 CNCF 旗下的标准项目。它定义了一套简单的接口规范,让容器运行时(如 containerd、CRI-O)能够调用网络插件为容器配置网络。CNI 的核心设计理念是“小而美”——它只关注网络连通性,不关心 IPAM(IP 地址管理)的具体实现,也不涉及网络策略的强制执行。
CNI 规范定义了三个基本操作:
- ADD:将容器添加到网络。插件负责创建 veth 对、分配 IP 地址、配置路由。
- DEL:将容器从网络移除。插件负责清理 veth、释放 IP、删除路由。
- CHECK:检查容器网络配置是否正确(可选操作,用于容器运行时恢复场景)。
CNI 插件通过 JSON 格式的配置文件进行参数传递,支持插件链(Plugin Chain)——多个插件可以串联执行,例如先执行 portmap 插件进行端口映射,再执行 bridge 插件创建网桥。这种模块化设计使得网络功能可以灵活组合,也降低了插件开发的复杂度。
| CNI 操作 | 触发时机 | 典型动作 | 失败处理 |
|---|---|---|---|
| ADD | Pod 创建时 | 创建 veth、分配 IP、配置路由 | 返回错误,Pod 创建失败 |
| DEL | Pod 删除时 | 清理 veth、释放 IP、删除路由 | 记录日志,不阻塞 Pod 删除 |
| CHECK | Kubelet 定期检查 | 验证网络配置一致性 | 返回错误,触发 Pod 重建 |
在实际生产环境中,CNI 插件还需要处理一些边界情况:例如节点重启后,veth 设备可能残留;IP 地址池耗尽时,需要优雅地拒绝新 Pod 的创建;网络策略更新时,需要保证已有连接不受影响。这些细节往往决定了插件在生产环境中的稳定性。
经验之谈:选择 CNI 插件时,不要只看功能列表,更要关注其 IPAM 模块的健壮性。很多网络故障的根因是 IP 地址冲突或泄漏,而非数据面转发问题。
1.3 Calico 与 Cilium 对比:架构、性能与生态
Calico 和 Cilium 是当前生产环境中最主流的两种 CNI 实现,它们的设计哲学截然不同。Calico 基于传统的 Linux 内核网络栈,利用 BGP 协议在节点间分发路由,数据面采用 iptables 或 eBPF(可选);Cilium 则完全基于 eBPF,将数据面逻辑下沉到内核虚拟机中执行,绕过了 iptables 的线性遍历开销。
从架构层面看,Calico 的核心组件包括 Felix(负责编程 iptables 和路由)、BIRD(BGP 客户端)、confd(配置管理)。Cilium 的核心组件包括 Cilium Agent(管理 eBPF 程序)、Cilium Operator(处理集群级任务)、Envoy(用于 L7 策略)。两者都支持 Overlay 和 Underlay 网络模式,但 Calico 更擅长纯 Underlay 的 BGP 模式,而 Cilium 在 Overlay 模式下也能保持较高性能。
| 对比维度 | Calico | Cilium (eBPF) |
|---|---|---|
| 数据面技术 | iptables / eBPF(可选) | eBPF(原生) |
| 路由模式 | BGP(Underlay)、IPIP/VXLAN(Overlay) | VXLAN、Geneve、原生路由 |
| 网络策略 | 基于 iptables,支持 L3/L4 | 基于 eBPF,支持 L3/L4/L7(HTTP/gRPC) |
| 可观测性 | 基础指标(通过 Prometheus) | 高级可观测性(Hubble,支持 L7 流量可视化) |
| 性能表现 | iptables 模式有规则遍历开销 | eBPF 哈希查找,性能损耗极低 |
| 内核要求 | Linux 4.9+(eBPF 模式需 5.7+) | Linux 5.10+(推荐) |
| 运维复杂度 | 中等,依赖 BGP 配置 | 较高,需理解 eBPF 概念 |
| 生态集成 | 与云厂商 BGP 设备集成良好 | 与 Service Mesh、可观测性工具集成紧密 |
从性能角度看,Cilium 在 Pod 间通信延迟和吞吐量上通常优于 Calico 的 iptables 模式。例如,在 100Gbps 网卡环境下,Cilium 可以接近线速转发,而 iptables 模式会因规则匹配产生明显损耗。但 Calico 的 eBPF 模式(Dataplane 设置为 eBPF)也能达到接近 Cilium 的性能,只是功能丰富度稍逊。
从安全策略角度看,Cilium 的 L7 策略可以直接解析 HTTP 方法、路径、Header 等信息,实现应用层访问控制;Calico 则需要借助 Envoy 或 Kubernetes Ingress 才能实现类似功能。对于金融、电商等对安全合规要求较高的场景,Cilium 的 L7 能力具有明显优势。
选型警示:不要盲目追求新技术。如果团队对 eBPF 不熟悉,且集群规模在 200 节点以内,Calico 的 iptables 模式完全够用。Cilium 的调试门槛较高,遇到问题时需要深入理解内核 eBPF 程序的行为。
1.4 课程学习路径与实战环境准备
本课程共 30 章,按照“基础→进阶→实战→调优”的路径设计。前 5 章聚焦 CNI 基础与 Calico 核心原理;第 6-10 章深入 Calico 的 BGP、网络策略、IPAM 与故障排查;第 11-15 章转向 Cilium,讲解 eBPF 基础、数据面架构、Hubble 可观测性;第 16-20 章覆盖 Cilium 的 L7 策略、Service Mesh 集成、性能调优;第 21-25 章是混合场景实战,包括多集群网络、云上部署、安全加固;最后 5 章是综合案例与性能基准测试。
为了顺利完成课程中的实验,建议准备以下环境:
- 硬件要求:一台 16GB 内存以上的 Linux 服务器(或虚拟机),4 核 CPU 以上,磁盘 100GB 以上。如果使用云服务器,建议选择 4C8G 规格。
- 操作系统:Ubuntu 22.04 LTS 或 CentOS 9 Stream,内核版本 5.15 以上(推荐 6.1 LTS)。
- Kubernetes 集群:使用 kubeadm 部署 1 个 Master + 2 个 Worker 节点,版本 1.28+。
- 容器运行时:containerd 1.7+,配置 SystemdCgroup 驱动。
- 网络工具:安装 tcpdump、iproute2、bpftool、cilium-cli、calicoctl。
建议使用虚拟机快照功能,在安装不同 CNI 插件前创建快照,方便回滚。对于 Cilium 实验,需要确保内核支持 eBPF 的 BTF 特性,可以通过 ls /sys/kernel/btf/vmlinux 检查。
# 检查内核版本与 BTF 支持
uname -r
ls /sys/kernel/btf/vmlinux
# 安装基础工具
apt-get update && apt-get install -y tcpdump iproute2 bpftool
# 下载 Cilium CLI
curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
tar xzvf cilium-linux-amd64.tar.gz
sudo mv cilium /usr/local/bin/
# 下载 calicoctl
curl -L https://github.com/projectcalico/calico/releases/latest/download/calicoctl-linux-amd64 -o calicoctl
chmod +x calicoctl && sudo mv calicoctl /usr/local/bin/
在课程中,我们将反复使用这些工具进行网络抓包、eBPF 程序加载、策略验证等操作。建议读者在每章学习前,先启动一个干净的 Kubernetes 集群,并按照章节要求安装对应的 CNI 插件。
学习建议:不要只跟着命令敲,要理解每个操作背后的原理。例如,当使用 calicoctl get ippool 查看 IP 池时,要思考 IP 地址是如何被分配的;当使用 cilium monitor 观察流量时,要理解 eBPF 程序是如何捕获数据包的。
最后,需要强调的是,云原生网络是一个快速演进的领域。Calico 和 Cilium 都在持续迭代,新特性不断加入。本课程的内容基于 2025 年初的稳定版本(Calico v3.28、Cilium 1.16),但核心原理和设计思想具有长期参考价值。读者在学习过程中,应关注官方文档和 Release Notes,及时了解最新变化。