Generator Kubernetes ResourceQuota

Generator Kubernetes ResourceQuota i LimitRange

Kubernetes ResourceQuota ogranicza łączne zasoby całego namespace: sumę requests i limits CPU oraz pamięci, liczbę podów, PVC i wybranych obiektów. LimitRange działa na pojedynczy kontener i wstawia mu domyślne requests i limits, gdy pod ich nie deklaruje. Generator buduje oba manifesty w jednym pliku YAML, sprawdza spójność wartości i liczy, ile podów z domyślnymi ustawieniami faktycznie zmieści się w quocie.

ResourceQuota kontra LimitRange

Co trafia do manifestu YAML

Plik zawiera dwa dokumenty rozdzielone ---: ResourceQuota o nazwie <namespace>-quota i LimitRange o nazwie <namespace>-limits. LimitRange dodajesz lub pomijasz jednym polem wyboru. Nazwa namespace musi spełniać regułę DNS-1123: małe litery, cyfry i myślniki, najwyżej 63 znaki.

CPU podajesz w rdzeniach (4, 0.5) albo milirdzeniach (500m), pamięć jako liczbę całkowitą z jednostką Mi, Gi lub Ti. Jednostki dziesiętne G i M nie są przyjmowane, bo 1G to tylko około 0,93Gi i łatwo o pomyłkę. LimitRange dostaje sekcje default, defaultRequest i max dla typu Container. Gotowe zestawy Mały (2/4 vCPU, 10 podów), Średni (4/8 vCPU, 20 podów) i Duży (16/32 vCPU, 100 podów) wypełniają główne limity jednym kliknięciem. Wynik kopiujesz albo pobierasz jako resourcequota-<namespace>.yaml, a obok dostajesz polecenia kubectl do wdrożenia i sprawdzenia zużycia.

Dlaczego to ważne

• chroni klaster przed wyczerpaniem zasobów przez jeden namespace,
• wymusza deklarowanie requestów i limitów,
• pozwala sprawiedliwie dzielić zasoby między zespoły.

Jak działa quota w Kubernetes i co sprawdza generator

ResourceQuota działa na poziomie namespace i jest sprawdzana przez kontroler admission w momencie tworzenia lub aktualizacji poda. API server sumuje deklaracje wszystkich podów w namespace i porównuje je z wartościami hard. Jeśli suma przekroczy którąkolwiek z granic, operacja jest odrzucana. Mechanizm można zapisać wzorem: suma requests.cpu wszystkich podów ≤ hard.requests.cpu, suma limits.cpu ≤ hard.limits.cpu, liczba podów ≤ hard.pods. Analogicznie dla pamięci i pozostałych kluczy.

LimitRange działa na poziomie pojedynczego kontenera. Przy przyjęciu poda kontroler wstawia domyślne wartości, jeśli kontener ich nie zadeklarował, i odrzuca kontener większy niż max. W ustawieniach startowych kontener bez własnych wartości dostaje request 250m CPU i 256Mi pamięci oraz limit 500m CPU i 512Mi. Te liczby wliczają się potem do sum w ResourceQuota. Gdy LimitRange ma tylko default bez defaultRequest, Kubernetes przyjmuje request równy limitowi.

Generator nie łączy się z klastrem, ale pilnuje arytmetyki. Zablokuje wynik, jeśli w LimitRange domyślny request przekracza domyślny limit albo limit przekracza maksimum na kontener. Ostrzeże, gdy requests w quocie są wyższe niż limits, gdy maksymalny kontener nie zmieści się w limits całego namespace i gdy limit podów jest nieosiągalny przy wartościach domyślnych. Bez LimitRange przypomni, że pod bez requests i limits zostanie odrzucony przez quotę. Kafelki pokazują też średni przydział na pod (limits ÷ maks. pody) i stosunek limits do requests.

Przykład krok po kroku: ile podów zmieści się w quocie

