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

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

文章目录

  • 【云原生|Kubernetes】12-容器生命周期的回调(PreStart和PreStop)
    • 简介
    • 回调函数
      • 回调处理程序的实现
      • 回调处理程序执行
      • 调试回调函数
    • 为容器的生命周期事件设置处理函数
      • 定义 postStart 和 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 管理系统根据回调动作执行其处理程序, httpGettcpSocket 在 kubelet 进程执行(这一段是说Pod层面的健康检查和服务可用性检查),而 exec 则由容器内执行(这里就是我们这章所说的PreStart和PreStop)。

当一个 Pod 中的容器被创建时,Kubernetes 会先运行容器的入口点(即 commandargs 字段指定的命令),然后再运行 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 的值小于后面两件事情所花费的总时间

如果 PostStartPreStop 回调失败,它会杀死容器。

调试回调函数

回调处理程序的日志不会在 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。

你可能感兴趣的:(Kubernetes,云原生,kubernetes,容器)