阿里云上万个Kubernetes 集群大规模管理实践,阿里云kubernetes搭建-ESG跨境

阿里云上万个Kubernetes 集群大规模管理实践,阿里云kubernetes搭建

阿里云上万个Kubernetes 集群大规模管理实践

在2019年双11中，容器服务ACK支撑了阿里巴巴内部核心系统容器化和阿里云的云产品本身，也将阿里巴巴多年的大规模容器技术以产品化的能力输出给众多围绕双11的生态公司。通过支撑来自全球各行各业的容器云，容器服务沉淀了支持单元化全球化架构和柔性架构的云原生应用托管中台能力，管理了超过1W个以上的容器集群。本文将会介绍容器服务在海量Kubernetes集群管理上的实践经验。

什么是海量Kubernetes集群管理

大家可能之前看过一些分享，介绍了阿里巴巴如何管理单集群1W节点的最佳实践，管理大规模节点是一个很有意思的挑战。不过这里讲的海量Kubernetes集群管理，会侧重讲如何管理超过1W个以上不同规格的Kubernetes集群。根据我们和一些同行的沟通，往往一个企业内部只要管理几个到几十个Kubernetes集群，那么我们为什么需要考虑管理如此庞大数量的Kubernetes集群

首先，容器服务ACK是阿里云上的云产品，提供了Kubernetes as a Service的能力，面向全球客户，目前已经在全球20个地域支持；

其次，得益于云原生时代的发展，越来越多的企业拥抱Kubernetes，Kubernetes已经逐渐成为云原生时代的基础设施，成为platform of platform。

背景介绍

首先我们一起来看下托管这些Kubernetes集群的痛点：

1.集群种类不同：有标准的、无服务器的、AI的、裸金属的、边缘、Windows等Kubernetes集群。不同种类的集群参数、组件和托管要求不一样，并且需要支撑更多面向垂直场景的Kubernetes；

2.集群大小不一：每个集群规模大小不一，从几个节点到上万个节点，从几个service到几千个service等，需要能够支撑每年持续几倍集群数量的增长；

3.集群安全合规：分布在不同的地域和环境的Kubernetes集群，需要遵循不同的合规性要求。比如欧洲的Kubernetes集群需要遵循欧盟的GDPR法案，在中国的金融业和政务云需要有额外的等级保护等要求；

4.集群持续演进：需要能够持续的支持Kubernetes的新版本新特性演进。

设计目标：

支持单元化的分档管理、容量规划和水位管理；

支持全球化的部署、发布、容灾和可观测性；

支持柔性架构的可插拔、可定制、积木式的持续演进能力。

1.支持单元化的分档管理、容量规划和水位管理

单元化

一般讲到单元化，大家都会联想到单机房容量不够或二地三中心灾备等场景。那单元化和Kubernetes管理有什么关系

对我们来说，一个地域（比如：杭州）可能会管理几千个Kubernetes，需要统一维护这些Kubernetes的集群生命周期管理。作为一个Kubernetes专业团队，一个朴素的想法就是通过多个Kubernetes元集群来管理这些guest K8s master。而一个Kubernetes元集群的边界就是一个单元。

曾经我们经常听说某某机房光纤被挖断，某某机房电力因故障而导致服务中断，容器服务ACK在设计之初就支持了同城多活的架构形态，任何一个用户Kubernetes集群的master组件都会自动地分散在多个机房，不会因单机房问题而影响集群稳定性；另外一个层面，同时要保证master组件间的通信稳定性，容器服务ACK在打散master时调度策略上也会尽量保证master组件间通信延迟在毫秒级。

分档化

大家都知道，Kubernetes集群的master组件的负载主要与Kubernetes集群的节点规模、worker侧的controller或workload等需要与kubeapiserver交互的组件数量和调用频率息息相关，对于上万个Kubernetes集群，每个用户Kubernetes集群的规模和业务形态都千差万别，我们无法用一套标准配置来去管理所有的用户Kubernetes集群。

同时，从成本经济角度考虑，我们提供了一种更加灵活、更加智能的托管能力。考虑到不同资源类型会对master产生不同的负载压力，因此我们需要为每类资源设置不同的因子，最终可归纳出一个计算范式，通过此范式可计算出每个用户Kubernetes集群master所适应的档位。另外，我们也会基于已构建的Kubernetes统一监控平台实时指标来不断地优化和调整这些因素值和范式，从而可实现智能平滑换挡的能力。

