隨著小步快跑、快速迭代的開(kāi)發(fā)模式被越來(lái)越多的互聯(lián)網(wǎng)企業(yè)認(rèn)同和采用，應(yīng)用的變更、升級(jí)頻率變得越來(lái)越頻繁。為了應(yīng)對(duì)不同的升級(jí)需求，保證升級(jí)過(guò)程平穩(wěn)順利地進(jìn)行，誕生了一系列的部署發(fā)布模式。

• 停機(jī)發(fā)布 - 把老版的應(yīng)用實(shí)例完全停止，再發(fā)布新的版本。這種發(fā)布模式主要為了解決新老版本互不兼容、無(wú)法共存的問(wèn)題，缺點(diǎn)是一段時(shí)間內(nèi)服務(wù)完全不可用。
• 藍(lán)綠發(fā)布 - 在線上同時(shí)部署相同數(shù)量的新老版本應(yīng)用實(shí)例。待新版本測(cè)試通過(guò)后，將流量一次性地切到新的服務(wù)實(shí)例上來(lái)。這種發(fā)布模式解決了停機(jī)發(fā)布中存在的服務(wù)完全不可用問(wèn)題，但會(huì)造成比較大的資源消耗。
• 滾動(dòng)發(fā)布 - 分批次逐步替換應(yīng)用實(shí)例。這種發(fā)布模式不會(huì)中斷服務(wù)，同時(shí)也不會(huì)消耗過(guò)多額外的資源，但由于新老版本實(shí)例同時(shí)在線，可能導(dǎo)致來(lái)自相同客戶端的請(qǐng)求在新老版中切換而產(chǎn)生兼容性問(wèn)題。
• 金絲雀發(fā)布 - 逐漸將流量從老版本切換到新版本上。如果觀察一段時(shí)間后沒(méi)有發(fā)現(xiàn)問(wèn)題，就進(jìn)一步擴(kuò)大新版本流量，同時(shí)減少老版本上流量。
• A/B 測(cè)試 - 同時(shí)上線兩個(gè)或多個(gè)版本，收集用戶對(duì)這些版本的反饋，分析評(píng)估出最好版本正式采用。

隨著越來(lái)越多的應(yīng)用被容器化，如何方便地讓容器應(yīng)用平穩(wěn)順利升級(jí)受到了廣泛關(guān)注。本文將介紹 k8s 中不同部署形式下應(yīng)用的升級(jí)方法，并重點(diǎn)介紹如何對(duì) Deployment 中的應(yīng)用實(shí)施滾動(dòng)發(fā)布（本文所作的調(diào)研基于k8s 1.13）。

K8s 應(yīng)用升級(jí)

在 k8s 中，pod 是部署和升級(jí)的基本單位。一般來(lái)說(shuō)，一個(gè) pod 代表一個(gè)應(yīng)用實(shí)例，而 pod 又會(huì)以 Deployment、StatefulSet、DaemonSet、Job 等形式部署運(yùn)行，下面依次介紹在這些部署形式下 pod 的升級(jí)方法。

Deployment

Deployment 是 pod 最常見(jiàn)的部署形式，這里將以基于 spring boot 的 java 應(yīng)用為例進(jìn)行介紹。該應(yīng)用是基于真實(shí)應(yīng)用抽象出來(lái)的簡(jiǎn)單版本，非常具有代表性，它有如下特點(diǎn)：

• 應(yīng)用啟動(dòng)后，需要花費(fèi)一定的時(shí)間加載配置，在這段時(shí)間內(nèi)，無(wú)法對(duì)外提供服務(wù)。
• 應(yīng)用能夠啟動(dòng)并不意味著它能夠正常提供服務(wù)。
• 應(yīng)用如果無(wú)法提供服務(wù)不一定能自動(dòng)退出。
• 在升級(jí)過(guò)程中需要保證即將下線的應(yīng)用實(shí)例不會(huì)接收到新的請(qǐng)求且有足夠時(shí)間處理完當(dāng)前請(qǐng)求。

參數(shù)配置

