A traffic spike may need more copies of an application, while a quiet period may need fewer. A HorizontalPodAutoscaler (HPA) adjusts a workload’s Pod replica count in response to a metric. This is horizontal scaling: adding or removing replicas rather than changing the resources available to each one. section 6.2
Listing 6.2 Chapter06/6.2_HPA/hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: timeserver
spec:
minReplicas: 1 #1
maxReplicas: 10 #2
metrics:
- resource:
name: cpu
target:
averageUtilization: 20 #3
type: Utilization
type: Resource
scaleTargetRef: #4
apiVersion: apps/v1 #4
kind: Deployment #4
name: timeserver #4
This HPA configuration targets a Deployment, keeps between one and ten replicas, and aims for average CPU utilization of 20% of the Pods’ requested CPU. section 6.2
For a CPU target, the HPA compares average utilization across the Pods with the configured percentage of their CPU requests. It adds replicas above the target and removes them below it, subject to replica limits and cooldown periods. Set resource requests on the Deployment so this comparison works correctly. An HPA scales Pods, not nodes: the cluster still needs capacity to run them. On GKE Autopilot, node capacity is provisioned automatically as Pod demand changes. section 6.2 section 6.1
Test scaling under load
A Deployment starts with one replica and exposes a CPU-intensive URL that calculates pi. After creating the Deployment, Service, and HPA, generate requests with Apache Bench. Use `kubectl top pods` to inspect CPU use and `kubectl get deploy,hpa,pods` to watch the target, replica count, and Pod status change. The same CPU-based approach can scale a Deployment of CPU-intensive background workers. section 6.2 section 10.1.3
CPU is not the only possible signal. Requests per second (RPS) can express traffic in terms of a measured per-replica capacity. An HPA can use an external RPS metric from a monitoring solution; the illustrated HTTP setup uses an Ingress, which can observe requests. Choosing that metric requires the appropriate monitoring metric and, in the Google Cloud example, the Ingress forwarding-rule identifier. section 6.2.1
