Generator Kubernetes HPA

Generator HorizontalPodAutoscaler

HPA automatycznie zwiększa i zmniejsza liczbę podów w zależności od obciążenia. Dzięki temu aplikacja radzi sobie ze wzrostem ruchu bez ręcznej ingerencji.

Jak to działa?

Przykład

HPA dla Deploymentu web utrzymuje 2–10 podów i skaluje, gdy średnie zużycie CPU przekroczy 70%. Przy większym ruchu dochodzą nowe repliki.

Wymagania

• Zainstalowany metrics-server w klastrze.
• Deployment z sekcją resources.requests (bez niej procenty są nieobliczalne).
• Kontener wspierający bezpieczne skalowanie poziome.

Jak działa HPA — pętla kontrolna i wzór na liczbę replik

HPA nie reaguje na pojedynczy odczyt, lecz pracuje w pętli kontrolnej: w regularnych odstępach pobiera metryki z metrics-servera, porównuje je z wartościami zadeklarowanymi w sekcji metrics i wylicza docelową liczbę podów. Najprostszy wskaźnik to średnie zużycie CPU odniesione do wartości z resources.requests kontenerów. Jeśli średnie zużycie wynosi dokładnie tyle, ile próg (w przykładzie 70%), współczynnik wynosi 1,0 i liczba replik się nie zmienia.

Wzór, którym posługuje się kontroler, sprowadza się do iloczynu: docelowa liczba replik = bieżąca liczba replik razy (bieżąca wartość metryki podzielona przez wartość progową), a wynik jest zaokrąglany w górę do liczby całkowitej. Potem następuje przycięcie do widełek: nigdy poniżej minReplicas i nigdy powyżej maxReplicas. Przy minReplicas 2 i maxReplicas 10 oraz progu 70% CPU każdy wariant pośredni, na przykład 6 albo 8 podów, jest wynikiem tego samego działania.

Kontroler nie skacze od razu do wyniku — nanosi zmiany stopniowo i stosuje tolerancję, dzięki której drobne wahania metryki nie powodują ciągłego dodawania i usuwania replik. Z tego samego powodu warto konfigurować sekcję behavior: to ona decyduje, jak szybko HPA może zwiększać i zmniejszać liczbę podów w reakcji na kolejne odczyty.

Przykład krok po kroku: Deployment web, widełki 2–10, próg 70% CPU

1. Tworzysz HPA w wersji autoscaling/v2 wskazujący przez scaleTargetRef na Deployment web, ustawiasz minReplicas na 2, maxReplicas na 10, a w metrics wpisujesz średnie zużycie CPU na poziomie 70%.
2. HPA pobiera metryki z metrics-servera i liczy średnie zużycie CPU kontenerów w stosunku do wartości z sekcji resources.requests.
3. Stan spoczynkowy: działają 2 repliki, a średnie zużycie wynosi dokładnie 70%, czyli współczynnik to 1,0. Działanie: 2 razy 1,0 = 2, więc liczba podów pozostaje bez zmian.
4. Wzrost ruchu: średnie zużycie rośnie do 140%, czyli dwa razy powyżej progu — współczynnik 2,0. Działanie: 2 razy 2,0 = 4, więc HPA skaluje Deployment z 2 do 4 podów.
5. Dalszy wzrost: przy 4 replikach średnie zużycie sięga 210%, czyli trzech progów po 70%. Działanie: 4 razy 3 = 12, ale wynik przekracza maxReplicas, dlatego HPA zatrzymuje się na 10 podach.
6. Spadek ruchu: przy 10 replikach średnie zużycie spada do 35%, czyli połowy progu. Działanie: 10 razy 0,5 = 5, więc HPA redukuje liczbę podów do 5, a po dalszym spadku do poziomu minReplicas, czyli 2.

Pola manifestu HPA i ich znaczenie

Praktyczne wskazówki przy wdrażaniu HPA

• Zawsze definiuj resources.requests — bez nich procenty CPU są nieobliczalne, a HPA nie podejmie żadnej decyzji o skalowaniu.
• Ustaw maxReplicas z realnym zapasem klastra — HPA sam nie sprawdzi, czy w klastrze są wolne zasoby; zbyt wysoki limit skończy się podami w stanie Pending.
• Traktuj próg 70% jako punkt wyjścia — dla aplikacji o dużym narzucie startu lepiej sprawdza się niższy próg, żeby nowe repliki zdążyły się rozgrzać przed szczytem.
• Skonfiguruj sekcję behavior — okna stabilizacji ograniczają gwałtowne skoki liczby replik przy krótkich wahaniach ruchu.
• Sprawdzaj działanie po wdrożeniu — polecenie kubectl describe hpa pokazuje bieżące metryki, zdarzenia i powody braku reakcji, a nie tylko samą liczbę replik.

Czego nie uwzględnia wygenerowany manifest

• Stanu klastra — generator tworzy poprawny zasób, ale nie sprawdza, czy metrics-server jest zainstalowany i czy klastrem zarządza node autoscaler.
• Rzeczywistego profilu obciążenia — próg z manifestu jest deklaracją; dopiero pomiary pokazują, przy jakim ruchu aplikacja faktycznie potrzebuje kolejnych replik.
• Zachowania aplikacji — czas startu kontenera, rozgrzewanie cache i nawiązywanie połączeń do bazy nie są modelowane, a to one często opóźniają efekt skalowania.
• Mechanizmów towarzyszących — quotas, limity zasobów, budżety PDB i kolejki zadań pozostają poza zakresem; HPA może chcieć więcej podów, niż dopuszczają te reguły.
• Konfliktu z VPA — jeśli Vertical Pod Autoscaler zmienia requests w tym samym czasie, punkt odniesienia dla procentów CPU przestaje być stabilny.

Najczęstsze pytania