IDP自助门户蓝图：Cilium网络策略调试与验证 - 第1节
1.1 Cilium 项目背景：从容器网络到云原生安全
Cilium 是一个基于 eBPF（extended Berkeley Packet Filter）的开源项目，旨在为容器化工作负载（尤其是 Kubernetes）提供高性能的网络、可观测性与安全能力。Cilium 由 Isovalent（现被 Cisco 收购）于 2016 年发起，并于 2021 年正式加入 CNCF（Cloud Native Computing Foundation）成为毕业项目。
核心定位：Cilium 不是传统的 CNI（Container Network Interface）插件，而是一个“云原生网络与安全层”。它利用 eBPF 在内核态动态注入程序，替代了 iptables、ipvs 等传统数据平面，实现了更细粒度的控制与更低的延迟。
1.1.1 为什么需要 Cilium？
传统 Kubernetes 网络方案（如 Calico、Flannel）依赖 iptables 或用户态代理，存在以下痛点：
| 痛点 | 传统方案表现 | Cilium 的改进 |
|---|---|---|
| 性能瓶颈 | iptables 规则链随 Pod 数量线性增长，CPU 开销高 | eBPF 在内核态直接处理，规则更新 O(1) 复杂度 |
| 安全粒度粗 | 仅支持 IP+端口 5 元组策略 | 支持 L3/L4/L7 协议、服务身份（Service Identity）、DNS、HTTP/gRPC 方法 |
| 可观测性弱 | 依赖 Prometheus 导出器或 sidecar 抓取 | eBPF 直接采集网络流、DNS 请求、TCP 状态，零侵入 |
| 服务网格集成 | 需要额外部署 Envoy/Istio sidecar | 支持 eBPF 加速的透明服务网格（无需 sidecar） |
1.1.2 Cilium 在 Kubernetes 中的角色
Cilium 在 Kubernetes 集群中承担以下核心角色：
- CNI 插件：为 Pod 分配 IP 地址，实现 Pod 间通信、Service 负载均衡。
- 网络策略引擎：执行 Kubernetes NetworkPolicy 以及 Cilium 增强的 CiliumNetworkPolicy（支持 L7、DNS、CIDR 等）。
- 可观测性数据源：通过 Hubble 组件提供网络流日志、服务依赖图、TCP 指标。
- 安全审计与隔离：基于身份（Identity）而非 IP 的零信任网络分段。
- 服务网格数据平面：可选替代 Envoy，提供 eBPF 加速的 L7 策略与负载均衡。
1.2 eBPF 技术原理：内核的可编程性革命
eBPF 是一项允许用户在 Linux 内核中安全地运行沙箱化程序的技术，无需修改内核源码或加载内核模块。eBPF 程序由内核验证器（Verifier）检查安全性后，通过 JIT（Just-In-Time）编译器转换为原生机器码执行。
1.2.1 eBPF 的核心工作流程
- 编写 eBPF 程序：通常使用 C 语言编写，定义挂载点（如网络包到达、系统调用、函数入口/出口）。
- 编译为 BPF 字节码：使用 LLVM/Clang 编译为 ELF 格式的 BPF 目标文件。
- 加载到内核：通过 bpf() 系统调用将字节码加载到内核，触发验证器检查。
- 验证与 JIT 编译：验证器确保程序无循环、无越界访问、有限指令数；通过后 JIT 编译为机器码。
- 挂载到事件源：将 eBPF 程序附加到指定事件（如 XDP、TC、kprobe、tracepoint）。
- 数据交互：通过 eBPF Map（键值存储）与用户态程序交换数据，或通过 perf_event 输出日志。
关键区别：传统内核模块可以访问任意内核函数和数据结构，一旦崩溃会导致整个系统宕机。eBPF 程序经过验证器严格检查，确保不会导致内核崩溃或死锁，因此被称为“安全的内核可编程性”。
1.2.2 eBPF 在 Cilium 中的典型应用
| eBPF 挂载点 | Cilium 使用场景 | 性能优势 |
|---|---|---|
| XDP (eXpress Data Path) | DDoS 防护、包过滤、重定向 | 在网卡驱动层处理，延迟微秒级 |
| TC (Traffic Control) | Pod 网络策略、Service 负载均衡、封装/解封装 | 避免 iptables 遍历，规则更新无连接中断 |
| cgroup/skb | 容器网络隔离、带宽限制 | 按 cgroup 粒度控制，无需 veth 对 |
| kprobe/tracepoint | Hubble 可观测性：TCP 状态、DNS 请求、HTTP 解析 | 零侵入采集，不修改应用代码 |
1.3 Cilium 在 Kubernetes 中的角色：身份驱动的网络策略
Cilium 在 Kubernetes 中引入了一个关键概念：身份（Identity）。每个 Pod 或外部端点根据其标签（Labels）被分配一个 24 位的安全身份 ID。网络策略基于身份而非 IP 地址编写，解决了 Pod 重建后 IP 变化导致的策略失效问题。
1.3.1 身份分配与策略执行流程
- Pod 创建：Kubernetes 调度 Pod 到节点，Cilium Agent 监听 API Server 事件。
- 身份解析：Cilium 根据 Pod 的 Labels 计算身份 ID，通过 KV 存储（etcd 或 CRD）同步到集群。
- eBPF Map 更新：每个节点上的 Cilium Agent 将身份 ID 写入本地的 eBPF Map（如 cilium_ipcache、cilium_identity）。
- 策略加载：CiliumNetworkPolicy 被转换为 eBPF 程序，挂载到 TC 或 XDP 钩子。
- 包处理：当 Pod 发送网络包时，eBPF 程序查找源/目的身份，匹配策略规则，决定允许或拒绝。
调试要点：在排查网络策略问题时，首先确认 Pod 的身份 ID 是否正确。使用
cilium identity list 查看身份映射，使用 cilium endpoint list 检查端点状态。身份 ID 不一致是策略不生效的常见原因。
1.3.2 CiliumNetworkPolicy 与传统 NetworkPolicy 对比
| 特性 | Kubernetes NetworkPolicy | CiliumNetworkPolicy |
|---|---|---|
| 策略范围 | 仅支持 L3/L4（IP+端口） | L3/L4 + L7（HTTP、gRPC、Kafka、DNS） |
| 身份标识 | 基于 Pod 标签 + IP 块 | 基于安全身份 ID + 标签 + 服务名 + FQDN |
| 策略方向 | Ingress / Egress | Ingress / Egress + 双向（toEntities / fromEntities） |
| 外部访问 | 仅支持 CIDR | 支持 CIDR + DNS 域名 + TLS SNI |
| 日志与审计 | 无原生支持 | Hubble 流日志 + 策略判定事件 |
| 性能 | iptables 规则链，大规模集群性能下降 | eBPF 哈希查找，O(1) 复杂度 |
1.3.3 典型 CiliumNetworkPolicy 示例
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-frontend-to-backend
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP
rules:
http:
- method: "GET"
path: "/api/v1/orders"
策略解读：该策略允许带有
app: frontend 标签的 Pod 向 app: backend 的 Pod 发起 HTTP GET 请求到 /api/v1/orders 路径。非 GET 方法或其他路径将被拒绝。策略基于身份而非 IP，即使 Pod 重建或迁移，策略依然生效。
1.4 本章小结
- Cilium 是 CNCF 毕业项目，基于 eBPF 实现高性能网络、安全与可观测性。
- eBPF 允许在内核安全运行沙箱程序，Cilium 利用 XDP、TC、kprobe 等挂载点实现数据面加速。
- Cilium 在 Kubernetes 中承担 CNI、网络策略引擎、可观测性数据源、服务网格数据平面等角色。
- 身份（Identity）驱动策略是 Cilium 的核心设计，解决了 IP 动态变化带来的策略管理难题。
- CiliumNetworkPolicy 支持 L7 协议过滤，比原生 NetworkPolicy 更精细、更高效。