騰訊遊戲容器雲平台的技術演進之路

作者｜郭蕾

嘉賓｜尹燁

從 2014 年開始，騰訊遊戲就逐步在生產環境中使用容器相關技術，到現在，代號為 TenC 的容器平台支撐了近 200 款遊戲的運營。在這 3 年的時間裡，整個平台經歷了從最開始的「輕量級虛擬機」使用 Docker 的方式，到現在的原生容器雲方式的迭代，接入的業務也由原來的在線服務擴展到現在的微服務、大數據、機器學習等類型。

2015 年時，InfoQ 記者曾對騰訊遊戲進行過一次專訪，在提到容器對於遊戲業務的價值時，騰訊遊戲高級工程師尹燁這樣說道：「相比其他行業，遊戲業務更為複雜多樣，有端游、手游、頁游之分，同時，還要分區和分服，甚至還要區分自研和代理。這些特性給運維和部署帶來了諸多不便，而 Docker 統一的鏡像分發方式，可以標準化程序的分發部署，提高交付效率。另外，遊戲業務的生命周期長短不一，這也就需要彈性的資源管理和交付，而容器更加輕量，資源的交付和銷毀更快。」

而在當時，Kubernetes 剛剛發布 1.0 版本，尹燁也表示他們對於 Kubernetes 的應用還沒有完全發揮其優勢，接下來一段時間，他們也會探索容器平台與業務開發、運維的結合方式。那在時過境遷的兩年之後，騰訊遊戲在容器平台的實踐方面又有哪些經驗和心得？InfoQ 記者再一次採訪了尹燁。另外，尹燁也將會在 CNUTCon 全球運維技術大會 上與參會者分享他們的經驗教訓。

InfoQ：2014 年的時候騰訊遊戲就開始在生產環境中使用了 Docker，到現在已有 3 年時間。能否談談你們從最初的簡單使用 Docker 到現在的容器雲平台，這中間你們大致經歷了哪幾個階段？

尹燁：現在我們的 Docker 容器平台（內部代號：TenC）主要支撐了如下三種類型的業務場景，也基本上對應了平台發展的三個階段，每個階段都是緊隨著業務的需求在推進。

第一階段：我們把容器當作輕量虛擬機來給業務使用，讓業務程序不需要特殊修改，就可以在容器中正常運行起來，我們花了很多精力來兼容原有業務架構和使用習慣，以及保證底層運行環境的穩定運行；

第二階段：後來在代理遊戲中，出現一些微服務架構的業務，這些業務完全採用原生的 Docker 方式，基於 Docker 鏡像來做分發和部署，彈性伸縮；

第三階段： 再後來隨著大數據和 AI 興起，這類業務計算量非常大，資源需求要求高彈性，使用 Docker 容器來交付資源相對於原來物理機、虛擬機方式效率高很多。

InfoQ：目前騰訊遊戲有多少的業務跑在容器雲上？可否談下你們的容器雲技術棧？

尹燁：目前有過百款遊戲業務都運行在容器上。在遊戲業務接入容器平台前，會有一些評估要素。評估通過的話，新業務基本上會首選放到容器里。我們的平台主要基於 Docker、Kubernetes（後面簡稱 K8s）等開源組件開發的。當前 Docker 主要使用了 1.12 的版本，Kubernetes 主要使用 1.2/ 1.5 版本。在實際的應用過程中，我們會基於我們自身的基礎環境做一些二次定製開發，包括資源調度和網路部分，例如我們自己開發的 SR-IOV CNI 插件等。 整體結構大致如下：

其中 TLinux 是騰訊操作系統團隊自研的伺服器操作系統，操作系統團隊針對 Docker 平台需求，進行了一系列內核特性研發和針對性改進。TLinux 為遊戲在 Docker 容器上的穩定運行奠定了基礎。例如，

cgroup 高版本特性移植，如 cgroup namespace, pids cgroup, cgroup 支持 IO 隔離等；

aufs、overlayfs 特性移植；網路 sysctl 隔離；

其他諸如 cgroup、overlayfs、xfs 等等的 bug 修復。

InfoQ：記得 2015 年的時候你們是基於 Kubernetes 0.4 版本做的改造，現在 Kubernetes 也跟著升級了？升級之後之前哪些改動是怎麼處理的？現在還有基於主幹版本做定製嗎？

