4 - Udostępnianie aplikacji

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

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.

Cele

Poznać Serwis w Kubernetesie
Zrozumieć, jak etykiety (labels) i selektory (selectors) 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.

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.

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

Mamy usługę o nazwie kubernetes, która jest tworzona domyślnie, gdy minikube uruchamia klaster. Aby utworzyć nową usługę i udostępnić ją dla ruchu zewnętrznego, użyjemy polecenia expose z parametrem NodePort.

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

Uruchommy ponownie komendę get services:

kubectl get services

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"

Informacja:

Jeśli używasz minikube z Docker Desktop jako sterownik kontenerów, potrzebny jest tunel minikube. Dzieje się tak, ponieważ kontenery wewnątrz Docker Desktop są izolowane od twojego komputera głównego.

W osobnym oknie terminala wykonaj:
minikube service kubernetes-bootcamp --url

Wyjście wygląda następująco:

http://127.0.0.1:51082
! Ponieważ używasz sterownika Docker na systemie Darwin, terminal musi być otwarty, aby go uruchomić.

Następnie użyj podanego URL-a, aby uzyskać dostęp do aplikacji:
curl 127.0.0.1:51082

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, wykonując curl z wewnątrz 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.

Gdy będziesz gotowy, przejdź do Uruchamianie wielu instancji Twojej aplikacji.

5 - Skalowanie aplikacji

5.1 - Uruchamianie wielu instancji aplikacji

Ręczne skalowanie istniejącej aplikacji za pomocą narzędzia kubectl.

Cele

Wyskaluj aplikację przy użyciu kubectl.

Skalowanie aplikacji

Poprzednio 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.

Jeśli nie pracowałeś z wcześniejszymi sekcjami, zacznij od sekcji Jak użyć Minikube do stworzenia klastra.

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

Informacja:

Jeśli próbujesz to zrobić po poprzedniej sekcji, mogłeś usunąć utworzoną usługę lub utworzyłeś usługę typu NodePort. W tej sekcji zakłada się, że dla wdrożenia kubernetes-bootcamp utworzono usługę o typie: LoadBalancer.

Jeśli nie usunąłeś usługi utworzonej w poprzedniej sekcji, najpierw usuń ją, a następnie uruchom następujące polecenie, aby utworzyć nową z ustawionym typem na LoadBalancer:

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

Ogólnie o skalowaniu

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ępnej sekcji.

Skalowanie Deploymentu

Aby wyświetlić listę swoich Deploymentów, użyj komendy get deployments:

kubectl get deployments

Wynik powinien wyglądać podobnie do:

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   1/1     1            1           11m

Powinniśmy mieć 1 Pod. Jeśli nie, uruchom polecenie ponownie. To pokazuje:

NAME wymienia nazwy Deploymentów w klastrze.
READY pokazuje stosunek replik bieżących (ang. CURRENT) do oczekiwanych (ang. DESIRED).
UP-TO-DATE wyświetla liczbę replik zaktualizowanych w celu osiągnięcia pożądanego stanu.
AVAILABLE pokazuje, ile replik aplikacji jest dostępnych dla użytkowników.
AGE pokazuje, jak długo aplikacja jest uruchomiona.

Aby zobaczyć ReplicaSet utworzony przez Deployment, uruchom:

kubectl get rs

Zauważ, że nazwa ReplicaSet zawsze jest sformatowana jako [NAZWA-DEPLOYMENTU]-[LOSOWY-STRING]. Losowy ciąg jest generowany losowo i wykorzystuje pod-template-hash jako ziarno.

Dwie istotne kolumny tego wyniku to:

DESIRED pokazuje żądaną liczbę replik aplikacji, którą określasz podczas tworzenia Deploymentu. Jest to pożądany stan.
CURRENT pokazuje, ile replik obecnie działa.

Następnie skalujemy Deployment do 4 replik. Użyjemy polecenia kubectl scale, po którym podajemy typ Deployment, nazwę i pożądaną liczbę instancji:

kubectl scale deployments/kubernetes-bootcamp --replicas=4

Aby ponownie wyświetlić listę swoich Deploymentów, użyj get deployments:

kubectl get deployments

Zmiana została zastosowana i mamy 4 dostępne instancje aplikacji. Następnie sprawdźmy, czy liczba Podów uległa zmianie:

