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 EngineGKE上部署 Cilium 的默认配置、集群创建时的节点污点Taint要求、污点机制在源码层的运作方式以及安装前后对 unmanaged Pod 的处理。读完本文你将能够在 GKE 上以 Direct Routing 数据路径正确创建集群并完成 Cilium 安装同时理解node.cilium.io/agent-not-ready污点在保障“先有 Cilium、后有业务 Pod”这一顺序中的关键作用。GKE 安装的默认配置在 GKE 上安装 Cilium 时默认使用以下三件套配置Datapath数据路径IPAMDatastore数据存储Direct Routing直接路由Kubernetes PodCIDRKubernetes CRDDatapathDirect Routing数据包不经过隧道封装直接基于 Pod 路由转发。这与 EKS 默认的 ENI 模式不同也与 kind、minikube 等本地环境默认的 TunnelVXLAN模式不同。Cilium CLI 会根据集群类型自动选择数据路径在 cilium-cli/install/autodetect.go 的detectDatapathMode中当检测到集群种类为KindGKE时会将数据路径模式设置为DatapathGKE。IPAMKubernetes PodCIDRPod IP 分配依赖 Kubernetes 节点的 PodCIDR 范围而非额外的 IPAM 控制器例如不依赖 GCP 的 Alias IP 管理。DatastoreKubernetes CRD所有状态身份、端点、策略等均存储在 Kubernetes 自定义资源CRD中无需外部 etcd 或 KVStore。此外在 cilium-cli/install/helm.go 中可以看到当数据路径为 GKE 模式时安装器会自动设置gke.enabledtrue与gke.disableDefaultSnattrue两个 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-readytrue:NoExecute。推荐的最小创建命令如下摘自 Documentation/gettingstarted/k8s-install-default.rstexport NAME$(whoami)-$RANDOM # 为节点池打上污点确保只有当 Cilium 就绪后 # Pod 才会被调度/运行在该节点上也可使用其他方案见下文 gcloud container clusters create ${NAME} \ --node-taints node.cilium.io/agent-not-readytrue:NoExecute \ --zone us-west2-a gcloud container clusters get-credentials ${NAME} --zone us-west2-a关于这条污点需要理解以下要点污点格式为keyvalue:effect其中 key 为node.cilium.io/agent-not-readyvalue 为trueeffect 为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-appcilium标签过滤并把 Pod 所在节点名加入工作队列。Operator 的 worker 处理节点checkAndMarkNode调用nodeHasCiliumPod判断节点上是否存在已就绪的 Cilium Agent Pod。若 Pod 处于 Running 且 Ready 状态则执行removeNodeTaint移除node.cilium.io/agent-not-ready污点并通过setNodeNetworkUnavailableFalse把节点NodeNetworkUnavailable条件置为 FalseReason 为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-workers10处理节点污点的并发 worker 数量--remove-cilium-node-taintstrueCilium 正常运行后移除node.cilium.io/agent-not-ready污点--set-cilium-node-taintsfalseCilium Pod 已调度但未运行时打回污点--set-cilium-is-up-conditiontrue设置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.rstAgent 侧对应命令行参数--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创建好集群并打上污点后即可安装 Ciliumcilium 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.rstkubectl get pods --all-namespaces -o custom-columnsNAMESPACE:.metadata.namespace,NAME:.metadata.name,HOSTNETWORK:.spec.hostNetwork --no-headerstrue | 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-readytrue:NoSchedule并为每个集群分配独立的 Pod/Service CIDRgcloud 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-typee2-medium \ --max-nodes1 \ --num-nodes1 \ --node-taints node.cilium.io/agent-not-readytrue:NoSchedule \ --project ${PROJECT_ID}随后为每个集群安装 Cilium 并指定唯一的cluster.id与cluster.namecilium install --version 版本号 \ --set cluster.id1 \ --set cluster.name${CLUSTER} cilium status注意该场景示例使用的是NoSchedule效果与单集群默认安装推荐的NoExecute不同——再次印证了污点效果需要结合具体环境权衡。总结与核对清单在 GKE 上部署 Cilium 的关键步骤可归纳为确认默认配置Direct Routing Kubernetes PodCIDR Kubernetes CRDCilium CLI 会自动探测并应用。创建集群时打污点--node-taints node.cilium.io/agent-not-readytrue: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），仅供参考