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 klaster Kubernetes w Minikube z czterema węzłami i wdrożono trzy komponenty: frontend, backend oraz Pod MySQL. Skonfigurowano odpowiednie usługi sieciowe, a następnie zastosowano politykę NetworkPolicy, która ograniczyła dostęp do bazy – tylko backend mógł łączyć się z bazą na porcie 3306.
Zadanie zostało zrealizowano na maszynie wirtualnej na której działał system Ubuntu 24.04 LTS.
Pierwszym krokiem było usunięcie poprzedniej konfiguracji Minikube oraz uruchomienie nowego klastra z czterema węzłami. Do tego celu użyto polecenia minikube start --nodes=4 --cni='calico' --driver=docker
Rys. 1. Utworzenie klastra Minikube z czterema węzłami
Po uruchomieniu klastra skonfigurowano węzeł główny (node1) oraz trzy węzły robocze (node2, node3, node4). Dzięki temu możliwe było późniejsze przypisanie zasobów do konkretnych węzłów.
Aby ułatwić zarządzanie zasobami, węzłom nadano aliasy A, B i C zgodnie z treścią zadania. Wykorzystano polecenia:
kubectl label node minikube-m02 node=A
kubectl label node minikube-m03 node=B
kubectl label node minikube-m04 node=C
Rys. 2. Nadanie aliasów A, B, C dla węzłów klastra
Dzięki temu możliwe było precyzyjne przypisanie deploymentów i Podów do wybranych węzłów.
W kolejnym etapie przygotowano deployment frontend, który składał się z trzech replik kontenera nginx. Deployment został przypisany do węzła A poprzez użycie nodeSelector.
Rys. 3. Plik konfiguracyjny frontend.yaml
Deployment frontend pełnił rolę warstwy prezentacji aplikacji i był wystawiony na zewnątrz klastra poprzez usługę typu NodePort.
Rys. 4. Utworzenie obiektu frontend typu deployment na węźle A
Następnie przygotowano deployment backend, który zawierał jedną replikę kontenera nginx. Deployment został przypisany do węzła B.
Rys. 5. Plik konfiguracyjny backend.yaml
Backend pełnił rolę warstwy logiki aplikacji i był dostępny w klastrze poprzez usługę typu ClusterIP.
Rys. 6. Utworzenie obiektu backend typu deployment na węźle B
Ostatnim komponentem był Pod my-sql, który został uruchomiony na węźle C. Pod korzystał z obrazu MySQL i miał ustawione hasło root dla użytkownika administracyjnego.
Rys. 7. Plik konfiguracyjny mysql.yaml
Pod my-sql pełnił rolę warstwy danych aplikacji i był dostępny w klastrze poprzez usługę typu ClusterIP.
Rys. 8. Utworzenie obiektu mysql typu pod na węźle C
Dla każdego komponentu utworzono odpowiednią usługę sieciową:
Rys. 9. Utworzenie usługi sieciowej dla frontendu
Rys. 10. Utworzenie usługi sieciowej dla backendu
Rys. 11. Utworzenie usługi sieciowej dla MYSQL
Aby ograniczyć dostęp do bazy danych MySQL, przygotowano politykę sieciową, która blokowała cały ruch przychodzący do Poda my-sql, dopuszczając jedynie połączenia z backendu na porcie 3306.
Rys. 12. Plik konfiguracyjny mysql-net.yaml
Zastosowana polityka sieciowa została zdefiniowana w sposób jednoznaczny – obejmuje tylko Poda oznaczonego etykietą app: my-sql i ogranicza ruch przychodzący wyłącznie do połączeń z Podów posiadających etykietę app: backend na porcie TCP 3306. Oznacza to, że wszystkie inne źródła ruchu, w tym frontend, zostaną domyślnie zablokowane.
Rys. 13. Utworzenie obiektu polityki sieciowej dla MYSQL
W celu weryfikacji poprawności konfiguracji wykonano serię testów:
Rys. 14. Test połączenia frontend → MySQL
W pierwszym teście sprawdzono możliwość połączenia z bazą danych MySQL z poziomu jednego z podów frontend. Próba wykonania polecenia wget zakończyła się niepowodzeniem – połączenie zostało zablokowane przez politykę sieciową. Wynik TIMEOUT potwierdził, że frontend nie ma dostępu do bazy danych, co było zgodne z założeniami zadania.
Rys. 15. Test połączenia backend → MySQL:3306
Drugi test polegał na sprawdzeniu komunikacji pomiędzy backendem a bazą danych MySQL. Tym razem próba połączenia na porcie 3306 zakończyła się sukcesem. Wynik wskazał, że backend ma prawidłowy dostęp do bazy danych, co potwierdziło poprawne działanie polityki sieciowej dopuszczającej ruch tylko z backendu i wyłącznie na właściwym porcie.
Rys. 16. Test połączenia backend → MySQL:80
Trzeci test miał na celu sprawdzenie, czy backend może połączyć się z bazą danych na innym porcie niż 3306. Próba wykonania połączenia na porcie 80 zakończyła się niepowodzeniem – wynik TIMEOUT potwierdził, że polityka sieciowa skutecznie blokuje wszelkie inne porty. Dzięki temu baza danych jest chroniona przed nieautoryzowanym dostępem z backendu na niewłaściwych portach.
Rys. 17. Test połączenia pod textbox → MySQL:3306
Czwarty test potwierdził skuteczność polityki sieciowej. Nie możemy połączyć się z bazą danych z zewnątrz, gdyż nie mamy zdefiniowanej odpowiedniej etykiety dla Poda.
Testy praktyczne potwierdziły poprawność konfiguracji: frontend nie uzyskał dostępu do bazy (wynik TIMEOUT), backend mógł połączyć się z MySQL na porcie 3306 (wynik SUKCES), a próba połączenia z backendu na innym porcie i próba połączenia na porcie 3306 z Poda bez wymaganej etykiety zakończyły się niepowodzeniem. Dzięki temu można stwierdzić, że NetworkPolicy działa zgodnie z założeniami i skutecznie kontroluje komunikację w klastrze.
W ramach zadania został przygotowany kompletny klaster Kubernetes w środowisku Minikube, składający się z czterech węzłów – jednego głównego oraz trzech roboczych. Na węzłach wdrożono trzy komponenty aplikacji: frontend (nginx, trzy repliki), backend (nginx, jedna replika) oraz Pod z bazą danych MySQL. Każdy z elementów został wystawiony poprzez odpowiednią usługę sieciową – frontend jako NodePort, backend i MySQL jako ClusterIP.
Dodatkowo skonfigurowano politykę sieciową (NetworkPolicy), która ograniczyła dostęp do bazy danych. Frontend nie miał możliwości połączenia z MySQL, natomiast backend mógł komunikować się z bazą wyłącznie na porcie 3306. Testy wykonane przy użyciu poleceń wget oraz dodatkowych narzędzi (busybox, netcat [nc]) potwierdziły poprawność konfiguracji.
Zadanie pokazało, jak w praktyce można wykorzystać Kubernetes do tworzenia wielowarstwowych aplikacji, zarządzania usługami oraz kontrolowania komunikacji sieciowej między komponentami.