企业级云原生：TKEStack 腾讯云原生开源实践之路

一、TKEStack 简介

TKEStack 是腾讯云开源的容器平台，很多小伙伴们问：有了 Kuberentes 为何还要用 TKEStack？其实 Kuberentes 作为能力平台还有很多欠缺。比如它没有 UI、镜像仓库、权限管理、日志、监控等基本运维能力，单把 Kuberentes 作为一个业务平台还是很单薄的，而容器平台补齐了以上这些功能点，把 K8S 封装成了完整的业务平台。

TKEStack 的开源历程

腾讯很早就开始做容器相关的计算平台了。2009 年吴军博士从谷歌来到腾讯，便借鉴了谷歌做出了腾讯自研的业务平台 T-Borg。到了 2011~2013 年左右开始用社区成熟的公认的技术做业务平台。当时有一次重要的技术方向转变，转向使用业界主流技术方案后，Torca 转向专门做大数据业务平台，于是有了 HOT（hadoop on torca）。到了 2014 年，Docker 技术也体现了威力，我们非常看好 Docker、Kubernetes 技术，于是迅速进行了切换，并且着手开始做通用的业务平台。

2014 年也有了全新的产品 GaiaStack 用来支持腾讯内部业务，2019 年腾讯做了业务整合，有多条业务线的合并，Kuberentes 和公有云业务团队合作推出了 TKEStack 的容器平台，整合了 Kuberentes 的技术能力。Gaiastack 和 TKE 的技术结合形成了 TKEStack 这个产品，并在 2019 年正式开源。

今年，又有一个非常重要的时间节点，就是上个月 TKEStack 正式加入了开放原子开源基金会。

二、产品定位与方向

1. 容器是云原生的事实底座

在介绍整个产品的定位和方向之前，首先要提一下目前最火热的技术方向 —— 云原生。

云原生是利用公有云、私有云和混合云构建和运行可拓展弹性的应用。容器基本上是整个云原生技术栈的底座角色，CNCF 官方来看容器族的产品中已经有大量产品和厂商参与其中，基本上是百花齐放的态势。

众多产品中，真正耳熟能详的产品主要有两个，分别是 openshift 和 rancher，它们是容器开源界的标杆。

首先是红帽的 openshift，大家从 K8S 的代码贡献可以得知，红帽 K8S 代码贡献率仅次于 google 排第二，技术能力非常强，产品也非常的完善，并且很早便开始做开源产品了。另一个是 rancher，今年被 suse 收购，产品体验非常好。

但在国内企业的使用场景中，这两个产品也有一些不太完善之处。

首先是国内外用户习惯的差异，国外的产品，更多照顾了国外用户的使用习惯。国外用户喜欢用小而专的产品，喜欢命令行工具。但国内大部分用户希望用一站式的平台，要界面化和一站式服务。

另一个问题点在于，国内下载一些国外产品的镜像，网络是个大问题，经常会网络不通或者非常慢，导致使用体验极差。

因此 TKEStack 做一个容器产品需要考虑如何定位这个产品，TKEStack 并不是要在基本体验和全局完善程度上和 openshift、rancher 去对标，他们已经做的非常成熟了，我们刚刚开源，很难在短时间一下子就可以达到他们的成熟度。

2. TKEStack 的开源思路

腾讯云的思路是寻找云原生的蓝海，我们认为在未来，多云以及硬件异构和硬件平台异构是一个方向。

从 2009 年开始腾讯在容器技术方面有很多积累，内部业务在云原生领域也有很多的积累。基于腾讯自己的技术优势和积累以及我们对国内用户诉求更为了解，我们计划基于这两个点做一些云原生的开源产品，为云原生生态贡献腾讯的力量。

（1）硬件异构

首先是硬件异构，绝大部分的使用场景是基于 X86 的硬件，但国内有一个很重要的诉求是支持 ARM。腾讯会做到 X86 和 ARM 可以在同一个集群内部署。GPU 方面除了有自己传统的比较有优势的 GPU 虚拟化能力以外，也把英特尔 GPU 能力和寒武纪和华为的 GPU 相关产品 在 TKEStack 里面做适配，让上层用户可以无感的使用。

（2）基础架构异构

