To wielostronicowy widok tej sekcji do wydrukowania. Kliknij aby wydrukować.

Wróć do zwykłego widoku tej strony.

Udostępnianie aplikacji

1 - Jak używać Service do udostępniania aplikacji

Cele

  • Dowiedz się, czym jest Service w Kubernetesie.
  • Zrozum, jak etykiety (labels) i selektory (selectors) są powiązane z Service.
  • Wystaw aplikację na zewnątrz klastra Kubernetesa.

Kubernetes Services - przegląd

Pody Kubernetesa są nietrwałe. Pody mają swój cykl życia. Jeśli węzeł roboczy ulegnie awarii, tracone są wszystkie pody działające na węźle. Replicaset będzie próbował automatycznie doprowadzić klaster z powrotem do pożądanego stanu tworząc nowe pody i w ten sposób zapewnić działanie aplikacji. Innym przykładem może być system na back-endzie przetwarzania obrazów posiadający 3 repliki. Każda z tych replik jest wymienna - system front-endu nie powinien musieć pilnować replik back-endu ani tego, czy któryś z podów przestał działać i został odtworzony na nowo. Nie należy jednak zapominać o tym, że każdy Pod w klastrze Kubernetesa ma swój unikatowy adres IP, nawet pody w obrębie tego samego węzła, zatem powinna istnieć metoda automatycznego uzgadniania zmian pomiędzy podami, aby aplikacja mogła dalej funkcjonować.

Serwis (ang. Service) w Kubernetesie jest abstrakcyjnym obiektem, która definiuje logiczny zbiór podów oraz politykę dostępu do nich. Serwisy pozwalają na swobodne łączenie zależnych podów. Serwis jest zdefiniowany w YAMLu lub w JSONie - tak, jak wszystkie obiekty Kubernetesa. Zbiór podów, które obsługuje Serwis, jest zazwyczaj określany przez LabelSelector (poniżej opisane jest, w jakich przypadkach możesz potrzebować zdefiniować Serwis bez specyfikowania selektora).

Mimo, że każdy pod ma swój unikatowy adres IP, te adresy nie są dostępne poza klastrem, o ile nie zostaną wystawione za pomocą Serwisu. Serwis umożliwia aplikacji przyjmować ruch przychodzący. Serwisy mogą być wystawiane na zewnątrz na kilka różnych sposobów, poprzez określenie typu w ServiceSpec:

  • ClusterIP (domyślnie) - Wystawia serwis poprzez wewnętrzny adres IP w klastrze. W ten sposób serwis jest dostępny tylko wewnątrz klastra.

  • NodePort - Wystawia serwis na tym samym porcie na każdym z wybranych węzłów klastra przy pomocy NAT. W ten sposób serwis jest dostępny z zewnątrz klastra poprzez NodeIP:NodePort. Nadzbiór ClusterIP.

  • LoadBalancer - Tworzy zewnętrzny load balancer u bieżącego dostawcy usług chmurowych (o ile jest taka możliwość) i przypisuje serwisowi stały, zewnętrzny adres IP. Nadzbiór NodePort.

  • ExternalName - Przypisuje Service do externalName (np. foo.bar.example.com), zwracając rekord CNAME wraz z zawartością. W tym przypadku nie jest wykorzystywany proces przekierowania ruchu metodą proxy. Ta metoda wymaga kube-dns w wersji v1.7 lub wyższej lub CoreDNS w wersji 0.0.8 lub wyższej.

Więcej informacji na temat różnych typów serwisów znajduje się w samouczku Używanie adresu źródłowego (Source IP). Warto też zapoznać się z Łączeniem Aplikacji z Serwisami.

W pewnych przypadkach w serwisie nie specyfikuje się selector. Serwis, który został stworzony bez pola selector, nie utworzy odpowiedniego obiektu Endpoints. W ten sposób użytkownik ma możliwość ręcznego przyporządkowania serwisu do konkretnych endpoints. Inny przypadek, kiedy nie używa się selektora, ma miejsce, kiedy stosujemy type: ExternalName.

Sewisy i Etykiety (Labels)

Serwis kieruje przychodzący ruch do grupy Podów. Serwisy są obiektami abstrakcyjnymi, dzięki czemu Pody, które z jakichś powodów przestały działać i zostały zastąpione przez Kubernetesa nowymi instancjami, nie wpłyną ujemnie na działanie twoich aplikacji. Detekcją nowych podów i kierowaniem ruchu pomiędzy zależnymi podami (takimi, jak składowe front-end i back-end w aplikacji) zajmują się Serwisy Kubernetesa.

