www.czarnaowca.it
ResourceQuota to jedno z kluczowych narzędzi w Kubernetes, które pozwala administratorom na kontrolowanie i zarządzanie zużyciem zasobów w klastrze.
Dzisiaj miałem sytuację. Kolega (inny administrator) napisał do mnie z pytaniem. Nie działało nam jedno z narzędzi wykorzystywanych do wdrażania aplikacji. Całkowicie znikły wszystkie pody.
Przyczyną problemu była nadgorliwość programisty na klastrze deweloperskim i jego zbyt duże uprawnienia. Otóż testując ResourceQuota, uruchomił je na każdym z Namespace. Zrobił to również w namespace dla kube-system i innych. Te nie powinny mieć limitów. ResourceQuota nadawało zbyt małe limity. Wszystko działało przez kilka tygodni, ale w końcu nadszedł ten dzień – aktualizacja klastra. Podczas aktualizacji, standardowo pody były z node’a usuwane i powinny wstać na innym node. Tak się nie działo, z powodu zbyt niskich limitów ResourceQuota. Zdarza się, ale skoro to takie upierdliwe, by to stosować, to po co jest stosować?
Dlaczego powstało ResourceQuota?
ResourceQuota zostało wprowadzone, aby rozwiązać problem nierównomiernego zużycia zasobów w klastrze Kubernetes. W środowiskach, gdzie wiele zespołów lub użytkowników współdzieli klaster, istnieje ryzyko. Jeden zespół może zużywać więcej zasobów niż mu przysługuje. To może prowadzić do problemów z wydajnością i stabilnością całego systemu.
ResourceQuota pozwala na ograniczenie zużycia zasobów na poziomie namespace, co zapewnia sprawiedliwy podział zasobów między różne zespoły i aplikacje
Od której wersji Kubernetes jest dostępne ResourceQuota?
ResourceQuota jest dostępne od wersji Kubernetes 1.2, która została wydana w marcu 2016 roku. Od tego czasu funkcjonalność ta była stopniowo rozwijana i ulepszana, aby lepiej odpowiadać na potrzeby użytkowników i administratorów Kubernetes.
Jak wykorzystywać ResourceQuota?
Tworzymy namespace:
kubectl create namespace psujemyNastępnie musimy zdefiniować ResourceQuota:
apiVersion: v1 kind: ResourceQuota metadata: name: limitujprogramiste namespace: psujemy spec: hard: pods: "2" requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2GiOczywiście wdrożymy: kubectl apply -f resourcequota.yaml i warto sprawdzić, czy jest ok: kubectl get resourcequota -n psujemy
Od tego momentu założyliśmy kaganiec, który nikt nie przekroczy.
W momencie, gdy będzie uruchamiany pod z naszą aplikacją, będzie musiał mieć przydzielone zasoby w .spec.resources i będą one musiały się mieścić w naszym „budżecie”. jeżeli budżet zostanie przekroczony (czyli przydział będzie większy niż zaplanowany) to pod nie zostanie nigdy utworzony.
Alternatywne rozwiązania
Kubernetes jest tak bogatym środowiskiem, iż na wszystko mamy alternatywne rozwiązania. Wbudowane rozwiązania są następujące:
- LimitRange: Pozwala na definiowanie limitów zasobów na poziomie pojedynczych kontenerów w namespace. Można go używać w połączeniu z ResourceQuota, aby zapewnić bardziej szczegółową kontrolę nad zużyciem zasobów.
- PodDisruptionBudget (PDB): Służy do określania minimalnej liczby podów, które muszą być dostępne podczas operacji konserwacyjnych, takich jak aktualizacje lub skalowanie.
- Vertical Pod Autoscaler (VPA): Automatycznie dostosowuje zasoby przydzielone do podów na podstawie ich rzeczywistego zużycia.
- Horizontal Pod Autoscaler (HPA): Automatycznie skaluje liczbę podów w zależności od obciążenia.
Każde z powyższych rozwiązań ma nieco inne zastosowanie, inny cel i trzeba je stosować zgodnie z realnymi potrzebami. Dodatkowo są jeszcze zewnętrzne rozwiązania zarządzania zasobami, więc przy odrobinie chęci – da się zrobić wszystko.
Podsumowanie
Administrator ma na głowie bardzo dużo tematów, takie jak stworzenie odpowiedniego środowiska, ale i pilnowanie wszystkiego, by działało poprawnie. Mamy do tego świetne możliwości i powinniśmy je stosować.
Więcej o rozwiązaniu znajdziesz w oficjalnej dokumentacji: https://kubernetes.io/docs/concepts/policy/resource-quotas/
Jeśli masz pytania, zadaj je w komentarzu, na moim Discord lub w wiadomości na social mediach.
