GSP768

概览

Google Kubernetes Engine 提供了横向和纵向两种解决方案来帮助您自动扩缩 Pod 和基础设施。这些工具非常有用，可确保您的工作负载尽可能高效运行，并且您只需要为使用的资源付费，从而帮助您优化费用。

在本实验中，您将设置 Pod 横向自动扩缩和 Pod 纵向自动扩缩以执行 Pod 级扩缩，同时设置集群自动扩缩器（横向基础设施解决方案）和节点自动预配（纵向基础设施解决方案），以执行节点级扩缩，并且观察这些扩缩是如何运作的。首先，您需要使用这些自动扩缩工具尽可能地节省更多资源，并在需求较低的时段缩减集群。然后增大集群的需求，并观察系统如何通过自动扩缩来保持正常运转。

目标

在本实验中，您将学习如何完成以下任务：

• 使用 Pod 横向自动扩缩器减少 Deployment 副本数量
• 使用 Pod 纵向自动扩缩器减少 Deployment 的 CPU 请求量
• 使用集群自动扩缩器减少集群中使用的节点数量
• 使用节点自动预配，自动为工作负载创建经优化的节点池
• 测试需求高峰时的自动扩缩行为
• 通过暂停 Pod 超额预配集群

设置和要求

点击“开始实验”按钮前的注意事项

请阅读以下说明。实验是计时的，并且您无法暂停实验。计时器在您点击开始实验后即开始计时，显示 Google Cloud 资源可供您使用多长时间。

此实操实验可让您在真实的云环境中开展实验活动，免受模拟或演示环境的局限。我们会为您提供新的临时凭据，让您可以在实验规定的时间内用来登录和访问 Google Cloud。

为完成此实验，您需要：

• 能够使用标准的互联网浏览器（建议使用 Chrome 浏览器）。

注意：请使用无痕模式或无痕浏览器窗口运行此实验。这可以避免您的个人账号与学生账号之间发生冲突，这种冲突可能导致您的个人账号产生额外费用。

• 完成实验的时间 - 请注意，实验开始后无法暂停。

注意：如果您已有自己的个人 Google Cloud 账号或项目，请不要在此实验中使用，以避免您的账号产生额外的费用。

如何开始实验并登录 Google Cloud 控制台

1. 点击开始实验按钮。如果该实验需要付费，系统会打开一个弹出式窗口供您选择付款方式。左侧是实验详细信息面板，其中包含以下各项：

   • 打开 Google Cloud 控制台按钮
   • 剩余时间
   • 进行该实验时必须使用的临时凭据
   • 帮助您逐步完成本实验所需的其他信息（如果需要）

2. 点击打开 Google Cloud 控制台（如果您使用的是 Chrome 浏览器，请右键点击并选择在无痕式窗口中打开链接）。

   该实验会启动资源并打开另一个标签页，显示登录页面。

   提示：请将这些标签页安排在不同的窗口中，并将它们并排显示。

   注意：如果您看见选择账号对话框，请点击使用其他账号。

3. 如有必要，请复制下方的用户名，然后将其粘贴到登录对话框中。

   {{{user_0.username | "<用户名>"}}}

   您也可以在实验详细信息面板中找到用户名。

4. 点击下一步。

5. 复制下面的密码，然后将其粘贴到欢迎对话框中。

   {{{user_0.password | "<密码>"}}}

   您也可以在实验详细信息面板中找到密码。

6. 点击下一步。

   重要提示：您必须使用实验提供的凭据。请勿使用您的 Google Cloud 账号凭据。 注意：在本次实验中使用您自己的 Google Cloud 账号可能会产生额外费用。

7. 继续在后续页面中点击以完成相应操作：

   • 接受条款及条件。
   • 由于该账号为临时账号，请勿添加账号恢复选项或双重验证。
   • 请勿注册免费试用。

片刻之后，系统会在此标签页中打开 Google Cloud 控制台。

注意：如需查看列有 Google Cloud 产品和服务的菜单，请点击左上角的导航菜单。

激活 Cloud Shell

