节点自动扩缩
为了在集群中运行工作负载，你需要节点。集群中的节点可以被**自动扩缩**——动态**供给**或**整合**，以提供所需容量并优化成本。自动扩缩由节点**自动扩缩器**执行。
节点供给
如果集群中有 Pod 无法调度到现有节点上，可以自动向集群添加新节点（**供给**）以容纳这些 Pod。这在 Pod 数量随时间变化时特别有用，例如由于结合水平工作负载自动扩缩和节点自动扩缩。
自动扩缩器通过创建和删除其背后的云提供商资源来供给节点。最常见的是，支持节点的资源是虚拟机。
供给的主要目标是使所有 Pod 都可以调度。这个目标并非总是可以实现，因为存在各种限制，包括达到配置的供给限制，供给配置与特定 Pod 集不兼容，或云提供商容量不足。在供给时，节点自动扩缩器通常会尝试实现其他目标（例如最小化供给节点的成本或平衡故障域之间的节点数量）。
节点自动扩缩器在决定要供给的节点时有两个主要输入：Pod 调度约束和自动扩缩器配置施加的节点约束。
自动扩缩器配置还可以包括其他节点供给触发器（例如，节点数量低于配置的最小限制）。
注意
在 Cluster Autoscaler 中，供给以前称为**扩容**。Pod 调度约束
Pod 可以表达调度约束来限制它们可以调度到的节点类型。节点自动扩缩器会考虑这些约束，以确保待处理的 Pod 可以调度到供给的节点上。
最常见的调度约束是 Pod 容器指定的资源请求。自动扩缩器将确保供给的节点具有足够的资源来满足这些请求。但是，它们不直接考虑 Pod 运行后实际的资源使用情况。为了根据实际工作负载资源使用情况自动扩缩节点，你可以将水平工作负载自动扩缩与节点自动扩缩结合使用。
其他常见的 Pod 调度约束包括节点亲和性、Pod 间亲和性或对特定存储卷的要求。
自动扩缩器配置施加的节点约束
供给节点的具体细节（例如资源量、是否存在给定标签）取决于自动扩缩器配置。自动扩缩器可以从预定义的节点配置集中选择它们，或使用自动供给。
自动供给
节点自动供给是一种供给模式，用户无需完全配置可以供给的节点的具体细节。相反，自动扩缩器根据其响应的待处理 Pod 以及预配置的约束（例如，最小资源量或对给定标签的需求）动态选择节点配置。
节点整合
运行集群时主要考虑的是确保所有可调度的 Pod 都在运行，同时将集群成本保持在尽可能低的水平。为了实现这一目标，Pod 的资源请求应尽可能多地利用节点的资源。从这个角度来看，集群中的整体节点利用率可以作为集群成本效益的衡量标准。
注意
正确设置 Pod 的资源请求对于集群的整体成本效益与优化节点利用率一样重要。将节点自动扩缩与垂直工作负载自动扩缩结合使用可以帮助你实现这一目标。集群中的节点可以自动**整合**，以提高整体节点利用率，进而提高集群的成本效益。整合通过从集群中移除一组利用率不足的节点来实现。另外，可以供给一组不同的节点来替换它们。
整合和供给一样，在做出决策时只考虑 Pod 资源请求，而不考虑实际资源使用情况。
出于整合目的，如果节点上只运行 DaemonSet 和静态 Pod，则该节点被认为是**空**的。在整合过程中移除空节点比移除非空节点更直接，自动扩缩器通常具有专门为整合空节点而设计的优化。
在整合过程中移除非空节点具有破坏性——运行在它们上面的 Pod 会被终止，并可能需要重新创建（例如通过 Deployment）。但是，所有这些重新创建的 Pod 都应该能够在集群中的现有节点上调度，或者作为整合一部分供给的替换节点上调度。**在整合过程中，通常不应有 Pod 变成待处理状态。**
注意
自动扩缩器会预测在节点供给或整合后，重新创建的 Pod 将如何调度，但它们不控制实际调度。因此，一些 Pod 可能会由于整合而变成待处理状态——例如，如果在执行整合时出现了一个全新的 Pod。自动扩缩器配置还可以根据其他条件（例如，节点创建以来经过的时间）触发整合，以优化不同的属性（例如，集群中节点的最大生命周期）。
整合的具体执行方式取决于给定自动扩缩器的配置。
注意
在 Cluster Autoscaler 中，整合以前称为**缩容**。自动扩缩器
前面几节中描述的功能由节点**自动扩缩器**提供。除了 Kubernetes API，自动扩缩器还需要与云提供商 API 交互以供给和整合节点。这意味着它们需要与每个受支持的云提供商进行显式集成。给定自动扩缩器的性能和功能集可能因云提供商集成而异。
自动扩缩器实现
Cluster Autoscaler 和 Karpenter 是目前由 SIG Autoscaling 赞助的两个节点自动扩缩器。
从集群用户的角度来看，这两个自动扩缩器都应该提供类似的节点自动扩缩体验。两者都将为无法调度的 Pod 供给新节点，并且都将整合不再以最佳方式利用的节点。
不同的自动扩缩器也可能提供此页面描述的节点自动扩缩范围之外的功能，这些附加功能可能有所不同。
请查阅以下部分以及各个自动扩缩器的链接文档，以决定哪个自动扩缩器更适合你的用例。
Cluster Autoscaler
Cluster Autoscaler 向预配置的**节点组**添加或删除节点。节点组通常映射到某种云提供商资源组（最常见的是虚拟机组）。单个 Cluster Autoscaler 实例可以同时管理多个节点组。在供给时，Cluster Autoscaler 会将节点添加到最符合待处理 Pod 请求的组中。在整合时，Cluster Autoscaler 总是选择要移除的特定节点，而不是仅仅调整底层云提供商资源组的大小。
附加背景信息
Karpenter
Karpenter 根据集群操作员提供的 NodePool 配置自动供给节点。Karpenter 处理节点生命周期的所有方面，而不仅仅是自动扩缩。这包括在节点达到一定生命周期后自动刷新节点，以及在新工作节点镜像发布时自动升级节点。它直接与单个云提供商资源（最常见的是单个虚拟机）配合使用，不依赖于云提供商资源组。
附加背景信息
实现比较
Cluster Autoscaler 和 Karpenter 的主要区别
- Cluster Autoscaler 仅提供与节点自动扩缩相关的功能。Karpenter 具有更广泛的范围，还提供用于管理节点生命周期的功能（例如，利用中断在节点达到一定生命周期后自动重新创建它们，或将它们自动升级到新版本）。
- Cluster Autoscaler 不支持自动供给，它可以供给的节点组必须预先配置。Karpenter 支持自动供给，因此用户只需配置一组供给节点的约束，而无需完全配置同构组。
- Cluster Autoscaler 直接提供云提供商集成，这意味着它们是 Kubernetes 项目的一部分。对于 Karpenter，Kubernetes 项目将 Karpenter 作为库发布，云提供商可以集成它来构建节点自动扩缩器。
- Cluster Autoscaler 集成了众多云提供商，包括较小和不太流行的提供商。与 Karpenter 集成的云提供商较少，包括 AWS 和 Azure。
结合工作负载和节点自动扩缩
水平工作负载自动扩缩
节点自动扩缩通常响应 Pods——它会供给新节点以容纳不可调度的 Pods，然后在 Pods 不再需要时整合这些节点。
水平工作负载自动扩缩自动扩缩工作负载副本的数量，以在副本中保持所需的平均资源利用率。换句话说，它会响应应用程序负载自动创建新 Pods，然后在负载降低时移除 Pods。
你可以将节点自动扩缩与水平工作负载自动扩缩结合使用，以根据 Pods 的平均实际资源利用率自动扩缩集群中的节点。
如果应用程序负载增加，其 Pods 的平均利用率也应增加，从而促使工作负载自动扩缩创建新的 Pods。节点自动扩缩应随后供给新节点以容纳新 Pods。
一旦应用程序负载降低，工作负载自动扩缩应移除不必要的 Pods。节点自动扩缩应反过来整合不再需要的节点。
如果配置正确，这种模式可确保你的应用程序始终具有节点容量以应对可能需要的负载高峰，但你在不需要容量时无需为此付费。
垂直工作负载自动扩缩
使用节点自动扩缩时，正确设置 Pod 资源请求非常重要。如果给定 Pod 的请求过低，为它供给新节点可能无法帮助该 Pod 实际运行。如果给定 Pod 的请求过高，它可能会错误地阻止整合其节点。
垂直工作负载自动扩缩根据 Pods 的历史资源使用情况自动调整其资源请求。
你可以将节点自动扩缩与垂直工作负载自动扩缩结合使用，以调整 Pods 的资源请求，同时保留集群中的节点自动扩缩能力。
注意
使用节点自动扩缩时，不建议为 DaemonSet Pod 设置垂直工作负载自动扩缩。自动扩缩器必须预测新节点上的 DaemonSet Pod 将是什么样子，才能预测可用的节点资源。垂直工作负载自动扩缩可能会使这些预测不可靠，从而导致错误的扩缩决策。相关组件
本节描述了提供与节点自动扩缩相关功能的组件。
Descheduler
descheduler 是一个提供基于自定义策略的节点整合功能以及其他与优化节点和 Pod 相关的特性（例如删除频繁重启的 Pod）的组件。
基于集群大小的工作负载自动扩缩器
Cluster Proportional Autoscaler 和 Cluster Proportional Vertical Autoscaler 根据集群中的节点数量提供水平和垂直工作负载自动扩缩。你可以在基于集群大小的自动扩缩中阅读更多信息。
下一步
- 阅读关于工作负载级别自动扩缩