kubernetes - pod PreStop 钩子(Hook)卡在 Termination 状态，仅在 TerminationGracePeriodSeconds 后被终止

Question

我在有状态 Pod 资源中定义了一个 preStop 钩子(Hook)，该钩子(Hook)运行 bash 脚本，以确保在应用程序中少数进程完成/取消/错误之前不会终止 Pod。我没有定义终止GracePeriodSeconds。现在，当我删除 pod 时，我测试了 preStop Hook 中的脚本是否按预期运行。但添加终止GracePeriodSeconds 10 分钟后，首先 bash 脚本作为 preStop Hook 的一部分成功运行几分钟，并且应该会杀死 pod。但 Pod 处于 TERMINATING 状态，并且仅在 10 分钟后就被杀死。

1. 为什么 Pod 挂起？无法找到此问题的答案。
2. 如果未添加终止GracePeriodSeconds，则流程会按预期工作，在完成脚本后或在 30 秒(即终止GracePeriodSeconds)内终止 pod。但是当我添加 10 分钟或更长的宽限期时，它会等到那个时间然后杀死 pod。

如何解决这个问题。有没有办法将 SIGTERM 或 SIGKILL 发送到 pod。有任何想法吗？预先感谢您!

STATEFULSET.YAML

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: appx
  name: appx
spec:
  serviceName: appx
  replicas: 1
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: appx
  template:
    metadata:
      labels:
        app: appx
    spec:
      #removed some of the sensitive info
      terminationGracePeriodSeconds: 600
      containers:
        - image: appx
          imagePullPolicy: IfNotPresent
          name: appx
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh", "-c", "sleep 30 && bash /var/tmp/runscript.sh; sleep10"]

KUBECTL 描述 POD

**kubectl describe pod appx**
Name:           appx
Namespace:      default
Priority:       0
Node:           docker-desktop/192.168.65.3
Start Time:     Mon, 21 Sep 2020 07:30:55 -0500
Labels:         app=appx
Annotations:    <none>
Status:         Running
IP:             x.x.x.x
Controlled By:  StatefulSet/appx
Containers:
  appx:
    Container ID:   docker://dfdgfgfgfgfgfgfg
    Image:          appx
    Image ID:       docker://sha256:49dfgfgfgfgfgfgfgfgfg96a6fc
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Mon, 21 Sep 2020 07:30:56 -0500
    Ready:          True
    Restart Count:  0
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  data:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  appx-token-xj6q9:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  appx-token-fhfdlf
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason     Age    From                     Message
  ----    ------     ----   ----                     -------
  Normal  Scheduled  2m43s  default-scheduler        Successfully assigned default/appx to docker-desktop
  Normal  Pulled     2m42s  kubelet, docker-desktop  Container image "appx" already present on machine
  Normal  Created    2m42s  kubelet, docker-desktop  Created container appx
  Normal  Started    2m42s  kubelet, docker-desktop  Started container appx

Answer 1

preStop Hook 和 terminationGracePeriodSeconds 是异步的。这意味着，一旦 kubelet 发现 Pod 已被标记为终止，kubelet 就会开始本地 Pod 关闭过程。这意味着，如果容器在宽限期内没有终止，则无论 preStop 钩子(Hook)中的命令是否完成，都会发送 SIGKILL 信号，并且容器将被终止。

2. When the terminationGracePeriodSeconds was not added, the flow was working as expected by killing the pod as soon as finishing the scriptor within 30 sec which is the terminationGracePeriodSeconds. But whenI added the grace period of 10 min or more, it is waiting until thattime and then killing the pod.

terminationGracePeriodSeconds 宽限期始终会添加。正如我在评论中提到的，它只是默认为 30 秒。那么，如果 terminationGracePeriodSeconds 小于完成 preStop Hook 的时间怎么办？

然后容器将在 terminationGracePeriodSeconds 结束时终止，并且 preStop Hook 将不会完成/运行。

当终止GracePeriodSeconds设置为600秒时，preStop Hook 脚本会挂起(目前不清楚它是否曾经工作过，因为由于抢先终止，它没有使用默认的30秒终止GracePeriodSeconds进行正确测试)。这意味着某些进程未正确处理 SIGTERM，目前尚未在 preStop Hook 中进行更正，这意味着容器正在等待 10 分钟终止GracePeriod 结束后发送 SIGKILL。

如果你看一下here你会发现，即使用户指定了 preStop 钩子(Hook)，他们也需要 SIGTERM nginx 才能正常关闭。

在这种情况下，尽管您已将 terminationGracePeriodSeconds 设置为 10 分钟，但即使您的 preStop Hook 成功执行，Kubernetes 也会等待 10 分钟才终止您的容器，因为这正是您告诉他要做的。终止信号由 kubelet 发送，但没有传递到容器内的应用程序。最常见的原因是，当您的容器运行一个运行应用程序进程的 shell 时，信号可能会被 shell 本身消耗/中断，而不是传递给子进程。此外，由于不清楚您的 runscript.sh 正在做什么，因此很难对哪些进程无法处理 SIGTERM 提出任何其他建议。

遇到这种情况你能做什么？提前结束的选项是:

• 减少终止GracePeriodSeconds
• 通过确保 SIGTERM 得到正确处理并且所有正在运行的进程都在监听终止来发送正常关闭的信号。如何执行此操作的示例为 here 。您可以看到他们对 NGINX 使用“退出”命令。

有关您的更多信息，可以找到精彩文章 here和 here .