Cloud Shell 是一种装有开发者工具的虚拟机。它提供了一个永久性的 5GB 主目录，并且在 Google Cloud 上运行。Cloud Shell 提供可用于访问您的 Google Cloud 资源的命令行工具。

1. 点击 Google Cloud 控制台顶部的激活 Cloud Shell 。

如果您连接成功，即表示您已通过身份验证，且当前项目会被设为您的 PROJECT_ID 环境变量所指的项目。输出内容中有一行说明了此会话的 PROJECT_ID：

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud 是 Google Cloud 的命令行工具。它已预先安装在 Cloud Shell 上，且支持 Tab 自动补全功能。

2. （可选）您可以通过此命令列出活跃账号名称：

gcloud auth list

3. 点击授权。

4. 现在，输出的内容应如下所示：

输出：

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （可选）您可以通过此命令列出项目 ID：

gcloud config list project

输出：

[core] project = <project_ID>

输出示例：

[core] project = qwiklabs-gcp-44776a13dea667a6 Note: For full documentation of gcloud, in Google Cloud, refer to the gcloud CLI overview guide.

预配测试环境

1. 将默认可用区设置为 ：

gcloud config set compute/zone {{{project_0.default_zone | zone}}}

2. 运行以下命令，在 可用区中创建一个包含三个节点的集群：

gcloud container clusters create scaling-demo --num-nodes=3 --enable-vertical-pod-autoscaling

为便于展示 Pod 横向自动扩缩，本实验使用基于 php-apache 映像的自定义 Docker 映像。另外还定义了 index.php 页面，以执行一些 CPU 密集型计算。您将监控此映像的 Deployment。

3. 为 php-apache Deployment 创建清单：

cat << EOF > php-apache.yaml apiVersion: apps/v1 kind: Deployment metadata: name: php-apache spec: selector: matchLabels: run: php-apache replicas: 3 template: metadata: labels: run: php-apache spec: containers: - name: php-apache image: k8s.gcr.io/hpa-example ports: - containerPort: 80 resources: limits: cpu: 500m requests: cpu: 200m --- apiVersion: v1 kind: Service metadata: name: php-apache labels: run: php-apache spec: ports: - port: 80 selector: run: php-apache EOF

4. 将新创建的清单应用到集群：

kubectl apply -f php-apache.yaml

点击检查我的进度，验证您是否完成了上述任务。 预配测试环境

任务 1. 使用 Pod 横向自动扩缩对 Pod 进行扩缩

Pod 横向自动扩缩根据工作负载的 CPU 或内存消耗情况，或者根据 Kubernetes 报告的自定义指标或来自集群外部来源的外部指标，来自动增加或减少 Pod 的数量，从而改变 Kubernetes 工作负载的状况。

1. 在 Cloud Shell 中，运行以下命令以检查集群的 Deployment：

kubectl get deployment

您应该会看到 php-apache Deployment，其中有 3 个（共 3 个）在运行中：

NAME READY UP-TO-DATE AVAILABLE AGE php-apache 3/3 3 3 91s 注意：若您没有看到 3 个可用的 Pod，请稍等片刻，以便系统创建 Pod，然后重试上述命令。如果您看到只有 1 个（共 1 个）Pod 可用，很可能是已经过了足够的时间，您的 Deployment 缩容了。

2. 对 php-apache Deployment 应用横向自动扩缩：

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

点击检查我的进度，验证您是否完成了上述任务。 使用 Pod 横向自动扩缩对 Pod 进行扩缩

此 autoscale 命令可配置 Pod 横向自动扩缩器，使 php-apache Deployment 控制的 Pod 副本数保持在 1 到 10 个之间。cpu-percent 标志将所有 Pod 所请求的 CPU 的目标平均 CPU 利用率指定为 50%。HPA 将通过 Deployment 调整副本数量，以使所有 Pod 的平均 CPU 利用率保持在 50%。

3. 查看 Pod 横向自动扩缩器的当前状态：

kubectl get hpa

在 Targets 列下，您应该会看到 1%/50%。

