立方体、元集群、蜂窝、资源分布
米。 1. 阿里云上的 Kubernetes 生态
自2015年以来，阿里云Kubernetes容器服务（ACK）一直是阿里云中增长最快的云服务之一。 它为众多客户提供服务，还支持阿里巴巴的内部基础设施和公司的其他云服务。
与世界一流云提供商提供的类似容器服务一样，我们的首要任务是可靠性和可用性。 因此，为数以万计的 Kubernetes 集群创建了一个可扩展且全球可访问的平台。
在这篇文章中，我们将分享我们在云基础设施上管理大量 Kubernetes 集群的经验，以及底层平台的架构。
输入
Kubernetes 已成为云中各种工作负载的事实上的标准。 如图所示。 如上所述，现在越来越多的阿里云应用程序运行在 Kubernetes 集群上：有状态和无状态应用程序，以及应用程序管理器。 对于构建和维护基础设施的工程师来说，Kubernetes 管理一直是一个有趣而严肃的讨论话题。 当谈到像阿里云这样的云提供商时，扩展问题就凸显出来了。 如何管理如此规模的 Kubernetes 集群？ 我们已经介绍了管理 1 个节点的大型 Kubernetes 集群的最佳实践。 当然，这是一个有趣的缩放问题。 但还有另一个尺度：数量 集群本身.
我们已经与许多 ACK 用户讨论过这个话题。 他们中的大多数人选择运行数十个（如果不是数百个）中小型 Kubernetes 集群。 这样做有充分的理由：限制潜在的损害、为不同的团队分离集群、创建用于测试的虚拟集群。 如果 ACK 旨在通过这种使用模型为全球受众提供服务，则它必须可靠且高效地管理跨 20 多个区域的大量集群。
米。 2.管理海量Kubernetes集群的问题
管理如此规模的集群的主要挑战是什么？ 如图所示，有四个问题需要处理：
- 异质性
ACK 应支持各种类型的集群，包括标准、无服务器、Edge、Windows 等。 不同的集群需要不同的选项、组件和托管模型。 一些客户需要针对其具体情况进行定制方面的帮助。
- 各种簇大小
集群的大小各不相同，从几个节点和几个 Pod 到数万个节点和数千个 Pod。 资源需求也有很大差异。 资源分配不当会影响性能甚至导致故障。
- 不同版本
Kubernetes 发展得非常快。 每隔几个月就会发布新版本。 客户总是愿意尝试新功能。 因此，他们希望将测试负载放在新版本的 Kubernetes 上，将生产负载放在稳定版本上。 为了满足这一要求，ACK必须不断向客户提供新版本的Kubernetes，同时保持稳定的版本。
- 安全合规性
集群分布在不同的区域。 因此，它们必须遵守各种安全要求和官方法规。 例如，欧洲的集群必须符合 GDPR，而中国的金融云必须有额外的保护层。 这些要求是强制性的，忽视它们是不可接受的，因为这会给云平台的客户带来巨大的风险。
ACK平台旨在解决上述大部分问题。 目前可靠稳定地管理着全球超过10万个Kubernetes集群。 让我们看看这是如何实现的，包括通过几个关键的设计/架构原则。
设计
立方体和蜂窝体
与集中式层次结构不同，基于单元的架构通常用于将平台扩展到单个数据中心之外或扩大灾难恢复的范围。
阿里云中的每个区域由多个可用区（AZ）组成，通常对应于一个特定的数据中心。 在一个大的区域（例如黄州），往往有数千个 Kubernetes 客户端集群运行 ACK。
ACK 使用 Kubernetes 本身来管理这些 Kubernetes 集群，这意味着我们有一个运行的 Kubernetes 元集群来管理客户端 Kubernetes 集群。 这种架构也称为“kube-on-kube”（KoK）。 KoK 架构简化了客户端集群的管理，因为集群部署简单且确定。 更重要的是，我们可以复用原生 Kubernetes 功能。 例如，通过部署来管理API服务器，使用etcd操作符来管理多个etcd。 这样的递归总是能带来特别的乐趣。
根据客户端数量，在一个区域内部署多个 Kubernetes 元集群。 我们将这些称为元簇细胞。 为了防止整个可用区发生故障，ACK 支持在单个区域中进行多主部署：元集群将 Kubernetes 客户端集群主组件分布在多个可用区中并同时运行，即以多主模式运行。 为了保证master的可靠性和效率，ACK优化了组件的放置，并确保API服务器和etcd彼此靠近。
该模型可以让您高效、灵活、可靠地管理 Kubernetes。
元集群资源规划
正如我们已经提到的，每个区域中的元集群数量取决于客户端数量。 但什么时候添加新的元集群呢？ 这是一个典型的资源规划问题。 通常，当现有元集群耗尽其所有资源时，通常会创建一个新的元集群。
我们以网络资源为例。 在 KoK 架构中，客户端集群中的 Kubernetes 组件被部署为元集群中的 Pod。 我们用 （图3）是阿里云开发的一款用于容器网络管理的高性能插件。 它提供了丰富的安全策略，并允许您通过阿里云弹性网络接口（ENI）连接到客户的虚拟私有云（VPC）。 为了有效地跨元集群中的节点、pod 和服务分配网络资源，我们必须仔细监控它们在虚拟私有云元集群中的使用情况。 当网络资源耗尽时，就会创建一个新的小区。
为了确定每个元集群中客户端集群的最佳数量，我们还考虑了成本、密度要求、资源配额、可靠性要求和统计数据。 创建新元集群的决定是根据所有这些信息做出的。 请注意，小集群未来可能会大幅扩展，因此即使集群数量不变，资源消耗也会增加。 我们通常会为每个集群的增长留出足够的可用空间。
米。 3. Terway网络架构
跨客户端集群扩展向导组件
向导组件有不同的资源需求。 它们取决于集群中节点和 Pod 的数量、与 APIServer 交互的非标准控制器/操作器的数量。
在 ACK 中，每个 Kubernetes 客户端集群的大小和运行时要求都不同。 没有用于放置向导组件的通用配置。 如果我们错误地为大型客户端设置了较低的资源限制，那么其集群将无法应对负载。 如果为所有集群设置保守的较高限制，则会浪费资源。
为了在可靠性和成本之间找到微妙的权衡，ACK 使用类型系统。 即，我们定义三种类型的集群：小型、中型和大型。 每种类型都有单独的资源分配配置文件。 根据向导组件的负载、节点数量等因素确定类型。 集群类型可能会随着时间而改变。 ACK 持续监控这些因素并可以相应地向上/向下键入。 一旦集群类型发生更改，资源分配就会自动更新，只需最少的用户干预。
我们正在努力通过更细粒度的扩展和更精确的类型更新来改进这个系统，以便这些变化更顺利地发生并具有更大的经济意义。
米。 4.智能多段式切换
客户端集群的大规模演变
前面的部分介绍了管理大量 Kubernetes 集群的一些方面。 然而，还有一个问题需要解决：集群的演化。
Kubernetes 是云世界的“Linux”。 它不断更新并变得更加模块化。 我们必须不断向客户提供新版本、修复漏洞并更新现有集群，以及管理大量相关组件（CSI、CNI、设备插件、调度程序插件等）。
我们以 Kubernetes 组件管理为例。 首先，我们开发了一个集中式系统来注册和管理所有这些连接的组件。
米。 5. 灵活的可插拔组件
在继续之前，您需要确保更新成功。 为此，我们开发了一个用于检查组件功能的系统。 检查在更新之前和之后执行。
米。 6. 集群组件初步检查
为了快速可靠地更新这些组件，持续部署系统支持部分推进（灰度）、暂停和其他功能。 标准 Kubernetes 控制器不太适合这种用例。 因此，为了管理集群组件，我们开发了一套专门的控制器，包括插件和辅助控制模块（sidecar管理）。
例如，BroadcastJob 控制器旨在更新每台工作计算机上的组件或检查每台计算机上的节点。 Broadcast 作业在集群中的每个节点上运行一个 pod，类似于 DaemonSet。 然而，DaemonSet 总是让 pod 保持长时间运行，而 BroadcastJob 则让它崩溃。 广播控制器还在新加入的节点上启动 Pod，并使用必要的组件初始化节点。 2019 年 XNUMX 月，我们开放了 OpenKruise 自动化引擎的源代码，我们自己在公司内部使用该引擎。
米。 7.OpenKurise组织Broadcast任务在所有节点上的执行
为了帮助客户选择正确的集群配置，我们还提供了一组预定义的配置文件，包括 Serverless、Edge、Windows 和 Bare Metal 配置文件。 随着业务范围的扩大和客户需求的增长，我们将添加更多配置文件以简化繁琐的设置过程。
米。 8. 先进灵活的集群配置，适用于各种场景
跨数据中心的全球可观测性
如下图所示。 9、阿里云容器云服务已在全球二十个地区部署。 考虑到这种规模，ACK 的关键目标之一是轻松监控正在运行的集群的状态，以便如果客户端集群遇到问题，我们可以快速响应该情况。 换句话说，您需要提出一个解决方案，使您能够高效、安全地从所有区域的客户端集群实时收集统计数据，并直观地呈现结果。
米。 9、阿里云容器服务全球二十个地区部署
与许多 Kubernetes 监控系统一样，我们使用 Prometheus 作为主要工具。 对于每个元集群，Prometheus 代理收集以下指标：
- 操作系统指标，例如主机资源（CPU、内存、磁盘等）和网络带宽。
- 元集群和客户端集群管理系统的指标，例如 kube-apiserver、kube-controller-manager 和 kube-scheduler。
- 来自 kubernetes-state-metrics 和 cadvisor 的指标。
- etcd 指标，例如磁盘写入时间、数据库大小、节点之间连接的吞吐量等。
使用典型的多层聚合模型收集全局统计数据。 来自每个元集群的监控数据首先在每个区域进行聚合，然后发送到显示整体情况的中央服务器。 一切都通过联邦机制进行。 每个数据中心的 Prometheus 服务器从该数据中心收集指标，中央 Prometheus 服务器负责聚合监控数据。 AlertManager 连接到中央 Prometheus，如有必要，通过钉钉、电子邮件、短信等发送警报。 可视化 - 使用 Grafana。
图10中，监控系统可分为三个层次：
- 边界水平
离中心最远的层。 Prometheus 边缘服务器在每个元集群中运行，从同一网络域内的元集群和客户端集群收集指标。
- 级联级
Prometheus级联层的作用是收集多个区域的监控数据。 这些服务器在更大的地理单元层面上运行，例如中国、亚洲、欧洲和美洲。 随着集群的增长，可以划分区域，然后每个新的大区域中都会出现一个级联级的Prometheus服务器。 通过此策略，您可以根据需要顺利扩展。
- 中央层面
中央Prometheus服务器连接所有级联服务器并进行最终的数据聚合。 为了可靠性，两个中央 Prometheus 实例在不同的区域中启动，连接到相同的级联服务器。
米。 10、基于Prometheus联邦机制的全局多级监控架构
总结
基于 Kubernetes 的云解决方案不断改变我们的行业。 阿里云容器服务提供安全、可靠和高性能的托管——它是最好的 Kubernetes 云托管之一。 阿里云团队坚信开源原则和开源社区。 我们一定会继续分享我们在运营和管理云技术领域的知识。
来源： habr.com