Wdrażanie, skalowanie i aktualizowanie witryny przy użyciu Google Kubernetes Engine (GKE)

1. Wprowadzenie

Obsługa witryn internetowych i aplikacji to niełatwa sprawa.

W najbardziej niepożądanych momentach dochodzi do usterek, serwery ulegają awarii, wzrost zainteresowania sprawia, że coraz większe jest wykorzystanie zasobów, a wprowadzanie zmian bez przestojów jest skomplikowane i stresujące.

Wyobraź sobie narzędzie, które mogłoby Ci w tym pomóc, a nawet zautomatyzować te działania. Dzięki GKE jest to nie tylko możliwe, ale wręcz banalnie proste. W tym module wcielisz się w rolę programisty prowadzącego stronę internetową typu e-commerce dla fikcyjnej firmy Fancy Store. Ze względu na problemy ze skalowaniem i awariami musisz wdrożyć aplikację w GKE.

Ćwiczenia zostały ułożone w kolejności wykonywania typowych zadań przez programistę w chmurze:

  1. utworzyć klaster GKE,
  2. Utwórz kontener Dockera.
  3. Wdróż kontener w GKE.
  4. Udostępnij kontener za pomocą usługi.
  5. Skaluj kontener przez utworzenie wielu replik.
  6. Zmodyfikuj witrynę.
  7. wdrażać nową wersję z zerowym czasem przestoju,

Diagram architektury

ddba666bd2b02d0d.png

Czego się nauczysz

  • Jak utworzyć klaster GKE
  • Jak utworzyć obraz Dockera
  • jak wdrożyć obrazy Dockera w środowisku Kubernetes,
  • jak skalować aplikacje w środowisku Kubernetes,
  • jak wykonywać kroczące aktualizacje aplikacji w środowisku Kubernetes.

Wymagania wstępne

  • Konto Google z dostępem administracyjnym do tworzenia projektów lub projekt z rolą właściciela projektu
  • Podstawowa znajomość technologii Docker i Kubernetes (jeśli nie masz podstawowej wiedzy, zapoznaj się z informacjami o DockerzeKubernetes).

2. Konfigurowanie środowiska

Samodzielne konfigurowanie środowiska

Jeśli nie masz jeszcze konta Google, musisz je utworzyć. Zaloguj się w konsoli Google Cloud i utwórz nowy projekt.

53dad2cefdae71da.png

Screenshot from 2016-02-10 12:45:26.png

Pamiętaj, że identyfikator projektu jest unikalną nazwą we wszystkich projektach Google Cloud (podana powyżej nazwa jest już zajęta i nie będzie działać w Twoim przypadku). Będzie on dalej występować jako PROJECT_ID.

Następnie musisz włączyć płatności w konsoli Google Cloud, aby korzystać z zasobów Google Cloud. Nowi użytkownicy Google Cloud mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD. Jeśli nie jesteś nowym użytkownikiem, nie martw się, ponieważ ten codelab nie powinien kosztować więcej niż kilka dolarów. Jeśli jednak wykorzystasz więcej zasobów lub pozostawisz je uruchomione, codelab może kosztować więcej (patrz sekcja „zwalnianie miejsca” na końcu). Więcej informacji znajdziesz w cenniku.

Cloud Shell

Chociaż możesz zdalnie korzystać z Google Cloud i GKE na laptopie, w tym module użyjesz Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.

Ta maszyna wirtualna oparta na Debianie zawiera wszystkie potrzebne narzędzia dla programistów. Zawiera również stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie zwiększa wydajność sieci i usprawnia proces uwierzytelniania. Oznacza to, że do ukończenia tego ćwiczenia potrzebujesz tylko przeglądarki (działa ona na Chromebooku).

  1. Aby aktywować Cloud Shell w konsoli Cloud, kliknij Aktywuj Cloud Shell fEbHefbRynwXpq1vj2wJw6Dr17O0np8l-WOekxAZYlZQIORsWQE_xJl-cNhogjATLn-YxLVz8CgLvIW1Ncc0yXKJsfzJGMYgUeLsVB7zSwz7p6ItNgx4tXqQjag7BfWPcZN5kP-X3Q (udostępnienie środowiska i połączenie się z nim powinno zająć tylko kilka chwil).

I5aEsuNurCxHoDFjZRZrKBdarPPKPoKuExYpdagmdaOLKe7eig3DAKJitIKyuOpuwmrMAyZhp5AXpmD_k66cBuc1aUnWlJeSfo_aTKPY9aNMurhfegg1CYaE11jdpSTYNNIYARe01A

