于广游: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一样都是一类公民即可。每一个云供应商都有相应的很成熟的方案了,比如腾讯云提供的方案有两个,一个是专线一个是VPN,通过专线或者VPN将云与IDC打通后,对容器网段配置相应的子网路由即可。

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

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

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券