linux企业级运维-----＞kubernetes（4）Pod生命周期

一、Pod的相位

Pod的status字段是PodStatus对象，它拥有一个名为phase的字段即Pod的相位。
pod的相位是对Pod的生命周期中所属位置的一种简单宏观的概述。相位不是pod状态或容器状态的汇总，也不是为了当作综合状态机来使用的。

pod的相位值是严格界定的。除了这些已经定义的相位值外，不会有其他任何值的出现。

相位值	说明
Pending	pod已经被kubernetes系统接受，但尚有一个或多个容器镜像未能创建。比如，调度前消耗的运算时间，以及通过网络下载镜像所消耗的时间这些准备时间都会导致容器镜像未创建。
Running	pod已经绑定到node中，所有的容器均已经创建。至少有一个容器还在运行，或者正在启动或重新启动
Succeeded	pod中的所有容器都已经成功终止并且不会重新启动
Failed	pod中的所有容器都已经终止，并且至少有一个容器表现出失败的终止状态。也就是说，容器要么非零退出，要么被系统终止
Unknown	由于某种原因无法获得pod的状态，者通常是pod所在的宿主机通信出错而导致的

在pod的整个生命周期里，会经历两个大的阶段：（1）初始化容器运行阶段（2）正是容器运行阶段

二、init初始化容器运行阶段

1、init容器

Pod 可以包含多个容器,应用运行在这些容器里面,同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。

init容器与普通容器的区别：

（1）它们总是运行到完成。
（2）Init 容器不支持 Readiness,因为它们必须在 Pod 就绪之前运行完成。
每个 Init 容器必须运行成功,下一个才能够运行。

Init 容器能做什么?

• Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化
代码。
• Init 容器可以安全地运行这些工具,避免这些工具导致应用镜像的安全性
降低。
• 应用镜像的创建者和部署者可以各自独立工作,而没有必要联合构建一个
单独的应用镜像。
• Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此,Init容器
可具有访问 Secrets 的权限,而应用容器不能够访问。
• 由于 Init 容器必须在应用容器启动之前运行完成,因此 Init 容器提供了一
种机制来阻塞或延迟应用容器的启动,直到满足了一组先决条件。一旦前
置条件满足,Pod内的所有的应用容器会并行启动。

一些命令

命令	含义
kubectl describe -f myapp.yaml	查看容器详细信息
kubectl logs myapp-pod -c init-myservice	查看pod内指定容器的日志
kubectl create -f services.yaml	创建服务

2、init初始化容器

pause镜像为pod提供了基础的初始化环境

#在server1中查找并拉取busyboxplus镜像并上传到私有仓库
docker login reg.westos.org
docker search busyboxplus
docker pull radial/busyboxplus
docker tag doc