Horizontal Pod Autoscaler কীভাবে কাজ করে, এবং এটি Cluster Autoscaler-এর সাথে কীভাবে সম্পর্কিত?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** পর্যবেক্ষিত metric (CPU, memory, বা custom)-এর ভিত্তিতে **Pod replica** যোগ বা অপসারণ করে। **Cluster Autoscaler (CA)** **node** যোগ বা অপসারণ করে যখন Pod schedule করা যায় না বা node কম ব্যবহৃত হয়। এরা ভিন্ন স্তরে কাজ করে এবং একসাথে কাজ করে।

## দুটি autoscaler, দুটি স্তর

```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                       # current/target metric, replica count
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-কে স্বয়ংক্রিয়ভাবে চাহিদার সাথে capacity মেলাতে দেয়, এবং দুটি স্তর বোঝা senior-স্তরের জ্ঞান যা খরচ-সাশ্রয়ী, স্থিতিস্থাপক cluster-কে অতি- বা কম-provision করা cluster থেকে আলাদা করে। মূল মানসিক মডেলটি হলো যে **HPA লোডের প্রতিক্রিয়ায় Pod scale করে** (পর্যবেক্ষিত CPU, memory, বা custom metric থেকে replica count সমন্বয় করে) যখন **Cluster Autoscaler scheduling চাপের প্রতিক্রিয়ায় node scale করে** (Pod Pending থাকলে মেশিন যোগ করে, node idle থাকলে অপসারণ করে) — এরা ভিন্ন স্তরে কাজ করে ও সহযোগিতা করে: HPA কেবল তখনই Pod যোগ করতে পারে যদি জায়গা থাকে, আর CA সেই জায়গা সরবরাহ করে। HPA-এর control loop বোঝা — `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)` সূত্র, পর্যায়ক্রমিক reconciliation, এবং flapping প্রতিরোধকারী stabilization window — আপনাকে এটিকে জাদু হিসেবে না দেখে কনফিগার ও debug করতে দেয়। সতর্কতাগুলো সেখানেই যেখানে senior বিচারবুদ্ধি প্রকাশ পায়: CPU/memory-তে HPA-এর **metrics-server দরকার** এবং utilization **request-এর সাপেক্ষে** গণনা করে, তাই ভুল বা অনুপস্থিত request এর গণিতকে অর্থহীন করে; custom metric (requests-per-second, queue depth)-এর Prometheus Adapter বা KEDA-এর মতো একটি adapter দরকার; এবং node scale-up মিনিট নেয়, তাই headroom গুরুত্বপূর্ণ। যেহেতু capacity right-size করা সরাসরি traffic spike-এর অধীনে নির্ভরযোগ্যতা ও শান্ত সময়ে cloud খরচকে প্রভাবিত করে, এবং যেহেতু উভয় autoscaler সঠিকভাবে সেট করা resource request-এর উপর নির্ভর করে, HPA ও Cluster Autoscaler আয়ত্ত করা production Kubernetes দক্ষ ও নির্ভরযোগ্যভাবে চালানোর জন্য ভিত্তিমূলক।

দুটি autoscaler, দুটি স্তর

HPA control loop কীভাবে কাজ করে

একটি HPA manifest

গুরুত্বপূর্ণ নির্ভরতা ও সতর্কতা

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন