📚 课程目录第4章 Cilium安装与部署

4. Cilium安装与部署：使用Helm安装Cilium、配置kube-proxy替代、验证eBPF数据路径

本章聚焦于在生产级Kubernetes集群中部署Cilium的核心步骤。我们将使用Helm作为包管理工具，完成Cilium的安装、配置kube-proxy替代模式，并最终验证eBPF数据路径是否正常工作。正确的部署是后续蓝绿发布网络性能调优的基础。

4.1 环境准备与Helm仓库配置

在安装Cilium之前，请确保你的Kubernetes集群满足以下最低要求，并已配置好Helm客户端。

组件	最低版本要求	说明
Kubernetes	v1.21+	支持EndpointSlice和核心eBPF特性
Linux Kernel	5.10+	确保eBPF程序稳定运行，推荐5.15+
Helm	v3.8+	用于管理Cilium的Chart包
etcd	v3.4+	集群状态存储，Cilium依赖其进行KVStore操作

内核版本检查： 在集群所有节点上执行 uname -r 确认内核版本。如果低于5.10，建议先升级内核，否则eBPF数据路径可能回退到标准Linux网络路径，导致性能优势无法发挥。

首先，添加Cilium的官方Helm仓库并更新索引：

helm repo add cilium https://helm.cilium.io/
helm repo update

4.2 使用Helm安装Cilium

安装Cilium时，我们需要通过Helm values文件或命令行参数来定义关键配置。以下是一个针对kube-proxy替代场景的典型安装命令：

helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=6443 \
  --set ipam.mode=kubernetes \
  --set devices='{eth0}' \
  --set routingMode=native \
  --set autoDirectNodeRoutes=true \
  --set bpf.masquerade=true

    关键参数解析：
    kubeProxyReplacement=true：启用完全kube-proxy替代模式，Cilium将接管Service负载均衡。
routingMode=native：使用原生路由模式，绕过iptables，直接通过eBPF转发。
bpf.masquerade=true：使用eBPF进行SNAT（源地址转换），避免依赖iptables的MASQUERADE规则。
autoDirectNodeRoutes=true：自动为Pod CIDR添加节点路由，优化跨节点通信。

安装完成后，检查Cilium Pod是否全部处于Running状态：

kubectl -n kube-system get pods -l k8s-app=cilium
NAME               READY   STATUS    RESTARTS   AGE
cilium-xxxxx       1/1     Running   0          2m
cilium-yyyyy       1/1     Running   0          2m

4.3 配置kube-proxy替代

kube-proxy替代是Cilium的核心能力之一。它通过eBPF程序直接在数据路径上处理Service流量，消除了iptables规则链带来的性能损耗。配置完成后，需要验证kube-proxy是否已被完全禁用。

首先，检查集群中是否还存在kube-proxy Pod：

kubectl -n kube-system get pods -l k8s-app=kube-proxy

如果返回为空，说明kube-proxy已被移除或未部署。接下来，验证Cilium的kube-proxy替代状态：

kubectl -n kube-system exec ds/cilium -- cilium status | grep KubeProxyReplacement
KubeProxyReplacement:   Strict   [eth0  10.0.0.0/8]

输出中的Strict表示Cilium正在严格模式下运行，完全替代了kube-proxy的功能。

注意事项： 如果集群中原本部署了kube-proxy，在启用Cilium的kube-proxy替代后，务必删除kube-proxy DaemonSet，避免两者冲突导致Service规则混乱。删除命令：kubectl -n kube-system delete ds kube-proxy。

4.4 验证eBPF数据路径

验证eBPF数据路径是确保Cilium正常工作、网络性能达到预期的关键步骤。我们将通过Cilium CLI工具和实际流量测试来确认。

4.4.1 使用Cilium CLI检查eBPF状态

进入任意Cilium Pod，执行状态检查命令：

kubectl -n kube-system exec -it ds/cilium -- cilium status --verbose

重点关注以下输出指标：

指标项	期望值	含义
BPF Masquerade	Enabled	eBPF SNAT已启用，无需iptables
BPF NodePort	Enabled	NodePort服务由eBPF直接处理
BPF Host Routing	Enabled	主机路由通过eBPF加速
KubeProxyReplacement	Strict	严格替代模式，无回退

4.4.2 验证eBPF数据路径的流量走向

下图展示了启用kube-proxy替代后，Pod到Service的流量如何通过eBPF数据路径转发：

4.4.3 端到端连通性测试

使用Cilium内置的连通性测试工具，验证eBPF数据路径下的网络功能：

kubectl -n kube-system exec ds/cilium -- cilium connectivity test

该测试会创建临时Pod，执行Pod-to-Pod、Pod-to-Service、Pod-to-External等多种场景的连通性检查。如果所有测试通过，说明eBPF数据路径已成功部署并正常工作。

快速验证： 你也可以手动创建一个nginx Deployment和Service，然后从集群内另一个Pod通过Service ClusterIP访问，观察响应是否正常。使用 kubectl run test --image=busybox -- wget -O- http://<SERVICE_IP> 即可。

4.5 部署后检查清单

完成安装和验证后，建议对照以下清单进行最终确认：

Pod状态： 所有Cilium Pod处于Running状态，且READY列为1/1。
kube-proxy替代： cilium status 显示KubeProxyReplacement为Strict。
eBPF特性： BPF Masquerade、BPF NodePort、BPF Host Routing均为Enabled。
连通性： cilium connectivity test 全部通过，无失败项。
资源消耗： Cilium Agent的CPU和内存使用在合理范围内（通常CPU<1核，内存<500MB）。

至此，Cilium已成功部署并运行在eBPF数据路径上，为后续的蓝绿发布网络性能调优奠定了坚实的基础。