优秀企业网站建设定制,python网站搭建,在线咨询平台系统,adsense用什么网站做一、前言
Airbnb 基础设施的一个重要作用是保证我们的云能够根据需求上升或下降进行自动扩缩容#xff0c;我们每天的流量波动都非常大#xff0c;需要依靠动态扩缩容来保证服务的正常运行。为了支持扩缩容#xff0c;Airbnb 使用了 Kubernetes 编排系统#xff0c;并且使…一、前言
Airbnb 基础设施的一个重要作用是保证我们的云能够根据需求上升或下降进行自动扩缩容我们每天的流量波动都非常大需要依靠动态扩缩容来保证服务的正常运行。为了支持扩缩容Airbnb 使用了 Kubernetes 编排系统并且使用了一种基于 Kubernetes 的服务配置接口。现在来讨论一下如何使用 Kubernetes Cluster Autoscaler 来动态调整集群的大小这些改进增加了可定制性和灵活性以满足 Airbnb 独特的业务需求。
二、Airbnb 的 Kubernetes 集群
在过去的几年中Airbnb 已经将几乎所有的在线服务从手动编排的 EC2 实例迁移到了 Kubernetes。现如今在近百个集群中运行了上千个节点来适应这些工作负载。然而这些变化并不是一蹴而就的在迁移过程中随着新技术栈上的工作负载和流量越来越多底层的 Kubernetes 集群也随之变得越来越复杂。这些演变可以划分为如下三个阶段 同质集群手动扩容 多集群类型独立扩缩容 异构集群自动扩缩容。
① 同质集群手动扩缩容
在使用 Kubernetes 之前每个服务实例都运行在其所在的机器上通过手动分配足够的容量来满足流量增加的场景。每个团队的容量管理方式都不尽相同且一旦负载下降很少会取消配置。一开始 Kubernetes 集群的配置相对比较简单配置有几个集群每个集群都有单独的底层节点类型和配置它们只运行无状态的在线服务。随着服务开始迁移到 Kubernetes我们便开始在多租户环境中运行容器化的服务。这种聚合方式减少了资源浪费并且将这些服务的容量管理整合到 Kuberentes 控制平面上。在这个阶段需要我们手动扩展集群但相比之前仍然有着显著的提升。 ② 多集群类型独立扩缩容
集群配置的第二个阶段是因为更多样化的工作负载而出现的每个试图在 Kubernetes 上运行的工作负载都有着不同的需求。为了满足这些需求为此创建了一个抽象的集群类型集群类型定义了集群的底层配置这意味着集群类型的所有集群都是相同的从节点类型到集群组件设置都是相同的。越来越多的集群类型导致出现了越来越多的集群最初通过手动方式来调节每个集群容量的方式很快就变得崩溃了。为了解决这个问题我们为每个集群添加了 Kubernetes Cluster Autoscaler 组件该组件会基于pod requests 来动态调节集群的大小。如果一个集群的容量被耗尽则 Cluster Autoscaler 会添加一个新的节点来满足 pending 状态的 pods。同样如果在一段时间内集群的某些节点的利用率偏低则 Cluster Autoscaler 会移除这些节点。这种方式非常适合我们的场景为我们节省了大约 5% 的总的云开销以及手动扩展集群的运维开销。 ③ 异构集群自动扩缩容
当 Airbnb 的几乎所有在线计算都转移到 Kubernetes 时集群类型的数量已经增长到 30 多个了集群的数量也增加到了 100 多个。这种扩展使得 Kubernetes 集群管理相当乏味例如在集群升级时需要单独对每种类型的集群进行单独测试。在第三个阶段通过创建异构集群来整合集群类型这些集群可以通过单个 Kubernetes 控制平面来容纳许多不同的工作负载 首先这种方式极大降低了集群管理的开销因为拥有更少、更通用的集群会减少需要测试的配置数量 其次现在大多数 Airbnb 的服务已经运行在 Kubernetes 集群上每个集群的效率可以为成本优化提供一个很大的杠杆。 整合集群类型允许在每个集群中运行不同的工作负载这种工作负载类型的聚合有些大有些小可以带来更好的封装和效率从而提高利用率。通过这种额外的工作负载灵活性可以有更多的空间来实施复杂的扩展策略而不是默认的 Cluster Autoscaler 扩展逻辑。具体来说就是计划实现与 Airbnb 特定业务逻辑相关的扩缩容逻辑。 随着对集群的扩展和整合就实现了异构每个集群有多种实例类型我们开始在扩展期间实现特定的业务逻辑并且意识到有必要对扩缩容的行为进行某些变更。
三、Cluster Autoscaler 改进自定义 gRPC 扩展器
要对 Cluster Autoscaler 所做的最重要的改进是提供一种新方法来确定要扩展的节点组在内部 Cluster Autoscaler 会维护一系列映射到不同候选扩容对象的节点组它会针对当前 Pending 状态的 pods 执行模拟调度然后过滤掉不满足调度要求的节点组。如果存在 Pending 的 podsCluster Autoscaler 会尝试通过扩展集群来满足这些 pods所有满足 pod 要求的节点组都会被传递给一个名为 Expander 的组件。 Expander 负责根据需求进一步过滤节点组Cluster Autoscaler 有大量内置的扩展器选项每个选型都有不同的处理逻辑。例如默认是随机扩展器它会随机选择可用的节点组另一个是 Airbnb 曾经使用过的优先级扩展器 它会根据用户指定的分级优先级列表来选择需要扩展的节点组。当使用异构集群逻辑的同时可以发现默认的扩展器无法在成本和实例类型选择方面满足复杂的业务需求。假设想要实现一个基于权重的优先级扩展器目前的优先级扩展器仅允许用户为节点组设置不同的等级这意味着它会始终以确定的顺序来扩展节点组。如果某个等级有多个节点组则会随机选择一个节点组。基于权重的优先级策略可以支持在同一个等级下设置两个节点组其中 80% 的时间会扩展一个节点组另外 20% 的时间会扩展另一个节点组但默认并不支持基于权重的扩展器。除了当前支持的扩展器的某些限制外还有一些操作上的问题 Cluster Autoscaler 的发布流水线比较严格在合并到上游之前需要花大量时间来审核变更但我们的业务逻辑和所需的扩展策略是在不断变化的能够满足当前需求的扩展器并不一定能够满足未来的需求 我们的业务逻辑是与 Airbnb 关联的其他用户则没有这种业务逻辑因此实现的特定逻辑并不一定对上游用户有用 因此可以对 Cluster Autoscaler 中的新扩展器类型提出了一些要求 我们希望扩展器是可扩展的能够被其他用户使用其他用户在使用默认的 Expanders 可能会遇到类似的限制那么希望提供一个通用的解决方案并回馈上游 解决方案应该能够独立于 Cluster Autoscaler 部署这样可以能够响应快速变更的业务需求。 解决方案应该能够融入 Kubernetes Cluster Autoscaler 生态系统这样就无需一直维护一个 Cluster Autoscale 的分支。 鉴于这些需求可以提出了一种设计将扩展职责从 Cluster Autoscaler 的核心逻辑中分离出来设计一种可插拔的“自定义扩展器” 它实现 gRPC 客户端类似 custom cloud provider)该自定义扩展器分为两个组件 第一个组件是内置到 Cluster Autoscaler 中的 gRPC 客户端这个 Expander 与 Cluster Autoscaler 中的其他扩展器遵循相同的接口负责将 Cluster Autoscaler 中的有效节点组信息转换为定义好的 protobuf 格式并接收来自 gRPC 服务端的输出将其转换回 Cluster Autoscaler 要扩展的最终的可选列表。
service Expander {rpc BestOptions (BestOptionsRequest) returns (BestOptionsResponse)
} message BestOptionsRequest {repeated Option options;mapstring, k8s.io.api.core.v1.Node nodeInfoMap;
} message BestOptionsResponse {repeated Option options;
} message Option {// ID of node to uniquely identify the nodeGroupstring nodeGroupId;int32 nodeCount;string debug;repeated k8s.io.api.core.v1.Pod pod;
}第二个组件是 gRPC 服务端这需要由用户实现该服务端作为一个独立的应用或服务运行通过客户端传递的信息以及复杂的扩展逻辑来选择需要扩容的节点组。当前通过 gRPC 传递的 protobuf 消息是 Cluster Autoscaler 中传递给 Expander 的内容的略微转换版本。 在前面的例子中可以非常容易地实现加权随机优先级扩展器方法是让服务器从优先级列表中读取并通过 confimap 读取权重百分比然后进行相应的选择。 其实实现还包含一个故障保护选项建议使用该选项将“多个扩展器”作为参数传递给 Cluster Autoscaler使用该选择后如果服务端出现故障Cluster Autoscaler 仍然能够使用一个备用的扩展器进行扩展。由于服务端作为一个独立的应用运行因此可以在 Cluster Autoscaler 外开发扩展逻辑且 gRPC 服务端可以根据用户需求实现自定义因此这种方案对整个社区来说也非常有用。在内部从 2022 年开始Airbnb 就一直在使用这种方案来扩缩容所有的集群期间一直没有出现任何问题它允许动态地选择何时去扩展特定的节点组来满足 Airbnb 的业务需求从而实现可以开发一个可扩展的自定义扩展器。