这表示在您的 Deployment 中，所有 Pod 目前的目标平均 CPU 利用率为 1%。由于 php-apache 应用目前尚未接收任何流量，此利用率是正常的。

注意：若您看到 <unknown>/50%，请稍等片刻，然后再次运行 kubectl get hpa 命令。您的 HPA 可能尚未创建评估。

另外，请留意 Replicas（副本）列。在开始时，此列的值为 3。随着所需要的 Pod 数量变化，自动扩缩器将会更改此数值。

在本例中，自动扩缩器会将 Deployment 缩减至您在运行 autoscale 命令时指定的 Pod 数量下限。Pod 横向自动扩缩需要 5-10 分钟的时间才能完成，且可能会随着扩缩方式的不同而要求您关停或启动新 Pod。

继续执行本实验的下一步。您可以稍后检查自动扩缩器的运行结果。

注意：在本实验中，当您使用 cpu-percent 作为自动扩缩器的目标指标时，HPA 将允许您自定义一些指标，以便您可以根据日志中所捕获的其他有用指标来扩缩 Pod。

任务 2. 使用 Pod 纵向自动扩缩对 Pod 大小进行扩缩

使用 Pod 纵向自动扩缩时，您无需考虑为容器的 CPU 和内存请求指定哪些值。自动扩缩器可以为 CPU 和内存请求及限制提供建议值，也可以自动更新这些值。

注意：不能同时对 CPU 或内存使用 Pod 纵向自动扩缩和 Pod 横向自动扩缩。因为这两种自动扩缩器会对相同指标的需求变化做出响应，从而引发冲突。不过，在对 CPU 或内存执行 VPA 的同时可以对自定义指标使用 HPA，以免发生重叠。

scaling-demo 集群上已启用 Pod 纵向自动扩缩。

1. 如需对此进行验证，请运行以下命令：

gcloud container clusters describe scaling-demo | grep ^verticalPodAutoscaling -A 1

输出应显示为 enabled: true

注意：如需在现有集群上启用 Pod 纵向自动扩缩，请运行以下命令：gcloud container clusters update scaling-demo --enable-vertical-pod-autoscaling

为展示 VPA 是如何运作的，您将部署 hello-server 应用。

2. 将 hello-server Deployment 应用到您的集群：

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

3. 确保已成功创建该 Deployment：

kubectl get deployment hello-server

4. 为该 Deployment 分配 450m 的 CPU 资源请求量：

kubectl set resources deployment hello-server --requests=cpu=450m

5. 接下来，运行以下命令来检查 hello-server Pod 的容器具体情况：

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

• 在输出中，找到 Requests（请求）部分。请注意，此 Pod 目前正在申请您分配的 450m 的 CPU 资源。

6. 现在，为您的 Pod 纵向自动扩缩器创建清单：

cat << EOF > hello-vpa.yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hello-server-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: hello-server updatePolicy: updateMode: "Off" EOF

上述命令将为针对 hello-server Deployment 的 Pod 纵向自动扩缩器生成清单，并将 Update Policy 设为 Off。VPA 可根据您的应用采用以下三种不同的更新政策之一，这一点很有用：

• Off（关）：此政策表示 VPA 将根据历史数据生成建议，您可以手动应用这些建议。
• Initial（初始）：根据 VPA 建议创建新 Pod 后，即无法更改 Pod 大小。
• Auto（自动）：时常删除和重新创建 Pod，以与建议的大小保持一致。

7. 将清单应用于 hello-vpa：

kubectl apply -f hello-vpa.yaml

8. 稍等片刻，然后查看 VerticalPodAutoscaler：

kubectl describe vpa hello-server-vpa

在输出末尾找到“Container Recommendations”（容器建议）部分。如果未找到，请再多等片刻，然后重试上述命令。在找到该部分后，您会看到几种不同类型的建议，每种建议都具有相应的 CPU 值和内存值：