Screen Shot 2017-06-14 at 10.13.43 PM.png

Po połączeniu z Cloud Shell zobaczysz, że uwierzytelnianie zostało już przeprowadzone, a projekt jest już ustawiony na Twój identyfikator projektu PROJECT_ID.

gcloud auth list

Wynik polecenia

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)
gcloud config list project

Wynik polecenia

[core]
project = <PROJECT_ID>

Jeśli z jakiegoś powodu projekt nie jest ustawiony, po prostu wydaj to polecenie:

gcloud config set project <PROJECT_ID>

Szukasz urządzenia PROJECT_ID? Sprawdź, jakiego identyfikatora użyto w krokach konfiguracji, lub wyszukaj go w panelu konsoli Cloud:

R7chO4PKQfLC3bvFBNZJALLTUiCgyLEq_67ECX7ohs_0ZnSjC7GxDNxWrJJUaoM53LnqABYamrBJhCuXF-J9XBzuUgaz7VvaxNrkP2TAn93Drxccyj2-5zz4AxL-G3hzxZ4PsM5HHQ

Cloud Shell domyślnie ustawia też niektóre zmienne środowiskowe, które mogą być przydatne podczas wykonywania kolejnych poleceń.

echo $GOOGLE_CLOUD_PROJECT

Wynik polecenia

<PROJECT_ID>
  1. Na koniec ustaw domyślną strefę i konfigurację projektu.
gcloud config set compute/zone us-central1-f

Możesz wybrać różne strefy. Więcej informacji znajdziesz w artykule Regiony i strefy.

3. Tworzenie klastra GKE

Skoro masz już działające środowisko programistyczne, potrzebujesz teraz klastra GKE, w którym wdrożysz swoją witrynę. Przed utworzeniem klastra upewnij się, że są włączone odpowiednie interfejsy API. Aby włączyć interfejs API kontenerów, uruchom to polecenie:

gcloud services enable container.googleapis.com

Teraz możesz utworzyć klaster. Aby utworzyć klaster o nazwie fancy-cluster z 3 węzłami, wykonaj te czynności:

gcloud container clusters create fancy-cluster --num-nodes 3

Tworzenie klastra może potrwać kilka minut. Następnie uruchom to polecenie, aby wyświetlić 3 instancje robocze maszyn wirtualnych w klastrze:

gcloud compute instances list

Dane wyjściowe:

NAME                                          ZONE        MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
gke-fancy-cluster-default-pool-ad92506d-1ng3  us-east4-a  n1-standard-1               10.150.0.7   XX.XX.XX.XX    RUNNING
gke-fancy-cluster-default-pool-ad92506d-4fvq  us-east4-a  n1-standard-1               10.150.0.5   XX.XX.XX.XX    RUNNING
gke-fancy-cluster-default-pool-ad92506d-4zs3  us-east4-a  n1-standard-1               10.150.0.6   XX.XX.XX.XX    RUNNING

Klaster i powiązane z nim informacje możesz też wyświetlić w konsoli Cloud. W lewym górnym rogu kliknij przycisk menu, przewiń w dół do Kubernetes Engine i kliknij Klastry. Zobaczysz klaster o nazwie fancy-cluster.

795c794b03c5d2b0.png

6b394dfb8a6031f2.png

Gratulacje! Udało Ci się utworzyć pierwszy klaster.

4. Klonowanie repozytorium źródłowego

Ponieważ mamy do czynienia z istniejącą witryną, wystarczy sklonować źródło z repozytorium, dzięki czemu będzie można skoncentrować się na tworzeniu obrazów Dockera i ich wdrażaniu w GKE.

Uruchom te polecenia, aby sklonować repozytorium źródłowe do instancji Cloud Shell i przejść do odpowiedniego katalogu. Zainstalujesz też zależności Node.js, aby móc przetestować aplikację przed wdrożeniem.

cd ~
git clone https://github.com/googlecodelabs/monolith-to-microservices.git
cd ~/monolith-to-microservices
./setup.sh

Spowoduje to sklonowanie repozytorium, zmianę katalogu i zainstalowanie zależności potrzebnych do lokalnego uruchomienia aplikacji. Działanie tego skryptu może potrwać kilka minut.

