规划 GKE Standard 节点大小

本页面介绍如何规划 Google Kubernetes Engine (GKE) Standard 节点池中节点的大小，以降低工作负载中断和资源不足所致终止情况的风险。在 GKE Autopilot 中不需要进行此规划，因为 Google 会为您管理节点。

合理调整节点大小的优势

确保您的节点大小正确以适应您的工作负载并处理活动高峰具有以下好处：

  • 可降低资源不足逐出的风险，从而提高工作负载的可靠性。
  • 提高了可伸缩性，用于在高流量期间扩缩工作负载。
  • 降低成本，因为节点不会出现对您的需求来说过大的情况（这可能会导致资源浪费）。

节点可分配资源

GKE 节点运行系统组件，以使该节点作为集群的一部分运行。这些组件使用节点资源，例如 CPU 和内存。您可能会注意到节点的总资源（基于底层 Compute Engine 虚拟机 (VM) 的大小）与可供 GKE 工作负载请求的资源之间存在差异。这种差异是因为 GKE 为系统功能和节点可靠性预留了预定义的资源数量。GKE 为系统资源预留的磁盘可用空间因节点映像而异。可用于工作负载的剩余资源称为可分配资源。

在清单中定义 Pod 时，您可以在 Pod 规范中指定资源请求和限制。当 GKE 将 Pod 放置在节点上时，Pod 会从节点上的可分配资源请求这些指定的资源。在规划节点池中节点的大小时，您应该考虑工作负载需要多少资源才能正常运行。

检查节点上的可分配资源

如需检查现有节点上的可分配资源，请运行以下命令：

kubectl get node NODE_NAME \
    -o=yaml | grep -A 7 -B 7 capacity

将 NODE_NAME 替换为该节点的名称。

输出内容类似如下：

allocatable:
  attachable-volumes-gce-pd: "127"
  cpu: 3920m
  ephemeral-storage: "47060071478"
  hugepages-1Gi: "0"
  hugepages-2Mi: "0"
  memory: 13498416Ki
  pods: "110"
capacity:
  attachable-volumes-gce-pd: "127"
  cpu: "4"
  ephemeral-storage: 98831908Ki
  hugepages-1Gi: "0"
  hugepages-2Mi: "0"
  memory: 16393264Ki
  pods: "110"

在此输出中，allocatable 部分中的值是节点上的可分配资源。capacity 部分的值是节点上的总资源。临时存储的单位是字节。

GKE 资源预留

GKE 会根据节点上可用的资源总大小，在节点上预留特定数量的内存和 CPU 资源。机器类型越大，运行的容器和 Pod 就越多，因此 GKE 预留的资源数量也会随着机器大小的增加而扩容。此外，Windows Server 节点比等效的 Linux 节点还需要更多资源，以运行 Windows 操作系统和无法在容器中运行的 Windows Server 组件。

内存和 CPU 预留

以下部分介绍了基于机器类型的默认内存和 CPU 预留。

内存预留

对于内存资源，GKE 会预留：

  • 内存不足 1 GiB 的机器的 255 MiB 内存
  • 前 4 GiB 内存的 25%
  • 接下来 4 GiB 内存（最多 8 GiB）的 20%
  • 接下来 8 GiB 内存（最多 16 GiB）的 10%
  • 接下来 112 GiB 内存（最多 128 GiB）的 6%
  • 128 GiB 以上任何内存的 2%

GKE 还会在每个节点上额外预留 100 MiB 内存，用于处理 Pod 逐出。

CPU 预留

对于 CPU 资源，GKE 会预留：

  • 第一个核心的 6%
  • 下一个核心（最多 2 个核心）的 1%
  • 接下来 2 个核心（最多 4 个核心）的 0.5%
  • 4 个以上任何核心数量的 0.25%

对于共享核心 E2 机器类型，GKE 总共预留了 1060 个 millicore。

本地临时存储预留

GKE 提供具有本地临时存储空间的节点，由本地连接的设备（例如节点的启动磁盘或本地 SSD）提供支持。临时存储无法保证可用性，如果节点发生故障并被删除，则临时存储中的数据可能会丢失。

GKE 将节点总临时存储的一部分保留为单个文件系统，供 kubelet 在 Pod 逐出期间使用，并供节点上运行的其他系统组件使用。您可以将剩余的临时存储空间分配给 Pod，以用于日志等用途。如需了解如何在 Pod 中指定临时存储请求和限制，请参阅本地临时存储。

GKE 按如下方式计算本地临时存储预留：

EVICTION_THRESHOLD + SYSTEM_RESERVATION

实际值因支持存储的设备的大小和类型而异。

由节点启动磁盘支持的临时存储空间

默认情况下，临时存储由节点启动磁盘提供支持。在这种情况下，GKE 按如下方式确定逐出阈值的值：

EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY

逐出阈值始终为总启动磁盘容量的 10%。

GKE 按如下方式确定系统预留的值：

SYSTEM_RESERVATION = Min(50% * BOOT_DISK_CAPACITY, 6GiB + 35% * BOOT_DISK_CAPACITY, 100 GiB)

系统预留数量是以下各项中的最低数量：

  • 启动磁盘容量的 50%
  • 启动磁盘容量de 35% + 6 GiB
  • 100 GiB

例如，如果您的启动磁盘为 300 GiB，则以下值适用：

  • 50% 的容量：150 GiB
  • 35% 的容量 + 6 GiB：111 GiB
  • 100 GiB

GKE 会预留以下各项：

  • 系统预留：100 GiB（最小值）
  • 逐出阈值：30 GiB

预留的临时存储空间总量为 130 GiB。剩余的容量 (170 GiB) 是可分配的临时存储空间。

由本地 SSD 支持的临时存储空间

如果您的临时存储空间由本地 SSD 提供支持，GKE 会按如下方式计算逐出阈值：

EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GB

在此计算中，SSD_NUMBER 是挂接的本地 SSD 的数量。所有本地 SSD 的大小为 375 GB，因此逐出阈值为总临时存储容量的 10%。

GKE 会根据挂接的 SSD 数量计算系统预留，如下所示：

本地固态硬盘的数量 系统预留 (GiB)
1 50 GiB
2 75 GiB
3 个或更多 100 GiB

使用资源预留来规划节点大小

  1. 请考虑工作负载在部署时和负载下的资源要求。这包括工作负载的请求和计划限制，以及适应纵向扩容的开销。

  2. 考虑您需要少量大型节点还是大量小型节点来运行工作负载。

    • 少量大型节点非常适合不需要高可用性的资源密集型工作负载。节点自动扩缩不太敏捷，因为必须逐出更多 Pod 才能进行纵向缩容。
    • 大量小型节点非常适合非资源密集型的高可用性工作负载。节点自动扩缩更敏捷，因为只需逐出较少的 Pod 即可进行纵向缩容。

  3. 使用 Compute Engine 机器系列比较指南来确定节点所需的机器系列。

  4. 请考虑工作负载的临时存储要求。节点启动磁盘是否足够？您是否需要本地 SSD？

  5. 使用前面部分中的信息计算所选机器类型的可分配资源。将此信息与所需的资源和开销进行比较。

    • 如果您选择的机器类型过大，请考虑使用较小的机器，以免支付额外的资源费用。
    • 如果您选择的机器类型过小，请考虑使用较大的机器，以降低工作负载中断的风险。

后续步骤