3. Calico 架构概览：核心组件详解与数据/控制平面分离

Calico 是 Kubernetes 生态中最流行的 CNI 插件之一，其核心设计理念是将网络策略的执行与数据转发完全解耦。本章将深入剖析 Calico 的五大核心组件——Felix、BIRD、confd、Typha，并阐述其数据平面与控制平面分离的架构优势。

3.1 核心组件全景

Calico 采用分布式架构，每个节点上运行一组轻量级代理，通过 etcd 或 Kubernetes API Server 同步状态。下表总结了各组件的职责与部署位置：

3.2 Felix：数据平面的执行者

Felix 是 Calico 的“手脚”，运行在每个 Kubernetes 节点上，负责将网络策略和路由规则转化为内核中的实际配置。其工作流程如下：

1. 监听数据源：通过 Watch API 从 Typha 或直接从 API Server 获取 WorkloadEndpoint、NetworkPolicy、IPPool 等资源。
2. 计算差分：将当前内核状态与期望状态对比，生成增量更新指令。
3. 写入内核：调用 iptables-restore、ip route replace、ip link set 等系统命令，完成规则安装。
4. 健康上报：定期向 API Server 上报节点状态和 Felix 自身健康信息。

3.3 BIRD 与 confd：控制平面的路由引擎

BIRD（BIRD Internet Routing Daemon）是 Calico 实现 BGP 路由分发的核心。confd 则作为配置生成器，将 etcd 中的路由信息动态写入 BIRD 配置文件。

两者的协作关系如下：

• confd 订阅 etcd 中 /calico/bgp/v1 路径下的变化，当有新的节点加入或 Pod 子网变更时，立即生成新的 BIRD 配置。
• BIRD 通过 birdc configure 热加载新配置，无需重启进程。
• BIRD 与对端（其他节点或物理路由器）建立 BGP 会话，通告 Pod CIDR 路由。

3.4 Typha：大规模集群的通信瓶颈突破

当集群规模超过 50 个节点时，每个节点的 Felix 都直接 Watch API Server 会导致严重的连接风暴。Typha 作为中间层，解决了这一痛点：

Typha 内部维护一个 状态缓存，当 Felix 断开重连时，Typha 直接发送全量快照 + 增量事件，避免 Felix 重新从 API Server 拉取全量数据。

3.5 数据平面与控制平面分离架构

Calico 最核心的设计哲学是数据平面与控制平面完全分离。这种分离带来了以下优势：

• 独立升级：Felix 的升级不影响 BIRD 的路由会话，反之亦然。
• 故障隔离：BIRD 进程崩溃不会导致已有网络策略失效，Felix 仍维持内核规则。
• 性能优化：控制平面可以使用较慢的异步更新（BGP 收敛秒级），而数据平面必须快速响应（iptables 更新毫秒级）。
• 多后端支持：控制平面可以替换为其他路由协议（如 IPIP、VXLAN），数据平面保持不变。

3.6 组件间通信流程

为了更直观地理解组件协作，下图展示了从网络策略创建到内核规则生效的完整调用链：

3.7 架构设计总结

Calico 通过以下设计原则实现了高性能与高可用的统一：