騰訊遊戲 K8s 應用實踐｜更貼近業務場景的 K8s 工作負載：GameDeployment & GameStatefulSet

引言

藍鯨容器服務（Blueking Container Service，以下簡稱BCS）是騰訊 IEG 互動娛樂事業群的容器上雲平臺，底層基於騰訊雲容器服務(Tencent Kubernetes Engine, TKE)，為 IEG 的自研遊戲業務上雲提供容器化和微服務化的建設工作。 區別於一般網際網路業務，騰訊遊戲業務具有大規模、低時延、網路敏感、超高可靠性要求等一系列眾多特點，大量使用共享記憶體通訊等技術，對雲原生上雲是一個巨大的挑戰。BCS 在服務於各遊戲業務的容器上雲過程中，結合業務需求與社群方案，開發了兩個增強版的 Kubernetes 工作負載 operator：GameStatefulSet 和 GameDeployment，更貼近業務場景，滿足複雜多樣的容器上雲需求。

遊戲業務特性的複雜性

遊戲類業務具有多種型別，如房間類遊戲、MMO 遊戲。無論是哪種型別的遊戲，都有諸如大規模的線上玩家、對網路時延和抖動異常敏感、多區多服等特點，遊戲後臺服務在設計時為了滿足這些需求，天然地會追求實時高速通訊、效能最大化，大量地使用了程式間共享記憶體通訊、資料預載入進記憶體、跨主機 TCP 通訊等技術，極少使用遠端資料、RPC，這其實與微服務的要求有點背道而馳。
結合容器化上雲的需求，總結來說，遊戲類服務一般具有以下特性：

• 大量地使用共享記憶體技術，偏有狀態服務。
• 超大規模，分割槽分服，需要能做到分批灰度釋出，為減少運維難度，最好能實現智慧式控制，控制釋出規模、速度、步驟。
• 例項擴縮容或更新時需要進行資料搬遷，不能馬上退出服務。
• 縮容一個例項前，需要先完成路由變更。如微服務名字通訊網格，在縮容一個例項前先要跟名字通訊網格的 controller 進行互動，確認是否已完成路由變更，再決定是否刪除例項。
• 開房間對局類遊戲在縮容或更新前，需要等待例項上的所有對局結束後，再退出服務。
• 為了保證平滑升級，有些遊戲後臺服務使用了程式 reload 技術，reload 過程中新版本的程式接替舊版本的程式提供服務，記憶體資料不丟失，升級過程中玩家無感知。

所有這些特點，對於 Kubernetes 和雲原生上雲都是巨大的挑戰。Kubernetes 原生適合微服務架構，把所有例項當作牲畜而不是寵物。即便是推出了 StatefulSet(最開始起名為 PetSet) 來支援有狀態服務，也只是給每個例項設定一個網路和儲存的編號，即使例項掛了，拉起一個相同編號的例項代替即可，並不涉及到共享記憶體丟失、資料搬遷、路由變更等複雜的流程。這也是後來 PetSet 被改名為 StatefulSet 的原因。
要支援遊戲這類複雜業務的上雲，我們需要更進一步，開發更貼合業務場景的 workload，降低業務接入的門檻和成本。

BCS New Workload: GameDeployment & GameStatefulSet

BCS 在服務於騰訊 IEG 眾多不同型別的包括但不限於遊戲業務的容器上雲過程中，與各遊戲業務及平臺探討業務場景，抽象業務共性和需求，同時積極學習和借鑑雲原生社群的優秀開源專案如 OpenKruise,argo-rollouts,flagger 等，在 Kubernetes 原生及其它開源專案的基礎上，研發了 bcs-gamedeployment-operator 和 bcs-gamestatefulset-operator 兩個 operator，分別對應 GameDeployment 和 GameStatefulSet 兩個增強版的 Kubernetes 工作負載，在原生的 Deployment 和 StatefulSet 基礎上實現了一系列增強的特性和效能提升，以滿足複雜業務的雲原生上雲需求。
GameDeployment 和 GameStatefulSet 雖然是在服務於遊戲業務的的場景中產生，但我們為其抽象出來的特性，其實能契合大多數型別業務特別是複雜業務的需求，更強的可控性，更貼近業務的研發和運維釋出場景，能極大提升雲原生上雲的能力。

