本页面介绍了使用 Google Distributed Cloud for VMware（纯软件）创建、配置和运行集群的最佳实践，以适应那些接近 Kubernetes 可扩缩性限制的工作负载。
集群名称规则
对于每个 Google Cloud 项目：
- 每个用户集群在单个 Google Cloud 项目内的所有管理集群中必须具有唯一名称。
可扩缩性限制
在设计应用时，请考虑以下限制：
使用捆绑式负载均衡模式（Seesaw 或 MetalLB）或集成式负载均衡模式 (F5)，每个管理员集群最多支持 100 个用户集群，包括高可用性 (HA) 用户集群和非高可用性用户集群。
每个用户集群最多支持：
500 个使用捆绑式负载均衡模式（Seesaw 或 MetalLB）的节点，或 250 个使用集成式负载均衡模式 (F5) 的节点
15000 Pods
500 项使用捆绑式负载均衡模式（Seesaw 或 MetalLB）的 LoadBalancer 服务，或 250 项使用集成式负载均衡模式 (F5) 的 LoadBalancer 服务。
对于每个节点，您最多可以创建 110 个 Pod（每个 Pod 可以由 1 到 2 个容器组成）。其中包括运行插件系统服务的 Pod。
了解限制
因为 Google Distributed Cloud 是一个集成表面很大的复杂系统，所以集群可扩缩性涉及许多相互关联的维度。例如，Google Distributed Cloud 可以通过节点、Pod 或 Service 数量进行扩缩。一次扩展多个维度可能会导致问题，即使是在较小的集群中也是如此。例如，在含有 500 个节点的集群中为每个节点安排 110 个 pod 可能会使得 pod 数、每个节点的 pod 数和节点数扩展得太多。
如需了解详情，请参阅 Kubernetes 可扩缩性阈值。
可扩缩性限制对集群运行所在的 vSphere 配置和硬件也极为敏感。这些限制已在可能与您的环境不同的环境中经过验证。因此，当底层环境成为限制因素时，您可能无法重现确切的数字。
准备扩缩
在准备扩缩管理员集群或用户集群时，请考虑以下要求和限制。
CPU、内存和存储空间要求
查看每个虚拟机的 CPU、RAM 和存储空间要求。
磁盘和网络 I/O 要求
数据密集型工作负载和某些控制平面组件对磁盘和网络 I/O 延迟时间敏感。例如，在具有数十个节点和数千个 Pod 的集群中，etcd 的性能和稳定性通常需要 500 个顺序 IOPS（例如典型的 SSD 或高性能虚拟化块设备）。
节点 IP 地址
每个节点都需要一个 DHCP 或静态分配的 IP 地址。
例如，在包含一个含有 50 个节点的非高可用性 (HA) 用户集群和一个含有 250 个节点的高可用性 (HA) 用户集群的设置中，需要 307 个 IP 地址。
下表显示了 IP 地址的明细：
| 节点类型 | IP 地址数量 |
|---|---|
| 管理员集群控制平面虚拟机 | 3 |
| 用户集群 1（非 HA）控制层面虚拟机 | 1 |
| 用户集群 1 工作器节点虚拟机 | 50 |
| 用户集群 2 (HA) 控制层面虚拟机 | 3 |
| 用户集群 2 个工作器节点虚拟机 | 250 |
| 总计 | 307 |
在管理员集群中运行多个用户集群
在准备在管理员集群中运行多个用户集群时，请在创建管理员集群时执行以下步骤。
管理员集群中的 Pod CIDR 地址块
Pod CIDR 地址块是管理员集群中所有 Pod 的 CIDR 地址块。它通过 admin-cluster.yaml 中的 network.podCIDR 字段进行配置。
在此范围内，系统会为每个节点分配较小的 /24 地址块。如果所有用户集群都启用了 Controlplane V2，则管理员集群只有三个节点，并且有足够的 Pod IP 地址可用。但是，每次创建使用 kubeception（而非 Controlplane V2）的用户集群时，都会向管理员集群添加一个或三个节点：
每个高可用性 (HA) kubeception 用户集群都会向管理员集群添加三个节点。
每个非高可用性 kubeception 用户集群都会向管理员集群添加一个节点。
如果您需要一个 N 节点管理员集群，则必须确保 Pod CIDR 块足够大，能够支持 N 个 /24 地址块。
下表介绍了不同 pod CIDR 地址块大小支持的节点数上限：
| pod CIDR 地址块大小 | 支持的节点数上限 |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
管理员集群的默认 Pod CIDR 块为 192.168.0.0/16，支持 256 个节点。
在包含 100 个高可用性 kubeception 用户集群的管理员集群中，有 3 个管理员集群控制平面节点和 300 个用户集群控制平面节点。总节点数为 303（超过 256 个）。因此，您必须将 Pod CIDR 地址块更新为 /15，以支持多达 100 个高可用性 kubeception 用户集群。
如需配置 Pod CIDR 地址块，请在管理员集群配置文件中设置 network.podCIDR 字段。
管理员集群中的服务 CIDR 地址块
Service CIDR 地址块是管理员集群中所有服务的 CIDR 地址块。它通过 admin-cluster.yaml 中的 network.serviceCIDR 字段进行配置。
下表介绍了不同 Service CIDR 地址块大小支持的最大 Service 数量：
| Service CIDR 地址块大小 | 支持的 Service 数量上限 |
|---|---|
| /24 | 256 |
| /23 | 512 |
| /22 | 1024 |
默认值为 10.96.232.0/24，支持 256 个 Service。
每个 kubeception 用户集群使用 6 项 Service，管理员集群控制平面使用 14 项 Service。因此，若要运行 100 个 kubeception 用户集群，您必须更改管理员集群中的 Service CIDR 地址块以使用 /22 范围。
Cloud Logging 和 Cloud Monitoring
Cloud Logging 和 Cloud Monitoring 可帮助您跟踪资源。
在管理员集群中部署的 Logging 和 Monitoring 组件的 CPU 和内存用量会根据 kubeception 用户集群的数量进行扩缩。
下表列出了运行大量 kubeception 用户集群所需的管理员集群节点 CPU 和内存的数量：
| kubeception 用户集群的数量 | 管理员集群节点 CPU | 管理员集群节点内存 |
|---|---|---|
| 0 至 10 | 4 个 CPU | 16 GB |
| 11 至 20 | 4 个 CPU | 32 GB |
| 20 至 100 | 4 个 CPU | 90GB |
例如，如果有 2 个管理员集群节点，每个节点有 4 个 CPU 和 16 GB 内存，则您可以运行 0 到 10 个 kubeception 用户集群。如需创建超过 20 个 kubeception 用户集群，则必须先将管理员集群节点内存从 16 GB 调整为 90 GB。
GKE Hub
默认情况下，您最多可以为每个舰队注册 250 个具有全局成员资格的集群。如需在 GKE Hub 中注册更多集群，您可以在 Google Cloud 控制台中提交增加配额的申请：
如需详细了解基于成员资格设置的集群配额，请参阅分配配额。
在用户集群中运行多个节点和 pod
准备在用户集群中运行多个节点和 pod 时，请在创建用户集群时执行以下步骤。
用户集群中的 Pod CIDR 地址块
Pod CIDR 地址块是用户集群中所有 pod 的 CIDR 地址块。它通过 user-cluster.yaml 中的 network.podCIDR 字段进行配置。
在此范围内，系统会为每个节点分配一个较小的 /24 地址块。如果您需要一个 N 节点集群，则必须确保此地址块足够大，能够支持 N 个 /24 地址块。
下表介绍了不同 pod CIDR 地址块大小支持的节点数上限：
| pod CIDR 地址块大小 | 支持的节点数上限 |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
默认的 pod CIDR 地址块为 192.168.0.0/16，支持 256 个节点。例如，如需创建包含 500 个节点的集群，您必须更改用户集群中的 Pod CIDR 地址块以使用 /15 范围。
用户集群中的服务 CIDR 地址块
Service CIDR 地址块是用户集群中所有 Service 的 CIDR 地址块。它通过 user-cluster.yaml 中的 network.serviceCIDR 字段进行配置。
下表介绍了不同 Service CIDR 地址块大小支持的最大 Service 数量：
| Service CIDR 地址块大小 | 支持的 Service 数量上限 |
|---|---|
| /21 | 2048 |
| /20 | 4096 |
| /19 | 8192 |
| /18 | 16384 |
用户集群控制平面节点
用户集群控制平面组件的内存用量会根据用户集群中的节点数而扩缩。
下表根据用户集群的大小，提供用户集群控制平面节点所需的 CPU 和内存：
| 用户集群节点数 | 控制平面节点 CPU | 控制平面节点内存 |
|---|---|---|
| 0 至 20 | 3 个 CPU | 5 GB |
| 21 至 75 | 3 个 CPU | 6GB |
| 76 至 250 | 4 个 CPU | 8 GB |
| 251 至 500 | 4 个 CPU | 16 GB |
例如，要在一个用户集群中创建 250 个以上的节点，必须使用内存至少 16GB 的用户集群控制平面节点。
您可以通过 user-cluster.yaml 中的 masterNode 字段更改用户集群控制平面节点规范。
Dataplane v2
对于使用数据平面 V2 的 500 个节点用户集群，我们建议为用户集群控制平面节点使用 120 GB 的内存和 32 个 CPU 核心。
Cloud Logging 和 Cloud Monitoring
Cloud Logging 和 Cloud Monitoring 可帮助您跟踪资源。
在用户集群中部署的集群内代理的 CPU 和内存用量会根据用户集群中的节点数和 Pod 数量进行扩缩。
prometheus-server 和 stackdriver-prometheus-sidecar 等 Cloud Logging 和 Cloud Monitoring 组件根据节点数量和 pod 数量具有不同的 CPU 和内存资源用量。在扩容集群之前，请根据这些组件的预估平均用量设置资源请求和限制。下表显示了每个组件的平均用量的估算值：
| 节点数 | 容器名称 | 估计 CPU 利用率 | 估计内存用量 | ||
|---|---|---|---|---|---|
| 0 个 pod/节点 | 30 个 pod/节点 | 0 个 pod/节点 | 30 个 pod/节点 | ||
| 3 至 50 | prometheus-server | 100m | 390m | 650M | 1.3G |
| stackdriver-prometheus-sidecar | 100m | 340m | 1.5G | 1.6G | |
| 51 至 100 | prometheus-server | 160m | 500m | 1.8G | 5.5G |
| stackdriver-prometheus-sidecar | 200m | 500m | 1.9G | 5.7G | |
| 101 至 250 | prometheus-server | 400m | 2500m | 6.5G | 16G |
| stackdriver-prometheus-sidecar | 400m | 1300m | 7.5G | 12G | |
| 250 至 500 | prometheus-server | 1200m | 2600m | 22G | 25G |
| stackdriver-prometheus-sidecar | 400m | 2250m | 65G | 78G | |
请确保您有足够的节点来安排 Cloud Logging 和 Cloud Monitoring 组件。一种方法是先创建小型集群，根据上表修改 Cloud Logging 和 Cloud Monitoring 组件资源，创建节点池以适应组件，然后将集群逐步纵向扩容到更大的大小。
您可以选择保持将足够大的节点池用于 Logging 和 Monitoring 组件，以防止将其他 pod 安排到节点池中。为此，您必须将以下污点添加到节点池中：
taints:
- effect: NoSchedule
key: node-role.gke.io/observability这样可以防止在节点池上调度其他组件，并阻止用户因为监控组件的资源消耗而被逐出。
负载均衡器
在本部分中讨论的 Service 是指类型为 LoadBalancer 的 Kubernetes Service。
集群中的节点数量以及可以在负载均衡器上配置的 Service 数量有限制。
对于捆绑式负载均衡 (Seesaw)，健康检查数量也有限制。健康检查数量取决于节点数和本地流量 Service 数。本地流量 Service 是 externalTrafficPolicy 设置为 Local 的 Service。
下表介绍了捆绑式负载均衡 (Seesaw) 和集成负载均衡 (F5) 的 Service、节点和健康检查数上限：
| 捆绑式负载均衡 (Seesaw) | 集成负载均衡 (F5) | |
|---|---|---|
| Service 数上限 | 500 | 250 2 |
| 节点数上限 | 500 | 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/内存和许可等因素的影响。
自动扩缩系统组件
Google Distributed Cloud 会根据节点数在用户集群内自动扩缩系统组件，而不需要对配置进行任何更改。您可以使用本部分中的信息来规划资源。
Google Distributed Cloud 通过使用 addon-resizer 来扩缩以下系统组件的 CPU 和内存请求/限制来自动执行垂直扩缩：
kube-state-metrics 是在集群工作器节点上运行的 Deployment，用于侦听 Kubernetes API 服务器并生成有关对象状态的指标。CPU 和内存请求和限制基于节点数进行扩缩。
下表说明了系统根据集群中的节点数设置的资源请求/限制：
节点数 近似1 CPU 请求/限制 (milli) 近似1 内存请求/限制 (Mi) 3 至 5 105 110 6 至 500 100 + num_nodes 100 + (2 * num_nodes) 1 在扩缩过程中，有 +-5% 的余地减少组件重启次数。
例如，在含有 50 个节点的集群中，CPU 请求/限制设置为 150m/150m，内存请求/限制设置为 200Mi/200Mi。在含有 250 个节点的集群中，CPU 请求/限制设置为 350m/350m，内存请求/限制设置为 600Mi。
metrics-server 是在 Kubernetes 内置自动扩缩流水线所使用的集群工作器节点上运行的 Deployment。 CPU 和内存请求和限制基于节点数进行扩缩。
Google Distributed Cloud 会通过扩缩以下系统组件的副本数量，在管理员集群和用户集群中执行横向扩缩：
core-dns 是用于发现服务的 DNS 解决方案。它在用户集群工作器节点上作为 Deployment 运行。Google Distributed Cloud 会根据集群中的节点数和 CPU 核心数自动扩缩副本的数量。每增加/删除 16 个节点或 256 个核心，系统就会增加/减少 1 个副本。如果您有一个集群具有
N个节点和C个核心，则可能会有max(N/16, C/256)个副本。calico-typha 是一个支持 Pod 网络的组件。它在用户集群工作器节点上作为 Deployment 运行。Google Distributed Cloud 集群根据集群中的节点数自动扩缩 calico-typha 副本的数量：
节点数 (N) calico-typha 副本数量 N = 1 1 1 < N < 200 2 N >= 200 3 个或更多 Istio Ingress-gateway 是支持集群 Ingress 的组件，它在用户集群工作器节点上作为 Deployment 运行。Google Distributed Cloud 使用 Pod 横向自动扩缩器来根据副本的 CPU 利用率扩缩副本数量，最少 2 个副本，最多 5 个副本。
konnectability 网络代理 (KNP) 为来自用户集群控制平面节点的出站流量提供 TCP 级代理。它会将流量定向到用户集群节点的用户 kube-apiserver 出站流量。Konnectability 代理作为 Deployment 在用户集群工作器节点上运行。Google Distributed Cloud 根据集群中的节点数自动扩缩 calico-typha 副本的数量。
节点数 (N) 响应代理代理副本数 1 <= N <= 6 N 6 < N < 10 6 10 <= N < 100 8 N >= 100 12 个或更多
最佳做法
本部分介绍扩缩资源的最佳做法。
分阶段扩缩集群
创建 Kubernetes 节点的操作包括将节点操作系统映像模板克隆到新的磁盘文件中，此操作是 I/O 密集型 vSphere 操作。克隆操作和工作负载 I/O 操作之间没有 I/O 隔离。如果同时创建的节点太多，则克隆操作将需要很长时间才能完成，并且可能会影响集群和现有工作负载的性能和稳定性。
确保根据 vSphere 资源分阶段扩缩集群。例如，如要将集群大小从 3 个节点调整到 500 个节点，请考虑分阶段进行：先将集群扩展到 150 个节点、接着扩展到 350 个节点，然后再扩展到 500 个节点。这有助于减少 vSphere 基础架构上的负载。
优化 etcd 磁盘 I/O 性能
etcd 是用作所有集群数据的 Kubernetes 后备存储的键值对存储。它的性能和稳定性对集群的运行状况至关重要，并且它对磁盘和网络 I/O 延迟时间敏感。
按照以下建议优化用于控制层面虚拟机的 vSphere 数据存储区的 I/O 性能：
- 请遵循 etcd 硬件要求。
- 使用 SSD 或全部使用闪存。
几百毫秒的延迟会引起磁盘或网络 I/O 的瓶颈，还可能导致集群运行状况不佳。监控以下 etcd I/O 延迟时间指标并设置提醒阈值：
etcd_disk_backend_commit_duration_secondsetcd_disk_wal_fsync_duration_seconds
优化节点启动磁盘 I/O 性能
pod 将临时存储空间用于内部操作，例如保存临时文件。临时存储空间由容器的可写入层、日志目录和 emptyDir 卷使用。临时存储空间来自节点的文件系统，由节点的启动磁盘提供支持。
由于 Kubernetes 节点上没有存储空间 I/O 隔离，因此在其临时存储空间上使用高度高 I/O 的应用，可能导致通过加注星标的系统组件（如 Kubelet 和 Docker 守护程序）导致节点不稳定资源。
确保预配启动磁盘的数据存储区的 I/O 性能特征可为应用使用临时存储空间和日志记录流量提供合适的性能。
监控物理资源争用
请注意 vCPU 与 pCPU 比率和内存过度使用。物理主机上比率不佳或内存争用可能导致虚拟机性能下降。您应在主机层级监控物理资源利用率，并分配足够的资源来运行大型集群。