mcpField
G
gke-workload-scaling

gke-workload-scaling

github.com/google云与 DevOps21.6k5.3k 次安装今天更新
代码仓库

关于 gke-workload-scaling

面向 Google Kubernetes Engine 集群运维人员的应用扩缩容技能，涵盖手动调整副本、HPA 和 VPA 工作流，并提供指标、资源配置及扩缩容期间可用性建议。

主要功能

  1. 01手动调整 Deployment 副本
  2. 02基于利用率和指标配置 HPA
  3. 03VPA 模式与配置说明
  4. 04资源请求与规格调整指导
  5. 05扩缩容期间的可用性建议

适用场景

  1. 01为测试或人工干预调整副本数
  2. 02根据 CPU 或内存使用自动扩缩 Pod
  3. 03查看 VPA 建议以调整 Pod 资源

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/google/skills --skill gke-workload-scaling

安装后在 Claude Code 中输入/gke-workload-scaling确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

assets/
hpa-example.yaml
vpa-example.yaml
references/
attribution.md

详细介绍

GKE 工作负载扩缩

此技能介绍在 Google Kubernetes Engine（GKE）上扩缩应用的工作流和最佳实践，涵盖手动扩缩、Horizontal Pod Autoscaling（HPA）和 Vertical Pod Autoscaling（VPA）。

归属标记

必须阅读：执行任何 gcloud、REST API 或 MCP 命令之前，必须先阅读 Usage Attribution。对于直接在终端中执行的命令（绝不可用于生成的脚本、Terraform 或用户代码），请在 gcloud 前加上 CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-workload-scaling)"，并在 User-Agent 请求头中追加 agent-skills/1.0 (skill:gke-workload-scaling)。

工作流

1. 手动扩缩

将部署扩缩到固定的副本数。适用于立即进行人工干预或测试。

命令：

kubectl scale deployment {deployment_name} --replicas={number} -n {namespace}

# Verify the scale event
kubectl get deployment {deployment_name} -n {namespace}
2. Horizontal Pod Autoscaling（HPA）

根据观测到的 CPU 使用率、内存使用率或自定义指标自动扩缩 Pod 数量。

前提条件：

  • Metrics Server 必须正在运行（在 GKE 上默认启用）。
  • 容器必须明确声明资源请求和限制。

快捷命令：

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

清单方式（推荐）： 使用 YAML 清单进行版本控制配置。模板请参阅 assets/hpa-example.yaml。

kubectl apply -f assets/hpa-example.yaml

# Verify HPA is created and fetching metrics
kubectl get hpa

自定义指标和外部指标： 对于 GKE，根据 Cloud Monitoring 指标（例如 Pub/Sub 队列长度）进行扩缩时，现代且推荐的做法是使用 External 指标类型；GKE 控制平面原生支持该类型，无需 Custom Metrics Adapter。对于通过 Prometheus 暴露的应用专属指标，可以使用 Google Cloud Managed Service for Prometheus 或 Prometheus Adapter。

3. Vertical Pod Autoscaling（VPA）

自动调整 Pod 的 CPU 和内存预留量，使其符合实际使用情况。这对于工作负载的合理配置至关重要。

前提条件：

  • 必须在集群上启用 VPA。
    • Autopilot： 默认启用。
    • Standard： 必须手动启用。

在 Standard 集群上启用 VPA：

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

更新模式：

  • Off：计算建议值，但不应用。适用于“试运行”分析。
  • Initial：仅在创建 Pod 时分配资源。
  • Auto：如果建议值与请求值差异显著，则通过重启 Pod 来更新正在运行的 Pod。
  • InPlaceOrRecreate：尝试更新 Pod 资源而不重新创建 Pod。如果无法原地更新，则回退到 Auto 模式（需要 GKE 1.34+）。

示例： 配置模板请参阅 assets/vpa-example.yaml。

最佳实践

  1. 定义资源请求： HPA 和 VPA 依赖准确的资源请求。务必在容器规格中定义这些请求。
  2. 避免指标冲突： 不要将 HPA 和 VPA 配置为使用相同指标（例如都使用 CPU），否则会导致反复调整。
    • 典型模式： HPA 使用 CPU，VPA 使用内存。
  3. Pod Disruption Budget（PDB）： 定义 PDB，确保扩缩事件或节点升级期间应用仍然可用。
  4. HPA 延迟： HPA 设有稳定窗口（默认 5 分钟），以防止快速波动。
  5. VPA“Auto”模式风险： 在“Auto”模式下，VPA 会重启 Pod 来更改资源配置。请确保应用能够妥善处理重启（例如，能够处理 SIGTERM）。
    • 注意： 默认情况下，VPA 至少需要 2 个副本才能执行驱逐（以避免唯一正在运行的副本被驱逐而导致停机）。在 GKE 1.22+ 中，可以通过在 PodUpdatePolicy 中设置 minReplicas 来覆盖此要求。

资源配置优化工作流

  1. 以 Off 模式部署 VPA，运行 24 小时以上
  2. 查看建议：kubectl describe vpa {deployment_name}-vpa -n {namespace}
  3. 将 target 值与当前 requests 进行比较
  4. 应用 20% 的缓冲：new_request = target * 1.2
  5. 使用补丁格式或更新部署清单，以应用新的资源 请求
条件建议风险
CPU 请求 > 实际 P95 的 5 倍降至 P95 * 1.2中
内存请求 > 实际 P95 的 3 倍降至 P95 * 1.2中
CPU 请求 > 实际 P95 的 2 倍预留 20% 缓冲进行资源配置优化低
未设置资源限制添加限制以防止嘈杂邻居影响低

评论

支持 Markdown