可扩缩性

本页面介绍了创建、配置和运行 Anthos clusters on VMware (GKE On-Prem) 集群的最佳做法，以适应那些满足 Kubernetes 可扩缩性限制的工作负载。

可扩缩性限制

在 Anthos clusters on VMware 上设计应用时，请考虑以下限制：

  • 每个管理员集群最多支持 20 个用户集群，包括高可用性 (HA) 用户集群和非高可用性 (HA) 用户集群。

  • 每个用户集群最多支持：

  • 对于每个节点，您最多可以创建 110 个 Pod（每个 Pod 可以由 1 到 2 个容器组成）。其中包括运行插件系统服务的 Pod。

了解限制

因为 Anthos clusters on VMware 是一个集成表面很大的复杂系统，所以集群可扩缩性涉及许多相互关联的维度。例如，Anthos clusters on VMware 可以通过节点、pod 或 Service 数量进行扩缩。一次扩展多个维度可能会导致问题，即使是在较小的集群中也是如此。例如，在含有 250 个节点的集群中为每个节点安排 110 个 pod 可能会使得 pod 数、每个节点的 pod 数和节点数扩展得太多。

如需了解详情，请参阅 Kubernetes 可扩缩性阈值。

可扩缩性限制对集群运行所在的 vSphere 配置和硬件也极为敏感。这些限制已在可能与您的环境不同的环境中经过验证。因此，当底层环境成为限制因素时，您可能无法重现确切的数字。

准备扩缩

在准备进行扩缩时，请考虑 vSphere 基础架构、Kubernetes 网络、GKE Hub 以及 Cloud Logging 和 Cloud Monitoring 的要求和限制。

vSphere 基础架构

本部分介绍针对 CPU、内存、存储、磁盘和网络 I/O 要求以及节点 IP 地址的可扩缩性注意事项。

CPU、内存和存储空间要求

控制层面虚拟机需符合以下要求：

  • 管理员集群控制平面和插件节点最多可以支持 20 个用户集群，包括高可用性 (HA) 用户集群和非高可用性 (HA) 用户集群。因此，管理员集群无需调整。

  • 默认用户集群控制层面虚拟机配置（4 个 CPU、8GB 内存和 40GB 存储空间）是用户集群中最多运行 250 个节点所需的最低设置。

查看每个虚拟机的 CPU、RAM 和存储空间要求。

磁盘和网络 I/O 要求

数据密集型工作负载和某些控制层面组件对磁盘和网络 I/O 延迟时间敏感。例如，在具有数十个节点和数千个 Pod 的集群中，etcd 的性能和稳定性通常需要 500 个顺序 IOPS（例如典型的 SSD 或高性能虚拟化块设备）。

节点 IP 地址

每个 Anthos clusters on VMware 节点都需要一个 DHCP 或静态分配的 IP 地址。

例如，在包含一个含有 50 个节点的非高可用性 (HA) 用户集群和一个含有 250 个节点的高可用性 (HA) 用户集群的设置中，需要 308 个 IP 地址。下表显示了 IP 地址的明细：

节点类型 IP 地址数量
管理员集群控制层面虚拟机 1
管理员集群插件节点虚拟机 3
用户集群 1（非 HA）控制层面虚拟机 1
用户集群 1 节点虚拟机 50
用户集群 2 (HA) 控制层面虚拟机 3
用户集群 2 节点虚拟机 250
总计 308

Kubernetes 网络

本部分介绍 Pod CIDR 地址块和 Kubernetes Service 的可扩缩注意事项。

Pod CIDR 地址块

Pod CIDR 地址块是用户集群中所有 pod 的 CIDR 地址块。在此范围内，系统会为每个节点分配较小的 /24 地址块。如果您需要 N 节点集群，则必须确保此地址块足够大，能够支持 N 个 /24 地址块。

下表介绍了不同 pod CIDR 地址块大小支持的节点数上限：

pod CIDR 地址块大小 支持的节点数上限
/19 32
/18 64
/17 128
/16 256

默认的 pod CIDR 地址块为 192.168.0.0/16，支持 256 个节点。通过默认的 pod CIDR 地址块，您可以创建具有 250 个节点的集群，这是 Anthos clusters on VMware 在用户集群中支持的节点数上限。

Kubernetes Service

本部分介绍了 Service CIDR 地址块和负载平衡器的可扩缩性注意事项。

Service CIDR 地址块

Service CIDR 地址块是用户集群中所有 Service 的 CIDR 地址块。在本部分中讨论的 Service 是指类型为 LoadBalancer 的 Kubernetes 服务。

下表介绍了不同 Service CIDR 地址块大小支持的最大 Service 数量：

Service CIDR 地址块大小 支持的 Service 数量上限
/20 4096
/19 8192
/18 16384

默认值为 10.96.0.0/12，支持 1,048,576 个 Service。通过默认 Service CIDR 地址块，您可以创建具有 500 个 Service 的集群，这是 Anthos clusters on VMware 在用户集群中支持的 Service 数上限。

