Horizontal Pod Autoscaler (HPA) கவனிக்கப்பட்ட metric களை (CPU, memory, அல்லது custom) அடிப்படையாகக் கொண்டு Pod replica களை சேர்க்கிறது அல்லது அகற்றுகிறது. Cluster Autoscaler (CA) Pod களை schedule செய்ய முடியாதபோது அல்லது node கள் குறைவாகப் பயன்படுத்தப்படும்போது node களை சேர்க்கிறது அல்லது அகற்றுகிறது. அவை வெவ்வேறு layer களில் இயங்கி ஒன்றாக வேலை செய்கின்றன.
HPA → scales PODS (more/fewer replicas of a Deployment) — reacts to LOAD
CA → scales NODES (grows/shrinks the cluster's machines) — reacts to PENDING Pods
VPA → (bonus) adjusts a Pod's requests/limits — reacts to right-sizing
Typical flow: load rises → HPA adds Pods → Pods can't fit → CA adds a node →
Pods schedule. Load drops → HPA removes Pods → node idle → CA removes it.
Every ~15s the HPA controller:
1. reads current metric (e.g. avg CPU across Pods) from metrics-server / custom API
2. computes: desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
3. scales the Deployment toward that (bounded by minReplicas/maxReplicas)
Example: 4 Pods at 80% CPU, target 50% → 4 * 80/50 = 6.4 → 7 replicas.
Stabilization windows dampen flapping (esp. on scale-down).
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web
minReplicas: 3
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60 # keep avg CPU ~60% of the REQUEST
behavior: # optional: tune scale up/down speed
scaleDown:
stabilizationWindowSeconds: 300
kubectl get hpa # current/target metric, replica count
kubectl top pods # requires metrics-server
• HPA on CPU/memory REQUIRES metrics-server installed; utilization is relative to REQUESTS
→ if requests are unset/wrong, HPA math is meaningless. Set requests correctly.
• Custom/external metrics (RPS, queue depth) need an adapter (Prometheus Adapter, KEDA).
• HPA and manual `replicas` conflict — let the HPA own the replica count.
• Cluster Autoscaler needs correct requests too: it looks at Pending Pods' REQUESTS to
decide node scaling. Node scale-up takes minutes (provisioning), so keep headroom.
Autoscaling தான் Kubernetes capacity ஐ தேவைக்கு தானாகப் பொருத்த அனுமதிக்கிறது, மேலும் இரண்டு layer களைப் புரிந்துகொள்வது senior-level அறிவு, இது செலவு-திறமையான, resilient cluster களை over- அல்லது under-provisioned ஆனவற்றிலிருந்து பிரிக்கிறது. முக்கிய மனநிலை model என்னவென்றால் HPA load-க்கு பதிலளிக்க Pod களை scale செய்கிறது (கவனிக்கப்பட்ட CPU, memory, அல்லது custom metric களிலிருந்து replica எண்ணிக்கையை சரிசெய்கிறது) அதேசமயம் Cluster Autoscaler scheduling அழுத்தத்திற்கு பதிலளிக்க node களை scale செய்கிறது (Pod கள் Pending-இல் இருக்கும்போது machine களைச் சேர்த்து, node கள் idle-ஆக இருக்கும்போது அவற்றை அகற்றுகிறது) — அவை வெவ்வேறு layer களில் இயங்கி ஒத்துழைக்கின்றன: இடம் இருந்தால் மட்டுமே HPA Pod களைச் சேர்க்க முடியும், மேலும் CA அந்த இடத்தை வழங்குகிறது. HPA-இன் control loop ஐப் புரிந்துகொள்வது — desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric) சூத்திரம், அவ்வப்போதைய reconciliation, மற்றும் flapping ஐத் தடுக்கும் stabilization window கள் — அதை ஒரு மந்திரமாகக் கருதாமல் configure மற்றும் debug செய்ய உங்களை அனுமதிக்கிறது. எச்சரிக்கைகள் தான் senior தீர்ப்பு தெரியும் இடம்: CPU/memory-இல் HPA-க்கு metrics-server தேவை மற்றும் utilization ஐ requests-க்கு தொடர்புடையதாக கணக்கிடுகிறது, எனவே தவறான அல்லது இல்லாத requests அதன் கணிதத்தை அர்த்தமற்றதாக்குகின்றன; custom metric கள் (requests-per-second, queue depth) Prometheus Adapter அல்லது KEDA போன்ற ஒரு adapter ஐத் தேவைப்படுகின்றன; மற்றும் node scale-up நிமிடங்கள் ஆகும், எனவே headroom முக்கியம். Right-sizing capacity traffic spike களின் கீழ் reliability ஐயும் அமைதியான காலகட்டங்களில் cloud செலவையும் நேரடியாகப் பாதிப்பதால், மற்றும் இரண்டு autoscaler களும் சரியாக அமைக்கப்பட்ட resource requests ஐ சார்ந்திருப்பதால், HPA மற்றும் Cluster Autoscaler ஐ தேர்ச்சி பெறுவது production Kubernetes ஐ திறமையாகவும் நம்பகமாகவும் இயக்குவதற்கு அடிப்படையானது.
விரிவான பதில்களுடன் கூடிய IT நேர்காணல் கேள்விகளின் நூலகம் — Junior முதல் Senior வரை.
நன்கொடை