2. Cilium基础回顾:架构、eBPF原理与核心组件

在深入多集群镜像拉取故障排查之前,必须先夯实Cilium的基础知识。Cilium是一个基于eBPF(extended Berkeley Packet Filter)的数据平面与网络策略引擎,它彻底改变了Kubernetes集群的网络、可观测性与安全模型。本节将系统回顾Cilium的架构、eBPF原理、核心组件及其与kube-proxy的关系。

2.1 Cilium整体架构

Cilium采用控制面与数据面分离的架构。控制面由Cilium Operator和Cilium Agent组成,负责策略下发与状态管理;数据面则完全运行在Linux内核的eBPF程序中,实现高性能的数据包转发与策略执行。

Cilium 整体架构图 Cilium 整体架构图 Kubernetes 集群 控制面 (Control Plane) Cilium Operator • 集群级策略管理 • 身份管理 (Identity) • 端点发现与同步 数据面 (Data Plane) Cilium Agent (每个节点) • 本地eBPF程序管理 • 网络策略执行 • 服务负载均衡 Linux 内核 eBPF 子系统 eBPF 程序挂载点 XDP (网卡层) TC (流量控制) CGroup (套接字) Tracepoint 说明:Cilium Agent 通过 gRPC 与 kube-apiserver 交互,并将策略编译为 eBPF 字节码注入内核。

2.2 eBPF原理与Cilium的关系

eBPF是Cilium的技术基石。它允许用户在Linux内核中安全地运行沙箱化程序,而无需修改内核源码或加载内核模块。Cilium利用eBPF实现网络数据包过滤、负载均衡、可观测性以及安全策略执行。

核心原理:eBPF程序通过 bpf() 系统调用加载到内核,经过验证器(Verifier)检查安全性后,由JIT编译器编译为原生机器码,挂载到指定的钩子点(如XDP、TC、套接字等)。Cilium Agent负责将Kubernetes资源(如NetworkPolicy、Service)转换为eBPF映射(Map)和程序。

特性 传统iptables/kube-proxy Cilium (eBPF)
数据包处理路径 用户态 → 内核态 (Netfilter) → 多个规则遍历 内核态直接执行eBPF程序,单次查找
策略更新性能 规则数量增加时性能线性下降 O(1) 哈希查找,规则数量无关
可观测性 需要额外工具(如tcpdump) 内置eBPF指标,通过Prometheus暴露
安全模型 基于IP和端口 基于容器身份(Label + Identity)

2.3 Cilium Agent与Operator组件

Cilium由两个主要控制面组件构成:Cilium Agent(DaemonSet)和Cilium Operator(Deployment)。它们分工明确,共同维护集群网络状态。

2.3.1 Cilium Agent

  • 部署方式:以DaemonSet运行在每个Kubernetes节点上。
  • 核心职责:
    • 监听kube-apiserver,获取Pod、Service、NetworkPolicy、EndpointSlice等资源变化。
    • 管理本地eBPF程序的生命周期(加载、更新、卸载)。
    • 维护本地eBPF映射(如策略映射、端点映射、服务映射)。
    • 处理节点间的网络封装(VXLAN/Geneve)或直接路由。
    • 暴露本地指标和健康检查接口。

2.3.2 Cilium Operator

  • 部署方式:以Deployment运行,通常副本数为1或2。
  • 核心职责:
    • 集群级身份管理(Identity Allocation):为每个端点分配唯一的安全身份。
    • 处理集群范围的网络策略冲突与依赖。
    • 管理CiliumNetworkPolicy和CiliumClusterwideNetworkPolicy的全局状态。
    • 可选:管理Service的负载均衡器IPAM(如MetalLB集成)。

排障提示:当遇到跨节点通信失败或策略不生效时,应首先检查 cilium status 命令的输出,确认Agent和Operator均处于健康状态。Operator故障会导致新Pod无法获取身份,从而被网络策略拒绝。

2.4 Cilium与kube-proxy的关系

Cilium可以完全替代kube-proxy,这是其核心优势之一。当启用 kubeProxyReplacement 功能时,Cilium会接管所有Service的负载均衡逻辑,不再依赖kube-proxy和iptables。

Cilium 替代 kube-proxy 对比图 Cilium 替代 kube-proxy 对比图 传统模式 (kube-proxy + iptables) Pod → Service ClusterIP Pod 发起请求 iptables DNAT conntrack 跟踪 后端 Pod 性能随规则数下降 Cilium 模式 (eBPF) Pod → Service ClusterIP Pod 发起请求 eBPF 直接查找 负载均衡 (BPF) 后端 Pod O(1) 性能,规则无关

关键配置:在Cilium安装时,如果集群中同时存在kube-proxy,必须设置 kubeProxyReplacement: strict 或 probe 模式,并确保kube-proxy已移除或禁用。否则会导致负载均衡规则冲突,造成Service访问异常。

2.5 关键概念总结

概念 说明 排障关注点
eBPF Map 内核中的键值存储,用于策略查找、端点映射 检查 cilium bpf map list 确认映射是否正常
Endpoint Cilium管理的网络端点(通常对应一个Pod) 使用 cilium endpoint list 查看端点状态
Identity 基于Label的安全身份,用于策略匹配 使用 cilium identity list 查看身份分配
NetworkPolicy Kubernetes原生网络策略,Cilium扩展支持L7 使用 cilium policy trace 模拟策略验证