优美的吊舱终止 [英] Graceful pod termination

问题描述

我需要让容器在kubectl'终止后5分钟运行.它需要做一些工作才能销毁.看来kubernetes完全包含了我所需要的东西:

I need to let the container to run 5 minutes after the kubectl ' termination. It needs to do some work before it's destroyed. It seems that kubernetes contains exactly what I need:

terminationGracePeriodSeconds: 300

所以我在yaml中定义了它.我已经更新了正在运行的RCs，删除了当前的pod，因此创建了新的pod，现在我可以通过get pod xyz -o=yaml看到一个pod恰好包含此设置.

so I defined it within my yaml. I've updated running RCs, delete current pods so new ones were created and now I can see that a pod contains exactly this setting via get pod xyz -o=yaml.

不幸的是，当我尝试执行rolling-update时，原始吊舱在1分钟后(而不是5分钟后)就被杀死了.我对目标计算机执行了ssh操作，然后看到docker终止了该容器.

Unfortunately, when I tried to do rolling-update, the original pod was killed after exactly 1 minute, not after 5 minutes. I does ssh to the target machine and I could see that docker termineted the container after this time.

我试图进行一些调查，研究该功能的工作原理.我终于找到kubectl delete的文档，其中有关于宽限期终止的概念:

I tried to do some investigation how the feature works. I finally found the documentation to kubectl delete where there is a notion about graceful termination period:

http://kubernetes.io/docs/user-guide/pods/

默认情况下，所有删除均会在30秒内正常显示. kubectl delete命令支持--grace-period =选项，该选项允许用户覆盖默认值并指定自己的值.值0表示删除应立即生效，并立即删除API中的Pod，以便可以创建具有相同名称的新Pod.在节点上设置为立即终止的Pod仍将被给予短暂的宽限期，然后被强制杀死

By default, all deletes are graceful within 30 seconds. The kubectl delete command supports the --grace-period= option which allows a user to override the default and specify their own value. The value 0 indicates that delete should be immediate, and removes the pod in the API immediately so a new pod can be created with the same name. On the node pods that are set to terminate immediately will still be given a small grace period before being force killed

所以我拿了一个pod nginx，并尝试用grace-period=30删除它.原来，原来的Pod已被立即删除，get pods显示新的Pod正在启动.

So I took one pod, nginx, and try to delete it with grace-period=30. It turned out, that original pod was immediately delete and get pods showed that new one was being started.

所以没有30秒.我究竟做错了什么?似乎所有pod kubernetes都没有考虑这些值. 请注意，我正在使用kubernetes v1.2.2

So no 30 seconds. What am I doing wrong? It seems that all pods kubernetes does not take these values into account. Note that I'm using kubernetes v1.2.2

我也发现了此问题 https://github.com/kubernetes/kubernetes/issues/24695 那里的记者遇到了同样的问题，他以同样的方式解决了这个问题.所以对于kubernetes而言，300秒并不是太多.

I also found this issue https://github.com/kubernetes/kubernetes/issues/24695 where the reporter had same problem and he solved it in the same fashion. So e.g. 300 seconds is not too much for kubernetes.

推荐答案

您也许可以在'preStop'挂钩中设置魔术睡眠.在kubectl将SIGTERM发送到您的容器之前，该钩子将被保护.

You may be able to set magic sleep in 'preStop' hook.　This hook will be extecuted prior to kubectl sending SIGTERM to your container.

http://kubernetes. io/docs/user-guide/production-pods/#lifecycle-hooks-and-termination-notice

类似:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sleep","300"]

这篇关于优美的吊舱终止的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！