Serwis znajduje zestaw odpowiednich Podów przy pomocy etykiet i selektorów, podstawowych jednostek grupujących, które umożliwiają operacje logiczne na obiektach Kubernetesa. Etykiety to pary klucz/wartość przypisane do obiektów. Mogą być używane na różne sposoby:

  • Dzielić obiekty na deweloperskie, testowe i produkcyjne
  • Osadzać znaczniki (tags) określające wersje
  • Klasyfikować obiekty przy użyciu znaczników

Obiekty mogą być oznaczane etykietami w momencie tworzenia lub później. Etykiety mogą być zmienianie w dowolnej chwili. Udostępnijmy teraz naszą aplikację przy użyciu Serwisu i oznaczmy ją odpowiednimi etykietami.

Krok 1: Tworzenie nowej Usługi

Sprawdźmy, czy nasza aplikacja działa. Użyjemy polecenia kubectl get i sprawdzimy istniejące Pody:

kubectl get pods

Jeśli żadne Pody nie działają, oznacza to, że obiekty z poprzednich samouczków zostały usunięte. W takim przypadku wróć i odtwórz wdrożenie z samouczka Używanie kubectl do tworzenia Deploymentu. Proszę poczekać kilka sekund i ponownie wylistować Pody. Możesz kontynuować, gdy zobaczysz działający jeden Pod.

Następnie wymieńmy aktualne usługi z naszego klastra:

kubectl get services

Aby utworzyć nową usługę i udostępnić ją dla ruchu zewnętrznego, użyjemy polecenia expose z parametrem --type=NodePort:

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

Mamy teraz działającą usługę o nazwie kubernetes-bootcamp. Tutaj widzimy, że usługa otrzymała unikalny cluster-IP, wewnętrzny port oraz zewnętrzny-IP (IP węzła).

Aby dowiedzieć się, który port został otwarty zewnętrznie (dla type: NodePort usługi), uruchomimy komendę describe service:

kubectl describe services/kubernetes-bootcamp

Utwórz zmienną środowiskową o nazwie NODE_PORT, która ma wartość przypisanego portu węzła:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
echo "NODE_PORT=$NODE_PORT"

Teraz możemy przetestować, czy aplikacja jest wystawiona poza klaster, używając curl, adresu IP węzła i zewnętrznie wystawionego portu:

curl http://"$(minikube ip):$NODE_PORT"

Otrzymaliśmy odpowiedź od serwera. Usługa jest wystawiona.

Krok 2: Używanie etykiet

Deployment automatycznie utworzył etykietę dla naszego Poda. Za pomocą komendy describe deployment możesz zobaczyć nazwę (klucz) tej etykiety:

kubectl describe deployment

Użyjmy tej etykiety, aby zapytać o naszą listę Podów. Skorzystamy z polecenia kubectl get pods z parametrem -l, a następnie wartościami etykiet:

kubectl get pods -l app=kubernetes-bootcamp

Możesz zrobić to samo, aby wyświetlić istniejące Usługi:

kubectl get services -l app=kubernetes-bootcamp

Pobierz nazwę Pod i zapisz ją w zmiennej środowiskowej POD_NAME:

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo "Name of the Pod: $POD_NAME"

Aby zastosować nową etykietę, używamy komendy label, po której następuje typ obiektu, nazwa obiektu i nowa etykieta:

kubectl label pods "$POD_NAME" version=v1

To zastosuje nową etykietę do naszego poda (przypięliśmy wersję aplikacji do poda), a możemy to sprawdzić za pomocą polecenia describe pod:

kubectl describe pods "$POD_NAME"

Widzimy tutaj, że etykieta jest teraz przypisana do naszego Poda. Możemy teraz zapytać o listę podów, używając nowej etykiety:

kubectl get pods -l version=v1

I widzimy Pod.

Krok 3: Usuwanie usługi

Aby usunąć Usługi, można użyć polecenia delete service. Etykiety mogą być również używane tutaj:

kubectl delete service -l app=kubernetes-bootcamp

Potwierdź, że Usługa została usunięta:

kubectl get services

To potwierdza, że nasza usługa została usunięta. Aby upewnić się, że trasa nie jest już wystawiona, możesz użyć curl na wcześniej wystawionym adresie IP i porcie:

curl http://"$(minikube ip):$NODE_PORT"

To dowodzi, że aplikacja nie jest już dostępna z zewnątrz klastra. Możesz potwierdzić, że aplikacja nadal działa za pomocą curl z wnętrza poda:

kubectl exec -ti $POD_NAME -- curl http://localhost:8080

Widzimy tutaj, że aplikacja jest uruchomiona. Dzieje się tak, ponieważ aplikacją zarządza Deployment. Aby wyłączyć aplikację, należy również usunąć Deployment.

Co dalej?