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ć.
Jeśli chciałbyś napisać nowy samouczek, odwiedź Content Page Types, gdzie znajdziesz dodatkowe informacje o tym typie strony.
Ten samouczek pokaże, jak uruchomić przykładową aplikację na Kubernetesie przy użyciu minikube. W tym samouczku wykorzystamy obraz kontenera, który korzysta z NGINX, aby wyświetlić z powrotem wszystkie przychodzące zapytania.
Ten tutorial zakłada, że masz już skonfigurowane narzędzie minikube. Instrukcje instalacji
znajdziesz w Kroku 1 dokumentacji minikube start.
Dodatkowo wymagane jest zainstalowanie kubectl. Szczegółowe instrukcje
instalacji dostępne są w sekcji Install tools.
minikube start
Sprawdź status klastra minikube, aby upewnić się, że wszystkie jego komponenty są uruchomione.
minikube status
Wynik z powyższego polecenia powinien pokazywać wszystkie komponenty jako działające (ang. Running) lub skonfigurowane (ang. Configured), jak pokazano w poniższym przykładzie:
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
Otwórz dashboard Kubernetesa. Można to zrobić na dwa sposoby:
Otwórz nowy terminal i uruchom:
# Uruchom nową sesję terminala i pozostaw ją aktywną.
minikube dashboard
Teraz wróć do terminala, w którym uruchomiłeś minikube start.
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.
Aby dowiedzieć się, jak uniknąć bezpośredniego uruchamiania przeglądarki z terminala i uzyskać URL do pulpitu nawigacyjnego w sieci, zapoznaj się z kartą "Kopiuj i wklej URL".
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.
Jeśli nie chcesz, aby minikube automatycznie otwierał przeglądarkę internetową, uruchom podkomendę dashboard z flagą --url. minikube wyświetli adres URL, który możesz otworzyć w preferowanej przeglądarce.
Otwórz nowy terminal i uruchom:
# Uruchom nową sesję terminala i pozostaw ją aktywną.
minikube dashboard --url
Teraz możesz użyć tego URL-a i wrócić do terminala, w którym uruchomiłeś minikube start.
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.
# Uruchom testowy obraz kontenera zawierający serwer WWW
kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.53 -- /agnhost netexec --http-port=8080
Sprawdź stan Deploymentu:
kubectl get deployments
Wynik powinien wyglądać podobnie do:
NAME READY UP-TO-DATE AVAILABLE AGE
hello-node 1/1 1 1 1m
(Może minąć trochę czasu, zanim pod stanie się dostępny. Jeśli widzisz "0/1", spróbuj ponownie za kilka sekund.)
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
Pobierz logi aplikacji z kontenera działającego w podzie (użyj nazwy poda zwróconej przez polecenie kubectl get pods).
hello-node-5f76cf6ccf-br9b5 w poleceniu kubectl logs nazwą poda z wyniku polecenia kubectl get pods.kubectl logs hello-node-5f76cf6ccf-br9b5
Wynik powinien wyglądać podobnie do:
I0911 09:19:26.677397 1 log.go:195] Started HTTP server on port 8080
I0911 09:19:26.677586 1 log.go:195] Started UDP server on port 8081
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:
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
Opcja --type=LoadBalancer wskazuje, że
chcesz udostępnić swój Serwis na zewnątrz klastra.
Aplikacja, która jest umieszczona w obrazie kontenera, 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, serwis typu
LoadBalancer można udostępnić poprzez polecenie minikube service.
Uruchom poniższe polecenie:
minikube service hello-node
Otworzy sie okno przeglądarki obsługującej twoją aplikację i wyświetli odpowiedź tej aplikacji.
Narzędzie minikube dysponuje zestawem wbudowanych dodatków, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes.
Lista aktualnie obsługiwanych dodatków:
minikube addons list
Wynik powinien wyglądać podobnie do:
addon-manager: enabled
dashboard: enabled
default-storageclass: enabled
efk: disabled
freshpod: disabled
gvisor: disabled
helm-tiller: disabled
ingress: disabled
ingress-dns: disabled
logviewer: disabled
metrics-server: disabled
nvidia-driver-installer: disabled
nvidia-gpu-device-plugin: disabled
registry: disabled
registry-creds: disabled
storage-provisioner: enabled
storage-provisioner-gluster: disabled
Włącz dodatek, na przykład metrics-server:
minikube addons enable metrics-server
Wynik powinien wyglądać podobnie do:
The 'metrics-server' addon is enabled
Sprawdź Pody i Serwisy, który właśnie stworzyłeś:
kubectl get pod,svc -n kube-system
Wynik powinien wyglądać podobnie do:
NAME READY STATUS RESTARTS AGE
pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m
pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m
pod/metrics-server-67fb648c5 1/1 Running 0 26s
pod/etcd-minikube 1/1 Running 0 34m
pod/influxdb-grafana-b29w8 2/2 Running 0 26s
pod/kube-addon-manager-minikube 1/1 Running 0 34m
pod/kube-apiserver-minikube 1/1 Running 0 34m
pod/kube-controller-manager-minikube 1/1 Running 0 34m
pod/kube-proxy-rnlps 1/1 Running 0 34m
pod/kube-scheduler-minikube 1/1 Running 0 34m
pod/storage-provisioner 1/1 Running 0 34m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/metrics-server ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 34m
service/monitoring-grafana NodePort 10.99.24.54 <none> 80:30002/TCP 26s
service/monitoring-influxdb ClusterIP 10.111.169.94 <none> 8083/TCP,8086/TCP 26s
Sprawdź wynik z metrics-server:
kubectl top pods
Wynik powinien wyglądać podobnie do:
NAME CPU(cores) MEMORY(bytes)
hello-node-ccf4b9788-4jn97 1m 6Mi
Jeśli zobaczysz następującą wiadomość, poczekaj i spróbuj ponownie:
error: Metrics API not available
Wyłącz dodatek metrics-server:
minikube addons disable metrics-server
Wynik powinien wyglądać podobnie do:
metrics-server was successfully disabled
Teraz jest czas na wyczyszczenie zasobów, które utworzyłeś w klastrze:
kubectl delete service hello-node
kubectl delete deployment hello-node
Zatrzymaj wirtualną maszynę Minikube (VM):
minikube stop
(Opcjonalnie) Skasuj Minikube VM:
# Optional
minikube delete
Jeżeli planujesz ponownie używać minikube do dalszej nauki Kubernetesa, nie musisz go usuwać.
Ta strona obejmowała podstawowe aspekty dotyczące uruchomienia klastra minikube. Teraz jesteś gotowy do wdrażania aplikacji.
Ten samouczek poprowadzi Cię przez podstawy systemu zarządzania zadaniami na klastrze Kubernetesa. W każdym module znajdziesz najważniejsze informacje o głównych pojęciach i funkcjonalnościach Kubernetesa. Dzięki samouczkom nauczysz się zarządzać prostym klasterem i skonteneryzowanymi aplikacjami uruchamianymi na tym klastrze.
Nauczysz się, jak:
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.
Poznaj klaster Kubernetesa i naucz się, jak stworzyć jego prostą wersję przy pomocy Minikube.
Polecenia w tym poradniku są napisane w składni zgodnej ze standardem POSIX, którą
obsługują domyślne powłoki w Linuxie i macOS (np. bash, zsh, sh). Jeśli
używasz Windowsa, potrzebujesz powłoki zgodnej z POSIX, np. WSL
Windows Subsystem for Linux (WSL) lub
Git Bash, żeby
uruchomić je w takiej formie. Polecenia z export, $() i podobnymi
elementami nie zadziałają w PowerShellu ani w zwykłym wierszu polecenia.
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 Kubernetesa składa się z dwóch rodzajów zasobów:
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 Kubernetesa. 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 CRI-O. Klaster Kubernetesa w środowisku produkcyjnym powinien składać się minimum z trzech węzłów, ponieważ w przypadku awarii jednego węzła traci się zarówno element etcd, jak i warstwy sterowania przy jednoczesnym zachowaniu minimalnej nadmiarowości (redundancy). Dodanie kolejnych węzłów warstwy sterowania może temu zapobiec.
Kiedy instalujesz aplikację na Kubernetesie, zlecasz warstwie sterowania uruchomienie kontenera z aplikacją. Warstwa sterowania zleca uruchomienie kontenera na węzłach klastra. Komponenty działające na poziomie węzła, takie jak kubelet, 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 Kubernetesa 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.
Polecenia w tym poradniku są napisane w składni zgodnej ze standardem POSIX, którą
obsługują domyślne powłoki w Linuxie i macOS (np. bash, zsh, sh). Jeśli
używasz Windowsa, potrzebujesz powłoki zgodnej z POSIX, np. WSL
Windows Subsystem for Linux (WSL) lub
Git Bash, żeby
uruchomić je w takiej formie. Polecenia z export, $() i podobnymi
elementami nie zadziałają w PowerShellu ani w zwykłym wierszu polecenia.
Mając działający klaster Kubernetesa, można na nim zacząć instalować aplikacje. W tym celu należy utworzyć Deployment. Deployment informuje Kubernetesa, jak tworzyć i aktualizować instancje Twojej aplikacji. Po stworzeniu Deploymentu, warstwa sterowania Kubernetesa zleca uruchomienie tej aplikacji na indywidualnych węzłach klastra.
Po utworzeniu instancji aplikacji, kontroler Deploymentu Kubernetesa 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, kontroler Deploymentu zamieni tę instancję z instancją na innym węźle klastra. W ten sposób działa samonaprawiają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 Kubernetesa oferuje fundamentalnie różne podejście do zarządzania aplikacjami.
Do tworzenia i zarządzaniem Deploymentem służy polecenie linii komend, kubectl. Kubectl używa API Kubernetesa 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 Kubernetesa.
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ł 5 oraz Moduł 6 omawiają skalowanie i aktualizowanie Deploymentó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 samouczku Hello Minikube.)
Musisz mieć zainstalowane narzędzie kubectl. Jeśli potrzebujesz go zainstalować, odwiedź install tools.
Skoro wiesz już, czym są Deploymenty, przeprowadźmy wdrożenie pierwszej aplikacji!
Typowy format polecenia kubectl to: kubectl akcja zasób.
Wykonuje określoną akcję (jak create, describe lub delete) na określonym
zasobie (jak node lub deployment). Możesz użyć --help po poleceniu, aby uzyskać dodatkowe
informacje o możliwych parametrach (na przykład: kubectl get nodes --help).
Sprawdź, czy kubectl jest skonfigurowany do komunikacji z twoim klastrem, uruchamiając polecenie kubectl version.
Sprawdź, czy kubectl jest zainstalowane oraz czy możesz zobaczyć zarówno wersję klienta, jak i serwera.
Aby wyświetlić węzły w klastrze, uruchom polecenie kubectl get nodes.
Zobaczysz dostępne węzły. Kubernetes wybierze, gdzie wdrożyć naszą aplikację, w oparciu o dostępne zasoby węzła.
Uruchommy naszą pierwszą aplikację na Kubernetesie, używając polecenia
kubectl create deployment. Musimy podać nazwę wdrożenia oraz lokalizację obrazu
aplikacji (w tym pełny adres URL repozytorium dla obrazów hostowanych poza Docker Hub).
kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1
Świetnie! Właśnie wdrożyłeś swoją pierwszą aplikację, tworząc Deployment. Kubernetes wykonał dla Ciebie kilka rzeczy:
Aby wyświetlić listę swoich wdrożeń, użyj polecenia kubectl get deployments:
kubectl get deployments
Widzimy, że jest jeden Deployment uruchamiający pojedynczą instancję Twojej aplikacji. Instancja działa wewnątrz kontenera na Twoim węźle.
Pody działające wewnątrz Kubernetesa
działają na prywatnej, izolowanej sieci. Domyślnie są one widoczne z innych
podów i usług w ramach tego samego klastra Kubernetesa, ale nie poza tą
siecią. Kiedy używamy kubectl, komunikujemy się z aplikacją za pośrednictwem API.
Później, w Module 4, omówimy
inne opcje dotyczące sposobów udostępniania Twojej aplikacji poza klastrem
Kubernetesa. Ponieważ jest to tylko podstawowy samouczek, to nie wyjaśniamy
tutaj szczegółowo, czym są Pody, bo będzie to omówione w późniejszych tematach.
Polecenie kubectl proxy może utworzyć proxy, które przekaże komunikację do
ogólnoklastrowej, prywatnej sieci. Proxy można zakończyć poprzez
naciśnięcie control-C - podczas działania nie wyświetla ono żadnych komunikatów.
Musisz otworzyć drugie okno terminala, aby uruchomić proxy.
kubectl proxy
Mamy teraz połączenie pomiędzy naszym hostem (terminalem) a klastrem Kubernetesa. Proxy umożliwia bezpośredni dostęp do API z tych terminali.
Możesz zobaczyć wszystkie te interfejsy API hostowane przez punkt końcowy serwera proxy.
Na przykład możemy bezpośrednio zapytać o wersję za pomocą polecenia curl:
curl http://localhost:8001/version
kubectl proxy, który uruchomiłeś wyżej, działa w drugim terminalu.Serwer API automatycznie utworzy punkt końcowy dla każdego poda, bazując na nazwie poda, który jest również dostępny przez serwer proxy.
Najpierw musimy uzyskać nazwę Poda i zapisać 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
Możesz uzyskać dostęp do Poda za pośrednictwem API z proxy, uruchamiając:
curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/
Aby nowy Deployment był dostępny bez użycia proxy, wymagane jest utworzenie obiektu usługi (ang. Service), co zostanie wyjaśnione w Module 4.
Polecenia w tym poradniku są napisane w składni zgodnej ze standardem POSIX, którą
obsługują domyślne powłoki w Linuxie i macOS (np. bash, zsh, sh). Jeśli
używasz Windowsa, potrzebujesz powłoki zgodnej z POSIX, np. WSL
Windows Subsystem for Linux (WSL) lub
Git Bash, żeby
uruchomić je w takiej formie. Polecenia z export, $() i podobnymi
elementami nie zadziałają w PowerShellu ani w zwykłym wierszu polecenia.
Po stworzeniu Deploymentu w Module 2, Kubernetes stworzył Pod, który "przechowuje" instancję Twojej aplikacji. Pod jest obiektem abstrakcyjnym Kubernetesa, 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ć:
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 Kubernetesa, 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.
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 Kubernetesa 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.
W module 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 zasobachkubectl describe - pokaż szczegółowe informacje na temat konkretnego zasobukubectl logs - wyświetl logi z kontenera w danym podziekubectl exec - wykonaj komendę wewnątrz kontenera w danym podzieKorzystaj 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.
Sprawdźmy, czy aplikacja, którą wdrożyliśmy w poprzednim scenariuszu, działa.
Użyjemy polecenia kubectl get i poszukamy istniejących Podów:
kubectl get pods
Jeśli żadne pody nie działają, poczekaj kilka sekund i ponownie wylistuj pody. Możesz kontynuować, gdy zobaczysz działający jeden pod.
Następnie, aby zobaczyć, jakie kontenery znajdują się w tym Podzie i jakie obrazy
są używane do budowy tych kontenerów, uruchamiamy polecenie kubectl describe pods:
kubectl describe pods
Widzimy tutaj szczegóły dotyczące kontenera Pod: adres IP, używane porty oraz listę zdarzeń związanych z cyklem życia Poda.
Wyjście komendy describe jest obszerne i obejmuje niektóre pojęcia, których jeszcze nie
omawialiśmy, ale nie martw się tym, bo staną się one zrozumiałe przed końcem tego bootcampu.
describe może być używana do uzyskania szczegółowych informacji o większości
obiektów Kubernetesa, w tym o Węzłach, Podach i Deploymentach. Wyjście komendy
describe jest zaprojektowane tak, aby było czytelne dla ludzi, a nie do wykorzystania w skryptach.Pamiętaj, że Pody działają w izolowanej, prywatnej sieci - więc musimy
przepuścić do nich dostęp, aby móc je debugować i wchodzić z nimi w interakcję. Aby
to zrobić, użyjemy polecenia kubectl proxy, aby uruchomić proxy w
drugim terminalu. Otwórz nowe okno terminala, a w tym nowym terminalu uruchom:
kubectl proxy
Teraz ponownie uzyskamy nazwę Poda i zapytamy ten pod bezpośrednio przez
proxy. Aby uzyskać nazwę Poda i zapisać 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 zobaczyć wyniki działania naszej aplikacji, wykonaj polecenie curl:
curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/
URL jest ścieżką do API Poda.
Możemy wykonywać polecenia bezpośrednio na kontenerze po
uruchomieniu i działaniu Poda. Do tego celu używamy podpolecenia exec i
używamy nazwy Poda jako parametru. Wymieńmy zmienne środowiskowe:
kubectl exec "$POD_NAME" -- env
Warto ponownie wspomnieć, że nazwa samego kontenera może zostać pominięta, ponieważ w Podzie mamy tylko jeden kontener.
Następnie rozpocznijmy sesję bash w kontenerze Pod:
kubectl exec -ti $POD_NAME -- bash
Mamy teraz otwartą konsolę na kontenerze, w którym uruchamiamy naszą
aplikację NodeJS. Kod źródłowy aplikacji znajduje się w pliku server.js:
cat server.js
Możesz sprawdzić, czy aplikacja działa, wykonując polecenie curl:
curl http://localhost:8080
localhost, ponieważ wykonaliśmy polecenie wewnątrz Podu
NodeJS. Jeśli nie możesz połączyć się z localhost:8080, upewnij się, że uruchomiłeś
polecenie kubectl exec i wykonujesz polecenie z wnętrza Podu.Aby zamknąć połączenie z kontenerem, wpisz exit.
Polecenia w tym poradniku są napisane w składni zgodnej ze standardem POSIX, którą
obsługują domyślne powłoki w Linuxie i macOS (np. bash, zsh, sh). Jeśli
używasz Windowsa, potrzebujesz powłoki zgodnej z POSIX, np. WSL
Windows Subsystem for Linux (WSL) lub
Git Bash, żeby
uruchomić je w takiej formie. Polecenia z export, $() i podobnymi
elementami nie zadziałają w PowerShellu ani w zwykłym wierszu polecenia.
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.
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:
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.
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"
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
! Because you are using a Docker driver on darwin, the terminal needs to be open to run it.
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.
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.
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.
Samouczek Uruchamianie wielu instancji aplikacji.
Dowiedz się więcej o Usłudze.
Polecenia w tym poradniku są napisane w składni zgodnej ze standardem POSIX, którą
obsługują domyślne powłoki w Linuxie i macOS (np. bash, zsh, sh). Jeśli
używasz Windowsa, potrzebujesz powłoki zgodnej z POSIX, np. WSL
Windows Subsystem for Linux (WSL) lub
Git Bash, żeby
uruchomić je w takiej formie. Polecenia z export, $() i podobnymi
elementami nie zadziałają w PowerShellu ani w zwykłym wierszu polecenia.
Poprzednio stworzyliśmy Deployment i udostępniliśmy go publicznie korzystając z Service. 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.
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
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 Kubernetesie 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.
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.
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:
Aby zobaczyć ReplicaSet utworzony przez Deployment, uruchom:
kubectl get rs
Zauważ, że nazwa ReplicaSet jest zawsze sformatowana jako
Dwie istotne kolumny tego wyniku to:
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.
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
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
! Because you are using a Docker driver on darwin, the terminal needs to be open to run it.
Następnie użyj podany URL, aby uzyskać dostęp do aplikacji:
curl 127.0.0.1:51082
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.
Samouczek Aktualizacje Rolling Update.
Dowiedz się więcej o ReplicaSet.
Dowiedz się więcej o Autoskalowaniu.
Wykonaj aktualizację Rolling Update używając kubectl.
Polecenia w tym poradniku są napisane w składni zgodnej ze standardem POSIX, którą
obsługują domyślne powłoki w Linuxie i macOS (np. bash, zsh, sh). Jeśli
używasz Windowsa, potrzebujesz powłoki zgodnej z POSIX, np. WSL
Windows Subsystem for Linux (WSL) lub
Git Bash, żeby
uruchomić je w takiej formie. Polecenia z export, $() i podobnymi
elementami nie zadziałają w PowerShellu ani w zwykłym wierszu polecenia.
Użytkownicy oczekują, że aplikacje są dostępne non-stop, a deweloperzy chcieliby móc wprowadzać nowe wersje nawet kilka razy dziennie. W Kubernetesie 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 Kubernetesie, każda aktualizacja ma nadany numer wersji i każdy Deployment może być wycofany do wersji poprzedniej (stabilnej).
Podczas płynnych aktualizacji (ang. rolling update) utrzymywana jest dostępność aplikacji przez kierowanie ruchu wyłącznie do Podów obsługujących żądania. Rolling update umożliwia następujące działania:
W ramach tego interaktywnego samouczka zaktualizujemy aplikację do nowej wersji, a następnie wycofamy tę aktualizację.
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
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).
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 polecenia get pods, aby ponownie wyświetlić listę Podów:
kubectl get pods
Aby sprawdzić obraz wdrożony na działających Podach, użyj polecenia 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