应用优雅上下线

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

阅读原文

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