K8S线上集群排查，实测排查Node节点NotReady异常状态

一，文章简述

大家好，本篇是关于在之前项目中，k8s 线上集群中 Node 节点状态变成 NotReady 状态，导致整个 Node 节点中容器停止服务后的问题排查。

文章中所描述的是本人在项目中线上环境实际解决的，那除了如何解决该问题，更重要的是如何去排查这个问题的起因。

关于 Node 节点不可用的 NotReady 状态，当时也是花了挺久的时间去排查的。

二，Pod 状态

在分析 NotReady 状态之前，我们首先需要了解在 k8s 中 Pod 的状态都有哪些。并且每个状态都表示什么含义，不同状态是很直观的显示出当前 Pod 所处的创建信息。

为了避免大家对 Node 和 Pod 的概念混淆，先简单描述下两者之间的关系(引用一张 K8S 官方图)。

image

从图中很直观的显示出最外面就是 Node 节点，而一个 Node 节点中是可以运行多个 Pod 容器，再深入一层就是每个 Pod 容器可以运行多个实例 App 容器。

因此关于本篇文章所阐述的 Node 节点不可用，就会直接导致 Node 节点中所有的容器不可用。

毫无疑问，Node 节点是否健康，直接影响该节点下所有的实例容器的健康状态，直至影响整个 K8S 集群。

那么如何解决并排查 Node 节点的健康状态？不急，我们先来聊聊关于关于 Pod 的生命周期状态。

image

• Pending：该阶段表示已经被 Kubernetes 所接受，但是容器还没有被创建，正在被 kube 进行资源调度。
• 1：图中数字 1 是表示在被 kube 资源调度成功后，开始进行容器的创建，但是在这个阶段是会出现容器创建失败的现象
• Waiting或ContainerCreating：这两个原因就在于容器创建过程中镜像拉取失败，或者网络错误容器的状态就会发生转变。
• Running：该阶段表示容器已经正常运行。
• Failed：Pod 中的容器是以非 0 状态(非正常)状态退出的。
• 2：阶段 2 可能出现的状态为CrashLoopBackOff，表示容器正常启动但是存在异常退出。
• Succeeded：Pod 容器成功终止，并且不会再在重启。

上面的状态只是 Pod 生命周期中比较常见的状态，还有一些状态没有列举出来。

这。。。状态有点多。休息 3 秒钟

image

不过话又说回来&