GameDeployment

Kubernetes 原生的 Deployment 是面向無狀態服務的工作負載，其底層是基於 ReplicaSet 來實現，一個 Deployment 通過控制底層多個版本的 ReplicaSet 的版本數量來實現應用的滾動更新和回滾。
雖然是無狀態服務，大多數應用仍有 pod 原地升級、pod 映象熱更新(下文單獨)等其它一些需求，而原生的 Deployment 由於是基於多個版本的 ReplicaSet 迭代來實現，實現較為複雜，想要在其中新增原地升級等功能比較困難。
我們在借鑑原生的 Deployment 和 StatefulSet 的程式碼實現的基礎上，參考了其它開源專案，研發實現了一個增強版的 Deployment: GameDeployment，以滿足複雜的無狀態應用的更多高階需求。
相比 Deployment，GameDeployment 具有以下一些核心特性：

• 支援滾動更新 RollingUpdate。
• 支援 pod 原地升級
• 支援 pod 容器映象熱更新
• 支援 partition 灰度釋出
• 支援智慧式分步驟灰度釋出，可在灰度釋出步驟中加入 hook 校驗
• 支援刪除或更新 pod 前的 hook 校驗，以實現優雅的 pod 退出
• 支援原地重啟前的映象預拉取，以加快原地重啟的速度

apiVersion: tkex.tencent.com/v1alpha1
kind: GameDeployment
metadata:
  name: test-gamedeployment
  labels:
    app: test-gamedeployment
spec:
  replicas: 5
  selector:
    matchLabels:
      app: test-gamedeployment
  template:
    metadata:
      labels:
        app: test-gamedeployment
    spec:
      containers:
      - name: python
        image: python:3.5
        imagePullPolicy: IfNotPresent
        command: ["python"]
        args: ["-m", "http.server", "8000" ]
        ports:
        - name: http
          containerPort: 8000
  preDeleteUpdateStrategy:
    hook:
      templateName: test
  updateStrategy:
    type: InplaceUpdate
    partition: 1
    maxUnavailable: 2
    canary:
      steps:
        - partition: 3
        - pause: {}
        - partition: 1
        - pause: {duration: 60}
        - hook:
            templateName: test
        - pause: {}
    inPlaceUpdateStrategy:
      gracePeriodSeconds: 30

以上是一個示例的 GameDeployment yaml 配置，與 Deployment 的配置差別不大，大部分繼承 Deployment 的引數含義。我們將逐個介紹不同或新增之處：

• updateStrategy/type
  更新型別，支援 RollingUpdate(滾動更新),InplaceUpdate(原地升級),HotPatchUpdate(映象熱更新)三種更新策略。RollingUpdate 與 Deployment 的定義相同，下文我們將單獨介紹 InplaceUpdate 和 HotPatchUpdate。
• updateStrategy/partition
  相比 Deployment 新增的引數，用於實現灰度釋出，含義同 StatefulSet 的 partition。
• updateStrategy/maxUnavailable
  指在更新過程中每批執行更新的例項數量，在更新過程中這批例項是不可用的。比如一共有 8 個例項，maxUnavailable 設定為 2 ，那麼每批滾動或原地重啟 2 個例項，等這 2 個例項更新完成後，再進行下一批更新。可設定為整數值或百分比，預設值為 25% 。
• updateStrategy/maxSurge
  在滾動更新過程中，如果每批都是先刪除 maxUnavailable 數量的舊版本 pod 數，再新建新版本的 pod 數，那麼在整個更新過程中，總共只有 replicas - maxUnavailable 數量的例項數能夠提供服務。在總例項數較小的情況下，會影響應用的服務能力。設定 maxSurge 後，會在滾動更新前先多建立 maxSurge 數量的 pod，然後再逐批進行更新，所有例項更新完後再刪掉 maxSurge 數量的 pod ，這樣就能保證整個更新過程中可服務的總例項數量。
  maxSurge 預設值為 0 。
  因 InplaceUpdate 和 HotPatchUpdate 不會重啟 pod ，因此建議在這兩種更新策略的情況下無需設定 maxSurge 引數，只在 RollingUpdate 更新時設定。