Zachowaj należytą staranność i przetestuj aplikację. Aby uruchomić serwer WWW, wykonaj to polecenie:

cd ~/monolith-to-microservices/monolith
npm start

Dane wyjściowe:

Monolith listening on port 8080!

Aby wyświetlić podgląd aplikacji, kliknij ikonę podglądu w przeglądarce w menu Cloud Shell i wybierz Podejrzyj na porcie 8080.

5869738f0e9ec386.png

Powinno otworzyć się nowe okno, w którym zobaczysz działającą stronę internetową swojego sklepu Fancy Store.

9ed25c3f0cbe62fa.png

Po wyświetleniu witryny możesz zamknąć to okno. Aby zatrzymać proces serwera WWW, naciśnij Control+C (Windows lub Mac) w oknie terminala.

5. Tworzenie kontenera Dockera za pomocą Cloud Build

Po przygotowaniu plików źródłowych nadszedł czas na umieszczenie aplikacji w kontenerze Dockera.

Ten proces składa się zwykle z 2 kroków obejmujących utworzenie kontenera Dockera i przeniesienie go do rejestru w celu zapisania obrazu pobieranego potem przez GKE. Możesz jednak ułatwić sobie zadanie, korzystając z Cloud Build, aby za pomocą jednego polecenia utworzyć kontener Dockera i umieścić obraz w Container Registry. (Aby prześledzić proces ręcznego tworzenia pliku Dockera i jego przenoszenia, zapoznaj się z krótkim wprowadzeniem do Container Registry).

Cloud Build skompresuje pliki znajdujące się w katalogu i przeniesie je do zasobnika Cloud Storage. Następnie w procesie kompilacji wszystkie pliki z zasobnika razem z plikiem Dockerfile zostaną użyte do uruchomienia procesu kompilacji Dockera. Ponieważ dla obrazu Dockera określono flagę --tag z hostem gcr.io, wynikowy obraz Dockera zostanie przeniesiony do Container Registry.

Najpierw musisz włączyć interfejs Cloud Build API, uruchamiając to polecenie:

gcloud services enable cloudbuild.googleapis.com

Po włączeniu interfejsu API uruchom w Cloud Shell to polecenie, aby rozpocząć proces kompilacji:

cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 .

Ten proces może potrwać kilka minut, a po jego zakończeniu w terminalu pojawią się dane wyjściowe podobne do tych poniżej:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                  IMAGES                              STATUS
1ae295d9-63cb-482c-959b-bc52e9644d53  2019-08-29T01:56:35+00:00  33S       gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz  gcr.io/<PROJECT_ID>/monolith:1.0.0  SUCCESS

Aby wyświetlić historię kompilacji lub obserwować ten proces w czasie rzeczywistym, otwórz Cloud Console. W lewym górnym rogu kliknij przycisk menu, przewiń w dół do sekcji CI/CD, a następnie kliknij Cloud Build i Historia. Znajdziesz tam listę swoich poprzednich kompilacji, ale powinna być tam tylko ta, którą utworzono.

4c753ede203255f6.png

Po kliknięciu identyfikatora kompilacji zostaną wyświetlone wszystkie szczegóły kompilacji, w tym dane wyjściowe dzienników.

Na stronie szczegółów kompilacji możesz wyświetlić utworzony obraz kontenera, klikając nazwę obrazu w sekcji informacji o kompilacji.

6e88ed1643dfe629.png

6. Wdrażanie kontenera w GKE

Po skonteneryzowaniu witryny i przeniesieniu kontenera do Container Registry możesz wdrożyć go w Kubernetes.

Aby móc wdrażać aplikacje w klastrze GKE i nimi zarządzać, należy skomunikować się z systemem zarządzania klastrami Kubernetes. Zwykle robi się to za pomocą narzędzia wiersza poleceń kubectl.

Kubernetes prezentuje aplikacje jako pody, czyli jednostki reprezentujące kontener (lub grupę ściśle połączonych kontenerów). Pod to najmniejsza możliwa do wdrożenia jednostka w Kubernetes. W tym przypadku każdy pod zawiera tylko kontener aplikacji monolitycznej.

Aby wdrożyć aplikację, musisz utworzyć wdrożenie. Deployment zarządza wieloma kopiami aplikacji nazywanymi replikami i planuje ich uruchamianie w poszczególnych węzłach w klastrze. W tym przypadku Deployment uruchomi tylko jeden pod Twojej aplikacji. Aby wszystko działało bezproblemowo, zasoby Deployment tworzą kontroler ReplicaSet. ReplicaSet odpowiada za to, aby zawsze działała określona liczba replik.

