Cluster Autoscaler - Amazon EKS
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

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

Cluster Autoscaler

KubernetesCluster Autoscaler当容器失败或重新安排到其他节点时,会自动调整集群中的节点数。群集自动扩展器通常作为部署(位于集群中)。它使用领导选举,以确保高可用性,但一次只能由一个副本完成扩展。

在部署集群自动扩展器之前,请确保您熟悉 Kubernetes 概念如何与Amazon功能。本主题中使用了以下术语:

  • Kubernetes Cluster Autoscaler —Kubernetes 控制层面的核心组件,用于制定调度和缩放决策。有关更多信息,请参阅 。Kubernetes 控制层面常见问题(位于 GitHub 上)。

  • Amazon云提供商实施 —Kubernetes 集群自动缩放器的扩展,通过与通信实现库贝内特斯群集自动扩展器的决策Amazon产品和服务,例如 Amazon EC2。有关更多信息,请参阅 。Cluster Autoscaler 上的Amazon(位于 GitHub 上)。

  • 节点组— 集群中一组节点的 Kubernetes 抽象。节点组不是真正的 Kubernetes 资源,但它们在集群自动扩展器、集群 API 和其他组件中作为抽象找到。在单个节点组中找到的节点可能共享多个常见属性,如标签和污点。但是,它们仍然可以由多个可用区或实例类型组成。

  • Amazon EC2 Auto Scaling 组— 的一个功能Amazon集群自动缩放器使用的。Auto Scaling 组适用于大量使用案例。Amazon EC2 Auto Scaling 组配置为启动自动加入其 Kubernetes 集群的实例。它们还将标签和污染应用到 Kubernetes API 中的相应节点资源。

作为参考,托管节点组使用 Amazon EC2 Auto Scaling 组进行管理,并且与集群自动扩展器兼容。

本主题介绍如何将集群自动扩展器部署到您的 Amazon EKS 集群,并将其配置为修改 Amazon EC2 Auto Scaling 组。

Prerequisites

在部署集群自动扩展程序之前,您必须满足以下先决条件:

  • 拥有现有 Kubernetes 集群 — 如果您没有集群,请参阅创建 Amazon EKS 群集

  • 集群的现有 IAM OIDC 提供商。若要确定是否有或需要创建一个,请参阅为您的集群创建 IAM OIDC 提供商

  • 具有 Auto Scaling 组标签的节点组 — Cluster Autoscaler 要求您的 Auto Scaling 组上具有以下标签,以便能够自动发现它们。

    • 如果您使用eksctl创建您的节点组,则这些标签会自动应用。

    • 如果您没有使用eksctl中,您必须使用以下标签手动标记 Auto Scaling 组。有关更多信息,请参阅 。为 Amazon EC2 资源添加标签适用于 Linux 实例的 Amazon EC2 用户指南中的相关信息。

    密钥
    k8s.io/cluster-autoscaler/<cluster-name>

    owned

    k8s.io/cluster-autoscaler/enabled TRUE

创建 IAM 策略和角色

