【云原生|Kubernetes】12-容器生命周期的回调（PreStart和PreStop）

简介

我们知道，K8S可以在应用容器启动之前先执行一些预定义的操作，比如事先生成一些数据，以便于应用容器在启动的时候使用。这种方式可以通过init container技术实现。

那么事实上，在实际生产中，还有一种需求，就是我们需要在应用容器启动后执行一些初始化操作，比如设置容器的dns参数等，说到这里就不得不多提一句，k8s到目前为止尚不支持通过为kubelet添加参数的方式为应用容器设置dns的options。事实上我们在生产中之所以使用到本篇文档所说的这种钩子，就是为了在应用容器启动后为其设置一个dns的options。

除了为容器添加启动后的钩子之外，还可以为容器添加销毁之前的钩子。

回调函数

有两个回调暴露给容器：

• PostStart: 这个回调在容器被创建之后立即被执行(业务容器启动之后立即执行)。 但是，不能保证回调会在容器入口点（ENTRYPOINT）之前执行。 没有参数传递给处理程序。
• PreStop： 在容器因 API 请求或者管理事件（诸如存活态探针、启动探针失败、资源抢占、资源竞争等） 而被终止之前，此回调会被调用。 如果容器已经处于已终止或者已完成状态，则对 preStop 回调的调用将失败。 在用来停止容器的 TERM 信号被发出之前，回调必须执行结束。 Pod 的终止宽限周期在 PreStop 回调被执行之前即开始计数， 所以无论回调函数的执行结果如何，容器最终都会在 Pod 的终止宽限期内被终止。 没有参数会被传递给处理程序。

回调处理程序的实现

容器可以通过实现和注册该回调的处理程序来访问该回调。 针对容器，有两种类型的回调处理程序可供实现：

• Exec - 在容器的 cgroups 和名字空间中执行特定的命令（例如 pre-stop.sh）。 命令所消耗的资源计入容器的资源消耗。这些回调可以用于在容器终止之前执行清理操作，例如关闭文件句柄或释放其他资源。
• HTTP - 对容器上的特定端点执行 HTTP 请求。这些回调可以用于在容器启动或停止时向外部服务发送通知，例如将容器的状态报告给监控系统。

回调处理程序执行

• PreStart：

当调用容器生命周期管理回调时，Kubernetes 管理系统根据回调动作执行其处理程序， httpGet 和 tcpSocket 在 kubelet 进程执行（这一段是说Pod层面的健康检查和服务可用性检查），而 exec 则由容器内执行（这里就是我们这章所说的PreStart和PreStop）。

当一个 Pod 中的容器被创建时，Kubernetes 会先运行容器的入口点（即 command 或 args 字段指定的命令），然后再运行 PostStart 回调处理程序。因此，在 PostStart 回调处理程序执行之前，容器的入口点已经完成并且容器已经启动。这是异步的行为，因为容器的入口点和 PostStart 回调处理程序是在不同的时间点执行的。

需要注意的是，在 PostStart 回调处理程序执行期间，容器仍然处于启动阶段，可能还没有完全准备好接受流量。因此，在 PostStart 回调处理程序中执行的任何操作都应该考虑到这一点，并且应该只涉及容器内部的操作，而不是与外部服务交互。例如，在 PostStart 回调处理程序中可以执行初始化操作、启动后台服务、创建临时文件等操作，但应该避免向外部服务发送请求或接收来自外部服务的请求。但是，如果回调运行或挂起的时间太长，则容器无法达到 running 状态。

• PreStop:

PreStop 回调处理程序的执行与停止容器的信号处理程序是同步的，而不是异步的。当 Kubernetes 停止一个容器时，它将首先向容器发送一个停止信号，然后等待一段时间（称为 terminationGracePeriodSeconds）以便容器可以执行清理操作，并且关闭所有正在进行的连接。在此期间，Kubernetes 将运行 PreStop 回调处理程序，以便容器可以在关闭之前执行一些清理任务，例如保存状态、执行清理操作等。

需要注意的是，PreStop 回调处理程序必须在容器停止之前完成执行。如果回调处理程序无法在 terminationGracePeriodSeconds 内完成执行，Kubernetes 将强制停止容器，这可能会导致数据丢失或其他不良后果。因此，在编写 PreStop 回调处理程序时，需要确保它可以在规定的时间内完成执行，并且不会影响容器的正常停止过程。

1 如果 PreStop 回调在执行期间停滞不前，Pod 的阶段会变成 Terminating并且一直处于该状态， 直到其 terminationGracePeriodSeconds 耗尽为止，这时 Pod 会被杀死。 这一宽限期是针对 PreStop 回调的执行时间及容器正常停止时间的总和而言的。 例如，如果 terminationGracePeriodSeconds 是 60，回调函数花了 55 秒钟完成执行， 而容器在收到信号之后花了 10 秒钟来正常结束，那么容器会在其能够正常结束之前即被杀死， 因为 terminationGracePeriodSeconds 的值小于后面两件事情所花费的总时间

如果 PostStart 或 PreStop 回调失败，它会杀死容器。

调试回调函数

回调处理程序的日志不会在 Pod 事件中公开。 如果处理程序由于某种原因失败，它将播放一个事件。 对于 PostStart，这是 FailedPostStartHook 事件，对于 PreStop，这是 FailedPreStopHook 事件。 要自己生成失败的 FailedPostStartHook 事件，请修改 lifecycle-events.yaml 文件将 postStart 命令更改为 “badcommand” 并应用它。

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "badcommand"]

为容器的生命周期事件设置处理函数

定义 postStart 和 preStop 处理函数

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]

在上述配置文件中，你可以看到 postStart 命令在容器的 /usr/share 目录下写入文件 message。 命令 preStop 负责优雅地终止 nginx 服务。

可以使用 terminationGracePeriodSeconds 字段设置容器的优雅停机期限。这个字段指定了 Kubernetes 等待容器停止的时间，以确保容器可以优雅地停止并完成清理操作。在 terminationGracePeriodSeconds 时间内，Kubernetes 会等待容器完成所有正在进行的连接，并允许容器执行 PreStop 钩子中指定的清理操作。

默认情况下，terminationGracePeriodSeconds 的值为 30 秒。可以通过在 Pod 的 spec 字段中设置 terminationGracePeriodSeconds 来自定义该值。

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo 'Stopping application'"]
    terminationGracePeriodSeconds: 60

总结

• Kubernetes 在容器创建后立即发送 postStart 事件。 然而，postStart 处理函数的调用不保证早于容器的入口点（entrypoint） 的执行。postStart 处理函数与容器的代码是异步执行的，但 Kubernetes 的容器管理逻辑会一直阻塞等待 postStart 处理函数执行完毕。 只有 postStart 处理函数执行完毕，容器的状态才会变成 RUNNING。
  postStart 处理函数与容器的代码是异步执行的，但 Kubernetes 的容器管理逻辑会一直阻塞等待 postStart 处理函数执行完毕。 只有 postStart 处理函数执行完毕，容器的状态才会变成 RUNNING。