Cluster Autoscaler

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

概览

Kubernetes 集群自动扩缩器是 SIG Autoscal ing 维护的流行集群自动扩缩解决方案。它负责确保您的集群有足够的节点来调度 Pod，而不会浪费资源。它会监视调度失败的 Pod 和未充分利用的节点。然后，它会模拟节点的添加或移除，然后再将更改应用于您的集群。集群自动扩缩器中的 AWS 云提供商实现控制您的 Aut EC2 o Scaling 组的.DesiredReplicas字段。

本指南将提供一个心理模型，用于配置集群自动扩缩程序并选择一组最佳的权衡方案来满足您的组织需求。虽然没有单一的最佳配置，但有一组配置选项可以让您在性能、可扩展性、成本和可用性之间进行权衡。此外，本指南还将提供有关优化 AWS 配置的提示和最佳实践。

术语表

本文档中将经常使用以下术语。这些术语可能具有广泛的含义，但仅限于本文档的以下定义。

可扩展性是指随着 Kubernetes 集群的 Pod 和节点数量的增加，集群自动扩缩程序的表现如何。当达到可扩展性限制时，集群自动扩缩程序的性能和功能就会降低。当集群自动扩缩器超出其可扩展性限制时，它可能无法再在您的集群中添加或删除节点。

性能是指集群自动扩缩器能够以多快的速度做出和执行扩展决策。性能完美的 Cluster Autoscaler 会立即做出决定并触发缩放动作以响应刺激，例如 pod 变得不可调度。

可用性意味着可以快速、无中断地调度 pod。这包括何时需要对新创建的 Pod 进行调度，以及缩小规模的节点何时终止调度给它的所有剩余 Pod。

成本由事件中扩展和扩展背后的决策决定。如果现有节点未得到充分利用，或者添加的新节点对于传入的 Pod 来说太大，就会浪费资源。根据用例的不同，由于做出激进的缩减决定，过早终止 pod 可能会产生成本。

节点组是一个抽象的 Kubernetes 概念，用于集群中的一组节点。它不是真正的 Kubernetes 资源，而是作为抽象存在于集群自动扩缩器、集群 API 和其他组件中。节点组中的节点共享标签和污点等属性，但可能由多个可用区或实例类型组成。

EC2 Auto Scaling Groups 可用作上节点组的实现 EC2。 EC2 Auto Scaling 组配置为启动自动加入其 Kubernetes 集群的实例，并在 Kubernetes API 中对相应的节点资源应用标签和污点。

EC2 托管节点组是上节点组的另一种实现EC2。它们消除了手动配置 EC2 AutoScaling Groups 的复杂性，并提供了额外的管理功能，例如节点版本升级和优雅的节点终止。

操作集群自动扩缩器

Cluster Autoscaler 通常作为部署安装在集群中。它使用领导者选举来确保高可用性，但一次只能通过一个副本完成工作。它不能横向扩展。对于基本设置，默认设置应该使用提供的安装说明开箱即用，但有几点需要记住。

确保：

使用对 IAM 角色的最低特权访问权限

使用 Auto Discovery 时，我们强烈建议您使用最低权限访问权限，方法是autoscaling:TerminateInstanceInAutoScalingGroup将操作autoscaling:SetDesiredCapacity和范围限制在当前集群的 Auto Scaling 组。

这将防止在一个集群中运行的集群 Autoscaler 修改另一个集群中的节点组（例如），即使--node-group-auto-discovery参数的范围未缩小到使用标签的集群节点组。k8s.io/cluster-autoscaler/<cluster-name>

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/enabled": "true",
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/<my-cluster>": "owned"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:DescribeScalingActivities",
                "autoscaling:DescribeTags",
                "ec2:DescribeImages",
                "ec2:DescribeInstanceTypes",
                "ec2:DescribeLaunchTemplateVersions",
                "ec2:GetInstanceTypesFromInstanceRequirements",
                "eks:DescribeNodegroup"
            ],
            "Resource": "*"
        }
    ]
}

配置您的节点组

