
Before you begin
- Labs create a Google Cloud project and resources for a fixed time
- Labs have a time limit and no pause feature. If you end the lab, you'll have to restart from the beginning.
- On the top left of your screen, click Start lab to begin
Provision testing environment
/ 20
Scale pods with Horizontal Pod Autoscaling
/ 20
Scale size of pods with Vertical Pod Autoscaling
/ 20
Cluster autoscaler
/ 20
Node Auto Provisioning
/ 10
Optimize larger loads
/ 10
Google Kubernetes Engine 提供了横向和纵向两种解决方案来帮助您自动扩缩 Pod 和基础设施。这些工具非常有用,可确保您的工作负载尽可能高效运行,并且您只需要为使用的资源付费,从而帮助您优化费用。
在本实验中,您将设置 Pod 横向自动扩缩和 Pod 纵向自动扩缩以执行 Pod 级扩缩,同时设置集群自动扩缩器(横向基础设施解决方案)和节点自动预配(纵向基础设施解决方案),以执行节点级扩缩,并且观察这些扩缩是如何运作的。首先,您需要使用这些自动扩缩工具尽可能地节省更多资源,并在需求较低的时段缩减集群。然后增大集群的需求,并观察系统如何通过自动扩缩来保持正常运转。
在本实验中,您将学习如何完成以下任务:
请阅读以下说明。实验是计时的,并且您无法暂停实验。计时器在您点击开始实验后即开始计时,显示 Google Cloud 资源可供您使用多长时间。
此实操实验可让您在真实的云环境中开展实验活动,免受模拟或演示环境的局限。我们会为您提供新的临时凭据,让您可以在实验规定的时间内用来登录和访问 Google Cloud。
为完成此实验,您需要:
点击开始实验按钮。如果该实验需要付费,系统会打开一个弹出式窗口供您选择付款方式。左侧是实验详细信息面板,其中包含以下各项:
点击打开 Google Cloud 控制台(如果您使用的是 Chrome 浏览器,请右键点击并选择在无痕式窗口中打开链接)。
该实验会启动资源并打开另一个标签页,显示登录页面。
提示:请将这些标签页安排在不同的窗口中,并将它们并排显示。
如有必要,请复制下方的用户名,然后将其粘贴到登录对话框中。
您也可以在实验详细信息面板中找到用户名。
点击下一步。
复制下面的密码,然后将其粘贴到欢迎对话框中。
您也可以在实验详细信息面板中找到密码。
点击下一步。
继续在后续页面中点击以完成相应操作:
片刻之后,系统会在此标签页中打开 Google Cloud 控制台。
Cloud Shell 是一种装有开发者工具的虚拟机。它提供了一个永久性的 5GB 主目录,并且在 Google Cloud 上运行。Cloud Shell 提供可用于访问您的 Google Cloud 资源的命令行工具。
如果您连接成功,即表示您已通过身份验证,且当前项目会被设为您的 PROJECT_ID 环境变量所指的项目。输出内容中有一行说明了此会话的 PROJECT_ID:
gcloud
是 Google Cloud 的命令行工具。它已预先安装在 Cloud Shell 上,且支持 Tab 自动补全功能。
点击授权。
现在,输出的内容应如下所示:
输出:
输出:
输出示例:
gcloud
, in Google Cloud, refer to the gcloud CLI overview guide.
为便于展示 Pod 横向自动扩缩,本实验使用基于 php-apache
映像的自定义 Docker 映像。另外还定义了 index.php
页面,以执行一些 CPU 密集型计算。您将监控此映像的 Deployment。
php-apache
Deployment 创建清单:点击检查我的进度,验证您是否完成了上述任务。
Pod 横向自动扩缩根据工作负载的 CPU 或内存消耗情况,或者根据 Kubernetes 报告的自定义指标或来自集群外部来源的外部指标,来自动增加或减少 Pod 的数量,从而改变 Kubernetes 工作负载的状况。
您应该会看到 php-apache
Deployment,其中有 3 个(共 3 个)在运行中:
php-apache
Deployment 应用横向自动扩缩:点击检查我的进度,验证您是否完成了上述任务。
此 autoscale
命令可配置 Pod 横向自动扩缩器,使 php-apache
Deployment 控制的 Pod 副本数保持在 1 到 10 个之间。cpu-percent
标志将所有 Pod 所请求的 CPU 的目标平均 CPU 利用率指定为 50%。HPA 将通过 Deployment 调整副本数量,以使所有 Pod 的平均 CPU 利用率保持在 50%。
在 Targets 列下,您应该会看到 1%/50%。
这表示在您的 Deployment 中,所有 Pod 目前的目标平均 CPU 利用率为 1%。由于 php-apache
应用目前尚未接收任何流量,此利用率是正常的。
kubectl get hpa
命令。您的 HPA 可能尚未创建评估。另外,请留意 Replicas(副本)列。在开始时,此列的值为 3。随着所需要的 Pod 数量变化,自动扩缩器将会更改此数值。
在本例中,自动扩缩器会将 Deployment 缩减至您在运行 autoscale
命令时指定的 Pod 数量下限。Pod 横向自动扩缩需要 5-10 分钟的时间才能完成,且可能会随着扩缩方式的不同而要求您关停或启动新 Pod。
继续执行本实验的下一步。您可以稍后检查自动扩缩器的运行结果。
cpu-percent
作为自动扩缩器的目标指标时,HPA 将允许您自定义一些指标,以便您可以根据日志中所捕获的其他有用指标来扩缩 Pod。使用 Pod 纵向自动扩缩时,您无需考虑为容器的 CPU 和内存请求指定哪些值。自动扩缩器可以为 CPU 和内存请求及限制提供建议值,也可以自动更新这些值。
scaling-demo 集群上已启用 Pod 纵向自动扩缩。
输出应显示为 enabled: true
gcloud container clusters update scaling-demo --enable-vertical-pod-autoscaling
为展示 VPA 是如何运作的,您将部署 hello-server
应用。
hello-server
Deployment 应用到您的集群:hello-server
Pod 的容器具体情况:上述命令将为针对 hello-server
Deployment 的 Pod 纵向自动扩缩器生成清单,并将 Update Policy 设为 Off。VPA 可根据您的应用采用以下三种不同的更新政策之一,这一点很有用:
hello-vpa
:VerticalPodAutoscaler
:在输出末尾找到“Container Recommendations”(容器建议)部分。如果未找到,请再多等片刻,然后重试上述命令。在找到该部分后,您会看到几种不同类型的建议,每种建议都具有相应的 CPU 值和内存值:
您会发现,VPA 建议将此容器的 CPU 请求量设置为 25m,而非之前的 100m,还会为您提供建议的内存请求量。此时,您可以手动将这些建议应用到 hello-server
Deployment。
为了观察 VPA 及其在本实验中发挥的效果,您需要将 hello-vpa 更新政策改为 Auto,并观察其扩缩情况。
更新清单以将该政策设置为 Auto,然后应用该配置:
为了调整 Pod 大小,Pod 纵向自动扩缩器需要先删除该 Pod,然后重新创建一个大小不同的新 Pod。默认情况下,为避免造成停机,VPA 不会删除最后一个活跃 Pod,也不会调整其大小。因此,您需要至少具有 2 个副本,VPA 才会进行任何更改。
hello-server
Deployment 扩展至 2 个副本:hello-server-xxx
Pod 处于 terminating 或 pending 状态(或者,前往 Kubernetes Engine > 工作负载):这表示 VPA 正在删除您的 Pod 并调整其大小。在看到此信息时,按 Ctrl + c 退出命令。
点击检查我的进度,验证您是否完成了上述任务。
至此,Pod 横向自动扩缩器很可能已经对您的 php-apache
Deployment 进行了缩容。
php-apache
Deployment 已缩减至 1 个 Pod。php-apache
Deployment 仍有 3 个副本,请多等几分钟,以便自动扩缩器完成相应的操作。php-apache
应用收到更多需求,它将会重新扩容以满足负载需求。这对于优化费用大有帮助。使用经调优的自动扩缩器,不但可以让应用保持高可用性,还可以让您只需为维持应用正常运行所必需的资源付费(不论需求如何)。
现在,VPA 应该已经调整了 hello-server
Deployment 中的 Pod 大小。
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,并根据需要采纳相关的建议,以优化资源利用率并尽可能地提升集群的可用性。
在接下来的部分中,您将了解如何使用集群自动扩缩器和节点自动预配功能,以进一步优化您的资源利用率。
集群自动扩缩器可用于根据需求添加或移除节点。当需求较高时,集群自动扩缩器将会向节点池中添加节点,以满足该需求。当需求较低时,集群自动扩缩器将会移除节点,以对集群进行缩容。这种方式可确保集群保持高可用性,同时最大限度降低与额外机器相关的多余费用。
这需要几分钟才能完成。
对集群进行扩缩时,需要在优化资源利用率与提高资源可用性之间进行权衡取舍,以决定何时移除节点。移除使用率过低的节点可以提高集群利用率,但新的工作负载可能需要等待重新预配资源才能运行。
您可以指定在做出此类决定时使用哪种自动扩缩配置文件。目前可用的配置文件包括:
optimize-utilization
自动扩缩配置文件,以便观察扩缩的完整效果:启用自动扩缩后,在 Cloud 控制台中观察您的集群。点击左上角的三条横线,打开导航菜单。
在导航菜单中,依次选择 Kubernetes Engine > 集群。
在集群页面上,选择 scaling-demo 集群。
在 scaling-demo 的集群页面上,选择节点标签页。
如果您将 3 个节点请求的 CPU 值和可分配的 CPU 值分别相加,总值将分别为 1555m 和 2820m。也就是说,整个集群总计有 1265m 的可用 CPU 资源。此值高于单个节点提供的资源大小。
为优化资源利用率,可以将满足当前需求的当前工作负载合并到两个节点中(而非三个节点)。不过,您的集群还没有自动缩减。这是因为集群中分布着系统 Pod。
您的集群在 kube-system
命名空间下运行了多个 Deployment,因此可提供日志记录、监控和自动扩缩等不同的 GKE 服务。
默认情况下,这些 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
。
kube-system
Pod 创建 Pod 中断预算:点击检查我的进度,验证您是否完成了上述任务。
在这些命令中,您将根据在创建 Deployment 时定义的标签选择不同的 kube-system Deployment Pod,并指定每个 Deployment 可以有 1 个不可用的 Pod。这将允许自动扩缩器重新安排系统 Pod。
应用 PDB 后,集群应该在一两分钟内由三个节点缩减至两个节点。
在 Cloud 控制台中,刷新 scaling-demo 的节点标签页,检查您的资源是如何打包的:
您设置了自动化,使集群从三个节点缩减为两个节点!
从费用角度讲,由于缩减了节点池,在集群需求较低的时间段,您将需要付费的机器数量也更少。如果您在一天之中在高需求时间段和低需求时间段之间波动,这种扩缩可能会更为剧烈。
需要注意的是,尽管集群自动扩缩器移除了不必要的节点,但 Pod 纵向自动扩缩和 Pod 横向自动扩缩还是对降低足够的 CPU 需求起到了很大的帮助作用,因此不再需要该节点。将这些工具结合使用可以非常好地优化总体费用和资源利用率。
所以,在需要安排 Pod 时,集群自动扩缩器可以帮助添加和移除节点。然而,GKE 还专门提供了另一个用于纵向扩缩的功能,称为节点自动预配。
节点自动预配 (NAP) 实际上是通过添加新节点来调整节点池的大小,从而满足需求。如果不启用节点自动预配功能,集群自动扩缩器将仅在您指定的节点池内创建新节点。也就是说,新节点的机器类型与该池内的其他节点相同。这尤其适合优化批量工作负载以及其他不需要过度扩缩的应用的资源利用率,因为相比只在现有池内添加一些节点,创建一个专门针对您的使用情形进行优化的节点池可能需要花费更多的时间。
在此命令中,您指定了 CPU 资源和内存资源的数量下限和数量上限。此设置适用于整个集群。
NAP 可能会花费一些时间,而且它很可能不会为当前状态下的 scaling-demo 集群创建新节点池。
在接下来的部分中,您将增大对集群的需求,并观察自动扩缩器以及 NAP 的行为。
点击检查我的进度,验证您是否完成了上述任务。
至此,您已经分析了在对应用的需求较低时,HPA、VPA 以及集群自动扩缩器是如何帮助您节省资源和费用的。现在,您将了解在需求增加的情况下,这些工具将如何处理可用性问题。
php-apache
服务发送一个无限查询循环:返回原来的 Cloud Shell 标签页。
执行以下命令,在一分钟左右的时间内,您应该会看到 CPU 负载增大:
等待并重新运行此命令,直至您看到目标值高于 100%。
您还可以在 Cloud 控制台中刷新节点标签页,以此来监控您的集群。
几分钟后,您将会发现以下几点。
php-apache
Deployment 进行扩容。等到您的 php-apache
Deployment 扩展到 7 个副本,并且您的“节点”标签页如下所示:
当需求增大时,您的集群也可以高效扩容来满足需求!但是,请注意处理这种需求高峰时所花费的时间。对于多数应用来说,预配新资源时无法正常运行也是一个问题。
在扩容以满足更大负载的需求时,Pod 横向自动扩缩会添加新的 Pod,而 Pod 纵向自动扩缩将根据您的设置来调整 Pod 大小。如果现有节点上有空间,则它可能会跳过拉取映像的步骤,立即开始在新 Pod 上运行应用。若您使用的节点以前没有部署过您的应用,则在运行应用前需要下载容器映像,这可能会多花一些时间。
因此,如果您的现有节点上没有足够的空间,并且您使用了集群自动扩缩器,则可能需要更长的时间。现在,它需要预配新节点,对其进行设置,然后下载映像并启动 Pod。如果节点自动预配器将要创建一个新节点池,就像在集群中一样,则可能需要更长的时间,因为您需要先预配新节点池,然后对新节点完成所有相同的步骤。
为了应对在自动扩缩时出现的这些延迟,您可能会希望进行一些超额预配,以减小在自动扩容时应用承受的压力。这对优化费用十分重要,因为您肯定不希望为多余的资源付费,也不希望应用性能受到影响。
您可以使用以下公式确定超额预配的数量:
我们以集群的 CPU 利用率为例。您不希望它达到 100%,所以您可以选择 15% 的缓冲空间,以保持安全的范围。之后,公式中的流量变量是指估计在接下来两到三分钟内的流量增长百分比。在前面运行的负载测试中,流量出现了极端增长,从 0% 增长到 150%,我们假设一个更为平均的流量增长水平 30%。
根据这些数字,您计算出的安全缓冲空间约为 65%。也就是说,为了应对扩容需求并尽可能地降低任何问题的影响,您可以将资源超额预配约 65%。
使用集群自动扩缩功能超额预配集群时,一个高效的策略是使用暂停 Pod。
暂停 Pod 是低优先级 Deployment,能够被高优先级的 Deployment 移除并取代。也就是说,您可以创建低优先级 Pod,但它们除了在集群中预留缓冲空间之外,实际上不执行任何操作。当高优先级 Pod 需要空间时,将移除暂停 Pod 并将其重新安排到另一个节点或新节点上,而高优先级 Pod 将具有所需要的空间来快速进行安排。
观察如何创建新节点(很可能是在新节点池中),以适配您新创建的暂停 Pod。现在,若您再次运行负载测试,当您需要为 php-apache
Deployment 增加一个额外的节点时,该 Deployment 可能会被安排在暂停 Pod 所在的节点上,而暂停 Pod 将被安排到新节点上。这是非常有用的,因为虚拟暂停 Pod 让您的集群可以提前预配新节点,以便实际应用可以更快地进行扩容。若您预计会有大量的流量,可以添加更多的暂停 Pod,但每个节点上添加的暂停 Pod 最好不要超过一个。
点击检查我的进度,验证您是否完成了上述任务。
恭喜!在本实验中,您配置了集群,使其可以基于需求自动、高效地扩容或缩容。Pod 横向自动扩缩和 Pod 纵向自动扩缩可帮助您自动扩缩集群的部署,而集群自动扩缩器和节点自动预配功能可为您自动扩缩集群的基础设施。
与往常一样,使用哪种工具将取决于您的工作负载。谨慎使用这些自动扩缩器可以在您需要时充分提高可用性,并确保您在低需求的时间段仅为需要的资源付费。在费用方面,它们还可以帮助您优化资源利用率并节省费用。
请查看以下资源,详细了解本实验中介绍的主题:
…可帮助您充分利用 Google Cloud 技术。我们的课程会讲解各项技能与最佳实践,可帮助您迅速上手使用并继续学习更深入的知识。我们提供从基础到高级的全方位培训,并有点播、直播和虚拟三种方式选择,让您可以按照自己的日程安排学习时间。各项认证可以帮助您核实并证明您在 Google Cloud 技术方面的技能与专业知识。
上次更新手册的时间:2024 年 2 月 1 日
上次测试实验的时间:2023 年 9 月 20 日
版权所有 2025 Google LLC 保留所有权利。Google 和 Google 徽标是 Google LLC 的商标。其他所有公司名和产品名可能是其各自相关公司的商标。
此内容目前不可用
一旦可用,我们会通过电子邮件告知您
太好了!
一旦可用,我们会通过电子邮件告知您
One lab at a time
Confirm to end all existing labs and start this one