基础架构异构就是混合云，TKEStack 架构设计上是拿一个集群管其他的集群，天然可以做到混合云，把别的集群，自建集群注册到 TKEStack 里面来，利用 TKEStack 提供的镜像仓库、认证、日志、权限、监控，在一个 TKEStack 界面来可以管理多个 K8S 集群。

腾讯积累了一批云原生应用相关的技术方案，两个比较为人熟知的是有状态应用的 TAPP 和英伟达 GPU 虚拟化，还有一些大数据套件也在做集成。腾讯希望把内部的优势开源组件一步一步往 TKEStack 里面集成，在用户可以 在 TKEStack 上使用。

（3）松耦合

除此以外还有一个比较重要的点就是松耦合，TKEStack 一方面支持自研业务，另一方面也支持商业化产品，最终呈现给用户态的不止一个产品。用户直接用的开源产品，内部用也有变化。

面对这样的诉求，就要求 TKEStack 要做到可插拔、积木式组装。A 产品要用日志，B 产品不用日志，自己可以选择可以随意的组合，TKEStack 是具备这样的松耦合能力。

三、开源方法论

TKEStack 从去年 11 月份开源以来，在差不多一年的时间里已经积累了不少经验，也采用了不少方法，感谢资深开源专家马全一老师的指导，现在除了可以对外贡献代码和技术以外，也把经验积累以方法论的形式体现出来，下文为大家分享一下开源治理模式的经验和总结。

1. 为什么要开源

为什么要开源？这个问题在很多搜索引擎上有不少答案，但更多的是偏向于开源对于个人的发展以及开源对整个社会的价值的角度来看的。腾讯更多的是从作为一个企业或者一个部门，对外开源一个项目能够给公司和企业带来哪些优势来考虑的。

只有能够商业落地的开源项目才能获得发展繁荣的机会。近年来 IT 行业的发展中，有几个大家耳熟能详的大项目，Apache、Linux、CentOS 等等，这些都有非常深厚的开源背景和商业落地历史。

开源首先就是能够为商业版本市场推广上带来巨大的马太效应，强者越强、弱者越弱。Apache 首先有了开源项目，然后在开源项目知名度打开后越来越多的用户或者是开发者加入项目中来，开源的用户自然的转化为商业版本的用户或者是商业产品的应用。用户想要完善商业版本，很自然的就会到开源版本社区上为社区贡献自己的代码或者是他的体验优化，形成了良性循环。

开源是对商业版本的重要支撑，开源的社区能够为商业版本产品贡献资源和力量，也是开源商业产品去丰富自己的功能特性和环境适配、是构建完整生态的重要支撑。

有些客户对业务会被某一家供应商所绑定的问题比较敏感，给用户提供开源的商业版本就会减少他们的顾虑，他们也会更乐意支持开源项目。

整个开源商业以及生态互相支撑、相互的建立标准、形成生态，最后落地为一个商业市场的行为，变成良性循环，把开源项目、商业项目越做越大、越做越好。

2. 开源项目为什么需要方法论

以刚刚提到的几个大项目为例，最开始的项目其实完全是由一些杰出的开源工作者按照个人的喜好和热情推动了整个开源的起步。

但是如果看今天各种的项目，能够形成巨大社区或者产业的巨大项目，仅靠个人的热情是很难推动和完善的。这样的大产业项目迫切需要有一套方法论来支撑和引领开源项目制定战略、规划特性、构建标准、建设生态，一步一步环环相扣。

如果是 to C 的商业模型的开源项目，生态是重中之重的要建设的点。如果是 to B 的项目，会尤其看重合作，合作伙伴的选择和治理方式对开源有着非常重要的意义和价值。

3. 开源项目架构

（1）金字塔模型

开源项目的整个架构首先是开源战略的金字塔模型，企业开源整个金字塔塔尖的位置首先要制定好战略，只有制定好了战略，指明了未来产品或者是项目的发展方向之后，才有了后续的标准、产品、生态。

战略是指明了大方向的前提，是整个开源项目的灵魂。开源之前大家一定要想好做产品或者是做项目想要让它达到什么样的效果、未来的发展方向是什么、或者更加理想中的未来世界的开源项目能够站在什么样的位置上，为大家贡献怎样的力量，战略是灵魂也是核心。