有效的自动扩缩首先要为集群正确配置一组节点组。选择正确的节点组集是最大限度地提高可用性和降低工作负载成本的关键。AWS 使用 A EC2 uto Scaling 组来实现节点组，该组可灵活应用于大量用例。但是，集群自动扩缩器会对您的节点组进行一些假设。保持 A EC2 uto Scaling Group 配置与这些假设保持一致可以最大限度地减少不良行为。

确保：

注意：我们建议使用 EKS 托管节点组。托管节点组具有强大的管理功能，包括集群自动扩缩器的功能，例如自动发现 Aut EC2 o Scaling 组和优雅地终止节点。

针对性能和可扩展性进行优化

了解自动扩缩算法的运行时复杂性将有助于您调整集群自动扩缩器，使其在节点数超过 1,000 的大型集群中继续平稳运行。

调整集群自动扩缩器可扩展性的主要旋钮是提供给进程的资源、算法的扫描间隔以及集群中节点组的数量。该算法的真实运行时复杂性还涉及其他因素，例如调度插件的复杂性和 pod 的数量。这些参数被认为是不可配置的参数，因为它们是集群工作负载的自然参数，并且不容易进行调整。

集群自动扩缩器将整个集群的状态加载到内存中，包括 Pod、节点和节点组。在每个扫描间隔内，该算法都会识别不可调度的 pod，并模拟每个节点组的调度。调整这些因素会带来不同的权衡取舍，对于您的用例，应仔细考虑这些权衡。

垂直自动缩放集群自动扩缩器

将集群自动扩缩器扩展到更大的集群的最简单方法是增加其部署的资源请求。对于大型集群，应增加内存和 CPU，尽管这会因集群大小而有很大差异。自动缩放算法将所有 pod 和节点存储在内存中，在某些情况下，这可能会导致内存占用量大于 1 GB。增加资源通常是手动完成的。如果你发现持续的资源调整会带来运营负担，可以考虑使用 Addon Resizer 或 Vertic al Pod Autoscaler。

减少节点组的数量

尽量减少节点组的数量是确保集群自动扩缩程序在大型集群上继续保持良好性能的一种方法。对于某些按团队或应用程序构建节点组的组织来说，这可能具有挑战性。虽然 Kubernetes API 完全支持这一点，但这被认为是一种集群自动扩缩程序的反模式，会对可扩展性产生影响。使用多个节点组的原因有很多（例如 Spot 或 GPUs），但在许多情况下，还有其他设计可以在使用少量组的情况下达到相同的效果。

确保：

缩短扫描间隔

低扫描间隔（例如 10 秒）将确保集群自动扩缩程序在 pod 变得不可调度时尽快做出响应。但是，每次扫描都会导致对 Kubernetes API 和 EC2 Auto Scaling 组或 EKS 托管节点组进行许多 API 调用。APIs这些 API 调用可能会导致 Kubernetes 控制平面出现速率限制甚至服务不可用。

默认扫描间隔为 10 秒，但在 AWS 上，启动节点需要更长的时间才能启动新实例。这意味着，可以在不显著增加整体纵向扩展时间的情况下提高扫描间隔时间。例如，如果启动节点需要 2 分钟，则将间隔更改为 1 分钟，则需要权衡 API 调用减少 6 倍，而扩展速度降低 38%。

跨节点组分片

可以将集群自动扩缩器配置为在一组特定的节点组上运行。使用此功能，可以部署集群自动扩缩器的多个实例，每个实例都配置为在不同的节点组上运行。这种策略允许您使用任意数量的节点组，用成本换取可扩展性。我们只建议将其作为提高性能的最后手段。

Cluster Autoscaler 最初不是为此配置设计的，因此会产生一些副作用。由于分片无法通信，因此多个自动扩缩器可能会尝试调度不可调度的 pod。这可能会导致对多个节点组进行不必要的扩展。这些额外的节点将在之后缩减规模scale-down-delay。

metadata:
  name: cluster-autoscaler
  namespace: cluster-autoscaler-1

...

--nodes=1:10:k8s-worker-asg-1
--nodes=1:10:k8s-worker-asg-2

---

metadata:
  name: cluster-autoscaler
  namespace: cluster-autoscaler-2

...

--nodes=1:10:k8s-worker-asg-3
--nodes=1:10:k8s-worker-asg-4

确保：

针对成本和可用性进行优化

竞价型实例

