Πώς λειτουργεί ο Horizontal Pod Autoscaler, και πώς σχετίζεται με τον Cluster Autoscaler;

Question

IT Interview Practice · Accepted Answer

Ο **Horizontal Pod Autoscaler (HPA)** προσθέτει ή αφαιρεί **Pod replicas** βάσει παρατηρούμενων metrics (CPU, memory ή custom). Ο **Cluster Autoscaler (CA)** προσθέτει ή αφαιρεί **nodes** όταν τα Pods δεν μπορούν να δρομολογηθούν ή οι 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.
```

## Πώς λειτουργεί το control loop του HPA

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

## Ένα manifest HPA

```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 ~60% του REQUEST
  behavior:                           # προαιρετικό: ρύθμισε την ταχύτητα scale up/down
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # τρέχον/στόχος metric, αριθμός replicas
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 να ταιριάζει αυτόματα τη χωρητικότητα με τη ζήτηση, και η κατανόηση των δύο επιπέδων είναι γνώση επιπέδου senior που ξεχωρίζει τα οικονομικά αποδοτικά, ανθεκτικά clusters από τα υπερ- ή υπο-provisioned. Το βασικό νοητικό μοντέλο είναι ότι ο **HPA κάνει scale Pods** ως απόκριση στο φορτίο (προσαρμόζοντας τον αριθμό replicas από παρατηρούμενα CPU, memory ή custom metrics) ενώ ο **Cluster Autoscaler κάνει scale nodes** ως απόκριση στην πίεση δρομολόγησης (προσθέτοντας μηχανήματα όταν τα Pods είναι Pending, αφαιρώντας τα όταν οι nodes είναι αδρανείς) — λειτουργούν σε διαφορετικά επίπεδα και συνεργάζονται: ο HPA μπορεί να προσθέσει Pods μόνο αν υπάρχει χώρος, και ο CA παρέχει αυτόν τον χώρο. Η κατανόηση του control loop του HPA — του τύπου `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, της περιοδικής εναρμόνισης, και των stabilization windows που αποτρέπουν το flapping — σου επιτρέπει να τον ρυθμίζεις και να τον κάνεις debug αντί να τον αντιμετωπίζεις σαν μαγεία. Οι επιφυλάξεις είναι εκεί που φαίνεται η κρίση του senior: ο HPA σε CPU/memory **απαιτεί metrics-server** και υπολογίζει το utilization **σε σχέση με τα requests**, οπότε λανθασμένα ή απόντα requests καθιστούν τα μαθηματικά του άσκοπα· τα custom metrics (requests-per-second, βάθος ουράς) χρειάζονται έναν adapter όπως το Prometheus Adapter ή το KEDA· και το scale-up των nodes παίρνει λεπτά, οπότε το περιθώριο (headroom) μετράει. Επειδή το σωστό μέγεθος χωρητικότητας επηρεάζει άμεσα την αξιοπιστία σε αιχμές κίνησης και το κόστος cloud σε ήσυχες περιόδους, και επειδή και οι δύο autoscalers εξαρτώνται από σωστά ορισμένα resource requests, η κατάκτηση του HPA και του Cluster Autoscaler είναι θεμελιώδης για να λειτουργείς production Kubernetes αποδοτικά και αξιόπιστα.

Δύο autoscalers, δύο επίπεδα

Πώς λειτουργεί το control loop του HPA

Ένα manifest HPA

Σημαντικές εξαρτήσεις & επιφυλάξεις

Γιατί έχει σημασία

Σχετικές ερωτήσεις