Warsztaty Anthos Service Mesh: przewodnik dotyczący modułu

1. ALPHA WORKSHOP

WAŻNA UWAGA: TO WARSZTAT W WERSJI ALFA, KTÓRY JEST PRZEZNACZONY WYŁĄCZNIE DO SZKOLENIA W KLASIE POD KIERUNKIEM INSTRUKTORA.

Link do warsztatów w formie codelabu: bit.ly/asm-workshop

2. Przegląd

Schemat architektury

Warsztaty te to praktyczne szkolenie, podczas którego dowiesz się, jak skonfigurować w GCP usługi rozpowszechniane na całym świecie. Głównymi używanymi technologiami są Google Kubernetes Engine (GKE) do obliczeń i siatka usług Istio do tworzenia bezpiecznych połączeń, dostrzegalności i zaawansowanego kształtowania ruchu. Wszystkie praktyki i narzędzia użyte w tym warsztacie są takie same jak te, których używasz w produkcji.

Plan dnia

• Moduł 0. Wprowadzenie i konfiguracja platformy
• Wprowadzenie i architektura
• Wprowadzenie do siatki usług i Istio/ASM
• Laboratorium: Konfiguracja infrastruktury: przepływ pracy użytkownika
• Przerwa
• QnA
• Moduł 1. Instalowanie, zabezpieczanie i monitorowanie aplikacji za pomocą ASM
• Model repozytorium: wyjaśnienie repozytoriów infrastruktury i Kubernetes
• Laboratorium: wdrażanie przykładowej aplikacji
• Usługi rozproszone i obserwacja
• Lunch
• Laboratorium: widoczność w Stackdriver
• QNA
• Moduł 2. DevOps – wdrażanie kanaryjne, zasady/RBAC
• Wieloklastrowe wykrywanie usług oraz zabezpieczenia i zasady
• Laboratorium: wzajemne uwierzytelnianie TLS
• Wdrożenia do wczesnych testów
• Moduł: wdrożenia do wczesnych testów
• Bezpieczne globalne równoważenie obciążenia w wielu klastrach
• Przerwa
• Laboratorium: zasady autoryzacji
• QNA
• Moduł 3. Operacje dotyczące infrastruktury – aktualizacje platformy
• Elementy składowe usługi Distributed Service
• Laboratorium: skalowanie infrastruktury
• Dalsze kroki

Prezentacje

Slajdy z tych warsztatów znajdziesz pod tym linkiem:

Slajdy z warsztatów ASM

Wymagania wstępne

Zanim przejdziesz do tego warsztatu, musisz spełnić te wymagania:

1. Węzeł organizacji GCP
2. Identyfikator konta rozliczeniowego (użytkownik musi mieć na tym koncie rozliczeniowym rolę administratora odpowiedzialnego za płatności).
3. Rola administratora organizacji na poziomie organizacji dla Twojego użytkownika

3. Konfiguracja infrastruktury – proces administratora

Czynności opisane w tej sekcji wykonuje administrator tworzący warsztaty.

Jeśli jesteś uczestnikiem warsztatów, przejdź do następnej sekcji oznaczonej symbolem Infrastructure Setup - User Workflow.

Wyjaśnienie skryptu warsztatów dotyczących wczytywania

Skrypt o nazwie bootstrap_workshop.sh służy do skonfigurowania początkowego środowiska warsztatów. Możesz użyć tego skryptu, aby skonfigurować jedno środowisko dla siebie lub wiele środowisk dla wielu użytkowników, jeśli prowadzisz te warsztaty jako szkolenie dla wielu osób.

Skrypt warsztatowy dotyczący rozruchu wymaga tych danych wejściowych:

• Nazwa organizacji (np. yourcompany.com) – organizacja, w której tworzysz środowiska na potrzeby warsztatów.
• Identyfikator płatności (np. 12345-12345-12345) – ten identyfikator płatności jest używany do rozliczania wszystkich zasobów używanych podczas warsztatów.
• Numer warsztatu (np. 01) – liczba dwucyfrowa. Jest to przydatne, jeśli w ciągu jednego dnia prowadzisz kilka warsztatów i chcesz śledzić je osobno. Numery warsztatów są też używane do tworzenia identyfikatorów projektów. Oddzielne numery warsztatów ułatwiają uzyskiwanie unikalnych identyfikatorów projektów za każdym razem. Oprócz numeru warsztatu do identyfikatorów projektów używana jest też bieżąca data (w formacie YYMMDD). Połączenie daty i numeru warsztatu zapewnia unikalne identyfikatory projektów.
• Numer pierwszego użytkownika (np. 1) – ten numer oznacza pierwszego użytkownika w warsztacie. Jeśli na przykład chcesz utworzyć warsztat dla 10 użytkowników, możesz ustawić numer pierwszego użytkownika na 1, a numer ostatniego użytkownika na 10.
• Numer użytkownika (np. 10) – ten numer oznacza ostatniego użytkownika w warsztacie. Jeśli na przykład chcesz utworzyć warsztat dla 10 użytkowników, możesz ustawić numer pierwszego użytkownika na 1, a numer ostatniego użytkownika na 10. Jeśli konfigurujesz jedno środowisko (np. dla siebie), ustaw tę samą liczbę użytkowników początkowych i końcowych. Spowoduje to utworzenie jednego środowiska.

Oprócz daty i numeru warsztatu identyfikatory projektów zawierają też numery użytkowników początkowych i końcowych. Identyfikatory użytkowników (którzy biorą udział w warsztatach) są wyznaczane na podstawie numeru użytkownika początkowego i końcowego. Identyfikatory użytkowników zostały opisane w sekcji User schema and permissions performing the workshop.

• Zasobnik GCS administratora (np. my-gcs-bucket-name) – zasobnik GCS służy do przechowywania informacji związanych z warsztatami. Te informacje są używane przez skrypt cleanup_workshop.sh do prawidłowego usuwania wszystkich zasobów utworzonych podczas skryptu warsztatów wczytywania. Administratorzy tworzący warsztaty muszą mieć uprawnienia do odczytu i zapisu w przypadku tego zasobnika.

Skrypt warsztatowy bootstrap wykorzystuje podane powyżej wartości i działa jako skrypt otoki, który wywołuje skrypt setup-terraform-admin-project.sh. Skrypt setup-terraform-admin-project.sh tworzy środowisko warsztatowe dla jednego użytkownika.

Uprawnienia administratora wymagane do uruchomienia warsztatów

W tych warsztatach są 2 rodzaje użytkowników. ADMIN_USER, który tworzy i usuwa zasoby na potrzeby tych warsztatów. Drugą jest MY_USER, która wykonuje czynności w ramach warsztatów. MY_USER ma dostęp tylko do własnych zasobów. ADMIN_USER ma dostęp do wszystkich konfiguracji użytkowników. Jeśli tworzysz tę konfigurację dla siebie, wartości ADMIN_USER i MY_USER są takie same. Jeśli jesteś nauczycielem i tworzysz te warsztaty dla wielu uczniów, wartości ADMIN_USER i MY_USER będą się różnić.

Do korzystania z ADMIN_USER wymagane są te uprawnienia na poziomie organizacji:

• Właściciel – uprawnienia właściciela projektu do wszystkich projektów w organizacji.
• Administrator folderu – może tworzyć i usuwać foldery w organizacji. Każdy użytkownik otrzymuje jeden folder ze wszystkimi zasobami w projekcie.
• Administrator organizacji
• Twórca projektu – możliwość tworzenia projektów w organizacji.
• Usuwanie projektów – możliwość usuwania projektów w organizacji.
• Administrator uprawnień projektu – możliwość tworzenia reguł uprawnień we wszystkich projektach w organizacji.

Oprócz tego ADMIN_USER musi być też administratorem rozliczeń w przypadku identyfikatora płatności użytego na potrzeby warsztatów.

Schemat użytkownika i uprawnienia użytkownika przeprowadzającego warsztaty

Jeśli planujesz utworzyć te warsztaty dla użytkowników (innych niż Ty) w swojej organizacji, musisz zastosować określony schemat nazewnictwa użytkowników dla MY_USERs. Podczas wykonywania skryptu bootstrap_workshop.sh podajesz początkowy i końcowy numer użytkownika. Na podstawie tych numerów tworzone są te nazwy użytkowników:

• user<3 digit user number>@<organization_name>

Jeśli na przykład uruchomisz skrypt warsztatowy z numerem użytkownika początkowego 1 i numerem użytkownika końcowego 3 w organizacji o nazwie twojafirma.pl, zostaną utworzone środowiska warsztatowe dla tych użytkowników:

• [e-mail]
• [e-mail]
• [e-mail]

Te nazwy użytkowników mają przypisane role właściciela projektu w przypadku konkretnych projektów utworzonych za pomocą skryptu setup_terraform_admin_project.sh. Podczas korzystania ze skryptu bootstrap musisz przestrzegać tego schematu nazewnictwa użytkowników. Przeczytaj artykuł jak dodać wielu użytkowników jednocześnie w G Suite.

Narzędzia wymagane podczas warsztatów

Te warsztaty są przeznaczone do uruchamiania z Cloud Shell. Na potrzeby tych warsztatów potrzebne są te narzędzia.

• gcloud (wersja >= 270)
• kubectl
• sed (działa z sed w Cloud Shell/Linux, ale nie w macOS)
• git (upewnij się, że masz aktualną wersję);
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize

Wszystkie narzędzia z wyjątkiem kustomize są już domyślnie zainstalowane w Cloud Shell. Jeśli narzędzie kustomize nie jest zainstalowane, zainstaluj je za pomocą skryptu bash podanego w linku powyżej. Upewnij się, że plik binarny kustomize znajduje się w zmiennej PATH, i potwierdź to, uruchamiając polecenie kustomize w Cloud Shell.

Konfigurowanie warsztatu dla siebie (konfiguracja dla jednego użytkownika)

1. Otwórz Cloud Shell i wykonaj w nim wszystkie poniższe działania. Kliknij link poniżej.

CLOUD SHELL

2. Sprawdź, czy jesteś zalogowany(a) w gcloud jako odpowiedni użytkownik z uprawnieniami administracyjnymi.

gcloud config list
 

3. Utwórz WORKDIR i sklonuj repozytorium warsztatów.

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

4. Określ nazwę organizacji, identyfikator płatności, numer warsztatu i zasobnik GCS administratora, który będzie używany podczas warsztatu. Sprawdź uprawnienia wymagane do skonfigurowania warsztatu w sekcjach powyżej.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<ADMIN_BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

5. Uruchom skrypt bootstrap_workshop.sh. Wykonanie tego skryptu może potrwać kilka minut.

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --set-up-for-admin 
 

Pamiętaj, że nie musisz definiować numeru użytkownika początkowego i końcowego, ponieważ konfigurujesz to dla siebie.

Po zakończeniu działania skryptu bootstrap_workshop.sh dla każdego użytkownika w organizacji zostanie utworzony folder GCP. W folderze zostanie utworzony projekt administratora Terraform. Projekt administratora Terraform służy do tworzenia pozostałych zasobów GCP wymaganych w ramach tych warsztatów. Wymagane interfejsy API włączasz w projekcie administracyjnym Terraform. Do stosowania planów Terraform używasz Cloud Build. Musisz przypisać kontu usługi Cloud Build odpowiednie role IAM, aby mogło tworzyć zasoby w GCP. Na koniec skonfiguruj zdalny backend w zasobniku Google Cloud Storage (GCS), aby przechowywać stany Terraform wszystkich zasobów GCP.

Aby wyświetlić zadania Cloud Build w projekcie administracyjnym Terraform, musisz mieć identyfikator tego projektu. Jest on przechowywany w pliku vars/vars.sh w katalogu asm. Ten katalog jest zachowywany tylko wtedy, gdy konfigurujesz warsztaty dla siebie jako administrator.

6. Uruchom plik zmiennych, aby ustawić zmienne środowiskowe.

echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
source $WORKDIR/asm/vars/vars.sh 
 

Konfigurowanie warsztatu dla wielu użytkowników

7. Otwórz Cloud Shell i wykonaj w nim wszystkie poniższe działania. Kliknij link poniżej.

CLOUD SHELL

8. Sprawdź, czy jesteś zalogowany(a) w gcloud jako odpowiedni użytkownik z uprawnieniami administracyjnymi.

gcloud config list
 

9. Utwórz WORKDIR i sklonuj repozytorium warsztatów.

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

10. Określ nazwę organizacji, identyfikator płatności, numer warsztatu, liczbę użytkowników początkowych i końcowych oraz zasobnik GCS administratora, który będzie używany podczas warsztatu. Sprawdź uprawnienia wymagane do skonfigurowania warsztatu w sekcjach powyżej.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export START_USER_NUMBER=<number for example 1>

export END_USER_NUMBER=<number greater or equal to START_USER_NUM>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

11. Uruchom skrypt bootstrap_workshop.sh. Wykonanie tego skryptu może potrwać kilka minut.

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --start-user-num ${START_USER_NUMBER} --end-user-num ${END_USER_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET}
 

12. Pobierz plik workshop.txt z zasobnika GCS administratora, aby uzyskać identyfikatory projektów Terraform.

export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .
 

4. Konfiguracja i przygotowanie laboratorium

Użytkownicy biorący udział w warsztatach zaczynają tutaj. Wykonaj wszystkie czynności w INCOGNITO w Chrome lub Firefox.

Wybierz ścieżkę modułu

Ćwiczenia w tym warsztacie można wykonać na 2 sposoby:

• Sposób „łatwe, szybkie i interaktywne skrypty”
• Ręczne kopiowanie i wklejanie każdej instrukcji

Metoda skryptów szybkiej ścieżki umożliwia uruchomienie pojedynczego interaktywnego skryptu dla każdego modułu, który przeprowadzi Cię przez moduł, automatycznie uruchamiając polecenia dla tego modułu. Polecenia są wykonywane w partiach, a każdy krok jest krótko wyjaśniony. Po każdej grupie poleceń pojawi się prośba o przejście do następnej grupy. Dzięki temu możesz wykonywać ćwiczenia we własnym tempie. Skrypty szybkiej ścieżki są idempotentne, co oznacza, że możesz je uruchamiać wielokrotnie, a wynik będzie zawsze taki sam.

Skrypty szybkiej ścieżki będą wyświetlane u góry każdego laboratorium w zielonym polu, jak pokazano poniżej.

FAST TRACK SCRIPT

${WORKDIR}/asm/fasttrack_scripts/<name_of_script>.sh

Metoda kopiowania i wklejania to tradycyjny sposób kopiowania i wklejania poszczególnych bloków poleceń wraz z wyjaśnieniami. Ta metoda jest przeznaczona do jednorazowego użycia. Nie ma gwarancji, że ponowne uruchomienie poleceń tą metodą da takie same wyniki.

Podczas wykonywania ćwiczeń wybierz jedną z tych dwóch metod.

Po wybraniu metody i wykonaniu odpowiednich czynności nie wykonuj czynności z innej metody.

Szybka konfiguracja skryptu

Po wykonaniu skryptu szybkiej ścieżki możesz zakończyć to laboratorium. Nie wykonuj czynności opisanych w instrukcjach do laboratorium dotyczących kopiowania i wklejania.

Pobieranie informacji o użytkowniku

Warsztaty są prowadzone z użyciem tymczasowego konta użytkownika (lub konta laboratoryjnego) utworzonego przez administratora warsztatów. Konto laboratorium jest właścicielem wszystkich projektów w warsztacie. Administrator warsztatów udostępnia użytkownikowi przeprowadzającemu warsztaty dane logowania do konta w laboratorium (nazwę użytkownika i hasło). Wszystkie projekty użytkownika mają prefiks w postaci nazwy użytkownika konta laboratorium. Na przykład w przypadku konta laboratorium [e-mail] identyfikator projektu administratora Terraform będzie mieć postać user001-200131-01-tf-abcde i tak dalej w przypadku pozostałych projektów. Każdy uczestnik musi zalogować się na konto w laboratorium udostępnione przez administratora warsztatów i wykonać ćwiczenia w ramach warsztatów, korzystając z tego konta.