• Lower Bound（下限）：这是可触发 VPA 来调整 Pod 大小的数量下限。当您的 Pod 利用率低于此值时，VPA 将删除 Pod 并对其进行缩减。
• Target（目标值）：这是 VPA 调整 Pod 大小时所用的值。
• Uncapped Target（不设限目标值）：当没有为 VPA 指定容量下限或上限时，则此值将为 VPA 使用的目标利用率。
• Upper Bound（上限）：这是可触发 VPA 来调整 Pod 大小的数量上限。当您的 Pod 利用率高于此值时，VPA 将删除 Pod 并对其进行扩容。

您会发现，VPA 建议将此容器的 CPU 请求量设置为 25m，而非之前的 100m，还会为您提供建议的内存请求量。此时，您可以手动将这些建议应用到 hello-server Deployment。

注意：Pod 纵向自动扩缩将基于来自容器的历史数据来提供建议。在实践中，建议至少等 24 小时来收集建议数据，然后再应用任何更改。

9. 为了观察 VPA 及其在本实验中发挥的效果，您需要将 hello-vpa 更新政策改为 Auto，并观察其扩缩情况。

10. 更新清单以将该政策设置为 Auto，然后应用该配置：

sed -i 's/Off/Auto/g' hello-vpa.yaml kubectl apply -f hello-vpa.yaml

为了调整 Pod 大小，Pod 纵向自动扩缩器需要先删除该 Pod，然后重新创建一个大小不同的新 Pod。默认情况下，为避免造成停机，VPA 不会删除最后一个活跃 Pod，也不会调整其大小。因此，您需要至少具有 2 个副本，VPA 才会进行任何更改。

11. 将 hello-server Deployment 扩展至 2 个副本：

kubectl scale deployment hello-server --replicas=2

12. 现在，查看您的 Pod：

kubectl get pods -w

13. 等到您看到 hello-server-xxx Pod 处于 terminating 或 pending 状态（或者，前往 Kubernetes Engine > 工作负载）：

这表示 VPA 正在删除您的 Pod 并调整其大小。在看到此信息时，按 Ctrl + c 退出命令。

点击检查我的进度，验证您是否完成了上述任务。 使用 Pod 纵向自动扩缩对 Pod 大小进行扩缩

任务 3. HPA 结果

至此，Pod 横向自动扩缩器很可能已经对您的 php-apache Deployment 进行了缩容。

1. 运行以下命令来查看您的 HPA：

kubectl get hpa

• 查看 Replicas（副本）列。您会发现您的 php-apache Deployment 已缩减至 1 个 Pod。

注意：若您看到 php-apache Deployment 仍有 3 个副本，请多等几分钟，以便自动扩缩器完成相应的操作。

• HPA 会充分利用应用将即刻停止运行这一事实，移除所有未使用的资源。而且，如果 php-apache 应用收到更多需求，它将会重新扩容以满足负载需求。

注意：如果您十分关注应用的可用性，则最佳做法是给 Pod 数量下限多留出一些缓冲空间，以便 Pod 横向自动扩缩器有足够的时间进行扩缩。

这对于优化费用大有帮助。使用经调优的自动扩缩器，不但可以让应用保持高可用性，还可以让您只需为维持应用正常运行所必需的资源付费（不论需求如何）。

任务 4. VPA 结果

现在，VPA 应该已经调整了 hello-server Deployment 中的 Pod 大小。

1. 检查您的 Pod：

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

2. 找到 Requests:（请求量）字段。

• 您的 Pod 纵向自动扩缩器将使用其目标利用率重新创建 Pod。现在，它应该会申请少一些的 CPU 以及一定数量的内存：

Requests: cpu: 25m memory: 262144k 注意：若您发现任一 Pod 的 CPU 请求量仍然是 450m，请输入以下命令以手动将您的 CPU 资源设置为目标值：kubectl set resources deployment hello-server --requests=cpu=25m 。当 VPA 处于 Auto 模式时，有时可能会没有足够的时间收集准确数据，因而导致运行较长的时间或设置的上限值或下限值不准确。在本实验中，为了不浪费时间，一个简单的解决办法是使用它在“Off”模式下提供的建议。

