下一个 Kubernetes 前沿:多集群管理-阿里云开发者社区

开发者社区> 游客gurpphp54sbay> 正文

下一个 Kubernetes 前沿:多集群管理

简介: 蚂蚁集团运行着全球最大的 Kubernetes*(内部称为 Sigma)* 集群之一。Kubernetes 社区官方以 5K node 作为 Kubernetes 规模化的事实标准,而蚂蚁集团在 2019 年的时候,就已经维护着单集群规模超过 1W node 的 Kubernetes 集群。
+关注继续查看

📄

文|金敏(蚂蚁集团技术专家)

   邱见(Red Hat)

校对| 冯泳(蚂蚁集团资深技术专家)

本文 3311 字 阅读 6 分钟

从最初 Kubernetes 技术问世,业界一遍一遍的质疑它能否能经得住生产级的考验,到今天许多大型企业已经采用 Kubernetes 技术“云化”之前大规模的基础设施,在企业内部创建了数十个甚至数百个集群。

Kubernetes 原生的管理能力目前仍然停留在单集群级别。每一个集群可以稳定地自治运行,但是却缺乏横贯多个集群的统筹管理能力。基础设施的建立者需要协调分散在各处的管理组件,形成一个统一的管理平台。

通过它,运维管理人员能够获知多集群水位的变化,节点健康状态的震荡等信息;业务应用负责人能够决策如何调配应用服务在各个集群中的部署分布;应用的运维人员能够获知服务状态,下发腾挪的策略。

与多集群相关的创新正在不断涌现。例如 ClusterAPI 和 Submariner 就是处理特定多集群管理问题比较成功的项目。

而本文要讨论的是那些试图解决企业在面对多集群管理时遇到的所有问题的技术探索。

在过去五年中,中国的技术公司蚂蚁集团在多集群管理的思考、使用和实施等方面学习到了很多宝贵的经验。

蚂蚁集团管理着遍布全球的数十个 Kubernetes 集群,每个集群平均拥有数千个节点(服务器)。他们将应用程序及其所需组件(包括中间件,数据库,负载均衡等等)在架构层面组织成逻辑数据中心(LDC)的弹性逻辑单元中,并将它们规划部署到物理基础设施上。这种架构设计帮助他们实现基础设施运维的两个关键目标:高可用性和事务性。

  • 首先,部署在某个 LDC 上的业务应用的可用性在所属 LDC 内能够得到保障。
  • 其次,部署在 LDC 内的应用组件可以被验证,并在故障发生时,可以被回滚。

蚂蚁集团 PaaS 团队的资深技术专家冯泳表示:

“蚂蚁集团拥有数十个 Kubernetes 集群、数十万个节点和数千个关键应用的基础设施。在这样的云原生基础设施中,每天都会有数以万计的 Pod 被创建和删除。构建一个高度可用、可扩展且安全的平台来管理这些集群和应用程序是一项挑战。”

PART. 1

始于 KubeFed

在 Kubernetes 项目生态中,多集群功能主要由与之同名的 SIG-Multicluster 团队处理。这个团队在 2017 年开发了一个集群联邦技术叫做 KubeFed。

联邦最初被认为是 Kubernetes 的一个内置特性,但很快就遇到了实现以及用户诉求分裂的问题,Federation v1 可以将服务分发到多个 Kubernetes 集群,但不能处理其他类型的对象,也不能真正的以任何方式“管理”集群。一些有相当专业需求的用户——尤其是几个学术实验室——仍在使用它,但该项目已被 Kubernetes 归档,从未成为核心功能。

然后,Federation v1 很快被一种名为“ KubeFed v2 ”的重构设计所取代,世界各地的运营人员都在使用该设计。它允许单个 Kubernetes 集群将多种对象部署到多个其他 Kubernetes 集群。KubeFed v2 还允许“控制平面”主集群管理其他集群,包括它们的大量资源和策略。这是蚂蚁集团多集群管理平台的第一代方案。