• updateStrategy/inPlaceUpdateStrategy
  原地升級時的 gracePeriodSeconds 時間，詳見下文“InplaceUpdate 原地升級”的介紹。
• updateStrategy/canary
  定義分批灰度釋出的步驟，詳見下文“自動化分步驟灰度釋出”。
• preDeleteUpdateStrategy
  刪除或更新前 pod 前的 hook 策略，實現優雅地退出 pod。詳見下文“PreDeleteHook：優雅地刪除和更新 Pod”。

GameStatefulSet

Kubernetes 原生的 StatefulSet 是面向有狀態應用的工作負載，每個應用例項都有一個單獨的網路和儲存編號，例項在更新和縮容時是有序進行的。StatefulSet
為了面對上文描述的一些更為複雜的有狀態應用的需求，我們在原生的 StatefulSet 的基礎上，開發實現了增強版本： GameStatefulSet。
相比 StatefulSet, GameStatefulSet 主要包含以下新增特性：

• 支援 pod 原地升級
• 支援 pod 容器映象熱更新
• 支援並行更新，以提升更新(包括滾動更新、原地升級和映象熱更新)速度
• 支援智慧式分步驟灰度釋出，可在灰度釋出步驟中加入 hook 校驗
• 支援刪除或更新 pod 前的 hook 校驗，以實現優雅的 pod 退出
• 支援原地重啟前的映象預拉取，以加快原地重啟的速度

apiVersion: tkex.tencent.com/v1alpha1
kind: GameStatefulSet
metadata:
  name: test-gamestatefulset
spec:
  serviceName: "test"
  podManagementPolicy: Parallel
  replicas: 5
  selector:
    matchLabels:
      app: test
  preDeleteUpdateStrategy:
    hook:
      templateName: test
  updateStrategy:
    type: InplaceUpdate
    rollingUpdate:
      partition: 1
    inPlaceUpdateStrategy:
      gracePeriodSeconds: 30
    canary:
      steps:
      - partition: 3
      - pause: {}
      - partition: 1
      - pause: {duration: 60}
      - hook:
          templateName: test
      - pause: {}
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: python
        image: python:latest
        imagePullPolicy: IfNotPresent
        command: ["python"]
        args: ["-m", "http.server", "8000" ]
        ports:
        - name: http
          containerPort: 8000

以上是一個 GameStatefulSet 的 yaml 示例，相關引數介紹如下：

• podManagementPolicy
  支援 "OrderedReady" 和 "Parallel" 兩種方式，定義和 StatefulSet 一致，預設為 OrderedReady。與 StatefulSet 不同的是，如果配置為 Parallel，
  那麼不僅例項擴縮容是並行的，例項更新也是並行的，即自動並行更新。
• updateStrategy/type
  支援 RollingUpdate, OnDelete, InplaceUpdate, HotPatchUpdate 四種更新方式，相比原生 StatefulSet,新增 InplaceUpdate, HotPatchUpdate 兩種更新模式。
• updateStrategy/rollingUpdate/partition
  控制灰度釋出的數量，與 StatefulSet 含義一致。為了相容，InplaceUpdate 和 HotPatchUpdate 的灰度釋出數量也由這個引數配置。
• updateStrategy/inPlaceUpdateStrategy
  原地升級時的 gracePeriodSeconds 時間，詳見下文“InplaceUpdate 原地升級”的介紹。
• updateStrategy/canary
  定義分批灰度釋出的步驟，詳見下文“智慧式分步驟灰度釋出”。
• preDeleteUpdateStrategy
  刪除或更新前 pod 前的 hook 策略，實現優雅地退出 pod。詳見下文“PreDeleteHook：優雅地刪除和更新 Pod”。

功能特性與場景覆蓋

原地升級 InplaceUpdate

