Kubernetes Pod在收到SIGTERM后仍然收到请求吗？

我想在Kubernetes Pod中实现正常关机。我知道我需要侦听SIGTERM，它表示关机程序的开始。但是当我收到它时，我究竟做了什么？Kubernetes Pod在收到SIGTERM后仍然收到请求吗？

至少我必须等待所有运行请求在退出之前完成。但是在收到SIGTERM后，pod仍然可以收到新的请求吗？（它使用服务公开。）我找不到任何明确的文档。

The docs状态：

吊舱从端点列表服务中删除，并且不再被认为是一组运行荚复制控制器的一部分。缓慢关闭的Pod可以继续为流量提供服务，因为负载平衡器（如服务代理）将它们从旋转中移除。

因此，这似乎意味着新的请求仍然可以进来。因此，在优雅的终止之前，我应该继续期待多久？我是否忽略了SIGTERM，像往常一样继续提供请求并等待最终的SIGKILL？

我想确保未来的准备情况检查失败，然后等待的时间比终止前可能发生的时间长吗？

我在Kubernetes 1.2.5上，如果这有什么区别的话，我特别讨论滚动更新，但也会一般缩小复制控制器。

来源

2016-11-11 Mr. Wonko

我跑了一些实验，找出究竟发生了什么。

吊舱将短暂（< 1S）继续接收请求关机开始后，所以你需要或者捕捉SIGTERM或安装的prestop挂钩，所以你可以等待他们（和完成服务的当前请求）。

但是，一旦关闭已经启动，就绪探测不再重要，您不需要更改其状态以停止接收请求。（但在此之前，一个失败的准备就绪探针将导致您的pod无法接收更多流量。）

来源

2016-11-28 10:56:25

如果您想在关闭Pod之前清除流量，则应该使用preStop hook以及livenessProbe health check。

理想情况下，您将拥有一个preStop挂钩，将pod强制转换为不健康的livenessProbe检查，以便将pod从负载平衡器中删除，然后正常关闭。

这不太好，但是这个例子在我的简单测试中有效。

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
    name: nginx 
spec: 
    template: 
    metadata: 
     labels: 
     app: nginx 
    spec: 
     containers: 
     - name: nginx 
     image: nginx 
     livenessProbe: 
      exec: 
      command: 
      - cat 
      - /usr/share/nginx/html/50x.html 
      initialDelaySeconds: 15 
      timeoutSeconds: 1 
     ports: 
     - containerPort: 80 
     lifecycle: 
      preStop: 
      exec: 
       # SIGTERM triggers a quick exit; fail health check and gracefully terminate instead 
       command: ["/bin/rm","-f","/usr/share/nginx/html/50x.html",";","sleep","2",";","/usr/sbin/nginx","-s","quit"]

从这个例子中，livenessProbe查找/usr/share/nginx/html/50x.html文件。只要该文件存在，吊舱就是健康的。当Pod将被关闭时，PreStop钩子将被触发，从而移除该文件。这应该会触发在下一次运行状况检查（1秒）时将外挂从外部负载平衡器中移除。然后preStop命令会休眠2秒（以确保下一次运行状况检查被触发）并告诉nginx正常停止-s quiet。 preStop命令应该在30秒内完成，在pod强制终止（SIGTERM）之前30秒内完成，但是应该为nginx排出连接提供足够的时间。

来源

2016-11-16 06:03:00

由于不可预测的时间，但韩元失败的活性探针立即杀死容器，关闭所有打开的连接？准备就绪调查似乎更适合我。无论哪种方式，使用preStop钩子和捕获SIGTERM有什么区别？ –

如果吊舱失效，它将通过正常的终止程序。如果一个吊舱已经被杀死，它不会被重新杀死，除非它超过了30秒的超时时间（默认时间）。准备探测器仅在启动时使用，以确保在发送流量之前该容器已准备就绪。准备完成后，不再检查准备就绪探测器，将来的检查将使用livenessProbe。的prestop可以重复使用泛型容器和做每荚自定义操作，而不是建立每个应用程序/ POD专门的容器来处理正常关机。 –

我做了一些实验，并准备探头，其实是在定期检查，如果一个吊舱不再是准备将不再接收流量。 –

我最近面临着类似的问题，我用简单的prestop钩，它引入了终止的开始和接收SIGTERM之间有一些延迟（睡眠），以下面的过程

lifecycle: 
     preStop: 
      exec: 
      command: 
       - "sleep" 
       - "60"

这个延时有助于，

负载均衡器删除（同步）正在终止的pod
给予终止pod的机会以完成收到的请求bef矿石终止
履行终止终止和负载平衡器更新之间荚（同步）接收到的请求

的prestop可以更加智能对于吊舱服务

来源

2017-11-15 23:46:45 JRomio

Kubernetes Pod在收到SIGTERM后仍然收到请求吗？

回答

相关问题