容量规划

接下来我们看下Kubernetes元集群的容量模型，单个元集群到底能托管多少个用户Kubernetes集群的master

首先，要确认容器网络规划。这里我们选择了阿里云自研的高性能容器网络Terway,一方面需要通过弹性网卡ENI打通用户VPC和托管master的网络，另一方面提供了高性能和丰富的安全策略；

接下来，我们需要结合VPC内的ip资源，做网段的规划，分别提供给node、pod和service。

最后，我们会结合统计规律，结合成本、密度、性能、资源配额、档位配比等多种因素的综合考量，设计每个元集群单元中部署的不同档位的guest Kubernetes的个数，并预留40%的水位。

2.支持全球化的部署、发布、容灾和可观测性

容器服务已经在全球20个地域支持，我们提供了完全自动化的部署、发布、容灾和可观测性能力，接下来将重点介绍全球化跨数据中心的可观测。

全球跨数据中心的可观测性

**全球化布局的大型集群的可观测性，对于Kubernetes集群的日常保障至关重要。如何在纷繁复杂的网络环境下高效、合理、安全、可扩展的采集各个数据中心中目标集群的实时状态指标，是可观测性设计的关键与核心。

我们需要兼顾区域化数据中心、单元化集群范围内可观测性数据的收集，以及全局视图的可观测性和可视化。基于这种设计理念和客观需求，全球化可观测性必须使用多级联合方式，也就是边缘层的可观测性实现下沉到需要观测的集群内部，中间层的可观测性用于在若干区域内实现监控数据的汇聚，中心层可观测性进行汇聚、形成全局化视图以及告警。

这样设计的好处在于可以灵活地在每一级别层内进行扩展以及调整，适合于不断增长的集群规模，相应的其他级别只需调整参数，层次结构清晰；网络结构简单，可以实现内网数据穿透到公网并汇聚。

针对该全球化布局的大型集群的监控系统设计，对于保障集群的高效运转至关重要，我们的设计理念是在全球范围内将各个数据中心的数据实时收集并聚合，实现全局视图查看和数据可视化，以及故障定位、告警通知。

进入云原生时代，Prometheus作为CNCF第二个毕业的项目，天生适用于容器场景，Prometheus与Kubernetes结合一起，实现服务发现和对动态调度服务的监控，在各种监控方案中具有很大的优势，实际上已经成为容器监控方案的标准，所以我们也选择了Prometheus作为方案的基础。

针对每个集群，需要采集的主要指标类别包括：

OS指标，例如节点资源（CPU,内存，磁盘等）水位以及网络吞吐；

元集群以及用户集群Kubernetes master指标，例如kubeapiserver,kubecontrollermanager,kubescheduler等指标；

Kubernetes组件（kubernetesstatemetrics，cadvisor）采集的关于Kubernetes集群状态；

etcd指标，例如etcd写磁盘时间，DB size，Peer之间吞吐量等等。

当全局数据聚合后，AlertManager对接中心Prometheus，驱动各种不同的告警通知行为，例如钉钉、邮件、短信等方式。

监控告警架构

为了合理地将监控压力负担分到多个层次的Prometheus并实现全局聚合，我们使用了联邦Federation的功能。在联邦集群中，每个数据中心部署单独的Prometheus，用于采集当前数据中心监控数据，并由一个中心的Prometheus负责聚合多个数据中心的监控数据。

基于Federation的功能，我们设计的全球监控架构图如下，包括监控体系、告警体系和展示体系三部分。

监控体系按照从元集群监控向中心监控汇聚的角度，呈现为树形结构，可以分为三层：

边缘Prometheus

为了有效监控元集群Kubernetes和用户集群Kubernetes的指标、避免网络配置的复杂性，将Prometheus下沉到每个元集群内。

级联Prometheus