GameDeployment 和 GameStatefulSet 都支援 InplaceUpdate 更新策略。
原地升級是指，在更新 pod 版本時，保持 pod 的生命週期不變，只重啟 pod 中的一個或多個容器，因而在升級期間，pod 的共享記憶體 IPC 等能保持不丟失。使用原地升級的例項更新方式，有以下收益：

• pod 中有多個容器，容器之間通過共享記憶體通訊。升級時期望保持 pod 生命週期，只更新其中部分容器，IPC 共享記憶體不丟失，更新完成後 pod 繼續提供服務。
• 原生的滾動升級更新策略需要逐個或分批的刪掉舊版本例項，再建立新版本例項，效率很低。使用原地升級的方式，不需要重建 pod 例項，能大為提升釋出更新的速度。

Kubernetes 原生的 Deployment 和 StatefulSet 等工作負載都沒有直接支援原地升級的更新方式，但 kubelet 元件隱藏地支援了這一能力。針對一個處於 running 狀態的 Pod，我們只需要通過 patch 的方式更新 pod spec 中的 image 版本，kubelet 監控到了這一變化後，就會自動地殺掉對應的舊版本映象的容器並拉起一個新版本映象的容器，即實現了 Pod 的原地升級。
我們通過 ReadinessGate 和 inPlaceUpdateStrategy/gracePeriodSeconds 的結合，來實現原地升級當中的流量服務的平滑切換。

原地升級的更新策略下，可以配置 spec/updateStrategy/inPlaceUpdateStrategy/gracePeriodSeconds 引數，假設配置為 30 秒，那麼 GameStatefulSet/GameDeployment 在原地更新一個 pod 前，會通過 ReadinessGate 先把這個 pod 設定為 unready 狀態，30 秒過後才會真正去原地重啟 pod 中的容器。這樣，在這 30 秒的時間內因為 pod 變為 unready 狀態，k8s 會把該 pod 例項從 service 的 endpoints 中剔除。等原地升級成功後，GameStatefulSet/GameDeployment 再把該 pod 設為 ready 狀態，之後 k8s 才會重新把該 pod
例項加入到 service 的 endpoints 當中。
通過這樣的邏輯，在整個原地升級過程中，能保證服務流量的無損。
gracePeriodSeconds 的預設值為 0 ，當為 0 時，GameStatefulSet/GameDeployment 會立刻原地升級 pod 中的容器，可能會導致服務流量的丟失。
InplaceUpdate 同樣支援灰度釋出 partition 配置，用於配置灰度釋出的比例。

GameDeployment InplaceUpdate 使用示例
GameStatefulSet InplaceUpdate 使用示例

容器映象熱更新 HotPatchUpdate

原地升級更新策略雖然能保持 pod 的生命週期和 IPC 共享記憶體，但始終是要重啟容器的。對於遊戲對局類的 GameServer 容器，如有玩家正在進行對局服務，原地升級 GameServer 容器會中斷玩家的服務。
有些業務為了實現不停服更新，使用了服務程式 reload 技術，reload 過程中新版本的程式接替舊版本的程式提供服務，記憶體資料不丟失，升級過程中玩家無感知。
為了滿足這類業務的容器上雲需求，我們調研了 docker 映象 merge 的增量更新策略，修改 docker 原始碼增加了一個容器映象熱更新的介面。在對一個執行著的容器呼叫映象熱更新介面進行映象版本的更新時，容器的生命週期不變，容器內的程式也保持不變，但容器的基礎映象會替換為新的版本。
通過對 docker 的這種改動，對一個執行狀態的容器進行映象熱更新後，容器狀態不變，但其基礎映象的版本及資料已實現了增量更新。假如容器中的程式實現了 reload 功能，而基礎映象中的 so 檔案或配置都已更新為新版本，此時只需要往容器中的程式傳送 reload 訊號，就能完成服務程式的熱更新，實現不停服升級。
為了在 Kubernetes 中實現容器映象熱更新的能力，我們修改了 kubelet 的程式碼，在 kubelet 原地升級能力的基礎上，當 pod 中加了指定的 annotation 時，kubelet 對 pod 的更新就會從原地升級操作變為容器映象熱更新操作，呼叫 docker 的映象熱更新介面完成容器的映象熱更新。
關於在 docker 和 kubelet 上對容器映象熱更新的詳細實現，我們後續將在另外的文章中詳細闡述。

