本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # Cluster Autoscaler **提示** 通过 Amazon EKS 研讨会@@ [探索](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)最佳实践。 ## 概述 [Kubernetes 集群自动扩缩器是 SIG Autoscal](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) [ing 维护的流行集群自动扩缩解决方案。](https://github.com/kubernetes/community/tree/master/sig-autoscaling)它负责确保您的集群有足够的节点来调度 Pod，而不会浪费资源。它会监视调度失败的 Pod 和未充分利用的节点。然后，它会模拟节点的添加或移除，然后再将更改应用于您的集群。集群自动扩缩器中的 AWS 云提供商实施控制您的 EC2 Auto Scaling 组的`.DesiredReplicas`字段。 ![\[架构\]](http://docs.aws.amazon.com/zh_cn/eks/latest/best-practices/images/autoscaling/cas_architecture.png) 本指南将提供一个心理模型，用于配置集群自动扩缩程序并选择一组最佳的权衡方案来满足您的组织需求。虽然没有单一的最佳配置，但有一组配置选项可以让您在性能、可扩展性、成本和可用性之间进行权衡。此外，本指南还将提供有关优化 AWS 配置的提示和最佳实践。 ### 术语表 本文档中将经常使用以下术语。这些术语可能具有广泛的含义，但仅限于本文档的以下定义。 **可扩展性**是指随着 Kubernetes 集群的 Pod 和节点数量的增加，集群自动扩缩程序的表现如何。当达到可扩展性限制时，集群自动扩缩程序的性能和功能就会降低。当集群自动扩缩器超出其可扩展性限制时，它可能无法再在您的集群中添加或删除节点。 **性能**是指集群自动扩缩器能够以多快的速度做出和执行扩展决策。性能完美的 Cluster Autoscaler 会立即做出决定并触发缩放动作以响应刺激，例如 pod 变得不可调度。 **可用性**意味着可以快速、无中断地调度 pod。这包括何时需要对新创建的 Pod 进行调度，以及缩小规模的节点何时终止调度给它的所有剩余 Pod。 **成本**由事件中扩展和扩展背后的决策决定。如果现有节点未得到充分利用，或者添加的新节点对于传入的 Pod 来说太大，就会浪费资源。根据用例的不同，由于做出激进的缩减决定，过早终止 pod 可能会产生成本。 **节点组**是一个抽象的 Kubernetes 概念，用于集群中的一组节点。它不是真正的 Kubernetes 资源，而是作为抽象存在于集群自动扩缩器、集群 API 和其他组件中。节点组中的节点共享标签和污点等属性，但可能由多个可用区或实例类型组成。 **EC2 Auto Scaling 组**可用作 EC2 上节点组的实现。EC2 Auto Scaling 组配置为启动自动加入其 Kubernetes 集群的实例，并在 Kubernetes API 中为其相应的节点资源应用标签和污点。 **EC2 托管节点组**是 EC2 上节点组的另一种实现。它们消除了手动配置 EC2 AutoScaling Group 的复杂性，并提供了额外的管理功能，例如节点版本升级和优雅的节点终止。 ### 操作集群自动扩缩器 Cluster Autoscaler 通常作为[部署](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/aws/examples)安装在集群中。它使用[领导者选举](https://en.wikipedia.org/wiki/Leader_election)来确保高可用性，但一次只能通过一个副本完成工作。它不能横向扩展。对于基本设置，默认设置应该使用提供的[安装说明](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html)开箱即用，但有几点需要记住。 请确保： + 集群自动扩缩程序的版本与集群的版本相匹配。跨版本兼容性[未经过测试或支持](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/README.md#releases)。 + 除非您有阻止使用此模式的特定高级用例，否则将启用@@ [自动发现](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/aws#auto-discovery-setup)。 ### 使用对 IAM 角色的最低特权访问权限 使用 [Auto Discovery](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#Auto-discovery-setup) 时，我们强烈建议您使用最低权限访问权限，方法是`autoscaling:TerminateInstanceInAutoScalingGroup`将操作`autoscaling:SetDesiredCapacity`和范围限制在当前集群的 Auto Scaling 组。 这将防止在一个集群中运行的集群 Autoscaler 修改另一个集群中的节点组（例如），即使`--node-group-auto-discovery`参数的范围未缩小到使用标签的集群节点组。`k8s.io/cluster-autoscaler/` ``` { "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 使用 EC2 Auto Scaling 组来实现节点组，这些组可以灵活应用于大量用例。但是，集群自动扩缩器会对您的节点组进行一些假设。使您的 EC2 Auto Scaling 组配置与这些假设保持一致可以最大限度地减少不良行为。 请确保： + 节点组中的每个节点都有相同的调度属性，例如标签、污点和资源。 + 对于 MixedInstancePolicies，CPU、内存和 GPU 的实例类型的形状必须相同 + 策略中指定的第一个实例类型将用于模拟调度。 + 如果您的策略有其他实例类型和更多资源，则在扩展后可能会浪费资源。 + 如果您的策略中包含其他实例类型，且资源较少，则 Pod 可能无法在实例上调度。 + 与具有较少节点的许多节点组相比，具有多个节点的节点组更受青睐。这将对可扩展性产生最大的影响。 + 如果两个系统都提供支持，请尽可能首选 EC2 功能（例如区域 MixedInstancePolicy） **注意** 我们建议使用 [EKS 托管节点组](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)。托管节点组具有强大的管理功能，包括集群自动扩缩器的功能，例如自动发现 EC2 Auto Scaling 组和优雅地终止节点。 ## 针对性能和可扩展性进行优化 [了解自动扩缩算法的运行时复杂性将有助于您调整集群自动扩缩器，使其在节点数超过 1,000 的大型集群中继续平稳运行。](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/proposals/scalability_tests.md) 调整集群自动扩缩器可扩展性的主要旋钮是提供给进程的资源、算法的扫描间隔以及集群中节点组的数量。该算法的真实运行时复杂性还涉及其他因素，例如调度插件的复杂性和 pod 的数量。这些参数被认为是不可配置的参数，因为它们是集群工作负载的自然参数，并且不容易进行调整。 集群自动扩缩器将整个集群的状态加载到内存中，包括 Pod、节点和节点组。在每个扫描间隔内，该算法都会识别不可调度的 pod，并模拟每个节点组的调度。调整这些因素会带来不同的权衡取舍，对于您的用例，应仔细考虑这些权衡。 ### 垂直自动缩放集群自动扩缩器 将集群自动扩缩器扩展到更大的集群的最简单方法是增加其部署的资源请求。对于大型集群，应增加内存和 CPU，尽管这会因集群大小而有很大差异。自动缩放算法将所有 pod 和节点存储在内存中，在某些情况下，这可能会导致内存占用量大于 1 GB。增加资源通常是手动完成的。如果你发现持续的资源调整会带来运营负担，可以考虑使用 [Addon Resizer 或 Vertic [al Pod](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer)。 ### 减少节点组的数量 尽量减少节点组的数量是确保集群自动扩缩程序在大型集群上继续保持良好性能的一种方法。对于某些按团队或应用程序构建节点组的组织来说，这可能具有挑战性。虽然 Kubernetes API 完全支持这一点，但这被认为是一种集群自动扩缩程序的反模式，会对可扩展性产生影响。使用多个节点组的原因有很多（例如 Spot 或 GPUs），但在许多情况下，还有其他设计可以在使用少量组的情况下达到相同的效果。 请确保： + Pod 隔离是使用命名空间而不是节点组完成的。 + 在低信任度多租户集群中，这可能不可能实现。 + Pod ResourceRequests 和 ResourceLimits 已正确设置以避免资源争用。 + 更大的实例类型将带来更优的垃圾箱打包效果并减少系统容器开销。 + NodeTaints 或 NodeSelectors 用于将 pod 作为例外情况进行调度，而不是通常使用。 + 区域资源被定义为具有多个可用区的单个 EC2 Auto Scaling 组。 ### 缩短扫描间隔 低扫描间隔（例如 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 ``` 请确保： + 每个分片都配置为指向一组唯一的 EC2 Auto Scaling 组 + 每个分片都部署到单独的命名空间，以避免领导者选举冲突 ## 针对成本和可用性进行优化 ### 竞价型实例 您可以在节点组中使用竞价型实例，比按需价格节省高达 90% 的费用，但要权衡一下，当 EC2 需要恢复容量时，竞价型实例可以随时中断。当您的 EC2 Auto Scaling 组由于可用容量不足而无法扩展时，就会出现容量不足错误。通过选择多个实例系列来最大限度地提高多样性，可以利用许多竞价型容量池来增加实现所需规模的机会，并减少竞价型实例中断对集群可用性的影响。包含 Spot 实例的混合实例策略是在不增加节点组数量的情况下提高多样性的好方法。请记住，如果您需要有保障的资源，请使用按需实例而不是竞价型实例。 配置混合实例策略时，所有实例类型都必须具有相似的资源容量，这一点至关重要。自动扩缩程序的调度模拟器使用 InstanceType 中的第一个。 MixedInstancePolicy如果后续的实例类型更大，则在扩展后可能会浪费资源。如果容量较小，您的 Pod 可能会因为容量不足而无法在新实例上进行调度。例如，M4、M5、M5a 和 M5n 实例都具有相似的 CPU 和内存量，是理想的候选实例。 MixedInstancePolicy[EC2 实例选择器](https://github.com/aws/amazon-ec2-instance-selector)工具可以帮助您识别相似的实例类型。 ![\[Spot_mix_instance_policy\]](http://docs.aws.amazon.com/zh_cn/eks/latest/best-practices/images/autoscaling/cas_spot_mix_instance_policy.jpg) 建议将按需容量和竞价容量隔离到单独的 EC2 Auto Scaling 组中。这比使用[基本容量策略](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-instances-distribution)更可取，因为调度属性有根本的不同。由于竞价型实例随时会中断（当 EC2 需要恢复容量时），因此用户经常会污染其可抢占节点，这就要求对抢占行为有明确的 Pod 容忍度。这些污点会导致节点的调度属性不同，因此应将它们分成多个 EC2 Auto Scaling 组。 Cluster Autoscaler 有一个[扩展器的](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-are-expanders)概念，它为选择要扩展的节点组提供了不同的策略。该策略`--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 调度延迟增加一个数量级。 此问题可以通过[超额配置](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#how-can-i-configure-overprovisioning-with-cluster-autoscaler)来缓解，超额配置是以成本换取调度延迟。过度配置是使用优先级为负的临时 pod 实现的，这些容器会占用集群中的空间。当新创建的 pod 不可调度且优先级更高时，临时 pod 将被抢占以腾出空间。然后，临时 Pod 变得不可调度，从而触发集群自动扩缩程序扩展新的超额配置节点。 过度配置还有其他不太明显的好处。在没有过度配置的情况下，高利用率集群的副作用之一是，Pod 将使用 Pod 或 Node Affinity `preferredDuringSchedulingIgnoredDuringExecution` 规则做出不太理想的调度决策。一个常见的用例是使用将高可用性应用程序的 pod 分隔为多个可用区 AntiAffinity。过度配置会显著增加正确区域的节点可用的几率。 对于您的组织来说，过度配置的容量是一个谨慎的业务决策。从本质上讲，它是在性能和成本之间进行权衡。做出此决定的一种方法是确定您的平均扩容频率，然后将其除以向上扩展新节点所需的时间。例如，如果您平均每 30 秒需要一个新节点，而 EC2 需要 30 秒来配置一个新节点，那么单个超额配置节点将确保始终有一个额外的节点可用，从而将调度延迟缩短 30 秒，代价是增加一个 EC2 实例。要改进区域调度决策，请超额配置与 EC2 Auto Scaling 组中可用区数量相等的节点，以确保调度器可以为传入的 Pod 选择最佳区域。 ### 防止缩小规模驱逐 移出某些工作负载成本非常高昂。大数据分析、机器学习任务和测试运行器最终将完成，但如果中断，则必须重新启动。Cluster Autoscaler 将尝试缩小下方的任何节点 scale-down-utilization-threshold，这将中断该节点上所有剩余的 Pod。通过确保驱逐成本高昂的 Pod 受到集群自动扩缩器识别的标签的保护，可以防止这种情况。 请确保： + 有注释驱逐吊舱的代价很高 `cluster-autoscaler.kubernetes.io/safe-to-evict=false` ## 高级使用案例 ### EBS 卷 持久存储对于构建有状态的应用程序（例如数据库或分布式缓存）至关重要。[EBS 卷](https://aws.amazon.com/premiumsupport/knowledge-center/eks-persistent-storage/)在 Kubernetes 上启用此用例，但仅限于特定区域。如果在多个可用区之间使用单独的 EBS 卷对每个可用区进行分片，则这些应用程序可以具有高可用性。然后，集群自动扩缩器可以平衡 EC2 自动扩缩组的扩展。 请确保： + 通过设置 `balance-similar-node-groups=true` 启用节点组平衡。 + 节点组配置的设置完全相同，但可用区和 EBS 卷不同。 ### 共同调度 Machine Learning 分布式培训作业可从同区节点配置的最小化延迟中获益匪浅。这些工作负载将多个 Pod 部署到特定区域。这可以通过为所有共同调度的 pod 设置 Pod Affinity 或使用的 Node Affinity 来实现。`topologyKey: failure-domain.beta.kubernetes.io/zone`然后，集群自动扩缩器将扩展特定区域以满足需求。您可能希望分配多个 EC2 Auto Scaling 组，每个可用区一个，以便为整个联合计划的工作负载启用故障转移。 请确保： + 通过设置 `balance-similar-node-groups=false` 启用节点组平衡 + 当集群同时包含区域和区域@@ [节点组时，将使用节点关联](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)和/或 [Pod 抢占](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)。 + 使用 [Node Affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) 强制或鼓励区域 pod 避开区域节点组，反之亦然。 + 如果区域 Pod 调度到区域节点组，则会导致您的区域 Pod 的容量不平衡。 + 如果您的区域工作负载可以容忍中断和重新定位，请配置 [Pod Preemption](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) 以启用按区域扩展的 pod，以便在竞争较少的区域强制抢占和重新调度。 ### 加速器 一些集群利用专门的硬件加速器，例如 GPU。横向扩展时，加速器设备插件可能需要几分钟才能将资源通告到集群。Cluster Autoscaler 模拟该节点将配备加速器，但是在加速器准备就绪并更新节点的可用资源之前，无法在该节点上调度待处理的 Pod。这可能会导致[重复、不必要的横向扩展](https://github.com/kubernetes/kubernetes/issues/54959)。 此外，即使未使用加速器，CPU 或内存利用率较高的节点也不会考虑缩小规模。由于加速器的相对成本，这种行为可能会很昂贵。相反，如果节点有未占用的加速器，集群自动扩缩程序可以应用特殊规则来考虑缩小规模。 为了确保在这些情况下行为正确，您可以在加速器节点上配置 kubelet，使其在节点加入集群之前对其进行标记。集群自动扩缩程序将使用此标签选择器来触发加速器优化行为。 请确保： + 适用于 GPU 节点的 Kubelet 配置为 `--node-labels k8s.amazonaws.com/accelerator=$ACCELERATOR_TYPE` + 带有加速器的节点遵守上述相同的调度属性规则。 ### 从 0 开始缩放 Cluster Autoscaler 能够将节点组缩放到零或从零扩展，这可以节省大量成本。它通过检查 LaunchConfiguration 或 LaunchTemplate中InstanceType 指定的来检测 Auto Scaling 组的 CPU、内存和 GPU 资源。有些 pod 需要额外的资源，例如`WindowsENI`或`PrivateIPv4Address`或特定的 NodeSelectors 或 Taints，这些资源无法从中 LaunchConfiguration发现。集群自动扩缩程序可以通过从 EC2 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 ``` **注意** 请记住，当扩展到零时，您的容量将返回到 EC2，并且将来可能不可用。 ## 其他参数 有许多配置选项可用于调整 Cluster Autoscaler 的行为和性能。有关参数的完整列表，请访问[GitHub](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-are-the-parameters-to-ca)。 | 参数 | 说明 | 默认 | | --- | --- | --- | | 扫描间隔 | 为向上或向下扩展而重新评估集群的频率 | 10 秒 | | max-empty-bulk-delete | 可以同时删除的最大空节点数。 | 10 | | scale-down-delay-after-添加 | 在扩大规模后多久才会恢复缩小规模的评估 | 10 分钟 | | scale-down-delay-after-删除 | 节点删除后多长时间恢复缩小评估，默认为扫描间隔 | 扫描间隔 | | scale-down-delay-after-失败 | 缩减规模失败后多久可以恢复缩小规模的评估 | 3 分钟 | | scale-down-unneeded-time | 节点需要多长时间才有资格缩小规模 | 10 分钟 | | scale-down-unready-time | 未就绪的节点需要多长时间才有资格缩小规模 | 20 分钟 | | scale-down-utilization-threshold | 节点利用率级别，定义为请求的资源总和除以容量，低于该水平可以考虑缩减节点 | 0.5 | | scale-down-non-empty-候选人人数 | 在一次迭代中考虑作为排水向下缩减的候选节点的最大非空节点数。值越低意味着 CA 响应速度越好，但缩小延迟可能会变慢。较高的值可能会影响大型集群（数百个节点）的 CA 性能。设置为非正值可关闭此启发式算法-CA 不会限制其考虑的节点数量。 ” | 30 | | scale-down-candidates-pool-比例 | 当先前迭代中的某些候选节点不再有效时，被视为缩减的额外非空候选节点的比例。值越低意味着 CA 响应速度越好，但缩小延迟可能会变慢。较高的值可能会影响大型集群（数百个节点）的 CA 性能。设置为 1.0 可关闭此启发式算法-CA 会将所有节点作为其他候选节点。 | 0.1 | | scale-down-candidates-pool-最小计数 | 当先前迭代中的某些候选节点不再有效时，被视为向下缩减的额外非空候选节点的最小数量。在计算其他候选人的人才库规模时，我们会采用 `max(#nodes * scale-down-candidates-pool-ratio, scale-down-candidates-pool-min-count)` | 50 | ## 其他资源 本页包含集群自动扩缩器演示和演示的列表。如果您想在此处添加演示文稿或演示，请发送拉取请求。 | 演示/演示 | 主持人 | | --- | --- | | [Kubernetes 上的自动扩缩和成本优化：从 0 到 100](https://sched.co/Zemi) | Guy Templeton、Skyscanner 和 Jiaxin Shan，Amazon | | [SIG 自动缩放深度探索](https://youtu.be/odxPyW_rZNQ) | Maciek Pytel & Marcin Wielgus | ## 参考 + https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md + https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md + https://github.com/aws/亚马逊 ec2 实例选择器 + https://github.com/aws/aws-node-termination-handler