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

一，文章简述

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

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

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

二，Pod 状态

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

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

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

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

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

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

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

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

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

不过话又说回来，Pod 的状态和 Node 状态是一回事吗？嗯。。。其实并不完全是一回事。

但是当容器服