為了讓具有上述特點(diǎn)的應(yīng)用實(shí)現(xiàn)零宕機(jī)時(shí)間和無(wú)生產(chǎn)中斷的升級(jí)，需要精心地配置 Deployment 中的相關(guān)參數(shù)。這里和升級(jí)有關(guān)的配置如下（完整配置參見(jiàn) spring-boot-probes-v1.yaml）。

kind: Deployment
...
spec:
  replicas: 8
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 2
  minReadySeconds: 120
  ...
  template:
    ...
    spec:
      containers:
      - name: spring-boot-probes
        image: registry.cn-hangzhou.aliyuncs.com/log-service/spring-boot-probes:1.0.0
        ports:
        - containerPort: 8080
        terminationGracePeriodSeconds: 60
        readinessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 1
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 40
          periodSeconds: 20
          successThreshold: 1
          failureThreshold: 3
        ...

配置 strategy

通過(guò) strategy 可以配置 pod 的替換策略，主要參數(shù)如下。

• .spec.strategy.type - 用于指定替換 pod 的策略類型。該參數(shù)可取值 Recreate 或 RollingUpdate，默認(rèn)為 RollingUpdate。

  • Recreate - K8s 會(huì)先刪掉全部原有 pod 再創(chuàng)建新的 pod。該方式適用于新老版本互不兼容、無(wú)法共存的場(chǎng)景。但由于該方式會(huì)造成一段時(shí)間內(nèi)服務(wù)完全不可用，在上述場(chǎng)景之外須慎用。
  • RollingUpdate - K8s 會(huì)將 pod 分批次逐步替換掉，可用來(lái)實(shí)現(xiàn)服務(wù)熱升級(jí)。
• .spec.strategy.rollingUpdate.maxSurge - 指定在滾動(dòng)更新過(guò)程中最多可創(chuàng)建多少個(gè)額外的 pod，可以是數(shù)字或百分比。該值設(shè)置得越大、升級(jí)速度越快，但會(huì)消耗更多的系統(tǒng)資源。
• .spec.strategy.rollingUpdate.maxUnavailable - 指定在滾動(dòng)更新過(guò)程中最多允許多少個(gè) pod 不可用， 可以是數(shù)字或百分比。該值設(shè)置得越大、升級(jí)速度越快，但服務(wù)會(huì)越不穩(wěn)定。

通過(guò)調(diào)節(jié) maxSurge 和 maxUnavailable，可以滿足不同場(chǎng)景下的升級(jí)需求。

• 如果您希望在保證系統(tǒng)可用性和穩(wěn)定性的前提下盡可能快地進(jìn)行升級(jí)，可以將 maxUnavailable 設(shè)置為 0，同時(shí)為 maxSurge 賦予一個(gè)較大值。
• 如果系統(tǒng)資源比較緊張，pod 負(fù)載又比較低，為了加快升級(jí)速度，可以將 maxSurge 設(shè)置為 0，同時(shí)為 maxUnavailable 賦予一個(gè)較大值。需要注意的是，如果 maxSurge 為 0，maxUnavailable 為 DESIRED，可能造成整個(gè)服務(wù)的不可用，此時(shí) RollingUpdate 將退化成停機(jī)發(fā)布。

樣例選擇了一個(gè)折中方案，將 maxSurge 設(shè)置為 3，將 maxUnavailable 設(shè)置為 2，平衡了穩(wěn)定性、資源消耗和升級(jí)速度。

配置探針

K8s 提供以下兩類探針：

• ReadinessProbe - 默認(rèn)情況下，一旦某個(gè) pod 中的所有容器全部啟動(dòng)，k8s 就會(huì)認(rèn)為該 pod 處于就緒狀態(tài)，從而將流量發(fā)往該 pod。但某些應(yīng)用啟動(dòng)后，還需要完成數(shù)據(jù)或配置文件的加載工作才能對(duì)外提供服務(wù)，因此通過(guò)容器是否啟動(dòng)來(lái)判斷其是否就緒并不嚴(yán)謹(jǐn)。通過(guò)為容器配置就緒探針，能讓 k8s 更準(zhǔn)確地判斷容器是否就緒，從而構(gòu)建出更健壯的應(yīng)用。K8s 保證只有 pod 中的所有容器全部通過(guò)了就緒探測(cè)，才允許 service 將流量發(fā)往該 pod。一旦就緒探測(cè)失敗，k8s 會(huì)停止將流量發(fā)往該 pod。
• LivenessProbe - 默認(rèn)情況下，k8s 會(huì)認(rèn)為處于運(yùn)行狀態(tài)下的容器是可用的。但如果應(yīng)用在出現(xiàn)問(wèn)題或不健康時(shí)無(wú)法自動(dòng)退出（例如發(fā)生嚴(yán)重死鎖），這種判斷就會(huì)出現(xiàn)問(wèn)題。通過(guò)為容器配置活性探針，能讓 k8s 更準(zhǔn)確地判斷容器是否正常運(yùn)行。如果容器沒(méi)有通過(guò)活性探測(cè)，kubelet 會(huì)將其停止，并根據(jù)重啟策略決定下一步的動(dòng)作。