项目要遵循标准或者是行业的事实标准，可以更加关注开源项目能否形成行业标准或者是事实标准。当然不必非得是具体条文、接口规范，也可以是隐性的标准，比如操作习惯、UI 界面设计等等，指引和影响用户人群的观念和习惯，带来潜移默化的形成一套隐性标准。

围绕标准、围绕战略设计开源项目，把开源项目真正当做一个产品来设计，意识到开源项目是有它的开发者、有对应的用户、有真正的使用者，不是我们想怎么做就怎么做的，而是把开源项目当成一个真正产品来做、做到越来越完善、越来越完备的状态。

最后以产品、以项目为核心建设生态，同时把生态转化成商业的载体，这是企业开源战略的金字塔。

（2）沙漏模型

接下来开源项目治理的模型，或者真正要把整套的开源项目运转起来。整个沙漏最重要的部分的是瓶颈部分，开源项目就是产品，产品就是我们的重中之重，开源项目最终呈现给客户就是以开源项目为核心的整个产品。

而产品的基石就是核心开发者，核心开发者可以掌握整个项目发展方向，维护社区的稳定。

这之下是使用开源项目的商业伙伴，他们非常有动力完善 TKEStack 的功能、优化和提高 TKEStack 的产品质量和体验。

在此基础上也有更多来自于社区或者来自于其他团队的上游开发者，他们会为 TKEStack 贡献大家的各种环境的适配、各种特异化的功能丰富 TKEStack 的产品线。

（3）生态伙伴模型

对于 TKEStack 来说，企业开源项目的重心重点是生态伙伴，合作伙伴怎么来选择怎么来合作，就形成了生态伙伴模型。

合作伙伴分为几大类，首先是核心开发者以及 TOC 技术委员会，这是整个开源项目的核心，只有核心团队稳定后才可以保持 TKEStack 整个开源项目的稳定。

首先 TOC 技术委员会可以包含创始人、团队的导师、架构师、产品经理、运营经理等等，是以一个委员会的形式确定整个开源项目的发展方向。核心开发工作者社区可以来自于公司的内部，或者是来自于重度使用的团队贡献整个开源项目核心的代码和架构部分。

除了核心工作者提供以外也有忠实追随者，比如投后的公司、对于项目有非常忠实的粉丝，他们会为整个项目贡献他们的活力、贡献他们在商业场景上的适配或者是客户真实需求都可以在开源项目上努力实现。

一个开源的项目对外是要有开放包容的态度来欢迎各类开发者甚至是竞争对手一起合作，竞争对手某一个角度上、某些场景上也可以找到一起合作的点。大家的出发点都是站在开源的角度，都是为了整个生态和社区服务的，从这个角度上来看跟客户或者是跟个人开发或者是竞争对手合作起来会比较容易谈成。

制约整个项目成功的要素首先还是要选择正确的核心的合作伙伴，争取中间位置的合作伙伴，总的来说是要争取更多的开发者的力量，朝着一个目标贡献开源的社区力量。

4. 其他制约项目发展和成功的要素

针对于这套方法论还要有一套能够适配于这个方法论的治理模型，能够把方法论和开源理想落地实现，要有丰富的市场手段宣传开源项目、宣传商业产品。同时，这样也是整个开源社区或者是产品和项目是非常好的强心剂，能够助推项目更好更快的发展。

四、开源治理模式

1. 开源项目全生命周期治理

TKEStack 开源项目是有生命周期治理的，从最开始战略的规划、到产品需求、开发迭代、发布周期、运维管理、运营管理，各种的阶段都是有着自己的流程和方法的。

对于战略计划和需求而言，战略计划会有定期的 TOC 的技术委员会会议，周期是半年或者是一年的年度计划或者是半年计划，以此来制定整个 TKEStack 的年度里程碑。

制定完之后里程碑和路线图会在代码托管网站上公布出来。后面会就路线图进行细化，真正落实到每天的工作中，以周会的形式来跟踪里程碑和路线图。

具体实施阶段，一是内部的用户反馈、二是外部的用户反馈。内部客户会有一套 TAPD 需求管理系统来跟踪整个状态，外部用户则使用 Github Issue 跟踪。

