把 Kubernetes 集群的网络底座从 kube-proxy 切换到 Cilium，本质是用 eBPF 程序直接接管 Pod 发包、收包以及 Service 负载均衡。这种方式不再依赖 iptables 规则链，避免了大规模集群中规则匹配带来的 CPU 开销。Cilium 通过挂载到内核钩子点的 eBPF 字节码，实现 L3/L4 乃至 L7 的访问控制，并把策略编译成高效的内核态判断逻辑。对于已经跑着业务的集群，做这种替换要评估兼容性、内核能力以及迁移窗口。
环境准备与内核能力核查
在动手部署之前，必须先确认节点内核版本与编译选项。Cilium 要求 Linux 内核至少在 4.19 以上，如果要使用完整 L7 策略与 Hubble 观测，建议 5.4 或更高。可以通过 uname -r 查看版本，并用 cilium prerequisites 命令或核对 /boot/config-$(uname -r) 中的 CONFIG_BPF、CONFIG_BPF_SYSCALL 是否开启。部分云厂商的定制内核可能精简了某些 eBPF 功能，需要提前在测试节点验证。
另一个容易被忽略的点是关闭节点上的冲突组件。如果集群原先使用 kube-proxy，Cilium 在 kube-proxy-free 模式下会自己实现 Service 转发，此时必须保证 kube-proxy 的 DaemonSet 被删除或停止，否则会出现规则双写。对于使用 Containerd 或 Docker 的节点，还要确认 CNI 配置目录（一般是 /etc/cni/net.d）中旧的插件文件被清理，避免 kubelet 依然调用旧网络插件。
存储与权限方面，Cilium 的 Agent 需要访问 Kubernetes API 并挂载 /sys/fs/bpf 文件系统。在 RHEL 系发行版上，可能还要调整 SELinux 策略，允许容器读写 bpf 类型文件系统。如果采用 Helm 部署，应提前创建独立的 cilium 命名空间，并为后续升级保留 values 文件，方便追溯每次变更的参数。
使用 Helm 完成基础部署
最稳妥的部署方式是使用官方 Helm Chart。先添加仓库并更新本地缓存，再准备一份 values 文件来声明关键参数。下面这段配置关闭了 kube-proxy 替换、启用了 Hubble 并选择了 VXLAN 隧道模式，适合跨子网且不支持直接路由的环境。
# values-cilium.yaml
kubeProxyReplacement: strict
k8sServiceHost: "192.168.0.1"
k8sServicePort: 6443
tunnel: vxlan
hubble:
enabled: true
relay:
enabled: true
ui:
enabled: true
ipam:
mode: cluster-pool
clusterPoolIPv4PodCIDR: 10.244.0.0/16
clusterPoolIPv4MaskSize: 24
执行安装时，用 helm install 指定上述文件即可。安装完成后，每个节点会起一个 cilium-agent 容器，它负责加载 eBPF 程序到内核，并监听 Kubernetes 的 Endpoint 与 Service 变化。可以通过 cilium status 命令观察代理状态，确认 BPF 文件系统挂载、节点间加密以及策略引擎是否就绪。
若集群原本有旧 CNI，迁移过程建议先排空节点再逐步替换，防止 Pod 网络瞬间中断。Cilium 提供了 cilium-cni 插件，kubelet 调用它后为新创建的 Pod 分配 IP 并写入 BPF 映射。此时用 kubectl get pods -n kube-system 能看到 Cilium 相关组件处于 Running，说明数据面已接管。
网络策略验证与性能对比
部署只是第一步，必须验证 eBPF 数据面是否真正生效。可以写一个拒绝所有流量的 CiliumNetworkPolicy，再部署两个测试 Pod，用 ping 或 curl 验证连通性被阻断；随后放开策略，确认通信恢复。相比原先的 NetworkPolicy 依赖 kube-proxy 与 iptables，Cilium 的策略直接在内核判断，规则变更无需重建规则链。
package main
import (
"fmt"
"os/exec"
)
func checkConnectivity(target string) bool {
cmd := exec.Command("ping", "-c", "1", target)
err := cmd.Run()
if err != nil {
fmt.Println(target, "unreachable")
return false
}
fmt.Println(target, "reachable")
return true
}
func main() {
checkConnectivity("10.244.1.5")
}
从性能角度看，在五千个 Service 的压测场景中，iptables 模式 kube-proxy 的转发延迟随规则数线性上升，而 Cilium 的 eBPF 映射查找复杂度接近 O(1)，P99 延迟更稳定。此外，Hubble 能导出每个请求的源目 IP、HTTP 方法等元数据，帮助排查微服务调用异常，这是传统 kube-proxy 方案难以低成本实现的。
运维上还要注意 Cilium 版本与 Kubernetes 版本的兼容矩阵。大版本升级前，应在离线环境先用相同参数部署模拟集群，跑通策略与 Service 网格流量。遇到 BPF 程序加载失败，多半是内核缺少某项特性，可临时调低 bpfClockProbe 相关开关或升级内核解决。整体而言，Cilium eBPF 方案将网络逻辑下沉到内核，既降低了开销，也打开了可观测与零信任策略的新空间。
KubernetesCiliumeBPF修改时间：2026-08-16 23:50:34