探針的配置非常靈活，用戶可以指定探針的探測(cè)頻率、探測(cè)成功閾值、探測(cè)失敗閾值等。各參數(shù)的含義和配置方法可參考文檔 Configure Liveness and Readiness Probes。

樣例為目標(biāo)容器配置了就緒探針和活性探針：

• 就緒探針的 initialDelaySeconds 設(shè)置成 30，這是因?yàn)閼?yīng)用平均需要 30 秒時(shí)間完成初始化工作。
• 在配置活性探針時(shí)，需要保證容器有足夠時(shí)間到達(dá)就緒狀態(tài)。如果參數(shù) initialDelaySeconds、periodSeconds、failureThreshold 設(shè)置得過(guò)小，可能造成容器還未就緒就被重啟，以至于永遠(yuǎn)無(wú)法達(dá)到就緒狀態(tài)。樣例中的配置保證如果容器能在啟動(dòng)后的 80 秒內(nèi)就緒就不會(huì)被重啟，相對(duì) 30 秒的平均初始化時(shí)間有足夠的緩沖。
• 就緒探針的 periodSeconds 設(shè)置成 10，failureThreshold 設(shè)置成 1。這樣當(dāng)容器異常時(shí)，大約 10 秒后就不會(huì)有流量發(fā)往它。
• 活性探針的 periodSeconds 設(shè)置成 20，failureThreshold 設(shè)置成 3。這樣當(dāng)容器異常時(shí)，大約 60 秒后就不會(huì)被重啟。

配置 minReadySeconds

默認(rèn)情況下，一旦新創(chuàng)建的 pod 變成就緒狀態(tài) k8s 就會(huì)認(rèn)為該 pod 是可用的，從而將老的 pod 刪除掉。但有時(shí)問(wèn)題可能會(huì)在新 pod 真正處理用戶請(qǐng)求時(shí)才暴露，因此一個(gè)更穩(wěn)健的做法是當(dāng)某個(gè)新 pod 就緒后對(duì)其觀察一段時(shí)間再刪掉老的 pod。

參數(shù) minReadySeconds 可以控制 pod 處于就緒狀態(tài)的觀察時(shí)間。如果 pod 中的容器在這段時(shí)間內(nèi)都能正常運(yùn)行，k8s 才會(huì)認(rèn)為新 pod 可用，從而將老的 pod 刪除掉。在配置該參數(shù)時(shí)，需要仔細(xì)權(quán)衡，如果設(shè)置得過(guò)小，可能造成觀察不充分，如果設(shè)置得過(guò)大，又會(huì)拖慢升級(jí)進(jìn)度。樣例將 minReadySeconds 設(shè)置成了 120 秒，這樣能保證處于就緒狀態(tài)的 pod 能經(jīng)歷一個(gè)完整的活性探測(cè)周期。

配置 terminationGracePeriodSeconds

當(dāng) k8s 準(zhǔn)備刪除一個(gè) pod 時(shí)，會(huì)向該 pod 中的容器發(fā)送 TERM 信號(hào)并同時(shí)將 pod 從 service 的 endpoint 列表中移除。如果容器無(wú)法在規(guī)定時(shí)間（默認(rèn) 30 秒）內(nèi)終止，k8s 會(huì)向容器發(fā)送 SIGKILL 信號(hào)強(qiáng)制終止進(jìn)程。Pod 終止的詳細(xì)流程可參考文檔 Termination of Pods。

