Configure autoscaling for Kubernetes, VMs, and serverless workloads based on metrics, schedules, and custom indicators.
Implement autoscaling strategies to automatically adjust resource capacity based on demand, ensuring cost efficiency while maintaining performance and availability.
Minimal working example:
# hpa-configuration.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
namespace: production
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
// ... (see reference guides for full implementation)
Detailed implementations in the references/ directory:
| Guide | Contents | |---|---| | Kubernetes Horizontal Pod Autoscaler | Kubernetes Horizontal Pod Autoscaler | | AWS Auto Scaling | AWS Auto Scaling | | Custom Metrics Autoscaling | Custom Metrics Autoscaling | | Autoscaling Script | Autoscaling Script | | Monitoring Autoscaling | Monitoring Autoscaling |
Copy a source-pinned command for your client. You run it yourself.
Destination: .claude/skills/autoscaling-configuration · pinned to the source commit
git clone https://github.com/aj-geddes/useful-ai-prompts.git
cd useful-ai-prompts
git checkout 3f5182cfd739fc113f4af5244a1cf342ad7f7911
mkdir -p ".claude/skills/autoscaling-configuration"
cp -r "skills/autoscaling-configuration" ".claude/skills/autoscaling-configuration"Review the source before running. This copies files into your project; it is not a one-click install and does not verify runtime safety.
Scanner static-checks@0.1.0 · commit 3f5182cfd739. Static checks cannot prove runtime safety – review the source and the exact diff before installing. How checks work.
No static rules matched. This is not a safety guarantee.