Sprawdź swój służbowy adres e-mail (ten sam, którego użyto do rejestracji na warsztaty). Powinieneś(-aś) otrzymać od administratora warsztatów e-maila z danymi logowania do konta w laboratorium (czyli nazwą użytkownika i hasłem). E-mail wygląda tak:

1. Otwórz Cloud Shell, klikając link poniżej.

CLOUD SHELL

2. Zaloguj się przy użyciu danych logowania do konta w laboratorium (nie loguj się na konto firmowe ani osobiste). Konto laboratorium wygląda tak: userXYZ@<workshop_domain>.com.
3. Ponieważ jest to nowe konto, pojawi się prośba o zaakceptowanie Warunków korzystania z usług Google. Kliknij Akceptuję.

4. Na następnym ekranie zaznacz pole wyboru, aby zaakceptować Warunki korzystania z usług Google, a następnie kliknij Start Cloud Shell.

W tym kroku udostępnimy Ci małą maszynę wirtualną z systemem Linux Debian, której możesz używać do uzyskiwania dostępu do zasobów GCP. Każde konto otrzymuje maszynę wirtualną Cloud Shell. Zalogowanie się za pomocą konta w laboratorium powoduje zalogowanie się przy użyciu danych logowania do tego konta. Oprócz Cloud Shell udostępniany jest też edytor kodu, który ułatwia edytowanie plików konfiguracyjnych (terraform, YAML itp.). Domyślnie ekran Cloud Shell jest podzielony na środowisko powłoki Cloud Shell (u dołu) i edytor Cloud Code (u góry). Ikony ołówka i wiersza poleceń  w prawym górnym rogu umożliwiają przełączanie się między tymi dwoma widokami (wierszem poleceń i edytorem kodu). Możesz też przeciągnąć środkowy pasek separatora (w górę lub w dół) i ręcznie zmienić rozmiar każdego okna. 5. Utwórz katalog WORKDIR na potrzeby tych warsztatów. WORKDIR to folder, z którego wykonujesz wszystkie moduły w ramach tych warsztatów. Aby utworzyć WORKDIR, uruchom w Cloud Shell te polecenia:

mkdir -p ${HOME}/asm-workshop
cd ${HOME}/asm-workshop
export WORKDIR=`pwd` 
 

6. Wyeksportuj użytkownika konta laboratorium jako zmienną, która będzie używana w tych warsztatach. Jest to to samo konto, za pomocą którego logujesz się w Cloud Shell.

export MY_USER=<LAB ACCOUNT EMAIL PROVIDED BY THE WORKSHOP ADMIN>
# For example export MY_USER=[e-mail] 
 

Uwaga: jeśli jesteś administratorem i konfigurujesz warsztaty dla siebie za pomocą flag „-sufa” lub „–setup-for-admin”, ustaw MY_USER na adres e-mail konta GCP, którego używasz do tworzenia projektów warsztatowych.

7. Aby sprawdzić, czy zmienne WORKDIR i MY_USER zostały prawidłowo ustawione, uruchom te polecenia:

echo "WORKDIR set to ${WORKDIR}" && echo "MY_USER set to ${MY_USER}"
 

8. Sklonuj repozytorium warsztatów.

git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git ${WORKDIR}/asm
 

5. Konfigurowanie infrastruktury – przepływ pracy użytkownika

Cel: weryfikacja infrastruktury i instalacji Istio

• Instalowanie narzędzi warsztatowych
• Klonowanie repozytorium warsztatów
• Weryfikacja instalacji Infrastructure
• Weryfikacja instalacji k8s-repo
• Weryfikowanie instalacji Istio

FAST TRACK SCRIPT

Jeśli wybierzesz tę metodę, uruchom ten skrypt, aby ukończyć ten moduł.

${WORKDIR}/asm/fasttrack_scripts/infrastructure-setup-user-workflow.sh

Po zakończeniu działania skryptu uruchom plik bashrc, aby zaktualizować zmienne w sesji Cloud Shell.

source ${HOME}/.bashrc

Instrukcje dotyczące modułu z metodą kopiowania i wklejania

WAŻNE: jeśli skrypt szybkiej ścieżki do tego laboratorium został już przez Ciebie wykonany, nie używaj poniższej metody kopiowania i wklejania**.**

Pobieranie informacji o użytkowniku

Administrator konfigurujący warsztaty musi podać użytkownikowi nazwę użytkownika i hasło. Wszystkie projekty użytkownika będą miały przedrostek w postaci nazwy użytkownika. Na przykład w przypadku użytkownika [e-mail] identyfikator projektu administracyjnego Terraform będzie miał postać user001-200131-01-tf-abcde i tak dalej w przypadku pozostałych projektów. Każdy użytkownik ma dostęp tylko do własnego środowiska warsztatowego.

Narzędzia wymagane podczas warsztatów

Te warsztaty są przeznaczone do uruchamiania z Cloud Shell. Na potrzeby tych warsztatów potrzebne są te narzędzia.

Wszystkie narzędzia z wyjątkiem kustomize i pv są domyślnie zainstalowane w Cloud Shell. Instrukcje instalacji obu tych aplikacji znajdziesz poniżej.

• gcloud (wersja >= 270)
• kubectl
• sed (działa z sed w Cloud Shell/Linux, ale nie w macOS)
• git (upewnij się, że masz aktualną wersję);
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize
• pv

Dostęp do projektu administratora Terraform

Po zakończeniu działania skryptu bootstrap_workshop.sh dla każdego użytkownika w organizacji zostanie utworzony folder GCP. W folderze zostanie utworzony projekt administratora Terraform. Projekt administratora Terraform służy do tworzenia pozostałych zasobów GCP wymaganych w ramach tych warsztatów. Skrypt setup-terraform-admin-project.sh włącza wymagane interfejsy API w projekcie administracyjnym Terraform. Cloud Build służy do stosowania planów Terraform. Za pomocą skryptu przyznajesz kontu usługi Cloud Build odpowiednie role IAM, aby mogło tworzyć zasoby w GCP. Na koniec w zasobniku Google Cloud Storage (GCS) skonfigurowano zdalny backend do przechowywania stanów Terraform wszystkich zasobów GCP.

Aby wyświetlić zadania Cloud Build w projekcie administracyjnym Terraform, musisz mieć identyfikator tego projektu. Jest on przechowywany w zasobniku GCS administratora określonym w skrypcie wczytywania. Jeśli skrypt inicjujący jest uruchamiany dla wielu użytkowników, wszystkie identyfikatory projektu administratora Terraform znajdują się w zasobniku GCS.

Te warsztaty są przeznaczone do przeprowadzenia w Cloud Shell i Cloud Console. Wykonaj te czynności w oknie INCOGNITO, ponieważ będziesz logować się za pomocą osobnej nazwy użytkownika i hasła.

1. Otwórz Cloud Shell (jeśli nie jest jeszcze otwarty w sekcji Konfiguracja i przygotowanie modułu) – kliknij link poniżej.

CLOUD SHELL

2. Zainstaluj kustomize (jeśli nie jest jeszcze zainstalowany) w folderze $HOME/bin i dodaj folder $HOME/bin do $PATH.

mkdir -p $HOME/bin
cd $HOME/bin
curl -s "https://raw.githubusercontent.com/\
kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
cd $HOME
export PATH=$PATH:${HOME}/bin
echo "export PATH=$PATH:$HOME/bin" >> $HOME/.bashrc
 

3. Zainstaluj pv i przenieś go do $HOME/bin/pv.

sudo apt-get update && sudo apt-get -y install pv
sudo mv /usr/bin/pv ${HOME}/bin/pv
 

4. Zaktualizuj prompt Basha.

cp $WORKDIR/asm/scripts/krompt.bash $HOME/.krompt.bash
echo "export PATH=\$PATH:\$HOME/bin" >> $HOME/.asm-workshop.bash
echo "source $HOME/.krompt.bash" >> $HOME/.asm-workshop.bash

alias asm-init='source $HOME/.asm-workshop.bash' >> $HOME/.bashrc
echo "source $HOME/.asm-workshop.bash" >> $HOME/.bashrc
source $HOME/.bashrc
 

5. Sprawdź, czy w gcloud logujesz się na odpowiednie konto użytkownika.

echo "Check logged in user output from the next command is $MY_USER"
gcloud config list account --format=json | jq -r .core.account
 

6. Aby uzyskać identyfikator projektu administracyjnego Terraform, uruchom to polecenie:

export TF_ADMIN=$(gcloud projects list | grep tf- | awk '{ print $1 }')
echo $TF_ADMIN
 

7. Wszystkie zasoby powiązane z warsztatami są przechowywane jako zmienne w pliku vars.sh, który znajduje się w zasobniku GCS w projekcie administracyjnym Terraform. Pobierz plik vars.sh dla projektu administracyjnego Terraform.

mkdir $WORKDIR/asm/vars
gsutil cp gs://$TF_ADMIN/vars/vars.sh $WORKDIR/asm/vars/vars.sh
echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
 

8. Kliknij wyświetlony link, aby otworzyć stronę Cloud Build projektu administracyjnego Terraform, i sprawdź, czy kompilacja została ukończona.

source $WORKDIR/asm/vars/vars.sh
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

Jeśli po raz pierwszy uzyskujesz dostęp do konsoli Cloud, zaakceptuj Warunki korzystania z usług Google.

9. Na stronie Cloud Build kliknij link History w menu po lewej stronie, a potem kliknij najnowszą kompilację, aby wyświetlić szczegóły początkowego zastosowania Terraform. W ramach skryptu Terraform tworzone są te zasoby: Możesz też zapoznać się z diagramem architektury powyżej.

• 4 projekty GCP w organizacji. Podane konto rozliczeniowe jest powiązane z każdym projektem.
• Jeden projekt jest network host project dla współdzielonego środowiska VPC. W tym projekcie nie są tworzone żadne inne zasoby.
• Jeden projekt to ops project używany w przypadku klastrów GKE platformy sterującej Istio.
• Dwa projekty reprezentują 2 różne zespoły programistyczne pracujące nad swoimi usługami.
• W każdym z 3 projektów ops, dev1 i dev2 tworzone są 2 klastry GKE.
• Tworzone jest repozytorium CSR o nazwie k8s-repo, które zawiera 6 folderów z plikami manifestu Kubernetes. Jeden folder na klaster GKE. To repozytorium służy do wdrażania plików manifestu Kubernetes w klastrach w sposób GitOps.
• Tworzony jest aktywator kompilacji Cloud Build, który za każdym razem, gdy w gałęzi głównej repozytorium k8s-repo nastąpi zatwierdzenie, wdraża pliki manifestu Kubernetes w klastrach GKE z odpowiednich folderów.

Wykonanie skryptu Terraform zajmuje 40–50 minut.

10. Po zakończeniu kompilacji w projekcie terraform admin project w projekcie operacyjnym rozpocznie się kolejna kompilacja. Kliknij wyświetlony link, aby otworzyć stronę Cloud Build dla ops project, i sprawdź, czy Cloud Build k8s-repo zakończył się pomyślnie.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

Uwaga: zanim zweryfikujesz instalację Istio, musisz ukończyć tę kompilację.

Zweryfikuj instalację

11. Utwórz pliki kubeconfig dla wszystkich klastrów. Uruchom ten skrypt.

$WORKDIR/asm/scripts/setup-gke-vars-kubeconfig.sh
 

Ten skrypt tworzy nowy plik kubeconfig w folderze gke o nazwie kubemesh.

12. Zmień zmienną KUBECONFIG, aby wskazywała nowy plik kubeconfig.

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

13. Dodaj zmienne vars.sh i KUBECONFIG do pliku .bashrc w Cloud Shell, aby były one używane przy każdym ponownym uruchomieniu Cloud Shell.

echo "source ${WORKDIR}/asm/vars/vars.sh" >> $HOME/.bashrc
echo "export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh" >> $HOME/.bashrc
 

14. Wyświetl konteksty klastra. Powinno być widocznych 6 klastrów.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_tf05-01-ops_us-central1_gke-asm-2-r2-prod
gke_tf05-01-ops_us-west1_gke-asm-1-r1-prod
gke_tf05-02-dev1_us-west1-a_gke-1-apps-r1a-prod
gke_tf05-02-dev1_us-west1-b_gke-2-apps-r1b-prod
gke_tf05-03-dev2_us-central1-a_gke-3-apps-r2a-prod
gke_tf05-03-dev2_us-central1-b_gke-4-apps-r2b-prod

Weryfikowanie instalacji Istio

15. Sprawdź, czy Istio jest zainstalowane w obu klastrach, sprawdzając, czy wszystkie pody są uruchomione, a zadania zostały wykonane.