创建用于授予群集自动扩展器使用 IAM 角色所需的权限的 IAM 策略。替换所有<example-values>(包括<>),并在整个过程中添加您自己的值。

  1. 创建一个 IAM 策略。

    1. 将以下内容保存到名为cluster-autoscaler-policy.json。如果您的现有节点组是使用eksctl,并且您使用了--asg-access选项,则此策略已存在,并且可以跳到步骤 2。

      { "Version": "2012-10-17", "Statement": [ { "Action": [ "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeAutoScalingInstances", "autoscaling:DescribeLaunchConfigurations", "autoscaling:DescribeTags", "autoscaling:SetDesiredCapacity", "autoscaling:TerminateInstanceInAutoScalingGroup", "ec2:DescribeLaunchTemplateVersions" ], "Resource": "*", "Effect": "Allow" } ] }
    2. 使用以下命令创建策略。您可以更改policy-name

      aws iam create-policy \ --policy-name AmazonEKSClusterAutoscalerPolicy \ --policy-document file://cluster-autoscaler-policy.json

      记下输出中返回的 Amazon 资源名称 (ARN)。您需要在后面的步骤中使用它。

  2. 您可以使用创建一个 IAM 角色并向该角色附加一个 IAM 策略。eksctl或Amazon Web Services Management Console。为以下说明选择所需的选项卡。

    eksctl
    1. 运行以下命令,如果您使用eksctl。如果您使用--asg-access选项,然后替换<AmazonEKSClusterAutoscalerPolicy>替换为 IAM 策略的名称eksctl为您创建。策略名称类似于eksctl-<cluster-name>-nodegroup-ng-<xxxxxxxx>-PolicyAutoScaling

      eksctl create iamserviceaccount \ --cluster=<my-cluster> \ --namespace=kube-system \ --name=cluster-autoscaler \ --attach-policy-arn=arn:aws-cn:iam::<AWS_ACCOUNT_ID>:policy/<AmazonEKSClusterAutoscalerPolicy> \ --override-existing-serviceaccounts \ --approve
    2. 我们建议,如果您使用--asg-access选项时,您可以分离eksctl创建并附加到亚马逊 EKS 节点 IAM 角色thateksctl为节点组创建。您将策略与节点 IAM 角色分离,以便集群自动扩展器正常运行。分离策略不会为节点上的其他窗格提供策略中的权限。有关更多信息,请参阅 。-删除 IAM 身份权限适用于 Linux 实例的 Amazon EC2 用户指南中的相关信息。

    Amazon Web Services Management Console
    1. 通过以下网址打开 IAM 控制台:https://console.aws.amazon.com/iam/

    2. 在导航面板中,选择角色创建角色

    3. Select type of trusted entity (选择受信任实体的类型) 部分中,选择 Web identity (Web 身份)

    4. Choose a web identity provider (选择 Web 身份提供商) 部分中:

      1. 对于 Identity provider (身份提供商),选择您集群的 URL。

      2. 对于 Audience (受众),请选择 sts.amazonaws.com

    5. 选择 Next:。Permissions (下一步:权限)

    6. 附加策略部分中,选择AmazonEKSClusterAutoscalerPolicy策略,您在步骤 1 中创建以用于服务帐户的策略。

    7. 选择 Next:。标签

    8. Add tags (optional) (添加标签(可选)) 屏幕上,您可以为账户添加标签。选择 Next:。审核

    9. 适用于角色名称中,为您的角色输入一个名称,例如AmazonEKSClusterAutoscalerRole,然后选择创建角色

    10. 创建角色后,在控制台中选择角色以将其打开进行编辑。

    11. 选择 Trust relationships 选项卡,然后选择 Edit trust relationship

    12. 找到类似于以下内容的行:

      "oidc.eks.cn-north-1.amazonaws.com.cn/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com"

      更改此行,使它与如下一行类似。Replace<EXAMPLED539D4633E53DE1B716D3041E>(包括<>)替换为集群的 OIDC 提供程序 ID,并 <region-code> 替换为集群所在的区域代码。

      "oidc.eks.<region-code>.amazonaws.com.cn/id/<EXAMPLED539D4633E53DE1B716D3041E>:sub": "system:serviceaccount:kube-system:cluster-autoscaler"
    13. 选择 Update Trust Policy (更新可信策略) 以完成操作。

部署 Cluster Autoscaler

要部署集群自动扩展程序,请完成以下步骤。建议查看部署注意事项并优化集群 Autoscaler 部署,然后再将其部署部署部署到生产群集。

