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

4. Cilium安装与集群部署

Cilium 的部署质量直接决定了后续网络策略、可观测性和服务负载均衡能否稳定工作。与简单的“装一个 CNI 插件”不同，Cilium 的安装涉及三个关键决策：用 Helm 管理哪些参数、是否替换 kube-proxy、以及选择哪种 IPAM 模式。这三者相互关联，选错任何一个都可能导致集群网络异常或性能不达预期。本节围绕这三个决策展开，并给出生产环境的配置建议。

一、Helm 安装：参数化管理的正确姿势

Cilium 官方推荐使用 Helm 安装，因为它的参数体系庞大，直接 apply 一个 YAML 很难维护。安装前先添加仓库并确认版本：

helm repo add cilium https://helm.cilium.io/
helm repo update
helm search repo cilium/cilium --versions | head -5

生产环境不建议使用 --set 堆叠大量参数，而是把配置写入 values 文件，便于版本管理和审计。一个最小可用的安装命令如下：

helm install cilium cilium/cilium \
  --namespace kube-system \
  --version 1.16.3 \
  --values cilium-values.yaml

安装后需要验证三个层面：Pod 是否全部 Running、Cilium 自身状态是否健康、以及节点间连通性是否正常。

kubectl -n kube-system get pods -l k8s-app=cilium
kubectl -n kube-system exec ds/cilium -- cilium status --brief
kubectl -n kube-system exec ds/cilium -- cilium-health status

cilium status 会输出 Cilium、Hubble、IPAM、kube-proxy 替换等子系统的状态。如果 IPAM 显示 “OK” 且各节点 health 可达，说明基础网络已经就绪。

二、kube-proxy 替换模式：性能与复杂度的权衡

默认情况下，Cilium 与 kube-proxy 共存，Service 的负载均衡由 kube-proxy 通过 iptables/IPVS 完成。Cilium 提供了 kubeProxyReplacement 参数，用 eBPF 程序在 socket 层和网卡层直接完成 Service 转发，绕过 iptables 链，从而降低延迟、提升吞吐，并支持 DSR（Direct Server Return）等高级特性。

该参数有三个取值：disabled（默认，与 kube-proxy 共存）、partial（部分替换，保留 kube-proxy 处理 NodePort 等）、strict（完全替换，需移除 kube-proxy）。生产环境若追求性能且能接受运维复杂度，推荐 strict；若集群中已有依赖 kube-proxy 的组件或需要平滑迁移，可先用 partial。

选择 strict 时，必须在安装前删除 kube-proxy，否则两者会争抢 Service 规则。典型操作是：

kubectl -n kube-system delete ds kube-proxy
kubectl -n kube-system delete cm kube-proxy
# 清理节点上的 iptables 残留规则（可选但推荐）
iptables-save | grep -v KUBE | iptables-restore

对应的 values 配置为：

kubeProxyReplacement: strict
k8sServiceHost: 10.0.0.10      # API Server 地址
k8sServicePort: 6443
# 若使用 DSR 提升回程性能
loadBalancer:
  mode: dsr

注意 k8sServiceHost 和 k8sServicePort 必须显式指定，因为 kube-proxy 被移除后，Cilium 需要直接访问 API Server 来同步 Service 信息。如果这两个参数填错，Cilium Agent 会无法启动。

三、IPAM 模式选择：地址从哪来

IPAM（IP Address Management）决定 Pod IP 如何分配。Cilium 支持多种模式，生产环境最常用的是 cluster-pool 和 kubernetes 两种。

cluster-pool 模式由 Cilium 自己管理 IP 池，每个节点从集群级 CIDR 中划分一个子网。它的优点是地址规划清晰、不依赖云厂商，适合自建集群或混合云。配置示例：

ipam:
  mode: cluster-pool
  operator:
    clusterPoolIPv4PodCIDRList: ["10.244.0.0/16"]
    clusterPoolIPv4MaskSize: 24

这里 /16 是集群总池，/24 是每节点子网，意味着最多支持 256 个节点、每节点 254 个 Pod。如果节点数超过 256，需要扩大总池或减小 mask size。

kubernetes 模式则复用 Kubernetes 的 PodCIDR 分配（由 controller-manager 分配），Cilium 只负责从节点已分配的 CIDR 中取地址。它适合已经依赖 kube-controller-manager 分配 PodCIDR 的集群，或云托管 Kubernetes 场景。配置为：

ipam:
  mode: kubernetes

两种模式的选择依据可以归纳为：自建集群、需要精细控制地址规划 → cluster-pool；托管集群、已有 PodCIDR 分配机制 → kubernetes。若使用云厂商 ENI 模式（如 AWS），则还有 eni 模式，但那是另一套体系。

四、生产环境配置要点

把上述决策组合起来，一个面向生产、使用 strict 替换和 cluster-pool IPAM 的 values 文件大致如下：

# cilium-values.yaml
kubeProxyReplacement: strict
k8sServiceHost: 10.0.0.10
k8sServicePort: 6443

ipam:
  mode: cluster-pool
  operator:
    clusterPoolIPv4PodCIDRList: ["10.244.0.0/16"]
    clusterPoolIPv4MaskSize: 24

# 启用 Hubble 可观测性
hubble:
  enabled: true
  relay:
    enabled: true
  ui:
    enabled: true

# 资源限制，避免 Agent 被驱逐
resources:
  requests:
    cpu: 100m
    memory: 256Mi
  limits:
    memory: 512Mi

# 开启带宽管理（可选）
bandwidthManager:
  enabled: true

# 启用 BBR 拥塞控制（可选）
bpf:
  hostLegacyRouting: false

安装后按以下顺序验证：先看 Pod 状态，再看 cilium status 中 kube-proxy replacement 是否显示 “True”，然后检查 IPAM 是否正常分配，最后用两个跨节点 Pod 互 ping 并访问一个 ClusterIP Service，确认转发路径生效。

生产建议：升级 Cilium 时使用 helm upgrade 并保留 --reuse-values 或完整 values 文件，避免参数丢失。大版本升级前先在测试集群验证 kube-proxy 替换和 IPAM 的兼容性，因为这两项一旦出错，恢复成本较高。

常见坑：选择 strict 后忘记删除 kube-proxy，会导致 Service 规则冲突，表现为部分 Service 无法访问或间歇性超时。另外，k8sServiceHost 若填了 VIP 而非真实 API Server 地址，在 API Server 故障切换时 Cilium 可能失联。

总结来说，Helm 负责把配置固化下来，kube-proxy 替换决定转发性能，IPAM 决定地址来源。三者需要在安装前统一规划，安装后通过 cilium status 和实际连通性测试逐项确认，才能保证集群网络在生产环境中稳定运行。