2. 需求流程

由于对外开源，所以有大量的外部用户的需求和问题反馈。如果沿用之前流程，按照两条线分别进行需求开发跟踪会造成大量冲突和混乱的问题，产品经理会非常累的奔波于两条线上，统筹内外部的需求。

对于这个问题，我们进行了改进，做到了自动化。比如外部的需求和问题单，有自动化任务每天同步到内部系统中来，公司内部核心开发人员就可以看到外部客户的需求，并且第一时间进行评审，给出他的开发意见。

对于比较大的需求，给出的开发建议或者是概要设计我们也会提交 Proposal 供给整个社区的人看到。

3. 开发流程

开发流程包括开发中、测试和最后的提交，都可以整体在系统中追踪得到，并且也能够及时的同步到 Github 开源网站上，公司内外部的用户和团队能够第一时间掌握整个需求的状态。

开发流程沿用的是 Github 标准的开发流程，创建分支、创建 PR 申请、讨论以及最后的部署、测试等等，具体的详情可以参见 Github 的官网。

4. 测试流程

开发流程另一方面就是测试流程，现在 TKEStack 能够做到三级测试，每个测试所在的阶段和目标也不尽相同。

UT 是在每次的代码编译时候保证整个代码的可编译性、以及语法没有重大错误。SmokeTest 每次 PR 提交的时候运行，大概有十几个测试用例来保证提交代码不会影响到 TKEStack 的核心功能，最后每次发版的时候也有 release 测试，来保证最后发布的版本可靠性。这是三级测试的流程。

5. 发布与维护

发布也有自己的一套版本发布和分支管理的流程。下图中标红色线的是主分支，就是长期跟踪的分支，所有的 fix，feat，docs 等等代码全部都是要提供到主分支上的。

主分支上会按照计划去发布版本，比如发布的版本是 v1.4.0，就是按照计划在主分支上找到合适发布的版本，从上面拉取 release-1.4 的分支，发布的时候将 v1.4.0 的标签打到分支上，这个 v1.4.0 的分支就是我们要长期维护的分支。后续如果有 bug 修改也都会在这个分支上同步发布，也会定期在分支上发布 v1.4.1 的小版本。这些整体的版本发布维护计划都是可以看到的。

6. 社区治理

整个治理模型最后部分是社区的治理，对应于之前提到的方法论，吸引各种合作伙伴和团队参与到整个开源社区治理中来。

团队内部的核心开发者、公司内部的贡献者是负责 TKEStack 核心功能，要保证产品发展方向和核心能力的，分配的是基础架构方面的工作。

外部的合作伙伴更多的优势是在于他们能够结合环境的适配面对真正用户做特质化的需求，这是对产品功能方面非常重要的，也有更多的参与商业化的构建，以及特定的功能，比如日志、监控等等其他的针对于用户环境的优化需求。

社区内的大量开发者也可以有更多的优化体验，一些业内更好更新的实践或者是方法都可以来参与到社区中来。

对于各个开发团队或者是对于社区个人开发者，腾讯也做了很多努力，比如组织线上线下的活动来宣传介绍相关知识，例如 TKEStack 最近有在做开源悬赏任务，会定期的放出一些开发任务交给大家来参与进来。腾讯也会以各种奖励来回馈社区、提高大家对参与社区活动的积极性。

五、案例介绍

1. 内部上云

腾讯现在整体在做全量业务上云，这是一个过程，有些业务依赖的周边系统的业务还没上云，所以难以短时间直接切换为共有云部署。

另一方面，业务上云需要有一个中间过程，而且云机房的机器和 IDC 机房的机器不同，当把业务全部切到云上，IDC 机器就空闲了。

为了解决这两个问题，TKEStack 在内部部署了一套用来支持业务上云。TKEStack 界面和公有云一脉相承，两个产品的使用体验上没有大的区别。所以暂时还无法全量上云，但又必须要做云化改造的商品，现在可以借助 TKEStack 完成云化，条件成熟进一步上到腾讯公有云上，TKEStack 已经支持了大几百万核的内部业务运行。

2. TKE 企业版

