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

  • 时间:
  • 浏览:2
  • 来源:uu快3官网app_uu快3豹子赚钱

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

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

首先亲们 一块儿来看下托管哪此 Kubernetes 集群的痛点:

2019 年 6 月,阿里巴巴将内部的云原生应用自动化引擎 OpenKruise 开源,这里亲们 重点介绍下其中的 BroadcastJob 功能,它非常适用于每台 worker 机器上的组件进行升级,可能对每台机器上的节点进行检测。(Broadcast Job 会在集群中每个 node 后面 跑有一四个 pod 直至开始英文了了。类式于社区的 DaemonSet, 区别在于 DaemonSet 始终保持有一四个 pod 长服务在每个 node 上跑,而 BroadcastJob 中最终两种 pod 会开始英文了了。)

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

点击下载《不一样的 双11 技术:阿里巴巴经济体云原生实践》

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

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

2.埋点指定 Metric

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

此外,考虑不同 Kubernetes 使用场景,亲们 提供了多种 Kubernetes 的 cluster profile,能都都还还可以方便用户进行更方便的集群取舍。亲们 会结合小量集群的实践,持续提供更多更好的集群模板。

“ 阿里巴巴云原生微信公众号(ID:Alicloudnative)关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术公众号。”

进入云原生时代,Prometheus 作为 CNCF 第四个毕业的项目,天生适用于容器场景,Prometheus 与 Kubernetes 结合一块儿,实现服务发现和对动态调度服务的监控,在各种监控方案中具有很大的优势,实际上可能成为容器监控方案的标准,太大亲们 也取舍了 Prometheus 作为方案的基础。

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

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

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

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

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

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

针对每个集群,还要埋点的主要指标类别包括:

亲们 可能但是都看许多分享,介绍了阿里巴巴如何管理单集群 1W 节点的最佳实践,管理大规模节点是有一四个 很有意思的挑战。不过这里讲的海量 Kubernetes 集群管理,会侧重讲如何管理超过 1W 个以上不同规格的 Kubernetes 集群。根据亲们 和许多同行的沟通,往往有一四个 企业内部假如有一天管理多少到几四个 Kubernetes 集群,这麼 亲们 为哪此还要考虑管理这麼 庞大数量的 Kubernetes 集群?

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

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

作者 | 汤志敏,阿里云容器服务高级技术专家

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

一般讲到单元化,亲们 总要联想到单机房容量不足或二地三中心灾备等场景。那单元化和 Kubernetes 管理有哪此关系?

亲们 还要兼顾区域化数据中心、单元化集群范围内可观测性数据的埋点,以及全局视图的可观测性和可视化。基于两种 设计理念和客观需求,全球化可观测性还要使用多级联合辦法 ,也却说边缘层的可观测性实现下沉到还要观测的集群内部,后面 层的可观测性用于在若干区域内实现监控数据的汇聚,中心层可观测性进行汇聚、形成全局化视图以及告警。

2.集群大小不一:每个集群规模大小不一,从多少节点到上万个节点,从多少 service 到几千个 service 等,还要都都还还可以支撑每年持续几倍集群数量的增长;

基于 Federation 的功能,亲们 设计的全球监控架构图如下,包括监控体系、告警体系和展示体系三要素。

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

对亲们 来说,有一四个 地域(比如:杭州)可能会管理几千个 Kubernetes,还要统一维护哪此 Kubernetes 的集群生命周期管理。作为有一四个 Kubernetes 专业团队,有一四个 朴素的想法却说通太大个 Kubernetes 元集群来管理哪此 guest K8s master。而有一四个 Kubernetes 元集群的边界却说有一四个 单元。

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

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

更多相关信息,请关注“阿里巴巴云原生”。

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

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

4.集群持续演进:还要都都还还可以持续的支持 Kubernetes 的新版本新形态演进。

本文节选自《不一样的 双11 技术:阿里巴巴经济体云原生实践》一书,点击后面 图片即可下载!

Label 用于在级联 Prometheus 上标记 region 和元集群,太大在中心 Prometheus 汇聚是能都都还还可以定位到元集群的颗粒度。一块儿,尽量减少不会要的 label,实现数据节省。

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

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

前面两要素简要描述了如何管理海量 Kubernetes 集群的许多思考,然而光做到全球化、单元化的管理还远远不足。Kubernetes 都都还还可以成功,含晒 了声明式的定义、深度活跃的社区、良好的架构抽象等因素,Kubernetes 可能成为云原生时代的 Linux。

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

监控体系按照从元集群监控向中心监控汇聚的深度,呈现为树形形态,能都都还还可以分为三层:

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

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

3.Label 管理

在中心 Prometheus 只埋点还要使用的指标,一定必须全量抓取,但会 会造成网络传输压力过大丢失数据。

有兴趣的开发者,都可但是往阿里云控制台,创建有一四个 Kubernetes 集群来体验。一块儿也欢迎容器生态的合作伙伴加入阿里云的容器应用市场,和亲们 一块儿共创云原生时代。

本书亮点

这麼 设计的好所处于能都都还还可以灵活地在每一级别层内进行扩展以及调整,适合于不断增长的集群规模,相应的许多级别只需调整参数,层次形态清晰;网络形态简单,能都都还还可以实现内网数据穿透到公网并汇聚。