Generator Kubernetes Service

Generator manifestu Kubernetes Service

Pody w Kubernetes są ulotne — powstają i znikają, a ich adresy IP się zmieniają. Service daje im stabilny adres i równoważy ruch między replikami.

Typy Service

Selektor

Service kieruje ruch do podów na podstawie etykiet. Selektor app: web obejmie wszystkie pody z tą etykietą — dlatego etykiety w Deployment i Service muszą się zgadzać.

port i targetPort

• port — port, na którym Service jest dostępny.
• targetPort — port, na którym nasłuchuje kontener.

Dzięki temu można wystawić usługę na porcie 80, choć aplikacja działa na 3000.

Jak generator składa manifest Service

Generator zamienia wartości z formularza na manifest w formacie YAML, zgodny z API Kubernetes w wersji v1. Każde pole ma swoje odbicie w dokumencie: nazwa trafia do metadata.name, namespace do metadata.namespace, wybrane etykiety do mapy spec.selector, a wpisy portów do listy spec.ports. Typ usługi (ClusterIP, NodePort, LoadBalancer) ląduje w spec.type. Narzędzie nie wymyśla wartości za użytkownika — składa manifest wyłącznie z tego, co zostało wpisane, więc wynik jest przewidywalny i łatwo go porównać z tym, co zwraca kubectl get svc -o yaml.

Sercem obiektu jest selektor. W manifeście to zwykła mapa etykiet, czyli pary klucz-wartość. Kubernetes nie porównuje nazw Deploymentu i Service — porównuje etykiety. Po utworzeniu obiektu kontroler odpowiedzialny za endpointy przeszukuje pody w tym samym namespace i sprawdza, czy ich etykiety zawierają wszystkie wpisy z selektora. Pasujące pody trafiają jako adresy do listy endpointów. Selektor nie musi być równy całemu zestawowi etykiet poda — wystarczy, że jest jego podzbiorem, dlatego jedna etykieta app: web może objąć pody kilku różnych Deploymentów.

Lista portów jest tablicą, więc jeden Service może obsłużyć kilka portów naraz. Każdy wpis opisuje parę: port, na którym nasłuchuje Service, oraz targetPort, na którym odbiera kontener. Przy jednym porcie nazwa wpisu jest opcjonalna, przy kilku staje się wymagana, bo Kubernetes musi jakoś rozróżnić wpisy w tablicy. Do wpisu dochodzi jeszcze protokół (TCP albo UDP), a w typach NodePort i LoadBalancer również numer nodePort otwierany na każdym węźle klastra. Kolejność i wcięcia w YAML mają znaczenie — lista portów musi być tablicą, a selektor mapą, inaczej API odrzuci dokument przy kubectl apply.

Przykład krok po kroku

1. W polu nazwy wpisujesz web-service, a jako namespace zostawiasz default. Nazwa musi być unikalna w obrębie namespace i zgodna z regułami DNS, czyli bez wielkich liter i podkreśleń.
2. Wybierasz typ NodePort i podajesz własny numer nodePort, na przykład 30080. Ma on znaczenie tylko wtedy, gdy nie chcesz, aby klaster przydzielił port losowo przy każdym wdrożeniu.
3. Ustawiasz selektor na dwie etykiety: app: web oraz tier: frontend. Te same pary muszą się znaleźć w sekcji metadata podów w manifeście Deploymentu.
4. Dodajesz wpis portu: port 80, targetPort 3000, protokół TCP, nazwa wpisu http. Aplikacja w kontenerze nasłuchuje więc na 3000, a Service wystawia ją na 80.
5. Generator zwraca dokument z sekcjami metadata (name: web-service, namespace: default), spec.selector (app: web, tier: frontend), spec.type (NodePort) oraz spec.ports z jednym elementem zawierającym port 80, targetPort 3000, nodePort 30080, protocol TCP i name http.
6. Wynik działania: jeśli Deployment ma 3 repliki, a wszystkie etykiety się zgadzają, Service widzi 3 endpoints i rozdziela między nie ruch. Wewnątrz klastra usługa jest osiągalna pod adresem web-service.default.svc.cluster.local:80, a z zewnątrz pod adresem dowolnego węzła i portem 30080.

Mapowanie pól formularza na klucze YAML

Praktyczne wskazówki

• Trzymaj etykiety w jednym źródle — te same pary klucz-wartość muszą występować w Deployment i w Service. Rozjazd między nimi to najczęstsza przyczyna tego, że usługa nie ma żadnych endpoints.
• Nazywaj porty nawet przy jednym wpisie — dodanie name, np. http, kosztuje jedną linijkę, a gdy pojawi się drugi port, nie trzeba przepisywać manifestu. Nazwy portów wykorzystuje też Ingress.
• Rozważ targetPort jako nazwę — jeśli kontener deklaruje nazwane porty, można wskazać nazwę zamiast liczby. Wtedy zmiana numeru portu w obrazie nie wymaga modyfikacji Service.
• Dobierz typ do środowiska — ClusterIP wystarcza do komunikacji między usługami, NodePort sprawdza się w szybkich testach, a LoadBalancer ma sens tam, gdzie dostawca klastra przydziela zewnętrzny adres.
• Wersjonuj wygenerowany YAML — zapisz plik w repozytorium i wdrażaj go przez kubectl apply -f. Dzięki temu zmiany w portach czy selektorze przechodzą przez przegląd kodu.

Czego narzędzie nie uwzględnia

• Nie zna stanu klastra — nie sprawdza, jakie etykiety mają faktycznie uruchomione pody ani czy wpisana nazwa Service już istnieje. Manifest może być poprawny składniowo i mimo to nie wskazywać żadnego poda.
• Nie pilnuje numeru nodePort — nie wie, jaki zakres portów węzłów dopuszcza Twój kube-apiserver i czy wybrany numer nie jest już zajęty na węźle. Kolizję wykryjesz dopiero przy wdrożeniu.
• Generuje pojedynczy obiekt — nie tworzy Deploymentu ani Ingress, nie dopasowuje automatycznie etykiet i nie pilnuje, aby selektor pokrywał się z tym, co wygenerowały inne narzędzia.
• Pomija pola zaawansowane — takie elementy jak clusterIP, externalTrafficPolicy, sessionAffinity, loadBalancerSourceRanges czy polityka rodzin adresów trzeba dopisać ręcznie po wygenerowaniu pliku.

Najczęstsze pytania