Generator Kubernetes PDB (PodDisruptionBudget)

Generator PodDisruptionBudget

PodDisruptionBudget (PDB) chroni dostępność aplikacji w Kubernetes podczas dobrowolnych przerw — drainowania i aktualizacji węzłów albo usuwania węzłów przez autoskaler klastra. Określa, ile podów musi pozostać działających. Generator składa gotowy manifest YAML i od razu liczy, ile podów da się wyłączyć naraz przy podanej liczbie replik.

minAvailable a maxUnavailable

Wartości mogą być liczbą (np. 2) lub procentem (np. 50%). Generator przyjmuje liczbę całkowitą od 1 albo procent od 1% do 100%. Zera nie przyjmuje: minAvailable: 0 niczego nie chroni, a maxUnavailable: 0 blokuje każdą eksmisję.

Przykład manifestu PDB w YAML

Wynik dla domyślnych ustawień formularza:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
  namespace: default
spec:
  minAvailable: 1
  unhealthyPodEvictionPolicy: IfHealthyBudget
  selector:
    matchLabels:
      app: myapp

Pod manifestem narzędzie podaje polecenia kubectl apply -f app-pdb.yaml i kubectl get pdb app-pdb -n default. Wartości etykiet, które YAML odczytałby jako liczbę lub wartość logiczną (np. 2, true, yes), trafiają do pliku w cudzysłowie, bo matchLabels przyjmuje wyłącznie tekst.

Kiedy stosować PDB?

• bazy danych i systemy wymagające kworum,
• usługi o wysokich wymaganiach dostępności (SLA),
• aplikacje obsługujące ruch produkcyjny 24/7,
• klastrowane komponenty (np. Kafka, Elasticsearch).

unhealthyPodEvictionPolicy

Pole decyduje, co zrobić z podami, które działają (faza Running), ale nie przechodzą sondy gotowości. IfHealthyBudget to zachowanie domyślne: taki pod można usunąć tylko wtedy, gdy aplikacja ma już tyle zdrowych podów, ile wymaga budżet. Wartość AlwaysAllow pozwala usuwać niegotowe pody mimo budżetu — zapobiega blokowaniu aktualizacji przez zawieszone instancje, ale podczas awarii może dodatkowo obniżyć dostępność. Generator domyślnie wpisuje IfHealthyBudget, a AlwaysAllow ustawisz w opcjach zaawansowanych. Pole jest w wersji beta od Kubernetes 1.27 i stabilne od 1.31, więc na starszym klastrze sprawdź, czy jest obsługiwane.

Jak działa generator i sam mechanizm budżetu

Generator składa manifest YAML z danych, które wpiszesz w formularzu: nazwy obiektu i namespace, selektora etykiet oraz jednego z dwóch pól budżetu. Nazwy sprawdza według reguł Kubernetes (małe litery, cyfry i myślniki, do 63 znaków), a klucz etykiety może mieć prefiks, np. app.kubernetes.io/name. Wynikiem jest obiekt PodDisruptionBudget z grupy policy/v1, który nie tworzy i nie kontroluje podów, tylko informuje klaster, ile podów pasujących do selektora może zniknąć w wyniku operacji dobrowolnej. Zmniejszenie liczby replik Deploymentu i rolling update usuwają pody bez sprawdzania PDB.

Mechanizm opiera się na API Eviction. Narzędzie takie jak kubectl drain nie usuwa podów bezpośrednio, lecz wysyła dla każdego z nich żądanie eksmisji. API sprawdza bieżący stan: ile podów z selektora jest gotowych i zdrowych, a potem porównuje wynik z budżetem. Jeśli eksmisja zeszłaby poniżej minAvailable albo przekroczyła maxUnavailable, żądanie zostaje odrzucone (kod HTTP 429), a klient ponawia próbę. Drain czeka wtedy, aż budżet pozwoli.

W jednym spec podaje się tylko jedno z dwóch pól budżetu — minAvailable i maxUnavailable wykluczają się wzajemnie. Procenty przelicza kontroler klastra na podstawie liczby replik oczekiwanej przez Deployment, StatefulSet lub ReplicaSet i w obu trybach zaokrągla wynik w górę do pełnego poda. Generator stosuje ten sam wzór, gdy wpiszesz liczbę replik, i pokazuje minimum działających podów oraz liczbę podów do wyłączenia naraz.

Przykład krok po kroku: cztery repliki, minAvailable 2