这种情况下，VPA 将成为一款非常优秀的资源利用率优化工具，还可以帮助您节省费用。初始 CPU 请求量 400m 高于此容器的需求量。您可以将此请求量调整为建议的 25m，从而通过节点池使用较少的 CPU，并可能会因此减少在集群中预配的节点数量。

将更新政策设置为 Auto 时，VPA 将在其整个运行期间内继续删除 hello-server Deployment 的 Pod 并调整其大小。它可能会将 Pod 扩容至更大的请求量，以应对流量较大的情形，然后在停机期间重新缩容。这在应用收到稳步增长的需求时非常有用，但在需求激增的高峰期可能会有应用无法正常运行的风险。

根据应用的情形，通常最安全的做法是在将更新政策设置为 Off 的情况下使用 VPA，并根据需要采纳相关的建议，以优化资源利用率并尽可能地提升集群的可用性。

在接下来的部分中，您将了解如何使用集群自动扩缩器和节点自动预配功能，以进一步优化您的资源利用率。

任务 5. 集群自动扩缩器

集群自动扩缩器可用于根据需求添加或移除节点。当需求较高时，集群自动扩缩器将会向节点池中添加节点，以满足该需求。当需求较低时，集群自动扩缩器将会移除节点，以对集群进行缩容。这种方式可确保集群保持高可用性，同时最大限度降低与额外机器相关的多余费用。

1. 为集群启用自动扩缩：

gcloud beta container clusters update scaling-demo --enable-autoscaling --min-nodes 1 --max-nodes 5

这需要几分钟才能完成。

对集群进行扩缩时，需要在优化资源利用率与提高资源可用性之间进行权衡取舍，以决定何时移除节点。移除使用率过低的节点可以提高集群利用率，但新的工作负载可能需要等待重新预配资源才能运行。

您可以指定在做出此类决定时使用哪种自动扩缩配置文件。目前可用的配置文件包括：

• Balanced：默认配置文件。
• Optimize-utilization：优先优化利用率，而非在集群中保留空闲资源。选择此配置文件后，集群自动扩缩器会更主动地缩减集群。它可以移除更多节点，并更快地移除节点。此配置文件经过优化，适用于对启动延迟时间不敏感的批量工作负载。

2. 切换至 optimize-utilization 自动扩缩配置文件，以便观察扩缩的完整效果：

gcloud beta container clusters update scaling-demo \ --autoscaling-profile optimize-utilization

3. 启用自动扩缩后，在 Cloud 控制台中观察您的集群。点击左上角的三条横线，打开导航菜单。

4. 在导航菜单中，依次选择 Kubernetes Engine > 集群。

5. 在集群页面上，选择 scaling-demo 集群。

6. 在 scaling-demo 的集群页面上，选择节点标签页。

7. 查看三个节点的资源利用率的概览。

注意：您的具体数值可能与图中的值有所不同，因为 Kubernetes 并不是每次都使用相同的方式来预配和分配资源。

如果您将 3 个节点请求的 CPU 值和可分配的 CPU 值分别相加，总值将分别为 1555m 和 2820m。也就是说，整个集群总计有 1265m 的可用 CPU 资源。此值高于单个节点提供的资源大小。

为优化资源利用率，可以将满足当前需求的当前工作负载合并到两个节点中（而非三个节点）。不过，您的集群还没有自动缩减。这是因为集群中分布着系统 Pod。

您的集群在 kube-system 命名空间下运行了多个 Deployment，因此可提供日志记录、监控和自动扩缩等不同的 GKE 服务。

8. 如需对此进行验证，请在 Cloud Shell 中运行以下命令：

kubectl get deployment -n kube-system

默认情况下，这些 Deployment 中的大多数系统 Pod 都会阻止集群自动扩缩器，不让自动扩缩器为了重新进行安排而使它们完全离线运行。通常情况下需要这样做，因为其中的许多 Pod 用于收集其他部署和服务中使用的数据。例如，metrics-agent 暂时出现故障会导致为 VPA 和 HPA 收集的数据出现缺口，或者 fluentd Pod 出现故障会导致 Cloud 日志出现缺口。

