我们一般将pod对象从创建至终这段时间范围成为pod的生命周期，它主要包含以下的过程：
-
pod创建过程
-
运行初始化容器（init container）过程
-
运行主容器（main container）
---->容器启动后钩子（post start）、容器终止前钩子（pre stop）
---->容器的存活性检测（liveness probe）、就绪性检测（readiness probe）
-
pod终止过程
01Pod相位
首先在介绍 Pod 的生命周期之前，我们先了解下 Pod 的状态，因为 Pod 状态可以反映出当前我们的Pod 的具体状态信息，也是我们分析排错的一个必备的方式。
我们可以通过命令kubectl explain pod.status查看到
[root@master ~]# kubectl explain pod.statusKIND: PodVERSION: v1.....phase <string>The phase of a Pod is a simple, high-level summary of where the Pod is inits lifecycle. The conditions array, the reason and message fields, and theindividual container status arrays contain more detail about the pod'sstatus. There are five possible phase values:Pending: The pod has been accepted by the Kubernetes system, but one ormore of the container images has not been created. This includes timebefore being scheduled as well as time spent downloading images over thenetwork, which could take a while. Running: The pod has been bound to anode, and all of the containers have been created. At least one containeris still running, or is in the process of starting or restarting.Succeeded: All containers in the pod have terminated in success, and willnot be restarted. Failed: All containers in the pod have terminated, and atleast one container has terminated in failure. The container either exitedwith non-zero status or was terminated by the system. Unknown: For somereason the state of the pod could not be obtained, typically due to anerror in communicating with the host of the pod.
挂起（Pending）
Pod已被K8s系统接受，但有一个或者多个容器镜像尚未创建，等待时间包括调度Pod的时间和通过网络下载镜像的时间。这可能需要花点时间；
运行中（Running）
该Pod已经绑定到了一个节点上，Pod中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或者重启状态；
成功（Succeeded）
Pod中所有的容器都被成功终止并且不会再重启；
失败（Failed）
Pod中所有容器都已经终止，并且至少有一个容器是因为失败终止。也就是说，至少有一个容器以非0状态退出或者被系统终止；
未知（Unknown）
因为某些原因无法取得Pod的状态，通常是因为与Pod所在主机通信失败；
02pod创建和终止
Pod是Kubernetes的基础单元，理解它的创建过程对于了解系统运作大有帮助，下图中描述了一个Pod资源对象的典型过程。
pod的创建过程
1. 用户通过kubectl或者其他API客户端提交Pod Spec给API Server;
2. API Server将Pod对象的相关信息存入etcd中;
3. 待写入etcd操作完成，etcd将写入操作完成信息发送给API Server;
4. API Server将etcd写入完成信息返回给kubectl或者其他客户端;
5. kube-scheduler监听到API Server要创建一个新的Pod，然后开始对Pod进行调度绑定到Node;
6. 绑定Node成功后，kube-scheduler将bind结果返回给API Server;
7. API Server将bind信息存储到etcd系统中;
8. etcd将存储结果返回给API Server;
9. API Server告知kube-scheduler调度Pod信息已存储完成;
10. kubelet也在一直监听API Server，所以kubelet从API Server得知有一个Pod被调度到当前Node上，此时API Server也在监kubelet的信息;
11. kubelet调用当前节点的Docker来启动容器;
12. 容器启动成功后，docker将启动状态返回给kubelet;
13. kubelet收到docker返回的容器状态信息后，将容器状态信息更新给API Server;
14. API Server将Pod更新信息写入到etcd中;
15. etcd写入后将写入结果返回给API Server;
16. API Server将确认信息发送至相关的kubelet，事件将通过它被接受;
pod的终止过程
1. 用户向apiserver发送删除pod对象的命令;
2. apiserver中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead;
3. 将pod标记为terminating状态;
4. kubelet在监控到pod对象转为terminating状态的同时启动pod关闭进程;
5. 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表移除;
6. 如果当前pod对象定义了prestop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行;
7. pod对象中的容器进程收到停止信号;
8. 宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号;
9. kubelet请求apiserver将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见;
03初始化容器
Init Containers是在Pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作。
一个Pod能够具有多个容器，应用运行在应用容器里面，但是该Pod中可能有一个或多个先于应用容器启动的Init容器。
Init容器与普通容器非常像，除了以下两点：
-
Init容器总是运行到成功完成为止，如果某个初始化容器运行失败，那么kubernetes需要重启它直至成功完成;
-
Init容器必须按照定义的顺序执行，每个Init容器都必须在下一个Init容器启动之前成功完成;
注意：如果Pod的Init容器失败，Kubernetes会不断重启该Pod，知道Init容器成功位置。然而，如果Pod对应的重启策略restartPolicy为Never时，Pod不会重新启动。
Init Contianers的作用
因为Init容器具有与应用程序容器分离的单独镜像，所以它们的启动相关代码具有如下优势：
-
他们可以包含并运行实用工具，但是出于安全考虑，时不建议在应用程序容器镜像中包含这些实用工具的。
-
他们可以包含实用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python、dig这样的工具
-
应用程序镜像可以分离出创建和部署的角色，而没有必要联合他们构建一个单独的镜像。
-
Init容器使用Linux Namespace，所以相对应用程序容器来说，具有不同的文件系统视图。因此，他们能够具有访问Secret的权限，而应用程序容器则不能。实现分权限来治理。例如，有一个文件夹里面只有一个文件是main容器要用到的，但是又不希望main容器有这个文件夹的访问权限，于是通过init容器来访问该文件，并且把该文件复制到main容器中。
-
他们必须在应用程序容器启动之前运行完成，而应用程序容器时并行运行的，所以，Init容器能够提供一种简单的阻塞或延迟应用容器启动的方法，直到满足了一系列应用容器启动的先决条件。例如我们有两个容器，一个放数据库，一个放应用服务，服务要在数据库启动之后启动，访问才不会报错，那么此时我们可以在应用服务容器的init containers中设置一个条件，用于检测数据库容器是否完成启动，如果数据库完成启动了，则应用服务容器可以正常启动。
Init Contianers实验
下面我们通过实际例子来进一步认识init containers。
# init-pod.yamlapiVersion: v1kind: Podmetadata:name: init-podnamespace: testlabels:app: init-appversion: v1spec:containers:- name: baiyu-app-containerimage: busybox:1.32command: ['sh', '-c', 'echo The app is running && sleep 3600']initContainers:- name: init-baiyu-serviceimage: busybox:1.32command: ['sh', '-c','until nslookup baiyu-service; do echo waiting forbaiyu-service; sleep 2;done;']- name: init-baiyu-dbimage: busybox:1.32command: ['sh', '-c', 'until nslookup baiyu-db; do echo waiting for baiyudb;sleep 2; done;']
上面的yaml，运行了一个pod。里面有一个main container，有两个init container
kubectl apply -f init-pod.yaml然后执行kubectl get pod -n test -o wide -w查看容器状态
此时无论多久，上面这个容器都不会变成running状态的。这是因为我们写了两个init container的条件没有满足。
第一个init container里面，我们执行了下面这句命令，表示在我们能解析到有这个baiyu-service名称的网络服务就打破循环。
until nslookup baiyu-service;doecho waiting for baiyu-service;sleep 2;done;
此时，我们通过命令
kubectl logs init-pod -n test --container init-baiyu-service查看pod中的init-baiyu-service容器的日志，可以发现它一直在循环检测服务是否起来为了满足我们init-pod中的init container的条件，我们准备了以下脚本实现两个service，用于满足init C的条件。
# init-service.yamlkind: ServiceapiVersion: v1metadata:name: baiyu-servicenamespace: baiyu-learn-k8sspec:ports:- protocol: TCPport: 80targetPort: 9376---kind: ServiceapiVersion: v1metadata:name: baiyu-dbnamespace: baiyu-learn-k8sspec:ports:- protocol: TCPport: 80targetPort: 9377
执行命令启动脚本kubectl apply -f init-service.yaml
使用kubectl get pod -n test -o wide -w查看我们的pod的状态。结果如下图所示，在两个init容器执行完成之后，main 容器进行执行，最终Pod完成启动Pod状态变为Running。
下期分享生命周期(下)内容：钩子函数、容器探测、重启策略，敬请关注！