部署 Cluster Autoscaler

  1. 中国 (宁夏) 或中国 (北京)

    1. 使用下面的命令下载 清单。

      curl -o cluster-autoscaler-autodiscover.yaml https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml
    2. 修改清单。

      1. 查看您下载的一个或多个清单文件,并记下映像的名称。使用以下命令在本地下载映像。

        docker pull image:<tag>
      2. 使用以下命令标记要推送到中国亚马逊弹性容器注册存储库的图像。

        docker tag image:<tag> <aws_account_id>.dkr.ecr.<cn-north-1>.amazonaws.com.cn/image:<tag>
      3. 使用以下命令将图像推送到中国亚马逊 ECR 存储库。

        docker push image:<tag> <aws_account_id>.dkr.ecr.<cn-north-1>.amazonaws.com.cn/image:<tag>
      4. 更新 Kubernetes 清单文件以引用您所在地区的亚马逊 ECR 图片 URL。

    3. 应用清单。

      kubectl apply -f cluster-autoscaler-autodiscover.yaml
  2. 将注释为cluster-autoscaler服务账户带有您之前创建的 IAM 角色的 ARN。将替换为<example values>使用您自己的值。

  3. 修补部署以添加cluster-autoscaler.kubernetes.io/safe-to-evict注释添加到集群自动缩放器窗格中。

    kubectl patch deployment cluster-autoscaler \ -n kube-system \ -p '{"spec":{"template":{"metadata":{"annotations":{"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"}}}}}'
  4. 使用以下命令编辑 Cluster Autoscaler 部署。

    kubectl -n kube-system edit deployment.apps/cluster-autoscaler

    编辑cluster-autoscaler要替换的容器命令<YOUR CLUSTER NAME>(包括<>),然后添加以下选项。

    • --balance-similar-node-groups

    • --skip-nodes-with-system-pods=false

    spec: containers: - command: - ./cluster-autoscaler - --v=4 - --stderrthreshold=info - --cloud-provider=aws - --skip-nodes-with-local-storage=false - --expander=least-waste - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME> - --balance-similar-node-groups - --skip-nodes-with-system-pods=false

    保存并关闭该文件以应用更改。

  5. 打开 Cluster Autoscaler版本页面,找到与 Kubernetes 主版本和次要版本相匹配的 Cluster Autoscaler 版本。例如,如果您集群的 Kubernetes 版本是 1.20,则查找以 1.20 开头的最新 Cluster Autoscaler 版本。记录语义版本号 (1.20.n),以在下一步中使用。

  6. 使用以下命令,将 Cluster Autoscaler 映像标签设置为您在上一步中记录的版本。Replace1.20.n使用您自己的值。

    kubectl set image deployment cluster-autoscaler \ -n kube-system \ cluster-autoscaler=k8s.gcr.io/autoscaling/cluster-autoscaler:v<1.20.n>

查看 Cluster Autoscaler 日志

部署 Cluster Autoscaler 之后,您可以查看日志并验证它在监控您的集群负载。

使用以下命令查看您的 Cluster Autoscaler 日志。

kubectl -n kube-system logs -f deployment.apps/cluster-autoscaler

您可以在一个 (扩展) 代码行中执行所有这些操作:

I0926 23:15:55.165842 1 static_autoscaler.go:138] Starting main loop I0926 23:15:55.166279 1 utils.go:595] No pod using affinity / antiaffinity found in cluster, disabling affinity predicate for this loop I0926 23:15:55.166293 1 static_autoscaler.go:294] Filtering out schedulables I0926 23:15:55.166330 1 static_autoscaler.go:311] No schedulable pods I0926 23:15:55.166338 1 static_autoscaler.go:319] No unschedulable pods I0926 23:15:55.166345 1 static_autoscaler.go:366] Calculating unneeded nodes I0926 23:15:55.166357 1 utils.go:552] Skipping ip-192-168-3-111.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166365 1 utils.go:552] Skipping ip-192-168-71-83.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166373 1 utils.go:552] Skipping ip-192-168-60-191.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166435 1 static_autoscaler.go:393] Scale down status: unneededOnly=false lastScaleUpTime=2019-09-26 21:42:40.908059094 ... I0926 23:15:55.166458 1 static_autoscaler.go:403] Starting scale down I0926 23:15:55.166488 1 scale_down.go:706] No candidates for scale down

部署注意事项

请查看以下注意事项,以优化您的集群自动扩展器部署。

