Cum funcționează Horizontal Pod Autoscaler și cum se raportează la Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** adaugă sau elimină **replici de Pod** pe baza metricilor observate (CPU, memorie sau custom). **Cluster Autoscaler (CA)** adaugă sau elimină **node-uri** când Pod-urile nu pot fi programate sau node-urile sunt subutilizate. Operează la niveluri diferite și lucrează împreună.

## Doi autoscalere, două niveluri

```text
HPA  → scalează POD-uri  (mai multe/mai puține replici ale unui Deployment)  — reacționează la SARCINĂ
CA   → scalează NODE-uri (crește/micșorează mașinile clusterului)            — reacționează la Pod-uri PENDING
VPA  → (bonus) ajustează requests/limits ale unui Pod                        — reacționează la dimensionare corectă

Flux tipic: sarcina crește → HPA adaugă Pod-uri → Pod-urile nu încap → CA adaugă un node →
              Pod-urile se programează. Sarcina scade → HPA elimină Pod-uri → node inactiv → CA îl elimină.
```

## Cum funcționează bucla de control HPA

```text
La fiecare ~15s controllerul HPA:
  1. citește metrica curentă (ex. CPU mediu pe Pod-uri) din metrics-server / API custom
  2. calculează:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. scalează Deployment-ul spre asta (mărginit de minReplicas/maxReplicas)
Exemplu: 4 Pod-uri la 80% CPU, target 50% → 4 * 80/50 = 6.4 → 7 replici.
Ferestrele de stabilizare atenuează oscilația (mai ales la scale-down).
```

## Un manifest de 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      # menține CPU mediu la ~60% din REQUEST
  behavior:                           # opțional: reglează viteza de scale up/down
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # metrica curentă/target, numărul de replici
kubectl top pods                      # necesită metrics-server
```

## Dependențe & avertismente importante

```text
• HPA pe CPU/memorie NECESITĂ metrics-server instalat; utilizarea e relativă la REQUESTS
  → dacă requests sunt nesetate/greșite, matematica HPA e lipsită de sens. Setează requests corect.
• Metricile custom/externe (RPS, adâncimea cozii) au nevoie de un adaptor (Prometheus Adapter, KEDA).
• HPA și `replicas` manual intră în conflict — lasă HPA să dețină numărul de replici.
• Cluster Autoscaler are nevoie și el de requests corecte: se uită la REQUESTS-urile Pod-urilor Pending pentru
  a decide scalarea node-urilor. Scale-up-ul de node durează minute (provizionare), deci păstrează rezervă.
```

## De ce contează

Autoscaling-ul este ceea ce permite Kubernetes să potrivească automat capacitatea cu cererea, iar înțelegerea celor două niveluri este cunoaștere de nivel senior care separă clusterele eficiente ca cost și reziliente de cele supra- sau sub-provizionate. Modelul mental cheie este că **HPA scalează Pod-uri** ca răspuns la sarcină (ajustând numărul de replici din CPU, memorie sau metrici custom observate), în timp ce **Cluster Autoscaler scalează node-uri** ca răspuns la presiunea de scheduling (adăugând mașini când Pod-urile sunt Pending, eliminându-le când node-urile sunt inactive) — operează la niveluri diferite și cooperează: HPA poate adăuga Pod-uri doar dacă e loc, iar CA oferă acel loc. Înțelegerea buclei de control a HPA — formula `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, reconcilierea periodică și ferestrele de stabilizare care previn oscilația — îți permite să-l configurezi și să-l depanezi în loc să-l tratezi ca magie. Avertismentele sunt locul unde se vede judecata de senior: HPA pe CPU/memorie **necesită metrics-server** și calculează utilizarea **relativ la requests**, deci requests incorecte sau lipsă îi fac matematica lipsită de sens; metricile custom (cereri-pe-secundă, adâncimea cozii) au nevoie de un adaptor precum Prometheus Adapter sau KEDA; iar scale-up-ul de node durează minute, deci rezerva contează. Deoarece dimensionarea corectă a capacității afectează direct fiabilitatea sub vârfuri de trafic și cheltuiala de cloud în perioadele liniștite, și deoarece ambele autoscalere depind de requests de resurse setate corect, stăpânirea HPA și a Cluster Autoscaler este fundamentală pentru a opera Kubernetes de producție eficient și fiabil.

Doi autoscalere, două niveluri

Cum funcționează bucla de control HPA

Un manifest de HPA

Dependențe & avertismente importante

De ce contează

Întrebări conexe