TKEStack 企业版除了在开源也在支持内部业务，同时也支持商业化的产品。相比内部资源上云，商业化的企业版在很多方面会做更多强化。

TKEStack 企业版界面跟开源 TKEStack 有些不同，开源的 TKEStack 在基于商业化诉求界面上封装得更多、展现的内容更多。

TKEStack 企业版的核心能力，比如集群的调度、创建、业务管理比较核心的底层能力是 TKEStack 贡献，但是在微服务方面以及运维和运营相关的比较强用户体验的功能更多的是企业版自己构建的。这就是拿一部分开源底层能力和商业化特殊要求的能力进行组合，就会变成 TKEStack 企业版，相互不会影响彼此。

六、总结和展望

开源类似于创业，要做到天时地利人和。

天时，是对的时间做对的事，比如目前大家都在做云原生，这个时候做容器平台就可以吸引到用户，如果做一个 openstack 平台， 相对吸引力就不是那么强，所以正确的时间做正确的事情，跟随主流技术趋势是天时。

地利，有了好的方向后也得有能力做。腾讯在这方面有着十多年的积累，技术能力比较强，既有内部业务的使用经验，有腾讯公有云的运营经验，也有大规模集训支撑能力，这几者结合可以说做开源的容器平台有了技术的基础。

人和，目前在国内很难有这样的机会有一拨人完全做开源，长时间的关注在开源领域没有任何业务 KPI，这是理想化的过程。实际上的过程是既要支持核心业务，又要做好开源产品。

在两者间综合协调，要有合适的战略推动这个产品持续的迭代，有了产品后也需要更多人参与生态中认同这个生态，使用、维护，并且对生态做出贡献。有更多人参与这个产品才更有生命力，才算得上是合格的开源产品。

这是天时地利人和，商业化的卖一个产品也是一样的道理，好的商机、有做产品的能力，有对的人做出受欢迎的产品。

未来的云计算基础设施一定是处于多维异构的状态。多维是三维，硬件是异构的、基础设施是异构的（公有云和私有云）、业务也是异构的，不光跑一些非常简单的无状态服务也要跑有状态任务，包括在线业务、离线业务等等。

我们希望在多维异构的层面为用户提供一站式的通用的基础架构平台，这是 TKEStack 的愿景。

TKEStack 在今年 10 月发布了 1.4 版本，主要的核心点包括应用市场、导入集群支持安装插件，也有集群小版本升级功能逐渐上到 TKEStack 中，同时修复了大量体验相关用户反馈问题。

今年 12 月，TKEStack 还会在几个重要的点进行升级，比如大数据组件的集成，要把腾讯云优势产品持续和 TKEStack 同步。我们会在年内把优秀大数据套件集成进来，TKEStack 一键就可以部署常用的大数据套件。对一个集群高可用也是业界的难点，私有云环境有太多不可知的因素，在这个场景里是很麻烦的。

明年，TKEStack 会继续往上层发展，比如做应用的复制，至少要有完整使用腾讯云公有云所有产品的能力。

目前，对于 TKEStack 整个平台升级呼声比较大的是 IPV6，但这一点要等官方 IPV6 的正式支持。明年腾讯的公有云和混合云也会有更丰富的能力，比如全部的 DNS 服务可以多集群接入，集群迁移也可以提供更多的工具的方法，更简单无门槛的做整个 K8S 集群的迁移，或者是做容器化的迁移，这些能力的提升可以真正解决许多用户的共同问题。

Q&A

Q：TKE 如何实现服务发现呢?

A： 我们暂时没有额外做更多的服务发现的能力，就是 K8S 原生的 service 服务发现机制，但是下一个版本很快会集成自己的 Service mesh 产品，走云原生的路线。

Q：外部需求都是主要哪里来的呢，都是客户吗?

A： 我们在 Github 开源，社区中有人提出需求来我们也有产品的同事来看，会拿出来看是否适合做，如果适合也会做进来，当然也分轻重缓急。

Q：大数据组件集成了哪些呢？

A： 当前版本里没有集成，今年年内会争取放上来，会包含常用的大数据、AI 组件，容器化部署会在这个大包里，因为现在还有知识产权相关问题要处理，我们希望年内把它集成到 TKEStack 可以一键部署，真正让大家大数据和 AI 业务可以 TKEStack 上跑得更好。

