Kaip veikia Horizontal Pod Autoscaler ir kaip jis susijęs su Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** prideda arba pašalina **Pod replikas** pagal stebimas metrikas (CPU, atmintį ar savas). **Cluster Autoscaler (CA)** prideda arba pašalina **node'us**, kai Pod'ai negali būti suplanuoti arba node'ai išnaudojami menkai. Jie veikia skirtinguose sluoksniuose ir dirba kartu.

## Du autoscaler'iai, du sluoksniai

```text
HPA  → keičia POD'Ų mastelį (daugiau/mažiau Deployment'o replikų)   — reaguoja į APKROVĄ
CA   → keičia NODE'Ų mastelį (didina/mažina klasterio mašinas)       — reaguoja į PENDING Pod'us
VPA  → (papildomai) koreguoja Pod'o requests/limits                  — reaguoja į dydžio parinkimą

Tipinis srautas: apkrova kyla → HPA prideda Pod'us → Pod'ai netelpa → CA prideda node →
              Pod'ai suplanuojami. Apkrova krenta → HPA pašalina Pod'us → node tuščias → CA jį pašalina.
```

## Kaip veikia HPA valdymo ciklas

```text
Kas ~15s HPA controller'is:
  1. nuskaito dabartinę metriką (pvz., vid. CPU per Pod'us) iš metrics-server / savo API
  2. apskaičiuoja:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. keičia Deployment'o mastelį link jos (ribojama minReplicas/maxReplicas)
Pavyzdys: 4 Pod'ai prie 80% CPU, tikslas 50% → 4 * 80/50 = 6,4 → 7 replikos.
Stabilizacijos langai slopina svyravimą (ypač mažinant).
```

## HPA manifest'as

```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      # laikyti vid. CPU ~60% nuo REQUEST
  behavior:                           # neprivaloma: derinti mastelio keitimo greitį
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # dabartinė/tikslinė metrika, replikų skaičius
kubectl top pods                      # reikalauja metrics-server
```

## Svarbios priklausomybės ir pastabos

```text
• HPA pagal CPU/atmintį REIKALAUJA įdiegto metrics-server; utilizacija skaičiuojama nuo REQUESTS
  → jei requests nenustatyti/klaidingi, HPA matematika beprasmė. Nustatykite requests teisingai.
• Savos/išorinės metrikos (RPS, eilės gylis) reikia adapterio (Prometheus Adapter, KEDA).
• HPA ir rankinis `replicas` konfliktuoja — leiskite HPA valdyti replikų skaičių.
• Cluster Autoscaler taip pat reikalauja teisingų requests: jis žiūri į Pending Pod'ų REQUESTS,
  kad nuspręstų node mastelį. Node padidinimas trunka minutes (provisioning), tad laikykite atsargą.
```

## Kodėl tai svarbu

Autoscaling yra tai, kas leidžia Kubernetes automatiškai derinti pajėgumą prie paklausos, o dviejų sluoksnių supratimas yra senior-lygio žinia, skirianti sąnaudoms efektyvius, atsparius klasterius nuo per- ar nepakankamai provisioninamų. Pagrindinis mąstymo modelis — kad **HPA keičia Pod'ų mastelį** reaguodamas į apkrovą (koreguodamas replikų skaičių pagal stebimą CPU, atmintį ar savas metrikas), o **Cluster Autoscaler keičia node'ų mastelį** reaguodamas į scheduling spaudimą (pridedamas mašinas, kai Pod'ai Pending, pašalindamas jas, kai node'ai tušti) — jie veikia skirtinguose sluoksniuose ir bendradarbiauja: HPA gali pridėti Pod'us tik jei yra vietos, o CA tą vietą suteikia. HPA valdymo ciklo supratimas — `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)` formulė, periodinis derinimas ir stabilizacijos langai, apsaugantys nuo svyravimo — leidžia jį sukonfigūruoti ir ištaisyti, o ne laikyti magija. Pastabose ir pasireiškia senior sprendimas: HPA pagal CPU/atmintį **reikalauja metrics-server** ir skaičiuoja utilizaciją **nuo requests**, tad neteisingi ar trūkstami requests jo matematiką paverčia beprasme; savoms metrikoms (užklausų per sekundę, eilės gyliui) reikia adapterio kaip Prometheus Adapter ar KEDA; o node padidinimas trunka minutes, tad svarbi atsarga. Kadangi teisingas pajėgumo dydžio parinkimas tiesiogiai veikia patikimumą per srauto šuolius ir cloud išlaidas ramiais laikotarpiais, o abu autoscaler'iai priklauso nuo teisingai nustatytų resource requests, HPA ir Cluster Autoscaler įvaldymas yra pamatinis efektyviai ir patikimai eksploatuoti production Kubernetes.

Du autoscaler'iai, du sluoksniai

Kaip veikia HPA valdymo ciklas

HPA manifest'as

Svarbios priklausomybės ir pastabos

Kodėl tai svarbu

Susiję klausimai