2. Calico 架构总览：核心组件与数据流

Calico 采用分布式无中心架构，通过一组协同工作的组件实现容器网络策略与路由管理。理解每个组件的职责及其数据交互路径，是进行缓存命中率调优的前提。本章将逐一解析 Felix、BIRD、confd、数据存储后端以及 Typha 的作用，并展示完整的数据流。

2.1 核心组件一览

2.2 组件详解与数据流

2.2.1 Felix：节点代理

Felix 是运行在每个 Kubernetes 节点上的核心代理，直接负责数据平面的编程。它通过监听数据存储中的 NetworkPolicy、Endpoint 和 IPPool 资源，将策略转化为节点本地的 iptables 规则或 eBPF 程序，并维护路由表与虚拟网卡。

• 数据输入：从数据存储（直接或通过 Typha）watch 资源变更。
• 数据输出：调用 iptables/ip6tables、ip route、ip link 等系统命令。
• 缓存机制：Felix 内部维护资源缓存，减少对数据存储的重复查询。

2.2.2 BIRD：BGP 路由引擎

BIRD 负责在 Calico 节点之间通过 BGP 协议交换容器路由。每个节点的 BIRD 实例会将自己负责的容器网段通告给其他节点，从而实现跨节点 Pod 通信。

• 配置来源：confd 根据数据存储中的 BGPPeer、Node 资源动态生成 BIRD 配置文件。
• 路由学习：从 Felix 维护的内核路由表导入直连路由，并通过 BGP 会话导出给邻居。
• 性能关键：BGP 会话数量、路由表规模直接影响内存与 CPU 开销。

2.2.3 confd：配置模板引擎

confd 是一个轻量级的配置管理工具，在 Calico 中专门用于为 BIRD 生成配置。它 watch 数据存储中的特定 key 前缀，一旦发现变化，就使用 Go 模板渲染出新的 BIRD 配置文件，并触发 BIRD 重新加载。

• 工作流程：watch 事件 → 读取最新数据 → 渲染模板 → 校验配置 → 重启 BIRD。
• 调优点：模板渲染性能、watch 超时设置、重载触发频率。

2.2.4 数据存储：etcd 与 Kubernetes API

Calico 支持两种数据存储后端：etcd 和 Kubernetes API。etcd 模式提供更精细的 watch 控制和更低延迟，但需要独立运维；Kubernetes API 模式复用集群已有存储，简化运维但 watch 性能受 API Server 限制。

2.2.5 Typha：连接扇出与缓存层

在大型集群中，成百上千个 Felix 实例同时 watch 数据存储会给后端带来巨大压力。Typha 作为中间代理层，所有 Felix 连接到 Typha，Typha 再维持少量连接到数据存储。Typha 内部维护一个事件缓存，当 Felix 重连时可以直接从缓存恢复，避免全量重新同步。

• 连接数压缩：N 个 Felix 对 M 个数据存储连接，变为 N 个 Felix 对 1 个 Typha 连接 + 1 个 Typha 对数据存储连接。
• 缓存加速：Felix 断连后重连，Typha 可发送缓存快照，大幅减少数据存储负载。
• 推荐场景：节点数 > 50 时强烈建议启用 Typha。

2.3 完整数据流图

下图展示了 Calico 组件之间的数据交互路径，重点关注策略下发与路由同步两条主线。

2.4 组件交互时序

以创建一个新的 NetworkPolicy 为例，展示组件间的典型交互时序：

1. 用户创建策略：通过 kubectl apply -f policy.yaml 写入 Kubernetes API。
2. 数据存储更新：API Server 将策略持久化到 etcd，并触发 watch 事件。
3. Typha 接收事件：Typha 从数据存储收到变更通知，更新内部缓存，并推送给所有连接的 Felix。
4. Felix 处理事件：Felix 解析策略，计算需要更新的 iptables 规则链，调用 iptables-restore 应用变更。
5. confd 同步：如果策略涉及路由变化（如 IP 池变更），confd 检测到后重新渲染 BIRD 配置。
6. BIRD 重载：BIRD 加载新配置，更新 BGP 路由通告。

2.5 缓存命中率相关组件总结

从缓存命中率的角度，各组件的影响可归纳如下：