Kubernetes在微服務化遊戲中的探索實踐

隨著Kubernetes的持續火熱，那在線遊戲領域又將如何使用，又將碰到哪些問題，以及帶來哪些價值？ 本次分享將為大家介紹微服務化架構遊戲領域中，Kubernetes支撐技術方案選型，功能優化以及實踐過程中的一些思考。

微服務化遊戲容器化探索

隨著Docker技術在近幾年的快速發展，國內外掀起了一股容器之風。而我們也在這時，開啟了遊戲容器化的探索之路。最開始在Docker容器的應用上，還是以VM的模式去部署，畢竟遊戲是非常複雜的應用，沒有統一的模式。除此之外，對於一項全新技術的應用，大家都很謹慎，一步一步地去實踐。

而在近一兩年，部分遊戲的架構也逐漸往微服務化方向轉變，以下是一款遊戲的架構：遊戲的邏輯層按不同的服務劃分為不同的模塊，每個模塊都是高內聚低耦合，之間的通信通過消息隊列（或者API）來實現。模塊的版本通過CI/CD，實現鏡像標準交付，快速部署。在這些模塊中，大部分是無狀態服務，很容易實現彈性伸縮。

我們再來看另一款微服務化遊戲的架構：也是按功能模塊劃分不同的服務，前端通過HAProxy來代理用戶請求，後端服務可以根據負載來實現擴縮容。在服務發現模塊中，通過Registrator來監視容器的啟動和停止，根據容器暴露的埠和環境變數自動註冊服務，後端存儲使用了Consul，結合consul-template來發現服務的變化時，可以更新業務配置，並重載。

對於這些微服務化的遊戲，服務模塊小且多。那麼，怎樣快速部署，怎樣彈性伸縮，怎樣實現服務發現等等，都是我們需要解決的問題。容器化這些服務是一個不錯的方案，接下來就是容器調度、編排平台的建設了。在當前也有多種方案可選，Mesos、Swarm等，而我們沿用了Kubernetes做來容器的整個調度管理平台，這也得利於之前VM模式下Kubernetes的成功應用。不同的是我們選擇了高版本的Kubernetes，無論從功能的豐富上，性能的提升上，穩定性，可擴展性上來說，都有絕對的優勢。以下會從幾個維度來分析Kubernetes在微服務化遊戲上的實踐。

基於Kubernetes的解決方案

定製的網路與調度方案

集群的網路方案，是最為複雜，也是最為基礎的一項。結合業務各模塊之間的訪問關係，我們選定的方案如下：

集群內各模塊之間的通信：Overlay網路

我們基於Flannel來實現Overlay網路，每個主機擁有一個完整的子網，在這個扁平化的網路裡面，管理簡單。當我們創建容器的時候，會為容器分配一個唯一的虛擬IP，容器與容器之間（甚至母機與容器之間）可以方便地通信。當然，在實現中，業務也並非單純的用IP來訪問，而是結合DNS服務，通過域名來訪問，後面會講到。

以下是基於Flannel實現的Overlay網路的通信案例：

假設當sshd-2訪問nginx-0：當packet 到達docker0時，根據node1上的路由規則，選對flannel.1作為出口，同時，根據iptables SNAT規則，將packet的源IP地址改為flannel.1的地址(172.16.28.0/12)。flannel.1是一個VXLAN設備，將packet進行隧道封包，然後發到node2。node2解包，然後根據node2上的路由規則，從介面docker0出發，再轉給nginx-0。最終實現通信。

公司內網到集群內模塊的通信：sriov-cni

sriov-cni是我們基於CNI定製的一套SRIOV網路方案，而CNI作為Kubernetes Network Plugins，插件式接入，非常方便，目前已開源，地址：https://github.com/hustcat/sriov-cni。

以下是SRIOV網路拓撲圖與實現細節：

母機上開啟SRIOV功能，同時向公司申請子機IP資源，每個VF對應一個子機IP。

Kubernetes在調度時，為每個Pod分配一個VF與子機IP。

在Pod拿到VF與IP資源，進行綁定設置後，就可以像物理網卡一樣使用。

同時我們也做了一些優化：包括VF中斷CPU綁定同時關閉物理機的irqbalance功能，容器內設置RPS，把容器內的中斷分到各個CPU處理，來提升網路性能。

此類容器除了SRIOV網路之外，還有一個Overlay網路介面，也即是多重網路，可以把公司內網流量導入到Overlay集群中，實現集群內外之間的通信。在實際應用中，我們會用此類容器來收歸通往集群內的通信，例如我們用HAProxy LB容器來提供服務。

對接公網：採用公司的TGW方案