由于應(yīng)用處理請(qǐng)求最長(zhǎng)耗時(shí) 40 秒，為了讓其在關(guān)閉前能夠處理完已到達(dá)服務(wù)端的請(qǐng)求，樣例設(shè)置了 60 秒的優(yōu)雅關(guān)閉時(shí)間。針對(duì)不同的應(yīng)用，您可以根據(jù)實(shí)際情況調(diào)整 terminationGracePeriodSeconds 的取值。

觀察升級(jí)行為

上述配置能夠保證目標(biāo)應(yīng)用的平滑升級(jí)。我們可以通過(guò)更改 Deployment 中 PodTemplateSpec 的任意字段觸發(fā) pod 升級(jí)，并通過(guò)運(yùn)行命令kubectl get rs -w觀察升級(jí)行為。這里觀察到的新老版本的 pod 副本數(shù)的變化情況如下：

• 創(chuàng)建 maxSurge 個(gè)新 pod。這時(shí) pod 總數(shù)達(dá)到了允許的上限，即 DESIRED + maxSurge。
• 不等新 pod 就緒或可用，立刻啟動(dòng) maxUnavailable 個(gè)老 pod 的刪除流程。這時(shí)可用 pod 數(shù)為 DESIRED - maxUnavailable。
• 某個(gè)老 pod 被完全刪除，這時(shí)會(huì)立刻補(bǔ)充一個(gè)新 pod。
• 某個(gè)新 pod 通過(guò)了就緒探測(cè)變成了就緒態(tài)，k8s 會(huì)將流量發(fā)往該 pod。但由于未達(dá)到規(guī)定的觀察時(shí)間，該 pod 并不會(huì)被視作可用。
• 某個(gè)就緒 pod 在觀察期內(nèi)運(yùn)行正常被視作可用，這時(shí)可以再次啟動(dòng)某個(gè)老 pod 的刪除流程。
• 重復(fù)步驟 3、4、5 直到所有老 pod 被刪除，并且可用的新 pod 達(dá)到目標(biāo)副本數(shù)。

失敗回滾

應(yīng)用的升級(jí)并不總會(huì)一帆風(fēng)順，在升級(jí)過(guò)程中或升級(jí)完成后都有可能遇到新版本行為不符合預(yù)期需要回滾到穩(wěn)定版本的情況。K8s 會(huì)將 PodTemplateSpec 的每一次變更（如果更新模板標(biāo)簽或容器鏡像）都記錄下來(lái)。這樣，如果新版本出現(xiàn)問(wèn)題，就可以根據(jù)版本號(hào)方便地回滾到穩(wěn)定版本?；貪L Deployment 的詳細(xì)操作步驟可參考文檔 Rolling Back a Deployment。

StatefulSet

StatefulSet 是針對(duì)有狀態(tài) pod 常用的部署形式。針對(duì)這類 pod，k8s 同樣提供了許多參數(shù)用于靈活地控制它們的升級(jí)行為。好消息是這些參數(shù)大部分都和升級(jí) Deployment 中的 pod 相同。這里重點(diǎn)介紹兩者存在差異的地方。

策略類型

在 k8s 1.7 及之后的版本中，StatefulSet 支持 OnDelete 和 RollingUpdate 兩種策略類型。

• OnDelete - 當(dāng)更新了 StatefulSet 中的 PodTemplateSpec 后，只有手動(dòng)刪除舊的 pod 后才會(huì)創(chuàng)建新版本 pod。這是默認(rèn)的更新策略，一方面是為了兼容 k8s 1.6 及之前的版本，另一方面也是為了支持升級(jí)過(guò)程中新老版本 pod 互不兼容、無(wú)法共存的場(chǎng)景。
• RollingUpdate - K8s 會(huì)將 StatefulSet 管理的 pod 分批次逐步替換掉。它與 Deployment 中 RollingUpdate 的區(qū)別在于 pod 的替換是有序的。例如一個(gè) StatefulSet 中包含 N 個(gè) pod，在部署的時(shí)候這些 pod 被分配了從 0 開(kāi)始單調(diào)遞增的序號(hào)，而在滾動(dòng)更新時(shí)，它們會(huì)按逆序依次被替換。

