GKE Pod执行kubectl及运行chaos-mesh时报10.0.0.1:443 i/o timeout错误求助

故障特征 #

执行kubectl get pods或调用K8s API时抛出以下报错：

Unable to connect to the server: dial tcp 10.0.0.1:443: i/o timeout

Chaos Mesh控制器报错日志：

"error": "Get \"https://10.0.0.1:443/api?timeout=32s\": dial tcp 10.0.0.1:443: i/o timeout"
Failed to get API Group-Resources       {"error": "Get \"https://10.0.0.1:443/api?timeout=32s\": dial tcp 10.0.0.1:443: i/o timeout"}

• 同镜像同Deployment部署的2个Pod调度到不同节点，仅单节点上的Pod出现报错
• 报错地址10.0.0.1为GKE集群默认Kubernetes API服务的ClusterIP

排查与解决步骤 #

1. 定位故障节点 #

执行命令kubectl describe pod <故障Pod名称> -n <对应命名空间>，找到Node字段对应的节点IP/名称，确认所有报错Pod是否都调度到同一批异常节点上。

2. 排查节点防火墙与网络规则 #

• 对比正常节点和故障节点的VPC防火墙标签，确认故障节点是否缺少k8s.io/role/node标签，GKE默认要求工作节点持有该标签才能访问控制平面443端口
• 登录故障节点执行iptables-save | grep 10.0.0.1，确认没有自定义DROP规则拦截API服务访问流量
• 检查集群内NetworkPolicy配置，确认故障Pod所在命名空间没有限制访问kube-system命名空间443端口的规则

3. 排查kube-proxy运行状态 #

kube-proxy负责ClusterIP请求的转发，异常会直接导致API访问失败：

• 执行kubectl get pod -n kube-system | grep kube-proxy | grep <故障节点名称>，确认对应节点的kube-proxy Pod处于Running状态
• 若kube-proxy状态异常，直接删除异常Pod，DaemonSet会自动重建该Pod，重建后再次测试Pod内API访问状态

4. 排查Chaos Mesh残留规则 #

如果集群已部署Chaos Mesh，需确认是否存在未清理的故障注入规则：

• 执行kubectl get networkchaos -A查看所有活跃的网络故障规则，确认没有规则拦截了节点或Pod到API服务的流量
• 临时将Chaos Mesh控制器调度到正常节点，可快速恢复控制器服务

5. 故障节点重建 #

如果上述排查都未发现问题，直接执行节点重建操作：先cordon故障节点，驱逐节点上的所有业务Pod后删除故障节点，集群会自动创建新的工作节点，节点重建后配置会恢复默认状态，90%以上的节点层面网络问题都可以通过重建解决。

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