W tym rozdziale dokumentacji Kubernetes znajdziesz różne samouczki.
Dzięki nim dowiesz się, jak osiągnąć złożone cele, które przekraczają wielkość
pojedynczego zadania. Typowy samouczek podzielony jest na kilka części,
z których każda zawiera sekwencję odpowiednich kroków.
Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do
słownika, aby móc się później do niego na bieżąco odwoływać.
Podstawy
Podstawy Kubernetesa (PL) to interaktywny samouczek, który pomoże zrozumieć system Kubernetes i wypróbować jego podstawowe możliwości.
Jeśli chciałbyś napisać nowy samouczek, odwiedź
Content Page Types,
gdzie znajdziesz dodatkowe informacje o tym typie strony.
1 - Hello Minikube
Ten samouczek pokaże, jak uruchomić przykładową aplikację
na Kubernetesie przy użyciu minikube oraz Katacoda.
Katacoda to darmowe środowisko Kubernetes dostępne bezpośrednio z przeglądarki web.
Informacja: Możesz też skorzystać z tego samouczka, jeśli już zainstalowałeś minikube.
Odwiedź stronę minikube start, aby dowiedzieć się, jak go zainstalować.
Cele
Skonfiguruj przykładową aplikację do uruchomienia w minikube.
Uruchom aplikację.
Przejrzyj jej logi.
Nim zaczniesz
W tym samouczku wykorzystamy obraz kontenera, który korzysta z NGINX, aby wyświetlić z powrotem wszystkie przychodzące zapytania.
Stwórz klaster minikube
Kliknij w Launch Terminal
Informacja: Jeśli masz minikube zainstalowane lokalnie, uruchom minikube start. Przed uruchomieniem minikube dashboard, otwórz okno nowego terminala, uruchom w nim minikube dashboard i przełącz się z powrotem do okna głównego terminala.
Otwórz panel Kubernetesa w przeglądarce:
minikube dashboard
Tylko w Katacoda: Na górze okienka z terminalem kliknij na znak plus, a następnie wybierz Select port to view on Host 1.
Tylko w Katacoda: Wpisz 30000i kliknij Display Port.
Informacja:
Polecenie dashboard uruchamia dodatek panelu i otwiera proxy w domyślnej przeglądarce.
W panelu można tworzyć różne obiekty Kubernetesa, takie jak Deployment czy Serwis.
Panel jest domyślnie dostępny jedynie z wewnętrznej sieci Kubernetesa.
Polecenie dashboard tworzy tymczasowe proxy, które udostępnia panel także poza tą wewnętrzną sieć.
Aby zatrzymać proxy, wciśnij Ctrl+C i zakończ proces.
Panel ciągle działa na klastrze Kubernetesa, nawet po przerwaniu działania proxy.
Aby dostać się ponownie do panelu, trzeba stworzyć kolejne proxy poleceniem dashboard.
Otwieranie panelu poprzez URL
Jeśli nie chcesz otwierać przeglądarki, uruchom panel z opcją --url, aby wyświetlić URL:
minikube dashboard --url
Stwórz Deployment
Pod w Kubernetesie to grupa jednego lub wielu kontenerów
połączonych ze sobą na potrzeby administrowania i dostępu sieci. W tym samouczku Pod
zawiera tylko jeden kontener. Deployment
w Kubernetesie monitoruje stan twojego Poda
i restartuje należące do niego kontenery, jeśli z jakichś powodów przestaną działać.
Użycie Deploymentu to rekomendowana metoda zarządzania tworzeniem i skalowaniem Podów.
Użyj polecenia kubectl create do stworzenia Deploymentu, który będzie zarządzał Podem. Pod uruchamia kontener
wykorzystując podany obraz Dockera.
NAME READY UP-TO-DATE AVAILABLE AGE
hello-node 1/1 1 1 1m
Sprawdź stan Poda:
kubectl get pods
Wynik powinien wyglądać podobnie do:
NAME READY STATUS RESTARTS AGE
hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
Obejrzyj zdarzenia na klastrze:
kubectl get events
Sprawdź konfigurację kubectl:
kubectl config view
Informacja: Więcej informacji na temat polecenia kubectl znajdziesz w przeglądzie kubectl.
Stwórz Serwis
Domyślnie Pod jest dostępny tylko poprzez swój wewnętrzny adres IP
wewnątrz klastra Kubernetes. Aby kontener hello-node był osiągalny spoza
wirtualnej sieci Kubernetesa, musisz najpierw udostępnić Pod
jako Serwis Kubernetes.
Udostępnij Pod w Internecie przy pomocy polecenia kubectl expose:
Opcja --type=LoadBalancer wskazuje, że chcesz udostępnić swój Serwis
na zewnątrz klastra.
Aplikacja, która jest umieszczona w obrazie kontenera k8s.gcr.io/echoserver, nasłuchuje jedynie na porcie TCP 8080. Jeśli użyłeś
kubectl expose do wystawienia innego portu, aplikacje klienckie mogą nie móc się podłączyć do tamtego innego portu.
Sprawdź Serwis, który właśnie utworzyłeś:
kubectl get services
Wynik powinien wyglądać podobnie do:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
U dostawców usług chmurowych, którzy obsługują load balancers,
zostanie przydzielony zewnętrzny adres IP na potrzeby serwisu.
W minikube, typ LoadBalancer udostępnia serwis poprzez polecenie
minikube service.
Uruchom poniższe polecenie:
minikube service hello-node
Tylko w Katacoda: Kliknij znak plus, a następnie Select port to view on Host 1.
Tylko w Katacoda: Wpisz 30369 (sprawdź numer portu obok 8080 w opisie Serwisu) i kliknij Display Port
Otworzy sie okno przeglądarki obsługującej twoją aplikację i wyświetli odpowiedź tej aplikacji.
Włącz dodatki
Narzędzie minikube dysponuje zestawem wbudowanych dodatków, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes.
Ten samouczek poprowadzi Cię przez podstawy systemu zarządzania zadaniami na klastrze Kubernetes. W każdym module znajdziesz najważniejsze informacje o głównych pojęciach i funkcjonalnościach Kubernetes oraz interaktywny samouczek online. Dzięki samouczkom nauczysz się zarządzać prostym klasterem i skonteneryzowanymi aplikacjami uruchamianymi na tym klastrze.
Nauczysz się, jak:
Zainstalować skonteneryzowaną aplikację na klastrze.
Wyskalować tę instalację.
Zaktualizować aplikację do nowej wersji.
Rozwiązywać problemy z aplikacją.
Ten samouczek korzysta z Katacoda do uruchomienia wirtualnego terminalu w przeglądarce. W terminalu dostępny jest Minikube, niewielka lokalna instalacja Kubernetes, która może być uruchamiana z dowolnego miejsca. Nie ma konieczności instalowania ani konfigurowania żadnego oprogramowania. Każdy z interaktywnych samouczków jest wykonywany bezpośrednio w przeglądarce.
Co Kubernetes może dla Ciebie zrobić?
Użytkownicy oczekują od współczesnych serwisów internetowych dostępności non-stop, a deweloperzy chcą móc instalować nowe wersje swoich serwisów kilka razy dziennie. Używając kontenerów można przygotowywać oprogramowanie w taki sposób, aby mogło być instalowane i aktualizowane nie powodując żadnych przestojów. Kubernetes pomaga uruchamiać te aplikacje w kontenerach tam, gdzie chcesz i kiedy chcesz i znajdować niezbędne zasoby i narzędzia wymagane do ich pracy. Kubernetes może działać w środowiskach produkcyjnych, jest otwartym oprogramowaniem zaprojektowanym z wykorzystaniem nagromadzonego przez Google doświadczenia w zarządzaniu kontenerami, w połączeniu z najcenniejszymi ideami społeczności.
Uruchomić klaster Kubernetes przy pomocy terminala online.
Klaster Kubernetes
Zadaniem Kubernetesa jest zarządzanie klastrem komputerów o wysokiej dostępności, działającego jako jedna całość. Kubernetes, poprzez swój system obiektów abstrakcyjnych, umożliwia uruchamianie aplikacji w kontenerach bez przypisywania ich do konkretnej maszyny. Aby móc korzystać z tego nowego modelu instalacji, aplikacje muszą być przygotowane w taki sposób, aby były niezależne od konkretnego serwera: muszą być skonteneryzowane. Aplikacje w kontenerach są bardziej elastyczne przy instalacji, niż to miało miejsce w poprzednich modelach, kiedy aplikacje były instalowane bezpośrednio na konkretne maszyny jako pakiety ściśle powiązane z tą maszyną. Kubernetes automatyzuje dystrybucję i zlecanie uruchamiania aplikacji na klastrze w bardziej efektywny sposób. Kubernetes jest platformą otwartego oprogramowania, gotowym do pracy w środowiskach produkcyjnych.
Klaster Kubernetes składa się z dwóch rodzajów zasobów:
Warstwa sterowania koordynuje działanie klastra
Na węzłach (nodes) uruchamiane są aplikacje
Podsumowanie:
Klaster Kubernetes
Minikube
Kubernetes to platforma oprogramowania typu open source, gotowa do pracy w środowiskach produkcyjnych, która zarządza rozmieszczeniem i uruchomieniem kontenerów zawierających aplikacje na klastrach komputerowych.
Schemat klastra
Warstwa sterowania odpowiada za zarządzanie klastrem. Warstwa sterowania koordynuje wszystkie działania klastra, takie jak zlecanie uruchomienia aplikacji, utrzymywanie pożądanego stanu aplikacji, skalowanie aplikacji i instalowanie nowych wersji.
Węzeł to maszyna wirtualna (VM) lub fizyczny serwer, który jest maszyną roboczą w klastrze Kubernetes. Na każdym węźle działa Kubelet, agent zarządzający tym węzłem i komunikujący się z warstwą sterowania Kubernetesa. Węzeł zawiera także narzędzia do obsługi kontenerów, takie jak containerd lub Docker. Klaster Kubernetes w środowisku produkcyjnym powinien składać się minimum z trzech węzłów.
Warstwa sterowania zarządza klastrem i węzłami wykorzystywanymi do uruchamiania aplikacji.
Kiedy instalujesz aplikację na Kubernetesie, zlecasz warstwie sterowania uruchomienie kontenera z aplikacją. Warstwa sterowania zleca uruchomienie kontenera na węzłach klastra. Węzły komunikują się z warstwą sterowania przy użyciu API Kubernetesa, udostępnianego poprzez warstwę sterowania. Użytkownicy końcowi mogą korzystać bezpośrednio z API Kubernetesa do komunikacji z klastrem.
Klaster Kubernetes może być zainstalowany zarówno na fizycznych, jak i na maszynach wirtualnych. Aby wypróbować Kubernetesa, można też wykorzystać Minikube. Minikube to "lekka" implementacja Kubernetesa, która tworzy VM na maszynie lokalnej i instaluje prosty klaster składający się tylko z jednego węzła. Minikube jest dostępny na systemy Linux, macOS i Windows. Narzędzie linii poleceń Minikube obsługuje podstawowe operacje na klastrze, takie jak start, stop, prezentacja informacji jego stanie i usunięcie klastra. Na potrzeby tego samouczka wykorzystamy jednak terminal online z zainstalowanym już wcześniej Minikube.
Teraz, kiedy już wiesz, co to jest Kubernetes, przejdźmy do samouczka online i stwórzmy nasz pierwszy klaster!
Mając działający klaster Kubernetes, można na nim zacząć instalować aplikacje.
W tym celu należy skonfigurować Deployment. Deployment informuje Kubernetesa,
jak tworzyć i aktualizować instancje Twojej aplikacji. Po stworzeniu Deploymentu, węzeł master Kubernetesa
zleca uruchomienie tej aplikacji na indywidualnych węzłach klastra.
Po utworzeniu instancji aplikacji, Kubernetes Deployment Controller na bieżąco monitoruje te instancje. Jeśli węzeł, na którym działała jedna z instancji ulegnie awarii lub zostanie usunięty, Deployment Controller zamieni tę instancję z instancją na innym węźle klastra. W ten sposób działa samo naprawiający się mechanizm, który reaguje na awarie lub wyłączenia maszyn w klastrze.
W czasach przed wprowadzeniem takiej automatyzacji, skrypty instalacyjne używane były zazwyczaj do uruchomienia aplikacji, ale nie radziły sobie z awariami maszyn. Poprzez połączenie procesu instalacji i kontroli nad działaniem aplikacji na węzłach, Deployment Kubernetes oferuje fundamentalnie różne podejście do zarządzania aplikacjami.
Podsumowanie:
Deployments
Kubectl
Deployment odpowiada za stworzenie i aktualizacje instancji Twojej aplikacji
Instalacja pierwszej aplikacji w Kubernetes
Do tworzenia i zarządzaniem Deploymentem służy polecenie linii komend, Kubectl. Kubectl używa Kubernetes API do komunikacji z klasterem. W tym module nauczysz się najczęściej używanych poleceń Kubectl niezbędnych do stworzenia Deploymentu, który uruchomi Twoje aplikacje na klastrze Kubernetes.
Tworząc Deployment musisz określić obraz kontenera oraz liczbę replik, które mają być uruchomione. Te ustawienia możesz zmieniać później, aktualizując Deployment. Moduły 5 oraz 6 omawiają skalowanie i aktualizowanie Deploymentów.
Aby aplikacja mogła zostać uruchomiona w Kubernetes, musi być opakowana w jeden z obsługiwanych formatów kontenerów
Na potrzeby pierwszej instalacji użyjesz aplikacji hello-node zapakowaną w kontener Docker-a, która korzysta z NGINXa i powtarza wszystkie wysłane do niej zapytania. (Jeśli jeszcze nie próbowałeś stworzyć aplikacji hello-node i uruchomić za pomocą kontenerów, możesz spróbować teraz, kierując się instrukcjami samouczka Hello Minikube).
Teraz, kiedy wiesz, czym są Deploymenty, przejdźmy do samouczka online, żeby zainstalować naszą pierwszą aplikację!
Pod to podstawowy element odpowiedzialny za uruchomienie aplikacji na Kubernetesie. Każdy pod to część składowa całościowego obciążenia Twojego klastra. Dowiedz się więcej na temat Podów.
Do pracy z terminalem użyj wersji na desktop/tablet
Po stworzeniu Deploymentu w Module 2, Kubernetes stworzył Pod, który "przechowuje" instancję Twojej aplikacji. Pod jest obiektem abstrakcyjnym Kubernetes, który reprezentuje grupę jednego bądź wielu kontenerów (jak np. Docker) wraz ze wspólnymi zasobami dla tych kontenerów. Zasobami mogą być:
Współdzielona przestrzeń dyskowa, np. Volumes
Zasoby sieciowe, takie jak unikatowy adres IP klastra
Informacje służące do uruchamiania każdego z kontenerów ⏤ wersja obrazu dla kontenera lub numery portów, które mają być użyte
Pod tworzy model specyficznego dla aplikacji "wirtualnego serwera" i może zawierać różne kontenery aplikacji, które są relatywnie blisko powiązane. Przykładowo, pod może zawierać zarówno kontener z Twoją aplikacją w Node.js, jak i inny kontener dostarczający dane, które mają być opublikowane przez serwer Node.js. Kontenery wewnątrz poda współdzielą adres IP i przestrzeń portów, zawsze są uruchamiane wspólnie w tej samej lokalizacji i współdzielą kontekst wykonawczy na tym samym węźle.
Pody są niepodzielnymi jednostkami na platformie Kubernetes. W trakcie tworzenia Deploymentu na Kubernetes, Deployment tworzy Pody zawierające kontenery (w odróżnieniu od tworzenia kontenerów bezpośrednio). Każdy Pod związany jest z węzłem, na którym zostało zlecone jego uruchomienie i pozostaje tam aż do jego wyłączenia (zgodnie z polityką restartowania) lub skasowania. W przypadku awarii węzła, identyczny pod jest skierowany do uruchomienia na innym węźle klastra.
Podsumowanie:
Pody
Węzły
Główne polecenia Kubectl
Pod to grupa jednego lub wielu kontenerów aplikacji (jak np. Docker) zawierających współdzieloną przestrzeń dyskową (volumes), adres IP i informacje, jak mają być uruchamiane.
Schemat ogólny podów
Węzły
Pod jest uruchamiany na węźle (Node). Węzeł jest maszyną roboczą, fizyczną lub wirtualną, w zależności od klastra. Każdy z węzłów jest zarządzany przez warstwę sterowania (Control Plane). Węzeł może zawierać wiele podów. Warstwa sterowania Kubernetesa automatycznie zleca uruchomienie podów na różnych węzłach w ramach klastra. Automatyczne zlecanie uruchomienia bierze pod uwagę zasoby dostępne na każdym z węzłów.
Na każdym węźle Kubernetes działają co najmniej:
Kubelet, proces odpowiedzialny za komunikację pomiędzy warstwą sterowania Kubernetesa i węzłami; zarządza podami i kontenerami działającymi na maszynie.
Proces wykonawczy kontenera (np. Docker), który zajmuje się pobraniem obrazu dla kontenera z repozytorium, rozpakowaniem kontenera i uruchomieniem aplikacji.
Kontenery powinny być uruchamiane razem w jednym podzie, jeśli są ściśle ze sobą związane i muszą współdzielić zasoby, np. dysk.
Schemat węzła
Rozwiązywanie problemów przy pomocy kubectl
W module 2 używałeś narzędzia Kubectl. W module 3 będziemy go nadal używać, aby wydobyć informacje na temat zainstalowanych aplikacji i środowiska, w jakim działają. Najczęstsze operacje przeprowadzane są przy pomocy następujących poleceń kubectl:
kubectl get - wyświetl informacje o zasobach
kubectl describe - pokaż szczegółowe informacje na temat konkretnego zasobu
kubectl logs - wyświetl logi z kontenera w danym podzie
kubectl exec - wykonaj komendę wewnątrz kontenera w danym podzie
Korzystaj z tych poleceń, aby sprawdzić, kiedy aplikacja została zainstalowana, jaki jest jej aktualny status, gdzie jest uruchomiona i w jakiej konfiguracji.
Kiedy już wiemy więcej na temat części składowych klastra i podstawowych poleceń, przyjrzyjmy się naszej aplikacji.
Węzeł jest maszyną roboczą Kubernetes - fizyczną lub wirtualną, zależnie od klastra. Wiele podów może być uruchomionych na tym samym węźle.
2.4.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 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.
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 którym pody mogą się psuć i być zastępowane przez Kubernetes nowymi bez ujemnego wpływu 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.
W poprzednim module stworzyliśmy Deployment i udostępniliśmy go publicznie korzystając z Serwisu. Deployment utworzył tylko jeden Pod, w którym uruchomiona jest nasza aplikacja. Wraz ze wzrostem ruchu, będziemy musieli wyskalować aplikację, aby była w stanie obsłużyć zwiększone zapotrzebowanie użytkowników.
Skalowanie polega na zmianie liczby replik w Deploymencie.
Podsumowanie:
Skalowanie Deploymentu
Od samego początku w ramach Deploymentu można uruchomić wiele instancji — skorzystaj z parametru --replicas polecenia kubectl create deployment
Kiedy zwiększamy skalę Deploymentu, uruchomienie nowych Podów jest zlecane na Węzłach, które posiadają odpowiednio dużo zasobów. Operacja skalowania zwiększy liczbę Podów do oczekiwanej wartości. W Kubernetes możliwe jest również autoskalowanie Podów, ale jest ono poza zakresem niniejszego samouczka. Istnieje także możliwość skalowania do zera — w ten sposób zatrzymane zostaną wszystkie Pody należące do konkretnego Deploymentu.
Kiedy działa jednocześnie wiele instancji jednej aplikacji, należy odpowiednio rozłożyć ruch pomiędzy każdą z nich. Serwisy posiadają zintegrowany load-balancer, który dystrybuuje ruch na wszystkie Pody w Deployment wystawionym na zewnątrz. Serwis prowadzi ciągły monitoring Podów poprzez ich punkty dostępowe (endpoints), aby zapewnić, że ruch kierowany jest tylko do tych Podów, które są faktycznie dostępne.
Skalowanie polega na zmianie liczby replik w ramach Deploymentu.
Kiedy aplikacja ma uruchomioną więcej niż jedną instancję, można prowadzić ciągłe aktualizacje (Rolling updates) bez przerw w działaniu aplikacji. O tym będzie mowa w następnym module. Na razie przejdźmy do terminala online, aby przeprowadzić skalowanie aplikacji.
Przeprowadzić płynną aktualizację przy użyciu kubectl.
Aktualizowanie aplikacji
Użytkownicy oczekują, że aplikacje są dostępne non-stop, a deweloperzy chcieliby móc wprowadzać nowe wersje nawet kilka razy dziennie. W Kubernetes jest to możliwe dzięki mechanizmowi płynnych aktualizacji (rolling updates). Rolling updates pozwala prowadzić aktualizację w ramach Deploymentu bez przerw w jego działaniu dzięki krokowemu aktualizowaniu kolejnych Podów. Nowe Pody uruchamiane są na Węzłach, które posiadają wystarczające zasoby.
W poprzednim module wyskalowaliśmy aplikację aby była uruchomiona na wielu instancjach. To niezbędny wymóg, aby móc prowadzić aktualizacje bez wpływu na dostępność aplikacji. Domyślnie, maksymalna liczba Podów, które mogą być niedostępne w trakcie aktualizacji oraz Podów, które mogą być tworzone, wynosi jeden. Obydwie opcje mogą być zdefiniowane w wartościach bezwzględnych lub procentowych (ogólnej liczby Podów).
W Kubernetes, każdy aktualizacja ma nadany numer wersji i każdy Deployment może być wycofany do wersji poprzedniej (stabilnej).
Podsumowanie:
Aktualizacja aplikacji
Rolling updates to metoda na aktualizację Deploymentów bez przerwy w ich dostępności poprzez stopniową zamianę kolejnych Podów na ich nowe wersje.
Podobnie, jak w przypadku skalowania aplikacji, jeśli Deployment jest udostępniony publicznie, Serwis będzie kierował ruch tylko do Podów, które są dostępne w trakcie aktualizacji. Dostępny Pod to taki, którego instancja jest dostępna dla użytkowników aplikacji.
Płynne aktualizacje pozwalają na:
Promocję aplikacji z jednego środowiska do innego (poprzez aktualizację obrazu kontenera)
Wycofywanie się do poprzedniej wersji
Continuous Integration oraz Continuous Delivery aplikacji bez przerw w jej działaniu
Jeśli Deployment jest udostępniony publicznie, Serwis będzie kierował ruch w trakcie aktualizacji tylko do Podów, które są aktualnie dostępne.
W ramach tego interaktywnego samouczka zaktualizujemy aplikację do nowej wersji oraz wycofamy tę aktualizację.