Partition

可以通過(guò)參數(shù).spec.updateStrategy.rollingUpdate.partition實(shí)現(xiàn)只升級(jí)部分 pod 的目的。在配置了 partition 后，只有序號(hào)大于或等于 partition 的 pod 才會(huì)進(jìn)行滾動(dòng)升級(jí)，其余 pod 將保持不變。

Partition 的另一個(gè)應(yīng)用是可以通過(guò)不斷減少 partition 的取值實(shí)現(xiàn)金絲雀升級(jí)。具體操作方法可參考文檔 Rolling Out a Canary。

DaemonSet

DaemonSet 保證在全部（或者一些）k8s 工作節(jié)點(diǎn)上運(yùn)行一個(gè) pod 的副本，常用來(lái)運(yùn)行監(jiān)控或日志收集程序。對(duì)于 DaemonSet 中的 pod，用于控制它們升級(jí)行為的參數(shù)與 Deployment 幾乎一致，只是在策略類型方面略有差異。DaemonSet 支持 OnDelete 和 RollingUpdate 兩種策略類型。

• OnDelete - 當(dāng)更新了 DaemonSet 中的 PodTemplateSpec 后，只有手動(dòng)刪除舊的 pod 后才會(huì)創(chuàng)建新版本 pod。這是默認(rèn)的更新策略，一方面是為了兼容 k8s 1.5 及之前的版本，另一方面也是為了支持升級(jí)過(guò)程中新老版本 pod 互不兼容、無(wú)法共存的場(chǎng)景。
• RollingUpdate - 其含義和可配參數(shù)與 Deployment 的 RollingUpdate 一致。

滾動(dòng)更新 DaemonSet 的具體操作步驟可參考文檔 Perform a Rolling Update on a DaemonSet。

Job

Deployment、StatefulSet、DaemonSet 一般用于部署運(yùn)行常駐進(jìn)程，而 Job 中的 pod 在執(zhí)行完特定任務(wù)后就會(huì)退出，因此不存在滾動(dòng)更新的概念。當(dāng)您更改了一個(gè) Job 中的 PodTemplateSpec 后，需要手動(dòng)刪掉老的 Job 和 pod，并以新的配置重新運(yùn)行該 job。

總結(jié)

K8s 提供的功能可以讓大部分應(yīng)用實(shí)現(xiàn)零宕機(jī)時(shí)間和無(wú)生產(chǎn)中斷的升級(jí)，但也存在一些沒(méi)有解決的問(wèn)題，主要包括以下幾點(diǎn)：

• 目前 k8s 原生僅支持停機(jī)發(fā)布、滾動(dòng)發(fā)布兩類部署升級(jí)策略。如果應(yīng)用有藍(lán)綠發(fā)布、金絲雀發(fā)布、A/B 測(cè)試等需求，需要進(jìn)行二次開(kāi)發(fā)或使用一些第三方工具。
• K8s 雖然提供了回滾功能，但回滾操作必須手動(dòng)完成，無(wú)法根據(jù)條件自動(dòng)回滾。
• 有些應(yīng)用在擴(kuò)容或縮容時(shí)同樣需要分批逐步執(zhí)行，k8s 還未提供類似的功能。

實(shí)例配置：

livenessProbe:
  failureThreshold: 3
  httpGet:
    path: /user/service/test
    port: 8080
    scheme: HTTP
  initialDelaySeconds: 40
  periodSeconds: 20
  successThreshold: 1
  timeoutSeconds: 1
name: dataline-dev
ports:
  - containerPort: 8080
    protocol: TCP
readinessProbe:
  failureThreshold: 1
  httpGet:
    path: /user/service/test
    port: 8080
    scheme: HTTP
  initialDelaySeconds: 30
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 1

經(jīng)測(cè)試 ， 再對(duì)sprintboot 應(yīng)用進(jìn)行更新時(shí)， 訪問(wèn)不再出現(xiàn)502的報(bào)錯(cuò)。

更多關(guān)于阿里云k8s服務(wù)springboot項(xiàng)目應(yīng)用升級(jí)時(shí)出現(xiàn)502錯(cuò)誤技術(shù)文章請(qǐng)查看下面的相關(guān)鏈接