kubectl --context ${OPS_GKE_1} get pods -n istio-system
kubectl --context ${OPS_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-z9f98                  1/1     Running   0          6m21s
istio-citadel-568747d88-qdw64             1/1     Running   0          6m26s
istio-egressgateway-8f454cf58-ckw7n       1/1     Running   0          6m25s
istio-galley-6b9495645d-m996v             2/2     Running   0          6m25s
istio-ingressgateway-5df799fdbd-8nqhj     1/1     Running   0          2m57s
istio-pilot-67fd786f65-nwmcb              2/2     Running   0          6m24s
istio-policy-74cf89cb66-4wrpl             2/2     Running   1          6m25s
istio-sidecar-injector-759bf6b4bc-mw4vf   1/1     Running   0          6m25s
istio-telemetry-77b6dfb4ff-zqxzz          2/2     Running   1          6m24s
istio-tracing-cd67ddf8-n4d7k              1/1     Running   0          6m25s
istiocoredns-5f7546c6f4-g7b5c             2/2     Running   0          6m39s
kiali-7964898d8c-5twln                    1/1     Running   0          6m23s
prometheus-586d4445c7-xhn8d               1/1     Running   0          6m25s

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-2s8k4                  1/1     Running   0          59m
istio-citadel-568747d88-87kdj             1/1     Running   0          59m
istio-egressgateway-8f454cf58-zj9fs       1/1     Running   0          60m
istio-galley-6b9495645d-qfdr6             2/2     Running   0          59m
istio-ingressgateway-5df799fdbd-2c9rc     1/1     Running   0          60m
istio-pilot-67fd786f65-nzhx4              2/2     Running   0          59m
istio-policy-74cf89cb66-4bc7f             2/2     Running   3          59m
istio-sidecar-injector-759bf6b4bc-grk24   1/1     Running   0          59m
istio-telemetry-77b6dfb4ff-6zr94          2/2     Running   4          60m
istio-tracing-cd67ddf8-grs9g              1/1     Running   0          60m
istiocoredns-5f7546c6f4-gxd66             2/2     Running   0          60m
kiali-7964898d8c-nhn52                    1/1     Running   0          59m
prometheus-586d4445c7-xr44v               1/1     Running   0          59m

16. Upewnij się, że Istio jest zainstalowane w obu klastrach dev1. W klastrach dev1 działają tylko usługi Citadel, sidecar-injector i coredns. Współdzielą one platformę sterującą Istio działającą w klastrze ops-1.

kubectl --context ${DEV1_GKE_1} get pods -n istio-system
kubectl --context ${DEV1_GKE_2} get pods -n istio-system
 

17. Upewnij się, że Istio jest zainstalowane w obu klastrach dev2. W klastrach dev2 działają tylko usługi Citadel, sidecar-injector i coredns. Mają wspólną platformę sterującą Istio działającą w klastrze ops-2.

kubectl --context ${DEV2_GKE_1} get pods -n istio-system
kubectl --context ${DEV2_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

Weryfikowanie wykrywania usług w przypadku współdzielonych płaszczyzn sterowania

18. Opcjonalnie sprawdź, czy obiekty tajne zostały wdrożone.

kubectl --context ${OPS_GKE_1} get secrets -l istio/multiCluster=true -n istio-system
kubectl --context ${OPS_GKE_2} get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

For OPS_GKE_1:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      8m7s
gke-2-apps-r1b-prod   Opaque   1      8m7s
gke-3-apps-r2a-prod   Opaque   1      44s
gke-4-apps-r2b-prod   Opaque   1      43s

For OPS_GKE_2:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      40s
gke-2-apps-r1b-prod   Opaque   1      40s
gke-3-apps-r2a-prod   Opaque   1      8m4s
gke-4-apps-r2b-prod   Opaque   1      8m4s

W tych warsztatach użyjesz jednego współdzielonego środowiska VPC, w którym utworzysz wszystkie klastry GKE. Aby wykrywać usługi w klastrach, używasz plików kubeconfig (dla każdego klastra aplikacji) utworzonych jako obiekty tajne w klastrach operacyjnych. Pilot używa tych kluczy tajnych do wykrywania usług, wysyłając zapytania do serwera interfejsu Kube API w klastrach aplikacji (uwierzytelnianych za pomocą powyższych kluczy tajnych). Widzisz, że oba klastry operacyjne mogą uwierzytelniać się we wszystkich klastrach aplikacji za pomocą kluczy tajnych utworzonych przez kubeconfig. Klastry operacyjne mogą automatycznie wykrywać usługi za pomocą plików kubeconfig jako metody tajnej. Wymaga to, aby Pilot w klastrach operacyjnych miał dostęp do serwera Kube API we wszystkich innych klastrach. Jeśli Pilot nie może połączyć się z serwerami API Kube, musisz ręcznie dodać usługi zdalne jako ServiceEntries. Można je traktować jako wpisy DNS w rejestrze usług. Obiekty ServiceEntry definiują usługę za pomocą pełnej i jednoznacznej nazwy DNS ( FQDN) i adresu IP, pod którym jest ona dostępna. Więcej informacji znajdziesz w dokumentacji Istio Multicluster.

6. Wyjaśnienie repozytorium infrastruktury

Cloud Build infrastruktury

Zasoby GCP na potrzeby warsztatów są tworzone za pomocą Cloud Build i infrastructure repozytorium CSR. Właśnie uruchomiono skrypt początkowy (znajdujący się w lokalnym terminalu w lokalizacji scripts/bootstrap_workshop.sh). Skrypt inicjujący tworzy folder GCP, projekt administratora Terraform i odpowiednie uprawnienia IAM dla konta usługi Cloud Build. Projekt administratora Terraform służy do przechowywania stanów Terraform, dzienników i różnych skryptów. Zawiera repozytoria infrastructure i k8s_repo CSR. Szczegółowe informacje o tych repozytoriach znajdziesz w następnej sekcji. W projekcie administracyjnym Terraform nie ma żadnych innych zasobów warsztatowych. Konto usługi Cloud Build w projekcie administracyjnym Terraform jest używane do tworzenia zasobów na potrzeby warsztatów.

Do utworzenia zasobów GCP na potrzeby warsztatów służy plik cloudbuild.yaml znajdujący się w folderze infrastructure. Tworzy niestandardowy obraz narzędzia do tworzenia ze wszystkimi narzędziami potrzebnymi do tworzenia zasobów GCP. Obejmują one pakiet SDK gcloud, Terraform i inne narzędzia, takie jak Python, Git czy jq. Obraz niestandardowego narzędzia do tworzenia uruchamia terraform plan i apply dla każdego zasobu. Pliki Terraform każdego zasobu znajdują się w osobnych folderach (szczegóły w następnej sekcji). Zasoby są tworzone pojedynczo i w kolejności, w jakiej zwykle są tworzone (np. projekt GCP jest tworzony przed zasobami w projekcie). Więcej informacji znajdziesz w pliku cloudbuild.yaml.

Cloud Build jest uruchamiana za każdym razem, gdy w repozytorium infrastructure nastąpi zatwierdzenie. Wszelkie zmiany wprowadzone w infrastrukturze są przechowywane jako infrastruktura jako kod (IaC) i zatwierdzane w repozytorium. Stan warsztatu jest zawsze przechowywany w tym repozytorium.

Struktura folderów – zespoły, środowiska i zasoby

Repozytorium infrastruktury konfiguruje zasoby infrastruktury GCP na potrzeby warsztatów. Jest on podzielony na foldery i podfoldery. Foldery podstawowe w repozytorium reprezentują team, które są właścicielami określonych zasobów GCP. Kolejna warstwa folderów reprezentuje konkretne environment zespołu (np. dev, stage, prod). Kolejna warstwa folderów w środowisku reprezentuje konkretne resource (np. host_project, gke_clusters itp.). W folderach zasobów znajdują się wymagane skrypty i pliki Terraform.

W tych warsztatach są reprezentowane 4 typy zespołów:

1. infrastructure – reprezentuje zespół ds. infrastruktury w chmurze. Odpowiadają za tworzenie zasobów GCP dla wszystkich pozostałych zespołów. Do zarządzania zasobami używają projektu administratora Terraform. Samo repozytorium infrastruktury znajduje się w projekcie administracyjnym Terraform, podobnie jak pliki stanu Terraform (opisane poniżej). Te zasoby są tworzone przez skrypt bash podczas procesu uruchamiania (szczegółowe informacje znajdziesz w module 0 – przepływ pracy administratora).
2. network – oznacza zespół ds. sieci. Odpowiadają za zasoby sieci VPC i sieciowe. są właścicielami tych zasobów GCP;
3. host project – reprezentuje główny projekt współdzielonego środowiska VPC.
4. shared VPC – reprezentuje współdzielone środowisko VPC, podsieci, dodatkowe zakresy adresów IP, trasy i reguły zapory sieciowej.
5. ops – reprezentuje zespół ds. operacji/DevOps. Są właścicielami tych zasobów:
6. ops project – reprezentuje projekt dla wszystkich zasobów operacji.
7. gke clusters – klaster GKE operacji w każdym regionie. Platforma sterująca Istio jest instalowana w każdym z klastrów GKE operacji.
8. k8s-repo – repozytorium CSR zawierające manifesty GKE dla wszystkich klastrów GKE.
9. aplikacje – reprezentuje zespoły aplikacji. W tym warsztacie symulujemy 2 zespoły: app1 i app2. Są właścicielami tych zasobów:
10. app projects – każdy zespół aplikacji ma własny zestaw projektów. Umożliwi mu to kontrolowanie rozliczeń i IAM w przypadku konkretnego projektu.
11. gke clusters – są to klastry aplikacji, w których działają kontenery/pody aplikacji.
12. gce instances – opcjonalnie, jeśli mają aplikacje działające na instancjach GCE. W tych warsztatach aplikacja app1 ma kilka instancji GCE, na których działa część aplikacji.

W tych warsztatach ta sama aplikacja (aplikacja Hipster Shop) reprezentuje zarówno aplikację 1, jak i aplikację 2.

Dostawca, stany i dane wyjściowe – back-endy i udostępnione stany

Usługodawcy google i google-beta znajdują się w lokalizacji gcp/[environment]/gcp/provider.tf. Plik provider.tf jest symlinked w każdym folderze zasobów. Dzięki temu możesz zmienić dostawcę w jednym miejscu, zamiast zarządzać dostawcami poszczególnych zasobów.

Każdy zasób zawiera plik backend.tf, który określa lokalizację pliku tfstate zasobu. Ten plik backend.tf jest generowany na podstawie szablonu (znajdującego się w lokalizacji templates/backend.tf_tmpl) za pomocą skryptu (znajdującego się w lokalizacji scripts/setup_terraform_admin_project), a następnie umieszczany w odpowiednim folderze zasobów. Jako backendy są używane zasobniki Google Cloud Storage (GCS). Nazwa folderu zasobnika GCS jest zgodna z nazwą zasobu. Wszystkie back-endy zasobów znajdują się w projekcie administracyjnym Terraform.

Zasoby z wartościami wzajemnie od siebie zależnymi zawierają plik output.tf. Wymagane wartości wyjściowe są przechowywane w pliku tfstate zdefiniowanym w backendzie dla danego zasobu. Jeśli na przykład chcesz utworzyć klaster GKE w projekcie, musisz znać identyfikator projektu. Identyfikator projektu jest przekazywany przez plik output.tf do pliku tfstate, którego można użyć za pomocą źródła danych terraform_remote_state w zasobie klastra GKE.

Plik shared_state to terraform_remote_state źródło danych wskazujące plik tfstate zasobu. W folderach zasobów znajduje się shared_state_[resource_name].tfplik (lub pliki), który wymaga danych wyjściowych z innych zasobów. Na przykład w folderze zasobów ops_gke znajdują się pliki shared_state z zasobów ops_project i shared_vpc, ponieważ do utworzenia klastrów GKE w projekcie operacyjnym potrzebujesz identyfikatora projektu i szczegółów środowiska VPC. Pliki shared_state są generowane na podstawie szablonu (znajdującego się w lokalizacji templates/shared_state.tf_tmpl) za pomocą skryptu (znajdującego się w lokalizacji scripts/setup_terraform_admin_project). Wszystkie pliki shared_state zasobów są umieszczane w folderze gcp/[environment]/shared_states. Wymagane pliki shared_state są połączone symbolicznie w odpowiednich folderach zasobów. Umieszczenie wszystkich plików shared_state w jednym folderze i utworzenie do nich linków symbolicznych w odpowiednich folderach zasobów ułatwia zarządzanie wszystkimi plikami stanu w jednym miejscu.

Zmienne

Wszystkie wartości zasobów są przechowywane jako zmienne środowiskowe. Te zmienne są przechowywane (jako instrukcje eksportu) w pliku o nazwie vars.sh znajdującym się w zasobniku GCS w projekcie administratora Terraform. Zawiera identyfikator organizacji, konto rozliczeniowe, identyfikatory projektów, szczegóły klastra GKE itp. Możesz pobrać i uzyskać vars.sh z dowolnego terminala, aby uzyskać wartości dla swojej konfiguracji.

Zmienne Terraform są przechowywane w vars.sh jako TF_VAR_[variable name]. Te zmienne służą do generowania pliku variables.tfvars w odpowiednim folderze zasobów. Plik variables.tfvars zawiera wszystkie zmienne wraz z ich wartościami. Plik variables.tfvars jest generowany na podstawie pliku szablonu w tym samym folderze za pomocą skryptu (znajdującego się w scripts/setup_terraform_admin_project).

Wyjaśnienie dotyczące repozytorium K8s

k8s_repo to repozytorium CSR (oddzielne od repozytorium infrastruktury) znajdujące się w projekcie administracyjnym Terraform. Służy do przechowywania i stosowania plików manifestu GKE we wszystkich klastrach GKE. k8s_repo jest tworzony przez infrastrukturę Cloud Build (szczegóły znajdziesz w poprzedniej sekcji). Podczas początkowego procesu tworzenia infrastruktury Cloud Build tworzonych jest łącznie 6 klastrów GKE. W k8s_repo utworzono 6 folderów. Każdy folder (o nazwie zgodnej z nazwą klastra GKE) odpowiada klastrowi GKE zawierającemu odpowiednie pliki manifestu zasobów. Podobnie jak w przypadku tworzenia infrastruktury, Cloud Build służy do stosowania manifestów Kubernetes we wszystkich klastrach GKE za pomocą k8s_repo. Cloud Build jest wywoływany za każdym razem, gdy w repozytorium k8s_repo nastąpi zatwierdzenie. Podobnie jak w przypadku infrastruktury wszystkie manifesty Kubernetes są przechowywane jako kod w repozytorium k8s_repo, a stan każdego klastra GKE jest zawsze przechowywany w odpowiednim folderze.

W ramach początkowej konfiguracji infrastruktury tworzony jest k8s_repo, a Istio jest instalowany we wszystkich klastrach.

Projekty, klastry GKE i przestrzenie nazw

Zasoby w tych warsztatach są podzielone na różne projekty GCP. Projekty powinny odzwierciedlać strukturę organizacyjną (lub zespołową) Twojej firmy. Zespoły w Twojej organizacji odpowiedzialne za różne projekty, usługi lub zasoby korzystają z różnych projektów GCP. Oddzielne projekty umożliwiają tworzenie osobnych zestawów uprawnień IAM i zarządzanie rozliczeniami na poziomie projektu. Limitami zarządza się też na poziomie projektu.

W warsztatach uczestniczy 5 zespołów, z których każdy pracuje nad własnym projektem.

1. Zespół ds. infrastruktury, który tworzy zasoby GCP, używa Terraform admin project. Zarządzają infrastrukturą jako kodem w repozytorium CSR (o nazwie infrastructure) i przechowują wszystkie informacje o stanie Terraform dotyczące zasobów utworzonych w GCP w zasobnikach GCS. Kontrolują one dostęp do repozytorium CSR i zasobników GCS ze stanem Terraform.
2. Zespół ds. sieci, który tworzy współdzielone środowisko VPC, używa host project. Ten projekt zawiera sieć VPC, podsieci, trasy i reguły zapory sieciowej. Dzięki współdzielonemu środowisku VPC mogą centralnie zarządzać siecią zasobów GCP. Wszystkie projekty korzystały z tego jednego współdzielonego środowiska VPC na potrzeby sieci.
3. Zespół ds. operacji i platformy, który tworzy klastry GKE i platformy sterujące ASM/Istio, korzysta z ops project. Zarządzają cyklem życia klastrów GKE i siatki usług. Odpowiadają za wzmacnianie zabezpieczeń klastrów oraz zarządzanie odpornością i skalą platformy Kubernetes. W tym module wykorzystasz metodę GitOps do wdrażania zasobów w Kubernetes. W projekcie operacyjnym znajduje się repozytorium CSR (o nazwie k8s_repo).
4. Na koniec zespoły dev1 i dev2 (reprezentujące 2 zespoły programistów) tworzące aplikacje używają własnych dev1 i dev2 projects. Są to aplikacje i usługi, które udostępniasz klientom. Są one tworzone na platformie zarządzanej przez zespół ds. operacji. Zasoby (wdrożenia, usługi itp.) są przesyłane do k8s_repo i wdrażane w odpowiednich klastrach. Pamiętaj, że te warsztaty nie skupiają się na sprawdzonych metodach i narzędziach CI/CD. Cloud Build służy do automatyzowania wdrażania zasobów Kubernetes bezpośrednio w klastrach GKE. W rzeczywistych scenariuszach produkcyjnych do wdrażania aplikacji w klastrach GKE używa się odpowiedniego rozwiązania CI/CD.

W tym warsztacie są 2 rodzaje klastrów GKE.

1. Klastry operacyjne – używane przez zespół operacyjny do uruchamiania narzędzi DevOps. W tych warsztatach uruchamiają platformę sterującą ASM/Istio, aby zarządzać siatką usług.
2. Klastry aplikacji – używane przez zespoły programistów do uruchamiania aplikacji. W tych warsztatach używana jest aplikacja Hipster Shop.

Oddzielenie narzędzi operacyjnych i administracyjnych od klastrów, w których działa aplikacja, umożliwia niezależne zarządzanie cyklem życia każdego zasobu. Oba typy klastrów znajdują się też w różnych projektach związanych z zespołem lub produktem, który z nich korzysta, co ułatwia zarządzanie uprawnieniami IAM.

Łącznie jest 6 klastrów GKE. W projekcie operacyjnym zostaną utworzone 2 regionalne klastry operacyjne. Platforma sterująca ASM/Istio jest zainstalowana w obu klastrach operacyjnych. Każdy klaster operacyjny znajduje się w innym regionie. Dodatkowo istnieją 4 klastry aplikacji strefowych. Są one tworzone w osobnych projektach. Te warsztaty symulują 2 zespoły deweloperskie, z których każdy ma własne projekty. Każdy projekt zawiera 2 klastry aplikacji. Klastry aplikacji to klastry strefowe w różnych strefach. Cztery klastry aplikacji znajdują się w 2 regionach i 4 strefach. W ten sposób uzyskasz nadmiarowość regionalną i strefową.

Aplikacja używana w tych warsztatach, czyli Hipster Shop, jest wdrażana we wszystkich 4 klastrach aplikacji. Każdy mikroserwis znajduje się w osobnej przestrzeni nazw w każdym klastrze aplikacji. Wdrożenia (pody) aplikacji sklepu Hipster nie są wdrażane w klastrach operacyjnych. Jednak przestrzenie nazw i zasoby usługi dla wszystkich mikroserwisów są też tworzone w klastrach operacyjnych. Platforma sterująca ASM/Istio używa rejestrów usług Kubernetes do wykrywania usług. W przypadku braku usług (w klastrach operacyjnych) musisz ręcznie utworzyć wpisy ServiceEntry dla każdej usługi działającej w klastrze aplikacji.

W tych warsztatach wdrożysz 10-poziomową aplikację mikroserwisową. Aplikacja to internetowa aplikacja e-commerce o nazwie „ Hipster Shop”, w której użytkownicy mogą przeglądać produkty, dodawać je do koszyka i kupować.

Manifesty Kubernetes i k8s_repo

Za pomocą k8s_repo możesz dodawać zasoby Kubernetes do wszystkich klastrów GKE. Aby to zrobić, skopiuj pliki manifestu Kubernetes i zatwierdź je w repozytorium k8s_repo. Wszystkie commity w k8s_repo wywołują zadanie Cloud Build, które wdraża pliki manifestu Kubernetes w odpowiednim klastrze. Manifest każdego klastra znajduje się w osobnym folderze o nazwie identycznej z nazwą klastra.

Są to:

1. gke-asm-1-r1-prod – regionalny klaster operacyjny w regionie 1.
2. gke-asm-2-r2-prod – regionalny klaster operacyjny w regionie 2.
3. gke-1-apps-r1a-prod – klaster aplikacji w strefie a regionu 1
4. gke-2-apps-r1b-prod – klaster aplikacji w regionie 1 w strefie b
5. gke-3-apps-r2a-prod – klaster aplikacji w strefie a regionu 2
6. gke-4-apps-r2b-prod – klaster aplikacji w regionie 2, strefa b

k8s_repo zawiera foldery odpowiadające tym klastrom. Każdy plik manifestu umieszczony w tych folderach zostanie zastosowany w odpowiednim klastrze GKE. Manifesty każdego klastra są umieszczane w podfolderach (w głównym folderze klastra), aby ułatwić zarządzanie. W tych warsztatach użyjesz narzędzia Kustomize, aby śledzić wdrażane zasoby. Więcej informacji znajdziesz w oficjalnej dokumentacji Kustomize.

7. Wdrażanie przykładowej aplikacji

Cel: wdrożenie aplikacji Hipster Shop w klastrach aplikacji

• Klon aplikacji k8s-repo
• Kopiowanie plików manifestu sklepu Hipster do wszystkich klastrów aplikacji
• Tworzenie usług dla aplikacji Hipster Shop w klastrach operacyjnych
• Skonfiguruj loadgenerators w klastrach operacyjnych, aby przetestować łączność globalną
• Weryfikowanie bezpiecznego połączenia z aplikacją Hipster Shop

FAST TRACK SCRIPT

Jeśli wybierzesz tę metodę, uruchom ten skrypt, aby ukończyć ten moduł.

${WORKDIR}/asm/fasttrack_scripts/deploy-sample-app.sh

Instrukcje dotyczące modułu z metodą kopiowania i wklejania

Jeśli skrypt szybkiej ścieżki do tego laboratorium został już przez Ciebie wykonany, nie stosuj poniższej metody kopiowania i wklejania**.

Klonowanie repozytorium źródłowego projektu operacyjnego

W ramach początkowej konfiguracji infrastruktury Terraform w projekcie operacyjnym jest już utworzony k8s-repo.

1. Utwórz pusty katalog dla repozytorium Git:

mkdir $WORKDIR/k8s-repo
 

2. Zainicjuj repozytorium Git, dodaj zdalne repozytorium i pobierz z niego gałąź master:

cd $WORKDIR/k8s-repo
git init && git remote add origin \
https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo
 

3. Ustaw lokalną konfigurację Git.

git config --local user.email $MY_USER
git config --local user.name "K8s repo user"
git config --local \
credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

Kopiowanie plików manifestu, zatwierdzanie i przesyłanie zmian

4. Skopiuj przestrzenie nazw i usługi Hipster Shop do repozytorium źródłowego dla wszystkich klastrów.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.
 

5. Skopiuj folder aplikacji kustomization.yaml do wszystkich klastrów.

cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/
 

6. Skopiuj Hipster Shop Deployments, RBAC i PodSecurityPolicy do repozytorium źródłowego dla klastrów aplikacji.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

7. Usuń wdrożenie cartservice, rbac i podsecuritypolicy ze wszystkich klastrów deweloperskich z wyjątkiem jednego. Hipstershop nie został zaprojektowany do wdrożenia w wielu klastrach, więc aby uniknąć niespójnych wyników, używamy tylko jednego cartservice.

rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml
 

8. Dodaj wdrożenie cartservice, rbac i podsecuritypolicy do kustomization.yaml tylko w pierwszym klastrze deweloperskim.

cd ${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app
cd deployments && kustomize edit add resource app-cart-service.yaml
cd ../podsecuritypolicies && kustomize edit add resource cart-psp.yaml
cd ../rbac && kustomize edit add resource cart-rbac.yaml
cd ${WORKDIR}/asm
 

9. Usuń katalogi podsecuritypolicies, deployments i rbac z pliku ops clusters kustomization.yaml.

sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/kustomization.yaml
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/kustomization.yaml

10. Zastąp PROJECT_ID w plikach manifestu RBAC.

sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/*
  

11. Skopiuj manifesty IngressGateway i VirtualService do repozytorium źródłowego dla klastrów operacyjnych.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-ingress/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-ingress/
 

12. Skopiuj zasoby Config Connector do jednego z klastrów w każdym projekcie.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/
 

13. Zastąp PROJECT_ID w manifestach Config Connector.

sed -i 's/${PROJECT_ID}/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev1_project_name'/g' \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev2_project_name'/g' \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/*
 

14. Skopiuj manifesty loadgenerator (wdrożenie, PodSecurityPolicy i RBAC) do klastrów operacyjnych. Aplikacja Hipster Shop jest udostępniana za pomocą globalnego systemu równoważenia obciążenia Google Cloud (GCLB). GCLB odbiera ruch klienta (przeznaczony dla frontend) i wysyła go do najbliższej instancji usługi. Umieszczenie loadgenerator w obu klastrach operacyjnych zapewni przesyłanie ruchu do obu bram Ingress Istio działających w klastrach operacyjnych. Równoważenie obciążenia zostało szczegółowo opisane w następnej sekcji.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/. 
 

15. Zastąp identyfikator projektu operacji w plikach manifestu loadgenerator w przypadku obu klastrów operacji.

sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g'  \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
 

16. Dodaj zasoby loadgenerator do pliku kustomization.yaml w przypadku obu klastrów operacyjnych.

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml
 

17. Zobowiązanie do k8s-repo.

cd $WORKDIR/k8s-repo
git add . && git commit -am "create app namespaces and install hipster shop"
git push --set-upstream origin master 
 

18. Sprawdź stan projektu operacyjnego Cloud Build w otwartej wcześniej karcie lub klikając ten link:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
  

Sprawdzanie wdrożenia aplikacji

19. Sprawdź, czy pody we wszystkich przestrzeniach nazw aplikacji z wyjątkiem koszyka są uruchomione we wszystkich klastrach deweloperskich.

for ns in ad checkout currency email frontend payment product-catalog recommendation shipping; do
  kubectl --context $DEV1_GKE_1 get pods -n $ns;
  kubectl --context $DEV1_GKE_2 get pods -n $ns;
  kubectl --context $DEV2_GKE_1 get pods -n $ns;
  kubectl --context $DEV2_GKE_2 get pods -n $ns;
done;
 

Output (do not copy)

NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-pvc6s   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-xlkl9   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-zdjkg   2/2     Running   0          115s
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-l748q   2/2     Running   0          82s

NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-gk92n   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-rvzk9   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-mt925   2/2     Running   0          117s
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-klqn7   2/2     Running   0          84s

NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-kkq7d   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-lwskf   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-zz7xs   2/2     Running   0          118s
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-2vtw5   2/2     Running   0          85s

NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-df8ml   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-bdcvg   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-jqf28   2/2     Running   0          117s
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-95x2m   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-q5g9p   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-n6lp8   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-gf9xl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-v7cbr   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-2ltrk   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-dqd55   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-jghcl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-kkspz   2/2     Running   0          87s

NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-qqd9n   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-xczg5   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-wfgfr   2/2     Running   0          2m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-r6t8v   2/2     Running   0          88s

20. Sprawdź, czy pody w przestrzeni nazw koszyka są w stanie Running tylko w pierwszym klastrze deweloperskim.

kubectl --context $DEV1_GKE_1 get pods -n cart;
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
cartservice-659c9749b4-vqnrd   2/2     Running   0          17m

Dostęp do aplikacji Hipster Shop

Globalne równoważenie obciążenia

Aplikacja Hipster Shop jest teraz wdrożona we wszystkich 4 klastrach aplikacji. Te klastry znajdują się w 2 regionach i 4 strefach. Klienci mogą uzyskać dostęp do aplikacji sklepu Hipster, korzystając z usługi frontend. Usługa frontend działa we wszystkich 4 klastrach aplikacji. System równoważenia obciążenia Google Cloud ( GCLB) służy do kierowania ruchu klientów do wszystkich 4 instancji usługi frontend.

Bramy wejściowe Istio działają tylko w klastrach operacyjnych i pełnią funkcję regionalnego systemu równoważenia obciążenia dla 2 strefowych klastrów aplikacji w regionie. GCLB używa 2 bram wjazdowych Istio (działających w 2 klastrach operacyjnych) jako backendów globalnej usługi frontendowej. Bramy Istio Ingress odbierają ruch klienta z GCLB, a następnie przesyłają go dalej do podów frontendowych działających w klastrach aplikacji.

Możesz też umieścić bramy wejściowe Istio bezpośrednio w klastrach aplikacji, a GCLB może używać ich jako backendów.

Kontroler Autoneg GKE

Usługa Kubernetes bramy wejściowej Istio rejestruje się jako backend w GCLB za pomocą grup punktów końcowych sieci (NEG). Sieci NEG umożliwiają natywne równoważenie obciążenia w kontenerze za pomocą globalnych systemów równoważenia obciążenia. Sieciowe punkty końcowe są tworzone za pomocą specjalnej adnotacji w usłudze Kubernetes, dzięki czemu może ona zarejestrować się w kontrolerze sieciowych punktów końcowych. Kontroler Autoneg to specjalny kontroler GKE, który automatyzuje tworzenie grup NEG i przypisywanie ich jako backendów do GCLB za pomocą adnotacji usługi. Płaszczyzny sterowania Istio, w tym bramy wejściowe Istio, są wdrażane podczas początkowego tworzenia infrastruktury za pomocą Terraform Cloud Build. Konfiguracja GCLB i autoneg jest przeprowadzana w ramach początkowego tworzenia infrastruktury Terraform w Cloud Build.

Zabezpieczanie ruchu przychodzącego za pomocą Cloud Endpoints i zarządzanych certyfikatów

Certyfikaty zarządzane przez GCP służą do zabezpieczania ruchu klienta do usługi frontend GCLB. GCLB używa zarządzanych certyfikatów w przypadku usługi globalnej frontend, a certyfikat jest kończony w GCLB. W tych warsztatach jako domeny zarządzanego certyfikatu użyjesz Cloud Endpoints. Możesz też użyć domeny i nazwy DNS dla frontend, aby utworzyć certyfikaty zarządzane przez GCP.

21. Aby uzyskać dostęp do sklepu Hipster, kliknij link wygenerowany przez to polecenie.

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

22. Aby sprawdzić, czy certyfikat jest ważny, kliknij symbol kłódki na pasku adresu karty Chrome.

Weryfikowanie globalnego równoważenia obciążenia

W ramach wdrażania aplikacji w obu klastrach operacyjnych wdrożono generatory obciążenia, które generują ruch testowy do linku Cloud Endpoints sklepu Hipster w GCLB. Sprawdź, czy globalny system równoważenia obciążenia otrzymuje ruch i wysyła go do obu bram wejściowych Istio.

23. Uzyskaj link GCLB > Monitorowanie dla projektu operacyjnego, w którym utworzono GCLB sklepu Hipster.

echo "https://console.cloud.google.com/net-services/loadbalancing/details/http/istio-ingressgateway?project=$TF_VAR_ops_project_name&cloudshell=false&tab=monitoring&duration=PT1H" 
 

24. W menu Backend (Backend) zmień opcję All backends (Wszystkie backendy) na istio-ingressgateway (Brama wejściowa Istio), jak pokazano poniżej.

25. Zwróć uwagę na ruch idący do obu wersji istio-ingressgateways.

Na każdy istio-ingressgateway tworzone są 3 NEGs. Ponieważ klastry operacyjne są klastrami regionalnymi, dla każdej strefy w regionie tworzona jest jedna grupa NEG. istio-ingressgateway Pods działają jednak w jednej strefie w każdym regionie. Ruch jest kierowany do podów istio-ingressgateway.

Generatory obciążenia działają w obu klastrach operacyjnych, symulując ruch klientów z 2 regionów, w których się znajdują. Obciążenie wygenerowane w regionie 1 klastra operacyjnego jest wysyłane do istio-ingressgateway w regionie 2. Podobnie obciążenie wygenerowane w regionie 2 klastra operacyjnego jest wysyłane do istio-ingressgateway w regionie 2.

8. Dostrzegalność w usłudze Stackdriver

Cel: połączyć telemetrię Istio z usługą Stackdriver i sprawdzić to połączenie.

• Instalowanie zasobów istio-telemetry
• Tworzenie i aktualizowanie paneli usług Istio
• Wyświetlanie logów kontenera
• Wyświetlanie śledzenia rozproszonego w usłudze Stackdriver

FAST TRACK SCRIPT

Jeśli wybierzesz tę metodę, uruchom ten skrypt, aby ukończyć ten moduł.

${WORKDIR}/asm/fasttrack_scripts/observability-with-stackdriver.sh

Instrukcje dotyczące modułu z metodą kopiowania i wklejania

Jeśli skrypt szybkiej ścieżki do tego laboratorium został już przez Ciebie wykonany, nie stosuj poniższej metody kopiowania i wklejania**.

Jedną z najważniejszych funkcji Istio jest wbudowana dostrzegalność („o11y”). Oznacza to, że nawet w przypadku kontenerów typu black box bez instrumentacji operatorzy mogą obserwować ruch wchodzący i wychodzący z tych kontenerów, świadcząc usługi klientom. Obserwacja ta przybiera postać kilku różnych metod: danych, logów i śladów.

Skorzystamy też z wbudowanego w Hipster Shop systemu generowania obciążenia. Obserwacja nie działa zbyt dobrze w statycznym systemie bez ruchu, więc generowanie obciążenia pomaga nam sprawdzić, jak działa. To zadanie jest już uruchomione. Teraz będziemy mogli je tylko zobaczyć.

1. Zainstaluj plik konfiguracyjny istio to stackdriver.

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml
 

2. Zatwierdź zmiany w repozytorium k8s.

cd $WORKDIR/k8s-repo
git add . && git commit -am "Install istio to stackdriver configuration"
git push 
 

3. Sprawdź stan projektu operacyjnego Cloud Build w otwartej wcześniej karcie lub klikając ten link:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

4. Sprawdź integrację Istio z Stackdriver. Pobierz CRD modułu obsługi Stackdriver.

kubectl --context $OPS_GKE_1 get handler -n istio-system
 

Dane wyjściowe powinny zawierać moduł obsługi o nazwie stackdriver:

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s      # <== NEW!

5. Sprawdź, czy eksportowanie danych Istio do Stackdriver działa. Kliknij link wygenerowany przez to polecenie:

echo "https://console.cloud.google.com/monitoring/metrics-explorer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Pojawi się prośba o utworzenie nowej przestrzeni roboczej o nazwie projektu operacyjnego. Wystarczy kliknąć OK. Jeśli pojawi się okno z informacją o nowym interfejsie, zamknij je.

W eksploratorze danych w sekcji „Znajdź typ zasobu i dane” wpisz „istio”, aby zobaczyć opcje takie jak „Liczba żądań serwera” w przypadku typu zasobu „Kontener Kubernetes”. Pokazuje to, że dane są przesyłane z sieci do Stackdriver.

(Aby zobaczyć poniższe wiersze, musisz zgrupować dane według etykiety destination_service_name).

Wizualizacja danych za pomocą paneli informacyjnych:

Wskaźniki są już w systemie Stackdriver APM, więc chcemy je wizualizować. W tej sekcji zainstalujemy gotowy panel, który będzie wyświetlać 3 z 4 „złotych sygnałów” dotyczących danych: ruch (liczba żądań na sekundę), opóźnienie (w tym przypadku 99. i 50. percentyl) oraz błędy (w tym przykładzie pomijamy nasycenie).

Serwer proxy Envoy Istio udostępnia kilka rodzajów danych, ale te są dobrym punktem wyjścia. (pełna lista jest dostępna tutaj). Pamiętaj, że każdy rodzaj danych ma zestaw etykiet, których można używać do filtrowania i agregowania, np. destination_service, source_workload_namespace, response_code, istio_tcp_received_bytes_total itp.

6. Teraz dodajmy gotowy panel z danymi. Będziemy bezpośrednio korzystać z interfejsu Dashboard API. Zwykle nie wykonujesz tego ręcznie, generując wywołania interfejsu API. Jest to część systemu automatyzacji lub ręcznie tworzysz panel w interfejsie internetowym. Dzięki temu szybko zaczniemy:

sed -i 's/OPS_PROJECT/'${TF_VAR_ops_project_name}'/g' \
$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
OAUTH_TOKEN=$(gcloud auth application-default print-access-token)
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards \
 -d @$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
 

7. Kliknij link wyjściowy poniżej, aby wyświetlić nowo dodany „Panel usług”.

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 
 

Możemy edytować panel w miejscu za pomocą interfejsu, ale w naszym przypadku szybko dodamy nowy wykres za pomocą interfejsu API. Aby to zrobić, pobierz najnowszą wersję panelu, wprowadź zmiany, a następnie prześlij ją z powrotem za pomocą metody HTTP PATCH.

8. Istniejący panel możesz uzyskać, wysyłając zapytanie do interfejsu Monitoring API. Pobierz istniejący panel, który został właśnie dodany:

curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash > /tmp/services-dashboard.json
 

9. Dodawanie nowego wykresu: (50th %ile latency): [ dokumentacja API] Teraz możemy dodać do panelu nowy widżet wykresu w kodzie. Zmianę mogą sprawdzić inne osoby i można ją dodać do systemu kontroli wersji. Oto widżet, który pokazuje czas oczekiwania na poziomie 50% (medianę czasu oczekiwania).

Spróbuj edytować panel, który właśnie został utworzony, dodając nowy blok:

NEW_CHART=${WORKDIR}/asm/k8s_manifests/prod/app-telemetry/new-chart.json
jq --argjson newChart "$(<$NEW_CHART)" '.gridLayout.widgets += [$newChart]' /tmp/services-dashboard.json > /tmp/patched-services-dashboard.json
 

10. Zaktualizuj istniejący panel usług:

curl -X PATCH -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash \
 -d @/tmp/patched-services-dashboard.json
 

11. Wyświetl zaktualizowany panel, klikając ten link:

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 

12. przeprowadzać prostą analizę logów;

Istio udostępnia zestaw ustrukturyzowanych logów dla całego ruchu w sieci w siatce i przesyła je do Stackdriver Logging, aby umożliwić analizę w wielu klastrach za pomocą jednego zaawansowanego narzędzia. Dzienniki są opatrywane metadanymi na poziomie usługi, takimi jak klaster, kontener, aplikacja, connection_id itp.

Przykładowy wpis logu (w tym przypadku dzienniku dostępu serwera proxy Envoy) może wyglądać tak (skrócony):

*** DO NOT PASTE *** 
 logName: "projects/PROJECTNAME-11932-01-ops/logs/server-tcp-accesslog-stackdriver.instance.istio-system" 
labels: {
  connection_id: "fbb46826-96fd-476c-ac98-68a9bd6e585d-1517191"   
  destination_app: "redis-cart"   
  destination_ip: "10.16.1.7"   
  destination_name: "redis-cart-6448dcbdcc-cj52v"   
  destination_namespace: "cart"   
  destination_owner: "kubernetes://apis/apps/v1/namespaces/cart/deployments/redis-cart"   
  destination_workload: "redis-cart"   
  source_ip: "10.16.2.8"   
  total_received_bytes: "539"   
  total_sent_bytes: "569" 
...  
 }

Wyświetl logi:

echo "https://console.cloud.google.com/logs/viewer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Aby wyświetlić logi platformy sterującej Istio, wybierz Zasób > Kontener Kubernetes i wyszukaj „pilot”:

Widzimy tu płaszczyznę sterowania Istio, która przesyła konfigurację serwera proxy do pomocniczych serwerów proxy dla każdej usługi przykładowej aplikacji. „CDS”, „LDS” i „RDS” to różne interfejsy API Envoy ( więcej informacji).

Oprócz logów Istio w tym samym interfejsie znajdziesz też logi kontenerów oraz logi infrastruktury i innych usług GCP. Oto kilka przykładowych zapytań dotyczących dzienników w GKE. Przeglądarka logów umożliwia też tworzenie na podstawie logów danych (np. „zlicz każdy błąd, który pasuje do określonego ciągu znaków”), które można wykorzystać w panelu lub w ramach alertu. Dzienniki można też przesyłać strumieniowo do innych narzędzi analitycznych, takich jak BigQuery.

Przykładowe filtry dla sklepu z produktami dla hipsterów:

resource.type="k8s_container" labels.destination_app="productcatalogservice"

resource.type="k8s_container" resource.labels.namespace_name="cart"

13. Sprawdź śledzenie rozproszone.

Teraz, gdy pracujesz z systemem rozproszonym, do debugowania potrzebujesz nowego narzędzia: śledzenia rozproszonego. To narzędzie umożliwia odkrywanie statystyk dotyczących interakcji między usługami (np. znajdowanie nietypowych, powolnych zdarzeń, jak na ilustracji poniżej), a także zagłębianie się w surowe ślady próbek, aby zbadać szczegóły tego, co się dzieje.

Widok osi czasu pokazuje wszystkie żądania w czasie, przedstawione na wykresie według opóźnienia lub czasu spędzonego między początkowym żądaniem, przez stos Hipster, a ostateczną odpowiedzią dla użytkownika. Im wyżej znajdują się kropki, tym wolniejsze (i mniej satysfakcjonujące) jest działanie aplikacji.

Możesz kliknąć kropkę, aby wyświetlić szczegółowy widok kaskadowy danego żądania. Możliwość znajdowania szczegółowych informacji o konkretnym żądaniu (a nie tylko zagregowanych statystyk) jest kluczowa dla zrozumienia interakcji między usługami, zwłaszcza podczas wyszukiwania rzadkich, ale niepożądanych interakcji między usługami.

Widok kaskadowy powinien być znany każdemu, kto korzystał z debugera. W tym przypadku jednak zamiast czasu spędzonego w różnych procesach pojedynczej aplikacji pokazuje on czas spędzony na przechodzeniu przez naszą siatkę między usługami działającymi w oddzielnych kontenerach.

Ślady znajdziesz tutaj:

echo "https://console.cloud.google.com/traces/overview?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Przykładowy zrzut ekranu narzędzia:

9. Wzajemne uwierzytelnianie TLS

Cel: bezpieczne połączenia między mikroserwisami (uwierzytelnianie).

• Włączanie mTLS w całej siatce
• Sprawdzanie mTLS przez przeglądanie logów

FAST TRACK SCRIPT

Jeśli wybierzesz tę metodę, uruchom ten skrypt, aby ukończyć ten moduł.

${WORKDIR}/asm/fasttrack_scripts/mutual-tls.sh

Instrukcje dotyczące modułu z metodą kopiowania i wklejania

Jeśli skrypt szybkiej ścieżki do tego laboratorium został już przez Ciebie wykonany, nie stosuj poniższej metody kopiowania i wklejania**.

Po zainstalowaniu aplikacji i skonfigurowaniu funkcji Observability możemy zacząć zabezpieczać połączenia między usługami i sprawdzać, czy działają prawidłowo.

Na przykład w panelu Kiali możemy zobaczyć, że nasze usługi nie korzystają z mTLS (nie ma ikony „kłódki”). Ale ruch jest płynny, a system działa prawidłowo. Panel Złotych wskaźników StackDriver daje nam pewność, że wszystko działa.

1. Sprawdź MeshPolicy w klastrach operacyjnych. Uwaga: mTLS PERMISSIVE umożliwia zarówno ruch szyfrowany, jak i ruch bez mTLS.

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq '.items[].spec'
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq '.items[].spec'
 

    `Output (do not copy)`

{
  "peers": [
    {
      "mtls": {
        "mode": "PERMISSIVE"
      }
    }
  ]
}

Istio jest skonfigurowane we wszystkich klastrach za pomocą operatora Istio, który korzysta z niestandardowego zasobu IstioControlPlane. Skonfigurujemy mTLS we wszystkich klastrach, aktualizując CR IstioControlPlane i k8s-repo. Ustawienie global > mTLS > enabled: true w CR IstioControlPlane powoduje wprowadzenie tych 2 zmian w platformie sterującej Istio:

• Zasada MeshPolicy jest ustawiona tak, aby włączyć mTLS w całej siatce dla wszystkich usług działających we wszystkich klastrach.
• Tworzona jest reguła docelowa, która umożliwia ruch ISTIO_MUTUAL między usługami działającymi we wszystkich klastrach.

2. Zastosujemy poprawkę kustomize do CR istioControlPlane, aby włączyć mTLS w całym klastrze. Skopiuj poprawkę do odpowiedniego katalogu we wszystkich klastrach i dodaj poprawkę kustomize.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml
 

3. Zatwierdź zmiany w repozytorium k8s.

cd $WORKDIR/k8s-repo
git add . && git commit -am "turn mTLS on"
git push
 

4. Sprawdź stan projektu operacyjnego Cloud Build w otwartej wcześniej karcie lub klikając ten link:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

 

Weryfikowanie mTLS

5. Ponownie sprawdź MeshPolicy w klastrach operacyjnych. Uwaga: mTLS nie jest już PERMISSIVE i będzie obsługiwać tylko ruch mTLS.

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq .items[].spec
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq .items[].spec
 

Dane wyjściowe (nie kopiuj ich):

{
  "peers": [
    {
      "mtls": {}
    }
  ]
}

6. Opisz regułę docelową utworzoną przez kontroler operatora Istio.

kubectl --context $OPS_GKE_1 get DestinationRule default -n istio-system -o json | jq '.spec'
kubectl --context $OPS_GKE_2 get DestinationRule default -n istio-system -o json | jq '.spec'

Dane wyjściowe (nie kopiuj ich):

{
    host: '*.local',
    trafficPolicy: {
      tls: {
        mode: ISTIO_MUTUAL
      }
   }
}

W dziennikach możemy też zobaczyć przejście z protokołu HTTP na HTTPS.

Aby wyświetlić to pole w interfejsie, kliknij jeden z wpisów logu, a potem kliknij wartość pola, które chcesz wyświetlić. W naszym przypadku kliknij „http” obok „protocol:”.

Dzięki temu można w prosty sposób wizualizować przejście:

10. Wdrożenia do wczesnych testów

Cel: wdrożenie nowej wersji usługi frontendu.

• Wdrożenie usługi frontend-v2 (następna wersja produkcyjna) w 1 regionie
• Używaj opcji DestinationRules i VirtualServices, aby stopniowo kierować ruch do frontend-v2
• Sprawdź potok wdrażania GitOps, przeglądając serię commitów w k8s-repo

FAST TRACK SCRIPT

Jeśli wybierzesz tę metodę, uruchom ten skrypt, aby ukończyć ten moduł.

${WORKDIR}/asm/fasttrack_scripts/canary-deployments.sh

Instrukcje dotyczące modułu z metodą kopiowania i wklejania

Jeśli skrypt szybkiej ścieżki do tego laboratorium został już przez Ciebie wykonany, nie stosuj poniższej metody kopiowania i wklejania**.

Wdrożenie do wczesnych testów to stopniowe wprowadzanie nowej usługi. W przypadku wdrożenia do wczesnych testów wysyłasz coraz większą ilość ruchu do nowej wersji, a pozostały odsetek ruchu nadal kierujesz do bieżącej wersji. Typowym wzorcem jest przeprowadzanie analizy wczesnych testów na każdym etapie podziału ruchu i porównywanie „złotych sygnałów” nowej wersji (opóźnienia, odsetka błędów, nasycenia) z wartościami bazowymi. Pomaga to zapobiegać przerwom w działaniu i zapewniać stabilność nowej usługi „v2” na każdym etapie podziału ruchu.

Z tej sekcji dowiesz się, jak za pomocą Cloud Build i zasad ruchu Istio utworzyć podstawowe wdrożenie do wczesnych testów nowej wersji usługi frontend.

Najpierw uruchomimy potok Canary w regionie DEV1 (us-west1) i wdrożymy frontend w wersji 2 w obu klastrach w tym regionie. Następnie uruchomimy potok Canary w regionie DEV2 (us-central) i wdrożymy wersję 2 na obu klastrach w tym regionie. Uruchamianie potoku w regionach w kolejności, a nie równolegle we wszystkich regionach, pomaga uniknąć globalnych awarii spowodowanych nieprawidłową konfiguracją lub błędami w samej aplikacji w wersji 2.

Uwaga: w obu regionach ręcznie uruchomimy potok Canary, ale w środowisku produkcyjnym użyjesz automatycznego wyzwalacza, np. na podstawie nowego tagu obrazu Dockera przesłanego do rejestru.

1. W Cloud Shell zdefiniuj zmienne środowiskowe, aby uprościć wykonywanie pozostałych poleceń.

CANARY_DIR="$WORKDIR/asm/k8s_manifests/prod/app-canary/"
K8S_REPO="$WORKDIR/k8s-repo"
 

2. Uruchom skrypt repo_setup.sh, aby skopiować podstawowe pliki manifestu do k8s-repo.

$CANARY_DIR/repo-setup.sh 
 

Skopiowane zostaną te pliki manifestu:

• wdrożenie frontend-v2
• frontend-v1 (aby uwzględnić etykietę „v1” i obraz z punktem końcowym „/version”)
• respy, mały pod, który będzie wyświetlać rozkład odpowiedzi HTTP i pomagać nam wizualizować wdrożenie do wczesnych testów w czasie rzeczywistym.
• Istio DestinationRule usługi frontend – dzieli usługę Kubernetes frontend na 2 podzbiory, v1 i v2, na podstawie etykiety wdrożenia „version”.
• VirtualService frontend Istio – kieruje 100% ruchu do wersji 1 frontendu. Zastępuje to domyślne działanie usługi Kubernetes w trybie okrężnym, które natychmiast wysyłałoby 50% całego ruchu regionalnego Dev1 do frontendu w wersji 2.

3. Zatwierdź zmiany w repozytorium k8s:

cd $K8S_REPO 
git add . && git commit -am "frontend canary setup"
git push
 

4. Sprawdź stan projektu operacyjnego Cloud Build w otwartej wcześniej karcie lub klikając ten link:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}" 
 

5. W konsoli projektu OPS1 otwórz Cloud Build. Poczekaj na zakończenie potoku Cloud Build, a potem pobierz pody w przestrzeni nazw frontend w obu klastrach DEV1. Strona powinna wyglądać tak:

watch -n 1 kubectl --context $DEV1_GKE_1 get pods -n frontend 
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
frontend-578b5c5db6-h9567      2/2     Running   0          59m
frontend-v2-54b74fc75b-fbxhc   2/2     Running   0          2m26s
respy-5f4664b5f6-ff22r         2/2     Running   0          2m26s

Uwaga: aby zakończyć polecenia watch, naciśnij Ctrl+C.

Użyjemy tmux, aby podzielić okno Cloud Shell na 2 panele:

• W dolnym panelu będzie działać polecenie watch, które będzie obserwować rozkład odpowiedzi HTTP dla usługi frontendu.
• W górnym panelu będzie uruchamiany skrypt potoku kanaryjnego.

6. Uruchom polecenie, aby podzielić okno Cloud Shell i wykonać polecenie watch w dolnym panelu.

RESPY_POD=$(kubectl --context $DEV1_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV1_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

Dane wyjściowe (nie kopiuj ich)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

Widzimy, że cały ruch jest kierowany do wdrożenia frontend v1 zdefiniowanego w nowej usłudze wirtualnej.

7. Uruchom potok wczesnych testów w regionie Dev1. Udostępniamy skrypt, który aktualizuje procent ruchu frontend-v2 w VirtualService (aktualizując wagi do 20%, 50%, 80%, a następnie 100%). Między aktualizacjami skrypt czeka na zakończenie potoku Cloud Build. Uruchom skrypt wdrożenia do wczesnych testów w regionie Dev1. Uwaga: wykonanie tego skryptu zajmuje około 10 minut.

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_1_CLUSTER OPS_CONTEXT=$OPS_GKE_1 \
${CANARY_DIR}/auto-canary.sh
 

Podział ruchu możesz śledzić w czasie rzeczywistym w dolnym oknie, w którym uruchamiasz polecenie respy. Na przykład przy 20% :

Dane wyjściowe (nie kopiuj ich)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 79.4%             |
|          |                   |
| v2       | 20.6%             |
|          |                   |
+----------+-------------------+

8. Po zakończeniu wdrażania Dev2 w przypadku frontend-v2 na końcu skryptu powinien się wyświetlić komunikat o powodzeniu:

    Output (do not copy) 
   

✅ 100% successfully deployed
🌈 frontend-v2 Canary Complete for gke-asm-1-r1-prod

9. Cały ruch z podu Dev2 powinien być kierowany do frontend-v2:

    Output (do not copy) 
   

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

10. Zamknij podzielony panel.

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'
 

11. Otwórz Cloud Source Repos, korzystając z wygenerowanego linku.

echo https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo

Powinien być widoczny osobny commit dla każdego odsetka ruchu, a najnowszy commit powinien znajdować się na górze listy:

Teraz powtórz te same czynności w przypadku regionu Dev2. Pamiętaj, że region Dev2 jest nadal „zablokowany” w wersji 1. Dzieje się tak, ponieważ w skrypcie repo_setup w repozytorium bazowym wysłaliśmy VirtualService, aby wyraźnie kierować cały ruch do wersji 1. Dzięki temu mogliśmy bezpiecznie przeprowadzić test kanarkowy w regionie Dev1 i upewnić się, że działa on prawidłowo, zanim wdrożyliśmy nową wersję na całym świecie.

12. Uruchom polecenie, aby podzielić okno Cloud Shell i wykonać polecenie watch w dolnym panelu.

RESPY_POD=$(kubectl --context $DEV2_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV2_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

Dane wyjściowe (nie kopiuj ich)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

Widzimy, że cały ruch jest kierowany do wdrożenia frontend v1 zdefiniowanego w nowej usłudze wirtualnej.

13. Uruchom potok wczesnych testów w regionie Dev2. Udostępniamy skrypt, który aktualizuje procent ruchu frontend-v2 w VirtualService (aktualizując wagi do 20%, 50%, 80%, a następnie 100%). Między aktualizacjami skrypt czeka na zakończenie potoku Cloud Build. Uruchom skrypt wdrożenia do wczesnych testów w regionie Dev1. Uwaga: wykonanie tego skryptu zajmuje około 10 minut.

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_2_CLUSTER OPS_CONTEXT=$OPS_GKE_2 \
${CANARY_DIR}/auto-canary.sh
 

Dane wyjściowe (nie kopiuj ich)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

14. W podzie Respy w Dev2 obserwuj, jak ruch z podów Dev2 stopniowo przechodzi z frontend v1 na v2. Po zakończeniu skryptu powinien się wyświetlić ten komunikat:

Dane wyjściowe (nie kopiuj ich)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

15. Zamknij podzielony panel.

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'

W tej sekcji przedstawiliśmy sposób używania Istio do regionalnych wdrożeń wersji do wczesnych testów. W środowisku produkcyjnym zamiast ręcznego skryptu możesz automatycznie wywoływać ten skrypt kanaryjny jako potok Cloud Build, używając aktywatora, takiego jak nowy otagowany obraz przesłany do rejestru kontenerów. Warto też dodać analizę wczesnych testów między poszczególnymi krokami, aby porównać opóźnienie i odsetek błędów wersji 2 z wcześniej zdefiniowanym progiem bezpieczeństwa, zanim prześlesz więcej ruchu.

11. Zasady autoryzacji

Cel: skonfigurowanie RBAC między mikroserwisami (AuthZ).

• Utwórz AuthorizationPolicy, aby ODMÓWIĆ dostępu do mikroserwisu.
• Utwórz AuthorizationPolicy, aby ZEZWOLIĆ na określony dostęp do mikroserwisu.

FAST TRACK SCRIPT

Jeśli wybierzesz tę metodę, uruchom ten skrypt, aby ukończyć ten moduł.

${WORKDIR}/asm/fasttrack_scripts/authorization-policy.sh

Instrukcje dotyczące modułu z metodą kopiowania i wklejania

Jeśli skrypt szybkiej ścieżki do tego laboratorium został już przez Ciebie wykonany, nie stosuj poniższej metody kopiowania i wklejania**.

W przeciwieństwie do aplikacji monolitycznej, która może działać w jednym miejscu, aplikacje oparte na mikroserwisach rozmieszczonych na całym świecie wykonują wywołania poza granicami sieci. Oznacza to więcej punktów wejścia do aplikacji i większe możliwości przeprowadzania złośliwych ataków. A ponieważ pody Kubernetes mają tymczasowe adresy IP, tradycyjne reguły zapory sieciowej oparte na adresach IP nie wystarczają już do zabezpieczenia dostępu między zbiorami zadań. W architekturze mikroserwisów potrzebne jest nowe podejście do bezpieczeństwa. Istio korzysta z elementów zabezpieczeń Kubernetes, takich jak konta usługi, i udostępnia elastyczny zestaw zasad zabezpieczeń dla aplikacji.

Zasady Istio obejmują zarówno uwierzytelnianie, jak i autoryzację. Uwierzytelnianie weryfikuje tożsamość (czy ten serwer jest tym, za kogo się podaje?), a autoryzacja weryfikuje uprawnienia (czy ten klient może to zrobić?). Uwierzytelnianie Istio omówiliśmy w sekcji dotyczącej wzajemnego uwierzytelniania TLS w module 1 (MeshPolicy). W tej sekcji dowiesz się, jak używać zasad autoryzacji Istio do kontrolowania dostępu do jednego z naszych zadań aplikacji, currencyservice.

Najpierw wdrożymy AuthorizationPolicy we wszystkich 4 klastrach deweloperskich, blokując dostęp do usługi currencyservice i wywołując błąd w interfejsie. Następnie zezwolimy tylko usłudze frontend na dostęp do usługi currencyservice.

1. Sprawdź zawartość currency-deny-all.yaml. Ta zasada używa selektorów etykiet wdrożenia, aby ograniczyć dostęp do usługi currencyservice. Zwróć uwagę, że nie ma pola spec – oznacza to, że ta zasada odmówi dostępu do wybranej usługi.

cat $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml
 

Dane wyjściowe (nie kopiuj ich)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice

2. Skopiuj zasadę dotyczącą waluty do repozytorium k8s w przypadku klastrów operacyjnych w obu regionach.

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml

3. Przesyłanie zmian.

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: deny all"
git push 

4. Sprawdź stan projektu operacyjnego Cloud Build na wcześniej otwartej karcie lub klikając ten link:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name 
 

5. Po pomyślnym zakończeniu kompilacji spróbuj otworzyć interfejs hipstershop w przeglądarce, korzystając z tego linku:

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

Powinien pojawić się błąd autoryzacji z usługi currencyservice:

6. Sprawdźmy, jak usługa walutowa egzekwuje tę zasadę AuthorizationPolicy. Najpierw włącz dzienniki na poziomie śledzenia w przypadku serwera proxy Envoy dla jednego z podów waluty, ponieważ zablokowane wywołania autoryzacji nie są domyślnie rejestrowane.

CURRENCY_POD=$(kubectl --context $DEV1_GKE_2 get pod -n currency | grep currency| awk '{ print $1 }')
kubectl --context $DEV1_GKE_2 exec -it $CURRENCY_POD -n \
currency -c istio-proxy -- curl -X POST \
"http://localhost:15000/logging?level=trace"
 

7. Pobierz dzienniki RBAC (autoryzacji) z pomocniczego proxy usługi walutowej. Powinien pojawić się komunikat „enforced denied” (wymuszone odrzucenie), co oznacza, że usługa currencyservice jest skonfigurowana tak, aby blokować wszystkie żądania przychodzące.

kubectl --context $DEV1_GKE_2 logs -n currency $CURRENCY_POD \
-c istio-proxy | grep -m 3 rbac
 

Dane wyjściowe (nie kopiuj ich)

[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:67] checking request: remoteAddress: 10.16.5.15:37310, localAddress: 10.16.3.8:7000, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/frontend/sa/frontend, subjectPeerCertificate: , headers: ':method', 'POST'
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:118] enforced denied
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1354] [C115][S17310331589050212978] Sending local reply with details rbac_access_denied

8. Teraz zezwalajmy na dostęp do usługi currencyservice tylko w przypadku frontendu, a nie innych usług backendu. Otwórz plik currency-allow-frontend.yaml i sprawdź jego zawartość. Zauważ, że dodaliśmy tę regułę:

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml

Dane wyjściowe (nie kopiuj ich)

rules:
 - from:
   - source:
       principals: ["cluster.local/ns/frontend/sa/frontend"]

W tym przypadku dodajemy do listy dozwolonych konkretny element source.principal (klienta), aby uzyskać dostęp do usługi walutowej. To pole source.principal jest zdefiniowane przez konto usługi Kubernetes. W tym przypadku konto usługi, które dodajemy do listy dozwolonych, to konto usługi frontendu w przestrzeni nazw frontendu.

Uwaga: gdy używasz kont usługi Kubernetes w zasadach autoryzacji Istio, musisz najpierw włączyć wzajemne uwierzytelnianie TLS w całym klastrze, tak jak w module 1. Dzięki temu dane logowania konta usługi są dołączane do żądań.

9. Skopiuj zaktualizowane zasady dotyczące walut

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

10. Przesyłanie zmian.

cd $WORKDIR/k8s-repo
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend"
git push
 

11. Sprawdź stan projektu operacyjnego Cloud Build w otwartej wcześniej karcie lub klikając ten link:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name

12. Po pomyślnym zakończeniu kompilacji ponownie otwórz interfejs Hipstershop. Tym razem nie powinno być żadnych błędów na stronie głównej, ponieważ interfejs ma wyraźnie przyznany dostęp do bieżącej usługi.
13. Teraz spróbuj zrealizować płatność, dodając produkty do koszyka i klikając „Złóż zamówienie”. Tym razem powinien pojawić się błąd przeliczenia ceny z usługi walutowej – dzieje się tak, ponieważ dodaliśmy do białej listy tylko frontend, więc usługa checkoutservice nadal nie ma dostępu do usługi currencyservice.

14. Na koniec przyznajmy usłudze płatności dostęp do waluty, dodając kolejną regułę do zasady AuthorizationPolicy usługi currencyservice. Pamiętaj, że dostęp do waluty otwieramy tylko dla 2 usług, które go potrzebują – frontendu i płatności. Pozostałe backendy będą nadal blokowane.
15. Otwórz plik currency-allow-frontend-checkout.yaml i sprawdź jego zawartość. Zwróć uwagę, że lista reguł działa jak logiczne OR – waluta będzie akceptować tylko żądania z obciążeń z jednym z tych 2 kont usług.

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml
 

Dane wyjściowe (nie kopiuj ich)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/checkout/sa/checkout"]

16. Skopiuj ostateczne zasady autoryzacji do repozytorium k8s.

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

17. Przesyłanie zmian

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend and checkout"
git push
 

18. Sprawdź stan projektu operacyjnego Cloud Build w otwartej wcześniej karcie lub klikając ten link:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name
 

19. Po pomyślnym zakończeniu kompilacji spróbuj zrealizować płatność – powinna się udać.

W tej sekcji opisaliśmy, jak używać zasad autoryzacji Istio do egzekwowania szczegółowej kontroli dostępu na poziomie poszczególnych usług. W środowisku produkcyjnym możesz utworzyć jedną zasadę AuthorizationPolicy na usługę i (na przykład) użyć zasady zezwalającej na wszystko, aby umożliwić wszystkim zadaniom w tej samej przestrzeni nazw wzajemny dostęp.

12. Skalowanie infrastruktury

Cel: skalowanie infrastruktury przez dodawanie nowych regionów, projektów i klastrów.

• Sklonuj repozytorium infrastructure.
• Aktualizowanie plików Terraform w celu utworzenia nowych zasobów
• 2 podsieci w nowym regionie (jedna dla projektu operacyjnego i jedna dla nowego projektu).
• Nowy klaster operacyjny w nowym regionie (w nowej podsieci)
• Nowa platforma sterująca Istio w nowym regionie
• 2 klastry aplikacji w nowym projekcie w nowym regionie
• Zatwierdź w repozytorium infrastructure
• Zweryfikuj instalację

FAST TRACK SCRIPT

Jeśli wybierzesz tę metodę, uruchom ten skrypt, aby ukończyć ten moduł.

${WORKDIR}/asm/fasttrack_scripts/infrastructure-scaling.sh

Instrukcje dotyczące modułu z metodą kopiowania i wklejania

Jeśli skrypt szybkiej ścieżki do tego laboratorium został już przez Ciebie wykonany, nie stosuj poniższej metody kopiowania i wklejania**.

Istnieje wiele sposobów skalowania platformy. Możesz zwiększyć moc obliczeniową, dodając węzły do istniejących klastrów. W regionie możesz dodać więcej klastrów. Możesz też dodać do platformy więcej regionów. Decyzja o tym, który aspekt platformy należy skalować, zależy od wymagań. Jeśli na przykład masz klastry we wszystkich 3 strefach w regionie, być może wystarczy dodanie większej liczby węzłów (lub pul węzłów) do istniejącego klastra. Jeśli jednak masz klastry w 2 z 3 stref w jednym regionie, dodanie nowego klastra w trzeciej strefie zapewni Ci skalowanie i dodatkową domenę błędów (czyli nową strefę). Innym powodem dodania nowego klastra w regionie może być konieczność utworzenia klastra z jednym najemcą ze względu na przepisy lub wymagania dotyczące zgodności (np. PCI lub klaster bazy danych, w którym przechowywane są informacje umożliwiające identyfikację). W miarę rozwoju firmy i usług dodawanie nowych regionów staje się nieuniknione, aby świadczyć usługi bliżej klientów.

Obecna platforma składa się z 2 regionów i klastrów w 2 strefach w każdym regionie. Skalowanie platformy można rozpatrywać na 2 sposoby:

• W pionie – w każdym regionie przez dodanie większej mocy obliczeniowej. Możesz to zrobić, dodając więcej węzłów (lub pul węzłów) do istniejących klastrów albo dodając nowe klastry w regionie. Możesz to zrobić w repozytorium infrastructure. Najprostszym sposobem jest dodanie węzłów do istniejących klastrów. Żadna dodatkowa konfiguracja nie jest wymagana. Dodanie nowych klastrów może wymagać dodatkowych podsieci (i zakresów dodatkowych), dodania odpowiednich reguł zapory sieciowej, dodania nowych klastrów do regionalnej platformy sterującej siatki usług ASM/Istio i wdrożenia zasobów aplikacji w nowych klastrach.
• Poziomo – przez dodanie większej liczby regionów. Obecna platforma udostępnia szablon regionalny. Składa się on z regionalnego klastra operacyjnego, w którym znajduje się platforma sterująca ASM/Istio, oraz z co najmniej 2 klastrów aplikacji strefowych, w których wdrożone są zasoby aplikacji.

W tych warsztatach będziesz skalować platformę „w poziomie”, ponieważ obejmuje ona również kroki związane z przypadkiem użycia w pionie. Aby skalować platformę w poziomie przez dodanie do niej nowego regionu (r3), musisz dodać te zasoby:

1. Podsieci w głównym projekcie współdzielonego środowiska VPC w regionie r3 dla nowych klastrów operacyjnych i aplikacji.
2. Regionalny klaster operacyjny w regionie r3, w którym znajduje się platforma sterująca ASM/Istio.
3. 2 klastry aplikacji strefowych w 2 strefach w regionie r3.
4. Zaktualizuj repozytorium k8s:
5. Wdróż zasoby platformy sterującej ASM/Istio w klastrze operacyjnym w regionie r3.
6. Wdróż zasoby wspólnej platformy sterującej ASM/Istio w klastrach aplikacji w regionie r3.
7. Nie musisz tworzyć nowego projektu, ale w warsztatach pokazujemy, jak dodać nowy projekt dev3, aby przedstawić przypadek użycia polegający na dodaniu do platformy nowego zespołu.

Repozytorium infrastruktury służy do dodawania nowych zasobów wymienionych powyżej.

1. W Cloud Shell przejdź do WORKDIR i sklonuj repozytorium infrastructure.

mkdir -p $WORKDIR/infra-repo
cd $WORKDIR/infra-repo
git init && git remote add origin https://source.developers.google.com/p/${TF_ADMIN}/r/infrastructure
git config --local user.email ${MY_USER}
git config --local user.name "infra repo user"
git config --local credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

2. Sklonuj repozytorium źródłowe warsztatów w gałęzi add-proj do katalogu add-proj-repo.

cd $WORKDIR
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git add-proj-repo -b add-proj

 

3. Skopiuj pliki z gałęzi add-proj w repozytorium warsztatowym źródłowym. Gałąź add-proj zawiera zmiany w tej sekcji.

cp -r $WORKDIR/add-proj-repo/infrastructure/* $WORKDIR/infra-repo/
 

4. Zastąp katalog infrastructure w katalogu repozytorium add-proj symlinkiem do katalogu infra-repo, aby umożliwić uruchamianie skryptów w gałęzi.

rm -rf $WORKDIR/add-proj-repo/infrastructure
ln -s $WORKDIR/infra-repo $WORKDIR/add-proj-repo/infrastructure
 

5. Uruchom skrypt add-project.sh, aby skopiować stany współdzielone i zmienne do nowej struktury katalogów projektu.

$WORKDIR/add-proj-repo/scripts/add-project.sh app3 $WORKDIR/asm $WORKDIR/infra-repo

6. Zatwierdzanie i przesyłanie zmian w celu utworzenia nowego projektu

cd $WORKDIR/infra-repo
git add .
git status
git commit -m "add new project" && git push origin master
 

7. Zatwierdzenie powoduje wdrożenie infrastruktury z nowymi zasobami w repozytorium infrastructure. Postępy kompilacji Cloud Build możesz sprawdzić, klikając wynik poniższego linku i przechodząc do najnowszej kompilacji u góry.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

Wykonanie tego kroku zajmuje 25–30 minut. Czas na przerwę na kawę.

W ostatnim kroku infrastructure Cloud Build tworzy nowe zasoby Kubernetes w k8s-repo. Spowoduje to uruchomienie Cloud Build w projekcie k8s-repo (w projekcie operacyjnym). Nowe zasoby Kubernetes dotyczą 3 nowych klastrów dodanych w poprzednim kroku. Do nowych klastrów dodawane są zasoby platformy sterującej ASM/Istio i współdzielonej platformy sterującej za pomocą k8s-repo Cloud Build.

8. Po zakończeniu działania infrastruktury Cloud Build przejdź do k8s-reponajnowszego uruchomienia Cloud Build, klikając ten link wyjściowy.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

9. Uruchom ten skrypt, aby dodać nowe klastry do pliku vars i kubeconfig.

$WORKDIR/add-proj-repo/scripts/setup-gke-vars-kubeconfig-add-proj.sh $WORKDIR/asm
 

10. Zmień zmienną KUBECONFIG, aby wskazywała nowy plik kubeconfig.

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

11. Wyświetl konteksty klastra. Powinno być widocznych 8 klastrów.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_user001-200204-05-dev1-49tqc4_us-west1-a_gke-1-apps-r1a-prod
gke_user001-200204-05-dev1-49tqc4_us-west1-b_gke-2-apps-r1b-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-a_gke-3-apps-r2a-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-b_gke-4-apps-r2b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-b_gke-5-apps-r3b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-c_gke-6-apps-r3c-prod
gke_user001-200204-05-ops-49tqc4_us-central1_gke-asm-2-r2-prod
gke_user001-200204-05-ops-49tqc4_us-east1_gke-asm-3-r3-prod
gke_user001-200204-05-ops-49tqc4_us-west1_gke-asm-1-r1-prod

Weryfikowanie instalacji Istio

12. Sprawdź, czy Istio jest zainstalowane w nowym klastrze operacyjnym. W tym celu sprawdź, czy wszystkie pody są uruchomione, a zadania zostały wykonane.

kubectl --context $OPS_GKE_3 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-72g6w                  1/1     Running   0          5h12m
istio-citadel-7d8595845-hmmvj             1/1     Running   0          5h12m
istio-egressgateway-779b87c464-rw8bg      1/1     Running   0          5h12m
istio-galley-844ddfc788-zzpkl             2/2     Running   0          5h12m
istio-ingressgateway-59ccd6574b-xfj98     1/1     Running   0          5h12m
istio-pilot-7c8989f5cf-5plsg              2/2     Running   0          5h12m
istio-policy-6674bc7678-2shrk             2/2     Running   3          5h12m
istio-sidecar-injector-7795bb5888-kbl5p   1/1     Running   0          5h12m
istio-telemetry-5fd7cbbb47-c4q7b          2/2     Running   2          5h12m
istio-tracing-cd67ddf8-2qwkd              1/1     Running   0          5h12m
istiocoredns-5f7546c6f4-qhj9k             2/2     Running   0          5h12m
kiali-7964898d8c-l74ww                    1/1     Running   0          5h12m
prometheus-586d4445c7-x9ln6               1/1     Running   0          5h12m

13. Upewnij się, że Istio jest zainstalowane w obu klastrach dev3. W klastrach dev3 działają tylko usługi Citadel, sidecar-injector i coredns. Korzystają one ze wspólnej platformy sterującej Istio działającej w klastrze ops-3.

kubectl --context $DEV3_GKE_1 get pods -n istio-system
kubectl --context $DEV3_GKE_2 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

Weryfikowanie wykrywania usług w przypadku współdzielonych płaszczyzn sterowania

14. Sprawdź, czy obiekty tajne są wdrażane we wszystkich klastrach operacyjnych dla wszystkich 6 klastrów aplikacji.

kubectl --context $OPS_GKE_1 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_2 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_3 get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      14h
gke-2-apps-r1b-prod   Opaque   1      14h
gke-3-apps-r2a-prod   Opaque   1      14h
gke-4-apps-r2b-prod   Opaque   1      14h
gke-5-apps-r3b-prod   Opaque   1      5h12m
gke-6-apps-r3c-prod   Opaque   1      5h12m

13. Wyłączanie obwodu

Cel: wdrożenie wyłącznika awaryjnego dla usługi dostawy.

• Utwórz DestinationRule dla shipping usługi, aby wdrożyć bezpiecznik.
• Użyj narzędzia fortio (do generowania obciążenia), aby sprawdzić bezpiecznik usługi shipping, wymuszając wyłączenie obwodu.

Instrukcje dotyczące Fast Track Script Lab

Fast Track Script Lab już wkrótce!!

Instrukcje dotyczące modułu z metodą kopiowania i wklejania

Znasz już podstawowe strategie monitorowania i rozwiązywania problemów z usługami obsługującymi Istio. Teraz zobaczmy, jak Istio pomaga zwiększyć odporność usług, co zmniejsza liczbę problemów, które musisz rozwiązywać.

Architektura mikroserwisów wiąże się z ryzykiem kaskadowych awarii, w których awaria jednej usługi może rozprzestrzenić się na jej zależności i zależności tych zależności, powodując efekt domina, który może potencjalnie wpłynąć na użytkowników. Istio udostępnia zasadę ruchu Circuit Breaker, która pomaga izolować usługi, chroniąc usługi podrzędne (po stronie klienta) przed oczekiwaniem na usługi, które nie działają, a usługi nadrzędne (po stronie serwera) przed nagłym zalewem ruchu podrzędnego, gdy wrócą do trybu online. Ogólnie rzecz biorąc, używanie wyłączników awaryjnych może pomóc uniknąć sytuacji, w której wszystkie usługi nie spełniają umów SLA z powodu jednej zawieszającej się usługi backendu.

Wzorzec wyłącznika obwodu zawdzięcza swoją nazwę wyłącznikowi elektrycznemu, który może się „wyłączyć”, gdy przepływa przez niego zbyt dużo prądu, chroniąc urządzenia przed przeciążeniem. W konfiguracji Istio oznacza to, że Envoy jest bezpiecznikiem, który śledzi liczbę oczekujących żądań usługi. W tym domyślnym stanie zamkniętym żądania przepływają przez Envoy bez przerw.

Gdy jednak liczba oczekujących żądań przekroczy zdefiniowany próg, wyłącznik obwodu zadziała (otworzy się), a Envoy natychmiast zwróci błąd. Dzięki temu serwer może szybko zgłosić klientowi błąd i zapobiec otrzymywaniu przez kod aplikacji serwera żądań klienta w przypadku przeciążenia.

Następnie po upływie określonego czasu oczekiwania Envoy przechodzi w stan półotwarty, w którym serwer może ponownie zacząć odbierać żądania w sposób próbny. Jeśli serwer będzie w stanie na nie odpowiadać, bezpiecznik ponownie się zamknie i żądania do serwera zaczną ponownie płynąć.

Ten diagram podsumowuje wzorzec bezpiecznika w Istio. Niebieskie prostokąty reprezentują Envoy, niebieskie kółko to klient, a białe kółka to kontener serwera:

Zasady wyłącznika możesz zdefiniować za pomocą reguł docelowych Istio. W tej sekcji zastosujemy te zasady, aby wymusić bezpiecznik w usłudze dostawy:

Output (do not copy)

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "shippingservice-shipping-destrule"
  namespace: "shipping"
spec:
  host: "shippingservice.shipping.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 10s
      maxEjectionPercent: 100

W tym przypadku warto zwrócić uwagę na 2 pola DestinationRule. connectionPool określa liczbę połączeń, na które zezwala ta usługa. W polu outlierDetection konfigurujemy sposób, w jaki Envoy określa próg, przy którym ma otworzyć bezpiecznik. W tym przypadku co sekundę (w interwale) Envoy będzie zliczać liczbę błędów otrzymanych z kontenera serwera. Jeśli przekroczy próg consecutiveErrors, bezpiecznik Envoy otworzy się i przez 10 sekund 100% podów productcatalog będzie chronionych przed nowymi żądaniami klientów. Gdy bezpiecznik Envoy jest otwarty (czyli aktywny), klienci otrzymują błędy 503 (usługa niedostępna). Zobaczmy, jak to działa.

1. Ustaw zmienne środowiskowe dla katalogów k8s-repo i asm, aby uprościć polecenia.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm" 
 

2. Aktualizowanie repozytorium k8s

cd $WORKDIR/k8s-repo
git pull
cd $WORKDIR

3. Zaktualizuj regułę DestinationRule usługi dostawy w obu klastrach operacyjnych.

cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml

cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
 

4. Skopiuj poda generatora obciążenia Fortio do klastra GKE_1 w regionie Dev1. Jest to pod klienta, którego użyjemy do „wyłączenia” bezpiecznika dla usługi shippingservice.

cp $ASM/k8s_manifests/prod/app/deployments/app-fortio.yaml ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments/
cd ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments; kustomize edit add resource app-fortio.yaml
 

5. Zatwierdź zmiany.

cd $K8S_REPO 
git add . && git commit -am "Circuit Breaker: shippingservice"
git push
cd $ASM
 

6. Poczekaj na zakończenie kompilacji w Cloud Build.
7. Wróć do Cloud Shell i użyj poda fortio, aby wysłać ruch gRPC do shippingservice z 1 jednoczesnym połączeniem i 1000 żądaniami łącznie. Nie spowoduje to wyłączenia wyłącznika, ponieważ nie przekroczyliśmy jeszcze ustawień connectionPool.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 1 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

Dane wyjściowe (nie kopiuj ich)

Health SERVING : 1000
All done 1000 calls (plus 0 warmup) 4.968 ms avg, 201.2 qps

8. Teraz ponownie uruchom fortio, zwiększając liczbę jednoczesnych połączeń do 2, ale zachowując stałą łączną liczbę żądań. Około 2/3 żądań powinno zwrócić błąd „overflow”, ponieważ bezpiecznik został aktywowany:w zdefiniowanych przez nas zasadach w 1-sekundowym przedziale czasu dozwolone jest tylko 1 jednoczesne połączenie.

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 2 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

Dane wyjściowe (nie kopiuj ich)

18:46:16 W grpcrunner.go:107> Error making grpc call: rpc error: code = Unavailable desc = upstream connect error or disconnect/reset before headers. reset reason: overflow
...

Health ERROR : 625
Health SERVING : 375
All done 1000 calls (plus 0 warmup) 12.118 ms avg, 96.1 qps

9. Envoy śledzi liczbę połączeń, które zostały przerwane, gdy bezpiecznik był aktywny, za pomocą wskaźnika upstream_rq_pending_overflow. Znajdźmy to w podzie fortio:

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep shipping | grep pending
 

Dane wyjściowe (nie kopiuj ich)

cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.default.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.high.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_active: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_failure_eject: 9
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_overflow: 565
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_total: 1433

10. Wyczyść, usuwając zasadę wyłącznika z obu regionów.

kubectl --context ${OPS_GKE_1} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
 

kubectl --context ${OPS_GKE_2} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
cd $K8S_REPO; git add .; git commit -m "Circuit Breaker: cleanup"; git push origin master
 

W tej sekcji pokazano, jak skonfigurować pojedyncze zasady bezpiecznika dla usługi. Sprawdzoną metodą jest skonfigurowanie bezpiecznika dla każdej usługi nadrzędnej (backendu), która może się zawiesić. Stosując zasady bezpiecznika obwodu Istio, możesz odizolować mikrousługi, wbudować w architekturę odporność na awarie i zmniejszyć ryzyko kaskadowych awarii przy dużym obciążeniu.

14. Wstrzykiwanie błędów

Cel: przetestowanie odporności usługi rekomendacji przez wprowadzenie opóźnień (zanim zostanie ona wdrożona w środowisku produkcyjnym).

• Utwórz VirtualService dla recommendation Service, aby wprowadzić 5-sekundowe opóźnienie.
• Testowanie opóźnienia za pomocą fortio generatora obciążenia
• Usuń opóźnienie w VirtualService i sprawdź poprawność.

Instrukcje dotyczące Fast Track Script Lab

Fast Track Script Lab już wkrótce!!

Instrukcje dotyczące modułu z metodą kopiowania i wklejania

Dodanie zasad bezpiecznika do usług to jeden ze sposobów na zwiększenie odporności usług w środowisku produkcyjnym. Jednak wyłączanie obwodu powoduje błędy — potencjalnie błędy widoczne dla użytkowników — co nie jest idealne. Aby uniknąć takich błędów i lepiej przewidywać, jak usługi podrzędne mogą reagować, gdy backendy zwracają błędy, możesz zastosować testowanie chaosu w środowisku testowym. Testowanie chaosu to praktyka polegająca na celowym wywoływaniu awarii usług w celu analizowania słabych punktów systemu i zwiększania odporności na błędy. Możesz też użyć testów chaosu, aby znaleźć sposoby na ograniczenie błędów widocznych dla użytkowników w przypadku awarii backendu, np. wyświetlając w frontendzie wynik z pamięci podręcznej.

Używanie Istio do wstrzykiwania błędów jest przydatne, ponieważ możesz używać obrazów wersji produkcyjnej i dodawać błędy na warstwie sieci zamiast modyfikować kod źródłowy. W środowisku produkcyjnym możesz używać w pełni funkcjonalnego narzędzia do testowania chaosu, aby testować odporność na warstwie Kubernetes/obliczeniowej oprócz warstwy sieciowej.

Do testowania chaosu możesz użyć Istio, stosując VirtualService z polem „fault”. Istio obsługuje 2 rodzaje błędów: błędy opóźnienia (wstrzykiwanie limitu czasu) i błędy przerwania (wstrzykiwanie błędów HTTP). W tym przykładzie wstrzykniemy do usługi rekomendacji błąd 5-sekundowego opóźnienia. Tym razem jednak zamiast używać bezpiecznika, aby „szybko zakończyć działanie” w przypadku zawieszenia usługi, wymusimy na usługach podrzędnych pełny limit czasu.

11. Przejdź do katalogu wstrzykiwania błędów.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm/" 
cd $ASM
 

12. Otwórz plik k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml, aby sprawdzić jego zawartość. Zwróć uwagę, że Istio ma opcję wstrzykiwania błędu do określonego odsetka żądań. W tym przypadku wprowadzimy limit czasu we wszystkich żądaniach dotyczących usługi rekomendacji.

Dane wyjściowe (nie kopiuj ich)

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation-delay-fault
spec:
  hosts:
  - recommendationservice.recommendation.svc.cluster.local
  http:
  - route:
    - destination:
        host: recommendationservice.recommendation.svc.cluster.local
    fault:
      delay:
        percentage:
          value: 100
        fixedDelay: 5s

13. Skopiuj VirtualService do k8s_repo. Wprowadzimy błąd globalnie, w obu regionach.

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml
 

14. Przesyłanie zmian

cd $K8S_REPO 
git add . && git commit -am "Fault Injection: recommendationservice"
git push
cd $ASM
 

15. Poczekaj na zakończenie kompilacji w Cloud Build.
16. Wykonaj polecenie exec w podzie fortio wdrożonym w sekcji bezpiecznika i wyślij przeciętny ruch do usługi recommendationservice.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 100 -n 100 -qps 0 recommendationservice.recommendation.svc.cluster.local:8080
 

    Once the fortio command is complete, you should see responses averaging 5s:

Dane wyjściowe (nie kopiuj ich)

Ended after 5.181367359s : 100 calls. qps=19.3
Aggregated Function Time : count 100 avg 5.0996506 +/- 0.03831 min 5.040237641 max 5.177559818 sum 509.965055

17. Innym sposobem na sprawdzenie, czy wstrzyknięta przez nas usterka działa, jest otwarcie frontendu w przeglądarce i kliknięcie dowolnego produktu. Wczytywanie strony produktu powinno trwać 5 sekund dłużej, ponieważ pobiera ona rekomendacje wyświetlane u dołu strony.
18. Czyszczenie przez usunięcie usługi wstrzykiwania błędów z obu klastrów operacyjnych.

kubectl --context ${OPS_GKE_1} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml

kubectl --context ${OPS_GKE_2} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml
 

19. Przesyłanie zmian:

cd $K8S_REPO 
git add . && git commit -am "Fault Injection cleanup / restore"
git push
cd $ASM
 

15. Monitorowanie platformy sterującej Istio

ASM instaluje 4 ważne komponenty platformy sterującej: Pilot, Mixer, Galley i Citadel. Każda z nich wysyła odpowiednie wskaźniki monitorowania do Prometheusa, a ASM zawiera panele Grafana, które umożliwiają operatorom wizualizację tych danych monitorowania i ocenę stanu oraz wydajności platformy sterującej.

Wyświetlanie paneli informacyjnych

20. Przekierowywanie portów usługi Grafana zainstalowanej za pomocą Istio

kubectl --context ${OPS_GKE_1} -n istio-system port-forward svc/grafana 3000:3000 >> /dev/null
 

21. Otwórz Grafanę w przeglądarce
22. W prawym górnym rogu okna Cloud Shell kliknij ikonę „Podgląd w przeglądarce”.
23. Kliknij Podgląd na porcie 3000 (uwaga: jeśli port nie jest ustawiony na 3000, kliknij Zmień port i wybierz port 3000).
24. Spowoduje to otwarcie karty w przeglądarce z adresem URL podobnym do „ BASE_URL/?orgId=1&authuser=0&environment_id=default”.
25. Wyświetlanie dostępnych paneli
26. Zmień adres URL na „BASE_URL/dashboard”.
27. Kliknij folder „istio”, aby wyświetlić dostępne panele.
28. Kliknij dowolny z tych paneli, aby wyświetlić skuteczność danego komponentu. W kolejnych sekcjach omówimy ważne dane dotyczące każdego komponentu.

Monitoring Pilot

Pilot to komponent platformy sterującej, który rozpowszechnia konfigurację sieci i zasad na platformę danych (serwery proxy Envoy). Pilot zwykle skaluje się wraz z liczbą zbiorów zadań i wdrożeń, choć niekoniecznie z ilością ruchu do tych zbiorów zadań. Niesprawny Pilot może:

• zużywać więcej zasobów niż to konieczne (procesora lub pamięci RAM);
• może powodować opóźnienia w przesyłaniu zaktualizowanych informacji o konfiguracji do urządzeń Envoy.

Uwaga: jeśli Pilot nie działa lub występują opóźnienia, Twoje obciążenia nadal obsługują ruch.

23. W przeglądarce otwórz adres „ BASE_URL/dashboard/db/istio-pilot-dashboard”, aby wyświetlić dane Pilot.

Ważne monitorowane wskaźniki

Wykorzystanie zasobów

Skorzystaj ze wskazówek na stronie dotyczącej wydajności i skalowalności Istio, aby poznać dopuszczalne wartości użycia. Jeśli zauważysz znacznie większe zużycie zasobów, skontaktuj się z zespołem pomocy GCP.

Informacje o programie pilotażowym Push

W tej sekcji monitorowane są wysyłane przez Pilot konfiguracje do serwerów proxy Envoy.

• Pilot Pushes pokazuje typ konfiguracji przesłanej w danym momencie.
• Monitorowanie ADS pokazuje liczbę usług wirtualnych, usług i połączonych punktów końcowych w systemie.
• Klastry bez znanych punktów końcowych wyświetlają punkty końcowe, które zostały skonfigurowane, ale nie mają uruchomionych instancji (co może wskazywać usługi zewnętrzne, takie jak *.googleapis.com).
• Błędy pilotażowe pokazują liczbę błędów napotkanych w danym okresie.
• Konflikty pokazują liczbę konfliktów, które są niejednoznaczną konfiguracją odbiorników.

Jeśli widzisz błędy lub konflikty, oznacza to, że co najmniej jedna z Twoich usług ma nieprawidłową lub niespójną konfigurację. Więcej informacji znajdziesz w artykule Rozwiązywanie problemów z płaszczyzną danych.

Informacje o usłudze Envoy

Ta sekcja zawiera informacje o serwerach proxy Envoy, które kontaktują się z platformą sterującą. Jeśli widzisz powtarzające się błędy połączenia XDS, skontaktuj się z zespołem pomocy GCP.

Mikser monitorujący

Mikser to komponent, który przekazuje dane telemetryczne z serwerów proxy Envoy do backendów telemetrycznych (zwykle Prometheus, Stackdriver itp.). W tym przypadku nie znajduje się w płaszczyźnie danych. Jest on wdrażany jako 2 zadania Kubernetes (o nazwie Mixer) z 2 różnymi nazwami usług (istio-telemetry i istio-policy).

Mixer może też służyć do integracji z systemami zasad. W tym zakresie Mixer ma wpływ na płaszczyznę danych, ponieważ w przypadku niepowodzenia sprawdzania zasad w Mixerze dostęp do usług jest blokowany.

Mikser zwykle skaluje się wraz z natężeniem ruchu.

24. W przeglądarce otwórz adres „BASE_URL/dashboard/db/istio-mixer-dashboard”, aby wyświetlić dane Mixer.

Ważne monitorowane dane

Wykorzystanie zasobów

Skorzystaj ze wskazówek na stronie dotyczącej wydajności i skalowalności Istio, aby poznać dopuszczalne wartości użycia. Jeśli zauważysz znacznie większe zużycie zasobów, skontaktuj się z zespołem pomocy GCP.

Omówienie usługi Mixer

• Czas odpowiedzi to ważny wskaźnik. Chociaż raporty do telemetrii Mixera nie znajdują się na ścieżce danych, jeśli te opóźnienia są duże, z pewnością spowolnią działanie pomocniczego proxy. Wartość 90 percentyla powinna wynosić kilka milisekund, a wartość 99 percentyla – poniżej 100 ms.

• Adapter Dispatch Duration (Czas wysyłania adaptera) wskazuje opóźnienie, z jakim Mixer wywołuje adaptery (za ich pomocą wysyła informacje do systemów telemetrii i logowania). Wysokie opóźnienia w tym przypadku z pewnością wpłyną na wydajność sieci mesh. Ponownie, wartości p90 czasu oczekiwania powinny być mniejsze niż 10 ms.

Monitorowanie kuchni

Galley to komponent Istio do weryfikacji, pobierania, przetwarzania i dystrybucji konfiguracji. Przekazuje konfigurację z serwera Kubernetes API do komponentu Pilot. Podobnie jak Pilot, ma tendencję do skalowania się wraz z liczbą usług i punktów końcowych w systemie.

25. W przeglądarce otwórz adres „BASE_URL/dashboard/db/istio-galley-dashboard”, aby wyświetlić dane Galley.

Ważne monitorowane dane

Weryfikacja zasobów

Najważniejszy wskaźnik, który należy śledzić, ponieważ wskazuje liczbę zasobów różnych typów, takich jak reguły docelowe, bramy i wpisy usług, które przechodzą lub nie przechodzą weryfikacji.

Połączone klienty

Wskazuje, ilu klientów jest połączonych z Galley. Zwykle jest to 3 klientów (pilot, istio-telemetry, istio-policy), a liczba ta będzie się zwiększać wraz ze skalowaniem tych komponentów.

16. Rozwiązywanie problemów z Istio

Rozwiązywanie problemów z płaszczyzną danych

Jeśli na panelu pilota widać, że masz problemy z konfiguracją, sprawdź dzienniki pilota lub użyj narzędzia istioctl, aby znaleźć problemy z konfiguracją.

Aby sprawdzić logi pilota, uruchom polecenie kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery, zastępując istio-pilot-... identyfikatorem poda instancji pilota, z którą chcesz rozwiązać problem.

W wyświetlonym dzienniku wyszukaj wiadomość Push Status. Na przykład:

2019-11-07T01:16:20.451967Z        info        ads        Push Status: {
    "ProxyStatus": {
        "pilot_conflict_outbound_listener_tcp_over_current_tcp": {
            "0.0.0.0:443": {
                "proxy": "cartservice-7555f749f-k44dg.hipster",
                "message": "Listener=0.0.0.0:443 AcceptedTCP=accounts.google.com,*.googleapis.com RejectedTCP=edition.cnn.com TCPServices=2"
            }
        },
        "pilot_duplicate_envoy_clusters": {
            "outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            }
        },
        "pilot_eds_no_instances": {
            "outbound_.80_._.frontend-external.hipster.svc.cluster.local": {},
            "outbound|443||*.googleapis.com": {},
            "outbound|443||accounts.google.com": {},
            "outbound|443||metadata.google.internal": {},
            "outbound|80||*.googleapis.com": {},
            "outbound|80||accounts.google.com": {},
            "outbound|80||frontend-external.hipster.svc.cluster.local": {},
            "outbound|80||metadata.google.internal": {}
        },
        "pilot_no_ip": {
            "loadgenerator-778c8489d6-bc65d.hipster": {
                "proxy": "loadgenerator-778c8489d6-bc65d.hipster"
            }
        }
    },
    "Version": "o1HFhx32U4s="
}

Stan pusha będzie wskazywać wszelkie problemy, które wystąpiły podczas próby przesłania konfiguracji do serwerów proxy Envoy. W tym przypadku widzimy kilka komunikatów „Duplicate cluster”, które wskazują zduplikowane miejsca docelowe upstream.

Jeśli potrzebujesz pomocy w diagnozowaniu problemów, skontaktuj się z zespołem pomocy Google Cloud.

Wyszukiwanie błędów konfiguracji

Aby przeanalizować konfigurację za pomocą narzędzia istioctl, uruchom polecenie istioctl experimental analyze -k --context $OPS_GKE_1. Przeprowadzi to analizę konfiguracji w Twoim systemie i wskaże wszelkie problemy wraz z sugerowanymi zmianami. Pełną listę błędów konfiguracji, które może wykryć to polecenie, znajdziesz w dokumentacji.

17. Czyszczenie

Poniższe czynności wykonuje administrator po zakończeniu warsztatów.

Administrator uruchamia skrypt cleanup_workshop.sh, aby usunąć zasoby utworzone przez skrypt bootstrap_workshop.sh. Aby uruchomić skrypt czyszczący, potrzebujesz tych informacji.

• Nazwa organizacji – np. yourcompany.com
• Identyfikator warsztatu – w formacie YYMMDD-NN, np. 200131-01
• Zasobnik GCS administratora – zdefiniowany w skrypcie początkowym.

13. Otwórz Cloud Shell i wykonaj w nim wszystkie poniższe działania. Kliknij link poniżej.

CLOUD SHELL

14. Sprawdź, czy jesteś zalogowany(a) w gcloud jako odpowiedni użytkownik z uprawnieniami administracyjnymi.

gcloud config list
 

15. Przejdź do folderu asm.

cd ${WORKDIR}/asm
 

16. Określ nazwę organizacji i identyfikator warsztatu, które chcesz usunąć.

export ORGANIZATION_NAME=<ORGANIZATION NAME>
export ASM_WORKSHOP_ID=<WORKSHOP ID>
export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

17. Uruchom skrypt czyszczenia w ten sposób:

./scripts/cleanup_workshop.sh --workshop-id ${ASM_WORKSHOP_ID} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --org-name ${ORGANIZATION_NAME}