扩展注意事项

群集自动扩展器可以配置为包含节点的任何附加功能。这些功能可以包括连接到节点的 Amazon EBS 卷、Amazon EC2 实例类型的节点或 GPU 加速器。

跨多个可用区域范围节点组

我们建议您配置多个节点组,将每个组的范围设置为单个可用区,并启用--balance-similar-node-groups功能。如果您只创建一个节点组,则将该节点组作为跨越多个可用区的范围。

优化节点组

群集自动扩展器会假设您如何使用节点组。这包括您在组中使用的实例类型。要与这些假设保持一致,请根据以下注意事项和建议配置节点组:

  • 节点组中的每个节点必须具有相同的调度属性。这包括标签、污点和资源。

    • 适用于MixedInstancePolicies,实例类型必须具有兼容的 CPU、内存和 GPU 规范。

    • 策略中指定的第一个实例类型模拟计划。

    • 如果您的策略具有具有更多资源的其他实例类型,则在扩展后可能会浪费资源。

    • 如果您的策略具有其他实例类型,其资源比原始实例类型少,则容器可能无法在实例上计划。

  • 使用较多节点配置较少数量的节点组,因为相反的配置可能会对可扩展性产生负面影响。

  • 只要两个系统都提供支持,就可以使用 Amazon EC2 功能(例如,使用区域和MixedInstancePolicy。)

如果可能,我们建议使用托管节点组。托管节点组具有强大的管理功能。这些功能包括集群自动扩展器的功能,如自动 Amazon EC2 Auto Scaling 组发现和优雅的节点终止。

使用 EBS 卷作为永久存储

持久存储对于构建有状态应用程序(如数据库和分布式缓存)至关重要。借助 Amazon EBS 卷,您可以在 Kubernetes 上构建有状态的应用程序。但是,您只能在单个可用区中构建它们。有关更多信息,请参阅 。如何在亚马逊 EKS 中使用永久存储?。要获得更好的解决方案,请考虑为每个可用区使用单独的 Amazon EBS 卷构建跨多个可用区域的有状态应用程序。这样做意味着您的应用程序可以具有高度可用性。此外,集群自动扩展器还可以平衡 Amazon EC2 自动扩展组的扩展。要执行此操作,请确保满足以下条件:

  • 节点组平衡是通过设置balance-similar-node-groups=true

  • 您的节点组配置了相同的设置(除了位于多个可用区域内并使用不同的 Amazon EBS 卷之外)。

共有调度

机器学习分布式培训作业从同区节点配置的延迟最小化中获益匪浅。这些工作负载将多个窗格部署到特定区域。您可以通过使用topologyKey: failure-domain.beta.kubernetes.io/zone。使用此配置,群集自动扩展器可扩展特定区域以满足需求。分配多个 Amazon EC2 Auto Scaling 组,每个可用区都有一个组,以便为整个共同计划的工作负载启用故障转移。确保满足以下条件:

  • 节点组平衡是通过设置balance-similar-node-groups=false.

  • 节点关联Pod 抢占当群集同时包含区域节点组和分区节点组时,将使用这两者。

    • 使用节点关联强制或鼓励区域性豆荚并避免分区节点组。

    • 不要将区域窗格安排到区域节点组上。这样做可能会导致区域容量不平衡。

    • 配置Pod 抢占如果您的分区工作负载能够容忍中断和重新定位。这样做会在区域缩放的窗格中强制抢占和重新安排争议较少的区域。

加速器和 GPU

某些群集使用专用硬件加速器,例如专用 GPU。向外扩展时,加速器可能需要几分钟时间才能将资源通告到群集。在此期间,群集自动缩放器模拟此节点具有加速器。但是,在加速器准备就绪并更新节点的可用资源之前,无法在节点上安排挂起的窗格。这可能会导致重复不必要的扩展

即使加速器未使用,也不考虑使用加速器和高 CPU 或内存利用率的节点进行缩减。然而,这可能会导致不受损失的成本。为了避免这些成本,群集 Autoscaler 可以应用特殊规则来考虑节点进行缩小,如果节点具有未占用的加速器。

