容器生命周期回调

    类似于许多具有生命周期回调组件的编程语言框架，例如 Angular、Kubernetes 为容器提供了生命周期回调。 回调使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期回调时运行在处理程序中实现的代码。

    有两个回调暴露给容器：

    这个回调在容器被创建之后立即被执行。 但是，不能保证回调会在容器入口点（ENTRYPOINT）之前执行。 没有参数传递给处理程序。

    在容器因 API 请求或者管理事件（诸如存活态探针失败、资源抢占、资源竞争等）而被终止之前， 此回调会被调用。 如果容器已经处于终止或者完成状态，则对 preStop 回调的调用将失败。 此调用是阻塞的，也是同步调用，因此必须在发出删除容器的信号之前完成。 没有参数传递给处理程序。

    有关终止行为的更详细描述，请参见 。

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

    • HTTP - 对容器上的特定端点执行 HTTP 请求。

    当调用容器生命周期管理回调时，Kubernetes 管理系统根据回调动作执行其处理程序， exec 和 tcpSocket 在容器内执行，而 httpGet 则由 kubelet 进程执行。

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

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

    用户应该使他们的回调处理程序尽可能的轻量级。 但也需要考虑长时间运行的命令也很有用的情况，比如在停止容器之前保存状态。

    回调的递送应该是 至少一次，这意味着对于任何给定的事件， 例如 PostStart 或 PreStop，回调可以被调用多次。 如何正确处理被多次调用的情况，是回调实现所要考虑的问题。

    回调处理程序的日志不会在 Pod 事件中公开。 如果处理程序由于某种原因失败，它将播放一个事件。 对于 PostStart，这是 FailedPostStartHook 事件，对于 PreStop，这是 FailedPreStopHook 事件。 您可以通过运行 kubectl describe pod <pod_name> 命令来查看这些事件。 下面是运行这个命令的一些事件输出示例: