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

1. WARSZTATY ALFA

WAŻNA UWAGA: PRZEDSTAWIAJĄ WARSZTATY ALFA I MAJĄ STACJĘ SZKOLENIE CLASSROOM DLA INSTRUKTORÓW.

Link do ćwiczeń z programowania: bit.ly/asm-workshop

2. Omówienie

Schemat architektury

Te warsztaty są praktycznym doświadczeniem, z którego dowiesz się, jak skonfigurować globalnie rozproszone usługi w GCP w środowisku produkcyjnym. Główne używane technologie to Google Kubernetes Engine (GKE) do obliczeń i siatka usług Istio do tworzenia bezpiecznych połączeń, dostrzegalności i zaawansowanego modelowania ruchu. Wszystkie metody i narzędzia wykorzystywane podczas tych warsztatów można wykorzystać w produkcji.

Plan dnia

• Moduł 0. Wprowadzenie i konfiguracja platformy
• Wprowadzenie i architektura
• Wprowadzenie do Service Mesh i Istio/ASM
• Moduł: Konfiguracja infrastruktury: przepływ pracy użytkownika
• Przerwa
• QnA
• Moduł 1. Instalowanie, zabezpieczanie i monitorowanie aplikacji za pomocą ASM
• Model repozytorium: omówienie repozytoriów Kubernetes i infrastruktury
• Moduł: wdrażanie przykładowej aplikacji
• Usługi rozproszone i obserwowalność
• Obiad
• Moduł: Dostrzegalność w usłudze Stackdriver
• QNA
• Moduł 2 – DevOps – wdrożenia do wczesnych testów, zasady/RBAC
• Wykrywanie usług wieloklastrowych, zabezpieczenia i zasady
• Moduł: Wzajemne szyfrowanie 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
• Moduł: zasady autoryzacji
• QNA
• Moduł 3 – Operacje związane z infrastrukturą – uaktualnienia platformy
• Elementy składowe usług rozproszonych
• Moduł: Skalowanie infrastruktury
• Dalsze kroki

Prezentacje

Slajdy z tych warsztatów są dostępne pod tym linkiem:

Prezentacje warsztatów ASM

Wymagania wstępne

Przed rozpoczęciem warsztatów musisz spełnić te wymagania:

1. Węzeł organizacji GCP
2. identyfikator konta rozliczeniowego (użytkownik musi być administratorem odpowiedzialnym za płatności na tym koncie rozliczeniowym);
3. Rola uprawnień administratora organizacji na poziomie organizacji dla użytkownika.

3. Konfiguracja infrastruktury – przepływ pracy administratora

Kroki z tej sekcji są wykonywane przez administratora tworzącego warsztaty.

Jeśli jesteś użytkownikiem biorącym udział w warsztatach, przejdź do następnej sekcji o nazwie Infrastructure Setup - User Workflow.

Objaśnienie skryptu warsztatu wczytywania

Skrypt o nazwie bootstrap_workshop.sh służy do konfigurowania 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 na wypadek, gdy prowadzisz szkolenie dla wielu użytkowników.

Skrypt warsztatów wczytywania wymaga tych danych wejściowych:

• Nazwa organizacji (np. yourcompany.com) – jest to organizacja, w której tworzysz środowiska dla warsztatów.
• Identyfikator płatności (np. 12345-12345-12345) – służy do rozliczania wszystkich zasobów używanych podczas warsztatów.
• Numer warsztatu (np. 01) – numer dwucyfrowy. Przydaje się to, gdy prowadzisz kilka warsztatów jednego dnia i chcesz śledzić je oddzielnie. Numery warsztatów są też wykorzystywane do uzyskania identyfikatorów projektów. Dzięki osobnym numerom warsztatów łatwiej Ci będzie uzyskać unikalne identyfikatory projektów za każdym razem. Oprócz numeru warsztatów w identyfikatorach projektów używana jest też bieżąca data (w formacie YYMMDD). Połączenie daty i numeru warsztatów zapewnia unikalne identyfikatory projektów.
• Numer użytkownika początkowego (np. 1) – oznacza pierwszego użytkownika na warsztatach. Jeśli np. chcesz utworzyć warsztaty dla 10 użytkowników, możesz mieć użytkownika początkowego o liczbie 1, a użytkownika końcowego – 10.
• Numer użytkownika (np. 10) – oznacza ostatniego użytkownika, który bierze udział w warsztatach. Jeśli np. chcesz utworzyć warsztaty dla 10 użytkowników, możesz mieć użytkownika początkowego o liczbie 1, a użytkownika końcowego – 10. Jeśli konfigurujesz jedno środowisko (na przykład u siebie), ustaw taki sam numer początkowy i numer użytkownika końcowego. Spowoduje to utworzenie jednego środowiska.

Oprócz daty i numeru warsztatów w identyfikatorach projektów zawarte są też numery użytkowników początkowych i końcowych. Identyfikatory użytkowników (w przypadku użytkowników wykonujących warsztat) pochodzą z numeru początkowego i końcowego. Objaśnienie identyfikatorów użytkowników znajdziesz w sekcji User schema and permissions performing the workshop.

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

Skrypt warsztatów wczytywania korzysta z wartości podanych powyżej 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 pojedynczego użytkownika.

Uprawnienia administratora wymagane do wczytywania warsztatu

Występują 2 typy użytkowników. ADMIN_USER, który tworzy i usuwa zasoby na potrzeby tych warsztatów. Druga to MY_USER, która wykonuje kroki opisane w warsztatach. MY_USER ma dostęp tylko do własnych zasobów. ADMIN_USER ma dostęp do wszystkich konfiguracji użytkownika. Jeśli tworzysz tę konfigurację samodzielnie, zasady ADMIN_USER i MY_USER są takie same. Jeśli jesteś nauczycielem i tworzysz te warsztaty dla kilku uczniów, ADMIN_USER i MY_USER będą się różnić.

ADMIN_USER wymaga tych uprawnień na poziomie organizacji:

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

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

Schemat i uprawnienia użytkownika wykonujące warsztaty

Jeśli planujesz utworzyć te warsztaty dla użytkowników w swojej organizacji (innych niż Ty), musisz przestrzegać określonego schematu nazewnictwa użytkowników w MY_USERs. W ramach skryptu wczytywaniastrap_workshop.sh podajesz adres początkowy i numer użytkownika końcowego. Numery te służą do tworzenia następujących nazw użytkowników:

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

Jeśli na przykład uruchomisz skrypt warsztatów wczytywania z numerem początkowym użytkownika 1 i użytkownikiem końcowym o wartości 3, w Twojej organizacji o nazwie twojafirma.com zostaną utworzone środowiska warsztatów dla następujących użytkowników:

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

Te nazwy użytkowników są przypisane rolami właściciela projektu w konkretnych projektach utworzonych przy użyciu skryptu setup_terraform_admin_project.sh. Podczas korzystania ze skryptu wczytywania musisz przestrzegać tego schematu nazewnictwa użytkowników. Zobacz, jak dodać kilka kont użytkowników naraz w G Suite.

Narzędzia wymagane na warsztatach

To warsztaty są wczytywane z Cloud Shell. Do realizacji tych warsztatów potrzebne są następujące narzędzia.

• gcloud (ver >= 270)
• kubectl
• sed (działa z sed w Cloud Shell/Linux, ale nie w Mac OS)
• git (sprawdź, czy masz aktualną wersję)
• sudo apt update
• sudo apt install git
• JQ
• środowisko
• kustomize

Wszystkie narzędzia oprócz 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. Sprawdź, czy w ścieżce PATH znajduje się plik binarny kustomize, a następnie potwierdź to, uruchamiając polecenie kustomize w Cloud Shell.

Samodzielne konfigurowanie warsztatów (konfiguracja dla pojedynczego użytkownika)

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

CLOUD SHELL

2. Sprawdź, czy w gcloud korzystasz z konta odpowiedniego administratora.

gcloud config list
 

3. Utwórz WORKDIR i skopiuj repozytorium warsztatowe.

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 warsztatów i zasobnik GCS administratora, którego chcesz używać na warsztatach. Sprawdź uprawnienia wymagane do skonfigurowania warsztatów 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 wczytywaniastrap_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 określać numeru początkowego i końcowego użytkownika, ponieważ robisz to samodzielnie.

Po zakończeniu wykonywania skryptu wczytywaniastrap_workshop.sh dla każdego użytkownika w organizacji tworzony jest folder GCP. W folderze tworzony jest projekt administracyjny Terraform. Projekt administratora Terraform służy do utworzenia pozostałych zasobów GCP wymaganych w tym warsztatach. Wymagane interfejsy API są włączone w projekcie administracyjnym Terraform. Do stosowania abonamentów Terraform możesz używać Cloud Build. Aby umożliwić tworzenie zasobów w GCP, musisz przypisać do konta usługi Cloud Build odpowiednie role uprawnień. Na koniec konfigurujesz zdalny backend w zasobniku Google Cloud Storage (GCS) do przechowywania stanów Terraform dla wszystkich zasobów GCP.

Aby wyświetlać zadania Cloud Build w projekcie administracyjnym Terraform, potrzebujesz identyfikatora projektu administratora Terraform. Znajdziesz je w pliku vars/vars.sh w katalogu asm. Ten katalog jest zachowywany tylko wtedy, gdy konfigurujesz warsztat samodzielnie jako administrator.

6. Źródło pliku zmiennych w celu ustawiania zmiennych środowiskowych

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

Konfigurowanie warsztatów dla wielu użytkowników (konfiguracja wielu użytkowników)

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

CLOUD SHELL

8. Sprawdź, czy w gcloud korzystasz z konta odpowiedniego administratora.

gcloud config list
 

9. Utwórz WORKDIR i skopiuj repozytorium warsztatowe.

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 warsztatów, numer początkowy i końcowy użytkownika oraz zasobnik GCS administratora, którego chcesz używać na warsztatach. Sprawdź uprawnienia wymagane do skonfigurowania warsztatów 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 wczytywaniastrap_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 administratora GCS, aby pobrać 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 modułu

Tutaj zaczynają się użytkownicy wykonujący warsztat. Wykonaj wszystkie czynności w oknie INCOGNITO w Chrome lub Firefoksie.

Wybierz ścieżkę modułu

Moduły dostępne w tych warsztatach można przeprowadzać na 2 sposoby:

• „Proste i interaktywne skrypty z łatwością” droga
• Opcja „Ręczne kopiowanie i wklejanie poszczególnych instrukcji” droga

Metoda ze skryptami z szybką ścieżką umożliwia uruchomienie pojedynczego interaktywnego skryptu w każdym module, który przeprowadzi Cię przez cały moduł, automatycznie uruchamiając jego polecenia. Polecenia są uruchamiane partiami ze zwięzłym wyjaśnieniem każdego kroku i wyjaśniania ich działania. Po każdej partii poleceń pojawi się prośba o przejście do następnej. Dzięki temu możesz przeprowadzać moduły we własnym tempie. Skrypty z szybką ścieżką są idempotentne, co oznacza, że można je uruchamiać wielokrotnie, by osiągnąć ten sam wynik.

Skrypty przyspieszonej ścieżki pojawią się u góry każdego modułu w zielonym polu, jak pokazano poniżej.

SZYBKIE ŚLEDZENIE SKRYPTU

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

Metoda kopiowania i wklejania to tradycyjny sposób kopiowania i wklejania poszczególnych bloków poleceń z objaśnieniami poleceń. Tę metodę należy uruchomić tylko raz. Nie ma gwarancji, że ponowne uruchomienie poleceń w tej metodzie przyniesie te same wyniki.

Podczas realizacji modułów wybierz jedną z dwóch metod.

Po wybraniu metody i wykonaniu w niej kroków nie wykonuj czynności w drugiej metodzie.

Konfiguracja skryptu z przyspieszoną ścieżką

Moduł przyspieszony zostanie ukończony po ukończeniu skryptu. Nie wykonuj czynności podanych w instrukcjach modułu kopiowania i wklejania.

Uzyskaj informacje o użytkowniku

Te warsztaty są wykonywane na tymczasowym koncie użytkownika (lub koncie modułu) utworzonym przez administratora warsztatu. Konto modułu jest właścicielem wszystkich projektów w warsztatach. Administrator warsztatów podaje dane logowania do konta modułu (nazwę użytkownika i hasło) użytkownikowi wykonującemu warsztat. Wszystkie projekty użytkownika są poprzedzone nazwą konta modułu. Na przykład w przypadku konta modułu [e-mail] identyfikator projektu administratora Terraform to user001-200131-01-tf-abcde itd. w przypadku pozostałych projektów. Każdy użytkownik musi zalogować się na konto podane przez administratora warsztatu i przeprowadzić warsztaty na tym koncie.

Sprawdź swój firmowy adres e-mail (ten sam, który został użyty do rejestracji na warsztaty). Administrator warsztatów powinien już do Ciebie dotrzeć e-maila z danymi logowania do konta modułu (tj. nazwą użytkownika i hasłem). E-mail wygląda tak.

1. Kliknij link poniżej, aby otworzyć Cloud Shell.

CLOUD SHELL

2. Zaloguj się przy użyciu danych logowania na konto modułu (nie loguj się na konto firmowe ani osobiste). Wygląd konta modułu to userXYZ@<workshop_domain>.com.
3. To jest nowe konto, dlatego musisz zaakceptować Warunki korzystania z usług Google. Kliknij Zaakceptuj.

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

W tym kroku udostępnimy małą maszynę wirtualną z systemem Linux Debian, której będziesz używać do uzyskiwania dostępu do zasobów GCP. Każde konto otrzymuje maszynę wirtualną Cloud Shell. Gdy zalogujesz się na konto modułu, zostanie udostępnione i zalogujesz się przy użyciu danych logowania do konta modułu. Oprócz Cloud Shell dostępny jest również edytor kodu, który ułatwia edytowanie plików konfiguracji (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 powłoki w prawym górnym rogu umożliwiają przełączanie się między nimi (edytorem powłoki i edytorem kodu). Możesz też przeciągnąć środkowy separator (w górę lub w dół) i ręcznie zmienić rozmiar każdego okna. 5. Utwórz zadanie PRACA dla tego warsztatu. Folder WORKDIR to folder, w którym wykonujesz wszystkie moduły tego warsztatu. Aby utworzyć zadanie WORKDIR, uruchom te polecenia w Cloud Shell.

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

6. Wyeksportuj użytkownika konta modułu jako zmienną do wykorzystania w tych warsztatach. Jest to to samo konto, na którym jesteś zalogowany 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 samodzielnie konfigurujesz warsztaty za pomocą nagłówka „-sufa” lub „–setup-for-admin” flagami, a następnie ustaw użytkownika MY_USER na adres e-mail konta GCP użytego do utworzenia projektów warsztatów.

7. Powtórz zmienne WORKDIR i MY_USER, aby mieć pewność, że obie są ustawione prawidłowo, uruchamiając następujące 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. Konfiguracja infrastruktury – przepływ pracy użytkownika

Cel: weryfikacja infrastruktury i instalacji Istio

• Instalacja narzędzi warsztatowych
• Klonowanie repozytorium do warsztatów
• Zweryfikuj instalację aplikacji Infrastructure
• Zweryfikuj instalację aplikacji k8s-repo
• Weryfikowanie instalacji Istio

SZYBKIE ŚLEDZENIE SKRYPTU

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

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

Po zakończeniu skryptu przejdź do źródła bashrc, aby zaktualizować zmienne w sesji Cloud Shell.

source ${HOME}/.bashrc

Instrukcje z Laboratorium: kopiowanie i wklejanie

WAŻNE: jeśli masz już ukończony skrypt szybkiego przejścia tego modułu, nie wykonuj tej metody kopiowania i wklejania**.**

Uzyskaj informacje o użytkowniku

Administrator konfigurujący warsztaty musi podać użytkownikowi nazwę użytkownika i hasło. Wszystkie projekty użytkownika będą poprzedzone nazwą użytkownika (np. [e-mail]), identyfikatorem projektu administratora Terraform będzie on user001-200131-01-tf-abcde itd. w przypadku pozostałych projektów. Każdy użytkownik ma dostęp tylko do własnego środowiska warsztatów.

Narzędzia wymagane na warsztatach

To warsztaty są wczytywane z Cloud Shell. Do realizacji tych warsztatów potrzebne są następujące narzędzia.

Wszystkie narzędzia oprócz kustomize i pv są już domyślnie zainstalowane w Cloud Shell. Poniżej znajdziesz instrukcje instalacji obu tych narzędzi.

• gcloud (ver >= 270)
• kubectl
• sed (działa z sed w Cloud Shell/Linux, ale nie w Mac OS)
• git (sprawdź, czy masz aktualną wersję)
• sudo apt update
• sudo apt install git
• JQ
• środowisko
• kustomize
• pv

Dostęp do projektu administracyjnego Terraform

Po zakończeniu wykonywania skryptu wczytywaniastrap_workshop.sh dla każdego użytkownika w organizacji tworzony jest folder GCP. W folderze tworzony jest projekt administracyjny Terraform. Projekt administratora Terraform służy do utworzenia pozostałych zasobów GCP wymaganych w tym warsztatach. Skrypt setup-terraform-admin-project.sh włącza wymagane interfejsy API w projekcie administracyjnym Terraform. Do stosowania abonamentów Terraform służy Cloud Build. Za pomocą tego skryptu nadajesz kontu usługi Cloud Build odpowiednie role uprawnień, które umożliwiają mu tworzenie zasobów w GCP. I wreszcie w zasobniku Google Cloud Storage (GCS) konfigurowany jest zdalny backend, który zapisuje stany Terraform dla wszystkich zasobów GCP.

Aby wyświetlać zadania Cloud Build w projekcie administracyjnym Terraform, potrzebujesz identyfikatora projektu administratora Terraform. Są one przechowywane w administracyjnym zasobniku GCS określonym w skrypcie wczytywania. Jeśli uruchomisz skrypt wczytywania dla wielu użytkowników, wszystkie identyfikatory projektów administratora Terraform znajdziesz w zasobniku GCS.

Zadanie zostanie przeprowadzone w Cloud Shell i Cloud Console. Wykonaj poniższe czynności w oknie INCOGNITO, ponieważ będziesz logować się przy użyciu oddzielnej nazwy użytkownika i hasła.

1. Kliknij poniższy link, aby otworzyć Cloud Shell (jeśli nie jest jeszcze otwarta w sekcji Konfiguracja i przygotowanie modułu).

CLOUD SHELL

2. Zainstaluj kustomize (jeśli nie jest jeszcze zainstalowana) 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 bash.

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 korzystasz z odpowiedniego konta 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. Uzyskaj identyfikator projektu administratora Terraform, uruchamiając 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 przechowywanym 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 dla projektu administracyjnego Terraform i sprawdzić, 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 korzystasz z Cloud Console po raz pierwszy, zaakceptuj Warunki korzystania z usług Google.

9. Po otwarciu strony Cloud Build kliknij link History w panelu nawigacyjnym po lewej stronie, a następnie kliknij najnowszą kompilację, aby wyświetlić szczegóły początkowego zastosowania Terraform. Poniższe zasoby są tworzone w ramach skryptu Terraform. Możesz też skorzystać z powyższego schematu architektury.

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

Skrypt Terraform trwa 40–50 minut.

10. Po zakończeniu kompilacji w projekcie terraform admin project uruchomi się kolejna kompilacja w projekcie operacji. Kliknij wyświetlony link, aby otworzyć stronę Cloud Build dla instancji ops project i sprawdzić, czy kompilacja Cloud Build k8s-repo zakończyła się powodzeniem.

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

Uwaga: ta kompilacja należy przeprowadzić, zanim będzie można zweryfikować instalację Istio.

Zweryfikuj instalację

11. Utwórz pliki kubeconfig dla wszystkich klastrów. Uruchom następujący 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 tak, aby wskazywała nowy plik kubeconfig.

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

13. Dodaj zmienną vars.sh i KUBECONFIG do pliku .bashrc w Cloud Shell, aby pobierać z niego źródła 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 w obu klastrach zainstalowano Istio. W tym celu sprawdź, czy wszystkie pody są uruchomione, a zadania zostały ukończone.

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. Sprawdź, czy w dev1 klastrze zainstalowano Istio. W klastrach dev1 działają tylko cytadela, wstrzykiwacz pomocniczy i kodery rdzeni. Współużytkują 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. Sprawdź, czy w dev2 klastrze zainstalowano Istio. W klastrach dev2 działają tylko cytadela, wstrzykiwacz pomocniczy i kodery rdzeni. Współużytkują one 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

Sprawdzanie wykrywania usług dla współdzielonych platform sterujących

18. Możesz też sprawdzić, 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 tym warsztatach używasz jednego współdzielonego środowiska VPC, w którym tworzone są 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 operacji. Program pilotażowy używa tych obiektów tajnych do wykrywania usług przez wysyłanie zapytań do serwera Kube API klastrów aplikacji (uwierzytelnionych za pomocą powyższych obiektów tajnych). Widzisz, że oba klastry operacyjne mogą uwierzytelniać się we wszystkich klastrach aplikacji przy użyciu obiektów tajnych utworzonych przez kubeconfig. Klastry operacyjne mogą automatycznie wykrywać usługi, korzystając z plików kubeconfig jako metody obiektu tajnego. Wymaga to, aby wdrożenie pilotażowe w klastrach operacyjnych miało dostęp do serwera Kube API wszystkich innych klastrów. Jeśli program pilotażowy nie może połączyć się z serwerami Kube API, musisz ręcznie dodać usługi zdalne jako ServiceEntries. Możesz je traktować jako wpisy DNS w rejestrze usług. Wpisy usług definiują usługę przy użyciu w pełni kwalifikowanej nazwy DNS ( FQDN) i adresu IP, pod którym jest ona dostępna. Więcej informacji znajdziesz w dokumentacji Istio Multicluster.

6. Opis repozytorium infrastruktury

Kompilacja Cloud Build

Zasoby GCP na potrzeby warsztatów są tworzone przy użyciu Cloud Build i repozytorium CSR infrastructure. Właśnie uruchomiono skrypt wczytywania (znajdujący się pod adresem scripts/bootstrap_workshop.sh) z lokalnego terminala. Skrypt wczytywania tworzy folder GCP, projekt administracyjny Terraform i odpowiednie uprawnienia dla konta usługi Cloud Build. Projekt administratora Terraform służy do przechowywania stanów Terraform, logów i różnych skryptów. Zawiera on repozytorium infrastructure i k8s_repo. Szczegółowy opis tych repozytoriów znajdziesz w następnej sekcji. W projekcie administracyjnym Terraform nie są tworzone żadne inne zasoby warsztatów. Konto usługi Cloud Build w projekcie administracyjnym Terraform jest używane do kompilowania zasobów na potrzeby warsztatów.

Plik cloudbuild.yaml znajdujący się w folderze infrastructure jest używany do tworzenia zasobów GCP na potrzeby warsztatu. Tworzy on niestandardowy obraz kreatora ze wszystkimi narzędziami wymaganymi do tworzenia zasobów GCP. Do narzędzi tych należą gcloud SDK, terraform i inne narzędzia, takie jak python, git czy jq. Niestandardowy obraz kreatora uruchamia terraform plan i apply w przypadku każdego zasobu. Pliki Terraform dla każdego zasobu znajdują się w osobnych folderach (szczegóły znajdziesz w następnej sekcji). Zasoby są tworzone pojedynczo i w takiej kolejności, w jakiej są zwykle tworzone (np. projekt GCP zostaje utworzony przed złożeniem zasobów w nim). Więcej informacji znajdziesz w pliku cloudbuild.yaml.

Usługa Cloud Build jest aktywowana za każdym razem, gdy w repozytorium infrastructure pojawi się zatwierdzenie. Wszystkie zmiany wprowadzane w infrastrukturze są przechowywane jako infrastruktura jako kod (IaC) i zatwierdzone w repozytorium. Stan Twoich warsztatów jest zawsze przechowywany w tym repozytorium.

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

Repozytorium infrastruktury konfiguruje zasoby infrastruktury GCP na potrzeby warsztatów. Składa się on z folderów i podfolderów. Foldery podstawowe w repozytorium reprezentują elementy team, do których należą określone zasoby GCP. Kolejna warstwa folderów odpowiada konkretnemu obiektowi environment zespołu (np. „dev”, „Etap”, „prod”). Kolejna warstwa folderów w środowisku reprezentuje konkretny element resource (na przykład projekt główny, klaster_gke itp.). Wymagane skrypty i pliki Terraform znajdują się w folderach zasobów.

Podczas warsztatów przedstawione są 4 typy zespołów:

1. infrastructure – reprezentuje zespół ds. infrastruktury w chmurze. Odpowiada za tworzenie zasobów GCP dla wszystkich pozostałych zespołów. Na potrzeby swoich zasobów używają projektu administratora Terraform. Samo repozytorium infrastruktury znajduje się w projekcie administracyjnym Terraform, a także w plikach stanu Terraform (objaśnionych poniżej). Te zasoby są tworzone przez skrypt bash podczas procesu wczytywania (szczegóły znajdziesz w module 0 – Przepływ pracy administratora).
2. network – reprezentuje zespół ds. sieci. Odpowiada za zasoby VPC i sieciowe. Właścicielami poniższych 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ół operacyjny/devops. Właścicielami poniższych zasobów są:
6. ops project – reprezentuje projekt dla wszystkich zasobów operacji.
7. gke clusters – klaster GKE operacyjny na region. Platforma sterująca Istio jest zainstalowana w każdym z klastrów GKE, w którym działa.
8. k8s-repo – repozytorium CSR zawierające pliki manifestu GKE dla wszystkich klastrów GKE.
9. apps – reprezentuje zespoły zajmujące się aplikacjami. W tych warsztatach symulują 2 zespoły: app1 i app2. Właścicielami poniższych zasobów są:
10. app projects – każdy zespół zajmujący się aplikacją otrzymuje własny zestaw projektów. Dzięki temu mogą kontrolować płatności i uprawnienia w określonym projekcie.
11. gke clusters – są to klastry aplikacji, w których działają kontenery/pody aplikacji.
12. gce instances – opcjonalnie, jeśli ich aplikacje działają w instancjach GCE. W tym warsztatie aplikacja app1 ma kilka instancji GCE, w których działa część aplikacji.

W tym ćwiczeniu ta sama aplikacja (aplikacja sklepowa) reprezentuje zarówno aplikację1, jak i app2.

Dostawca, stany i dane wyjściowe – backendy i stany współdzielone

Dostawcy google i google-beta znajdują się pod adresem gcp/[environment]/gcp/provider.tf. Plik provider.tf jest połączony symbolem w każdym folderze zasobów. Dzięki temu możesz zmienić dostawcę w jednym miejscu zamiast zarządzać poszczególnymi dostawcami dla każdego zasobu.

Każdy zasób zawiera plik backend.tf, który określa lokalizację pliku tfstate zasobu. Ten plik backend.tf został wygenerowany na podstawie szablonu (znajdującego się pod adresem templates/backend.tf_tmpl) przy użyciu skryptu (znajdującego się pod adresem scripts/setup_terraform_admin_project), a następnie umieszczony w odpowiednim folderze zasobów. Zasobniki Google Cloud Storage (GCS) są używane na potrzeby backendów. Nazwa folderu zasobnika GCS jest zgodna z nazwą zasobu. Wszystkie backendy zasobów znajdują się w projekcie administracyjnym Terraform.

Zasoby z wartościami współzależnymi zawierają plik output.tf. Wymagane wartości wyjściowe są przechowywane w pliku tfstate zdefiniowanym w backendzie dla danego konkretnego zasobu. Aby na przykład utworzyć w projekcie klaster GKE, musisz znać jego identyfikator. Identyfikator projektu jest zwracany w 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 źródło danych terraform_remote_state wskazujące plik tfstate zasobu. W folderach zasobów istnieją pliki shared_state_[resource_name].tf, które wymagają 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 VPC. Pliki shared_state są generowane na podstawie szablonu (znajdującego się pod adresem templates/shared_state.tf_tmpl) za pomocą skryptu (znajdującego się pod adresem scripts/setup_terraform_admin_project). Wiersze ze wszystkimi zasobami pliki shared_state są umieszczane w folderze gcp/[environment]/shared_states. Wymagane pliki shared_state są połączone symbolami w odpowiednich folderach zasobów. Umieszczenie wszystkich plików shared_state w jednym folderze i symbolizacja powiązania między nimi 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, który znajduje się w zasobniku GCS w projekcie administracyjnym Terraform. Zawiera on identyfikator organizacji, konto rozliczeniowe, identyfikatory projektów, szczegóły klastra GKE itp. Aby pobrać wartości do konfiguracji, możesz pobrać vars.sh i pobrać źródło z dowolnego terminala.

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 znajdującego się w tym samym folderze za pomocą skryptu (znajdującego się pod adresem scripts/setup_terraform_admin_project).

Omówienie repozytorium K8s

k8s_repo to repozytorium CSR (niezależne 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. Projekt k8s_repo jest tworzony przez infrastrukturę Cloud Build (szczegóły znajdziesz w poprzedniej sekcji). Podczas początkowego procesu Cloud Build infrastruktura tworzonych jest łącznie 6 klastrów GKE. W usłudze k8s_repo zostanie utworzonych 6 folderów. Każdy folder (nazwa pasująca do nazwy klastra GKE) odpowiada klastrowi GKE zawierającemu odpowiednie pliki manifestu zasobów. Podobnie jak w przypadku infrastruktury, usługa Cloud Build służy do stosowania plików manifestu Kubernetes do wszystkich klastrów GKE korzystających z repozytorium k8s_repo. Usługa Cloud Build jest aktywowana za każdym razem, gdy w repozytorium k8s_repo pojawi się zatwierdzenie. Podobnie jak w przypadku infrastruktury, wszystkie pliki manifestu 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 kompilacji infrastruktury tworzony jest interfejs k8s_repo, a we wszystkich klastrach instalowany jest Istio.

Projekty, klastry GKE i przestrzenie nazw

Zasoby dostępne w tych warsztatach są podzielone na różne projekty GCP. Projekty powinny być zgodne ze strukturą organizacyjną (lub zespołem) Twojej firmy. Zespoły (w Twojej organizacji) odpowiedzialne za różne projekty, usługi i zasoby korzystają z różnych projektów GCP. Posiadanie osobnych projektów umożliwia tworzenie osobnych zbiorów uprawnień i zarządzanie płatnościami na poziomie projektu. Dodatkowo limity są zarządzane na poziomie projektu.

W warsztatach reprezentuje pięć zespołów, z których każdy ma własny projekt.

1. Zespół ds. infrastruktury, który tworzy zasoby GCP, korzysta z interfejsu Terraform admin project. Zarządza infrastrukturą jako kodem w repozytorium CSR (infrastructure) i przechowuje 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 stanu Terraform.
2. Zespół ds. sieci, który tworzy współdzielone środowisko VPC, używa host project. Ten projekt zawiera VPC, podsieci, trasy i reguły zapory sieciowej. Udostępnianie współdzielonego środowiska VPC umożliwia centralne zarządzanie siecią zasobów GCP. Wszystkie projekty używały tego jednego współdzielonego środowiska VPC na potrzeby sieci.
3. Zespół operacyjny/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. Odpowiada za wzmacnianie klastrów oraz zarządzanie odpornością i skalą platformy Kubernetes. W tym warsztatach użyjesz metody gitops, która pozwoli Ci wdrażać zasoby w Kubernetes. W projekcie operacyjnym istnieje repozytorium CSR (k8s_repo).
4. I wreszcie zespoły dev1 i dev2 (to 2 zespoły programistyczne), które tworzą 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, którą zarządza zespół operacyjny. Zasoby (wdrożenia, usługi itp.) są przekazywane do k8s_repo i wdrażane w odpowiednich klastrach. Warto zauważyć, że to warsztaty nie skupiają się na sprawdzonych metodach ani narzędziach CI/CD. Za pomocą Cloud Build możesz automatyzować wdrażanie zasobów Kubernetes bezpośrednio w klastrach GKE. W rzeczywistych scenariuszach produkcyjnych należy użyć odpowiedniego rozwiązania CI/CD do wdrażania aplikacji w klastrach GKE.

W tym warsztatie dostępne są 2 typy 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 do zarządzania siatką usług.
2. Klastry aplikacji – używane przez zespoły programistów do uruchamiania aplikacji. W tym ćwiczeniu wykorzystamy aplikację Hipster – sklep.

Oddzielenie narzędzi Ops/admin od klastrów, w których działa aplikacja, umożliwia niezależne zarządzanie cyklem życia każdego zasobu. Te 2 typy klastrów istnieją też w różnych projektach odnoszących się do zespołu lub usługi, która z nich korzysta, co ułatwia zarządzanie uprawnieniami.

Łącznie jest 6 klastrów GKE. W projekcie operacji tworzone są 2 regionalne klastry operacji. Platforma sterująca ASM/Istio jest zainstalowana w obu klastrach operacji. Każdy klaster operacji znajduje się w innym regionie. Dodatkowo istnieją 4 strefowe klastry aplikacji. Tworzone są w osobnych projektach. W tych warsztatach symulują 2 zespoły programistów, z których każdy ma własne projekty. Każdy projekt zawiera 2 klastry aplikacji. Klastry aplikacji to klastry strefowe znajdujące się w różnych strefach. Te 4 klastry aplikacji znajdują się w 2 regionach i 4 strefach. W ten sposób uzyskasz nadmiarowość regionalną i strefową.

Aplikacja użyta w tych warsztatach, aplikacja Hipster Shop, jest wdrożona we wszystkich 4 klastrach aplikacji. Każdy mikroserwis znajduje się we własnej przestrzeni nazw w każdym klastrze aplikacji. Wdrożenia aplikacji Hipster Shop (pody) nie są wdrażane w klastrach operacji. W klastrach operacyjnych są jednak tworzone przestrzenie nazw i zasoby usługi dla wszystkich mikroserwisów. Platforma sterująca ASM/Istio używa rejestrów usług Kubernetes do wykrywania usług. W przypadku braku usług (w klastrach operacji) konieczne było ręczne utworzenie wpisów usług dla każdej usługi uruchomionej w klastrze aplikacji.

W ramach tego warsztatu wdrożysz 10-poziomową aplikację z mikroserwisami. Jest to internetowa aplikacja e-commerce o nazwie „ Hipster Shop” na której użytkownicy mogą przeglądać produkty, dodawać je do koszyka i je kupować.

Pliki manifestu Kubernetes i repozytorium k8s_repo

k8s_repo umożliwia dodawanie zasobów Kubernetes do wszystkich klastrów GKE. W tym celu skopiuj pliki manifestu Kubernetes i zobowiązuj się do zadania k8s_repo. Wszystkie zatwierdzenia instancji k8s_repo aktywują zadanie Cloud Build, które wdraża pliki manifestu Kubernetes w odpowiednim klastrze. Plik manifestu każdego klastra znajduje się w osobnym folderze o nazwie takiej samej jak nazwa klastra.

Sześć nazw klastrów to:

1. gke-asm-1-r1-prod – regionalny klaster operacji w regionie 1
2. gke-asm-2-r2-prod – regionalny klaster operacji w regionie 2
3. gke-1-apps-r1a-prod – klaster aplikacji w regionie 1 strefy a
4. gke-2-apps-r1b-prod – klaster aplikacji w regionie 1 strefy b
5. gke-3-apps-r2a-prod – klaster aplikacji w regionie 2 strefy a
6. gke-4-apps-r2b-prod – klaster aplikacji w regionie 2 strefy b

W folderze k8s_repo znajdują się foldery odpowiadające tym klastrom. Każdy plik manifestu umieszczony w tych folderach zostanie zastosowany do odpowiedniego klastra GKE. Pliki manifestu dla 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
• Skopiuj pliki manifestu Hipster Shop do wszystkich klastrów aplikacji
• Twórz aplikacje usług dla Hipsterów w klastrach operacyjnych
• Skonfiguruj loadgenerators w klastrach operacyjnych, aby przetestować połączenia globalne
• Zweryfikuj bezpieczne połączenie z aplikacją Hipster Shop

SZYBKIE ŚLEDZENIE SKRYPTU

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

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

Instrukcje z Laboratorium: kopiowanie i wklejanie

Jeśli masz już ukończony scenariusz szybkiego przejścia tego modułu, nie wykonuj metody kopiowania i wklejania widocznej poniżej**.**

Klonowanie repozytorium źródłowego projektu operacyjnego

W ramach początkowej kompilacji infrastruktury Terraform obiekt k8s-repo został już utworzony w projekcie operacji.

1. Utwórz pusty katalog dla repozytorium Git:

mkdir $WORKDIR/k8s-repo
 

2. Uruchom repozytorium git, dodaj zdalne i pobierz wzorzec ze zdalnego repozytorium:

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

Kopiuj pliki manifestu, zatwierdzanie i przekazywanie

4. Skopiuj usługi i przestrzenie nazw Hipster Shop do repozytorium źródłowego 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 zasoby Hipster Shop Deployments, RBAC i PodSecurityPolicy do repozytorium źródłowego 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 usługi koszyka, rbac i podsecuritypolicy ze wszystkich klastrów programistycznych oprócz jednego. Usługa Hipstershop nie została stworzona z myślą o wdrażaniu wieloklastrowym, dlatego aby uniknąć niespójnych wyników, używamy tylko jednej usługi koszyka.

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 usługi koszyka, rbac i podsecuritypolicy do pliku kustomization.yaml tylko w pierwszym klastrze programisty.

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ń podsecuritypolicies, wdrożenia i katalogi Rbac z klastrów operacji 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 pliki manifestu IngressGateway i VirtualService do repozytorium źródłowego klastrów operacji.

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 1 klastra 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 identyfikator PROJECT_ID w plikach manifestu 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 pliki manifestu loadgenerator (Deployment, PodSecurityPolicy i RBAC) do klastrów operacji. Aplikacja sklepowa Hipster jest udostępniana przy użyciu globalnego systemu równoważenia obciążenia Google Cloud (GCLB). GCLB odbiera ruch klienta (kierowany do frontend) i wysyła go do najbliższej instancji usługi. Ustawienie loadgenerator w obu klastrach operacji sprawi, że ruch będzie kierowany do obu bram ruchu przychodzącego Istio działających w klastrach operacji. Równoważenie obciążenia zostało szczegółowo wyjaśnione 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 operacyjnego w plikach manifestu loadgenerator w obu klastrach 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 operacji.

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. Zatwierdź: 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. Wyświetl stan projektu operacyjnego Cloud Build na wcześniej otwartej karcie lub kliknij 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 (oprócz koszyka) są uruchomione we wszystkich klastrach programistycznych.

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ą uruchomione tylko w pierwszym klastrze programistycznym.

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

Otwórz aplikację Hipster Shop

Globalne równoważenie obciążenia

Aplikacja Hipster Shop jest teraz wdrożona we wszystkich 4 klastrach aplikacji. Klastry te znajdują się w 2 regionach i 4 strefach. Klienci mogą uzyskać dostęp do aplikacji Hipster, używając usługi frontend. Usługa frontend działa we wszystkich 4 klastrach aplikacji. System równoważenia obciążenia Google Cloud ( GCLB) jest używany do pobierania ruchu klienta do wszystkich 4 instancji usługi frontend.

Bramy ruchu przychodzącego Istio działają tylko w klastrach operacyjnych i działają jako regionalny system równoważenia obciążenia dla 2 strefowych klastrów aplikacji w regionie. GCLB używa 2 bram ruchu przychodzącego Istio (działających w 2 klastrach operacji) jako backendów w globalnej usłudze frontendu. Bramy Istio Ingress odbierają ruch klienta z GCLB, a następnie wysyłają ruch klienta do podów frontendu działających w klastrach aplikacji.

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

Kontroler Autoneg GKE

Usługa Kubernetes bramy Istio Ingress rejestruje się jako backend w GCLB przy użyciu grup punktów końcowych sieci. Grupy punktów końcowych sieci umożliwiają natywne równoważenie obciążenia w kontenerze za pomocą systemów równoważenia obciążenia GCLB. Grupy punktów końcowych sieci są tworzone za pomocą specjalnej adnotacji w usłudze Kubernetes, dzięki czemu mogą się zarejestrować w kontrolerze grup punktów końcowych sieci. Kontroler Autoneg to specjalny kontroler GKE, który automatyzuje tworzenie grup punktów końcowych sieci, a także przypisuje je jako backendy do GCLB za pomocą adnotacji dotyczących usługi. Platformy sterujące Istio, w tym bramy ruchu przychodzącego Istio, są wdrażane podczas początkowej infrastruktury Terraform Cloud Build. Konfiguracja GCLB i Autoneg odbywa się w ramach początkowej 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 GCLB frontend. GCLB używa certyfikatów zarządzanych na potrzeby globalnej usługi frontend, a certyfikat jest zamykany przez GCLB. W tych warsztatach użyjesz Cloud Endpoints – domeny zarządzanego certyfikatu. Możesz też użyć domeny i nazwy DNS dla: frontend, aby utworzyć certyfikaty zarządzane GCP.

21. Aby otworzyć sklep Hipster, kliknij link w poniższym poleceniu.

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

22. Ważność certyfikatu możesz sprawdzić, klikając symbol kłódki na pasku adresu URL na karcie Chrome.

Zweryfikuj globalne równoważenie obciążenia

W ramach wdrażania aplikacji generatory obciążenia zostały wdrożone w obu klastrach operacyjnych, które generują ruch testowy do linku Cloud Endpoints GCLB Hipster. Sprawdź, czy GCLB odbiera i wysyła ruch do obu bram ruchu przychodzącego Istio.

23. Pobierz GCLB > Link do monitorowania projektu operacyjnego, w którym tworzony jest 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 backendu zmień opcję Wszystkie backendy na istio-ingressgateway, jak pokazano poniżej.

25. Zwróć uwagę na ruch na drodze istio-ingressgateways.

W ramach każdego istio-ingressgateway są tworzone 3 grupy punktów końcowych sieci. Klastry operacji są klastrami regionalnymi, dlatego dla każdej strefy w regionie tworzona jest 1 grupa punktów końcowych sieci. Jednak pody istio-ingressgateway działają w 1 strefie na region. Widoczny jest ruch do istio-ingressgateway podów.

W obu klastrach operacji działają generatory obciążenia symulujące 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 generowane w regionie 2 klastra operacyjnego jest wysyłane do istio-ingressgateway w regionie 2.

8. Dostrzegalność w usłudze Stackdriver

Cel: połączenie danych telemetrycznych Istio z usługą Stackdriver i jej sprawdzenie.

• Zainstaluj zasoby (istio-telemetry)
• Tworzenie/aktualizowanie paneli usług Istio
• Wyświetl logi kontenerów
• Wyświetl rozproszone śledzenie w usłudze Stackdriver

SZYBKIE ŚLEDZENIE SKRYPTU

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

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

Instrukcje z Laboratorium: kopiowanie i wklejanie

Jeśli masz już ukończony scenariusz szybkiego przejścia tego modułu, nie wykonuj metody kopiowania i wklejania widocznej poniżej**.**

Jedną z głównych cech oferty Istio jest wbudowana dostrzegalność („o11y”). Oznacza to, że nawet w przypadku standardowych kontenerów, operatorzy mogą obserwować ruch napływający do tych kontenerów i wychodzący z nich, oferując usługi klientom. Ta obserwacja wykorzystuje kilka różnych metod: wskaźniki, logi i logi czasu.

Skorzystamy również z wbudowanego systemu generowania obciążenia dostępnego w sklepie Hipster Shop. Dostrzegalność nie działa zbyt dobrze w systemie statycznym bez ruchu, więc generowanie obciążenia pomaga nam sprawdzić, jak to działa. To wczytywanie jest już uruchomione, więc teraz możemy je tylko zobaczyć.

1. Zainstaluj istio w pliku konfiguracji usługi 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ź repozytorium k8s.

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

3. Wyświetl stan projektu operacyjnego Cloud Build na wcześniej otwartej karcie lub kliknij ten link:

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

4. Sprawdź konfigurację Istio → integracja z usługą Stackdriver Pobierz plik CRD Stackdriver Handler.

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

W danych wyjściowych powinien pojawić się moduł obsługi o nazwie „stackdriver”:

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

5. Sprawdź, czy eksport wskaźników Istio do usługi Stackdriver działa. Kliknij dane wyjściowe linku po kliknięciu tego polecenia:

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

Pojawi się prośba o utworzenie nowego obszaru roboczego o nazwie odpowiadającej nazwie projektu operacyjnego. Wybierz OK. Jeśli pojawi się prośba o pokazanie nowego interfejsu, po prostu zamknij to okno.

W narzędziu Metrics Explorer w sekcji „Znajdź typ zasobu i wskaźnik” wpisz „istio” są dostępne opcje takie jak „Server Request Count” (Liczba żądań serwera) w „kontenerze Kubernetes” typu zasobu. Pokazuje to, że dane są przesyłane z siatki do usługi Stackdriver.

(Aby zobaczyć wiersze poniżej, musisz użyć etykiety Pogrupuj według destination_service_name).

Wizualizacja danych za pomocą paneli:

Nasze wskaźniki są już w systemie Stackdriver APM, chcemy więc mieć możliwość ich wizualizacji. W tej sekcji zainstalujemy gotowy pulpit nawigacyjny, który pokazuje trzy z czterech Złote sygnały danych: Ruch (żądania na sekundę), Czas oczekiwania (w tym przypadku 99 i 50 percentyl) oraz Błędy (w tym przykładzie wykluczymy Nasycenie).

Serwer proxy Envoy w Istio dostarcza nam kilka danych, ale są to dobry zestaw, od którego warto zacząć. (pełną listę znajdziesz tutaj). Pamiętaj, że każdy wskaźnik ma zestaw etykiet, których można używać do filtrowania i agregacji, np.: usługa_docelowa, przestrzeń_nazw_zadań_źródłowy, kod_odpowiedzi, istio_tcp_received_bytes_total itp.

6. Teraz dodajmy panel gotowych danych. Będziemy korzystać bezpośrednio z interfejsu Dashboard API. To coś, co zazwyczaj nie robi się przez ręczne generowanie wywołań interfejsu API, jest to część systemu automatyzacji lub panel można utworzyć ręcznie 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. Aby wyświetlić nowo dodany „Panel usług”, kliknij link z danymi wyjściowymi poniżej.

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

Można edytować panel w miejscu, korzystając z UX, ale w naszym przypadku szybko dodamy nowy wykres za pomocą interfejsu API. Aby to zrobić, pobierz najnowszą wersję panelu, zastosuj zmiany, a następnie wypchnij ją z powrotem przy użyciu metody HTTP PATCH.

8. Możesz uzyskać istniejący panel, wysyłając zapytanie do interfejsu API monitorowania. 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. Dodaj nowy wykres (50 centyl czasu oczekiwania): [ Dokumentacja API] Teraz możemy dodać w kodzie do panelu nowy widżet z wykresem. Ta zmiana może zostać sprawdzona przez aplikacje równorzędne i zameldowana w kontroli wersji. Oto widżet do dodania, który pokazuje 50. centyl czasu oczekiwania (mediany czasu oczekiwania).

Spróbuj edytować wyświetlany panel, dodając nową strofę:

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 dotychczasowy 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. Aby wyświetlić zaktualizowany panel, kliknij ten link:

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

12. Wykonaj prostą analizę logów.

Istio udostępnia zestaw uporządkowanych logów dla całego ruchu sieciowego w sieci i przesyła je do Stackdriver Logging, aby umożliwić analizę między klastrami w ramach jednego, zaawansowanego narzędzia. Logi są oznaczone metadanymi poziomu usługi, takimi jak klaster, kontener, aplikacja czy identyfikator połączenia.

Przykładowy wpis logu (w tym przypadku log dostępu serwera proxy Envoy) może wyglądać tak (przycięty):

*** 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" 
...  
 }

Swoje logi możesz wyświetlić tutaj:

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 oraz wyszukiwanie w narzędziu „pilot” –

Widać tutaj, że platforma sterująca Istio przekazuje konfigurację serwera proxy na pomocnicze serwery proxy dla każdej przykładowej usługi aplikacji. "CDS", „LDS”, i „RDS” reprezentować różne interfejsy API Envoy ( więcej informacji).

Oprócz logów Istio w jednym interfejsie możesz też znaleźć logi kontenerów, a także logi infrastruktury lub innych usług GCP. Oto kilka przykładowych zapytań dotyczących logów GKE. Przeglądarka logów umożliwia też tworzenie wskaźników na podstawie logów (np. „liczenie każdego błędu pasującego do jakiegoś ciągu”), którego można używać w panelu lub w ramach alertu. Dzienniki mogą być też strumieniowane do innych narzędzi analitycznych, takich jak BigQuery.

Przykładowe filtry do sklepu hipsterów:

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

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

13. Sprawdź rozproszone logi czasu.

Teraz gdy pracujesz z systemem rozproszonym, debugowanie wymaga nowego narzędzia: Distributed tracking (Śledzenie rozproszone). To narzędzie umożliwia odkrywanie statystyk dotyczących interakcji między usługami (np. wykrywanie odległych powolnych zdarzeń na ilustracji poniżej), a także analizowanie nieprzetworzonych przykładowych zrzutów ekranu w celu zbadania szczegółów, co tak naprawdę się dzieje.

Widok Oś czasu przedstawia wszystkie żądania w czasie, przedstawione na wykresie według czasu oczekiwania lub czasu, jaki upłynął między pierwszym żądaniem, z poziomu stosu Hipstera, aby ostatecznie odpowiedzieć użytkownikowi. Im większa liczba kropek, tym wolniejsze (i mniej zadowolone!) wrażenia użytkownika.

Możesz kliknąć kropkę, aby wyświetlić szczegółowy widok kaskadowy danego żądania. Umiejętność znalezienia nieprzetworzonych szczegółów konkretnego żądania (a nie tylko zbiorczych statystyk) jest niezbędna do zrozumienia interakcji między usługami, zwłaszcza w przypadku poszukiwania rzadkich, ale nieskutecznych interakcji między usługami.

Widok kaskadowy powinien być dobrze znany każdemu, kto korzysta z debugera, ale w tym przypadku zamiast pokazywać czas spędzony w różnych procesach dla jednej aplikacji, pokazuje on czas spędzony na przemierzaniu naszej siatki, między usługami, w osobnych kontenerach.

Tutaj znajdziesz swoje logi czasu:

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 (AuthN).

• Włącz mTLS dla całej sieci typu mesh
• Zweryfikuj mTLS, sprawdzając logi

SZYBKIE ŚLEDZENIE SKRYPTU

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

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

Instrukcje z Laboratorium: kopiowanie i wklejanie

Jeśli masz już ukończony scenariusz szybkiego przejścia tego modułu, nie wykonuj metody kopiowania i wklejania widocznej poniżej**.**

Po zainstalowaniu naszych aplikacji i skonfigurowaniu dostrzegalności możemy zacząć zabezpieczać połączenia między usługami i zapewnić, że będą nadal działać.

Na przykład na panelu Kiali możemy zobaczyć, że nasze usługi nie korzystają z MTLS (ikona „kłódki”). Jednak ruch jest płynny, a system działa normalnie. Panel StackDriver Golden Metrics daje nam spokój ducha, dzięki czemu wszystko działa.

1. Sprawdź MeshPolicy w klastrach operacji. Pamiętaj, że mTLS to PERMISSIVE zezwala zarówno na ruch zaszyfrowany, jak i inny niż 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 konfigurowane we wszystkich klastrach przy użyciu operatora Istio, który używa niestandardowego zasobu IstioControlPlane (CR). Skonfigurujemy mTLS we wszystkich klastrach, aktualizując szablon CR IstioControlPlane i repozytorium k8s. Ustawienie globalne > mTLS > włączono: wartość true w szablonie odpowiedzi IstioControlPlane powoduje następujące 2 zmiany na platformie sterującej Istio:

• Zasada MeshPolicy włącza sieć typu mesh mTLS dla wszystkich usług działających we wszystkich klastrach.
• Utworzono regułę docelową, która zezwala na ruch ISTIO_MUTUAL między usługami działającymi we wszystkich klastrach.

2. Wdrożymy poprawkę kustomize do szablonu odpowiedzi istioControlPlane, aby włączyć obsługę całego klastra mTLS. Skopiuj poprawkę do odpowiedniego katalogu dla wszystkich klastrów 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ź repozytorium k8s.

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

4. Wyświetl stan projektu operacyjnego Cloud Build na wcześniej otwartej karcie lub kliknij ten link:

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

 

Zweryfikuj mTLS

5. Ponownie sprawdź MeshPolicy w klastrach operacji. Pamiętaj, że mTLS nie jest już PERMISSIVE i zezwala tylko na 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):

{
  "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):

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

Widzimy również w dziennikach przejście z protokołu HTTP na HTTPS.

Możemy ujawnić to pole z dzienników w interfejsie, klikając jeden wpis logu, a następnie klikając wartość pola, które chcesz wyświetlić. W naszym przypadku kliknij „http”. obok „protocol:

Pozwala to w łatwy sposób zobrazować zmianę.

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żyj DestinationRules i VirtualServices, by powoli kierować ruch do: frontend-v2
• Sprawdź potok wdrożenia GitOps, sprawdzając serię zatwierdzeń w k8s-repo

SZYBKIE ŚLEDZENIE SKRYPTU

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

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

Instrukcje z Laboratorium: kopiowanie i wklejanie

Jeśli masz już ukończony scenariusz szybkiego przejścia tego modułu, nie wykonuj metody kopiowania i wklejania widocznej poniżej**.**

Wdrożenie do wczesnych testów to stopniowe wdrażanie nowej usługi. We wdrożeniu do wczesnych testów wysyłasz coraz więcej ruchu do nowej wersji, jednocześnie wysyłając pozostałą część ruchu do bieżącej wersji. Częstym wzorcem jest przeprowadzanie analizy do wczesnych testów na każdym etapie podziału ruchu i porównywanie „złotych sygnałów”. nowej wersji (czas oczekiwania, odsetek błędów, nasycenie) względem wartości bazowej. Pomaga to zapobiegać przerwom w działaniu i zapewnia stabilność nowej wersji 2. na każdym etapie podziału ruchu.

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

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

Uwaga: ręcznie aktywujemy potok Canary w obu regionach, ale w środowisku produkcyjnym będziesz używać aktywatora automatycznego, na przykład na podstawie nowego tagu obrazu Dockera przekazanego do rejestru.

1. Zdefiniuj kilka zmiennych env w Cloud Shell, aby uprościć uruchamianie 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 repozytorium k8s-repo.

$CANARY_DIR/repo-setup.sh 
 

Te pliki manifestu są kopiowane:

• Wdrożenie frontend-v2
• Poprawka frontend-v1 (aby uwzględnić etykietę „v1” i obraz z punktem końcowym „/version”)
• respy – niewielki pod, który wyświetla dystrybucję odpowiedzi HTTP i pomaga nam wizualizować wdrożenie do wczesnych testów w czasie rzeczywistym.
• DestinationRule (Reguła docelowa) frontendu: dzieli frontendową usługę Kubernetes na dwa podzbiory (v1 i v2) na podstawie „wersji” etykieta wdrożenia
• frontend Istio VirtualService – kieruje 100% ruchu do frontendu w wersji 1. Zastępuje to domyślne działanie usługi Kubernetes w okienku kołowym, które natychmiast wysyła 50% całego ruchu regionalnego w wersji deweloperskiej do frontendu w wersji 2.

3. Zatwierdź zmiany w k8s_repo:

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

4. Wyświetl stan projektu operacyjnego Cloud Build na wcześniej otwartej karcie lub kliknij ten link:

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

5. W konsoli projektu OPS1 przejdź do Cloud Build. Poczekaj na zakończenie potoku Cloud Build, a następnie pobierz pody w przestrzeni nazw frontendu 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 zamknąć polecenia zegarka, naciśnij Ctrl+C

Za pomocą programu tmux podzielimy okno Cloud Shell na 2 panele:

• W dolnym panelu uruchomi się polecenie watch, aby obserwować rozkład odpowiedzi HTTP dla usługi frontendu.
• W górnym panelu będzie uruchomiony rzeczywisty skrypt potoku do wczesnych testów.

6. Uruchom polecenie, aby podzielić okno Cloud Shell, i wykonaj 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)

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

Widzimy, że cały ruch trafia do wdrożenia frontendu w wersji 1 zdefiniowanej w nowej usłudze VirtualService.

7. Uruchom potok do wczesnych testów w regionie Dev1. Udostępniamy skrypt, który aktualizuje w usłudze wirtualnej frontend-v2 procent ruchu (zmieniając wagi na 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 dla regionu 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
 

W dolnym oknie, w którym uruchamiasz polecenie „respy”, możesz zobaczyć podział ruchu w czasie rzeczywistym. Na przykład przy znaku 20% :

Dane wyjściowe (nie kopiuj)

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

8. Gdy wdrażanie wersji Dev2 dobiegnie końca, na końcu skryptu powinien pojawić się komunikat o powodzeniu:

    Output (do not copy) 
   

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

9. A cały ruch frontendu z poda w wersji 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 za pomocą wygenerowanego linku.

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

Powinno być widoczne osobne zatwierdzenie dla każdego odsetka ruchu, a najnowsze zatwierdzenie będzie widoczne u góry listy:

Teraz powtórz ten sam proces dla regionu Dev2. Pamiętaj, że region Dev2 jest nadal „zablokowany”. w wersji 1. Wynika to z tego, że w podstawowym skrypcie repo_setup została wysłana usługa VirtualService bezpośrednio do wysyłania całego ruchu do wersji 1. W ten sposób udało nam się bezpiecznie przeprowadzić regionalną wersję do wczesnych testów w wersji deweloperskiej i upewnić się, że działa dobrze, zanim wdrożymy nową wersję globalnie.

12. Uruchom polecenie, aby podzielić okno Cloud Shell, i wykonaj 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)

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

Widzimy, że cały ruch trafia do wdrożenia frontendu w wersji 1 zdefiniowanej w nowej usłudze VirtualService.

13. Uruchom potok do wczesnych testów w regionie Dev2. Udostępniamy skrypt, który aktualizuje w usłudze wirtualnej frontend-v2 procent ruchu (zmieniając wagi na 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 dla regionu 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)

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

14. Obserwuj ruch z podów w wersji Dev2 w podach Respy w wersji deweloperskiej 2, aby stopniowo przechodzić od wersji 1 frontendu do wersji 2. Gdy skrypt zakończy działanie, zobaczysz:

Dane wyjściowe (nie kopiuj)

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 omówiliśmy korzystanie z Istio na potrzeby regionalnych wdrożeń do wczesnych testów. W środowisku produkcyjnym zamiast ręcznego skryptu możesz automatycznie aktywować ten skrypt do wczesnych testów jako potok Cloud Build za pomocą aktywatora, na przykład nowego otagowanego obrazu przekazanego do rejestru kontenerów. Warto też między poszczególnymi krokami dodać analizę do wczesnych testów i analizować czas oczekiwania i odsetek błędów w wersji 2 pod kątem wstępnie zdefiniowanego progu bezpieczeństwa, a następnie przesyłać więcej ruchu.

11. Zasady autoryzacji

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

• Utwórz AuthorizationPolicy, aby odmówić dostępu do mikroserwisu
• Utwórz AuthorizationPolicy, aby ZEZWALAĆ na określony dostęp do mikroserwisu

SZYBKIE ŚLEDZENIE SKRYPTU

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

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

Instrukcje z Laboratorium: kopiowanie i wklejanie

Jeśli masz już ukończony scenariusz szybkiego przejścia tego modułu, nie wykonuj metody kopiowania i wklejania widocznej poniżej**.**

W przeciwieństwie do aplikacji monolitycznych, które mogą działać w jednym miejscu, rozproszone globalnie aplikacje z mikroserwisami wykonują wywołania przez granice sieci. Oznacza to więcej punktów dostępu do aplikacji i więcej możliwości przeprowadzania złośliwych ataków. A ponieważ pody Kubernetes mają przejściowe adresy IP, tradycyjne oparte na adresach IP reguły zapory sieciowej nie są już wystarczające do zabezpieczenia dostępu między zadaniami. W architekturze mikroserwisów potrzebne jest nowe podejście do bezpieczeństwa. Bazując na elementach zabezpieczeń Kubernetes, takich jak konta usługi, Istio zapewnia elastyczny zestaw zasad zabezpieczeń dla Twoich aplikacji.

Zasady Istio obejmują zarówno uwierzytelnianie, jak i autoryzację. Uwierzytelnianie weryfikuje tożsamość (to, za kogo jest ten serwer), a autoryzacja weryfikuje uprawnienia (czy klient może to zrobić?). Uwierzytelnianie Istio zostało omówione w sekcji o wzajemnym protokole TLS w module 1 (MeshPolicy). W tej sekcji pokażemy, jak używać zasad autoryzacji Istio do kontrolowania dostępu do jednego z naszych zbiorów zadań aplikacji – currencyservice.

Najpierw wdrożymy AuthorizationPolicy we wszystkich 4 klastrach programistycznych, zablokujemy cały dostęp do usługi currencyservice i wywołamy błąd w frontendzie. Potem zezwolimy na dostęp do currencyservice tylko usłudze frontendu.

1. Sprawdź zawartość pola currency-deny-all.yaml. Ta zasada używa selektorów etykiet wdrożenia do ograniczenia dostępu do usługi currencyservice. Zwróć uwagę, że brakuje pola spec. Oznacza to, że ta zasada odmówi całego dostępu do wybranej usługi.

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

Dane wyjściowe (nie kopiuj)

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

2. Skopiuj zasadę waluty do repozytorium k8s-repo dla klastrów operacji 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. Wypchnij zmiany.

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. Gdy kompilacja się zakończy, spróbuj otworzyć frontend 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. Zbadamy, jak usługa waluty egzekwuje tę zasadę AuthorizationPolicy. Najpierw włącz logi na poziomie śledzenia na serwerze 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. Pobieraj logi RBAC (autoryzacji) z pomocniczego proxy usługi waluty. Powinna pojawić się informacja „forced odrzucona” , który wskazuje, że usługa currencyservice jest ustawiona na blokowanie wszystkich żądań przychodzących.

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

Dane wyjściowe (nie kopiuj)

[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 zezwólmy frontendowi – ale nie innym usługom backendu – na dostęp do usługi currencyservice. Otwórz aplikację currency-allow-frontend.yaml i sprawdź jej zawartość. Pamiętaj, że dodaliśmy tę regułę:

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

Dane wyjściowe (nie kopiuj)

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

Umieszczamy na białej liście określony adres source.principal (klient) umożliwiający dostęp do usługi waluty. Ten element source.principal jest definiowany przez konto usługi Kubernetes. W tym przypadku konto usługi dodane do białej listy to konto usługi frontendu w przestrzeni nazw frontendu.

Uwaga: jeśli używasz kont usługi Kubernetes w Istio AuthorizationPolicies, musisz najpierw włączyć wzajemny protokół TLS w klastrze, tak jak w module 1. Ma to na celu zapewnienie, że dane logowania na konto usługi będą dołączane do żądań.

9. Skopiuj zaktualizowaną zasadę dotyczącą waluty

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. Wypchnij zmiany.

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

11. Wyświetl stan projektu operacyjnego Cloud Build na wcześniej otwartej karcie lub kliknij ten link:

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

12. Gdy kompilacja się zakończy, ponownie otwórz frontend Hipstershop. Tym razem na stronie głównej nie powinny być wyświetlane żadne błędy, ponieważ frontend ma jawnie przyznany dostęp do bieżącej usługi.
13. Teraz spróbuj sfinalizować transakcję, dodając produkty do koszyka i klikając „Złóż zamówienie”. Tym razem powinien pojawić się błąd przeliczania cen z usługi waluty, ponieważ dodaliśmy tylko frontend do białej listy, więc usługa Checkout nadal nie może uzyskać dostępu do usługi currencyservice.

14. Na koniec zezwól usłudze płatności na dostęp do waluty, dodając kolejną regułę do naszej usługi AuthorizationPolicy. Pamiętaj, że otwieramy dostęp do waluty tylko w przypadku 2 usług, które go potrzebują – frontendu oraz płatności. Pozostałe backendy będą nadal zablokowane.
15. Otwórz aplikację currency-allow-frontend-checkout.yaml i sprawdź jej zawartość. Zwróć uwagę, że lista reguł działa w trybie logicznym LUB – waluta akceptuje tylko żądania ze zbiorów zadań korzystających z jednego z tych 2 kont usługi.

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

Dane wyjściowe (nie kopiuj)

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 ostateczną zasadę autoryzacji do repozytorium k8s-repo.

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. Wypchnij zmiany

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

18. Wyświetl stan projektu operacyjnego Cloud Build na wcześniej otwartej karcie lub kliknij ten link:

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

19. Gdy kompilacja się zakończy, spróbuj przeprowadzić płatność – to powinno zadziałać.

W tej sekcji omówiliśmy, jak za pomocą zasad autoryzacji Istio egzekwować szczegółową kontrolę dostępu na poziomie poszczególnych usług. W środowisku produkcyjnym można utworzyć jedną zasadę AuthorizationPolicy na usługę i na przykład użyć zasady allow-all, aby umożliwić dostęp do siebie wszystkim zadaniom w tej samej przestrzeni nazw.

12. Skalowanie infrastruktury

Cel: skalowanie infrastruktury przez dodanie nowego regionu, projektu i klastrów.

• Klonowanie repozytorium infrastructure
• Zaktualizuj pliki Terraform, aby utworzyć nowe zasoby
• 2 podsieci w nowym regionie (jedna dla projektu operacyjnego, a druga dla nowego projektu)
• Nowy klaster operacji w nowym regionie (w nowej podsieci)
• Nowa platforma sterująca Istio dla nowego regionu
• 2 klastry aplikacji w nowym projekcie w nowym regionie
• Zatwierdź infrastructure repozytorium
• Zweryfikuj instalację

SZYBKIE ŚLEDZENIE SKRYPTU

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

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

Instrukcje z Laboratorium: kopiowanie i wklejanie

Jeśli masz już ukończony scenariusz szybkiego przejścia tego modułu, nie wykonuj metody kopiowania i wklejania widocznej poniżej**.**

Istnieje wiele sposobów skalowania platformy. Możesz dodać więcej mocy obliczeniowej, dodając węzły do istniejących klastrów. W jednym regionie możesz dodać więcej klastrów. Możesz też dodać do platformy więcej regionów. Decyzja o tym, jaki aspekt platformy należy zastosować, zależy od wymagań. Jeśli na przykład masz klastry we wszystkich 3 strefach w regionie, być może wystarczy dodać więcej węzłów (lub pul węzłów) do istniejącego klastra. Jeśli jednak w jednym regionie masz klastry w 2 z 3 stref, dodanie nowego klastra w trzeciej strefie zapewnia skalowanie i dodatkową domenę błędu (tj. nową strefę). Innym powodem dodania nowego klastra w regionie może być konieczność utworzenia 1 klastra najemcy – ze względu na przepisy lub zgodność z przepisami (na przykład ze względu na PCI lub klaster baz danych, który zawiera informacje umożliwiające identyfikację). Wraz z rozwojem firmy i jej 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 na region. Można to wyobrazić sobie na 2 sposoby:

• Pionowo – w każdym regionie z dodatkową mocą obliczeniową. Aby to zrobić, dodaj więcej węzłów (lub pul węzłów) do istniejących klastrów albo dodaj nowe klastry w regionie. Możesz to zrobić w repozytorium infrastructure. Najprostszą ścieżką jest dodanie węzłów do istniejących klastrów. Dodatkowa konfiguracja nie jest wymagana. Dodawanie 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.
• W poziomie – dodaj więcej regionów. Obecna platforma udostępnia szablon regionalny. Składa się z regionalnego klastra operacji, w którym znajduje się kontrola ASM/Istio, oraz 2 (lub więcej) strefowych klastrów aplikacji, w których są wdrożone zasoby aplikacji.

W ramach tego warsztatu skalujesz platformę „w poziomie” i pionowych etapów zastosowań. Aby można było skalować platformę w poziomie przez dodanie do niej nowego regionu (r3), należy dodać te zasoby:

1. Podsieci w głównym projekcie współdzielonego środowiska VPC w regionie r3 dla nowych klastrów operacji i aplikacji.
2. Regionalny klaster operacji w regionie r3, w którym znajduje się platforma sterująca ASM/Istio.
3. Dwa strefowe klastry aplikacji w 2 strefach w regionie R3.
4. Aktualizacja repozytorium k8s:
5. Wdróż zasoby platformy sterującej ASM/Istio w klastrze operacji w regionie r3.
6. Wdróż udostępnione zasoby platformy sterującej ASM/Istio w klastrach aplikacji w regionie r3.
7. Nie musisz tworzyć nowego projektu, ale kroki w warsztatach pokazują, jak dodać nowy projekt dev3, aby uwzględnić przypadek użycia związany z dodaniem nowego zespołu do platformy.

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

1. W Cloud Shell przejdź do zadania WORKDIR i skopiuj 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 gałąź repozytorium źródłowego warsztatów 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 warsztatów źródłowych. Gałąź add-proj zawiera zmiany dotyczące tej sekcji.

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

4. Zastąp katalog infrastructure w katalogu repozytorium add-proj linkiem symbolicznym 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ć udostępnione stany i zmienne do nowej struktury katalogów projektu.

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

6. Zatwierdź i wypchnij zmiany, aby utworzyć nowy projekt

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

7. Zatwierdzenie aktywuje repozytorium infrastructure, które aktywuje infrastrukturę z nowymi zasobami. Wyświetl postęp Cloud Build. W tym celu kliknij dane wyjściowe znajdujące się pod poniższym linkiem i przejdź do najnowszej kompilacji u góry.

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

Ten krok może potrwać 25–30 minut. Dobry moment na kawę.

W ostatnim kroku infrastructure Cloud Build tworzy nowe zasoby Kubernetes w k8s-repo. Spowoduje to aktywowanie Cloud Build w: k8s-repo (w projekcie operacji). Nowe zasoby Kubernetes są przeznaczone dla 3 nowych klastrów dodanych w poprzednim kroku. Za pomocą Cloud Build firmy k8s-repo i współdzielone zasoby platformy sterującej ASM/Istio są dodawane do nowych klastrów.

8. Gdy infrastruktura Cloud Build się zakończy, przejdź do ostatniego uruchomienia Cloud Build k8s-repo, klikając link do danych wyjściowych.

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

9. Uruchom poniższy skrypt, aby dodać nowe klastry do plików vars i kubeconfig.

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

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

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

11. Wyświetl konteksty klastra. Zobaczysz 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 w nowym klastrze operacji zainstalowano Istio. W tym celu sprawdź, czy wszystkie pody są uruchomione, a zadania zostały ukończone.

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. Sprawdź, czy w dev3 klastrze zainstalowano Istio. W klastrach dev3 działają tylko cytadela, wstrzykiwacz pomocniczy i kodery rdzeni. Współużytkują one platformę sterującą Istio działającą 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

Sprawdzanie wykrywania usług dla współdzielonych platform sterujących

14. Sprawdź, czy obiekty tajne zostały wdrożone we wszystkich klastrach operacji we wszystkich 6 klastrach 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. Pęknięcie obwodu

Cel: wdrożenie bezpiecznika na potrzeby usługi dostawy.

• Utwórz DestinationRule dla usługi shipping, aby wdrożyć bezpiecznik
• Użyj fortio (narzędzia generującego obciążenie) do sprawdzenia bezpiecznika w usłudze shipping przez wymuszenie wyłączenia obwodu

Instrukcje dotyczące modułu skryptów Fast Track

Wkrótce udostępnimy Laboratorium skryptów Fast Track.

Instrukcje z Laboratorium: kopiowanie i wklejanie

Znasz już podstawowe strategie monitorowania i rozwiązywania problemów w usługach z obsługą Istio, więc teraz przyjrzymy się, jak Istio pomaga zwiększyć odporność swoich usług, ograniczając liczbę czynności do wykonania.

Architektura mikroserwisów stwarza ryzyko kaskadowych awarii, w wyniku których awaria jednej usługi może dotrzeć do jej zależności i zależności tych zależności, powodując „efekt fali”. co może mieć wpływ na użytkowników. Istio udostępnia zasady ruchu dla przerw w działaniu obwodów, aby ułatwić izolowanie usług, ochronę usług podrzędnych (po stronie klienta) przed czekaniem na niedziałające usługi oraz ochronę usług wychodzących (po stronie serwera) przed nagłym zalewem ruchu odbierającego, gdy ponownie są one online. Ogólnie rzecz biorąc, użycie wyłączników obwodu pozwoli uniknąć awarii docelowych poziomów usług przez wszystkie usługi z powodu zawieszania się jednej usługi backendu.

Wzorzec bezpiecznika pochodzi od elektrycznego przełącznika, który może „działać” gdy przepływa za dużo prądu, co chroni urządzenia przed przeciążeniem. W przypadku konfiguracji Istio oznacza to, że Envoy jest wyłącznikiem obwodu, który śledzi liczbę oczekujących żądań dotyczących usługi. W tym domyślnym stanie zamkniętym żądania przechodzą przez Envoy w sposób ciągły.

Jednak gdy liczba oczekujących żądań przekracza zdefiniowany próg, wyłącznik obwodu (otwiera się) i Envoy natychmiast zwraca błąd. Dzięki temu serwer może szybko awansować w przypadku klienta i zapobiega odebraniu kodu aplikacji serwera po przeciążeniu.

Następnie, po ustalonym czasie oczekiwania, Envoy przechodzi w stan otwarty, w którym serwer może ponownie zacząć otrzymywać żądania w trybie próbnym, a jeśli uda mu się odpowiedzieć na żądania, bezpiecznik zostanie ponownie zamknięty, a żądania do serwera zaczną przychodzić znów.

Ten diagram zawiera podsumowanie wzorca bezpiecznika Istio. Niebieskie prostokąty oznaczają firmę Envoy, niebieskie okrąg – klienta, a białe okręgi – kontener serwera:

Zasady dotyczące wyłączników możesz definiować za pomocą reguł docelowych Istio. W tej sekcji zastosujemy następującą zasadę, aby wymusić stosowanie bezpiecznika 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

Warto tutaj zwrócić uwagę na 2 pola „DestinationRule”. connectionPool określa liczbę połączeń, na które będzie zezwalać ta usługa. W polu Wykrywanie odstających należy skonfigurować sposób, w jaki Envoy będzie określać próg, po którego przekroczeniu wyłącznik obwodu ma zostać otwarty. W tym miejscu co sekundę (z przedziałem czasu) Envoy zlicza błędy otrzymane z kontenera serwera. Jeśli przekroczy wartość progową consecutiveErrors, włączy się wyłącznik obwodu Envoy, a wszystkie pody katalogu produktów będą chronione przed żądaniami nowych klientów przez 10 sekund. Gdy wyłącznik obwodu Envoy będzie otwarty (tj. aktywny), klienty otrzymają błędy 503 (Usługa niedostępna). Zobaczmy, jak to działa.

1. Aby uprościć polecenia, ustaw zmienne środowiskowe dla repozytorium k8s-repo i katalogu asm.

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łę docelową 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 pod generatora obciążenia Fortio do klastra GKE_1 w regionie Dev1. To jest pod klienta, którego użyjemy do „Podróży” bezpiecznik obwodu dla usługi dostawy.

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 działania Cloud Build.
7. Z powrotem w Cloud Shell użyj poda fortio, aby wysyłać ruch gRPC do usługi dostawy przy 1 połączeniu równoczesnym, łącznie 1000 żądań. Nie spowoduje to wyłączenia bezpiecznika, ponieważ jeszcze nie przekroczliśmy 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)

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ę równoczesnych połączeń do 2, zachowując przy tym stałą łączną liczbę żądań. Ponad dwie trzecie żądań powinno zwrócić błąd „overflow” ponieważ został wyłączony bezpiecznik: zgodnie z zdefiniowaną przez nas zasadą dozwolone jest tylko 1 połączenie równoczesne w 1-sekundowym przedziale.

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)

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ń utraconych, gdy wyłącznik obwodu jest aktywny, przy użyciu wskaźnika upstream_rq_pending_overflow. Wyszukajmy 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)

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ę dotyczącą wyłączników obwodu 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 pokazujemy, jak skonfigurować w usłudze zasadę jednego bezpiecznika. Sprawdzoną metodą jest skonfigurowanie bezpiecznika dla każdej usługi nadrzędnej (backendowej), która może ulec awarii. Stosowanie zasad wyłączników obwodu Istio pomaga odizolować mikroserwisy, zwiększyć odporność na awarie w architekturze 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ń (przed przekazaniem jej do środowiska produkcyjnego).

• Utwórz VirtualService dla usługi recommendation, aby wprowadzić opóźnienie 5 s
• Przetestuj opóźnienie za pomocą generatora obciążenia fortio
• Usuń opóźnienie w: VirtualService i sprawdź poprawność

Instrukcje dotyczące modułu skryptów Fast Track

Wkrótce udostępnimy Laboratorium skryptów Fast Track.

Instrukcje z Laboratorium: kopiowanie i wklejanie

