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 कम उपयोग में हैं। ये अलग परतों पर काम करते हैं और साथ मिलकर काम करते हैं।

## दो autoscalers, दो परतें

```text
HPA  → PODS को scale करता है  (Deployment की अधिक/कम replicas)     — LOAD पर प्रतिक्रिया
CA   → NODES को scale करता है (cluster की मशीनें बढ़ाता/घटाता है)   — PENDING Pods पर प्रतिक्रिया
VPA  → (बोनस) एक Pod के requests/limits समायोजित करता है           — right-sizing पर प्रतिक्रिया

सामान्य प्रवाह: load बढ़ता है → HPA Pods जोड़ता है → Pods फिट नहीं होते → CA एक node जोड़ता है →
              Pods schedule होते हैं। load घटता है → HPA Pods हटाता है → node निष्क्रिय → CA उसे हटाता है।
```

## HPA control loop कैसे काम करता है

```text
हर ~15s पर HPA controller:
  1. metrics-server / custom API से वर्तमान metric (जैसे Pods में औसत CPU) पढ़ता है
  2. गणना करता है:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. Deployment को उसकी ओर scale करता है (minReplicas/maxReplicas द्वारा सीमित)
उदाहरण: 80% CPU पर 4 Pods, target 50% → 4 * 80/50 = 6.4 → 7 replicas।
Stabilization windows flapping को कम करती हैं (ख़ासकर 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                       # current/target metric, replica count
kubectl top pods                      # metrics-server आवश्यक है
```

## ज़रूरी निर्भरताएँ व चेतावनियाँ

```text
• CPU/memory पर HPA के लिए metrics-server स्थापित होना ज़रूरी है; utilization REQUESTS के सापेक्ष है
  → अगर requests unset/ग़लत हैं, तो HPA का गणित अर्थहीन है। requests सही सेट करें।
• Custom/external metrics (RPS, queue depth) को एक adapter चाहिए (Prometheus Adapter, KEDA)।
• HPA और मैनुअल `replicas` टकराते हैं — HPA को replica count का स्वामी बनने दें।
• Cluster Autoscaler को भी सही requests चाहिए: यह node scaling तय करने को Pending Pods के
  REQUESTS देखता है। Node scale-up में मिनट लगते हैं (provisioning), इसलिए headroom रखें।
```

## यह क्यों महत्वपूर्ण है

Autoscaling ही वह चीज़ है जो Kubernetes को क्षमता को माँग के अनुसार स्वतः मिलाने देती है, और दोनों परतों को समझना senior-स्तरीय ज्ञान है जो लागत-कुशल, लचीले clusters को अधिक- या कम-प्रावधानित clusters से अलग करता है। मुख्य मानसिक मॉडल यह है कि **HPA load के जवाब में Pods को scale करता है** (देखे गए CPU, memory, या custom metrics से replica count समायोजित करते हुए) जबकि **Cluster Autoscaler scheduling दबाव के जवाब में nodes को scale करता है** (जब Pods Pending हों तो मशीनें जोड़ते हुए, जब nodes निष्क्रिय हों तो हटाते हुए) — वे अलग परतों पर काम करते हैं और सहयोग करते हैं: 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-प्रति-second, queue depth) को Prometheus Adapter या KEDA जैसे adapter की ज़रूरत होती है; और node scale-up में मिनट लगते हैं, इसलिए headroom मायने रखता है। चूँकि क्षमता को right-size करना traffic spikes के दौरान विश्वसनीयता और शांत अवधियों में cloud ख़र्च को सीधे प्रभावित करता है, और चूँकि दोनों autoscalers सही ढंग से सेट resource requests पर निर्भर हैं, HPA और Cluster Autoscaler में महारत production Kubernetes को कुशलता और विश्वसनीयता से संचालित करने की नींव है।

दो autoscalers, दो परतें

HPA control loop कैसे काम करता है

एक HPA manifest

ज़रूरी निर्भरताएँ व चेतावनियाँ

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न