Azure Kubernetes 服务 (AKS) 中的节点资源预留

本文介绍 Azure Kubernetes 服务 (AKS) 中的节点资源预留。

资源预留

AKS 使用节点资源来帮助节点作为群集的一部分运行。 这种用法可能会造成节点的资源总数和 AKS 中可分配的资源数之间存在差异。

为了保持节点性能和功能，AKS 在每个节点上预留两种类型的资源（CPU 和内存）。 随着节点资源规模增大，由于对用户部署的 Pod 进行管理的需求更高，资源预留也会随之增加。 请记住，无法更改节点上的资源预留。

CPU 预留

预留的 CPU 取决于节点类型和群集配置，这可能会由于运行额外功能而导致可分配的 CPU 较少。 下表显示了 CPU 预留（以毫核为单位）：

主机上的 CPU 核心数 1 个核 2 个核心 4 核 8 核 16 核 32 个核心 64 个核心
为 Kube 预留的 CPU（毫核） 60 100 140 180 260 420 740

内存预留

AKS 中的预留内存包括两个值的总和：

AKS 1.29 及更高版本

  • 默认情况下，kubelet 守护程序具有memory.available < 100 Mi驱逐规则。 此规则确保节点至少有 100 Mi 可供分配。 当主机的可用内存低于该阈值时，kubelet 会触发终止其中一个正在运行的 Pod，并从主机上释放内存。

  • 根据以下较小值设置的内存预留率：20 MB * 节点上支持的最大 Pod 数 + 50 MB 或总系统内存资源的 25%。

    示例：

    • 如果虚拟机 (VM) 提供 8 GB 内存，并且节点最多支持 30 个 Pod，则 AKS 会为 kube-reserved 预留 20 MB * 30 个 Pod + 50 MB = 650 MB。 Allocatable space = 8 GB - 0.65 GB (kube-reserved) - 0.1 GB (eviction threshold) = 7.25 GB or 90.625% allocatable.
    • 如果 VM 提供 4 GB 内存，并且节点最多支持 70 个 Pod，AKS 将为 kube-reserved 预留 25% * 4 GB = 1000 MB，因为该值小于 20 MB * 70 个最大 Pod + 50 MB = 1450 MB。

注意

若要自定义 kubeReserved CPU 和内存值，或为 Linux 节点池配置 hardEvictionThreshold，请使用预览版自定义节点配置设置并注册 AKSNodeCustomizationPreview 功能标志。 有关详细信息，请参阅自定义Azure Kubernetes 服务 (AKS)节点池的节点配置。

1.29 之前的 AKS 版本

  • 默认情况下，kubelet daemon 具有 memory.available < 750 Mi 驱逐规则。 此规则确保节点始终至少有 750 Mi 可供分配。 当主机的可用内存低于该阈值时，kubelet 会终止其中一个正在运行的 Pod，并释放主机上的内存。
  • 为确保 kubelet 守护进程正常运行而按递减比率预留内存（kube-reserved）。
    • 前 4 GB 内存中的 25%
    • 下一个 4 GB 内存的 20%（最多 8 GB）
    • 下一个 8 GB 内存的 10%（最多 16 GB）
    • 接下来的 112 GB 内存的 6%（最多至 128 GB）
    • 任何超过 128 GB 的内存的 2%

注意

AKS 为计算内存中未包含的 Windows 节点中的系统进程额外保留 2 GB。

内存和 CPU 分配规则设计为：

  • 保持代理节点健康运行，包括那些承载对集群健康至关重要的系统 Pod 的节点。
  • 使节点报告的可分配内存和 CPU 数量少于它不属于 Kubernetes 群集时报告的数量。

例如，如果一个节点具有 7 GB 内存，它会报告 34% 的内存不可分配，其中包括 750 Mi 的硬逐出阈值。

0.75 + (0.25*4) + (0.20*3) = 0.75 GB + 1 GB + 0.6 GB = 2.35 GB / 7 GB = 33.57% reserved

除了 Kubernetes 本身的预留外，基础节点 OS 还预留了一定数量的 CPU 和内存资源以维持 OS 功能的运行。

如需相关的最佳做法，请参阅 AKS 中适用于基本计划程序功能的最佳做法。

后续步骤

  • Last updated on