kubernetes中pod状态和排查思路

背景：在一个环境中，有一个app一直不终态（终态：指的就是应用服务各个组件达到提供服务的一种状态），结果一查发现，是一个pod状态不是running，通过查看事件排查最终解决。（我的排查思路先看pod的事件，然后再看pod的退出码一看是137，纳尼，这不就是OOM导致的，直接把资源拉满，走起，直接拿下这个问题）

kubernets中pod的状态包含如下若干种：

1. running 该状态说明pod已经调度到node上，且镜像拉取无误，已经启动。万事大吉，ojbk.
2. pending 这个状态很常见。一直pending，说明该pod一直未调度到节点上。引起的原因很多包含资源依赖、资源不足、该Pod使用了hostPort、污点和容忍等原因导致集群中缺乏需要的资源。
3. ImagePullBackOff这个状态不是很常见。一般是在集群部署阶段会出现，说明该pod已经被调度到节点上，是由于镜像拉取失败导致。可以查看镜像仓库和本地镜像是否存在该镜像。
4. CrashLoopBackOff这个状态说明pod中的应用程序有问题。Pod启动失败，反复重启。需要通过pod的事件、日志来进行排查。
5. Evicted这个状态我在企业中没见过，但还是说一下。引起的原因：当节点的内存、磁盘空间、文件系统的inode和操作系统可分配的PID等资源中的一个或者多个达到特定的消耗水平，就会引发kubelet主动地驱逐节点上一个或者多个Pod，以回收节点资源。
6. Terminating状态说明pod正处于关闭状态。
7. Completed状态说明容器中的启动命令已执行完毕，容器中的所有进程都已退出。

kubernetes中用pod的异常退出码来进行定位问题：

声明：看这篇文章的人都是对k8s有不同程度的了解。相信大家一定知道pod就是由一个或多个容器组成，那么pod的异常退出码便是容器的异常退出码，两者关系等同。列举几个常见的异常退出码：

退出码137：退出码 137 表示容器已收到来自主机操作系统的 SIGKILL 信号。这个太熟悉了，poc环境部署经常出现137使pod不终态。这个基本是由于分配给该pod的资源不足导致pod启动失败，调大资源即可。引发退出码为137的其他原因有一下几种：

• 当通过容器引擎杀死容器时触发，例如使用 docker kill 命令时；
• 由 Linux 用户向进程发送 kill -9 命令触发；
• 在尝试终止容器并等待 30 秒的宽限期后由 Kubernetes 触发（默认情况下）；
• 由主机自动触发，通常是由于内存不足。在这种情况下，docker inspect 命令将指示 OOMKilled 错误。

退出码127：容器中指定的命令引用了不存在的文件或目录。说白了就是找不到文件或目录。排查pod的yaml配置。确保pod中引用的文件名或文件路径真实有效。

退出码128：退出时使用的参数无效导致。排查思路：

• 检查容器日志以确定哪个库导致容器退出。
• 确定有问题的库在哪里使用了 exit 命令，并更正它以提供有效的退出代码。

退出码125：容器未运行。容器中的命令未运行，例如 docker run 在 shell 中被调用但没有成功执行。以下是可能发生这种情况的常见原因：

• 命令中使用了未定义的 flag，例如 docker run --abcd；
• 镜像中用户的定义命令在本机权限不足；
• 容器引擎与宿主机操作系统或硬件不兼容。

无论是那个工作负载不终态，都是k8s中最基本的单位pod不终态导致。通过排查pod的事件、日志、退出码、配置、监控、详情多方面来进行定位问题。同时组件间的关系我们也需要了解。