1. 课程导入

云原生技术体系在过去十年间经历了从“容器化改造”到“全面云原生”的演进,Kubernetes 已成为分布式应用编排的事实标准。然而,当我们将成百上千个 Pod 调度到集群中时,一个根本性问题随之浮现:这些动态创建、销毁、迁移的 Pod 如何获得稳定、安全、高性能的网络通信能力?这正是云原生网络(Container Network)要解决的核心命题。本章作为整个课程的开篇,将首先梳理云原生网络的演进背景,明确 CNI(Container Network Interface)标准的设计动机与核心作用,随后对当前生产环境中应用最广泛的两大 CNI 实现——Calico 与 Cilium(基于 eBPF)进行多维度对比,最后给出本课程的学习路径与实战环境准备方案,帮助读者建立全局认知框架。

云原生网络 CNI 全景图:从 Pod 通信到策略管控 Kubernetes 集群(Pod 动态调度、服务发现、生命周期管理) Pod IP 不固定 · 多租户隔离 · 跨节点通信 · 服务暴露与负载均衡 CNI 标准(Container Network Interface) ADD / DEL / CHECK 命令 · 插件链式调用 · 网络配置 JSON 规范 Flannel / 简单 Overlay VXLAN · 易用 · 功能单一 适合小型集群 Calico BGP + IPIP/VXLAN · 网络策略 大规模生产首选 Cilium (eBPF) eBPF 数据面 · 可观测性 云原生网络演进方向 核心能力:Pod IP 分配 · 路由转发 · 网络策略 · 服务负载均衡 · 可观测性 性能 · 安全 · 可扩展性 · 运维复杂度 —— 四维权衡

上图展示了云原生网络 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 规范定义了三个基本操作:

  1. ADD:将容器添加到网络。插件负责创建 veth 对、分配 IP 地址、配置路由。
  2. DEL:将容器从网络移除。插件负责清理 veth、释放 IP、删除路由。
  3. 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,及时了解最新变化。