4.5.3 Pod 生命周期中的重要行为

除了创建应用容器（主容器及其辅助容器）之外，用户还可以为 Pod 对象定义其生命周期中的多种行文，如初始化容器、存活性探测及就绪性探测等。

1. 初始化容器

初始化容器（init container）即应用程序的主容器启动之前要运行的容器，常用于为主容器执行一些预置操作，它们具有两种典型特征。

1) 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么 Kubernetes 需要重启它直到成功完成。

2) 每个初始化容器都必须按定义的顺序串行运行。

有不少场景都需要在应用容器启动之前进行部分初始化操作，例如，等待其他关联自检服务可用、基于环境变量或配置模板为应用程序生成配置文件、从配置中心获取配置等。初始化容器的典型应用需求具体包含如下几种：

1) 用于运行特定的工具程序，出于安全等方面的原因，这些程序不适于包含再主容器镜像中。

2) 提供主容器镜像中不具备的工具程序或自定义代码。

3) 为容器镜像的构建和部署人员提供了分离、独立工作的途径，使得他们不必协同起来制作单个镜像文件。

4) 初始化容器和主容器处于不同的文件系统视图中，因此可以分别安全地使用敏感数据，例如 Secrets 资源。

5) 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足。

Pod 资源的 “spec.initContainers” 字段以列表的形式定义可用的初始容器，其嵌套可用字段类似与 “spec.Containers”。下面的资源清单仅是一个初始化容器的使用示例，读者可自行创建并观察初始化容器的相关状态：

apiVersion: v1
kind: Pod
metadata:
    name: myapp-pod
    labels:
        app: myapp
spec:
    containers:
    - name: myapp-container
      image: ikubernetes/myapp:v1
    initContainers:
    - name: init-somethings
      image: busybox
      command: ['sh', '-c', 'sleep 10']

2. 生命周期钩子函数

生命周期钩子函数（lifecycle hook）是编程语言（如 Anguler）中常用的生命周期管理的组件，它实现了程序运行周期中的关键时刻的可见性，并赋予用户为此采取某种行动的能力。类似地，容器生命周期钩子使它能够感知自身生命周期管理中的事件，并在相应的时刻到来时运行由用户指定的处理程序代码。Kubernetes 为容器提供了两种生命周期钩子。

• postStart：于容器创建完成之后立即运行的钩子处理器（handler），不过 Kubernetes 无法确保它一定会于容器中的 ENTRYPOINT 之前运行。
• preStop：于容器终止操作之前立即运行的钩子处理器，它以同步的方式调用，因此在其完成之前会阻塞删除容器的操作的调用。

钩子处理器的实现方式有“Exec”和“HTTP”两种，前一种在钩子时间触发时直接在当前容器中运行由用户定义的命令，后一种则是在当前容器中向某URL发起HTTP请求。

postStart 和 preStop 处理器定义在容器的 spec.lifecycle 嵌套字段中，其使用方法如下面的资源清单所示，读者可自行创建相关的 Pod 资源对象，并验证其执行结果：

apiVersion: v1
kind: Pod
metadata:
    name: lifecycle-demo
spec:
    containers:
    - name: lifecycle-demo-container
      image: ikubernetes/myapp:v1
      lifecycle:
        postStart:
          exec:
            command: ["/bin/sh", "-c", "echo 'lifecycle hooks handlers' > /usr/share/nginx/html/test.html"]

3. 容器探测

容器探测（container probe）是 Pod 对象生命周期中的一项重要的日常任务，它是 kubelet 对容器周期性执行的健康状态诊断，诊断操作由于容器的处理器（handler）进行定义。Kubernetes 支持三种处理器用于 Pod 探测。

• ExecAction：在容器中执行一个命令，并根据其返回的状态码进行诊断的操作称为 Exec 探测，状态码为 0 表示成功，否则即为不健康的状态。
• TCPSocketAction：通过与容器的某 TCP 端口尝试建立连接进行诊断，端口能够成功打开即为正常，否则为不健康状态。
• HTTPGetAction：通过向容器IP地址的某指定端口的指定path发起 HTTP GET 请求进行诊断，响应码为 2xx 或 3xx 时即为成功，否则为失败。

任何一种探测方式都可能存在三种结果：“Success”（成功）、“Failure”（失败）或“Unknown”（未知），只有第一种结果表示成功通过检测。

Kubelet 可在活动容器上执行两种类型的检测：存活性检测（livenessProbe）和就绪性检测（readinessProbe）。

• 存活性检测：用于判断容器是否处于“运行”（Running）状态；一旦此类检测未通过，kubelet 将杀死容器并根据其 restartPolicy 决定是否将其重启；未定义存活性检测的容器的默认状态为 “Success”。
• 就绪性检测：用于判断容器是否准备就绪并可对外提供服务；未通过检测的容器意味着尚未准备就绪，端点控制器（如 Service 对象）会将其IP从所有匹配到此 Pod 对象的 Service 对象的端点列表中移除；检测通过之后，会再次将其IP添加至端点列表中。

存活性检测和就绪性检测相关的话题在后文的章节中还会有进一步的介绍。