應用優雅上下線

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

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。