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 ..."

作者：joezxh