要确保这些情况的正确行为,请配置kubelet,以便在节点加入群集之前对其进行标记。群集自动缩放器使用此标签选择器调用加速器优化行为。确保满足以下条件:

  • 这些区域有:kubelet 配置为 GPU 节点--node-labels k8s.amazonaws.com/accelerator=$ACCELERATOR_TYPE

  • 带有加速器的节点遵守相同的调度属性规则。

从零扩展

群集自动缩放器可以将节点组扩展到零。这可能会显著节省成本。群集自动扩展器检测 Auto Scaling 组的 CPU、内存和 GPU 资源,方法是检查InstanceType中指定的LaunchConfiguration或者LaunchTemplate。某些容器需要额外的资源,例如WindowsENI或者PrivateIPv4Address。或者他们可能需要特定的NodeSelectors或者Taints。后两个不能从LaunchConfiguration。但是,群集自动扩展器可以通过从 Auto 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
注意
  • 当扩展到零时,您的容量将返回到 Amazon EC2,并且将来可能会变得不可用。

  • 您可以使用描述代码组以诊断从零扩展时托管节点组的问题。

其他配置参数

有许多配置选项可用于调整群集 Autoscaler 的行为和性能。有关参数的完整列表,请参阅CA 的参数是什么?(位于 GitHub 上)。

性能注意事项

您可以更改一些关键项目来调整集群 Autoscaler 的性能和可扩展性。主要资源是提供给进程的任何资源、算法的扫描间隔以及群集中的节点组数。但是,此算法的真正运行时复杂性也涉及其他几个因素。这些包括调度插件的复杂性和容器的数量。这些参数被认为是不可配置的参数,因为它们是集群工作负载的组成部分,并且不容易进行调整。

可扩展性是指随着 Kubernetes 集群中的容器和节点数量的增加,集群自动扩展器的性能如何。如果达到其可扩展性配额,则集群 Autoscaler 的性能和功能会降低。此外,当它超出其可扩展性配额时,群集 Autoscaler 无法再添加或删除群集中的节点。

性能是指集群自动扩展程序可以做出和实施扩展决策的速度。性能完美的集群 Autoscaler 可以立即做出决策并调用扩展操作,以响应特定条件,例如容器变得不可调度。

熟悉自动缩放算法的运行时复杂性。这样做可以更容易地调整群集 Autoscaler,以便在大型集群中运行良好(超过1,000 个节点)。

群集自动扩展器将整个群集的状态加载到内存中。这包括窗格、节点和节点组。在每个扫描间隔中,该算法会识别不可调度的容器并模拟每个节点组的调度。请知道,以不同的方式调整这些因素会带来不同的权衡。

垂直自动扩展

您可以通过增加其部署的资源请求,将群集 Autocaler 扩展到较大的群集。这是做到这一点的更简单的方法之一。增加大型群集的内存和 CPU。请知道,你应该增加多少内存和 CPU 在很大程度上取决于特定的群集大小。自动缩放算法将所有窗格和节点存储在内存中。在某些情况下,这可能会导致内存占用大于 1 GB。您通常需要手动增加资源。如果您发现您经常需要手动增加资源,请考虑使用插加项调整大小或者Vertical Pod Autoscaler来自动执行该过程。

减少节点组数量

您可以减少节点组的数量,以提高群集 Autoscaler 在大型群集中的性能。如果您以单个团队或应用程序为基础构建节点组,这可能是一项挑战。尽管 Kubernetes API 完全支持这一点,但这被认为是一个集群自动扩展器反模式,会影响可扩展性。使用多个节点组有许多好处,例如,这些节点组同时使用竞价型或 GPU 实例。在许多情况下,可以在使用少量组的同时实现同样的效果的替代设计。确保满足以下条件:

  • 通过使用命名空间而不是节点组来隔离容器。

    • 您可能无法在低信任度多租户集群中执行此操作。

    • 设置窗格ResourceRequestsResourceLimits以避免资源争用。

    • 使用较大的实例类型实现更优化的箱包装,并减少系统容器开销。

  • 避免使用NodeTaints或者NodeSelectors以安排窗格。只能在有限的基础上使用它们。

  • 将区域资源定义为具有多个可用区的单个 Amazon EC2 Auto Scaling 组。