kubectl get pods -o wide

Obecnie są 4 Pody, z różnymi adresami IP. Zmiana została zarejestrowana w dzienniku zdarzeń Deploymentu. Aby to sprawdzić, użyj komendy describe:

kubectl describe deployments/kubernetes-bootcamp

Możesz również zauważyć w wyniku tego polecenia, że obecnie istnieją 4 repliki.

Równoważenie obciążenia

Sprawdźmy, czy usługa równoważy obciążenie ruchem. Aby dowiedzieć się, jaki jest wystawiony adres IP i port, możemy użyć opcji `describe service`, jak nauczyliśmy się w poprzedniej części samouczka:

kubectl describe services/kubernetes-bootcamp

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

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

echo NODE_PORT=$NODE_PORT

Następnie wykonamy polecenie curl na wystawiony adres IP i port. Wykonaj to polecenie wielokrotnie:

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

Za każdym razem trafiamy na inny Pod z każdym żądaniem. To pokazuje, że równoważenie obciążenia działa.

Wynik powinien wyglądać podobnie do:

Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-wp67j | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-hs9dj | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-4hjvf | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-wp67j | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-4hjvf | v=1

Informacja:

Jeśli używasz minikube z Docker Desktop jako sterownika kontenerów, potrzebny jest tunel minikube. Wynika to z faktu, że kontenery w Docker Desktop są izolowane od Twojego hosta.

W osobnym oknie terminala wykonaj:
minikube service kubernetes-bootcamp --url

Wynik wygląda następująco:

http://127.0.0.1:51082
!  Ponieważ używasz sterownika Docker na systemie Darwin, terminal musi być otwarty, aby go uruchomić.

Następnie użyj podany URL, aby uzyskać dostęp do aplikacji:
curl 127.0.0.1:51082

Zmniejsz Skalę

Aby zmniejszyć skalowalność Deployment do 2 replik, ponownie uruchom komendę scale:

kubectl scale deployments/kubernetes-bootcamp --replicas=2

Wyświetl listę Deploymentów, aby sprawdzić, czy zmiana została zastosowana, za pomocą komendy get deployments:

kubectl get deployments

Liczba replik zmniejszyła się do 2. Wyświetl listę liczby Podów za pomocą get pods:

kubectl get pods -o wide

To potwierdza, że 2 Pody zostały zakończone.

Gdy będziesz gotowy, przejdź do Wykonywanie aktualizacji Rolling Update.

6 - Aktualizowanie aplikacji

6.1 - Aktualizacje Rolling Update

Wykonaj aktualizację Rolling Update używając kubectl.

Cele

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. Odbywa się to dzięki krokowemu zastępowaniu kolejnych Podów. Nowe Pody uruchamiane są na Węzłach, które posiadają wystarczające zasoby, a Kubernetes czeka, aż uruchomią się nowe Pody, zanim usunie stare.

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.

Ogólnie o Rolling updates

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, a następnie wycofamy tę aktualizację.

Zaktualizuj wersję aplikacji

Aby wyświetlić listę swoich Deploymentów, uruchom komendę get deployments: kubectl get deployments

Aby wyświetlić listę uruchomionych Podów, użyj komendy get pods:

kubectl get pods

Aby zobaczyć bieżącą wersję obrazu aplikacji, uruchom komendę describe pods i poszukaj pola Image:

kubectl describe pods

Aby zaktualizować obraz aplikacji do wersji 2, użyj komendy set image, podając nazwę Deploymentu oraz nową wersję obrazu:

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=docker.io/jocatalin/kubernetes-bootcamp:v2

Polecenie zainicjowało rolling update Deploymentu, aktualizując obraz aplikacji. Sprawdź status nowych Podów i zobacz, jak postępuje wyłączanie poprzednich wersji używając polecenia get pods:

kubectl get pods

Zweryfikuj aktualizację

Najpierw sprawdź, czy usługa działa, ponieważ mogłeś ją usunąć w poprzednim kroku samouczka, uruchom describe services/kubernetes-bootcamp. Jeśli jej brakuje, możesz ją ponownie utworzyć za pomocą:

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

Utwórz zmienną środowiskową o nazwie NODE_PORT, która będzie miała 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"

Następnie wykonaj polecenie curl na udostępniony adres IP i port:

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

