企业官网建设流程全解析

GKE 工作负载弹性伸缩实战：HPA 与 VPA 配置、Rightsizing 与最佳实践

【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills

导读

本文基于 gke-workload-scaling 技能文档，系统讲解在 Google Kubernetes Engine（GKE）上为应用配置弹性伸缩的完整方案，涵盖手动扩缩容、Horizontal Pod Autoscaler（HPA）与 Vertical Pod Autoscaler（VPA）的配置方法、更新模式选择、以及基于 VPA 推荐值进行资源 Rightsizing 的实战流程。读完本文，你将掌握用kubectl与 YAML 清单为 GKE 工作负载搭建可版本化、可观测、避免资源抖动与冲突的伸缩体系，并能结合仓库中现成的 HPA 模板 与 VPA 模板 直接落地。

一、GKE 伸缩模型总览

GKE 作为托管的 Kubernetes 平台，其伸缩能力分布在三个不同层级，本文聚焦的是工作负载（Pod）层的伸缩：

这一点在技能文档的描述（front-matter）中也有明确边界：gke-workload-scaling不用于集群级自动伸缩（Cluster Autoscaler）、静态集群规格设定或节点机型选择，那些应交给gke-cluster-autoscaler、gke-compute-classes等技能处理。仓库中 gke-basics 的 core-concepts 也印证了这一分层模型：HPA 伸缩副本、VPA 调整 requests、Cluster Autoscaler 伸缩节点、ComputeClasses 做声明式节点选择。

二、手动扩缩容：即时干预的基础手段

在自动化伸缩尚未部署、或需要立刻介入（如压测、故障演练、上线放量）时，手动扩缩容是最直接的选项：把 Deployment 固定缩放到指定副本数。

kubectl scale deployment {deployment_name} --replicas={number} -n {namespace} # 验证扩容事件 kubectl get deployment {deployment_name} -n {namespace}

要点：

• {deployment_name}、{namespace}、{number}需替换为实际值；若 Deployment 位于default命名空间，-n可省略。
• 验证时重点看READY与AVAILABLE列是否与目标副本数一致，以及kubectl get events中是否有Scaled up replica set之类的记录。
• 手动scale设置的副本数会与 HPA 的minReplicas/maxReplicas边界相互作用：一旦 HPA 开始管理该工作负载，后续副本数将由 HPA 控制，手动值只是临时干预。

手动扩缩容适合测试与应急，生产环境建议使用版本化的 HPA 清单，保证伸缩策略可审计、可回滚。

三、Horizontal Pod Autoscaler（HPA）：按指标横向伸缩

HPA 根据观测到的 CPU 利用率、内存利用率或自定义指标自动增减 Pod 副本数，是大多数无状态服务的主力伸缩手段。

3.1 前置条件

• Metrics Server 必须运行：HPA 依赖 Metrics Server 采集 CPU/内存指标，GKE 上默认启用，无需额外安装。
• 容器必须明确定义资源 requests/limits：HPA 按“实际使用量 / requests”计算利用率，没有 requests 则无法计算目标利用率。这一点也是文档 Best Practices 的第 1 条，后文会展开。

3.2 快速命令：一行启用

kubectl autoscale deployment {deployment_name} --cpu-percent=50 --min=1 --max=10

参数语义：

该命令生成一个HorizontalPodAutoscaler对象，等效于一个仅含 CPU 指标的 YAML 清单。它适合快速验证，但没有进入版本控制。

3.3 清单方式（推荐）：版本化配置

使用 YAML 清单可以把伸缩策略纳入 Git 管理。仓库提供了可直接应用的模板 assets/hpa-example.yaml，其完整内容如下：

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: example-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: example-deployment minReplicas: 1 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 70

应用并验证：

kubectl apply -f skills/cloud/gke-workload-scaling/assets/hpa-example.yaml # 确认 HPA 已创建并能拉到指标 kubectl get hpa

关于清单的关键细节：

• 使用autoscaling/v2API 版本，这是当前推荐的稳定版本，支持多指标与Utilization/AverageValue两种目标类型。
• scaleTargetRef指向被管理的 Deployment（apiVersion: apps/v1、kind: Deployment、name: example-deployment），替换name即指向你的工作负载。
• 示例同时配置了CPU（50%）与内存（70%）两个指标：HPA 会分别计算每个指标所需副本数，然后取其中最大值作为最终目标副本数，因此多指标配置时要评估两者是否会互相牵制。
• target.type: Utilization表示按“平均利用率”伸缩；若改为AverageValue，则可按绝对的 Pod 平均用量（如500mCPU、256Mi内存）伸缩。

