腾讯企业邮箱在线办理

企业邮箱
最新问题
接口文档

联系我们

深圳市美奔科技有限公司

  • 地址:深圳市南山区科苑路9号园西工业区23栋北212(深大A4出口)
  • Email:szqcloud@qq.com
  • 邮编:518000
  • 电话:15818558013
  • 联系人:林先生

腾讯游戏容器云平台的技术演进之路

发布日期:2018年04月04日    浏览次数:1968    关键字: 公司 新闻
作者|郭蕾


嘉宾|尹烨



从 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 对接外部网关,分离网关与业务服务。大致结构如下:

请点击阅读原文, 查看全部


评论(0 条评论)
游客