Z każdym uruchomieniem polecenia curl, trafisz na inny Pod. Zwróć uwagę, że obecnie wszystkie Pody działają na najnowszej wersji (v2).

Możesz również potwierdzić aktualizację, uruchamiając komendę rollout status:

kubectl rollout status deployments/kubernetes-bootcamp

Aby wyświetlić bieżącą wersję obrazu aplikacji, uruchom komendę describe pods:

kubectl describe pods

W polu Image sprawdź, czy używasz najnowszej wersji obrazu (v2).

Cofnięcie aktualizacji

Wykonajmy kolejną aktualizację i spróbujmy wdrożyć obraz oznaczony tagiem v10:

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10

Użyj get deployments, aby zobaczyć status Deploymentu:

kubectl get deployments

Zauważ, że w jest za mało Podów działających poprawnie. Uruchom komendę get pods, aby wyświetlić listę wszystkich Podów:

kubectl get pods

Zauważ, że niektóre z podów mają status ImagePullBackOff.

Aby uzyskać więcej informacji na temat problemu, uruchom komendę describe pods:

kubectl describe pods

W sekcji Events dla podów, zauważ, że wersja obrazu v10 nie istniała w repozytorium.

Aby wycofać wdrożenie do ostatniej działającej wersji, użyj komendy rollout undo:

kubectl rollout undo deployments/kubernetes-bootcamp

Polecenie rollout undo przywraca Deployment do poprzedniego znanego stanu (v2 obrazu). Aktualizacje są wersjonowane i można je cofać do dowolnego wcześniej znanego stanu Deploymentu.

Użyj podpolecenia get pods, aby ponownie wyświetlić listę Podów:

kubectl get pods

Aby sprawdzić obraz wdrożony na działających Podach, użyj podpolecenia describe pods:

kubectl describe pods

Deployment ponownie używa stabilnej wersji aplikacji (v2). Wycofanie zakończyło się pomyślnie.

Pamiętaj o oczyszczeniu lokalnego klastra

kubectl delete deployments/kubernetes-bootcamp services/kubernetes-bootcamp

Naucz się podstaw

Podstawy Kubernetesa

Co Kubernetes może dla Ciebie zrobić?

Podstawy Kubernetes — Moduły

1. Zbuduj klaster Kubernetes

2. Zainstaluj aplikację

3. Zapoznaj się z aplikacją

4. Udostępnij aplikację publicznie

5. Skaluj aplikację

6. Zaktualizuj aplikację

1 - Tworzenie klastra

1.1 - Jak użyć Minikube do stworzenia klastra

Cele

Klaster Kubernetes

Podsumowanie:

Schemat klastra

2 - Instalowanie aplikacji

2.1 - Jak użyć kubectl do tworzenia Deploymentu

Cele

Instalacje w Kubernetes

Informacja:

Podsumowanie:

Instalacja pierwszej aplikacji w Kubernetes

Podstawy kubectl

Wdrażanie aplikacji

Zobacz aplikację

3 - Poznawanie aplikacji

3.1 - Pody i Węzły

Cele

Pody Kubernetes

Podsumowanie:

Schemat ogólny podów

Węzły

Schemat węzła

Rozwiązywanie problemów przy pomocy kubectl

Sprawdzanie konfiguracji aplikacji

Pokazywanie aplikacji w terminalu

Przeglądanie dzienników kontenera

Wykonywanie polecenia w kontenerze

4 - Udostępnianie aplikacji

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

Cele

Kubernetes Services - przegląd

Podsumowanie

Sewisy i Etykiety (Labels)

Krok 1: Tworzenie nowej Usługi

Informacja:

Krok 2: Używanie etykiet

Krok 3: Usuwanie usługi

5 - Skalowanie aplikacji

5.1 - Uruchamianie wielu instancji aplikacji

Cele

Skalowanie aplikacji

Podsumowanie:

Informacja:

Ogólnie o skalowaniu

Skalowanie Deploymentu

Równoważenie obciążenia

Informacja:

Zmniejsz Skalę

6 - Aktualizowanie aplikacji

6.1 - Aktualizacje Rolling Update

Cele

Aktualizowanie aplikacji

Podsumowanie:

Ogólnie o Rolling updates

Zaktualizuj wersję aplikacji

Zweryfikuj aktualizację

Cofnięcie aktualizacji