减少扫描间隔

使用较低的扫描间隔(如默认设置为 10 秒)可确保群集 Autoscaler 在容器变为不可调度时尽快响应。但是,每次扫描都会导致对 Kubernetes API 和 Amazon EC2 Auto Scaling 组或 Amazon EKS 托管节点组 API 进行多次 API 调用。这些 API 调用可能会导致您的 Kubernetes 控制平面的速率限制甚至服务不可用。

默认扫描间隔为十秒,但在Amazon,启动节点需要更长时间来启动一个新的实例。这意味着可以在不显著增加整体扩展时间的情况下增加间隔。例如,如果启动节点需要两分钟时间,请不要将间隔更改为一分钟,因为这可能会导致减少 6 倍的 API 调用,缩减 38% 的扩展速度。

跨节点组分片

您可以将群集自动扩展器配置为对一组特定的节点组进行操作。通过使用此功能,您可以部署集群自动扩展器的多个实例。将每个实例配置为在一组不同的节点组上运行。通过这样做,你可以使用任意大量的节点组,交易成本的可扩展性。但是,我们只建议您在提高群集 Autoscaler 性能的最后手段执行此操作。

这种配置有其缺点。这可能会导致不必要的向外扩展多个节点组。额外的节点在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

确保满足以下条件。

  • 每个分片都配置为指向一组唯一的 Amazon EC2 Auto Scaling 组。

  • 每个分片都部署到一个单独的命名空间,以避免领导者选举冲突。

成本效益和可用性

调整集群自动扩展器成本效益的主要选项与配置 Amazon EC2 实例有关。此外,成本效益必须与可用性保持平衡。本节介绍使用竞价型实例降低成本和过度配置以减少创建新节点时的延迟等策略。

  • 可用性— 可以快速安排舱,而不会中断。即使在需要安排新创建的窗格以及缩小节点终止为其计划的任何剩余窗格时,也是如此。

  • Cost— 由扩大和缩减事件背后的决策决定。如果现有节点未充分利用,或者添加的新节点太大,无法传入容器,则资源将浪费。根据具体的使用情形,由于积极的缩减决策,可能会产生与过早终止容器相关的成本。

Spot 实例

您可以在节点组中使用竞价型实例,以节省高达 90% 的按需价格折扣。当 Amazon EC2 需要返回容量时,竞价型实例可能会在任何时候中断。Insufficient Capacity Errors只要您的 Amazon EC2 Auto Scaling 组由于缺乏可用容量而无法向上扩展,就会发生这种情况。选择许多不同的实例系列有两个主要好处。首先,它可以通过利用许多竞价型容量池来增加实现所需扩展的机会。其次,它还可以减少竞价型实例中断对集群可用性的影响。具有竞价型实例的混合实例策略是在不增加节点组数量的情况下增加多样性的好方法。但是,请注意,如果您需要有保证的资源,请使用按需实例而不是竞价型实例。

当对实例的需求增加时,竞价型实例可能会终止。有关更多信息,请参阅 。竞价型实例中断适用于 Linux 实例的 Amazon EC2 用户指南部分。这些区域有:Amazon节点终止处理程序项目会在节点关闭时自动提醒 Kubernetes 控制平面。该项目使用 Kubernetes API 封锁节点,以确保没有安排任何新工作,然后排除它并删除任何现有工作。