Polecenie kubectl create deployment powoduje utworzenie w klastrze Kubernetes zasobu Deployment o nazwie monolith1 repliką.

Uruchom to polecenie, aby wdrożyć swoją aplikację:

kubectl create deployment monolith --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0

Sprawdzanie wdrożenia

Aby sprawdzić, czy wdrożenie zostało utworzone, uruchom to polecenie (zmiana stanu poda na „Uruchomiono” może chwilę potrwać):

kubectl get all

Dane wyjściowe:

NAME                            READY   STATUS    RESTARTS   AGE
pod/monolith-7d8bc7bf68-htm7z   1/1     Running   0          6m21s

NAME                 TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.27.240.1   <none>        443/TCP   24h

NAME                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/monolith   1         1         1            1           20m

NAME                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/monolith-7d8bc7bf68   1         1         1       20m

Dane wyjściowe pokazują kilka elementów: Widać zasób Deployment, który jest aktualny, kontroler ReplicaSet z pożądaną liczbą podów równą 1 oraz działający pod. Wygląda na to, że udało Ci się utworzyć wszystkie elementy.

Aby wyświetlić poszczególne zasoby, możesz uruchomić te polecenia:

# Show pods
kubectl get pods

# Show deployments
kubectl get deployments

# Show replica sets
kubectl get rs

#You can also combine them
kubectl get pods,deployments

Aby zobaczyć pełnię możliwości Kubernetes, warto przeprowadzić symulację awarii serwera przez usunięcie poda i sprawdzić, co się stanie.

Skopiuj nazwę poda z poprzedniego polecenia i uruchom to polecenie, aby go usunąć:

kubectl delete pod/<POD_NAME>

Jeśli zdążysz, możesz uruchomić poprzednie polecenie, aby ponownie wyświetlić wszystkie pody. Zobaczysz wtedy 2 pody: jeden w fazie końcowej oraz drugi w fazie powstawania lub uruchomienia:

kubectl get all

Dane wyjściowe:

NAME                            READY   STATUS        RESTARTS   AGE
pod/monolith-7d8bc7bf68-2bxts   1/1     Running       0          4s
pod/monolith-7d8bc7bf68-htm7z   1/1     Terminating   0          9m35s

NAME                 TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.27.240.1   <none>        443/TCP   24h

NAME                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/monolith   1         1         1            1           24m

NAME                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/monolith-7d8bc7bf68   1         1         1       24m

Jaka była tego przyczyna? Kontroler ReplicaSet odnotował, że jeden pod kończy swoje działanie, i wywołał uruchomienie drugiego, tak aby utrzymana została pożądana liczba replik. W dalszej części modułu dowiesz się, jak przeprowadzić skalowanie do kilku uruchomionych instancji jednocześnie, tak aby w razie awarii jednej z nich użytkownicy nie doświadczali żadnych przestojów.

7. Udostępnianie wdrożenia GKE

Aplikacja została wdrożona w GKE, ale nie można uzyskać do niej dostępu spoza klastra. Domyślnie kontenery działające w GKE nie są dostępne z internetu, ponieważ nie mają zewnętrznych adresów IP. Musisz bezpośrednio udostępnić aplikację dla ruchu z internetu za pomocą zasobu Service. Usługa zapewnia obsługę sieci i protokołu IP dla podów aplikacji. GKE tworzy dla aplikacji zewnętrzny adres IP oraz system równoważenia obciążenia (podlega opłacie).

Aby udostępnić stronę w internecie, uruchom to polecenie:

kubectl expose deployment monolith --type=LoadBalancer --port 80 --target-port 8080

Dane wyjściowe:

service/monolith exposed

Uzyskiwanie dostępu do usługi

GKE przypisuje zewnętrzny adres IP do zasobu Service, a nie do Deployment. Aby dowiedzieć się, jaki jest zewnętrzny adres IP udostępniony przez GKE dla aplikacji, możesz sprawdzić zasób Service za pomocą polecenia kubectl get service:

kubectl get service

Dane wyjściowe:

NAME         CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
monolith     10.3.251.122    203.0.113.0     80:30877/TCP     3d

