Cilium 在 GKE 上的安装指南：默认配置、节点污点要求与 unmanaged Pod 处理-平芜编程栈

Cilium 在 GKE 上的安装指南：默认配置、节点污点要求与 unmanaged Pod 处理

【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium

本文以 Cilium 官方安装文档 Documentation/installation/requirements-gke.rst 为核心，系统讲解在 Google Kubernetes Engine（GKE）上部署 Cilium 的默认配置、集群创建时的节点污点（Taint）要求、污点机制在源码层的运作方式，以及安装前后对 unmanaged Pod 的处理。读完本文，你将能够在 GKE 上以 Direct Routing 数据路径正确创建集群并完成 Cilium 安装，同时理解node.cilium.io/agent-not-ready污点在保障“先有 Cilium、后有业务 Pod”这一顺序中的关键作用。

GKE 安装的默认配置

在 GKE 上安装 Cilium 时，默认使用以下三件套配置：

Datapath（数据路径）	IPAM	Datastore（数据存储）
Direct Routing（直接路由）	Kubernetes PodCIDR	Kubernetes CRD

Datapath：Direct Routing：数据包不经过隧道封装，直接基于 Pod 路由转发。这与 EKS 默认的 ENI 模式不同，也与 kind、minikube 等本地环境默认的 Tunnel（VXLAN）模式不同。Cilium CLI 会根据集群类型自动选择数据路径：在 cilium-cli/install/autodetect.go 的detectDatapathMode中，当检测到集群种类为KindGKE时，会将数据路径模式设置为DatapathGKE。
IPAM：Kubernetes PodCIDR：Pod IP 分配依赖 Kubernetes 节点的 PodCIDR 范围，而非额外的 IPAM 控制器（例如不依赖 GCP 的 Alias IP 管理）。
Datastore：Kubernetes CRD：所有状态（身份、端点、策略等）均存储在 Kubernetes 自定义资源（CRD）中，无需外部 etcd 或 KVStore。

此外，在 cilium-cli/install/helm.go 中可以看到，当数据路径为 GKE 模式时，安装器会自动设置gke.enabled=true与gke.disableDefaultSnat=true两个 Helm 值，用于关闭 GKE 环境下不必要的默认 SNAT 行为。Cilium CLI 还会尝试从 kubectl 上下文名（形如gke_PROJECT_ZONE_NAME）中解析出集群的 zone 与名称，并调用gcloud container clusters describe探测 GKE 原生路由 CIDR，相关实现见 cilium-cli/install/gke.go。

集群创建时的节点污点要求

官方安装要求中明确指出：

集群应使用--node-taints选项创建，并打上污点node.cilium.io/agent-not-ready=true:NoExecute。

推荐的最小创建命令如下（摘自 Documentation/gettingstarted/k8s-install-default.rst）：

export NAME="$(whoami)-$RANDOM" # 为节点池打上污点，确保只有当 Cilium 就绪后 # Pod 才会被调度/运行在该节点上（也可使用其他方案，见下文） gcloud container clusters create "${NAME}" \ --node-taints node.cilium.io/agent-not-ready=true:NoExecute \ --zone us-west2-a gcloud container clusters get-credentials "${NAME}" --zone us-west2-a

关于这条污点，需要理解以下要点：

污点格式为<key>=<value>:<effect>，其中 key 为node.cilium.io/agent-not-ready，value 为true，effect 为NoExecute。
污点的作用是：在 Cilium 尚未运行到某节点之前，阻止应用 Pod 被调度或执行到该节点上，从而避免应用 Pod 的网络由 GKE 预装的 CNI（如kubenet或gke-networking）接管，变成“unmanaged Pod”。
这里标注“还有其他方案”，指的是可以在不同场景下选择NoSchedule效果，或者完全改用安装后手动重启 unmanaged Pod 的方案。具体权衡请务必阅读文档 Documentation/installation/taints.rst。

为什么 GKE 尤其需要污点机制

Documentation/installation/taints.rst 中特别指出：GKE（非 Dataplane V2 场景）下，节点重启或升级时，云厂商会撤销 Cilium 对 CNI 配置的修改，重新恢复默认 CNI 配置。因此，如果 Pod 在 Cilium 启动之前运行，它们就会拿到预装 CNI 分配的 IP；只有通过节点污点先把业务 Pod “挡在门外”，等到 Cilium 在节点上就绪并移除污点后，Pod 才会开始调度，从而确保所有 Pod 的网络都由 Cilium 管理。