蚂蚁集团使用多集群联邦的首要任务之一是资源弹性,不止包括节点级别弹性也包括站点级别弹性。通过在需要时添加节点和整个集群起到提高效率和扩展系统的能力。例如年度性的资源弹性,每年 11 月 11 日是中国一年一度的光棍节,蚂蚁集团通常需要快速部署大量额外容量来支持高峰在线购物工作负载。然而,可惜的是正如他们发现的那样 KubeFed 添加新集群的速度很慢,而且在管理大量集群方面效率低下。

在 KubeFed v2 集群中,一个中枢 Kubernetes 集群会充当所有其他集群的单一“控制平面”。蚂蚁集团发现,在管理托管集群和托管集群中应用程序的时候,中枢集群的资源使用率都非常高。

在管理仅占蚂蚁集团总量 3% 的应用程序工作负载的测试中,他们发现由中等规模的云实例构成的中枢集群就已经饱和了,并且响应时间很差。因此,他们从未在 KubeFed 上运行全部工作负载。

第二个限制与 Kubernetes 的扩展功能有关,称为自定义资源定义或 CRD。类似蚂蚁集团这样的“高级用户”往往会开发众多的自定义资源来扩充管理能力。为了要在多集群间分发 CRD,KubeFed 要求为每个 CRD 都创建一个“联合 CRD”。这不仅使集群中的对象数量增加了一倍,也为在集群间维护 CRD 版本和 API 版本一致性方面带来了严重的问题,并且会造成应用程序因为不能兼容不同的 DRD 或者 API 版本而无法顺利升级。

CRD 的这种数量激增也导致了严重的故障排除问题,同时 CRD 的使用定义不规范/字段变更随意等坏习惯会使 KubeFed 控制面的鲁棒性雪上加霜。在本地集群有自定义资源的地方,联邦控制平面上也有一个代表该本地集群资源的图形聚合视图。但是如果本地集群出现问题,很难从联邦控制平面开始知道问题出在哪里。本地集群上的操作日志和资源事件在联邦级别也是不可见的。

PART. 2

转向 Open Cluster Management

Open Cluster Management 项目(OCM)是由 IBM 最初研发,并由红帽在去年开源。OCM 在蚂蚁集团和其他合作伙伴的经验基础上,改进了多集群管理的方法。它将管理开销从中枢集群下放到每个被管理集群上的代理(Agent)上,让它在整个基础设施中分布式自治并维护稳定。这使得 OCM 理论上能管理的集群数量至少比 KubeFed 多一个数量级。到目前为止,用户已经测试了同时管理多达 1000 个集群。

OCM 还能够利用 Kubernetes 本身的发展来提高自身的能力。例如,那些以 CRD 封装的能力扩展可以使用 OCM 的 WorkAPI(一个正在向 SIG-Multicluster 提议的子项目)在集群之间分发 Kubernetes 对象。WorkAPI 将本地 Kubernetes 资源的子集嵌入其中,作为要部署的对象的定义,并将其留给代理进行部署。此模型更加灵活,并且最大限度地减少了对任何中央控制平面的部署需求。WorkAPI 可以一起定义一个资源的多个版本,支持应用程序的升级路径。同时 WorkAPI 兼顾了中枢集群和被管理集群网络链接故障时的状态保持问题,并可以在重连的情况下保障资源状态的最终一致性。

最重要的是,OCM 在集群部署中实现了更多的自动化。在 KubeFed 中,集群的纳管是一个“双向握手”的过程,以中枢集群和被管理集群之间“零信任”作为基础,在此过程中涉及许多手动步骤来保障安全性。新平台能够简化这一过程。例如,因为它在 “PULL” 的基础上运行,不再需要多阶段手动证书注册,也不需要任何明文的 KubeConfig 证书的流通,就可以做到让被管理集群获取中枢集群的管理命令。

尽管注册的流程注重双向的“信任性”,但是在 OCM 中添加新集群只需要很少的操作;工作人员可以简单地在目标 Kubernetes 集群上部署 “Klusterlet” 代理实现自动纳管。这不仅对管理员来说更加容易,而且也意味着蚂蚁集团为双十一准备更多新集群的部署更加快速。