负载平衡器

集群中的节点数量以及可以在负载平衡器上配置的 Service 数量有限制。

对于捆绑式负载均衡 (Seesaw)，健康检查数量也有限制。健康检查数量取决于节点数和本地流量 Service 数。本地流量 Service 是 externalTrafficPolicy 设置为 Local 的 Service。

下表介绍了捆绑式负载均衡 (Seesaw) 和集成负载均衡 (F5) 的 Service、节点和健康检查数上限：

捆绑式负载平衡 (Seesaw) 集成负载平衡 (F5)
Service 数上限 500 250 2
节点数上限 250 250 2
最大健康检查数 N + (L * N) <= 10K，其中 N 是节点数，L 是流量本地服务的数量 1 N/A 2

1 例如，假设您有 100 个节点和 99 个本地流量 Service。健康检查数为 100 + (99 * 100) = 10,000，不超过 10,000 的限制。

2 如需了解详情，请参阅 F5。此数量受 F5 硬件型号、虚拟机实例 CPU/内存和许可等因素的影响。

GKE Hub

默认情况下，您最多可以注册 15 个用户集群。如需在 GKE Hub 中注册更多集群，您可以在 Google Cloud 控制台中提交增加配额申请。

Cloud Logging 和 Cloud Monitoring

Cloud Logging 和 Cloud Monitoring 可帮助您跟踪资源。

在用户集群中运行多个节点

在用户集群中部署的集群内代理的 CPU 和内存用量会根据用户集群中的节点数和 Pod 数量进行扩缩。

prometheus-server、stackdriver-prometheus-sidecar 和 stackdriver-log-aggregator 等 Cloud Logging 和 Cloud Monitoring 组件根据节点数量和 pod 数量具有不同的 CPU 和内存资源用量。在扩缩集群之前，请根据这些组件的平均用量设置资源请求和限制。下表显示了每个组件的平均用量的估算值：

节点数 容器名称 估计 CPU 利用率 估计内存用量
0 个 pod/节点 30 个 pod/节点 0 个 pod/节点 30 个 pod/节点
3 至 50 stackdriver-log-aggregator 150m 170m 1.6G 1.7G
prometheus-server 100m 390m 650M 1.3G
stackdriver-prometheus-sidecar 100m 340m 1.5G 1.6G
51 至 100 stackdriver-log-aggregator 220m 1100m 1.6G 1.8G
prometheus-server 160m 500m 1.8G 5.5G
stackdriver-prometheus-sidecar 200m 500m 1.9G 5.7G
101 至 250 stackdriver-log-aggregator 450m 1800m 1.7G 1.9G
prometheus-server 400m 2500m 6.5G 16G
stackdriver-prometheus-sidecar 400m 1300m 7.5G 12G

请确保您有足够的节点来安排 Cloud Logging 和 Cloud Monitoring 组件。一种方法是先创建小型集群，根据上表修改 Cloud Logging 和 Cloud Monitoring 组件资源，创建节点池以适应组件，然后将集群逐步纵向扩容到更大的大小。

您可以选择保持将足够大的节点池用于 Logging 和 Monitoring 组件，以防止将其他 pod 安排到节点池中。为此，您必须将以下污点添加到节点池中：

taints:
  - effect: NoSchedule
    key: node-role.gke.io/observability

这样可以防止在节点池上调度其他组件，并阻止用户因为监控组件的资源消耗而被逐出。

在管理员集群中运行多个用户集群

在管理员集群中部署的 Logging 和 Monitoring 组件的 CPU 和内存用量会根据用户集群的数量进行扩缩。

下表介绍了运行大量用户集群所需的管理员集群节点 CPU 和内存的数量：

用户集群数量 管理员集群节点 CPU 管理员集群节点内存
0 至 10 4 个 CPU 16 GB
11 至 20 4 个 CPU 32 GB

例如，如果有 2 个管理员集群节点，每个节点有 4 个 CPU 和 16GB 内存，则您可以运行 0 到 10 个用户集群。如需创建超过 10 个用户集群，则必须先将管理员集群节点大小内存从 16GB 调整为 32GB。

如需更改管理员集群节点的内存，请修改 MachineDeployment 配置：

  1. 运行以下命令：

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG edit machinedeployment gke-admin-node

    其中，ADMIN_CLUSTER_KUBECONFIG 是管理员集群的 kubeconfig 文件的路径。

  2. 将 spec.template.spec.providerSpec.value.machineVariables.memory 字段更改为 32768。

  3. 保存修改。重新创建具有 32GB 内存的管理员集群节点。

Dataplane V2

对于使用 Dataplane V2 的 500 个节点集群，我们建议为控制层面使用 120 GB 内存和 32 个 CPU 核心。

自动扩缩系统组件