在本实验中，您可以对您的 kube-system Pod 应用 Pod 中断预算，以便集群自动扩缩器可以将这些 Pod 安全地重新安排到另一个节点上。这样即可提供足够的空间来缩减集群。

Pod 中断预算 (PDB) 定义了 Kubernetes 对升级、Pod 移除和资源耗尽等中断情形的处理方法。在 PDB 中，您可以指定每个 Deployment 应包含的 Pod 数量上限 max-unavailable 和/或 Pod 数量下限 min-available。

9. 运行以下命令，为您的每个 kube-system Pod 创建 Pod 中断预算：

kubectl create poddisruptionbudget kube-dns-pdb --namespace=kube-system --selector k8s-app=kube-dns --max-unavailable 1 kubectl create poddisruptionbudget prometheus-pdb --namespace=kube-system --selector k8s-app=prometheus-to-sd --max-unavailable 1 kubectl create poddisruptionbudget kube-proxy-pdb --namespace=kube-system --selector component=kube-proxy --max-unavailable 1 kubectl create poddisruptionbudget metrics-agent-pdb --namespace=kube-system --selector k8s-app=gke-metrics-agent --max-unavailable 1 kubectl create poddisruptionbudget metrics-server-pdb --namespace=kube-system --selector k8s-app=metrics-server --max-unavailable 1 kubectl create poddisruptionbudget fluentd-pdb --namespace=kube-system --selector k8s-app=fluentd-gke --max-unavailable 1 kubectl create poddisruptionbudget backend-pdb --namespace=kube-system --selector k8s-app=glbc --max-unavailable 1 kubectl create poddisruptionbudget kube-dns-autoscaler-pdb --namespace=kube-system --selector k8s-app=kube-dns-autoscaler --max-unavailable 1 kubectl create poddisruptionbudget stackdriver-pdb --namespace=kube-system --selector app=stackdriver-metadata-agent --max-unavailable 1 kubectl create poddisruptionbudget event-pdb --namespace=kube-system --selector k8s-app=event-exporter --max-unavailable 1

点击检查我的进度，验证您是否完成了上述任务。 集群自动扩缩器

在这些命令中，您将根据在创建 Deployment 时定义的标签选择不同的 kube-system Deployment Pod，并指定每个 Deployment 可以有 1 个不可用的 Pod。这将允许自动扩缩器重新安排系统 Pod。

应用 PDB 后，集群应该在一两分钟内由三个节点缩减至两个节点。

10. 在 Cloud Shell 中重新运行以下命令，直至您看到集群中总计只有两个节点：

kubectl get nodes

在 Cloud 控制台中，刷新 scaling-demo 的节点标签页，检查您的资源是如何打包的：

您设置了自动化，使集群从三个节点缩减为两个节点！

从费用角度讲，由于缩减了节点池，在集群需求较低的时间段，您将需要付费的机器数量也更少。如果您在一天之中在高需求时间段和低需求时间段之间波动，这种扩缩可能会更为剧烈。

需要注意的是，尽管集群自动扩缩器移除了不必要的节点，但 Pod 纵向自动扩缩和 Pod 横向自动扩缩还是对降低足够的 CPU 需求起到了很大的帮助作用，因此不再需要该节点。将这些工具结合使用可以非常好地优化总体费用和资源利用率。

所以，在需要安排 Pod 时，集群自动扩缩器可以帮助添加和移除节点。然而，GKE 还专门提供了另一个用于纵向扩缩的功能，称为节点自动预配。

任务 6. 节点自动预配

节点自动预配 (NAP) 实际上是通过添加新节点来调整节点池的大小，从而满足需求。如果不启用节点自动预配功能，集群自动扩缩器将仅在您指定的节点池内创建新节点。也就是说，新节点的机器类型与该池内的其他节点相同。这尤其适合优化批量工作负载以及其他不需要过度扩缩的应用的资源利用率，因为相比只在现有池内添加一些节点，创建一个专门针对您的使用情形进行优化的节点池可能需要花费更多的时间。

• 启用节点自动预配：

gcloud container clusters update scaling-demo \ --enable-autoprovisioning \ --min-cpu 1 \ --min-memory 2 \ --max-cpu 45 \ --max-memory 160

在此命令中，您指定了 CPU 资源和内存资源的数量下限和数量上限。此设置适用于整个集群。

NAP 可能会花费一些时间，而且它很可能不会为当前状态下的 scaling-demo 集群创建新节点池。

在接下来的部分中，您将增大对集群的需求，并观察自动扩缩器以及 NAP 的行为。

点击检查我的进度，验证您是否完成了上述任务。 节点自动预配

任务 7. 使用更大的需求进行测试

至此，您已经分析了在对应用的需求较低时，HPA、VPA 以及集群自动扩缩器是如何帮助您节省资源和费用的。现在，您将了解在需求增加的情况下，这些工具将如何处理可用性问题。

1. 按 + 图标，在 Cloud Shell 中打开一个新标签页：

2. 在新标签页中运行以下命令，以向 php-apache 服务发送一个无限查询循环：

kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

3. 返回原来的 Cloud Shell 标签页。

4. 执行以下命令，在一分钟左右的时间内，您应该会看到 CPU 负载增大：

kubectl get hpa

等待并重新运行此命令，直至您看到目标值高于 100%。

5. 现在，定期运行以下命令，监控您的集群如何应对负载增大的情况：

kubectl get deployment php-apache

您还可以在 Cloud 控制台中刷新节点标签页，以此来监控您的集群。

几分钟后，您将会发现以下几点。

• 首先，为应对负载增大的情况，HPA 自动对您的 php-apache Deployment 进行扩容。
• 之后，集群自动扩缩器需要预配新的节点，以满足增加的需求。
• 最后，节点自动预配将根据集群工作负载的 CPU 请求量和内存请求量，创建一个经优化的节点池。在本例中，负载测试只提高了 CPU 限制，因此这应该是一个高 CPU、低内存的节点池。

等到您的 php-apache Deployment 扩展到 7 个副本，并且您的“节点”标签页如下所示：

6. 返回您运行负载测试时所在的 Cloud Shell 标签页，并按 Ctrl + c 取消测试。现在，随着需求再次减小，您的集群最终也将重新缩减。

当需求增大时，您的集群也可以高效扩容来满足需求！但是，请注意处理这种需求高峰时所花费的时间。对于多数应用来说，预配新资源时无法正常运行也是一个问题。

任务 8. 优化以满足更大负载的需求

在扩容以满足更大负载的需求时，Pod 横向自动扩缩会添加新的 Pod，而 Pod 纵向自动扩缩将根据您的设置来调整 Pod 大小。如果现有节点上有空间，则它可能会跳过拉取映像的步骤，立即开始在新 Pod 上运行应用。若您使用的节点以前没有部署过您的应用，则在运行应用前需要下载容器映像，这可能会多花一些时间。

因此，如果您的现有节点上没有足够的空间，并且您使用了集群自动扩缩器，则可能需要更长的时间。现在，它需要预配新节点，对其进行设置，然后下载映像并启动 Pod。如果节点自动预配器将要创建一个新节点池，就像在集群中一样，则可能需要更长的时间，因为您需要先预配新节点池，然后对新节点完成所有相同的步骤。

注意：在实践中，务必要确保应用使用尽可能小的容器映像。较小的映像有助于缩短 Pod 的冷启动时间，因为在集群自动扩缩器为您的集群预配新节点时，映像越小，节点下载映像的速度就越快。此外，较大的映像可能会延长 Pod 的启动时间，导致在流量高峰期间预配新节点时的性能降低。

为了应对在自动扩缩时出现的这些延迟，您可能会希望进行一些超额预配，以减小在自动扩容时应用承受的压力。这对优化费用十分重要，因为您肯定不希望为多余的资源付费，也不希望应用性能受到影响。

您可以使用以下公式确定超额预配的数量：

