騰訊遊戲 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

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