1. 概述

kubernetes滚动升级的过程：
1. 集群Deployment 或者 Statefulset 发生变化，触发部署滚动升级；
2. 根据 Deolyement 等配置，K8S集群首先启动新的POD来替代老 POD；
3. Deployemnt 根据配置调度 POD,拉取镜像，此时 POD 进入 Pending 状态；
4. POD 绑定到Node上，启动容器，在就绪检查readinessProbe 探针通过后，新的POD进入Ready状态；
5. K8S集群创建Endpoint，将新的POD纳入Service 的负载均衡；
6. K8S集群移除与老POD相关的Endpoint，并且将老POD状态设置为Terminating，此时将不会有新的请求到达老POD，同时调用PreStop Hook执行配置的脚本；
7. K8S集群会给老POD发送SIGTERM信号，并且等待 terminationGracePeriodSeconds 这么长的时间。(默认为30秒，可以根据优雅下线服务需要消耗时间调整)
8. 超过terminationGracePeriodSeconds等待时间后， K8S集群会强制结束老POD，在这个时间段内要将老 POD 资源释放掉，否则可能残留无用资源被占用。

---

从以上过程可以看到，如果在terminationGracePeriodSeconds 没有及时释放服务注册等资源信息，Service 负载均衡的健康检查又没有检查到老 POD服务已经挂掉，导致请求分发到这些 POD 上，从而触发一系列的请求错误，因而需要配置优雅下线脚本，在terminationGracePeriodSeconds 时间段内执行完毕。

2.优雅启动

kubernetes 集群提供了探针，类似健康检查，只有该请求通过，新的 POD 才能进入 Ready 状态，kubernetes集群才会将新的 POD 纳入 Service 的负载均衡。
因而如果该应用(POD)仅仅提供 service 配置的服务，不需要配置探针，就可以优雅启动，但是实际 POD 往往还有 HSF,LWP，Dubbo等注册于配置服务其实现负载均衡的服务，所以需要确保这些服务都已经启动，所以需要配置相应的探针。
同时，任何一个服务可能在运行中因为某种原因不稳定，导致服务中断，这个时候还需要配置livenessProbe探针，确保服务出故障时及时止损。
我们的应用主要有HSF,LWP 和 Https 服务，对于三种服务都有的应用，要求应用提供健康检查的接口，能即时检查三种服务都正常与否，然后做以下配置：

livenessProbe: failureThreshold: 3 initialDelaySeconds: 30 periodSeconds: 30 successThreshold: 1 tcpSocket: port: 5084 timeoutSeconds: 1 readinessProbe: failureThreshold: 3 initialDelaySeconds: 30 periodSeconds: 30 successThreshold: 1 tcpSocket: port: 5084 timeoutSeconds: 1 restartPolicy: Always

readinessProbe配置表示只有5804端口请求正常返回，pod 才会进入 ready 状态，确保各种服务 ok 。
livenessProbe 表示每10s 探一下5804端口，如果返回失败，达到阈值后，pod 会重启，对于服务出问题的 POD 及时止损。
注意：readinessProbe探针的 探测频率和延时时间，不健康阈值等数据要合理，部分应用启动时间本身较长，如果设置的时间过短，会导致 POD 反复无效重启。

3. 优雅下线：

我们的应用云上主要有 HSF,LWP 和 Https 服务，在 pod prestop里设置执行摘除服务注册信息脚本，来完成优雅下线。
https 服务基于 kubernetes 服务 Service 来实现服务暴露，在老 POD 状态设置为Terminating后，就不会有请求达到，因而已经优雅下线；
lwp 服务，通过注册 vipserver 来提供负载均衡，需要在下线前先摘除该服务注册，防止 老POD 下线后还有请求达到老 POD；
HSF 服务通过注册 configserver 来提供负载均衡，需要在下线前先摘除该服务注册，防止 老POD 下线后还有请求达到老 POD。
yaml：

lifecycle: preStop: exec: command: - sudo - '-u' - admin - /home/admin/shutdown.sh - {app_name}

preStop在 pod 终止之前，执行脚本 appctl.sh {app_name} stop。
终止 HSF 与 LWP 脚本：

#!/bin/bash APP_NAME=$1 ## HEALTH_URL="http://localhost:7002/health" offline() { echo "INFO: ${APP_NAME} try to offline..." offline_lwp offline_hsf echo "INFO: ${APP_NAME} offline success" return $? } offline_lwp() { echo "offline lwp" times=3 for e in $(seq 3); do curl -s --connect-timeout 3 --max-time 5 ${offline_lwp_url}${APP_NAME} -o /dev/null sleep 1 done } offline_hsf() { check_hsf=`(/usr/sbin/ss -ln4 sport = :12200; /usr/sbin/ss -ln6 sport = :12200) | grep -c ":12200"` check_pandora=`(/usr/sbin/ss -ln4 sport = :12201; /usr/sbin/ss -ln6 sport = :12201) | grep -c ":12201"` echo "try to offline hsf..." if [ $check_hsf -ne 0 -a $check_pandora -ne 0 ]; then echo "start to offline hsf...." ret_str=`curl --max-time ${HSF_ONLINE_TIMEOUT} -s "http://localhost:12201/hsf/offline?k=hsf" 2>&1` if echo "$ret_str" | grep "server is unregistered on cs(dr)" &>/dev/null; then echo "hsf offline success." return 0 else echo "hsf offline failed." exit 9 # hsf offline failed fi else if [ $check_hsf -eq 0 ]; then echo "WARN: port 12200 cannot be detected." fi if [ $check_pandora -eq 0 ]; then echo "WARN: port 12201 cannot be detected." fi echo "WARN: hsf offline failed." # DO NOT exit here fi } echo "[stop 1] before call offline hsf,lwp ..."