GameStatefulSet/GameDeployment 整合了容器映象熱更新的功能，當把 spec/updateStrategy/type 配置為 HotPatchUpdate 時，就會通過更新 pod 中的容器映象版本並新增 annotation 的方式，聯動 kubelet 和docker 完成容器映象熱更新的功能。在整個過程中，pod 及其容器的生命週期都是沒有變化的，此後，使用者可以通過向容器中程式傳送訊號的方式，完成業務程式的 reload，保證服務的不中斷。
HotPatchUpdate 同樣支援灰度釋出 partition 配置，用於配置灰度釋出的比例。

HotPatchUpdate 的更新策略需要結合我們定製化的 kubelet 和 docker 版本才能生效。
GameDeployment HotPatchUpdate 使用示例
GameStatefulSet HotPatchUpdate 使用示例

基於hook的應用互動式釋出

上文中我們提到，多數複雜類應用在釋出更新過程中有許多外部依賴或應用本身的資料指標依賴，如上面我們提到的：例項擴縮容或更新前需要進行資料搬遷；縮容一個例項前需要先完成路由變更；例項縮容或更新前需要等待遊戲對局結束。此外，在灰度釋出時，有時我們需要從 Prometheus 監控資料中檢視指標是否符合預期，以決定是否繼續灰度更多的例項。
這其實可以看作為應用釋出過程中的各種 hook 勾子，通過 hook 的結果來判斷是否可以繼續下一步的釋出流程。無論是面向無狀態應用的 GameDeployment 還是面向有狀態應用的 GameStatefulSet，都有這種釋出需求。
我們在深刻挖掘業務需求和調研解決方案後，在 Kubernetes 層面抽象出了一個通用的 operator: bcs-hook-operator。
bcs-hook-operator 主要職責是根據 hook 模板執行 hook 操作並記錄 hook 的狀態，GameDeployment 或 GameStatefulSet watch hook 的最終狀態，根據 hook 結果來決定下一步執行何種操作。

bcs-hook-operator 定義了兩種 CRD：

• HookTemplate

apiVersion: tkex.tencent.com/v1alpha1
kind: HookTemplate
metadata:
  name: test
spec:
  args:  
    - name: service-name
      value: test-gamedeployment-svc.default.svc.cluster.local
    - name: PodName
  metrics:
  - name: webtest
    count: 2
    interval: 60s
    failureLimit: 0
    successCondition: "asInt(result) < 30"
    provider:
      web:
        url: http://1.1.1.1:9091
        jsonPath: "{$.age}"

HookTemplate 用來定義一個 hook 的模板。在一個 HookTemplate 中可以定義多個 metric，每個 metric 都是需要執行的一個 hook。在 metric 中可以定義 hook 的次數、兩次之間的間隔、成功的條件、provider等等多個引數。provider 定義的是 hook 的型別，目前支援兩種型別的 hook：webhook 和 prometheus。

• HookRun

apiVersion: tkex.tencent.com/v1alpha1
kind: HookRun
metadata:
  name: test-gamedeployment-67864c6f65-4-test
  namespace: default
spec:
  metrics:
  - name: webtest
    provider:
      web:
        jsonPath: '{$.age}'
        url: http://1.1.1.1:9091
    successCondition: asInt(result) < 30
  terminate: true
status:
  metricResults:
  - count: 1
    failed: 1
    measurements:
    - finishedAt: "2020-11-09T10:08:49Z"
      phase: Failed
      startedAt: "2020-11-09T10:08:49Z"
      value: "32"
    name: webtest
    phase: Failed
  phase: Failed
  startedAt: "2020-11-09T10:08:49Z"