所有实例类型在配置混合实例策略。自动扩展器的调度模拟器使用混合实例策略中的第一个实例类型。如果后续实例类型较大,资源可能会在向上扩展后浪费。如果实例较小,则由于容量不足,您的容量可能无法在新实例上安排。例如,M4M5M5a,M5n实例都具有相似数量的 CPU 和内存,是混合实例策略的绝佳候选项。Amazon EC2 实例选择器工具可帮助您识别类似的实例类型。有关更多信息,请参阅 。Amazon EC2 实例选择器(位于 GitHub 上)。

我们建议您将按需和竞价型实例容量隔离到单独的 Amazon EC2 Auto Scaling 组中。我们建议使用一个基本容量策略,因为按需实例和竞价型实例的调度属性不同。可随时中断竞价型实例。当 Amazon EC2 需要返回容量时,抢占节点通常会受到影响,因此需要对抢占行为具有明确容忍容量。这会导致节点的调度属性不同,因此应将它们分成多个 Amazon EC2 Auto Scaling 组。

集群自动缩放器涉及Expand。它们为选择要扩展的节点组提供了不同的策略。A. 战略--expander=least-waste是一个很好的通用默认设置,如果您打算使用多个节点组实现竞价型实例多样化(如前所述),它可以通过扩展活动后最好利用的组来进一步优化节点组的成本。

确定节点组或 Auto Scaling 组的优先级

您还可以通过使用Priority扩展器。--expander=priority使您的集群能够确定节点组或 Auto Scaling 组的优先级,如果由于任何原因无法扩展,它将选择优先级列表中的下一个节点组。这在某些情况下非常有用,例如,您想要使用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.*

集群 Auto Scaler 尝试向上扩展 Amazon EC2 Auto Scaling 组与名称匹配p3-node-group。如果此操作在--max-node-provision-time,然后尝试扩展 Amazon EC2 Auto Scaling 组与名称相匹配p2-node-group。此值默认为 15 分钟,可以缩短,以便更快地选择节点组。但是,如果该值太低,则可能会发生不必要的向外扩展。

Overprovisioning

群集 Autoscaler 通过确保节点仅在需要时添加到群集,并在未使用时删除节点,从而帮助最大限度地降低成本。这会极大地影响部署延迟,因为许多窗格必须等待节点向上扩展,然后才能计划它们。节点可能需要几分钟才能变为可用,这可能会将容器调度延迟增加一个数量级。

这可以通过过度配置,它为调度延迟交易成本。过度配置是使用具有负优先级的临时窗格实施的。这些窗格占用集群中的空间。当新创建的窗格不可调度且具有较高的优先级时,会抢占临时窗格以腾出空间。然后,临时窗格变得不可调度,从而导致群集 Autoscaler 向外扩展新的过度置备节点。

过度配置还有其他好处。在没有过度配置的情况下,高利用率群集中的容器可以使用preferredDuringSchedulingIgnoredDuringExecution规则。这样做的一个常见用例是使用AntiAffinity。过度配置可以显著增加所需区域的节点可用的几率。

选择适当数量的过度配置容量非常重要。您可以确保选择适当数量的一种方法是:计算平均向上扩展频率,然后除以向上扩展新节点所需的时间。例如,如果您平均每 30 秒需要一个新节点,而 Amazon EC2 需要 30 秒来配置新节点,则单个过度配置节点可确保始终有一个额外的节点可用。这样做可以将计划延迟减少 30 秒,代价为单个额外的 Amazon EC2 实例。为了做出更好的分区调度决策,您还可以过度配置节点数,使其与 Amazon EC2 Auto Scaling 组中的可用区数量相同。执行此操作可确保调度程序可以为传入容器选择最佳区域。

防止减少驱逐

某些工作负载驱逐成本高昂。大数据分析、机器学习任务和测试运行者可能需要很长时间才能完成,如果中断,则必须重新启动。群集自动缩放器有助于缩小scale-down-utilization-threshold。这会中断节点上的所有剩余容器。但是,您可以通过确保驱出昂贵的窗格受到群集 Autoscaler 识别的标签的保护来防止这种情况发生。要做到这一点,请确保昂贵的驱逐舱具有标签cluster-autoscaler.kubernetes.io/safe-to-evict=false