Programowanie Full-Stack w Chmurze Obliczeniowej
dr inż. Sławomir Wojciech Przyłucki
Termin zajęć:
środa, godz. 11:30,
Imię i nazwisko:
Paweł Pieczykolan,
II rok studiów magisterskich, WOiSI 2.3,
W zadaniu utworzono dwie przestrzenie nazw K8s z kontrolą zasobów: ns-dev o ograniczonych limitach oraz ns-prod z dwukrotnie większą pulą CPU i RAM. Zweryfikowano działanie Podów nginx spełniających oraz przekraczających limity, potwierdzając poprawność konfiguracji przedziałów zasobów.
Zadanie zostało zrealizowano na maszynie wirtualnej na której działał system Ubuntu 24.04 LTS.
W pierwszym etapie zadania utworzone zostały dwie przestrzenie nazw: ns-dev dla środowiska deweloperskiego oraz ns-prod dla środowiska produkcyjnego.
Rys. 1. Utworzenie wymaganych przestrzeni nazw
W środowisku ns-dev ograniczono zasoby do 1 rdzenia CPU i 1024 megabitów pamięci RAM maksymalnie oraz 10 POD-ów. W środowisku ns-prod zasoby (CPU, RAM) zostały ustawione na dwukrotność wartości z ns-dev. Dodatkowo przygotowano obiekt LimitRange z pliku limitrange.yaml, który wymusza limity dla Podów uruchamianych bez zdefiniowanych żądań i limitów zasobów.
Rys. 2. Utworzenie obiektów Quota oraz LimitRange ograniczających zasoby dla przestrzeni nazw
Obiekt typu LimitRange o nazwie `memlimits` dla przestrzeni nazw ns-dev definiuje limity zasobów dla kontenerów w następujący sposób:
- default – domyślny limit, czyli ile kontener może maksymalnie używać, jeśli nie poda własnego limitu: 100m CPU i 128Mi pamięci.
- defaultRequest – domyślne żądanie zasobów, czyli ile kontener dostanie gwarantowane, jeśli nie poda własnego request: 100m CPU i 128Mi pamięci.
- max – maksymalny limit, czyli górna granica zasobów możliwych do przydzielenia kontenerowi: 200m CPU i 256Mi pamięci.
Rys. 3. Zawartość pliku limitrange.yaml
Utworzono obiekt Deployment o nazwie no-test w przestrzeni nazw ns-dev na bazie obrazu nginx. Deployment został celowo skonfigurowany tak, aby przekraczał ustalone limity zasobów CPU i pamięci. Celem tego działania było sprawdzenie, czy wprowadzone ograniczenia w ramach LimitRange i ResourceQuota skutecznie blokują uruchamianie kontenerów, które próbują wykorzystać więcej zasobów, niż zostało przydzielone. Dzięki temu można zweryfikować, że mechanizmy kontroli zasobów w Kubernetes działają zgodnie z oczekiwaniami.
Rys. 4. Zawartość pliku no-test.yaml
Po uruchomieniu Deploymentu sprawdzono jego status. Ze względu na przekroczenie limitów CPU i pamięci, Pod-y nie mogły zostać uruchomione poprawnie. W logach i wynikach komend widać było błędy dotyczące braku możliwości przydzielenia żądanych zasobów. To zachowanie potwierdziło skuteczność konfiguracji LimitRange i ResourceQuota, a także pokazało, że Kubernetes efektywnie chroni środowisko przed nadmiernym zużyciem zasobów w przestrzeni ns-dev.
Rys. 5. Uruchomienie Deploymentu no-test
Po wydaniu polecenia uruchamiającego Deployment widać było, że Pod-y nie mogą zostać uruchomione. Kontenery próbowały zużyć więcej CPU i pamięci, niż pozwalały na to limity zdefiniowane w LimitRange oraz ResourceQuota. Ten etap pozwolił zweryfikować, że mechanizm kontroli zasobów skutecznie blokuje uruchomienie nieprawidłowo skonfigurowanych kontenerów i chroni środowisko przed nadmiernym obciążeniem.
Rys. 6. Przekroczenie limitu kontenera w deploymencie no-test
Kolejnym krokiem było utworzenie Deploymentu yes-test, który spełniał wszystkie wymagania dotyczące wykorzystania zasobów CPU i pamięci. Deployment ten miał na celu pokazanie, że Pod-y mieszczące się w zadeklarowanych limitach uruchamiają się poprawnie i działają stabilnie w przestrzeni ns-dev.
Rys. 7. Zawartość pliku yes-test.yaml
W trakcie uruchamiania sprawdzano status Pod-ów, aby upewnić się, że działają poprawnie.
Rys. 8. Uruchomienie Deploymentu yes-test
W kolejnym kroku użyto polecenia kubectl describe, aby szczegółowo zweryfikować przydzielone żądania i limity zasobów dla każdego Poda.
Rys. 9. Wynik polecenia describe dla yes-test
Ostatnim testem był Deployment zero-test, który nie posiadał deklaracji żądań i limitów zasobów. Celem było sprawdzenie, czy obiekt LimitRange automatycznie przypisuje domyślne wartości do Pod-ów uruchamianych bez własnych deklaracji. Test ten pozwala upewnić się, że nawet w przypadku braku jawnych wartości zasoby są kontrolowane i mieszczą się w przyjętych granicach, co zwiększa stabilność środowiska.
Rys. 10. Zawartość pliku zero-test.yaml
Deployment został uruchomiony w przestrzeni ns-dev przy użyciu polecenia kubectl apply -f zero-test.yaml. Po jego uruchomieniu sprawdzono status Pod-ów oraz ich przydzielone zasoby. Dzięki LimitRange, każdy kontener otrzymał domyślne wartości CPU i pamięci, nawet jeśli nie zostały one jawnie zadeklarowane w pliku YAML. To pozwoliło upewnić się, że mechanizm automatycznego przydzielania zasobów działa zgodnie z założeniami i chroni środowisko przed niekontrolowanym zużyciem zasobów.
Rys. 11. Uruchomienie Deploymentu zero-test
Opis Deploymentu potwierdził, że Pod-y zostały poprawnie uruchomione. Dodatkowo sprawdzono szczegóły pojedynczego Poda, aby zweryfikować, że przydział domyślnych wartości CPU i pamięci jest prawidłowy, co zapewnia bezpieczeństwo i przewidywalność środowiska.
Rys. 12. Wynik polecenia describe dla zero-test
Szczegółowe sprawdzenie pojedynczego Poda pokazało, że domyślne wartości CPU i pamięci zostały poprawnie przypisane zgodnie z LimitRange, co potwierdza skuteczność mechanizmu automatycznego przydzielania zasobów w przestrzeni ns-dev.
Rys. 13. Wynik polecenia describe dla Poda zero-test
W ramach zadania utworzono dwie przestrzenie nazw K8s: ns-dev i ns-prod, z różnymi limitami zasobów. W przestrzeni ns-dev ograniczono liczbę Pod-ów oraz maksymalne zużycie CPU i pamięci. Przestrzeń nazw ns-prod posiadała dwukrotnie większe zasoby. Przeprowadzone testy Deploymentów ns-dev pokazały, że: Deployment przekraczający limity no-test nie uruchomił się poprawnie, Deployment spełniający limity yes-test działał stabilnie, a Deployment bez deklaracji limitów zero-test działał poprawnie oraz otrzymał domyślne wartości zasobów. Zadanie potwierdziło skuteczność konfiguracji ResourceQuota i LimitRange oraz prawidłowe działanie mechanizmów kontroli zasobów w Kubernetes.