于广游：TKE——贯穿云端，一站式云原生容器 PaaS 平台

12月15日，由腾讯云主办的首届“腾讯腾讯云开发者社区开发者大会”在北京举行。本届大会以“新趋势•新技术•新应用”为主题，汇聚了超40位技术专家，共同探索人工智能、大数据、物联网、小程序、运维开发等热门技术的最新发展成果，吸引超过1000名开发者的参与。以下是DevOps分会场的演讲内容，稍作整理，分享给大家。

本次我们主要讲讲腾讯云TKE平台是怎么设计和实现，踩过哪些坑。首先介绍一下标题的含义：贯穿云端，指的我们既支持公有云也支持私有云，部署在公有云上可以管理私有云集群，部署在私有云上也可以管理公有云集群。云原生，指的是我们不对k8s做二次封装，而是暴露出原生k8s概念，并对k8s做一些优化、增强。本次分享，我希望大家得到的价值是，听完之后知道腾讯云的TKE是怎么设计与实现的，通过怎样的机制实现不同环境的部署。

我是2016年加入TKE团队，一直负责k8s产品化相关工作，加入TKE之前做过一些云主机和云盘相关的开发。

本次的分享主要分为四个部分，第一部分介绍TKE是什么，有哪些功能；第二部分讲一讲我们老的架构遇到了哪些问题与挑战；第三部分介绍新架构是怎么参考k8s对我们的平台做插件化拆分，继而使TKE能够够适配各个环境，最后对本次分享做一下总结与展望。

TKE第一个能力是能够支持各种环境，如公有云、TCE、私有云，并保证基本上能力是一致的。下一个能力是集群管理，支持两种集群模式，一种是托管集群，一种是独立集群，托管集群就是客户在我们这买一个集群，客户不用管Master，我们帮客户管。独立集群是客户买一些主机，我们帮客户部署上k8s，k8s Master和主机本身都是用户自己管理的。接下来是网络，k8s的本身网络能力就不介绍了，主要介绍下我们增强的网络能力：固定IP与网段IP。固定IP是用户容器挂掉、迁移IP保持不变；网段IP是用户创建workload时能够指定这个workload使用哪个网段的IP，帮助做一些事先的安全授权。接下来是存储，TKE支持腾讯云的系统存储、文件存储等等。然后是运维中心，有监控、告警、审计等功能，这就是我们这个平台有的特性。

TKE有这么多特性，那这些功能怎么做到即支持公有云又支持私有云呢？在正式介绍新架构前，我先介绍下老架构是怎样的，有哪些问题。

这个是老架构示意图。

最上方是云API，它接收用户的请求，进行认证和授权后转发给后端服务。所谓认证即是判断账号密码/token等是否正确，并解析出相应账户信息，云上为uin（登陆账号）和appId（租户ID）。授权则是判断该用户对此资源是否有该操作权限。TKE-dashboard是TKE老架构中核心业务模块，接收用户请求后调用云主机、VPC等接口创建、销毁集群、添加、删除节点等，这一块代码与腾讯云上CVM、CLB、CBS等接口有强耦合。下面可以看到我们有一个MetaCluster，我们现网有数千个k8s集群，这么多k8s集群他们的运维、升级都是一个大问题，我们搞了一个方案，把这些放到一个集群，用这个集群解决k8s Maste本身的升级问题。另外就是独立集群了，也即Master用户自己管理的集群。总结一下，TKE老架构的认证、授权是依赖于公有云云API的，帐号是腾讯云的帐号，授权是腾讯云的授权，下面的很多资源也是跟腾讯云做一个强耦合的。同时这个代码经过了三个大版本的迭代，问题很大，第一版基于CVM的托管集群，第二版是基于MetaCluster的托管集群。搞完之后产品同学说托管集群不能完全满足用户的需求，是不是可以搞一下独立集群？于是做了第三版支持了新的集群模式：独立集群。

云上其实还有一个产品叫黑石物理机，一些用户有在黑石上使用TKE的需求，但黑石环境中主机、负载均衡网络等方案与云主机都不同。有一天，产品说：TKE支持黑石半个月是否可以上线？我回想起来TKE-dashboard代码中对公有云的强依赖，于是做了一个草率的决定:重新拉了一个代码仓库叫TKE-Bmdashboard。于是就变黑石与公有云两套代码，独立迭代，每次需求都需要双倍开发，就这样度过了一段艰难的岁月，但也勉强维持下去了。

又有一天，产品说：腾讯现在支持TCE，有些客户嫌TCE太大依赖太多，我们TKE能否做独立的私有化部署？也就是说TKE不但要支持公有云CVM和公有云黑石，还要支持IDC中私有部署。这对我们技术上带来了巨大的挑战，我们不能像之前支持黑石一样再重新拉一套代码来额外支持私有云，这样多少人力都不够。

于是我们开始重新思考架构设计的问题。最早的时候TKE中k8s Master是部署在CVM上的，数千个k8s集群本身Master的管理给我们带来了很大的负担。我们就用k8s来管理k8s Master，解决了k8s Master运维等的问题。于是我们想，既然k8s本身支持多云管理，为什么我们不能参考k8s来设计我们的管理面，再去管理集群呢？我们做了一定的分析，发现确实可以这样做。K8s apiserver支持各种各样的认证、授权插件，用于支持不同的场景。K8s controller-manager也支持各种各样的provider用于与不同环境集成。我们把这套东西搬到TKE上，实现多种的plugin和provider，是不是就可以支持不同的环境了？