Q：TKEStack 的运营体系是如何建设的?

A： 运营体系刚刚也介绍了，再简单说说，主要是有内部的核心开发者、商业化推动开源产品持续有人做这件事，光几个开发者肯定不够，也会去吸引更多人进入，一方面吸引内部技术团队，比如腾讯云其他的部门，他们在容器化过程中也有很多产品能力我们也会吸引进来，也有多家的商业合作伙伴，商业化方面有些合作伙伴做了好的能力可以反哺给 TKEStack，或者是给 TKEStack 提了一些需求，他就自己实现了，也可以把这部分提交过来，商业合作伙伴也在持续为 TKEStack 做贡献。

外部的用户也是现在重点在发力想吸引更多用户进入跟我们一起建设，对于一个容器平台这么大的项目，我们希望有更多的人参与进来能够把整个产品做得更完善，接下来正在酝酿一些活动，比如开源奖赏相关活动，比如加入开放原子基金会也希望其他的用户可以参与到 TKEStack 中来。

Q：请教下老师 TKEStack 是如何来设计自身的监控的？

A： 目前云监控普罗米修斯就是事实上的标准，所有的云产品和容器产品都是用普罗米修斯做监控，我们会给每个业务集群装一个普罗米修斯插件。目前业界受欢迎的 thanos 方案内部业务也应用起来了，下一步也会整合到 TKEStack 中来，未来 TKEStack 默认带普罗米修斯，如果是高可用我们会提供可选的 thanos 方案。

Q：TKE 有几个版本呢？

A： 主要有公有云的容器服务 TKE，以及腾讯专有云里面的 TKE，另外，就是独立部署开源版本 TKEStack；以及基于开源版衍生的商业版本 TKE 企业版、TCNP。专有云 TKE 沿用公有云 TKE 的技术实现和产品形态，依赖公有云或专有云中的 IAAS 资源，例如云主机、 VPC。独立部署的版本，基于裸机和开源方案部署，不依赖其他资源。

Q：TKEStack 必须要使用 Kuberentes 吗，和 Kuberentes 有什么关系？

A： 是的，因为是基于 Kuberentes 做上层封装的，Kuberentes 如果直接用就是命令行，可以做各种调度，但是用户怎么登录、控制台如何管理应用、监控哪里看等等，TKEStack 是基于 Kuberentes 做上层封装，把 Kuberentes 真正变成可用的业务平台，这是 Kuberentes 和 TKEStack 之间的关系。

Q：TKE 的 configMap 什么时候能实现自动发现更改，重新部署服务，而不需要人为？

A： TKEStack 支持原生的 K8S configmap 功能，现在只是有一个界面化暂时没有做，很快当前正在开发的版本已经做 UI 化，下一个版本就可以用到跟公有云一样 UI 上的设置的产品能力了。

Q：SmokeTest 和 ReleaseTest 的 test case 有什么区别呢？

A： 每次 PR 提交的级，会主要偏重于测试这次代码提交不会影响整个 TKEStack 的基本核心功能，测试用例时间也有要求的，尽量在一个小时或者半个小时内完成的，它是简单的测试集、核心测试集，而每次版本发布前也是自动化的 release 测试，目的是为了评估版本，对版本的质量的保障，所以测试集是全方位的保证测试的质量。

Q：和 Racher 有什么区别？

A： Racher 是技术体验做得非常好的产品，非常成熟的产品。TKEStack 的重点方向是基础体验达到可用、不会太追求特别多细节，因为很难短时间同等级别好用，更多的是异构集群、混合云、插件提供方面重点发力，但是技术体验也要持续保障，使用上的问题欢迎大家提出来。

Q：TKE 跨集群 vpc 访问采用服务发现有实现么？

A： 现在已经支持多集群相互间的服务发现，TKEStack 本身没有做我们也在规划混合云相关产品能力，明年上旬混合云是很大的项目，并不是只有服务发现问题要解决，也有网络问题、集群版本不同、插件不同问题等等都要解决，大概明年上半年完成。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

企业级云原生：TKEStack 腾讯云原生开源实践之路