HookRun 是根據模板 HookTemplate 建立的一個實際執行的 hook CRD，bcs-hook-operator 監測並控制 HookRun 的執行狀態和生命週期，根據其 metrics 中的定義來執行 hook 操作，並實時記錄 hook 呼叫的結果。
關於 bcs-hook-operator 的更詳細介紹可參考：bcs-hook-operator

GameDeployment/GameStatefulSet 與 bcs-hook-operator 在應用釋出過程中使用 hook 時的互動架構圖：

自動化分步驟灰度釋出

GameDeployment & GameStatefulSet 支援智慧化的分步驟分批灰度釋出功能，允許使用者配置灰度釋出的自動化步驟，通過配置多個灰度釋出步驟，達到分批發布的目的，自動監測釋出的效果，實現灰度釋出的智慧化控制。
當前，可以在灰度釋出步驟中配置以下 4 種步驟：

• 灰度的例項個數，用 partition 來指定
• 永久暫停灰度，除非使用者手動觸發繼續後續步驟
• 暫停指定的時間後再繼續後續步驟
• Hook 呼叫，templateName 指定要使用的 HookTemplate，該 HookTemplate 必須已經在叢集中建立。
  GameDeployment&GameStatefulSet 會根據 HookTemplate 建立 HookRun，bcs-hook-operator 操縱並執行 HookRun。GameDeployment&GameStatefulSet watch HookRun 的狀態，如果結果滿足預期，則繼續執行後續的灰度步驟，如果返回結果不滿足預期，則暫停灰度釋出，必須由人工介入來決定是繼續後續灰度步驟還是進行回滾操作。
  下面的示例中，定義了灰度釋出的 6 個步驟：

...
spec:
  ...
  updateStrategy:
    type: InplaceUpdate
    rollingUpdate:
      partition: 1
    inPlaceUpdateStrategy:
      gracePeriodSeconds: 30
    canary:
      steps:
      - partition: 3            # 該批灰度釋出的個數
      - pause: {}               # 暫停釋出 
      - partition: 1            # 該批灰度釋出的個數
      - pause: {duration: 60}   # 暫停60秒後再繼續釋出
      - hook:                   # 定義 hook 步驟
          templateName: test    # 使用名為test的HookTemplate 
      - pause: {}               # 暫停釋出
 ...

在 GameDeployment 和 GameStatefulSet 上進行智慧式分步驟灰度釋出的配置和使用方式基本一致，詳細使用教程可參考：智慧式分步驟灰度釋出教程

PreDeleteHook：優雅地刪除和更新 Pod

在上文 “基於hook的應用互動式釋出” 章節我們提到，應用在釋出更新過程中有許多外部依賴或應用本身的資料指標依賴。特別是在縮容例項或升級例項版本時，需要刪掉舊版本的例項，但往往例項上仍然有服務不能中斷，如有玩家在進行遊戲對戰。此時，例項的縮容或更新是有依賴的，不能馬上進行縮容或更新，需要查詢條件，當條件滿足後再進行縮容或更新。
我們根據 bcs-hook-operator 的抽象，在 GameDeployment 和 GameStatefulSet 上開發了 PreDeleteHook 的功能，實現優雅地刪除和更新應用 Pod 例項。

apiVersion: tkex.tencent.com/v1alpha1
...
spec:
  preDeleteUpdateStrategy:     
    hook:
      templateName: test        # 使用的HookTemplate
  updateStrategy:
    ...
    inPlaceUpdateStrategy:
      gracePeriodSeconds: 30

在 GameDeployment/GameStatefulSet 的 spec/preDeleteUpdateStrategy 中指定 HookTemplate，那麼當縮容或更新 Pod 例項時，針對每一個待刪除或更新的 Pod，GameDeployment/GameStatefulSet 都會根據 HookTemplate 模板建立一個 HookRun，然後 watch 這個 HookRun 的狀態。bcs-hook-operator 控制 HookRun 的執行並實時記錄其狀態。當 HookRun 執行完成後，GameDeployment/GameStatefulSet watch 到其最終狀態，依據其最終狀態來決定是否能正常刪除或更新 Pod。

