服务器K8s集群神舟通用排错：从日志到修复的完整操作流程
K8s集群在神舟通用服务器上出现异常时，先不要急着重装。
多数故障可以通过 kubectl get nodes、kubectl describe pod 和 journalctl -u kubelet 三条线索定位到具体节点或组件。
本文按“查状态→看日志→修配置→验证恢复”的顺序展开，适用于使用 kubeadm 部署的 Kubernetes 集群，节点操作系统为常见 Linux 发行版。
先确认故障范围
登录到任意 Master 节点，执行以下命令查看集群整体状态：
kubectl get nodes -o wide
kubectl get pods -A | grep -v Running如果节点状态显示 NotReady，问题通常出在 kubelet、容器运行时或网络插件。
如果节点是 Ready 但 Pod 反复重启，优先看 Pod 事件和容器日志。
关键判断点：
- 只有一个节点异常：先查该节点的 kubelet 和磁盘、内存。
- 多个节点同时异常：检查网络插件 DaemonSet 是否正常，以及 Master 的 apiserver 是否可达。
- 所有 Pod 都异常：优先检查 CoreDNS 和 kube-proxy。
节点NotReady的排查步骤
以故障节点 IP 为 192.168.1.20 为例，SSH 登录后按顺序执行：
systemctl status kubelet
journalctl -u kubelet -n 100 --no-pager常见原因和对应处理：
- 容器运行时未启动：如果日志提示
failed to run Kubelet: cannot create CRI client，检查 containerd 或 docker 状态：
systemctl status containerd
systemctl restart containerd
systemctl restart kubelet- 磁盘压力：节点磁盘使用率超过 85% 时，kubelet 会标记
DiskPressure。清理无用镜像：
docker system prune -a
# 或 containerd 环境
crictl rmi --prune- 证书过期：kubeadm 集群默认证书有效期一年。检查：
kubeadm certs check-expiration如果过期，使用 kubeadm certs renew all 续期后重启 kubelet。
- 网络插件未就绪：执行
kubectl get pods -n kube-system，若 calico 或 flannel 的 Pod 不在 Running，先修复网络插件。
Pod启动失败的定位方法
Pod 一直 Pending 或 CrashLoopBackOff 时，用以下命令逐层排查：
kubectl describe pod -n <命名空间>
kubectl logs -n <命名空间> --previous Pending 常见原因：
- 节点资源不足：
kubectl describe node <节点名>查看 Allocatable 和 Requests 差值。 - 污点未容忍：检查节点是否有
NoSchedule污点，以及 Pod 是否配置 tolerations。 - PVC 未绑定：
kubectl get pvc -n <命名空间>确认存储卷状态。
CrashLoopBackOff 常见原因：
- 启动命令错误：对比 Dockerfile 的 ENTRYPOINT 和 Pod 的 command。
- 配置文件缺失：用
kubectl exec进入容器检查挂载路径。 - 依赖服务不可达：在容器内执行
curl或nc测试下游地址。
网络不通的检查顺序
神舟通用服务器如果有多网卡，容易出现 Pod 网段和主机网段冲突。
按以下顺序检查：
- 确认 Pod CIDR 和节点物理网段不重叠。查看：
kubectl cluster-info dump | grep -i cluster-cidr
ip route show- 检查 kube-proxy 模式。iptables 模式下规则过多会导致转发延迟：
kubectl logs -n kube-system
iptables -t nat -L KUBE-SERVICES -n | head -20 - 测试跨节点 Pod 通信。在节点 A 的 Pod 内执行：
kubectl exec -it -- ping 如果不通，检查 calico 的 BGP 邻居或 flannel 的 VXLAN 接口：
kubectl get bgpconfiguration -A
ip link show flannel.1避坑要点
- 不要直接删除节点上的 /var/lib/kubelet：会导致该节点所有 Pod 元数据丢失，恢复需要重新加入集群。
- 重启 kubelet 前先确认容器运行时正常：否则 kubelet 会反复重启失败，日志刷屏掩盖真实原因。
- 修改集群 CIDR 必须重建集群：Pod 网段和 Service 网段在初始化后不可更改，规划时就要避开物理网络。
- 神舟通用服务器若启用了安全加固：检查 SELinux 和 firewalld 是否拦截了 kubelet 端口 10250 和 etcd 端口 2379。
修复后的验证清单
完成修复后，依次执行以下命令确认集群恢复：
kubectl get nodes
kubectl get pods -A
kubectl run test-pod --image=busybox --restart=Never -- sleep 3600
kubectl exec test-pod -- nslookup kubernetes.default
kubectl delete pod test-pod节点全部 Ready、系统 Pod 全部 Running、DNS 解析正常、测试 Pod 能正常创建和删除，说明集群已恢复基本可用状态。
如果仍有业务 Pod 异常，再回到对应命名空间单独排查。
常见疑问
节点 NotReady 但 kubelet 日志没有明显报错，怎么办？
检查 kubectl describe node 中的 Conditions 部分，看是 MemoryPressure、DiskPressure 还是 NetworkUnavailable。不同压力类型对应的处理方式不同。
Pod 能启动但服务访问不了，优先查什么？
先确认 Service 的 Endpoints 是否有值：kubectl get endpoints 。如果为空，说明 Pod 的 readinessProbe 未通过或标签选择器不匹配。
神舟通用环境下网络插件选哪个？
如果节点数量少且网络简单，flannel 的 VXLAN 模式配置最少。如果需要 NetworkPolicy 或 BGP 路由，选 calico。具体选择取决于集群规模和网络团队的管理习惯，没有统一答案。