Anthos clusters on VMware 会根据节点数自动扩缩系统组件，而不需要对配置进行任何更改。您可以使用本部分中的信息来规划资源。

  • Anthos clusters on VMware 通过使用 addon-resizer 来扩缩以下系统组件的 CPU 和内存请求/限制来自动执行垂直扩缩：

    • kube-state-metrics 是在集群工作器节点上运行的 Deployment，用于侦听 Kubernetes API 服务器并生成有关对象状态的指标。CPU 和内存请求和限制基于节点数进行扩缩。

      下表说明了系统根据集群中的节点数设置的资源请求/限制：

      节点数 近似1 CPU 请求/限制 (milli) 近似1 内存请求/限制 (Mi)
      3 至 5 105 110
      6 至 250 100 + num_nodes 100 + (2 * num_nodes)

      1 在扩缩过程中，有 +-5% 的余地减少组件重启次数。

      例如，在含有 50 个节点的集群中，CPU 请求/限制设置为 150m/150m，内存请求/限制设置为 200Mi/200Mi。在含有 250 个节点的集群中，CPU 请求/限制设置为 350m/350m，内存请求/限制设置为 600Mi。

    • metrics-server 是在 Kubernetes 内置自动扩缩流水线所使用的集群工作器节点上运行的 Deployment。

  • Anthos clusters on VMware 可通过扩缩以下系统组件的副本数量来自动执行横向扩缩：

    • kube-dns 是用于在 Anthos clusters on VMware 中发现服务的 DNS 解决方案。它在用户集群工作器节点上作为 Deployment 运行。Anthos clusters on VMware 会根据集群中的节点数和 CPU 核心数自动扩缩副本的数量。每增加/删除 16 个节点或 256 个核心，系统就会增加/减少 1 个副本。如果您的集群有 N 个节点和 C 个核心，则预期 max(N/16, C/256) 个副本。请注意，自从 Anthos clusters on VMware 1.4 以来，kube-dns 已经更新，以支持每秒 1500 个并发请求。

    • calico-typha 是一个组件，用于支持 Anthos clusters on VMware 中的 pod 网络。它在用户集群工作器节点上作为 Deployment 运行。Anthos clusters on VMware 会根据集群中的节点数自动扩缩副本数量。在节点数小于 200 个的集群中有 calico-typha 的 1 个副本，在节点数等于或大于 200 个的集群中有 calico-typha 的 2 个副本。

    • ingress-gateway/istio-pilot 是用于支持集群 Ingress 的组件，它们在用户集群工作器节点上作为 Deployment 运行。Anthos clusters on VMware 使用水平 pod 自动扩缩器来根据副本的 CPU 利用率扩缩副本数量，最少 2 个副本，最多 5 个副本。

最佳做法

本部分介绍扩缩资源的最佳做法。

分阶段扩缩集群

创建 Kubernetes 节点的操作包括将节点操作系统映像模板克隆到新的磁盘文件中，此操作是 I/O 密集型 vSphere 操作。克隆操作和工作负载 I/O 操作之间没有 I/O 隔离。如果同时创建的节点太多，则克隆操作将需要很长时间才能完成，并且可能会影响集群和现有工作负载的性能和稳定性。

确保根据 vSphere 资源分阶段扩缩集群。例如，如要将集群大小从 3 个节点调整到 250 个节点，请考虑分阶段进行：先将集群扩展到 80 个节点、接着扩展到 160 个节点，然后再扩展到 250 个节点。这有助于减少 vSphere 基础架构上的负载。

优化 etcd 磁盘 I/O 性能

etcd 是用作所有集群数据的 Kubernetes 后备存储的键值对存储。它的性能和稳定性对集群的运行状况至关重要，并且它对磁盘和网络 I/O 延迟时间敏感。

  • 按照以下建议优化用于控制层面虚拟机的 vSphere 数据存储区的 I/O 性能：

  • 几百毫秒的延迟会引起磁盘或网络 I/O 的瓶颈，还可能导致集群运行状况不佳。监控以下 etcd I/O 延迟时间指标并设置提醒阈值：

    • etcd_disk_backend_commit_duration_seconds
    • etcd_disk_wal_fsync_duration_seconds

优化节点启动磁盘 I/O 性能

pod 将临时存储空间用于内部操作，例如保存临时文件。临时存储空间由容器的可写入层、日志目录和 emptyDir 卷使用。临时存储空间来自 Anthos clusters on VMware 节点的文件系统，由节点的启动磁盘提供支持。

由于 Kubernetes 节点上没有存储空间 I/O 隔离，因此在其临时存储空间上使用高度高 I/O 的应用，可能导致通过加注星标的系统组件（如 Kubelet 和 Docker 守护程序）导致节点不稳定资源。

确保预配启动磁盘的数据存储区的 I/O 性能特征可为应用使用临时存储空间和日志记录流量提供合适的性能。

监控物理资源争用

请注意 vCPU 与 pCPU 比率和内存过度使用。物理主机上比率不佳或内存争用可能导致虚拟机性能下降。您应在主机层级监控物理资源利用率，并分配足够的资源来运行大型集群。