更進一步地，我們在 HookTemplate 和 HookRun 中支援了一些常見引數的自動渲染，如 PodName, PodNamespace, PodIP 等。
例如，假設 PreDeleteHook 中需要執行的 hook 是應用例項本身的一個 http 介面，暴露在容器的 8080 埠，那麼我們可以定義這樣一個 HookTemplate:

apiVersion: tkex.tencent.com/v1alpha1
kind: HookTemplate
metadata:
  name: test
spec:
  args:
    - name: PodIP
  metrics:
    - name: webtest
      count: 3
      interval: 60s
      failureLimit: 2
      successCondition: "asInt(result) > 30"
      provider:
        web:
          url: http://{{ args.PodIP }}:8080
          jsonPath: "{$.age}"

這樣，GameDeployment/GameStatefulSet 在針對待刪除或更新的 Pod 建立 HookRun 時，會把 Pod IP 渲染進 webhook url 中，最終建立和執行的是對應用 Pod 本身提供的 http 介面的 webhook 呼叫。

在 GameDeployment 和 GameStatefulSet 上進行 PreDeleteHook 的配置和使用方式基本一致，詳細使用教程可參考：PreDeleteHook：優雅地刪除和更新 Pod

映象預熱

使用 Pod 原地升級是為了最大程度上提升釋出的效率，並減少服務中斷的時間。但一個 Pod 的原地升級過程中，最大的時間消耗在於拉取新版本映象的時間，特別是當映象很大的時候。
因此，業務在使用原地升級的過程中，向我們反饋的最多的問題就是原地升級的速度仍然過慢，與理想中的速度有差距。
基於此，我們與歡樂遊戲工作室的公共支援團隊合作共建了 GameStatefulSet&GameDeployment 的原地升級映象預熱方案。
以 GameDeployment 為例，映象預熱方案的流程架構如下圖所示：

• 1 . 使用者觸發 GameDeployment 原地升級。
• 2 . kube-apiserver 通過 admission webhook 攔截到請求，交由 bcs-webhook-server 處理。
• 3 . bcs-webhook-server 判斷為使用者觸發原地升級，修改 GameDeployment 的內容，把映象版本 patch 為原來版本，並在 annotations 中增加一個新版本映象的 patch。
• 4 . bcs-webhook-server 使用新版本的映象在所有執行有這個應用例項的節點上建立一個 Job，並 watch 這些 Job 的狀態。Job 執行時就會拉取新版本的映象。
• 5 . bcs-webhook-server 監測到所有 Job 執行結果後，修改 GameDeployment 的內容，把 annotations 中的新版本映象的 patch 刪除，並把映象版本 patch 為新版本的映象，觸發真正的原地升級。然後，清除掉執行完成的 Job。
• 6 . bcs-gamedeployment-operator watch 到真正的原地升級後，執行原地升級的更新策略。

使用這個方案，能保證 Kubernetes 工作負載 GameDeployment&GameStatefulSet 與映象預熱方案的解耦，假設要支援更多的 Kubernetes 工作負載的映象預熱，只需要在 bcs-webhook-server 上新增對這個工作負載 CRD 的支援即可。
基於此，我們重構開發了 bcs-webhook-server，支援以外掛化的方式新增 webhook：

映象預熱方案及 bcs-webhook-server 的更多實現細節，請參考：bcs-webhook-server

總結

BCS 團隊在基於 TKE 構建雲原生上雲平臺的過程中，與不同業務團隊進行探討，挖掘業務需求，抽象需求共性，並結合社群的開源方案，研發了 GameDeployment 和 GameStatefulSet 這兩個 Kubernetes 工作負載。這兩個工作負載及其特性雖然是為複雜的遊戲業務上雲而產生，但基本能覆蓋大多數網際網路業務的需求，更貼近各種業務的運維和釋出場景。
後續，我們也將繼續與各業務團隊進行探討和合作，抽象更多需求特性，不斷迭代，持續增強 GameStatefulSet 和 GameDeployment 的能力。
藍鯨容器服務 BCS 已經開源，更多容器上雲方案和細節請參考我們的開源專案：BK-BCS

感謝以下協作開發者 Committer

• stonewesley
• pang1567

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！