尹燁：2014 年我們開始使用 Docker 時，Google 剛剛開源了 K8s， K8s 的設計非常精巧，我們就開始做了一些定製，來管理容器。我們現在還在使用那個古老的深度定製版本來管理我們的輕量級虛擬機容器，因為這類業務對編排沒什麼需求，為了保證平台的穩定，一直沒有升級，將來也不太會。但針對微服務和離線計算這部分業務，我們沒有太多侵入式的定製修改 K8s，主要通過插件方式來擴展 K8s，我們會根據自身的需求來跟隨社區升級 K8s。

在功能定製方面， 先大概介紹幾點吧。比如，我們結合業務需求，和自身的基礎環境，主要在調度和網路等方面進行了一些擴展。首先，在網路方面，我們開發了 SRIOV CNI 插件。

（1）母機上開啟 SRIOV 功能，同時向網管系統申請子機 IP 資源，每個 VF 對應一個子機 IP。

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

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

同時我們也做了一些優化：比如將 VF 中斷綁定到容器分配的 CPU，並開啟 RPS，把網卡的軟中斷分到各個 CPU 處理，來提升網路性能。

其次，在調度方面，為了支持 SRIOV 插件，在容器調度中，除了 K8S 原生提供的 CPU、Memory、GPU 之外，我們還把網路（物理 IP）也作為一種資源來調度，同時結合 K8S 提供的 extender scheduler 介面，我們定製了符合我們需求的調度程序（cr-arbitrator）。其結構如下：

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

（1）預選演算法

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

（2）優選演算法

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

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

InfoQ：內部有遊戲開始使用微服務架構了？你們的容器雲平台是如何支撐微服務架構的？

尹燁：騰訊遊戲主要分兩部分，一部分是代理的，另外一部分是自研的。對於自研的業務，經歷那麼多年的沉澱，有一套非常成熟的框架和運營體系。微服務架構帶來的變化比較大，已有的業務架構轉過來成本太高。

而代理遊戲進行架構的轉變，相比而言成本會低很多。所以，一些新的代理業務往往會採用微服務架構。今年開始，我們內部也有一些在線業務也在開始這方面的嘗試，我想後面這種業務會越來越多的。

這些業務本身的架構使得業務很容易在容器上運行。另外，如果業務需要使用 K8s 的一些高級特性，比如服務發現、自動擴縮容機制等，則需要業務在架構上和實際部署時做一些簡單的適配，這些適配都比較簡單。

相對於輕量虛擬機，微服務的業務在網路、監控、日誌等方面有較大的不同。

首先是網路部分，受限於底層物理網路，業務的容器不再每個容器一個物理 IP（這會消耗大量的內網 IP 資源，而且管理也不方便），所以，我們使用了 Overlay 的網路方案，將容器的網路與底層物理網路解耦。業務的邏輯部分的容器都會跑在 Overlay 網路上，但是業務的數據層服務，比如 MySQL，Redis 之類的，仍然跑在物理網路上，Overlay 與數據層之間通過 NAT 訪問。同時，接入層通過內部 LB 對接外部網關，分離網關與業務服務。大致結構如下：

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

（1）每個母機部署 cAdvisor 程序，用於收集母機上容器的性能數據，比如 CPU 使用情況、memory、網路流量、TCP 連接數等。

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

（3）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 收集日誌時怎樣去區分不同的業務？而這恰恰是做日誌許可權管理的前提條件，我們只希望用戶只能查看自己業務的日誌。以下是具體的處理方案與流程：

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

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

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

InfoQ：這麼長時間的應用，有做過復盤嗎？未來有什麼計劃？

尹燁：我們一直致力於為遊戲業務提供高效的計算資源。從輕量虛擬機，到微服務，再到離線計算，我們一直緊隨業務的場景往前演進。特別是彈性計算場景，相對於原來交付物理機／虛擬機的方式，現在基於容器的方式更加高效。我們希望在滿足業務對計算資源需求的同時，儘可能提高資源的利用率，從而降低運營成本。我們會一直朝這個目標努力。

具體來說，整個平台也還有很多需要改進和優化的地方。比如，網路方面，我們希望簡化外部網關的接入，進一步提升底層 overlay 網路的性能。優化資源調度策略，考慮更多的一些因素，比如任務優先順序、任務運行時長等，將在線業務與離線業務混合部署等。

InfoQ：這一次的 CNUTCon 全球運維技術大會 上，你將會為參會者分享哪些技術點？

尹燁：這次會上，我會分享騰訊遊戲業務的各種應用場景，詳細介紹我們的 Docker 容器平台（TenC）的架構和技術方案，跟大家交流一些容器的實踐經驗和體會。

點擊展開全文

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