Jak działa Horizontal Pod Autoscaler i jak wiąże się z Cluster Autoscalerem?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** dodaje lub usuwa **repliki Podów** na podstawie obserwowanych metryk (CPU, pamięć lub własne). **Cluster Autoscaler (CA)** dodaje lub usuwa **nody**, gdy Pody nie mogą zostać zaplanowane lub nody są niedostatecznie wykorzystane. Działają na różnych warstwach i współpracują.

## Dwa autoskalery, dwie warstwy

```text
HPA  → skaluje PODY  (więcej/mniej replik Deploymentu)         — reaguje na OBCIĄŻENIE
CA   → skaluje NODY  (rośnie/kurczy maszyny klastra)           — reaguje na PENDING Pody
VPA  → (bonus) dostraja requesty/limity Poda                   — reaguje na dobór rozmiaru

Typowy przepływ: obciążenie rośnie → HPA dodaje Pody → Pody się nie mieszczą → CA dodaje node →
              Pody się planują. Obciążenie spada → HPA usuwa Pody → node bezczynny → CA go usuwa.
```

## Jak działa pętla sterująca HPA

```text
Co ~15s kontroler HPA:
  1. czyta bieżącą metrykę (np. średnie CPU po Podach) z metrics-server / custom API
  2. oblicza:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. skaluje Deployment ku temu (ograniczony przez minReplicas/maxReplicas)
Przykład: 4 Pody przy 80% CPU, cel 50% → 4 * 80/50 = 6,4 → 7 replik.
Okna stabilizacji tłumią miganie (zwł. przy skalowaniu w dół).
```

## 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      # utrzymuj śr. CPU ~60% REQUESTU
  behavior:                           # opcjonalnie: dostrój tempo skalowania w górę/dół
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # bieżąca/docelowa metryka, liczba replik
kubectl top pods                      # wymaga metrics-server
```

## Ważne zależności i zastrzeżenia

```text
• HPA na CPU/pamięci WYMAGA zainstalowanego metrics-server; wykorzystanie jest względem REQUESTÓW
  → jeśli requesty są nieustawione/błędne, matematyka HPA jest bezsensowna. Ustaw requesty poprawnie.
• Własne/zewnętrzne metryki (RPS, głębokość kolejki) potrzebują adaptera (Prometheus Adapter, KEDA).
• HPA i ręczne `replicas` kolidują — pozwól HPA być właścicielem liczby replik.
• Cluster Autoscaler też potrzebuje poprawnych requestów: patrzy na REQUESTY Podów w Pending, aby
  zdecydować o skalowaniu nodów. Skalowanie nodów w górę trwa minuty (provisioning), więc trzymaj zapas.
```

## Dlaczego to ważne

Autoskalowanie jest tym, co pozwala Kubernetes automatycznie dopasowywać pojemność do zapotrzebowania, a zrozumienie dwóch warstw to wiedza na poziomie senior, która odróżnia oszczędne kosztowo, odporne klastry od nad- lub niedoprowizjonowanych. Kluczowy model mentalny jest taki, że **HPA skaluje Pody** w odpowiedzi na obciążenie (dostrajając liczbę replik na podstawie obserwowanego CPU, pamięci lub własnych metryk), podczas gdy **Cluster Autoscaler skaluje nody** w odpowiedzi na presję schedulingu (dodając maszyny, gdy Pody są Pending, usuwając je, gdy nody są bezczynne) — działają na różnych warstwach i współpracują: HPA może dodać Pody tylko, jeśli jest miejsce, a CA to miejsce zapewnia. Zrozumienie pętli sterującej HPA — wzoru `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, okresowego uzgadniania i okien stabilizacji, które zapobiegają miganiu — pozwala go konfigurować i debugować, a nie traktować jak magię. Zastrzeżenia to miejsce, gdzie widać ocenę seniora: HPA na CPU/pamięci **wymaga metrics-server** i oblicza wykorzystanie **względem requestów**, więc błędne lub brakujące requesty czynią jego matematykę bezsensowną; własne metryki (żądania na sekundę, głębokość kolejki) potrzebują adaptera jak Prometheus Adapter lub KEDA; a skalowanie nodów w górę trwa minuty, więc zapas ma znaczenie. Ponieważ prawidłowy dobór pojemności wprost wpływa na niezawodność podczas skoków ruchu i wydatki chmurowe w okresach ciszy, a ponieważ oba autoskalery zależą od poprawnie ustawionych requestów zasobów, opanowanie HPA i Cluster Autoscalera jest fundamentalne dla wydajnej i niezawodnej obsługi produkcyjnego Kubernetesa.

Dwa autoskalery, dwie warstwy

Jak działa pętla sterująca HPA

Manifest HPA

Ważne zależności i zastrzeżenia

Dlaczego to ważne

Powiązane pytania