Cilium网络策略与Serverless性能调优实战 - 第1节
1.1 Cilium 的起源：从容器网络到内核可编程
Cilium 诞生于 2016 年，由 Thomas Graf 等内核与网络专家在创业公司 Covalent 中创建，随后捐赠给 CNCF 并于 2021 年晋升为毕业项目。其核心驱动力是：传统 CNI 在 Kubernetes 大规模多租户场景下，面临安全策略粒度粗、性能损耗高、可观测性不足三大瓶颈。Cilium 选择了一条激进的技术路径——基于 eBPF（extended Berkeley Packet Filter）直接在 Linux 内核中注入网络、安全与可观测逻辑，从而绕过 iptables 和用户态代理的沉重开销。
1.2 核心特性：eBPF、可观测性、安全
1.2.1 eBPF —— 内核中的沙箱虚拟机
eBPF 允许用户在 Linux 内核中安全地运行沙箱化程序，无需修改内核源码或加载内核模块。Cilium 利用 eBPF 实现数据路径的完全可编程：
- 网络转发：在 XDP（eXpress Data Path）或 TC（Traffic Control）层直接处理数据包，绕过 iptables 和 conntrack。
- 负载均衡：基于 eBPF 的 kube-proxy 替代方案，实现无 iptables 的 Service 转发。
- 策略执行：在 BPF 程序内完成 L3/L4/L7 策略匹配，延迟低至微秒级。
1.2.2 可观测性 —— Hubble 与 Tetragon
Cilium 的可观测性体系分为两层：
| 组件 | 数据来源 | 核心能力 |
|---|---|---|
| Hubble | eBPF 捕获的网络流 | 实时服务依赖图、L3/L4/L7 流量指标、DNS 解析追踪 |
| Tetragon | eBPF 捕获的系统调用 | 进程执行、文件访问、网络连接、容器逃逸检测 |
Hubble 提供 hubble observe CLI 和 UI 界面，支持按命名空间、标签、IP、端口、HTTP 路径等维度过滤流量。Tetragon 则聚焦运行时安全，可检测 exec、open、connect 等敏感系统调用。
1.2.3 安全 —— 身份感知与 L7 策略
Cilium 的安全模型基于 Identity（身份） 而非 IP 地址。每个 Pod 启动时，Cilium 根据其标签分配一个 24 位安全身份 ID，所有策略均基于此 ID 进行匹配，彻底消除 IP 漂移带来的策略失效问题。
- L3/L4 策略：基于身份、IP、端口、协议。
- L7 策略：基于 HTTP 方法、路径、头部；gRPC 服务名；Kafka Topic 等。
- DNS 策略：基于域名解析结果动态生成策略规则。
- 加密：通过 WireGuard 或 IPsec 实现节点间透明加密。
1.3 与传统 CNI 的对比
下表从架构、性能、安全、可观测性四个维度对比 Cilium、Calico 和 Flannel：
| 维度 | Cilium | Calico | Flannel |
|---|---|---|---|
| 数据路径 | eBPF（内核态） | iptables / eBPF（可选） | VXLAN / host-gw（用户态封装） |
| 网络策略 | L3/L4/L7 + DNS + 身份感知 | L3/L4 + 网络策略（K8s 原生） | 不支持 |
| 可观测性 | Hubble（流 + 指标 + 依赖图） | Felix 日志 + Prometheus 指标 | 无内置 |
| 性能（P99 延迟） | 低（微秒级） | 中（iptables 规则多时劣化） | 中（VXLAN 封装开销） |
| 加密 | WireGuard / IPsec 原生 | WireGuard 可选 | 无 |
| 运维复杂度 | 中（需内核 ≥ 5.10） | 低 | 低 |
1.4 Cilium 架构总览
下图展示了 Cilium 的核心组件及其交互关系：
架构要点：
- Cilium Operator 负责集群级协调，如身份分配、节点间隧道配置。
- Cilium Agent 运行在每个节点，通过 gRPC 与 API Server 通信，编译并加载 eBPF 程序。
- eBPF 程序 挂载到 XDP、TC、cgroup 等内核钩子，直接处理数据包和系统调用。
- Hubble Relay 聚合各节点的流数据，提供给 Hubble UI 或 CLI。
1.5 为什么 Serverless 场景需要 Cilium？
Serverless 平台（如 Knative、OpenFaaS、AWS Fargate）对网络层有特殊要求：
- 冷启动延迟敏感：传统 iptables 规则同步在 Pod 频繁创建/销毁时成为瓶颈。
- 细粒度隔离：每个函数实例需要独立的身份和策略，IP 地址复用频繁。
- 可观测性：需要追踪每个函数调用的网络路径和延迟分布。
Cilium 的 eBPF 数据路径在 Pod 创建时无需预分配 iptables 规则，身份感知策略天然适配函数实例的临时性，Hubble 提供的流日志可直接关联到函数调用链。这些特性使 Cilium 成为 Serverless 基础设施网络层的理想选择。