3.4 自定义指标与外部指标

当默认的 CPU/内存指标不够用时，GKE 提供两条路径：

• External 指标（现代推荐）：基于 Cloud Monitoring 指标（例如 Pub/Sub 队列积压长度）伸缩时，优先使用External指标类型——它由 GKE 控制平面原生支持，无需部署 Custom Metrics Adapter，架构更简单、维护成本更低。
• Prometheus 指标：对应用暴露给 Prometheus 的指标（如每秒请求数、队列长度），可选用Google Cloud Managed Service for Prometheus或 Prometheus Adapter 接入。

选择原则：优先 External（GKE 原生、少一个组件）；只有需要 PromQL 语义或既有 Prometheus 生态时才引入 Adapter。

四、Vertical Pod Autoscaler（VPA）：垂直资源调优

VPA 根据 Pod 的历史实际用量，自动调整 CPU/内存 requests 与 limits，是资源 Right-sizing（瘦身）与防资源浪费的关键工具。

4.1 前置条件与启用方式

• Autopilot 集群：VPA 默认启用，开箱即用。
• Standard 集群：需手动启用，命令如下：

gcloud container clusters update {cluster_name} --enable-vertical-pod-autoscaling --zone {zone}

注意：--zone用于 zonal 集群；如果是 regional 集群应改用--region（与 gke-basics 中get-credentials的规则一致，区域/可用区参数必须与集群创建方式匹配）。

4.2 四种更新模式（updateMode）

InPlaceOrRecreate是较新的模式：它先尝试 In-Place Pod 资源更新（Pod 不重启、保持调度位置），只有在该机制不可用时才退化为Auto的重建方式。选择时务必确认集群版本满足 GKE 1.34+ 的前提。

4.3 仓库提供的 VPA 模板

assets/vpa-example.yaml 给出了一份可直接落地的配置：

apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: example-vpa namespace: default spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: example-deployment updatePolicy: updateMode: "Auto" resourcePolicy: containerPolicies: - containerName: "*" minAllowed: cpu: 100m memory: 50Mi maxAllowed: cpu: 1 memory: 1Gi

解读：

• targetRef指定 VPA 管理的 Deployment；containerName: "*"表示策略作用于所有容器。
• minAllowed/maxAllowed是安全护栏：VPA 只会把资源调整限定在100m CPU / 50Mi 内存到1 CPU / 1Gi 内存之间，避免推荐值越界导致 Pod 无法调度（过大）或资源不足（过小）。生产上应根据业务特性设置合理的上下界。
• 把updateMode改为"Off"即可切换到纯推荐模式——这正是仓库中 gke-cost-optimization 用于成本瘦身的做法，它提供了一个更精简的 vpa-recommendation-mode.yaml 模板，并建议用kubectl get vpa {deployment_name}-vpa -o jsonpath='{.status.recommendation}'读取推荐结果。

五、伸缩最佳实践

文档总结了 5 条关键实践，前两条直接决定 HPA/VPA 能否协同工作，务必逐条落实：

1. 明确定义资源 requests：HPA 与 VPA 都依赖准确的 requests 作为基准（HPA 计算利用率、VPA 计算推荐值）。未设置 requests 的容器，两者都无法正确工作。

   • 补充：在Autopilot集群上，CPU requests 必须按250m（0.25 vCPU）的整数倍设置，若传入如300m的非对齐值会被自动向上取整到最近的250m增量（即500m），且 requests 与 limits 自动相等、通常省略 limits（见 gke-basics）。编写 VPAminAllowed/maxAllowed时应记住这一约束。

2. 避免指标冲突：不要让 HPA 与 VPA 使用同一个指标（例如两者都用 CPU），否则会导致“震荡”（thrashing）——HPA 加副本稀释 CPU 利用率、VPA 又缩减 CPU requests，循环往复。

   • 典型分工模式：HPA 管 CPU、VPA 管内存。这也与仓库中的 HPA 模板（CPU 指标）和成本优化技能中 “Reconcile HPA and VPA recommendations（MPA）” 的建议一致。

