To wielostronicowy widok tej sekcji do wydrukowania. Kliknij aby wydrukować.
Udostępnianie aplikacji
- 1: Jak używać Service do udostępniania aplikacji
- 2: Interaktywny samouczek - Udostępnianie aplikacji
1 - Jak używać Service do udostępniania aplikacji
Cele
- Poznać Serwis w Kubernetesie
- Zrozumieć, jak obiekty Label i LabelSelector są powiązane z Serwisem
- Udostępnić aplikację na zewnątrz klastra Kubernetes korzystając z Serwisu
Kubernetes Services - przegląd
Pody Kubernetes 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 Kubernetes 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 w Kubernetes 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 (zalecane) lub w JSONie - tak, jak wszystkie obiekty Kubernetes. 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 rekordCNAME
wraz z zawartością. W tym przypadku nie jest wykorzystywany proces przekierowania ruchu metodą proxy. Ta metoda wymagakube-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
.
Podsumowanie
- Otwarcie Poda na ruch z zewnątrz
- Rozkładanie ruchu pomiędzy poszczególne Pody
- Używanie etykiet
Serwis Kubernetesa to warstwa abstrakcji, która definiuje logiczny zbiór Podów i umożliwia kierowanie ruchu przychodzącego do Podów, jego równoważenie oraz service discovery.
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 Kubernetes.
Serwis znajduje zestaw odpowiednich Podów przy pomocy etykiet i selektorów, podstawowych jednostek grupujących, które umożliwiają operacje logiczne na obiektach Kubernetes. 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.