您可以在节点组中使用竞价型实例，在按需价格的基础上节省高达 90% 的费用，但要权衡一下，竞价型实例可以在 EC2 需要恢复容量时随时中断。如果您的 EC2 Auto Scaling 组由于可用容量不足而无法扩展，则会出现容量不足错误。通过选择多个实例系列来最大限度地提高多样性，可以利用许多竞价型容量池来增加实现所需规模的机会，并减少竞价型实例中断对集群可用性的影响。包含 Spot 实例的混合实例策略是在不增加节点组数量的情况下提高多样性的好方法。请记住，如果您需要有保障的资源，请使用按需实例而不是竞价型实例。

配置混合实例策略时，所有实例类型都必须具有相似的资源容量，这一点至关重要。自动扩缩程序的调度模拟器使用 InstanceType 中的第一个。 MixedInstancePolicy如果后续的实例类型更大，则在扩展后可能会浪费资源。如果容量较小，则由于容量不足，您的 Pod 可能无法在新实例上进行调度。例如，M4、M5、M5a 和 M5n 实例都具有相似的 CPU 和内存量，是理想的候选实例。 MixedInstancePolicyEC2 实例选择器工具可以帮助您识别相似的实例类型。

建议将按需容量和竞价容量隔离到单独的 EC2 Auto Scaling 组中。这比使用基本容量策略更可取，因为调度属性有根本的不同。由于竞价型实例随时会中断（当 EC2需要恢复容量时），因此用户经常会污染其可抢占节点，因此需要明确容忍抢占行为。这些污点会导致节点的调度属性不同，因此应将它们分成多个 EC2 Auto Scaling 组。

Cluster Autoscaler 有一个扩展器的概念，它为选择要扩展的节点组提供了不同的策略。该策略--expander=least-waste是一个不错的通用默认策略，如果您要使用多个节点组来实现竞价型实例的多样化（如上图所述），则可以通过扩展在扩展活动之后最适合利用的组来帮助进一步优化节点组的成本。

确定节点组/ASG 的优先级

您也可以使用优先级扩展器配置基于优先级的自动缩放。 --expander=priority使您的集群能够优先考虑节点组/ASG，如果由于任何原因无法扩展，它将选择优先级列表中的下一个节点组。例如，当您想使用 P3 实例类型时，这很有用，因为它们的 GPU 可为您的工作负载提供最佳性能，但作为第二个选择，您也可以使用 P2 实例类型。

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-priority-expander
  namespace: kube-system
data:
  priorities: |-
    10:
      - .*p2-node-group.*
    50:
      - .*p3-node-group.*

Cluster Autoscaler 将尝试扩大与名称 p3-node-group 匹配的 EC2 Auto Scaling 组。如果此操作在内未成功--max-node-provision-time，它将尝试缩放名称为 p2- node-group 的 EC2 Auto Scaling 组。该值默认为 15 分钟，可以减少该值以获得更快的节点组选择，但如果该值太低，可能会导致不必要的扩展。

超额配置

Cluster Autoscaler 可确保仅在需要时向集群添加节点，并在未使用时移除节点，从而最大限度地降低成本。这会显著影响部署延迟，因为许多 Pod 将被迫等待节点向上扩展后才能进行调度。节点可能需要几分钟才能使用，这可能会将 Pod 调度延迟增加一个数量级。

此问题可以通过超额配置来缓解，超额配置是以成本换取调度延迟。过度配置是使用优先级为负的临时 pod 实现的，这些容器会占用集群中的空间。当新创建的 pod 不可调度且优先级更高时，临时 pod 将被抢占以腾出空间。然后，临时 Pod 变得不可调度，从而触发集群自动扩缩程序扩展新的超额配置节点。

过度配置还有其他不太明显的好处。在没有过度配置的情况下，高利用率集群的副作用之一是，Pod 将使用 Pod 或 Node Affinity preferredDuringSchedulingIgnoredDuringExecution 规则做出不太理想的调度决策。一个常见的用例是使用将高可用性应用程序的 pod 分隔为多个可用区 AntiAffinity。过度配置会显著增加正确区域的节点可用的几率。

