2. Calico 架构基础：组件概览与数据路径
在平台门户中实施准入策略性能基准测试之前，必须深入理解 Calico 的架构组件及其数据路径。Calico 采用 纯三层网络模型，结合 iptables/eBPF 实现策略执行，其核心组件包括 Felix、Typha 以及 数据存储后端（etcd 或 Kubernetes API）。本章将逐一拆解这些组件的职责、交互方式以及策略执行的关键路径。
2.1 Calico 核心组件概览
Calico 的控制平面由以下组件构成，它们协同工作以维护网络策略的一致性和高性能。
| 组件 | 部署形态 | 核心职责 | 性能关键点 |
|---|---|---|---|
| Felix | DaemonSet（每个节点一个） | 策略代理：监听数据存储，将策略转换为 iptables/eBPF 规则，管理路由与端点 | 规则转换效率、节点级策略更新延迟 |
| Typha | Deployment（可选，大规模集群推荐） | 数据存储代理：聚合 Felix 对 API Server 的 Watch 请求，降低控制面压力 | 连接数压缩比、事件分发吞吐量 |
| etcd / K8s API | 外部依赖 | 数据存储：保存策略、端点、IPAM 等所有 Calico 资源对象 | 读写延迟、Watch 响应速度、资源版本管理 |
| calicoctl / kubectl | CLI 工具 | 管理接口：创建/更新/删除 Calico 资源（NetworkPolicy, IPPool 等） | API 调用延迟（非数据面关键路径） |
性能测试提示： 在基准测试中，Felix 的规则计算耗时和 Typha 的事件分发延迟是影响策略生效速度的两个主要瓶颈。建议在测试报告中单独记录这两个组件的 CPU 和内存开销。
2.2 组件交互与数据路径
下图展示了 Calico 组件之间的通信关系以及策略从创建到生效的完整数据路径。该路径直接影响准入策略的端到端延迟。
2.3 策略执行点详解
Calico 的策略执行发生在 宿主机内核的 Netfilter 框架（iptables）或 eBPF 中。Felix 作为每个节点上的代理，负责将抽象的 Calico 策略资源转换为内核可执行的规则。其执行点主要分为以下三个阶段：
- Ingress 路径（入站流量）：流量到达宿主机网卡后，经过 PREROUTING 链，Calico 在 FORWARD 链中插入规则，匹配源端点与策略，决定是否放行。
- Egress 路径（出站流量）：Pod 发出的流量经过 OUTPUT 链，Calico 在 OUTPUT 或 FORWARD 链中匹配目的端点与策略。
- 本地端点路径：对于宿主机本地进程，Calico 在 INPUT 和 OUTPUT 链中插入规则，确保宿主机自身的流量也受策略管控。
基准测试关注点： 策略执行点的规则数量直接影响数据面的吞吐量和延迟。在测试中，应记录不同策略规模（例如 100 条、1000 条、5000 条规则）下，Felix 的规则安装时间以及数据面的 P99 延迟变化。
2.4 组件通信协议与端口
了解组件间的通信协议和端口，有助于在平台门户中进行网络隔离和监控配置。
| 通信方向 | 协议 | 默认端口 | 用途 |
|---|---|---|---|
| Felix → K8s API Server | HTTPS | 6443 | Watch 策略、端点、命名空间等资源 |
| Felix → Typha | gRPC over TLS | 5473 | Felix 通过 Typha 代理获取数据存储事件 |
| Typha → K8s API Server | HTTPS | 6443 | Typha 作为唯一客户端 Watch 数据存储 |
| Felix ↔ 内核 Netfilter | Netlink | N/A | Felix 通过 Netlink 套接字操作 iptables/eBPF 规则 |
2.5 关键架构决策：Typha 的作用
在大型 Kubernetes 集群（节点数 > 50）中，Typha 是一个关键的性能优化组件。其工作原理如下：
- 连接聚合：所有 Felix 实例不再直接连接 API Server，而是连接到少数几个 Typha 实例。Typha 作为代理，将 Felix 的 Watch 请求合并为一个连接发送给 API Server。
- 事件分发：Typha 从 API Server 接收到资源更新事件后，将其广播给所有已连接的 Felix 实例。这大幅降低了 API Server 的连接数和 Watch 负载。
- 性能收益：在 200 节点集群中，使用 Typha 可以将 API Server 的 Watch 连接数从 200 降低到 2-3 个，显著减少控制面压力，提升策略更新速度。
避坑指南： 在基准测试中，如果未部署 Typha，当集群规模较大或策略频繁变更时，Felix 与 API Server 之间的 Watch 连接可能会成为瓶颈，导致策略生效延迟增加。建议在测试环境中同时部署带 Typha 和不带 Typha 的场景，以量化其性能差异。
2.6 数据路径总结
Calico 的策略执行数据路径可以概括为以下流程：
- 策略创建：用户通过
kubectl apply或calicoctl create将 NetworkPolicy 写入数据存储（etcd 或 K8s API）。 - 事件通知：数据存储触发 Watch 事件，Typha（如果部署）或 Felix 直接接收到策略变更通知。
- 规则计算：Felix 根据新的策略和当前端点信息，计算出一组 iptables 或 eBPF 规则。
- 规则注入：Felix 通过 Netlink 将规则写入内核的 Netfilter 框架，插入到对应的链中。
- 流量匹配：后续 Pod 间的流量经过宿主机内核时，由 iptables/eBPF 规则进行匹配，执行 Allow 或 Deny 动作。