1. 概述
kubernetes滚动升级的过程：
- 集群Deployment 或者 Statefulset 发生变化，触发部署滚动升级；
- 根据 Deolyement 等配置，K8S集群首先启动新的POD来替代老 POD；
- Deployemnt 根据配置调度 POD,拉取镜像，此时 POD 进入 Pending 状态；
- POD 绑定到Node上，启动容器，在就绪检查readinessProbe 探针通过后，新的POD进入Ready状态；
- K8S集群创建Endpoint，将新的POD纳入Service 的负载均衡；
- K8S集群移除与老POD相关的Endpoint，并且将老POD状态设置为Terminating，此时将不会有新的请求到达老POD，同时调用PreStop Hook执行配置的脚本；
- K8S集群会给老POD发送SIGTERM信号，并且等待 terminationGracePeriodSeconds 这么长的时间。(默认为30秒，可以根据优雅下线服务需要消耗时间调整)
- 超过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: AlwaysreadinessProbe配置表示只有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 ..."