这是我们新的架构，如果你熟悉k8s，你会觉得与k8s的架构非常相像。我们使用的就是k8s的框架，老架构中云API把请求进行认证和授权后直接发到TKE后台，请求中带有腾讯云账户相关信息，所以TKE后台需要识别腾讯云账号体系。现在我们实现一个gateway，不要让云API直接发到TKE-apiserver，而是发送到cloud-gw后，cloud-gw把腾讯云账号相关信息转换成TKE内置账号信息后发送到TKE-apiserver。集群管理也是类似，k8s有很多种controller和provider，我们参考k8s设计了TKE-controller，并实现了公有云托管集群、公有云独立集群、黑石集群三种provider，就能够做到一套代码同时多种部署模式，支持CVM与黑石。

在私有云里面我们把认证、授权、cluster-provider换成其它的插件即可。

接下来我会分认证、授权、集群管理、网络四方面具体讲讲新架构是怎样实现的。

首先是认证这块，大家知道k8s支持basic、token、双向认证等多种认证方式，我们直接在此框架上进行了开发。公有云上使用双向认证模式，TKE-apiserver内置了一个账户体系，不再直接识别腾讯云上的uin和appId等，统一转成TKE-apiserver内置的格式。在私有云中部署时则启动内置的单点认证系统，并开启需要的插件。如果公司内部没有自己的账户体系，可以使用TKE内置的账户体系，也可以与公司内部账户体系打通后，使用内部账号体系登陆。这是认证，认证是证明谁是谁，下一步要看这个人能不能干这些事情，就到了授权这一步。

新架构中不再由云API层对请求进行授权，TKE-apiserver内置一套授权请求协议，每个API请求进来，TKE-apiserver都会到授权中心对该请求进行授权。我们实现了对接公有云CAM的授权插件，公有云上我们部署这个插件，把内置授权协议转成公有云CAM的授权协议到CAM处进行授权，通过这样的机制把认证、授权跟公有云对接。同时在私有化场景中，可启用内置的授权中心，用户也可以实现自定义插件与其他授权中心对接。

接下来讲集群管理。TKE-apiserver中有cluster和machine两种资源，

用户创建集群时调用TKE-apiserver插入一个新的cluster资源。cluster-controller watch该资源后会根据资源中的类型调用相应的provider去创建集群，不同provider与不同云环境做了适配和打通。创建k8s集群时有很多通用的逻辑，比如k8s参数生成，比如下发命令的命令通道，我们把这些逻辑抽象为公共的组件，就可以很方便的新增一个provider。假如说腾讯云上新多了一个主机类型叫白石，我们可以实现一个白石的provider，内置白石主机发货逻辑，参数生成逻辑，实现任务下发接口，即可对接成功。现在要把这个东西部署到私有云，我们实现一个新的provider，就能在私有云中管理k8s集群。

网络这里，我们支持在创建容器的时，动态指定选择哪个网络模式。为此我们实现了一个CNI插件叫CNI-switch，这个插件本身不配置网络而是调用其他CNI插件。比如需要固定IP时，CNI帮我找到TKE-IPAMC插件，TKE-IPAMC访问TKE-IPAMD去申请IP。但是TKE-IPAMD怎么搬到私有云呢？也是参考了k8s做了一些抽象，其中有两个模块做了插件化，一个叫IP provider，一个叫IP storage，我们默认实现了对接腾讯云VPC接口的IP provider。你想在私有云中使用固定IP的方案，就要把IP provider依赖的四个接口对接私有云即可。

剩下的是日志、审计、事件，这些其实都是文本的展示、检索和存储，我们对后端存储抽象为插件，默认实现了CLS和ES插件。

下面说下客户案例，这里不讲普通TKE用户，说一个稍微有些特殊的例子。腾讯自研业务现在要全部上腾讯云，但是自研业务本身与腾讯内部环境耦合很深，用户使用习惯也是腾讯内部那一套，直接迁到腾讯云上很困难风险很大。我们团队与自研上云团队一起合作实现了TKE对接腾讯内部的各种插件，自研上云团队在内部机房中部署TKE管理台，即可同时管理公有云上和自研内部的k8s集群，将这些集群网络打通后，使用TKE管理台可以任意将业务部署到不通集群中，也就可以在公有云和内部之间迁来迁去。

最后总结一下。

老架构与腾讯云环境强耦合，代码不可移植。新架构中，参考k8s的设计，将抽象与实现分离，通过插件化机制做到能够灵活对接各种云环境。由于我们复用了k8s的框架，可以像写k8s插件一样写TKE插件，也方便第三方进行开发。

我们当前只做了多集群管理，下一步希望探索跨集群服务管理的场景，现在社区有集群联邦方案，实际落地还比较困难，我们希望在这方面做一定的探索。

Q：刚刚听到咱们的网络那块，是我比较关心的，在多云混合的情况下，私有云和公有云都有的情况下，我一个容器在跑的时候，多个网络云端是怎么解决的？

A：多云网络互通不是容器这一层要解决的问题，首先要在IaaS层解决，只要IaaS层网络是互通的，再保证容器IP与主机IP一样都是一类公民即可。每一个云供应商都有相应的很成熟的方案了，比如腾讯云提供的方案有两个，一个是专线一个是V**，通过专线或者V**将云与IDC打通后，对容器网段配置相应的子网路由即可。

Q：我看到第二个方案的时候，你是用k8s管理所有Master的，当集群特别大的时候，MetaCluster会不会有压力？

A：k8s集群规模2000个节点是能够比较轻松、稳定的跑起来。但事实上在这个问题上我们不会挑战集群规模，相反会避开集群规模上限。因为不同集群的Master Pod相互之间是没有关系的，我们可以把不同集群的Master Pod部署到不同的MetaCluster中。

2.于广游 TKE：贯穿云端，一站式云原生容器 PaaS 平台-compressed.pdf