污点机制的工作原理（源码视角）

从源码看，负责维护该污点的是 Cilium Operator 的 node taint 同步逻辑，核心实现在 operator/watchers/node_taint.go，其工作流为：

集群管理员在创建集群/节点池时打上污点，业务 Pod（没有对应 toleration）无法被调度或执行。
Cilium Agent Pod 在节点上启动并完成初始化。Operator 通过ciliumPodsWatcher监听 Cilium Pod 事件（以k8s-app=cilium标签过滤），并把 Pod 所在节点名加入工作队列。
Operator 的 worker 处理节点：checkAndMarkNode调用nodeHasCiliumPod判断节点上是否存在已就绪的 Cilium Agent Pod。若 Pod 处于 Running 且 Ready 状态，则执行removeNodeTaint移除node.cilium.io/agent-not-ready污点，并通过setNodeNetworkUnavailableFalse把节点NodeNetworkUnavailable条件置为 False（Reason 为CiliumIsUp），允许 Pod 开始调度。
若 Cilium 暂时从节点上消失（Pod 已调度但未运行），Operator 会通过setNodeTaint重新打回该污点，此时 effect 固定为NoSchedule（源码中setNodeTaint使用slim_corev1.TaintEffectNoSchedule，见 operator/watchers/node_taint.go）。

相关开关（见 operator/watchers/node_taint_cell.go）默认值为：

参数	默认值	含义
`--taint-sync-workers`	`10`	处理节点污点的并发 worker 数量
`--remove-cilium-node-taints`	`true`	Cilium 正常运行后移除`node.cilium.io/agent-not-ready`污点
`--set-cilium-node-taints`	`false`	Cilium Pod 已调度但未运行时打回污点
`--set-cilium-is-up-condition`	`true`	设置`CiliumIsUp`节点条件（将`NodeNetworkUnavailable`置为 False）

这些参数同样可以通过 Helm values 或cilium install --set调整，详见各 Operator 命令参考（如 Documentation/cmdref/cilium-operator.md）。

自定义污点 key 的场景

默认污点 key 为node.cilium.io/agent-not-ready。某些场景下需要调整，例如使用 Cluster Autoscaler 但无法配置其相关 flags 时，建议将 key 改为以ignore-taint.cluster-autoscaler.kubernetes.io/开头，这样 Cluster Autoscaler 在模拟调度计算扩缩容时会忽略该污点，集群可以正常扩容。对应配置项为agent-not-ready-taint-key（见 Documentation/configuration/index.rst），Agent 侧对应命令行参数--agent-not-ready-taint-key（见 Documentation/cmdref/cilium-agent.md）。

NoExecute 与 NoSchedule：如何选择污点效果

这是安装要求中最需要决策的部分，官方文档给出如下权衡：

NoSchedule 效果：

效果：Pod 在 Cilium 移除污点之前不会被调度到该节点。
代价：如果外部过程（如节点重启）重置了该节点的 CNI 配置，那么节点下次重启时，之前已经调度到该节点的 Pod 会与 Cilium 同时启动，从而可能变成 unmanaged，由其他 CNI 管理其网络。

NoExecute 效果：

效果：Pod 在 Cilium 移除污点之前既不会被调度也不会被执行到该节点。
代价：一旦外部过程（升级或例行运维）把污点重新加回节点，已有 Pod 会被驱逐，直到 Cilium 再次移除污点，这可能引发短时应用中断。

还需考虑节点视角的问题：云厂商可能用同名的新实例/VM 替换底层节点（例如补丁或重置文件系统），节点池级别的污点会被重新加到 Node 资源上。此时若使用NoSchedule，之前已调度到该节点的 Pod 会与 Cilium 同时运行，可能变成 unmanaged；而NoExecute能保证这些已调度 Pod 不运行，因此官方推荐使用NoExecute，认为它是云厂商环境下破坏性最小的方案。

不过，若某些环境下节点池级污点会在 Cilium 移除后、且并非节点升级/重置的情况下被重新加回，NoExecute可能引发意外驱逐。官方建议：根据环境与云厂商文档，在“出现 unmanaged Pod（可能导致流量丢失等问题）”与“出现意外驱逐（可能导致应用停机）”之间谨慎权衡，甚至可以完全不用污点方案（此时安装后需手动重启已有 Pod，见下文）。

在 GKE 上安装 Cilium

创建好集群并打上污点后，即可安装 Cilium：

