应用优雅上下线

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

阅读原文

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

你可能感兴趣的:(负载均衡,配置,集群,kubernetes)