k8s中pod的状态管理

这篇文章来说一下k8s中pod的状态管理。 

在k8s当中，一个pod是一个调度单元。一个pod可以包含一个或者多个容器。每个容器可以是一个网络服务器前端，后端或者整个包含前后端的服务。 

接下来我们来看看一个pod的状态变化过程。

Pending

当我们创建一个pod的时候，它的第1个状态是Pending。这个状态是说k8s的API已经接受了你的pod请求。但是还没有真正的发起调度。

这个地方我们假设你有多台机器，也可能是多台虚拟机。调度器用来查找和申请不同的资源，比如说我们需要一个CPU加上2G的内存来使用一个pod。

Creating

找到这些资源以后，调度器会在某台机子上，为pod的创建做准备。此时pod的状态就会进入到creating。在这个状态下第1件事要做的就是把容器的镜像下载下来。如果在当前机子上已经有了这个镜像的话，这个过程可以跳过。

Running

镜像准备好以后，接下来的一个状态就是running。在这个状态下就会启动容器也就是启动你的应用程序，比如后端服务，等等。

CrashLoopBackOff

如果在运行的过程中发生了故障导致你的容器崩溃。这个时候k8s会重启这个容器。如果经常崩溃，启动的次数过多的话。这个pod就会进入CrashLoopBackOff状态。进入这个状态以后，k8s不会立即再次启动容器，而是会等一段时间，比如说10秒钟以后再重启。如果继续重启失败的话，就会等20秒以后，以此类推。

这个时候你可能需要研究一下，到底发生了什么事情，继而修复你的程序。

导致这种现象可能的情况有很多，比如说数据库没有准备好，某个依赖服务没有启动起来等等。

如果资源非常紧张调度器无法申请到的时候，我们会看到pod处于Pending的状态。

解决这种问题的一般措施如下:

1. 被动的等待资源释放。

2. 主动的释放资源。

3. 增加资源。

如果无法获取到容器对应的镜像，也会使一个pod的状态处于Pending。

检查pods状态的两个常用命令如下:

kubectl get pods

kubectl describe pods

Health和Ready

每个pod对应一个IP地址和端口，你可以用health和ready请求来检查它们是否运转正常。如果返回200类的状态码，说明一切正常，否则的话你可以手工重启或者修复问题。

其他需要关注的pod的状态：

post start

post start, 这是当你的容器启动以后要触发的状态。

pre stop

另一个状态是pre stop，描述的是在你的容器要终止之前要触发的状态。

容器初始化

在pod中可以定义容器初始化过程。一般的情况用在某个容器需要做一些初始化的工作，然后才启动其他的容器。

这样的案例，比如说需要做数据库的迁移更新，文件的下载等等相对比较耗时而又必须的工作。