1. W namespace production tworzysz ResourceQuota z wartościami hard: requests.cpu: "4", requests.memory: 8Gi, limits.cpu: "8", limits.memory: 16Gi, pods: "20" i persistentvolumeclaims: "10".
2. Dodajesz LimitRange z defaultRequest 250m CPU i 256Mi, default 500m CPU i 512Mi oraz max 2 CPU i 2Gi. Każdy kontener bez deklaracji zabiera 0,25 CPU z puli requests.cpu i 0,5 CPU z puli limits.cpu.
3. Generator dzieli każdy z czterech progów przez wartość jednego kontenera: requests.cpu 4000m ÷ 250m = 16, limits.cpu 8000m ÷ 500m = 16, requests.memory 8192Mi ÷ 256Mi = 32, limits.memory 16384Mi ÷ 512Mi = 32. Decyduje najmniejszy wynik, czyli 16.
4. Wdrażasz 16 podów po jednym kontenerze. Suma requests.cpu wynosi 16 × 250m = 4000m, czyli równo 4 CPU, a suma limits.cpu 16 × 500m = 8 CPU. Obie są równe wartościom hard, więc quota przepuszcza.
5. Siedemnasty pod podniósłby sumy do 4250m requests i 8500m limits, więc API server go odrzuci, choć limit 20 podów nie został osiągnięty. Generator pokazuje to w uwagach: zmieści się 16 podów, wcześniej skończy się limits.cpu.
6. Aby przyjąć 20 podów, podnieś quotę do requests.cpu 5 i limits.cpu 10 (5000m ÷ 250m = 20, 10000m ÷ 500m = 20) albo zmniejsz domyślne wartości kontenera do 200m request i 400m limit (4 CPU ÷ 20 i 8 CPU ÷ 20). Limit kontenera nadal musi być większy lub równy jego requestowi.

ResourceQuota i LimitRange – dane referencyjne z przykładu

Praktyczne wskazówki przed wdrożeniem quota

• Najpierw policz budżet zespołu: ile CPU i pamięci ma przypadać na namespace. Dopiero potem wpisz wartości do ResourceQuota. Limitów z innego środowiska nie kopiuj bez przeliczenia.
• Ustawiaj LimitRange razem z ResourceQuota. Sam LimitRange nie ograniczy sumy w namespace, a sama quota nie wstawi wartości do kontenerów, które ich nie mają.
• Regularnie porównuj zużycie z wartościami hard. Zbliżanie się do limitu requests.cpu lub limits.cpu oznacza, że kolejne wdrożenia mogą być odrzucane.
• Quota ustawiona równo z obecnym zużyciem nie zmieści rolloutów ani dodatkowych replik, bo przy rolling update stare i nowe pody liczą się jednocześnie. Zostaw zapas.
• Testuj politykę na stagingu. Sprawdź, czy domyślne wartości z LimitRange nie powodują przekroczenia quoty przy typowej liczbie podów, i dopiero potem przenieś YAML na produkcję.

Czego nie uwzględnia generator

• Pojemność klastra: ResourceQuota to limit logiczny w namespace, a nie gwarancja, że węzły mają tyle CPU i pamięci. Scheduler może nie umieścić poda nawet przy niewykorzystanej quocie.
• Rzeczywiste zużycie: narzędzie pracuje na deklaracjach. Nie zna metryk i nie podpowie, czy wartość hard pasuje do realnego profilu aplikacji.
• Kilka kontenerów w podzie: wyliczenie „pody z domyślnym LimitRange” zakłada jeden kontener na pod. Sidecar dostaje własne wartości domyślne, więc pod z dwoma kontenerami zużywa dwa razy więcej, a init containers również wpływają na efektywny request poda.
• Autoskalowanie: HPA tworzy nowe pody pod obciążeniem. W szczycie liczba replik rośnie i może wyczerpać quotę, czego statyczny manifest nie przewidzi.