优雅停止（Gracful Shutdown）与 502/504 报错
如果 Pod 正在处理大量请求（比如 1000 QPS+）时，因为节点故障或「竞价节点」被回收等原因被重新调度， 你可能会观察到在容器被 terminate 的一段时间内出现少量 502/504。
为了搞清楚这个问题，需要先理解清楚 terminate 一个 Pod 的流程：
1.Pod 的状态被设为 Terminating，（几乎）同时该 Pod 被从所有关联的 Service Endpoints 中移除
2.preStop 钩子被执行
a.它的执行阶段很好理解：在容器被 stop 之前执行
b.它可以是一个命令，或者一个对 Pod 中容器的 http 调用
c.如果在收到 SIGTERM 信号时，无法优雅退出，要支持优雅退出比较麻烦的话，用 preStop 实现优雅退出是一个非常好的方式
d.preStop 的定义位置：https://github.com/kubernetes/api/blob/master/core/v1/types.go#L2515
3.preStop 执行完毕后，SIGTERM 信号被发送给 Pod 中的所有容器
4.继续等待，直到容器停止，或者超时 spec.terminationGracePeriodSeconds，这个值默认为 30s
a.需要注意的是，这个优雅退出的等待计时是与 preStop 同步开始的！而且它也不会等待 preStop 结束！
5.如果超过了 spec.terminationGracePeriodSeconds 容器仍然没有停止，k8s 将会发送 SIGKILL 信号给容器
6.进程全部终止后，整个 Pod 完全被清理掉
注意：1 跟 2 两个工作是异步发生的，所以在未设置 preStop 时，可能会出现「Pod 还在 Service Endpoints 中，但是 SIGTERM 已经被发送给 Pod 导致容器都挂掉」的情况，我们需要考虑到这种状况的发生。
了解了上面的流程后，我们就能分析出两种错误码出现的原因：
- 502：应用程序在收到 SIGTERM 信号后直接终止了运行，导致部分还没有被处理完的请求直接中断，代理层返回 502 表示这种情况
- 504：Service Endpoints 移除不够及时，在 Pod 已经被终止后，仍然有个别请求被路由到了该 Pod，得不到响应导致 504
通常的解决方案是，在 Pod 的 preStop 步骤加一个 15s 的等待时间。其原理是：在 Pod 处理 terminating 状态的时候，就会被从 Service Endpoints 中移除，也就不会再有新的请求过来了。在 preStop 等待 15s，基本就能保证所有的请求都在容器死掉之前被处理完成（一般来说，绝大部分请求的处理时间都在 300ms 以内吧）。
一个简单的示例如下，它使 Pod 被 Terminate 时，总是在 stop 前先等待 15s，再发送 SIGTERM 信号给容器：
containers:
- name: my-app
# 添加下面这部分
lifecycle:
preStop:
exec:
command:
- /bin/sleep
- "15"
更好的解决办法，是直接等待所有 tcp 连接都关闭（需要镜像中有 netstat）：
containers:
- name: my-app
# 添加下面这部分
lifecycle:
preStop:
exec:
command:
- /bin/sh
- -c
- "while [ $(netstat -plunt | grep tcp | wc -l | xargs) -ne 0 ]; do sleep 1; done"
如果我的服务还使用了 Sidecar 代理网络请求，该怎么处理？
以服务网格 Istio 为例，在 Envoy 代理了 Pod 流量的情况下，502/504 的问题会变得更复杂一点——还需要考虑 Sidecar 与主容器的关闭顺序：
- 如果在 Envoy 已关闭后，有新的请求再进来，将会导致 504（没人响应这个请求了）
- 所以 Envoy 最好在 Terminating 至少 3s 后才能关，确保 Istio 网格配置已完全更新
- 如果在 Envoy 还没停止时，主容器先关闭，然后又有新的请求再进来，Envoy 将因为无法连接到 upstream 导致 503
- 所以主容器也最好在 Terminating 至少 3s 后，才能关闭。
- 如果主容器处理还未处理完遗留请求时，Envoy 或者主容器的其中一个停止了，会因为 tcp 连接直接断开连接导致 502
- 因此 Envoy 必须在主容器处理完遗留请求后（即没有 tcp 连接时），才能关闭
所以总结下：Envoy 及主容器的 preStop 都至少得设成 3s，并且在「没有 tcp 连接」时，才能关闭，避免出现 502/503/504.
主容器的修改方法在前文中已经写过了，下面介绍下 Envoy 的修改方法。
和主容器一样，Envoy 也能直接加 preStop，修改 istio-sidecar-injector 这个 configmap，在 sidecar 里添加 preStop sleep 命令:
containers:
- name: istio-proxy
# 添加下面这部分
lifecycle:
preStop:
exec:
command:
- /bin/sh
- -c
- "while [ $(netstat -plunt | grep tcp | grep -v envoy | wc -l | xargs) -ne 0 ]; do sleep 1; done"
实践中java springcloud 微服务优雅停机设置
pod: http: port: 8080 probe: enabled: true probes: livenessProbe: tcpSocket: port: http initialDelaySeconds: 150 #启动容器后，启动活动或就绪探针之前的秒数。默认为0秒。最小值为0。 periodSeconds: 10 #执行探测的频率（以秒为单位）。默认为10秒。最小值为1。 timeoutSeconds: 1 #探测超时的秒数。默认为1秒。最小值为1。 successThreshold: 1 #探测失败后，连续最小成功探测为成功。默认值为1。为保持活力，必须为1。最小值为1。 failureThreshold: 3 #如果探测失败，Kubernetes将尝试尝试failureThreshold放弃。放弃活动探针意味着重新启动容器。如果准备就绪，则将Pod标记为“未就绪”。默认值为3。最小值为1。 readinessProbe: tcpSocket: port: http initialDelaySeconds: 150 #启动容器后，启动活动或就绪探针之前的秒数。默认为0秒。最小值为0。 periodSeconds: 10 #执行探测的频率（以秒为单位）。默认为10秒。最小值为1。 timeoutSeconds: 1 #探测超时的秒数。默认为1秒。最小值为1。 successThreshold: 1 #探测失败后，连续最小成功探测为成功。默认值为1。为保持活力，必须为1。最小值为1。 failureThreshold: 3 #如果探测失败，Kubernetes将尝试尝试failureThreshold放弃。放弃活动探针意味着重新启动容器。如果准备就绪，则将Pod标记为“未就绪”。默认值为3。最小值为1。 lifecycle: #优雅统计使用的k8s钩子函数 preStop: exec: command: #k8s 钩子函数需要执行的命令 - sh - -c #以下为服务线下流程，正常k8s 滚动更新是会发送SIGTERM信号给pod内PID为1的进程（正常状态下java进程pod内PID为1，故不用使用此钩子函数），特殊业务架构下，PID为1的进程可能不是java进程，此时必须使用此钩子函数才能优雅停机 - curl -X "POST" "http://localhost:9090/sys/actuator/service-registry?status=DOWN" -H "Content-Type:application/vnd.spring-boot.actuator.v2+json;charset=UTF-8" && sleep 35 && PID=`pidof java` && kill -SIGTERM $PID && while ps -p $PID > /dev/null; do sleep 1; done
今日语录：
才华是刀刃，辛苦是刀石，很锋利的刀刃，若日久不用磨，也会生锈，成为废物
标签：容器,停机,Envoy,优雅,最小值,preStop,Pod,K8S From： https://www.cnblogs.com/muyi-yang/p/17414254.html