3. 网络接口模型：Linux网络栈、veth pair、CNI接口、Cilium的Endpoint与Identity概念
在容量规划视角下，理解Cilium的网络接口模型是优化数据路径、降低延迟和提升吞吐量的基础。本章将逐层拆解从Linux内核网络栈到Cilium高层抽象（Endpoint与Identity）的完整链路，并揭示每一层对资源消耗和性能瓶颈的影响。
3.1 Linux网络栈：数据包的旅程
每个进出容器的数据包都必须穿越Linux内核网络栈。对于容量规划而言，关键路径上的每一步都可能成为CPU和内存的消耗点。
| 阶段 | 描述 | 容量规划关注点 |
|---|---|---|
| 1. 网卡接收 | 硬件通过DMA将数据写入Ring Buffer，触发硬中断。 | 中断亲和性、队列数（RSS）是否匹配CPU拓扑。 |
| 2. 内核协议栈 | 软中断（NET_RX_SOFTIRQ）处理，IP层路由查找、Netfilter钩子。 | 连接跟踪（conntrack）表大小、路由缓存命中率。 |
| 3. 套接字分发 | 根据四元组将数据包交付给对应Socket的接收队列。 | Socket backlog队列深度、epoll事件分发效率。 |
| 4. 用户态读取 | 应用通过read/recvmsg系统调用从内核拷贝数据到用户空间。 | 上下文切换开销、零拷贝（如XDP）是否启用。 |
容量规划要点： 在Cilium环境中，eBPF程序（如XDP和TC hook）可以绕过部分传统内核路径，显著降低延迟。规划时应评估是否启用XDP卸载以及硬件对eBPF的支持程度。
3.2 veth pair：容器网络的“虚拟网线”
veth（Virtual Ethernet）是成对出现的虚拟网络设备，一端在宿主机网络命名空间（通常作为CNI接口），另一端在容器网络命名空间（作为eth0）。它是Kubernetes Pod网络的基本连接单元。
- 工作原理： 数据包从一端进入，内核直接将其推送到另一端，不经过物理线路。
- 性能特征： 纯软件转发，延迟极低（通常微秒级），但大量veth pair会消耗系统文件描述符和内核内存。
- 容量规划指标：
- 每节点Pod密度：veth pair数量直接影响内核的net_device结构体内存占用。
- MTU一致性：宿主机与容器MTU不匹配会导致分片，增加CPU开销。
优化建议： 在Cilium中，veth pair的宿主机端通常被附加TC eBPF程序。确保宿主机端接口的txqueuelen设置合理（默认1000，高吞吐场景可调至10000），避免因队列溢出导致丢包。
3.3 CNI接口：Kubernetes与Cilium的桥梁
CNI（Container Network Interface）是Kubernetes调用网络插件的标准接口。Cilium作为CNI插件，在Pod创建时负责配置网络命名空间和veth pair。
CNI配置流程：
- kubelet调用Cilium CNI二进制（
ADD命令）。 - Cilium创建veth pair，将一端移入Pod网络命名空间。
- Cilium为Pod分配IP地址（来自IP池）。
- Cilium创建Endpoint对象，并附加eBPF程序到veth的宿主机端。
- 返回结果给kubelet，Pod网络就绪。
| CNI阶段 | 资源消耗 | 容量规划影响 |
|---|---|---|
| 二进制调用 | 进程启动、文件系统I/O | 高Pod创建并发时，CNI二进制路径的磁盘I/O可能成为瓶颈。 |
| IP分配 | IPAM（IP地址管理）查询 | CRD-backed IPAM模式下，etcd的QPS和延迟直接影响Pod启动速度。 |
| eBPF加载 | 内核验证器、内存分配 | 大规模集群（>1000 Pod/节点）需关注eBPF map大小和verifier复杂度。 |
3.4 Cilium Endpoint：Pod的网络抽象
在Cilium中，每个Pod（或外部服务）被抽象为一个Endpoint。Endpoint是Cilium内部管理网络策略、负载均衡和可观测性的基本单元。
- Endpoint ID： 每个Endpoint在Cilium Agent内部拥有唯一数字ID，用于快速查找eBPF map。
- 关联资源： 每个Endpoint关联一个veth pair的宿主机端接口、一个IP地址、一组安全标签（Labels）和一组策略规则。
- 生命周期： Endpoint随Pod创建而创建，随Pod删除而销毁。Cilium Agent维护一个全局Endpoint列表。
容量规划风险： 当节点上Pod数量极大（例如超过500）时，Cilium Agent的Endpoint同步和eBPF map更新可能成为CPU热点。建议监控
cilium_endpoint_count和cilium_k8s_events_rate指标。
3.5 Cilium Identity：安全策略的原子单元
Identity是Cilium基于身份的安全模型的核心。它不是网络接口，而是与Endpoint绑定的安全标识，用于在网络策略中标识“谁”在通信。
Identity的生成与分配：
- 基于Pod的Labels（如
app=frontend）通过一致性哈希或KV存储分配一个全局唯一的16位或24位数字ID。 - Identity存储在Cilium Agent的本地缓存和eBPF map中。
- 当两个Endpoint通信时，Cilium在eBPF层面直接比较Identity，而非解析IP地址，从而实现微秒级策略决策。
| 概念 | 作用域 | 容量规划影响 |
|---|---|---|
| Endpoint | 节点本地 | 数量受限于节点内存和eBPF map大小（默认64K）。 |
| Identity | 集群全局 | 数量受限于Identity位数（16位=65535，24位=16M）。Label组合爆炸可能导致Identity耗尽。 |
3.6 完整数据路径与容量规划视图
下图展示了从容器内应用到对端Pod的完整数据路径，并标注了每个环节的容量规划关键点。
3.7 容量规划检查清单
基于上述模型，在规划Cilium集群容量时，建议逐项评估以下指标：
| 层级 | 检查项 | 推荐阈值 | 监控指标 |
|---|---|---|---|
| Linux网络栈 | 软中断CPU使用率 | < 30% 单核 | softirq_net_rx |
| veth pair | 每节点veth数量 | < 1000 | net_device_count |
| CNI接口 | Pod创建延迟P99 | < 500ms | cilium_k8s_pod_latency |
| Endpoint | Agent内存占用 | < 1GB/节点 | cilium_agent_memory |
| Identity | 全局Identity数量 | < 10000 | cilium_identity_count |
实战建议： 在部署前使用
cilium connectivity test和cilium monitor验证数据路径完整性。对于高密度场景（每节点>200 Pod），建议启用Cilium的endpoint-bpf-prog-generation优化，减少eBPF程序重载次数。