Dodanie do usług zasad dotyczących wyłączników obwodu to jeden ze sposobów wzmocnienia odporności na działanie usług w środowisku produkcyjnym. Jednak złamanie obwodu powoduje awarie, czyli potencjalnie błędy napotykane przez użytkowników, co nie jest idealnym rozwiązaniem. Aby zapobiec przypadkom błędów i lepiej przewidywać, jak usługi otrzymujące mogą zareagować, gdy backendy zwracają błędy, możesz wdrożyć testy chaosu w środowisku testowym. Testowanie chaosu to praktyka celowego uszkodzenia usług w celu przeanalizowania słabych punktów w systemie i zwiększenia odporności na awarie. Testów chaosu możesz też użyć, aby określić sposoby łagodzenia skutków błędów występujących w przypadku awarii backendów – na przykład przez wyświetlanie wyniku z pamięci podręcznej we frontendzie.

Użycie Istio do wstrzykiwania błędów jest przydatne, ponieważ możesz użyć obrazów wersji produkcyjnej i dodać błąd w warstwie sieciowej, zamiast modyfikować kod źródłowy. W środowisku produkcyjnym możesz użyć pełnoprawnego narzędzia do testowania chaosu, aby przetestować odporność nie tylko w warstwie sieciowej, ale też w warstwie Kubernetes.

Aby testować chaos za pomocą Istio, możesz zastosować VirtualService z „błędem” . Istio obsługuje 2 rodzaje błędów: błędy opóźnione (wstrzykiwanie czasu oczekiwania) i błędy przerywania (wstrzykiwanie błędów HTTP). W tym przykładzie dodamy do usługi rekomendacji błąd 5-sekundowego opóźnienia. Tym razem jednak zamiast korzystać z bezpiecznika, by „szybko uległo awarii” przed tą usługą zawieszania, wymusimy przetrwanie pełnego czasu oczekiwania usługom pobieranym.

11. Przejdź do katalogu fault Injection (Wstrzykiwanie błędów).

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

12. Otwórz aplikację k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml, aby sprawdzić jej zawartość. Zwróć uwagę, że Istio ma opcję wstrzykiwania błędu do odsetka żądań – tutaj wprowadzimy limit czasu na wszystkie żądania usługi rekomendacji.

Dane wyjściowe (nie kopiuj)

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 obiekt VirtualService do k8s_repo. Wprowadzone zostaną wstrzykiwanie błędu na całym świecie 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. Wypchnij zmiany

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

15. Poczekaj na zakończenie działania Cloud Build.
16. Wykonaj działanie do poda fortio wdrożonego w sekcji wyłączników obwodu i wyślij część ruchu do usługi rekomendacji.

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)

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 błędu, który wstrzyknęliśmy, jest otwarcie frontendu w przeglądarce i kliknięcie dowolnej usługi. Wczytanie strony produktu powinno potrwać 5 dodatkowych sekund, ponieważ pobiera ona rekomendacje wyświetlane u dołu strony.
18. Wyczyść, usuwając usługę 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. Wypchnij zmiany:

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, Mikser, Galley i Cytadela. Każdy wysyła odpowiednie wskaźniki monitorowania do Prometheus, a statki ASM korzystają z paneli Grafana, które umożliwiają operatorom wizualizację danych monitorowania oraz ocenę stanu i wydajności platformy sterującej.

Wyświetlanie paneli informacyjnych

20. Przekierowanie portów w usłudze Grafana zainstalowanej z Istio

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

21. Otwórz Grafana w przeglądarce
22. Kliknij „Podgląd w przeglądarce”. w prawym górnym rogu okna Cloud Shell
23. Kliknij Podgląd na porcie 3000 (uwaga: jeśli port jest inny niż 3000, kliknij Zmień port i wybierz port 3000).
24. Spowoduje to otwarcie w przeglądarce karty o adresie URL podobnym do „ BASE_URL/?orgId=1&authuser=0&environment_id=default"
25. Wyświetl dostępne panele
26. Zmień adres URL na „ BASE_URL/dashboard"
27. Kliknij „istio”. aby wyświetlić dostępne panele
28. Kliknij dowolny panel, by wyświetlić jego skuteczność. W sekcjach poniżej przyjrzymy się istotnym danym związanym z każdym komponentem.

Wdrożenie pilotażowe monitorowania

Pilot to komponent platformy sterującej, który rozdziela konfigurację sieci i zasad na obszar danych (serwery proxy Envoy). Wdrożenie pilotażowe zwykle skaluje się wraz z liczbą zbiorów zadań i wdrożeń, ale niekoniecznie wraz z ilością ruchu skierowanego do tych zbiorów zadań. Wdrożenie pilotażowe w złym stanie może:

• zużywają więcej zasobów, niż jest to konieczne (procesor lub pamięć RAM)
• co może prowadzić do opóźnień w przekazywaniu zaktualizowanych informacji o konfiguracji do Envoys.

Uwaga: jeśli wdrożenie pilotażowe nie działa lub występują opóźnienia, zadania nadal obsługują ruch.

23. Nawiguj do " BASE_URL/dashboard/db/istio-pilot-dashboard" w przeglądarce, aby wyświetlić wskaźniki pilotażowe.

Ważne monitorowane dane

Wykorzystanie zasobów

Akceptowane dane liczbowe znajdziesz na stronie Istio Performance and Scalability. Jeśli zauważysz znacznie większe długotrwałe wykorzystanie zasobów niż to, skontaktuj się z zespołem pomocy GCP.

Informacje push o programie pilotażowym

Ta sekcja monitoruje wdrożenia pilotażowe konfiguracje na serwery proxy Envoy.

• Wypychania pilotażowe pokazują typ konfiguracji przekazanej 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 pokazuje punkty końcowe, które zostały skonfigurowane, ale nie mają uruchomionych instancji (co może oznaczać usługi zewnętrzne, takie jak *.googleapis.com).
• Błędy wdrożenia pilotażowego pokazują liczbę błędów, które wystąpiły w danym okresie.
• Konflikty wskazują liczbę konfliktów, które są niejednoznaczne w konfiguracji detektorów.

Występują błędy lub konflikty, co oznacza, że konfiguracja co najmniej jednej usługi jest nieprawidłowa lub niespójna. Więcej informacji znajdziesz w sekcji Rozwiązywanie problemów z obszarem danych.

Informacje o Envoy

Ta sekcja zawiera informacje o serwerach proxy Envoy komunikujących się z platformą sterującą. Jeśli zauważysz powtarzające się błędy połączenia XDS, skontaktuj się z zespołem pomocy GCP.

Mikser monitorowania

Mikser to komponent, który śledzi dane telemetryczne z serwerów proxy Envoy do backendów telemetrycznych (zwykle Prometheus, Stackdriver itp.). W tym zakresie nie znajduje się on w obszarze danych. Jest wdrażane jako 2 zadania Kubernetes (nazywane mikserem) z 2 różnymi nazwami usług (istio-telemetria i istio-policy).

Miksera można też używać do integracji z systemami zasad. W tym przypadku Mikser wpływa na obszar danych, sprawdzając zasady Miksera, który nie blokuje dostępu do Twoich usług.

Mikser dostosowuje się do natężenia ruchu.

24. Nawiguj do " BASE_URL/dashboard/db/istio-mixer-dashboard" w przeglądarce, aby wyświetlić dane z Miksera.

Ważne monitorowane dane

Wykorzystanie zasobów

Akceptowane dane liczbowe znajdziesz na stronie Istio Performance and Scalability. Jeśli zauważysz znacznie większe długotrwałe wykorzystanie zasobów niż to, skontaktuj się z zespołem pomocy GCP.

Omówienie miksera

• Czas trwania odpowiedzi to ważne dane. Chociaż w ścieżce danych nie występują raporty do telemetrii miksera, to jednak jeśli te opóźnienia są wysokie, znacznie spowalniają one wydajność pomocniczego proxy. 90 centyl powinien być wyrażony w milisekundach, a 99 centyl – poniżej 100 ms.

• Czas trwania wysyłki adaptera wskazuje czas oczekiwania miksera w wywoływaniu adapterów (przez jaki wysyła on informacje do systemów telemetrycznych i logowania). Długie czasy oczekiwania wpłyną na wydajność sieci typu mesh. Opóźnienia p90 także powinny być krótsze niż 10 ms.

Galeria monitorowania

Galley to komponent do walidacji, pozyskiwania, przetwarzania i dystrybucji konfiguracji Istio. Przekazuje konfigurację z serwera Kubernetes API do wdrożenia pilotażowego. Podobnie jak w przypadku wersji pilotażowej, mechanizm ten ma tendencję do skalowania w zależności od liczby usług i punktów końcowych w systemie.

25. Nawiguj do " BASE_URL/dashboard/db/istio-galley-dashboard" w przeglądarce, aby wyświetlić dane z usługi Galley.

Ważne monitorowane dane

Weryfikacja zasobów

Wskaźnik, który jest najważniejszym wskaźnikiem, który wskazuje liczbę zasobów różnych typów, takich jak reguły miejsc docelowych, bramy i wpisy usługi, które przeszły weryfikację lub nie przeszły weryfikacji.

Połączone klienty

Wskazuje liczbę klientów połączonych z Galley; zwykle wynosi on 3 (pilot, telemetria, istio-policy) i jest skalowany wraz ze skalowaniem tych komponentów.

16. Rozwiązywanie problemów z Istio

Rozwiązywanie problemów z obszarem danych

Jeśli panel pilotażowy wskazuje, że masz problemy z konfiguracją, przejrzyj logi PIlot lub użyj protokołu istioctl, aby znaleźć takie problemy.

Aby przeanalizować logi wdrożenia pilotażowego, uruchom wykrywanie kubectl -n istio-system istio-pilot-69db46c598-45m44, zastępując istio-pilot-... identyfikatorem poda instancji pilotażowej, której problem chcesz rozwiązać.

W wyświetlonym dzienniku wyszukaj komunikat Push Status (Stan push). 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 push wskazuje wszelkie problemy, które wystąpiły podczas próby przekazania konfiguracji na serwery proxy Envoy – w tym przypadku występuje kilka „zduplikowanych klastrów”. które wskazują zduplikowane miejsca docelowe nadrzędne.

Aby uzyskać pomoc w diagnozowaniu problemów, skontaktuj się z zespołem pomocy Google Cloud.

Znajdowanie błędów konfiguracji

Aby użyć istioctl do analizy konfiguracji, uruchom polecenie istioctl experimental analyze -k --context $OPS_GKE_1. Spowoduje to przeprowadzenie analizy konfiguracji w systemie, wskazanie problemów i sugerowanych zmian. Pełną listę błędów konfiguracji, które może wykryć to polecenie, znajdziesz w dokumentacji.

17. Czyszczenie

Poniższe czynności są wykonywane przez administratora po zakończeniu warsztatów.

Administrator uruchamia skrypt cleanup_workshop.sh, aby usunąć zasoby utworzone przez ten skrypt. Do uruchomienia skryptu czyszczenia potrzebne są następujące informacje.

• Nazwa organizacji – na przykład yourcompany.com
• Identyfikator warsztatów – w formacie YYMMDD-NN, np. 200131-01
• Zasobnik GCS administratora – zdefiniowany w skrypcie wczytywania.

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

CLOUD SHELL

14. Sprawdź, czy w gcloud korzystasz z konta odpowiedniego administratora.

gcloud config list
 

15. Przejdź do folderu asm.

cd ${WORKDIR}/asm
 

16. Podaj nazwę organizacji i identyfikator warsztatów do usunięcia.

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

17. Uruchom skrypt czyszczenia w następujący sposób.

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