对于您的组织来说，过度配置的容量是一个谨慎的业务决策。从本质上讲，它是在性能和成本之间进行权衡。做出此决定的一种方法是确定您的平均扩容频率，然后将其除以向上扩展新节点所需的时间。例如，如果您平均每 30 秒需要一个新节点，并且 EC2 需要 30 秒来配置一个新节点，那么单节点的超额配置将确保始终有一个额外的节点可用，从而将调度延迟缩短 30 秒，代价是增加一个 EC2 实例。要改进区域调度决策，请超额配置与 A EC2 uto Scaling 组中可用区数量相等的节点，以确保调度器可以为传入的 Pod 选择最佳区域。

防止缩小规模驱逐

移出某些工作负载成本非常高昂。大数据分析、机器学习任务和测试运行器最终将完成，但如果中断，则必须重新启动。Cluster Autoscaler 将尝试缩小下方的任何节点 scale-down-utilization-threshold，这将中断该节点上所有剩余的 Pod。通过确保驱逐成本高昂的 Pod 受到集群自动扩缩器识别的标签的保护，可以防止这种情况。

确保：

高级使用案例

EBS 卷

持久存储对于构建有状态的应用程序（例如数据库或分布式缓存）至关重要。EBS 卷在 Kubernetes 上启用此用例，但仅限于特定区域。如果为每个可用区 AZs 使用单独的 EBS 卷对多个应用程序进行分片，则这些应用程序可以高度可用。然后，集群自动扩缩器可以平衡 EC2 自动扩缩组的扩展。

确保：

共同调度

Machine Learning 分布式培训作业可从同区节点配置的最小化延迟中获益匪浅。这些工作负载将多个 Pod 部署到特定区域。这可以通过为所有共同调度的 pod 设置 Pod Affinity 或使用的 Node Affinity 来实现。topologyKey: failure-domain.beta.kubernetes.io/zone然后，集群自动扩缩器将扩展特定区域以满足需求。您可能希望分配多个 EC2 Auto Scaling 组，每个可用区一个，以便为整个共同计划的工作负载启用故障转移。

确保：

加速器

一些集群利用专门的硬件加速器，例如 GPU。扩展时，加速器设备插件可能需要几分钟才能将资源通告到集群。Cluster Autoscaler 模拟该节点将配备加速器，但是在加速器准备就绪并更新节点的可用资源之前，无法在该节点上调度待处理的 Pod。这可能会导致重复、不必要的横向扩展。

此外，即使未使用加速器，CPU 或内存利用率较高的节点也不会考虑缩小规模。由于加速器的相对成本，这种行为可能会很昂贵。相反，如果节点有未占用的加速器，集群自动扩缩程序可以应用特殊规则来考虑缩小规模。

为了确保在这些情况下行为正确，您可以在加速器节点上配置 kubelet，使其在节点加入集群之前对其进行标记。Cluster Autoscaler 将使用此标签选择器来触发加速器优化行为。

确保：

从 0 开始缩放

Cluster Autoscaler 能够将节点组扩展到零或从零缩放，这可以节省大量成本。它通过检查 LaunchConfiguration 或 LaunchTemplate中InstanceType 指定的来检测 Auto Scaling 组的 CPU、内存和 GPU 资源。有些 pod 需要额外的资源，例如WindowsENI或PrivateIPv4Address或特定的 NodeSelectors 或 Taints，这些资源无法从中 LaunchConfiguration发现。集群自动扩缩程序可以通过从 Aut EC2 o Scaling 组上的标签中发现这些因素来解释这些因素。例如：

Key: k8s.io/cluster-autoscaler/node-template/resources/$RESOURCE_NAME
Value: 5
Key: k8s.io/cluster-autoscaler/node-template/label/$LABEL_KEY
Value: $LABEL_VALUE
Key: k8s.io/cluster-autoscaler/node-template/taint/$TAINT_KEY
Value: NoSchedule

注意：请记住，当扩展到零时，您的容量将恢复到EC2 并可能在将来不可用。

其他参数

有许多配置选项可用于调整 Cluster Autoscaler 的行为和性能。有关参数的完整列表，请访问GitHub。

其他资源

本页包含集群自动扩缩器演示和演示的列表。如果您想在此处添加演示文稿或演示，请发送拉取请求。

参考信息