kubectl exec失败的根本原因是API Server与Node kubelet通信中断，需检查kubelet状态、10250端口监听、双向网络连通性、证书有效期、节点Ready状态及节点IP配置是否正确。
这个错误说明 kubectl exec 请求无法成功连接到目标 Pod 所在节点的 kubelet，根本原因不在 Pod 本身，而在于控制平面与工作节点之间的通信链路中断或异常。
检查 kubelet 是否正常运行
登录对应 Node 节点（可通过 kubectl get nodes -o wide 查看 Pod 所在节点），执行：
-
systemctl status kubelet—— 确认服务处于active (running) -
journalctl -u kubelet -n 50 --no-pager—— 查看最近日志，重点关注 TLS、证书、端口绑定（默认 10250）相关报错 -
ss -tlnp | grep :10250或netstat -tlnp | grep :10250—— 确认 kubelet 正在监听 10250 端口且未被防火墙拦截
验证 API Server 与 kubelet 的双向连通性
API Server 需要能从控制平面网络访问 Node 的 kubelet HTTPS 端口（通常是 10250），同时 kubelet 也要能反向连接 API Server（通常 6443）：
- 在 master 节点上执行：
curl -k https://<node-ip>:10250/healthz</node-ip>—— 应返回ok；若超时或拒绝连接，检查网络策略、安全组、iptables/firewalld 规则 - 在 Node 上执行：
curl -k https://<api-server-ip>:6443/healthz</api-server-ip>—— 确保 kubelet 能访问 API Server - 注意：若集群启用了 kubelet TLS 引导（TLS bootstrap），证书可能过期，需检查
/var/lib/kubelet/pki/下的kubelet-client-current.pem和kubelet-server-current.pem有效期
确认 Pod 网络和 CNI 插件状态
虽然该错误不直接由 CNI 导致，但部分 CNI（如 Calico、Cilium）异常可能间接影响节点健康状态上报，导致 API Server 认为节点 NotReady，进而拒绝 exec 请求：
-
kubectl get nodes—— 查看对应节点是否为Ready状态；若为NotReady，进一步查kubectl describe node <node-name></node-name>中的 Events 和 Conditions -
kubectl get pods -n kube-system | grep -E "(calico|cilium|flannel)"—— 确保 CNI 相关 Pod 全部 Running - 检查 CNI 插件日志，例如：
kubectl logs -n kube-system <calico-node-pod></calico-node-pod>
排查 kube-apiserver 到 kubelet 的代理路径
当使用 kubectl exec 时，请求路径是：kubectl → apiserver → kubelet。apiserver 通过节点的 InternalIP 或 ExternalIP 去 dial kubelet。若节点 IP 地址配置错误，也会触发此错误：
-
kubectl get node <node-name> -o wide</node-name>—— 检查INTERNAL-IP是否正确可达（比如是否是 docker0 或内网不可路由地址） - 查看节点对象中
addresses字段：kubectl get node <node-name> -o jsonpath='{.status.addresses}'</node-name>，确保至少有一个InternalIP可被 master 访问 - 必要时可手动修正：编辑节点对象，或通过 kubelet 启动参数
--node-ip显式指定监听和上报的 IP
