google/gke-workload-scaling
>- Manages scaling for GKE workloads using HPA and VPA. Use when configuring Horizontal Pod Autoscaler (HPA), configuring Vertical Pod Autoscaler (VPA), or applying best practices for GKE workload autoscaling. Do not use for cluster-level autoscaling (Cluster Autoscaler), static cluster sizing, or configuring node-level machine styles directly.
npx skills add https://github.com/google/skills --skill gke-workload-scaling
This skill provides workflows and best practices for scaling applications on
Google Kubernetes Engine (GKE). It covers manual scaling, Horizontal Pod
Autoscaling (HPA), and Vertical Pod Autoscaling (VPA).
Scale a deployment to a fixed number of replicas. Useful for immediate manual
intervention or testing.
Command:
kubectl scale deployment {deployment_name} --replicas={number} -n {namespace}
# Verify the scale event
kubectl get deployment {deployment_name} -n {namespace}
Automatically scale the number of pods based on observed CPU utilization, memory
utilization, or custom metrics.
Prerequisites:
Quick Command:
kubectl autoscale deployment {deployment_name} --cpu-percent=50 --min=1 --max=10
Manifest Approach (Recommended): Use a YAML manifest for version-controlled
configuration. See assets/hpa-example.yaml for a
template.
kubectl apply -f assets/hpa-example.yaml
# Verify HPA is created and fetching metrics
kubectl get hpa
Custom Metrics & External Metrics: For GKE, the modern and recommended
approach for scaling based on Cloud Monitoring metrics (e.g., Pub/Sub queue
length) is to use the External metric type, which is natively supported by
the GKE control plane without requiring the Custom Metrics Adapter. For
application-specific metrics exposed via Prometheus, you can use **Google Cloud
Managed Service for Prometheus** or the Prometheus Adapter.
Automatically adjust the CPU and memory reservations for your pods to match
actual usage. This is critical for right-sizing workloads.
Prerequisites:
Enable VPA on Standard Cluster:
gcloud container clusters update {cluster_name} --enable-vertical-pod-autoscaling --zone {zone}
Update Modes:
Off: Calculates recommendations but does not apply them. Good for "dryrun" analysis.
Initial: Assigns resources only at pod creation time.Auto: Updates running pods by restarting them if recommendations differsignificantly from requests.
InPlaceOrRecreate: Attempts to update Pod resources without recreating thePod. If in-place update is not possible, it reverts to Auto mode (requires
GKE 1.34+).
Example: See assets/vpa-example.yaml for a
configuration template.
requests. Always define them in your container specs.
metric (e.g., both CPU). This causes thrashing.
availability during scaling events or node upgrades.
rapid fluctuation.
resources. Ensure your application handles restarts gracefully (e.g.,
handles SIGTERM).
evictions (to prevent a situation where the only running replica is
evicted, causing downtime). In GKE 1.22+, you can override this by
setting minReplicas in PodUpdatePolicy.
Off mode for 24+ hours{namespace}`
target values against current requestsnew_request = target * 1.2requests
Condition | Recommendation | Risk
----------------------------- | ------------------------------------ | ------
CPU request >5x P95 actual | Reduce to P95 * 1.2 | Medium
Memory request >3x P95 actual | Reduce to P95 * 1.2 | Medium
CPU request >2x P95 actual | Rightsizing with 20% buffer | Low
No resource limits set | Add limits to prevent noisy-neighbor | Low
Take google/gke-workload-scaling from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.