级联Prometheus的作用在于汇聚多个区域的监控数据。级联Prometheus存在于每个大区域，例如中国区、欧洲区、美洲区、亚洲区。每个大区域内包含若干个具体的区域，例如北京、上海、东京等。随着每个大区域内集群规模的增长，大区域可以拆分成多个新的大区域，并始终维持每个大区域内有一个级联Prometheus，通过这种策略可以实现灵活的架构扩展和演进。

中心Prometheus

中心Prometheus用于连接所有的级联Prometheus，实现最终的数据聚合、全局视图和告警。为提高可靠性，中心Prometheus使用双活架构，也就是在不同可用区布置两个Prometheus中心节点，都连接相同的下一级Prometheus。

图2基于Prometheus Federation的全球多级别监控架构

优化策略

1.监控数据流量与API server流量分离

API server的代理功能可以使得Kubernetes集群外通过API server访问集群内的Pod、Node或者Service。

图3通过API Server代理模式访问Kubernetes集群内的Pod资源

常用的透传Kubernetes集群内Prometheus指标到集群外的方式是通过API server代理功能，优点是可以重用API server的6443端口对外开放数据，管理简便；缺点也明显，增加了API server的负载压力。

如果使用API Server代理模式，考虑到客户集群以及节点都会随着售卖而不断扩大，对API server的压力也越来越大并增加了潜在的风险。对此，针对边缘Prometheus增加了LoadBalancer类型的service，监控流量完全LoadBalancer，实现流量分离。即便监控的对象持续增加，也保证了API server不会因此增加Proxy功能的开销。

2.收集指定Metric

在中心Prometheus只收集需要使用的指标，一定不能全量抓取，否则会造成网络传输压力过大丢失数据。

3.Label管理

Label用于在级联Prometheus上标记region和元集群，所以在中心Prometheus汇聚是可以定位到元集群的颗粒度。同时，尽量减少不必要的label，实现数据节省。

3.支持柔性架构的可插拔、可定制、积木式的持续演进能力

前面两部分简要描述了如何管理海量Kubernetes集群的一些思考，然而光做到全球化、单元化的管理还远远不够。Kubernetes能够成功，包含了声明式的定义、高度活跃的社区、良好的架构抽象等因素，Kubernetes已经成为云原生时代的Linux。

我们必须要考虑Kubernetes版本的持续迭代和CVE漏洞的修复，必须要考虑Kubernetes相关组件的持续更新，无论是CSI、CNI、Device Plugin还是Scheduler Plugin等等。为此我们提供了完整的集群和组件的持续升级、灰度、暂停等功能。

组件可插拔

组件检查

组件升级

2019年6月，阿里巴巴将内部的云原生应用自动化引擎OpenKruise开源，这里我们重点介绍下其中的BroadcastJob功能，它非常适用于每台worker机器上的组件进行升级，或者对每台机器上的节点进行检测。（Broadcast Job会在集群中每个node上面跑一个pod直至结束。类似于社区的DaemonSet,区别在于DaemonSet始终保持一个pod长服务在每个node上跑，而BroadcastJob中最终这个pod会结束。）

集群模板

此外，考虑不同Kubernetes使用场景，我们提供了多种Kubernetes的cluster profile，可以方便用户进行更方便的集群选择。我们会结合大量集群的实践，持续提供更多更好的集群模板。

总结

随着云计算的发展,以Kubernetes为基础的云原生技术持续推动行业进行数字化转型。

容器服务ACK提供了安全稳定、高性能的Kubernetes托管服务，已经成为云上运行Kubernetes的最佳载体。在本次双11，容器服务ACK在各个场景为双11做出贡献，支撑了阿里巴巴内部核心系统容器化上云，支撑了阿里云微服务引擎MSE、视频云、CDN等云产品，也支撑了双11的生态公司和ISV公司，包括聚石塔电商云、菜鸟物流云、东南亚的支付系统等等。

容器服务ACK会持续前行，持续提供更高更好的云原生容器网络、存储、调度和弹性能力、端到端的全链路安全能力、serverless和servicemesh等能力。

有兴趣的开发者，可以前往阿里云控制台，创建一个Kubernetes集群来体验。同时也欢迎容器生态的合作伙伴加入阿里云的容器应用市场，和我们一起共创云原生时代。

特别声明：以上文章内容仅代表作者本人观点，不代表ESG跨境电商观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与ESG跨境电商联系。