TGW接入時，需要提供物理IP，所以對接TGW都會用到SRIOV網路的容器，例如上面提到的HAProxy LB容器。這樣公網通過TGW訪問haproxy，再由haproxy轉到集群內容器，從而打通訪問的整個鏈路。

集群內模塊訪問公司內網通信：NAT方案

調度：

在上述網路方案中，我們講到SRIOV需要綁定物理IP，所以在容器調度中，除了Kubernetes原生提供的CPU＼Memory＼GPU之外，我們還把網路（物理IP）也作為一個計算資源，同時結合Kubernetes提供的extender scheduler介面，我們定製了符合我們需求的調度程序（cr-arbitrator）。其結構如下：

cr-arbitrator做為extender scheduler，集成到Kubernetes中，包括兩部分內容：

預選演算法：

在完成Kuernetes的predicates調度後，會進入到cr-arbitrator的預選調度演算法，我們以網路資源為例，會根據創建的容器是否需要物理IP，從而計算符合條件的node（母機）。

優選演算法：

在整個集群中，需要物理IP的容器與Overlay網路的容器並未嚴格的劃分，而是採用混合部署方式，所以在調度Overlay網路的容器時，需要優化分配到沒有開啟sriov的node上，只有在資源緊張的情況下，才會分配到sriov的node上。

除了cr-arbitrator實現的調度策略外，我們還實現了CPU核綁定。可以使容器在其生命周期內使用固定的CPU核，一方面是避免不同遊戲業務CPU搶佔問題；另一方面在穩定性、性能上（結合NUMA）得到保障及提升，同時在遊戲業務資源核算方面會更加的清晰。

域名服務與負載均衡

在網路一節，我們講到Kubernetes會為每個Pod分配一個虛擬的IP，但這個IP是非固定的，例如Pod發生故障遷移後，那麼IP就會發生變化。所以在微服務化遊戲架構下，業務模塊之間的訪問更多地採用域名方式進行訪問。在Kubernetes生態鏈中，提供了SkyDNS作為DNS伺服器，可以很好的解決域名訪問問題。

在Kubernetes集群中，業務使用域名訪問有兩種方式：

負載均衡

通常情況下，遊戲的一個模塊可以通過deployment或者是replication controller來創建多個pod（即多組服務），同時這些容器又需要對外提供服務。如果給每個pod都配置一個公司內網IP，也是可以解決，但帶來的問題就是物理IP資源浪費，同時無法做到負載均衡，以及彈性伸縮。因此，我們需要一個穩固、高效的Loadbalancer方案來代理這些服務，其中也評估了Kubernetes的service方案，不夠成熟，在業務上應用甚少。剛好Kubernetes的第三方插件service-loadbalancer提供了這方面的功能，它主要是通過haproxy來提供代理服務，而且有其它在線遊戲也用了haproxy，所以我們選擇了service-loadbalancer。

service-loadbalancer除了HAProxy服務外，還有一個servicelb服務。servicelb通過Kubernetes的master api來時時獲取對應Pod信息（IP和port)，然後設置HAProxy的backends，再reload haproxy進程，從而保證HAProxy提供正確的服務。

監控與告警

監控、告警是整個遊戲運營過程中最為核心的功能之一，在遊戲運行過程中，對其性能進行收集、統計與分析，來發現遊戲模塊是否存在問題，負載是否過高，是否需要擴縮容之類等等。在監控這一塊，我們在cAdvisor基礎上進行定製，其結構如下：

每個母機部署cAdvisor程序，用於收集母機上容器的性能數據，目前包括CPU使用情況、memory、網路流量、TCP連接數。

在存儲方面，目前直接寫入到TenDis中，後續如果壓力太大，還可以考慮在TenDis前加一層消息隊列，例如Kafka集群。

Docker-monitor，是基於cAdvisor收集的數據而實現的一套性能統計與告警程序。在性能統計方面，除了對每個容器的性能計算外，還可以對遊戲的每個服務進行綜合統計分析，一方面用於前端用戶展示，另一方面可以以此來對服務進行智能擴縮容。告警方面，用戶可以按業務需求，配置個性化的告警規則，docker-monitor會針對不同的告警規則進行告警。

日誌收集

Docker在容器日誌處理這一塊，目前已很豐富，除了默認的json-file之外，還提供了gcplogs、awslogs、fluentd等log driver。而在我們的日誌系統中，還是簡單的使用json-file，一方面容器日誌並非整個方案中的關鍵節點，不想因為日誌上的問題而影響Docker的正常服務；另一方面，把容器日誌落地到母機上，接下來只需要把日誌及時採集走即可，而採集這塊方案可以根據情況靈活選擇，可擴展性強。我們當前選擇的方案是Filebeat + Kafka + Logstash + Elasticsearch，其結構如下：

