Horizontal Pod Autoscaler કેવી રીતે કામ કરે છે, અને તે Cluster Autoscaler સાથે કેવી રીતે સંબંધિત છે?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** અવલોકિત metrics (CPU, memory, કે custom) ના આધારે **Pod replicas** ઉમેરે કે દૂર કરે છે. **Cluster Autoscaler (CA)** જ્યારે Pods schedule ન થઈ શકે કે nodes ઓછા વપરાય ત્યારે **nodes** ઉમેરે કે દૂર કરે છે. તેઓ અલગ સ્તરે કામ કરે છે અને સાથે મળીને કામ કરે છે.

## બે autoscalers, બે સ્તરો

```text
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.
```

## HPA control loop કેવી રીતે કામ કરે છે

```text
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).
```

## એક HPA manifest

```yaml
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      # avg CPU ને REQUEST ના ~60% પર રાખો
  behavior:                           # વૈકલ્પિક: scale up/down ઝડપ tune કરો
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # current/target metric, replica count
kubectl top pods                      # metrics-server જરૂરી
```

## મહત્વની dependencies અને ચેતવણીઓ

```text
• 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 ને માંગ સાથે આપોઆપ મેળ ખવડાવવા દે છે, અને બે સ્તરો સમજવા એ senior-level જ્ઞાન છે જે cost-efficient, resilient clusters ને over- કે under-provisioned clusters થી અલગ પાડે છે. મુખ્ય માનસિક મોડલ એ છે કે **HPA load ના પ્રતિભાવમાં Pods scale કરે છે** (અવલોકિત CPU, memory, કે custom metrics થી replica count સમાયોજિત કરે છે) જ્યારે **Cluster Autoscaler scheduling દબાણના પ્રતિભાવમાં nodes scale કરે છે** (Pods Pending હોય ત્યારે મશીનો ઉમેરે, nodes idle હોય ત્યારે દૂર કરે) — તેઓ અલગ સ્તરે કામ કરે છે અને સહકાર આપે છે: HPA જગ્યા હોય તો જ Pods ઉમેરી શકે, અને CA એ જગ્યા પૂરી પાડે છે. HPA નું control loop સમજવું — `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)` સૂત્ર, સામયિક reconciliation, અને flapping અટકાવતી stabilization windows — તમને તેને જાદુ ગણવાને બદલે configure અને debug કરવા દે છે. ચેતવણીઓ એ છે જ્યાં senior નિર્ણય દેખાય છે: CPU/memory પર HPA ને **metrics-server જરૂરી છે** અને utilization ને **requests ના સાપેક્ષે** ગણે છે, તેથી ખોટા કે ગુમ requests તેની ગણતરીને અર્થહીન બનાવે છે; custom metrics (requests-per-second, queue depth) ને Prometheus Adapter કે KEDA જેવા adapter ની જરૂર છે; અને node scale-up ને મિનિટો લાગે છે, તેથી headroom મહત્વનું છે. કારણ કે capacity ને right-size કરવું traffic spikes હેઠળ reliability અને શાંત સમયગાળામાં cloud ખર્ચ પર સીધી અસર કરે છે, અને કારણ કે બંને autoscalers યોગ્ય રીતે set કરેલા resource requests પર આધાર રાખે છે, HPA અને Cluster Autoscaler પર પ્રભુત્વ મેળવવું એ production Kubernetes ને કાર્યક્ષમ અને reliable રીતે operate કરવા માટે પાયાનું છે.

બે autoscalers, બે સ્તરો

HPA control loop કેવી રીતે કામ કરે છે

એક HPA manifest

મહત્વની dependencies અને ચેતવણીઓ

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો