GKE集群中kube-proxy Pod卡在Init:0/1状态的问题咨询

碰到过不少GKE环境下kube-proxy卡在Init阶段的情况，结合你说的集群整体暂时正常的场景，我来帮你拆解下这个问题的影响、可能成因和具体解决步骤：

一、这个状态会带来什么影响？ #

目前集群整体正常，说明当前节点上的现有服务流量还没依赖这个未启动的kube-proxy，但长期来看存在这些风险：

• 该节点上新部署的Service无法正常完成流量转发，因为kube-proxy负责维护节点上的iptables/IPVS规则
• 现有Service的规则更新（比如后端Pod地址变更）不会同步到这个节点，可能导致部分流量异常
• 如果另一节点出现故障，流量切换到这个节点时会直接中断
• GKE的集群健康监控后续可能触发告警，甚至影响节点的调度优先级

二、可能的成因有哪些？ #

kube-proxy的Init容器卡住，常见原因集中在这几个方面：

• 镜像拉取失败：GCR的kube-proxy镜像无法正常拉取，可能是节点网络不通、GCR访问受限，或者节点的服务账号没有镜像拉取权限
• 节点资源不足：Init容器需要的CPU/内存被节点上其他Pod占用殆尽，导致无法启动
• 节点网络配置冲突：节点上的iptables规则存在冲突，或者kube-proxy需要的宿主机端口被其他进程占用
• kubelet状态异常：节点上的kubelet服务未正常运行，无法调度和执行Init容器
• 集群版本兼容性问题：最近做过集群升级，kube-proxy的版本与集群K8s版本不匹配，初始化逻辑出错

三、排查与解决步骤 #

1. 查看Init容器的日志（最关键） #

之前describe没拿到有效信息，直接看Init容器的日志才能定位根因：
首先通过kubectl describe pod kube-proxy-gke-app-... -n kube-system找到Init容器的名称（比如init-networking），然后执行：

kubectl logs kube-proxy-gke-app-... -n kube-system -c <init-container-name>

日志里通常会直接提示是镜像拉取失败、资源不足还是配置错误。

2. 检查节点资源状态 #

执行以下命令查看节点的资源使用情况：

kubectl describe node <node-name>

重点看Allocatable和Used部分的CPU、内存指标，如果资源已接近耗尽，需要清理节点上的无用Pod，或者考虑扩容集群节点。

3. 验证镜像拉取是否正常 #

如果日志提示镜像拉取失败，可以登录到该节点（通过gcloud compute ssh <node-name>），手动尝试拉取kube-proxy镜像：

docker pull gcr.io/google-containers/kube-proxy:v<your-cluster-version>

如果拉取失败，检查节点网络是否能访问GCR，或者确认节点的服务账号拥有roles/container.nodeServiceAgent权限（GKE默认应该有，但可能被误修改）。

4. 检查节点网络与kubelet状态 #

• 登录节点后，查看iptables规则是否有冲突：

  iptables-save | grep kube-proxy
  

  如果存在异常规则，可以尝试临时清理（但GKE节点不建议手动修改iptables，优先重启kube-proxy）。
• 检查kubelet服务状态：

  sudo systemctl status kubelet
  

  如果kubelet未正常运行，执行sudo systemctl restart kubelet重启服务。

5. 重建异常的kube-proxy Pod #

如果以上步骤都没解决问题，可以直接删除这个异常Pod，GKE的kube-proxy是DaemonSet，删除后会自动在节点上重建：

kubectl delete pod kube-proxy-gke-app-... -n kube-system

6. 检查集群版本兼容性 #

确认kube-proxy的镜像版本与集群K8s版本一致：

kubectl version --short

然后对比kube-proxy Pod的镜像标签，如果版本不匹配，可能是集群升级后未同步，可以手动触发DaemonSet滚动更新：

kubectl rollout restart daemonset kube-proxy -n kube-system

内容的提问来源于stack exchange，提问作者Ben