Po określeniu zewnętrznego adresu IP aplikacji skopiuj go. Wpisz ten adres URL (np. http://203.0.113.0) w przeglądarce, aby sprawdzić, czy Twoja aplikacja jest dostępna.

9ed25c3f0cbe62fa.png

Powinna wyświetlić się ta sama witryna, którą testowaliśmy wcześniej. Gratulacje! Twoja witryna internetowa działa teraz całkowicie w klastrze Kubernetes.

8. Skalowanie wdrożenia GKE

Wyobraź sobie, że po tym, jak Twoja aplikacja została uruchomiona w GKE i udostępniona w internecie, zyskała ogromną popularność. Potrzebujesz sposobu na przeskalowanie aplikacji na kilka instancji, tak by mogła poradzić sobie ze zwiększonym ruchem. Dowiedz się, jak przeskalować aplikację do 3 replik.

Aby przeskalować wdrożenie do 3 replik, uruchom to polecenie:

kubectl scale deployment monolith --replicas=3

Dane wyjściowe:

deployment.apps/monolith scaled

Weryfikacja skalowanego wdrożenia

Aby sprawdzić, czy skalowanie zasobu Deployment przebiegło pomyślnie, uruchom to polecenie:

kubectl get all

Dane wyjściowe:

NAME                            READY   STATUS    RESTARTS   AGE
pod/monolith-7d8bc7bf68-2bxts   1/1     Running   0          36m
pod/monolith-7d8bc7bf68-7ds7q   1/1     Running   0          45s
pod/monolith-7d8bc7bf68-c5kxk   1/1     Running   0          45s

NAME                 TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)        AGE
service/kubernetes   ClusterIP      10.27.240.1    <none>         443/TCP        25h
service/monolith     LoadBalancer   10.27.253.64   XX.XX.XX.XX   80:32050/TCP   6m7s

NAME                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/monolith   3         3         3            3           61m

NAME                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/monolith-7d8bc7bf68   3         3         3       61m

Powinny być widoczne 3 uruchomione instancje Twojego poda. Zwróć też uwagę, że Twoje wdrożenie oraz zestaw replik występują teraz w pożądanej liczbie: 3.

9. Wprowadzanie zmian w witrynie

Dział marketingu poprosił o zmianę strony głównej witryny. Ich zdaniem powinna zawierać więcej informacji o firmie i produktach, które sprzedaje. W tej sekcji dodasz więcej tekstu do strony głównej, aby spełnić prośbę działu marketingu. Wygląda na to, że jeden z naszych programistów przygotował już odpowiednie zmiany i umieścił je w pliku o nazwie index.js.new. Możesz skopiować plik do folderu index.js, a zmiany zostaną automatycznie zastosowane. Wykonaj podane niżej instrukcje, by wprowadzić odpowiednie zmiany.

Uruchom te polecenia, aby skopiować zaktualizowany plik z poprawną nazwą, a następnie wyświetlić jego zawartość w celu sprawdzenia dokonanych zmian:

cd ~/monolith-to-microservices/react-app/src/pages/Home
mv index.js.new index.js
cat ~/monolith-to-microservices/react-app/src/pages/Home/index.js

Wynikowy kod powinien wyglądać podobnie do tego:

/*
Copyright 2019 Google LLC

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

import React from "react";
import { makeStyles } from "@material-ui/core/styles";
import Paper from "@material-ui/core/Paper";
import Typography from "@material-ui/core/Typography";
const useStyles = makeStyles(theme => ({
  root: {
    flexGrow: 1
  },
  paper: {
    width: "800px",
    margin: "0 auto",
    padding: theme.spacing(3, 2)
  }
}));
export default function Home() {
  const classes = useStyles();
  return (
    <div className={classes.root}>
      <Paper className={classes.paper}>
        <Typography variant="h5">
          Fancy Fashion &amp; Style Online
        </Typography>
        <br />
        <Typography variant="body1">
          Tired of mainstream fashion ideas, popular trends and societal norms?
          This line of lifestyle products will help you catch up with the Fancy trend and express your personal style.
          Start shopping Fancy items now!
        </Typography>
      </Paper>
    </div>
  );
}

Zaktualizowane zostały komponenty React, ale musisz jeszcze utworzyć aplikację React, by wygenerować pliki statyczne. Uruchom to polecenie, by utworzyć aplikację React i skopiować ją do katalogu publicznego usługi monolith:

cd ~/monolith-to-microservices/react-app
npm run build:monolith

Po zaktualizowaniu kodu musisz ponownie utworzyć kontener Dockera i opublikować go w Container Registry. Możesz użyć tego samego polecenia co wcześniej, ale tym razem zaktualizujesz etykietę wersji.

Uruchom to polecenie, aby aktywować nową kompilację Cloud Build ze zaktualizowaną wersją obrazu 2.0.0:

cd ~/monolith-to-microservices/monolith

#Feel free to test your application
npm start

gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .

Aby zatrzymać proces serwera WWW, naciśnij Control+C (Windows lub Mac) w oknie terminala.

W następnej sekcji użyjesz tego obrazu, aby zaktualizować aplikację bez przestojów.

10. Aktualizowanie witryny z zerowym czasem przestoju

Zmiany zostały wprowadzone i dział marketingu jest zadowolony z aktualizacji. Nadszedł czas, aby zaktualizować witrynę bez przerw dla użytkowników. Aby zaktualizować witrynę, wykonaj instrukcje opisane poniżej.

Dzięki aktualizacjom kroczącym GKE Twoja aplikacja pozostanie zawsze dostępna, nawet podczas dokonywanej przez system wymiany instancji starego obrazu kontenera na nowy we wszystkich uruchomionych replikach.

Z wiersza poleceń możesz poinformować Kubernetes, że chcesz zaktualizować obraz swojego wdrożenia do nowej wersji, używając następującego polecenia:

kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0

Dane wyjściowe:

deployment.apps/monolith image updated

Sprawdzanie wdrożenia

Aby sprawdzić aktualizację wdrożenia, uruchom to polecenie:

kubectl get pods

Dane wyjściowe:

NAME                        READY   STATUS              RESTARTS   AGE
monolith-584fbc994b-4hj68   1/1     Terminating         0          60m
monolith-584fbc994b-fpwdw   1/1     Running             0          60m
monolith-584fbc994b-xsk8s   1/1     Terminating         0          60m
monolith-75f4cf58d5-24cq8   1/1     Running             0          3s
monolith-75f4cf58d5-rfj8r   1/1     Running             0          5s
monolith-75f4cf58d5-xm44v   0/1     ContainerCreating   0          1s

Jak widać, tworzone są 3 nowe pody, podczas gdy stare pody są wyłączane. Można stwierdzić, które pody są nowe, a które stare, na podstawie wartości w kolumnie AGE. Ostatecznie widoczne będą znowu tylko 3 pody – te zaktualizowane.

Aby sprawdzić zmiany, ponownie przejdź do zewnętrznego adresu IP systemu równoważenia obciążenia i zwróć uwagę na zaktualizowaną aplikację.

Jeśli zapomnisz adresu IP, uruchom to polecenie, aby wyświetlić listę usług i adres IP:

kubectl get svc

W Twojej witrynie powinien być teraz widoczny tekst dodany do komponentu strony głównej.

8006c9938dbd5aa5.png

11. Czyszczenie danych

Usuwanie repozytorium Git

cd ~
rm -rf monolith-to-microservices

Usuwanie obrazów Container Registry

UWAGA: jeśli masz inne wersje, możesz użyć tej samej składni, aby je usunąć. W tym samouczku zakłada się, że masz tylko 2 tagi.

# Delete the container image for version 1.0.0 of our monolith
gcloud container images delete gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 --quiet

# Delete the container image for version 2.0.0 of our monolith
gcloud container images delete gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 --quiet

Usuwanie artefaktów Cloud Build z Cloud Storage

UWAGA: jeśli Cloud Build został użyty do utworzenia artefaktów innych niż te, które są używane w tym laboratorium, musisz ręcznie usunąć źródło z zasobnika Cloud Storage gs://<PROJECT_ID>_cloudbuild/source.

# The following command will take all source archives from all builds and delete them from cloud storage

# Run this command to print all sources:
# gcloud builds list | awk 'NR > 1 {print $4}'

gcloud builds list | awk 'NR > 1 {print $4}' | while read line; do gsutil rm $line; done

Usuwanie usługi GKE

kubectl delete service monolith
kubectl delete deployment monolith

Usuwanie klastra GKE

gcloud container clusters delete fancy-cluster

UWAGA: wykonanie tego polecenia może zająć trochę czasu.

12. Gratulacje!

Udało Ci się wdrożyć, przeskalować i zaktualizować witrynę w GKE. Teraz już wiesz, jak korzystać z usług Docker i Kubernetes.

Dodatkowe materiały