1. Zakładamy aplikację działającą w 4 replikach, której pody mają etykietę app: myapp.
2. W selektorze wpisujesz klucz app i wartość myapp — dokładnie ten sam zestaw etykiet, który noszą pody. Jeśli etykieta się nie zgadza, budżet nie obejmie żadnego poda i niczego nie zabezpieczy.
3. Ustawiasz minAvailable: 2. Oznacza to, że w każdej chwili co najmniej 2 z 4 podów muszą pozostać dostępne.
4. Z tego wynika górna granica dobrowolnych przerw przy pełnej obsadzie: 4 − 2 = 2 pody. Tyle może zniknąć jednorazowo.
5. Jeśli jeden pod jest już niedostępny (trwa restart albo rolling update), dostępne są 3 pody, więc budżet pozwala usunąć tylko 3 − 2 = 1 pod.
6. Ten sam efekt daje maxUnavailable: 2 przy 4 replikach — dopuszczalne są 2 niedostępne pody, czyli wymagane pozostają 4 − 2 = 2 działające. W manifeście wybierasz jedno z tych pól, nigdy oba naraz.

Skutek dla drainowania: węzeł z dwoma podami tej aplikacji opróżni się bez oporu, ale trzecie żądanie eksmisji zostanie odrzucone i operacja poczeka, aż usunięte pody wstaną na innych węzłach. Przy 3 replikach i wartości 50% przeliczenie jest mniej oczywiste: 50% z 3 to 1,5, a Kubernetes zaokrągla w górę do 2. Dla minAvailable daje to 2 wymagane pody i 1 do wyłączenia naraz, dla maxUnavailable odwrotnie: 2 do wyłączenia i 1 wymagany.

Typowe ustawienia PDB przy 1–5 replikach

W każdej komórce pierwsza liczba to minimum działających podów, druga to liczba podów, które można wyłączyć jednocześnie, przy założeniu, że wszystkie pody są gotowe. Wartości policzono tym samym wzorem, którego używa generator.

Zero po ukośniku oznacza, że drain zostanie zablokowany. Przy jednej replice każdy maxUnavailable pozwala wyłączyć jedyny pod, więc budżet nie daje wtedy żadnej ochrony.

Pola manifestu i ich znaczenie

Jak używać generatora w praktyce

• Skopiuj selektor z Deploymentu — etykiety w matchLabels muszą być identyczne z tymi na podach, a namespace PDB taki sam jak namespace aplikacji.
• Wybierz jedno pole budżetu i trzymaj się konwencji: albo opisujesz stan wymagany (minAvailable), albo tolerancję na przerwy (maxUnavailable). Gotowe przyciski w formularzu ustawiają cztery częste warianty: minAvailable 1, kworum 2, maksymalnie 1 niedostępny i połowę niedostępną.
• Licz wartości od docelowej liczby replik i wpisz ją w pole „Liczba replik”. Narzędzie ostrzeże, gdy budżet nie pozwala wyłączyć żadnego poda (drain stanie) albo pozwala wyłączyć wszystkie (brak ochrony), a tabela pod wynikiem pokaże ten sam budżet dla 1–10 replik.
• Przetestuj manifest przez drain węzła w środowisku testowym. Po wdrożeniu kubectl get pdb pokaże w kolumnie ALLOWED DISRUPTIONS, ile podów klaster faktycznie pozwala wyłączyć; 0 przy działających replikach zwykle oznacza zły selektor albo zbyt ostry budżet.

Czego narzędzie nie sprawdza

• Nie weryfikuje selektora względem klastra — generator wypisuje wpisane dane, nie wie, czy etykieta app: myapp istnieje na jakimkolwiek podzie ani czy pokrywa właściwe obciążenie.
• Nie zna bieżącego stanu podów — wyliczenie zakłada, że wszystkie wpisane repliki są gotowe. Klaster liczy budżet w chwili eksmisji, więc przy podach w trakcie restartu dopuszczalnych przerw będzie mniej.
• Nie chroni przed przerwami niedobrowolnymi — awaria węzła, brak pamięci czy zabicie procesu omijają budżet całkowicie. PDB nie jest mechanizmem wysokiej dostępności samym w sobie.
• Nie wykrywa konfliktów między budżetami — kilka obiektów PDB obejmujących te same pody może wzajemnie blokować drainowanie, a narzędzie tego nie zasygnalizuje.