Horizontal Pod Autoscaler کیسے کام کرتا ہے، اور اس کا Cluster Autoscaler سے کیا تعلق ہے؟

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** مشاہدہ کیے گئے metrics (CPU، memory، یا custom) کی بنیاد پر **Pod replicas** کا اضافہ یا کمی کرتا ہے۔ **Cluster Autoscaler (CA)** **nodes** کا اضافہ یا کمی کرتا ہے جب Pods schedule نہیں ہو پاتے یا nodes کم استعمال ہو رہے ہوں۔ یہ مختلف layers پر کام کرتے ہیں اور مل کر کام کرتے ہیں۔

## دو autoscalers، دو layers

```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      # اوسط CPU کو REQUEST کے تقریباً 60% پر رکھیں
  behavior:                           # اختیاری: scale up/down رفتار کو ٹیون کریں
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # موجودہ/ہدف metric، replica کی تعداد
kubectl top pods                      # metrics-server درکار ہے
```

## اہم انحصار اور تنبیہات

```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 کو گنجائش کو طلب سے خود بخود میل کرانے دیتی ہے، اور دو layers کو سمجھنا ایک سینئر-سطح کا علم ہے جو لاگت کے لحاظ سے مؤثر، لچکدار clusters کو حد سے زیادہ یا حد سے کم مہیا کیے گئے clusters سے الگ کرتا ہے۔ کلیدی ذہنی ماڈل یہ ہے کہ **HPA بوجھ کے جواب میں Pods کو scale کرتا ہے** (مشاہدہ کیے گئے CPU، memory، یا custom metrics سے replica تعداد ایڈجسٹ کرتا ہے) جبکہ **Cluster Autoscaler scheduling دباؤ کے جواب میں nodes کو scale کرتا ہے** (جب Pods Pending ہوں تو مشینیں شامل کرتا ہے، جب nodes بیکار ہوں تو انہیں ہٹاتا ہے) — یہ مختلف layers پر کام کرتے ہیں اور تعاون کرتے ہیں: HPA صرف تب Pods شامل کر سکتا ہے جب جگہ ہو، اور CA وہ جگہ فراہم کرتا ہے۔ HPA کے control loop کو سمجھنا — `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)` فارمولا، متواتر reconciliation، اور stabilization windows جو flapping کو روکتی ہیں — آپ کو اسے کنفیگر اور debug کرنے دیتا ہے، بجائے اس کے کہ اسے جادو سمجھا جائے۔ تنبیہات وہ جگہ ہیں جہاں سینئر فہم ظاہر ہوتی ہے: CPU/memory پر HPA کو **metrics-server درکار** ہے اور یہ utilization کو **requests کے نسبت** حساب کرتا ہے، اس لیے غلط یا غائب requests اس کے حساب کو بے معنی بنا دیتے ہیں؛ custom metrics (requests-per-second، queue depth) کو Prometheus Adapter یا KEDA جیسے adapter کی ضرورت ہوتی ہے؛ اور node scale-up میں منٹ لگتے ہیں، اس لیے headroom اہم ہے۔ چونکہ گنجائش کو right-size کرنا براہِ راست ٹریفک کے اچانک اضافے کے تحت reliability اور خاموش ادوار میں cloud خرچ کو متاثر کرتا ہے، اور چونکہ دونوں autoscalers درست طریقے سے مقرر کردہ resource requests پر انحصار کرتے ہیں، HPA اور Cluster Autoscaler پر عبور production Kubernetes کو مؤثر اور قابلِ اعتماد انداز میں چلانے کے لیے بنیادی ہے۔

دو autoscalers، دو layers

HPA کا control loop کیسے کام کرتا ہے

ایک HPA manifest

اہم انحصار اور تنبیہات

یہ کیوں اہم ہے

متعلقہ سوالات