藍鲸容器服務（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 在服務于騰訊 IEG 衆多不同類型的包括但不限于遊戲業務的容器上雲過程中，與各遊戲業務及平台探讨業務場景，抽象業務共性和需求，同時積極學習和借鑒雲原生社群的優秀開源項目如 OpenKruise,argo-rollouts,flagger 等，在 Kubernetes 原生及其它開源項目的基礎上，研發了 bcs-gamedeployment-operator 和 bcs-gamestatefulset-operator 兩個 operator，分别對應 GameDeployment 和 GameStatefulSet 兩個增強版的 Kubernetes 工作負載，在原生的 Deployment 和 StatefulSet 基礎上實作了一系列增強的特性和性能提升，以滿足複雜業務的雲原生上雲需求。
GameDeployment 和 GameStatefulSet 雖然是在服務于遊戲業務的的場景中産生，但我們為其抽象出來的特性，其實能契合大多數類型業務特别是複雜業務的需求，更強的可控性，更貼近業務的研發和運維釋出場景，能極大提升雲原生上雲的能力。
Kubernetes 原生的 Deployment 是面向無狀态服務的工作負載，其底層是基于 ReplicaSet 來實作，一個 Deployment 通過控制底層多個版本的 ReplicaSet 的版本數量來實作應用的滾動更新和復原。
雖然是無狀态服務，大多數應用仍有 pod 原地更新、pod 鏡像熱更新(下文單獨)等其它一些需求，而原生的 Deployment 由于是基于多個版本的 ReplicaSet 疊代來實作，實作較為複雜，想要在其中添加原地更新等功能比較困難。
我們在借鑒原生的 Deployment 和 StatefulSet 的代碼實作的基礎上，參考了其它開源項目，研發實作了一個增強版的 Deployment: GameDeployment，以滿足複雜的無狀态應用的更多高階需求。
相比 Deployment，GameDeployment 具有以下一些核心特性：
支援滾動更新 RollingUpdate。
支援 pod 原地更新
支援 pod 容器鏡像熱更新
支援 partition 灰階釋出
支援智能式分步驟灰階釋出，可在灰階釋出步驟中加入 hook 校驗
支援删除或更新 pod 前的 hook 校驗，以實作優雅的 pod 退出
支援原地重新開機前的鏡像預拉取，以加快原地重新開機的速度
以上是一個示例的 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”。
Kubernetes 原生的 StatefulSet 是面向有狀态應用的工作負載，每個應用執行個體都有一個單獨的網絡和存儲編号，執行個體在更新和縮容時是有序進行的。StatefulSet
為了面對上文描述的一些更為複雜的有狀态應用的需求，我們在原生的 StatefulSet 的基礎上，開發實作了增強版本： GameStatefulSet。
相比 StatefulSet, GameStatefulSet 主要包含以下新增特性：
支援并行更新，以提升更新(包括滾動更新、原地更新和鏡像熱更新)速度
以上是一個 GameStatefulSet 的 yaml 示例，相關參數介紹如下：
podManagementPolicy
支援 "OrderedReady" 和 "Parallel" 兩種方式，定義和 StatefulSet 一緻，預設為 OrderedReady。與 StatefulSet 不同的是，如果配置為 Parallel，
那麼不僅執行個體擴縮容是并行的，執行個體更新也是并行的，即自動并行更新。
支援 RollingUpdate, OnDelete, InplaceUpdate, HotPatchUpdate 四種更新方式，相比原生 StatefulSet,新增 InplaceUpdate, HotPatchUpdate 兩種更新模式。
updateStrategy/rollingUpdate/partition
控制灰階釋出的數量，與 StatefulSet 含義一緻。為了相容，InplaceUpdate 和 HotPatchUpdate 的灰階釋出數量也由這個參數配置。
定義分批灰階釋出的步驟，詳見下文“智能式分步驟灰階釋出”。
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 使用示例
原地更新更新政策雖然能保持 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 使用示例
上文中我們提到，多數複雜類應用在釋出更新過程中有許多外部依賴或應用本身的資料名額依賴，如上面我們提到的：執行個體擴縮容或更新前需要進行資料搬遷；縮容一個執行個體前需要先完成路由變更；執行個體縮容或更新前需要等待遊戲對局結束。此外，在灰階釋出時，有時我們需要從 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
HookTemplate 用來定義一個 hook 的模闆。在一個 HookTemplate 中可以定義多個 metric，每個 metric 都是需要執行的一個 hook。在 metric 中可以定義 hook 的次數、兩次之間的間隔、成功的條件、provider等等多個參數。provider 定義的是 hook 的類型，目前支援兩種類型的 hook：webhook 和 prometheus。
HookRun
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 個步驟：
在 GameDeployment 和 GameStatefulSet 上進行智能式分步驟灰階釋出的配置和使用方式基本一緻，詳細使用教程可參考：智能式分步驟灰階釋出教程
在上文 “基于hook的應用互動式釋出” 章節我們提到，應用在釋出更新過程中有許多外部依賴或應用本身的資料名額依賴。特别是在縮容執行個體或更新執行個體版本時，需要删掉舊版本的執行個體，但往往執行個體上仍然有服務不能中斷，如有玩家在進行遊戲對戰。此時，執行個體的縮容或更新是有依賴的，不能馬上進行縮容或更新，需要查詢條件，當條件滿足後再進行縮容或更新。
我們根據 bcs-hook-operator 的抽象，在 GameDeployment 和 GameStatefulSet 上開發了 PreDeleteHook 的功能，實作優雅地删除和更新應用 Pod 執行個體。
在 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:
這樣，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
stonewesley
pang1567
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆号，及時擷取更多幹貨！！騰訊遊戲 K8s 應用實踐｜更貼近業務場景的 K8s 工作負載：GameDeployment & GameStatefulSet