PART. 3

Kubernetes 多集群

的下一步是什么?

在短短四年内,Kubernetes 社区的多集群管理能力迅速发展,从 Federation v1 到 KubeFed v2 再到 Open Cluster Management。

通过在内部兴趣组 SIG-Multicluster 和外部项目(OCM、Submariner 等)工作的那些才华横溢的工程师的技术能力,多集群支持的管理规模和管理功能都比以前提高了很多。

未来是否还会有一个新的平台来进一步发展多集群功能,或者 OCM 就是最终的实现方式?

冯泳是这么认为的:

“展望未来,在红帽、蚂蚁集团、阿里云等参与者的共同努力下,Open Cluster Management 项目将成为构建基于 Kubernetes 的多集群解决方案的标准和背板”。

无论如何,

有一件事很清楚:

您现在可以在 Kubernetes 上运行整个星球

要了解有关云原生主题的更多信息

请在KubeCon+CloudNativeCon North America

2021 – 2021 年 10 月 11-15 日

加入云原生计算基金会和云原生社区

🔗「原文链接」:

https://containerjournal.com/features/the-next-kubernetes-frontier-multicluster-management/

截屏2021-10-09 上午11.53.45.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
ASP.NET <a></a>标记href传递多个参数
方法一:          方法二:
709 0
阿里巴巴 Kubernetes 应用管理实践中的经验与教训
作者 | 孙健波(阿里巴巴技术专家)、赵钰莹 导读:云原生时代,Kubernetes 的重要性日益凸显。然而,大多数互联网公司在 Kubernetes 上的探索并非想象中顺利,Kubernetes 自带的复杂性足以让一批开发者望而却步。
11526 0
Docker 为 ASP.NET Core Web 应用程序生成 Docker 映像,创建并运行多个容器
1.为 ASP.NET Core 应用程序生成 Docker 映像 下载这个事例项目:https://github.com/dotnet/dotnet-docker/tree/master/samples/aspnetapp 下载完成后给这项目生成一个镜像名为aspnetapp镜像 docker build -t aspnetapp .
865 0
怎么设置阿里云服务器安全组?阿里云安全组规则详细解说
阿里云服务器安全组设置规则分享,阿里云服务器安全组如何放行端口设置教程
6903 0
DockOne微信分享( 九十五):树莓派上的Docker集群管理
本文讲的是DockOne微信分享( 九十五):树莓派上的Docker集群管理【编者的话】随着IOT市场的火热发展,Docker天然的轻量级以及帮助业务快速重构的特性,将会在IOT领域迎来巨大发展潜力,甚至有可能会比它在云端的潜力更大。
3162 0
Kubernetes 集群日志管理 - 每天5分钟玩转 Docker 容器技术(180)
Kubernetes 开发了一个 Elasticsearch 附加组件来实现集群的日志管理。
2927 0
灵活、高效的云原生集群管理经验:用 K8s 管理 K8s
单 K8s 集群为用户提供了 Namespace 级别的隔离能力,理论上支持不超过 5K Node、15W Pod。多 K8s 集群则解决了单集群的资源隔离、故障隔离难题,打破可支持节点数、Pod 数的限制,但与此同时也带来了集群管理复杂度的上升;尤其在专有云场景中,K8s 工程师不可能像在公有云中一样快速触达客户环境,运维成本被进一步放大。因此如何低成本、高效率、自动化低管理多套 K8s 集群,成为业内普遍难题。
893 0
使用OpenApi弹性释放和设置云服务器ECS释放
云服务器ECS的一个重要特性就是按需创建资源。您可以在业务高峰期按需弹性的自定义规则进行资源创建,在完成业务计算的时候释放资源。本篇将提供几个Tips帮助您更加容易和自动化的完成云服务器的释放和弹性设置。
7751 0
8
文章
0
问答
来源圈子
更多
致力于打造一流的分布式技术在金融场景应用实践的技术交流平台,专注于交流金融科技行业内最前沿、可供参考的技术方案与实施路线。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载