我们以集群的 CPU 利用率为例。您不希望它达到 100%，所以您可以选择 15% 的缓冲空间，以保持安全的范围。之后，公式中的流量变量是指估计在接下来两到三分钟内的流量增长百分比。在前面运行的负载测试中，流量出现了极端增长，从 0% 增长到 150%，我们假设一个更为平均的流量增长水平 30%。

根据这些数字，您计算出的安全缓冲空间约为 65%。也就是说，为了应对扩容需求并尽可能地降低任何问题的影响，您可以将资源超额预配约 65%。

使用集群自动扩缩功能超额预配集群时，一个高效的策略是使用暂停 Pod。

暂停 Pod 是低优先级 Deployment，能够被高优先级的 Deployment 移除并取代。也就是说，您可以创建低优先级 Pod，但它们除了在集群中预留缓冲空间之外，实际上不执行任何操作。当高优先级 Pod 需要空间时，将移除暂停 Pod 并将其重新安排到另一个节点或新节点上，而高优先级 Pod 将具有所需要的空间来快速进行安排。

1. 为暂停 Pod 创建清单：

cat << EOF > pause-pod.yaml --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: overprovisioning value: -1 globalDefault: false description: "Priority class used by overprovisioning." --- apiVersion: apps/v1 kind: Deployment metadata: name: overprovisioning namespace: kube-system spec: replicas: 1 selector: matchLabels: run: overprovisioning template: metadata: labels: run: overprovisioning spec: priorityClassName: overprovisioning containers: - name: reserve-resources image: k8s.gcr.io/pause resources: requests: cpu: 1 memory: 4Gi EOF

2. 将清单应用于您的集群：

kubectl apply -f pause-pod.yaml

3. 现在稍等片刻，然后刷新 scaling-demo 集群的节点标签页。

观察如何创建新节点（很可能是在新节点池中），以适配您新创建的暂停 Pod。现在，若您再次运行负载测试，当您需要为 php-apache Deployment 增加一个额外的节点时，该 Deployment 可能会被安排在暂停 Pod 所在的节点上，而暂停 Pod 将被安排到新节点上。这是非常有用的，因为虚拟暂停 Pod 让您的集群可以提前预配新节点，以便实际应用可以更快地进行扩容。若您预计会有大量的流量，可以添加更多的暂停 Pod，但每个节点上添加的暂停 Pod 最好不要超过一个。

点击检查我的进度，验证您是否完成了上述任务。 优化以满足更大负载的需求

恭喜！

恭喜！在本实验中，您配置了集群，使其可以基于需求自动、高效地扩容或缩容。Pod 横向自动扩缩和 Pod 纵向自动扩缩可帮助您自动扩缩集群的部署，而集群自动扩缩器和节点自动预配功能可为您自动扩缩集群的基础设施。

与往常一样，使用哪种工具将取决于您的工作负载。谨慎使用这些自动扩缩器可以在您需要时充分提高可用性，并确保您在低需求的时间段仅为需要的资源付费。在费用方面，它们还可以帮助您优化资源利用率并节省费用。

后续步骤/了解详情

请查看以下资源，详细了解本实验中介绍的主题：

• 在 GKE 上运行费用经过优化的 Kubernetes 应用的最佳实践：微调 GKE 自动扩缩
• 集群自动扩缩器文档
• Pod 横向自动扩缩器文档
• Pod 纵向自动扩缩器文档

Google Cloud 培训和认证

…可帮助您充分利用 Google Cloud 技术。我们的课程会讲解各项技能与最佳实践，可帮助您迅速上手使用并继续学习更深入的知识。我们提供从基础到高级的全方位培训，并有点播、直播和虚拟三种方式选择，让您可以按照自己的日程安排学习时间。各项认证可以帮助您核实并证明您在 Google Cloud 技术方面的技能与专业知识。

上次更新手册的时间：2024 年 2 月 1 日

上次测试实验的时间：2023 年 9 月 20 日

版权所有 2025 Google LLC 保留所有权利。Google 和 Google 徽标是 Google LLC 的商标。其他所有公司名和产品名可能是其各自相关公司的商标。