3. 配置 Pod Disruption Budgets（PDBs）：在扩缩容事件、节点升级或 VPA 驱逐期间，PDB 保证应用的最小可用副本数，避免滚动过程中出现全量不可用。

4. 理解 HPA 延迟（Lag）：HPA 内置稳定窗口（默认约 5 分钟），防止指标瞬时波动引发副本数快速抖动。这意味着副本数变化不是即时的，排查“为什么还没扩容/缩容”时先考虑窗口期。

5. VPAAuto模式的运行风险：Auto模式下 VPA 通过重启 Pod来改变资源，应用必须能优雅处理重启（例如正确响应 SIGTERM、支持优雅退出）。

   • 关键机制：默认情况下 VPA 要求工作负载至少 2 个副本才会执行驱逐，以防止驱逐唯一副本造成宕机；在 GKE 1.22+ 中，可通过PodUpdatePolicy中的minReplicas覆盖该默认行为（单副本工作负载需自行评估风险）。

六、Rightsizing 工作流：把推荐值变成资源配额

VPA 的价值不只在自动调优，更在于提供一个可审计的瘦身流程。文档给出的标准流程如下：

1. 以Off模式部署 VPA（纯推荐、不驱逐），持续观察24 小时以上以覆盖业务高峰。
2. 读取推荐值：

   kubectl describe vpa {deployment_name}-vpa -n {namespace}

   也可用 JSON 路径提取：

   kubectl get vpa {deployment_name}-vpa -o jsonpath='{.status.recommendation}'

3. 将target值（推荐的目标 requests）与当前requests逐项对比。
4. 按 20% 缓冲应用：new_request = target * 1.2，为突发流量留出余量，避免一缩就触发扩容抖动。
5. 使用kubectl patch或更新 Deployment 清单，应用新的资源 requests。

6.1 决策参考表

文档与 gke-cost-optimization 技能给出了高度一致的量化规则：

使用要点：

• P95 实际用量可以从 Cloud Monitoring、kubectl top pods或 VPA 推荐状态中获取；推荐值本身已基于历史曲线给出lowerBound/target/upperBound三档，可直接使用target作为基准。
• 表格给出的是决策触发条件而非万能公式：真实场景应结合业务特性（如秒杀型流量）与上述 20% 缓冲规则综合判定。
• 瘦身有成本收益（过配 requests 是 GKE 上最大的资源浪费源之一），但保守调整、分批灰度比一次激进收敛更稳妥——这正是Off → 分析 → 小步应用流程的意义。

七、常见排查与联动建议

• HPA 没有生效：先kubectl get hpa查看TARGETS列是否为<unknown>；若指标拉不到，确认 Metrics Server 运行状态与容器是否声明了 requests。
• 副本数反复横跳：检查是否 HPA 与 VPA 撞了同一个指标（违背实践第 2 条），或目标利用率设置过低。
• VPA 不驱逐：确认副本数 ≥ 2（或已显式设置minReplicas）、应用能否优雅处理 SIGTERM、PDB 是否限制了驱逐。
• 集群级容量：当 Pod 扩容受节点容量限制时，需配合 Cluster Autoscaler（Autopilot 自动处理）与 gke-cluster-autoscaler 技能；节点机型与 Spot 选择见 gke-compute-classes。
• 成本视角：HPA/VPA 的 Right-sizing 与 Spot、CUD 等策略配合可显著降低成本，完整路径参考 gke-cost-optimization。

八、仓库资源索引

• 技能主文档：skills/cloud/gke-workload-scaling/SKILL.md
• HPA 清单模板：skills/cloud/gke-workload-scaling/assets/hpa-example.yaml
• VPA 清单模板：skills/cloud/gke-workload-scaling/assets/vpa-example.yaml
• VPA 推荐模式（Off）模板：skills/cloud/gke-cost-optimization/assets/vpa-recommendation-mode.yaml
• GKE 伸缩模型背景：skills/cloud/gke-basics/references/core-concepts.md
• Autopilot 资源请求约束：skills/cloud/gke-basics/SKILL.md
• 成本优化与 Right-sizing 联动：skills/cloud/gke-cost-optimization/SKILL.md
• 生产化就绪检查（HPA/VPA/PDB 维度）：skills/cloud/gke-productionize/SKILL.md

【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills