2. Calico 架构基础：Felix、Typha、etcd 与 Kubernetes API Server 的交互模型
在深入控制平面驱动的准入策略之前，必须理解 Calico 的核心组件如何协同工作。Calico 的架构围绕 数据平面（Linux 内核 iptables/ebpf）和 控制平面（策略分发与状态同步）展开。本章聚焦控制平面的四个关键角色：Felix、Typha、etcd 与 Kubernetes API Server，并剖析它们之间的交互模型。
2.1 核心组件角色与职责
下表总结了每个组件在 Calico 控制平面中的定位与核心职责：
| 组件 | 部署模式 | 核心职责 | 数据存储依赖 |
|---|---|---|---|
| Felix | DaemonSet（每个节点一个） | 编程节点内核网络规则（iptables/ebpf）、路由、ACL；上报端点状态 | 直接或通过 Typha 读取策略/端点数据 |
| Typha | Deployment（可选，推荐大规模集群） | 作为 Felix 与数据存储之间的代理，降低数据存储的 watch 连接数，聚合数据 | 连接 etcd 或 Kubernetes API Server |
| etcd | 外部集群（独立部署） | Calico 原生数据存储，保存策略、端点、IPAM 分配等所有状态 | 自身分布式一致性存储 |
| Kubernetes API Server | Kubernetes 控制面组件 | 作为 Calico 的替代数据存储（KDD 模式），存储 NetworkPolicy、IPPool 等 CRD 对象 | etcd（Kubernetes 自身） |
关键选择：Calico 支持两种数据存储模式——etcd 模式（原生 Calico 数据存储）和 Kubernetes 数据存储（KDD）模式。KDD 模式是生产环境的主流选择，因为它复用 Kubernetes API Server 的鉴权、审计和一致性能力，无需额外维护 etcd 集群。
2.2 交互模型总览：Felix ↔ Typha ↔ 数据存储
下图展示了在 KDD 模式下，Felix、Typha 与 Kubernetes API Server 之间的核心交互流程。etcd 模式的结构类似，只是数据存储替换为 etcd 集群。
2.3 交互流程详解：从策略变更到规则生效
当用户创建或更新一个 NetworkPolicy（或 Calico 的 GlobalNetworkPolicy）时，控制平面经历以下完整链路：
- 策略写入：用户通过
kubectl apply将策略对象写入 Kubernetes API Server（KDD 模式）或 etcd（etcd 模式）。 - Typha 感知变更：Typha 通过 List-Watch 机制监听 API Server 上的策略、端点、IPPool 等资源的变化。Typha 维护一个本地缓存。
- 数据扇出：Typha 将变更事件（增量或全量）通过长连接推送到所有已连接的 Felix 实例。Felix 不直接 watch API Server。
- Felix 计算差分：Felix 收到更新后，对比本地缓存的数据，计算出需要增删改的 iptables 规则或路由条目。
- 内核编程：Felix 调用
iptables-restore或ipset命令，将差分结果写入内核。对于 eBPF 模式，则通过bpf()系统调用加载 BPF 程序。 - 状态上报：Felix 定期将节点上的端点状态（如端点是否就绪）写回 Typha，最终同步到 API Server。
性能关键点：Felix 的“差分计算”是性能瓶颈之一。Felix 内部使用 数据平面编程器（Dataplane Programmer） 维护一个期望状态（Desired State）与当前状态（Current State）的哈希表，只推送差异部分，避免全量刷新。
2.4 Typha 的连接聚合原理
在大规模集群（节点数 > 50）中，如果没有 Typha，每个 Felix 都会与 API Server 建立一个 Watch 连接。假设集群有 200 个节点，API Server 需要维护 200 个长连接，每个连接都在监听全量策略数据，这对 API Server 的内存和 CPU 造成巨大压力。
Typha 的引入将连接数从 O(N) 降低到 O(1)：
| 场景 | API Server 连接数 | Felix 连接数 | 数据一致性 |
|---|---|---|---|
| 无 Typha（直接连接） | N（每个 Felix 一个） | 1（直接连 API Server） | 每个 Felix 独立 watch，可能因重连导致短暂不一致 |
| 有 Typha | 1（Typha 到 API Server） | 1（Felix 到 Typha） | Typha 保证顺序一致性，扇出时保持相同视图 |
注意：Typha 本身是一个有状态组件。如果 Typha 崩溃，所有 Felix 会暂时失去数据更新推送，但 Felix 本地缓存的策略仍然生效，不会导致网络中断。Felix 会尝试重连 Typha，重连成功后重新同步全量数据。
2.5 etcd 模式 vs KDD 模式：交互差异
两种模式在交互模型上的核心差异体现在数据存储的访问方式上：
- etcd 模式：Typha 直接通过 etcd v3 API 进行 Watch 和 List 操作。Felix 同样通过 Typha 间接访问 etcd。etcd 模式不依赖 Kubernetes API Server，适合需要独立数据存储的场景。
- KDD 模式：Typha 通过 Kubernetes API Server 的 REST API 访问 Calico CRD（如
FelixConfiguration、IPPool）。API Server 负责鉴权、审计和资源版本管理。
下表对比了两种模式在关键交互维度上的差异：
| 维度 | etcd 模式 | KDD 模式（推荐） |
|---|---|---|
| 数据存储 | 独立 etcd 集群 | Kubernetes API Server + etcd |
| 鉴权 | etcd 证书/用户名密码 | Kubernetes RBAC + ServiceAccount |
| 审计 | etcd 审计日志（需额外配置） | Kubernetes Audit Logging 原生支持 |
| 运维复杂度 | 高（需维护 etcd 集群） | 低（复用 Kubernetes 控制面） |
| Felix 连接路径 | Felix → Typha → etcd | Felix → Typha → API Server → etcd |
2.6 交互模型中的关键性能瓶颈
理解交互模型后，可以识别出以下潜在性能瓶颈，这些瓶颈将在后续章节的调优中重点解决：
- API Server Watch 负载：即使有 Typha，API Server 仍需处理 Typha 的 List-Watch 请求。如果 Typha 配置不当（如
TyphaConnectionRebalancingInterval过短），可能导致 API Server 频繁重连。 - Typha 内存占用：Typha 缓存全量策略和端点数据。在拥有 10 万+ 端点的集群中，Typha 的内存可能达到数 GB，需要合理设置
--max-connections-per-node和缓存大小。 - Felix 数据平面编程延迟：Felix 从收到更新到完成内核编程的延迟受 CPU 和内核锁竞争影响。在高频策略变更场景下，Felix 的“编程队列”可能堆积。
- etcd 写入延迟：在 etcd 模式下，策略写入直接落盘 etcd。etcd 的磁盘 IOPS 和 Raft 共识延迟直接影响策略生效速度。
调优切入点：在后续章节中，我们将深入调整
FelixConfiguration 中的 IpsetRefreshInterval、ChainInsertMode，以及 Typha 的 TyphaConfiguration 中的 ConnectionRebalancingInterval 和 MaxConnectionsLowerLimit，以缓解上述瓶颈。
2.7 交互模型总结图：端到端数据流
下图从更高维度展示了控制平面中数据流的完整闭环，包括策略下发、状态上报和健康检查路径：