我們以DaemonSet方式部署Filebeat到集群中，收集容器的日誌，並上報到Kafka，最後存儲到Elasticsearch集群，整個過程還是比較簡單。而這裡有個關鍵點，在業務混合部署的集群中，通過Filebeat收集日誌時怎樣去區分不同的業務？而這恰恰是做日誌許可權管理的前提條件，我們只希望用戶只能查看自己業務的日誌。以下是具體的處理方案與流程：

首先我們在Docker日誌中，除了記錄業務程序的日誌外，還會記錄容器的name與namespace信息。

接著我們在Filebeat的Kafka輸出配置中，把namespace作為topic進行上報，最終對應到Elasticsearch的index。

在我們的平台中，一個namespace只屬於一個業務，通過namespace，可以快速的搜索到業務對應的日誌，通過容器的name，可以查看業務內每個模塊的日誌。

基於image的發布擴容

在微服務化遊戲中，模塊與模塊之間是高內聚低偶合，模塊的版本內容一般都會通過持續集成來構建成一個個鏡像（即image），然後以image來交付、部署。同時，遊戲版本發布都有一個時間窗，整個發布流程都需要在這個時間窗里完成，否則就會影響用戶體驗。怎樣做到版本的高效發布? 這裡有兩個關鍵點：一是基於Kubernetes的發布有效性；一是image下發效率；

Kubernetes在容器image發布這一塊的支持已比較穩定，對於無狀態的服務，還可以考慮rolling-update方式進行，使遊戲服務近乎無縫地平滑升級，即在不停止對外服務的前提下完成應用的更新。

在提高image下發效率方面，我們基於Distribution打造了一個企業級鏡像中心，主要涉及到以下幾點：

Ceph集群提供穩定、強大的後端數據存儲。

性能優化：mirror方案與P2P方案，實現快速的下載鏡像。同時對於時效性更高的用戶需求，還可以實現image預部署方案。

安全方面：不同類型用戶不同的許可權驗證方案。例如公司內部用戶會提供安全認證，其它用戶提供用戶名密碼認證。

Notification Server實現pullpush日誌記錄，便於後續分析與審計。

以上便是Kubernetes在微服務化遊戲中的一個解決方案，定製的網路與調度方案，為遊戲容器的運行提供基礎環境；域名服務與負載均衡，解決遊戲高可用、彈性伸縮問題；通過性能數據、日誌的收集、統計分析，及時發現程序問題與性能瓶頸，保證遊戲容器穩定、可持續性運行；最後，基於image的發布擴容，使得遊戲部署流程更加標準化以及高效。

Q&A

Q：CPU核綁定，能說下實現的細節嗎？

A：在創建容器的時候，通過Kubernetes的resources項指定所需的CPU核數，再由scheduler調度到具體的母機上。我們對kubelet進行了改造，增加了CPU核計算與綁定邏輯，主要有兩方面：一是計算母機上空閑的CPU核並分配到當前的容器；另一個是結合NUMA的cache機制，儘可能的把同一個NUMA node的CPU核分配給容器，從而提高性能。

Q：存儲方面一筆帶過了，文中提到把數據直接寫到tendis ，都包含哪些業務數據呢？另外，Tendis的driver 已經開源了么？

A： Tendis是基於RocksDB和Twemproxy的Redis集群方案，提供高效的，可線性擴展，數據落地硬碟的Cache集群服務。和TenDB， TenDB cluster一起是騰訊遊戲的Ten系列資料庫解決方案。Tendis目前暫時沒有開源。Tendis存儲了容器的元數據，例如容器的名稱，UID，狀態信息，性能數據包括了CPU使用率、內存使用情況，TCP連接數，網路流量等。

Q：service loadblance如何實現的能詳細介紹下嗎？

A： service loadblance由兩部分組成，一個是HAProxy程序，一個是service LB程序。其中servie LB程序通過訪問k8s master api的watch serviceendpoint的變化，得到當前正常服務的容器IP+port信息，然後把這些容器的IP+port綁定到HAProxy的backends，再reload haproxy程序，從而確保HAProxy的backends是最新的

Q：鏡像mirror方案與P2P方案能簡單介紹下實現技術方案嗎？

A：mirror方案如下圖，我們會在主要城市部署mirror節點，用於緩存鏡像，這樣在pull鏡像的時候就可以從最近城市來拉取。

P2P方案：其結構如下圖：

3 天燒腦式容器存儲網路訓練營

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！