騰訊遊戲 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: //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: //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: //{{ 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
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多乾貨！！