cilium install --version <版本号>

安装完成后检查状态：

cilium status

若安装失败，可通过cilium status查看整体部署状态，并检查异常 Pod 的日志。安装过程中你可能会看到类似输出：

♻️ Restarted unmanaged pod kube-system/event-exporter-gke-564fb97f9-rv8hg ♻️ Restarted unmanaged pod kube-system/kube-dns-6465f78586-hlcrz ♻️ Restarted unmanaged pod kube-system/l7-default-backend-7fd66b8b88-qqhh5 ♻️ Restarted unmanaged pod kube-system/metrics-server-v0.3.6-7b5cdbcbb8-kjl65

这表明你的集群在部署 Cilium 之前已存在一些 Pod，安装器已自动重启它们，以确保所有 Pod 的网络都由 Cilium 提供，且 NetworkPolicy 对其生效。

未打污点时的补救：重启 unmanaged Pod

如果你创建集群时没有打上node.cilium.io/agent-not-ready污点，那么安装 Cilium 后需要手动重启那些在 Cilium 部署之前就已运行的、且未使用 hostNetwork的 Pod，让 Cilium 接管其网络。官方推荐命令（见 Documentation/installation/k8s-install-restart-pods.rst）：

kubectl get pods --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOSTNETWORK:.spec.hostNetwork --no-headers=true | grep '<none>' | awk '{print "-n "$1" "$2}' | xargs -L 1 -r kubectl delete pod

执行后可以看到类似输出：

pod "event-exporter-v0.2.3-f9c896d75-cbvcz" deleted pod "fluentd-gcp-scaler-69d79984cb-nfwwk" deleted pod "heapster-v1.6.0-beta.1-56d5d5d87f-qw8pv" deleted pod "kube-dns-5f8689dbc9-2nzft" deleted pod "metrics-server-v0.3.1-54699c9cc8-7l5w2" deleted

注意：macOS 上的xargs可能不支持-r参数，此时可以去掉-r安全执行，但若没有可重启的 Pod，命令会挂起，可用ctrl-c终止。

扩展场景：GKE Clustermesh 准备

如果你计划在多 GKE 集群间搭建 Cilium Clustermesh，创建集群时同样需要打上节点污点以阻止 Pod 在 Cilium 安装前运行。以 Documentation/network/clustermesh/gke-clustermesh-prep.rst 中的示例为例，其创建命令使用--node-taints node.cilium.io/agent-not-ready=true:NoSchedule，并为每个集群分配独立的 Pod/Service CIDR：

gcloud container clusters create ${CLUSTER} \ --zone ${ZONE} \ --node-locations ${ZONE} \ --network=${VPC_NETWORK} \ --enable-ip-alias \ --cluster-ipv4-cidr=${POD_CIDR} \ --services-ipv4-cidr=${SERVICES_CIDR} \ --machine-type=e2-medium \ --max-nodes=1 \ --num-nodes=1 \ --node-taints node.cilium.io/agent-not-ready=true:NoSchedule \ --project ${PROJECT_ID}

随后为每个集群安装 Cilium 并指定唯一的cluster.id与cluster.name：

cilium install --version <版本号> \ --set cluster.id=1 \ --set cluster.name=${CLUSTER} cilium status

注意该场景示例使用的是NoSchedule效果，与单集群默认安装推荐的NoExecute不同——再次印证了污点效果需要结合具体环境权衡。

总结与核对清单

在 GKE 上部署 Cilium 的关键步骤可归纳为：

确认默认配置：Direct Routing + Kubernetes PodCIDR + Kubernetes CRD，Cilium CLI 会自动探测并应用。
创建集群时打污点：--node-taints node.cilium.io/agent-not-ready=true:NoExecute，优先推荐NoExecute；如受限于 Cluster Autoscaler 等场景，可自定义以ignore-taint.cluster-autoscaler.kubernetes.io/开头的 taint key。
安装并验证：执行cilium install --version <版本号>，随后cilium status确认节点污点被移除、NodeNetworkUnavailable条件置为 False。
处理未受管 Pod：若集群未打污点，安装后按本文命令重启非 hostNetwork 的存量 Pod，必要时也可直接参考 Cilium CLI 自动重启 unmanaged Pod 的提示输出。

相关文档与源码索引：GKE 安装要求、污点效果与 unmanaged Pod 详细说明、快速安装指南、重启 unmanaged Pod、污点同步源码、污点同步配置、GKE 数据路径自动探测。

【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考