作者｜郭蕾

　　嘉賓｜尹烨

　　從 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）的架構和技術方案，跟大家交流一些容器的實踐經驗和體會。

　　CNUTCon 全球運維技術大會将于 9 月 10-11 日在上海舉行，本文嘉賓尹烨現場會就騰訊遊戲容器雲平台演進之路分享更多技術細節，屆時可以深入交流，另外，大會還特設 AIOps、SRE、DevOps、運維監控與安全等專場，邀請了來自 Google、Uber、BAT 等公司大咖分享他們在最新運維技術實踐過程中遇到的坑與經驗，點擊“閱讀原文”了解更多精彩！9 折倒計時一周，欲報從速！

　　,