騰訊游戲 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 為例，鏡像預熱方案的流程架構如下圖所示：
闀滃儚棰勭儹.png

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

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

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/235013.html

標籤：其他

上一篇：容器網路（八）flannel 的連通與隔離【56】

下一篇：容器網路（八）flannel 的連通與隔離【56】