2、Calico 网络基础：Felix、BIRD、confd 组件架构与数据平面转发原理
Calico 作为 Kubernetes 生态中最流行的纯三层网络方案之一，其核心优势在于将网络策略与数据转发解耦，利用标准 Linux 路由和 iptables/netfilter 实现高性能转发。理解 Felix、BIRD、confd 三大控制面组件以及数据平面的转发路径，是后续进行参数调优和镜像拉取加速的前提。
2.1 三大控制面组件架构总览
Calico 的控制面由三个核心守护进程组成，它们各自承担不同的职责，并通过 etcd 或 Kubernetes API 进行状态同步。下表总结了各组件的功能定位与关键特性：
| 组件 | 运行位置 | 核心职责 | 数据来源 | 关键输出 |
|---|---|---|---|---|
| Felix | 每个节点（DaemonSet） | 管理主机路由、iptables 规则、策略执行 | etcd / K8s API | 路由条目、安全策略规则 |
| BIRD | 每个节点（可选 DaemonSet） | BGP 路由协议守护进程，负责跨节点路由分发 | Felix 写入的路由表 | BGP 路由更新 |
| confd | 每个节点（通常与 BIRD 同容器） | 监听 etcd 变化，动态生成 BIRD 配置文件 | etcd | BIRD 配置文件 |
架构要点：Felix 是“执行者”，直接操作节点网络栈；BIRD 是“传播者”，负责将 Felix 写入的路由通告给其他节点；confd 是“配置桥梁”，确保 BIRD 的配置始终与集群状态一致。在非 BGP 模式（如 VXLAN 或 IPIP）下，BIRD 和 confd 可以被替换或禁用。
2.2 Felix：节点网络策略引擎
Felix 是 Calico 在每台节点上的代理，它直接与 Linux 内核交互。Felix 的主要工作循环包括：
- 端点发现：通过监听 Kubernetes API 或 etcd，获取本节点上所有 Pod 的 IP 地址、MAC 地址以及关联的网络策略。
- 路由编程：为每个本地 Pod 写入主机路由（例如
10.244.1.3/32 dev caliXXXX scope link），确保 Pod 流量可以正确进入 veth 对。 - 策略编程：将 Kubernetes NetworkPolicy 翻译为 iptables 规则链（
cali-policy、cali-failsafe等），实现入站和出站流量过滤。 - 健康检查与清理：定期清理过期规则，确保节点网络状态与集群期望一致。
性能关键点：Felix 的 iptables 规则数量直接影响数据平面延迟。当集群中存在大量 NetworkPolicy 时，Felix 需要频繁更新规则链，这可能导致 CPU 开销上升。后续章节的调优将重点围绕
IptablesBackend（nftables 模式）和 ChainInsertMode 参数展开。
2.3 BIRD 与 confd：BGP 路由分发链路
在 Calico 的 BGP 模式下，BIRD 负责将 Felix 写入的本地路由通过 BGP 协议通告给其他节点或网络设备。confd 则作为配置生成器，确保 BIRD 的配置始终反映集群拓扑变化。
下图展示了 BIRD 与 confd 的协作流程：
注意：在非 BGP 模式下（例如使用
ipip 或 vxlan 封装），BIRD 和 confd 不会被启用。此时跨节点路由由 Felix 通过 IPIP/VXLAN 隧道直接处理，不再依赖 BGP 协议。选择哪种模式直接影响网络吞吐量和延迟，也是后续调优的核心决策点。
2.4 数据平面转发原理
Calico 的数据平面转发遵循“纯三层”设计理念，不依赖 Overlay 封装（默认模式）。当 Pod A（节点1）向 Pod B（节点2）发送数据包时，转发路径如下：
- Pod 出站：数据包通过 veth 对进入宿主机网络栈，目标 IP 为 Pod B 的 IP。
- 路由查找：宿主机内核根据路由表查找目标 IP。Felix 已为每个远程 Pod 写入主机路由（例如
10.244.2.3/32 via 192.168.1.2 dev eth0）。 - 下一跳转发：数据包被路由到下一跳节点（节点2的物理 IP），通过节点间二层网络直接发送。
- 目标节点处理：节点2 收到数据包后，再次进行路由查找，命中本地 Pod 路由，将数据包通过 veth 对送入 Pod B。
- 策略过滤：在入站和出站路径上，Felix 插入的 iptables 规则链对数据包进行过滤，匹配 NetworkPolicy。
下图展示了完整的跨节点数据包转发路径：
2.5 数据平面性能关键因素
从上述转发路径可以看出，Calico 的数据平面性能受以下因素影响：
| 因素 | 影响 | 调优方向 |
|---|---|---|
| 路由表规模 | 每增加一个远程 Pod 条目，路由查找时间线性增长 | 使用聚合路由（IP 池级别）减少条目数 |
| iptables 规则链长度 | NetworkPolicy 越多，规则链越长，匹配延迟越高 | 启用 nftables 后端、优化策略顺序 |
| MTU 配置 | IPIP/VXLAN 封装会额外消耗 MTU，导致分片 | 调整物理网络 MTU 或启用巨型帧 |
| BGP 收敛速度 | 节点故障时，BIRD 需要时间重新计算路由 | 调整 BGP 定时器、启用 ECMP |
| Felix 同步间隔 | Felix 与 API Server 的同步频率影响策略生效速度 | 调整 FelixSyncInterval 参数 |
镜像拉取加速关联：在多集群镜像拉取场景中，数据平面的转发延迟直接影响镜像层数据的传输效率。如果 Calico 使用 IPIP 封装，额外的 20 字节头部可能导致 MTU 问题，进而触发 TCP 分片和重传。后续章节将针对这些参数进行专项调优，以降低跨集群镜像拉取的网络开销。
2.6 组件交互时序总结
为了更直观地理解 Felix、BIRD、confd 之间的交互时序，下表总结了典型场景下的组件协作流程：
| 步骤 | 触发事件 | 执行组件 | 输出/结果 |
|---|---|---|---|
| 1 | 新 Pod 调度到节点 | Kubernetes Scheduler | Pod 状态更新写入 API Server |
| 2 | Felix 监听 Pod 变化 | Felix | 写入主机路由、创建 veth 对 |
| 3 | Felix 更新 iptables | Felix | 生成 cali-policy 规则链 |
| 4 | confd 检测路由变化 | confd | 更新 BIRD 配置文件 |
| 5 | BIRD 重载配置 | BIRD | 向 BGP 对等体发送路由更新 |
| 6 | 其他节点 BIRD 接收路由 | BIRD (其他节点) | 写入内核路由表，完成路由收敛 |