应用优雅上下线

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

原文链接
本文为云栖社区原创内容，未经允许不得转载。