Anthos Service Mesh-Workshop: Lab-Leitfaden

1. ALPHA-WORKSHOP

WICHTIGER HINWEIS: DIES IST EIN ALPHA-WORKSHOP, DER AUSSCHLIESSLICH ALS PRÄSENZSCHULUNG MIT KURSLEITER GEDACHT IST.

Link zum Workshop-Codelab: bit.ly/asm-workshop

2. Übersicht

Architekturdiagramm

In diesem Workshop erfahren Sie, wie Sie global verteilte Dienste in der Produktion in der GCP einrichten. Die wichtigsten verwendeten Technologien sind Google Kubernetes Engine (GKE) für die Rechenleistung und Istio Service Mesh für sichere Verbindungen, Beobachtbarkeit und erweiterte Traffic-Gestaltung. Alle in diesem Workshop verwendeten Methoden und Tools sind auch in der Produktion einsetzbar.

Inhalt

• Modul 0: Einführung und Einrichtung der Plattform
• Einführung und Architektur
• Einführung in Service Mesh und Istio/ASM
• Lab: Infrastructure Setup: User workflow
• Pause
• QnA
• Modul 1: Anwendungen mit ASM installieren, schützen und überwachen
• Repository-Modell: Infrastruktur- und Kubernetes-Repositories
• Lab: Deploy sample application
• Verteilte Dienste und Beobachtbarkeit
• Mittagessen
• Lab: Observability with Stackdriver
• QNA
• Modul 2 – DevOps – Canary-Rollouts, Richtlinie/RBAC
• Multi-Cluster-Service-Discovery und Sicherheit/Richtlinie
• Lab: Gegenseitiges TLS
• Canary-Deployments
• Lab: Canary-Deployments
• Sicheres globales Load-Balancing für mehrere Cluster
• Pause
• Lab: Authorization Policy
• QNA
• Modul 3 – Infra Ops – Plattform-Upgrades
• Bausteine für verteilte Dienste
• Lab: Infrastructure Scaling
• Nächste Schritte

Präsentationen

Die Folien für diesen Workshop finden Sie unter dem folgenden Link:

ASM Workshop Slides

Vorbereitung

Bevor Sie mit diesem Workshop fortfahren, müssen folgende Voraussetzungen erfüllt sein:

1. Ein GCP-Organisationsknoten
2. Eine Rechnungskonto-ID (Ihr Nutzer muss Abrechnungsadministrator für dieses Rechnungskonto sein)
3. IAM-Rolle „Organisationsadministrator“ auf Organisationsebene für Ihren Nutzer

3. Einrichten der Infrastruktur – Administrator-Workflow

Die Schritte in diesem Abschnitt werden von einem Administrator ausgeführt, der den Workshop erstellt.

Wenn Sie ein Nutzer sind, der den Workshop durchführt, fahren Sie mit dem nächsten Abschnitt mit dem Label Infrastructure Setup - User Workflow fort.

Bootstrap-Workshop-Script

Mit dem Skript bootstrap_workshop.sh wird die anfängliche Umgebung für den Workshop eingerichtet. Mit diesem Skript können Sie eine einzelne Umgebung für sich selbst oder mehrere Umgebungen für mehrere Nutzer einrichten, wenn Sie diesen Workshop als Training für mehrere Nutzer durchführen.

Für das Bootstrap-Workshop-Script sind die folgenden Eingaben erforderlich:

• Organisationsname (z. B. yourcompany.com): Dies ist die Organisation, in der Sie Umgebungen für den Workshop erstellen.
• Abrechnungs-ID (z. B. 12345-12345-12345): Diese Abrechnungs-ID wird verwendet, um alle während des Workshops verwendeten Ressourcen abzurechnen.
• Werkstattnummer (z. B. 01): Eine zweistellige Zahl. Dies ist nützlich, wenn Sie mehrere Workshops an einem Tag durchführen und diese separat im Blick behalten möchten. Workshopnummern werden auch zum Ableiten von Projekt-IDs verwendet. Durch separate Workshopnummern ist es einfacher, dafür zu sorgen, dass Sie jedes Mal eindeutige Projekt-IDs erhalten. Neben der Workshopnummer wird auch das aktuelle Datum (im Format YYMMDD) für Projekt-IDs verwendet. Durch die Kombination aus Datum und Workshopnummer werden eindeutige Projekt-IDs erstellt.
• Startnutzernummer (z. B. 1): Diese Nummer gibt den ersten Nutzer im Workshop an. Wenn Sie beispielsweise einen Workshop für 10 Nutzer erstellen möchten, können Sie die Startnutzernummer 1 und die Endnutzernummer 10 festlegen.
• Endnutzernummer (z. B. 10): Diese Nummer gibt den letzten Nutzer im Workshop an. Wenn Sie beispielsweise einen Workshop für 10 Nutzer erstellen möchten, können Sie die Startnutzernummer 1 und die Endnutzernummer 10 festlegen. Wenn Sie nur eine Umgebung einrichten (z. B. für sich selbst), geben Sie für die Start- und Endnutzernummer dieselbe Zahl ein. Dadurch wird eine einzelne Umgebung erstellt.

Neben dem Datum und der Workshopnummer sind auch die Start- und Endnutzernummern in den Projekt-IDs enthalten. Die Nutzer-IDs (für Nutzer, die den Workshop durchführen) werden aus der Start- und Endnutzernummer abgeleitet. User-IDs werden im Abschnitt User schema and permissions performing the workshop erläutert.

• Admin-GCS-Bucket (z. B. my-gcs-bucket-name): Ein GCS-Bucket wird zum Speichern von Workshop-bezogenen Informationen verwendet. Diese Informationen werden vom Skript cleanup_workshop.sh verwendet, um alle Ressourcen, die während des Bootstrap-Workshop-Skripts erstellt wurden, ordnungsgemäß zu löschen. Administratoren, die Workshops erstellen, benötigen Lese-/Schreibberechtigungen für diesen Bucket.

Das Bootstrap-Workshop-Skript verwendet die oben angegebenen Werte und fungiert als Wrapper-Skript, das das Skript setup-terraform-admin-project.sh aufruft. Mit dem Skript „setup-terraform-admin-project.sh“ wird die Workshop-Umgebung für einen einzelnen Nutzer erstellt.

Für das Bootstrapping des Workshops erforderliche Administratorberechtigungen

In diesem Workshop gibt es zwei Arten von Nutzern. Ein ADMIN_USER, der Ressourcen für diesen Workshop erstellt und löscht. Die zweite ist MY_USER, die die Schritte im Workshop ausführt. MY_USER hat nur Zugriff auf eigene Ressourcen. ADMIN_USER hat Zugriff auf alle Nutzereinrichtungen. Wenn Sie diese Einrichtung für sich selbst vornehmen, sind ADMIN_USER und MY_USER identisch. Wenn Sie diesen Workshop als Lehrkraft für mehrere Schüler oder Studenten erstellen, sind ADMIN_USER und MY_USER unterschiedlich.

Für die ADMIN_USER sind die folgenden Berechtigungen auf Organisationsebene erforderlich:

• Inhaber: Berechtigung als Projektinhaber für alle Projekte in der Organisation.
• Ordneradministrator: Kann Ordner in der Organisation erstellen und löschen. Jeder Nutzer erhält einen einzelnen Ordner mit allen seinen Ressourcen im Projekt.
• Administrator der Organisation
• Projektersteller: Berechtigung zum Erstellen von Projekten in der Organisation.
• Projektlöscher: Berechtigung zum Löschen von Projekten in der Organisation.
• Projekt-IAM-Administrator: Berechtigung zum Erstellen von IAM-Regeln in allen Projekten der Organisation.

ADMIN_USER muss außerdem Rechnungsadministrator für die Rechnungs-ID sein, die für den Workshop verwendet wird.

Nutzer-Schema und Berechtigungen für den Workshop

Wenn Sie diesen Workshop für andere Nutzer in Ihrer Organisation erstellen möchten, müssen Sie ein bestimmtes Namensschema für MY_USERs verwenden. Im Skript „bootstrap_workshop.sh“ geben Sie eine Start- und eine Endnutzernummer an. Anhand dieser Zahlen werden die folgenden Nutzernamen erstellt:

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

Wenn Sie beispielsweise das Bootstrap-Workshop-Skript mit der Startnutzernummer 1 und der Endnutzernummer 3 in Ihrer Organisation „IhrUnternehmen.de“ ausführen, werden die Workshop-Umgebungen für die folgenden Nutzer erstellt:

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

Diesen Nutzernamen werden für ihre spezifischen Projekte, die während des Skripts „setup_terraform_admin_project.sh“ erstellt wurden, Projektinhaberrollen zugewiesen. Sie müssen sich an dieses Schema für die Nutzerbenennung halten, wenn Sie das Bootstrap-Skript verwenden. Informationen zum gleichzeitigen Hinzufügen mehrerer Nutzer in G Suite

Für den Workshop erforderliche Tools

Dieser Workshop soll über Cloud Shell gestartet werden. Für diesen Workshop sind die folgenden Tools erforderlich.

• gcloud (Version >= 270)
• kubectl
• sed (funktioniert mit sed in Cloud Shell/Linux, aber nicht unter Mac OS)
• git (muss auf dem neuesten Stand sein)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize

Alle Tools mit Ausnahme von kustomize sind standardmäßig in Cloud Shell installiert. Wenn kustomize nicht installiert ist, installieren Sie es mit dem Bash-Script, das im Link oben bereitgestellt wird. Achten Sie darauf, dass sich die kustomize-Binärdatei in Ihrem PATH befindet, und bestätigen Sie dies, indem Sie den Befehl kustomize in Cloud Shell ausführen.

Workshop für sich selbst einrichten (Einrichtung für einen einzelnen Nutzer)

1. Öffnen Sie Cloud Shell und führen Sie alle unten aufgeführten Aktionen in Cloud Shell aus. Klicken Sie auf den Link unten.

CLOUD SHELL

2. Prüfen Sie, ob Sie mit dem gewünschten Administratornutzer in gcloud angemeldet sind.

gcloud config list
 

3. Erstellen Sie ein WORKDIR und klonen Sie das Workshop-Repository.

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

4. Geben Sie den Namen Ihrer Organisation, die Abrechnungs-ID, die Workshop-Nummer und einen GCS-Administrator-Bucket an, der für den Workshop verwendet werden soll. In den Abschnitten oben finden Sie Informationen zu den Berechtigungen, die für die Einrichtung des Workshops erforderlich sind.

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. Führen Sie das Skript „bootstrap_workshop.sh“ aus. Dieses Skript kann einige Minuten in Anspruch nehmen.

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 
 

Da Sie die Einrichtung selbst vornehmen, müssen Sie die Start- und Endnutzernummer nicht definieren.

Nachdem das Skript „bootstrap_workshop.sh“ abgeschlossen ist, wird für jeden Nutzer in der Organisation ein GCP-Ordner erstellt. Im Ordner wird ein Terraform-Admin-Projekt erstellt. Mit dem Terraform-Administratorprojekt werden die restlichen GCP-Ressourcen erstellt, die für diesen Workshop erforderlich sind. Sie aktivieren die erforderlichen APIs im Terraform-Administratorprojekt. Sie verwenden Cloud Build, um Terraform-Pläne anzuwenden. Sie weisen dem Cloud Build-Dienstkonto die entsprechenden IAM-Rollen zu, damit es Ressourcen in GCP erstellen kann. Schließlich konfigurieren Sie ein Remote-Backend in einem Google Cloud Storage-Bucket (GCS), um Terraform-Zustände für alle GCP-Ressourcen zu speichern.

Um die Cloud Build-Aufgaben im Terraform-Administratorprojekt aufzurufen, benötigen Sie die ID des Terraform-Administratorprojekts. Diese wird in der Datei „vars/vars.sh“ in Ihrem ASM-Verzeichnis gespeichert. Dieses Verzeichnis wird nur beibehalten, wenn Sie den Workshop als Administrator für sich selbst einrichten.

6. Variablendatei als Quelle verwenden, um Umgebungsvariablen festzulegen

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

Workshop für mehrere Nutzer einrichten (Einrichtung für mehrere Nutzer)

7. Öffnen Sie Cloud Shell und führen Sie alle unten aufgeführten Aktionen in Cloud Shell aus. Klicken Sie auf den Link unten.

CLOUD SHELL

8. Prüfen Sie, ob Sie mit dem gewünschten Administratornutzer in gcloud angemeldet sind.

gcloud config list
 

9. Erstellen Sie ein WORKDIR und klonen Sie das Workshop-Repository.

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

10. Geben Sie den Namen Ihrer Organisation, die Abrechnungs-ID, die Workshop-Nummer, die Start- und Endnutzernummer sowie einen Administrator-GCS-Bucket für den Workshop an. In den Abschnitten oben finden Sie Informationen zu den Berechtigungen, die für die Einrichtung des Workshops erforderlich sind.

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. Führen Sie das Skript „bootstrap_workshop.sh“ aus. Dieses Skript kann einige Minuten in Anspruch nehmen.

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. Rufen Sie die Datei „workshop.txt“ aus dem GCS-Bucket des Administrators ab, um die Terraform-Projekt-IDs abzurufen.

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

4. Lab einrichten und vorbereiten

Nutzer, die den Workshop durchführen, beginnen hier. Führen Sie alle Schritte in einem INCOGNITO-Fenster in Chrome oder Firefox aus.

Lab-Pfad auswählen

Die Labs in diesem Workshop können auf zwei Arten durchgeführt werden:

• Interaktive Scripts für den einfachen Fast Track
• Jede Anweisung manuell kopieren und einfügen

Mit der Methode mit Fast-Track-Scripts können Sie für jedes Lab ein einzelnes interaktives Script ausführen, das Sie durch das Lab führt, indem die Befehle für das Lab automatisch ausgeführt werden. Die Befehle werden in Batches mit kurzen Erklärungen zu den einzelnen Schritten und deren Zweck ausgeführt. Nach jedem Batch werden Sie aufgefordert, mit dem nächsten Batch von Befehlen fortzufahren. So können Sie die Labs in Ihrem eigenen Tempo durcharbeiten. Die Fast-Track-Skripts sind idempotent. Das bedeutet, dass Sie sie mehrmals ausführen können und das Ergebnis immer dasselbe ist.

Die Fast Track-Skripts werden oben in jedem Lab in einem grünen Feld angezeigt, wie unten zu sehen ist.

FAST TRACK SCRIPT

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

Bei der Copy-and-paste-Methode werden einzelne Befehlsblöcke mit Erklärungen der Befehle kopiert und eingefügt. Diese Methode ist nur für die einmalige Ausführung vorgesehen. Es gibt keine Garantie dafür, dass Sie mit dieser Methode dieselben Ergebnisse erhalten, wenn Sie Befehle noch einmal ausführen.

Wählen Sie für die Labs eine der beiden Methoden aus.

Nachdem Sie eine Methode ausgewählt und die entsprechenden Schritte ausgeführt haben, führen Sie keine Schritte der anderen Methode aus.

Schnelle Einrichtung von Scripts

Wenn Sie das Fast-Track-Skript durchgearbeitet haben, ist das Lab abgeschlossen. Führen Sie die Schritte in der Anleitung zum Kopieren und Einfügen nicht aus.

Nutzerinformationen abrufen

Für diesen Workshop wird ein temporäres Nutzerkonto (oder ein Lab-Konto) verwendet, das vom Administrator des Workshops erstellt wurde. Das Lab-Konto ist Inhaber aller Projekte im Workshop. Der Workshop-Administrator stellt dem Nutzer, der den Workshop durchführt, die Anmeldedaten für das Lab-Konto (Nutzername und Passwort) zur Verfügung. Alle Projekte des Nutzers haben das Präfix des Nutzernamens des Lab-Kontos. Für das Lab-Konto [e-mail] wäre die Terraform-Administratorprojekt-ID beispielsweise user001-200131-01-tf-abcde. Das gilt auch für die restlichen Projekte. Jeder Nutzer muss sich mit dem vom Workshop-Administrator bereitgestellten Lab-Konto anmelden und den Workshop mit diesem Konto durchführen.

Prüfen Sie Ihre geschäftliche E‑Mail-Adresse (dieselbe E‑Mail-Adresse, mit der Sie sich für den Workshop registriert haben). Sie sollten eine E-Mail vom Workshop-Administrator mit den Anmeldedaten für Ihr Lab-Konto (Nutzername und Passwort) erhalten haben. Die E‑Mail sieht so aus.

1. Klicken Sie auf den Link unten, um Cloud Shell zu öffnen.

CLOUD SHELL

2. Melden Sie sich mit den Anmeldedaten für das Lab-Konto an (nicht mit Ihrem Geschäfts- oder privaten Konto). Das Lab-Konto sieht so aus: userXYZ@<workshop_domain>.com.
3. Da es sich um ein neues Konto handelt, werden Sie aufgefordert, die Google-Nutzungsbedingungen zu akzeptieren. Klicken Sie auf „Akzeptieren“.

4. Klicken Sie auf dem nächsten Bildschirm das Kästchen an, um den Google-Nutzungsbedingungen zuzustimmen, und klicken Sie auf Start Cloud Shell.

In diesem Schritt wird eine kleine Linux-Debian-VM für Sie bereitgestellt, mit der Sie auf GCP-Ressourcen zugreifen können. Jedes Konto erhält eine Cloud Shell-VM. Wenn Sie sich mit dem Lab-Konto anmelden, werden Sie mit den Anmeldedaten des Lab-Kontos angemeldet. Zusätzlich zu Cloud Shell wird auch ein Code-Editor bereitgestellt, der das Bearbeiten von Konfigurationsdateien (Terraform, YAML usw.) erleichtert. Standardmäßig ist der Cloud Shell-Bildschirm in die Cloud Shell-Shell-Umgebung (unten) und den Cloud Code-Editor (oben) unterteilt.  Über das Stiftsymbol  und das Shell-Prompt-Symbol  oben rechts können Sie zwischen Shell und Code-Editor wechseln. Sie können auch den Trennbalken in der Mitte nach oben oder unten ziehen, um die Größe der einzelnen Fenster manuell zu ändern. 5. Erstellen Sie ein WORKDIR für diesen Workshop. WORKDIR ist ein Ordner, in dem Sie alle Labs für diesen Workshop ausführen. Führen Sie die folgenden Befehle in Cloud Shell aus, um das WORKDIR zu erstellen.

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

6. Exportieren Sie den Nutzer des Laborkontos als Variable, die für diesen Workshop verwendet werden soll. Das ist dasselbe Konto, mit dem Sie sich in Cloud Shell angemeldet haben.

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

Hinweis: Wenn Sie Administrator sind und den Workshop mit den Flags „-sufa“ oder „–setup-for-admin“ für sich selbst einrichten, legen Sie MY_USER auf die E-Mail-Adresse des GCP-Kontos fest, mit dem Sie die Workshop-Projekte erstellt haben.

7. Geben Sie die Variablen WORKDIR und MY_USER aus, um zu prüfen, ob beide richtig festgelegt sind. Führen Sie dazu die folgenden Befehle aus.

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

8. Klonen Sie das Workshop-Repository.

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

5. Einrichten der Infrastruktur – Nutzer-Workflow

Ziel: Infrastruktur und Istio-Installation prüfen

• Workshop-Tools installieren
• Workshop-Repository klonen
• Installation von Infrastructure prüfen
• Installation von k8s-repo prüfen
• Istio-Installation prüfen

FAST TRACK SCRIPT

Wenn Sie sich für diese Methode entscheiden, führen Sie das folgende Skript aus, um dieses Lab abzuschließen.

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

Nachdem das Skript abgeschlossen ist, geben Sie Ihren bashrc als Quelle an, um die Variablen in Ihrer Cloud Shell-Sitzung zu aktualisieren.

source ${HOME}/.bashrc

Lab-Anleitung für die Copy-and-Paste-Methode

WICHTIG: Wenn Sie das Fast-Track-Script für dieses Lab bereits ausgeführt haben, führen Sie die Copy-and-Paste-Methode unten NICHT aus.**

Nutzerinformationen abrufen

Der Administrator, der den Workshop einrichtet, muss dem Nutzer den Nutzernamen und das Passwort zur Verfügung stellen. Allen Projekten des Nutzers wird der Nutzername vorangestellt. Für den Nutzer [e-mail] wäre die Terraform-Administratorprojekt-ID beispielsweise user001-200131-01-tf-abcde. Das gilt auch für die anderen Projekte. Jeder Nutzer hat nur Zugriff auf seine eigene Workshop-Umgebung.

Für den Workshop erforderliche Tools

Dieser Workshop soll über Cloud Shell gestartet werden. Für diesen Workshop sind die folgenden Tools erforderlich.

Alle Tools mit Ausnahme von kustomize und pv sind standardmäßig in Cloud Shell installiert. Unten finden Sie eine Anleitung zur Installation beider Apps.

• gcloud (Version >= 270)
• kubectl
• sed (funktioniert mit sed in Cloud Shell/Linux, aber nicht unter Mac OS)
• git (muss auf dem neuesten Stand sein)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize
• pv

Auf das Terraform-Administratorprojekt zugreifen

Nachdem das Skript „bootstrap_workshop.sh“ abgeschlossen ist, wird für jeden Nutzer in der Organisation ein GCP-Ordner erstellt. Im Ordner wird ein Terraform-Admin-Projekt erstellt. Mit dem Terraform-Administratorprojekt werden die restlichen GCP-Ressourcen erstellt, die für diesen Workshop erforderlich sind. Mit dem Script „setup-terraform-admin-project.sh“ werden die erforderlichen APIs im Terraform-Administratorprojekt aktiviert. Cloud Build wird zum Anwenden von Terraform-Plänen verwendet. Über das Skript weisen Sie dem Cloud Build-Dienstkonto die entsprechenden IAM-Rollen zu, damit es Ressourcen in GCP erstellen kann. Schließlich wird ein Remote-Backend in einem Google Cloud Storage-Bucket (GCS) konfiguriert, um Terraform-Zustände für alle GCP-Ressourcen zu speichern.

Um die Cloud Build-Aufgaben im Terraform-Administratorprojekt aufzurufen, benötigen Sie die ID des Terraform-Administratorprojekts. Diese wird im Administrator-GCS-Bucket gespeichert, der im Bootstrap-Script angegeben wurde. Wenn Sie das Bootstrap-Skript für mehrere Nutzer ausführen, befinden sich alle Terraform-Administratorprojekt-IDs im GCS-Bucket.

Dieser Workshop soll in Cloud Shell und der Cloud Console durchgeführt werden. Führen Sie die folgenden Schritte in einem INCOGNITO-Fenster aus, da Sie sich mit einem separaten Nutzernamen und Passwort anmelden.

1. Öffnen Sie Cloud Shell (falls sie nicht bereits im Abschnitt „Lab-Einrichtung und ‑Vorbereitung“ geöffnet wurde), indem Sie auf den Link unten klicken.

CLOUD SHELL

2. Installieren Sie kustomize (falls noch nicht geschehen) im Ordner $HOME/bin und fügen Sie den Ordner $HOME/bin zu $PATH hinzu.

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. Installieren Sie pv und verschieben Sie es nach $HOME/bin/pv.

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

4. Aktualisieren Sie den Bash-Prompt.

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. Prüfen Sie, ob Sie mit dem gewünschten Nutzerkonto in gcloud angemeldet sind.

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

6. Rufen Sie die ID Ihres Terraform-Administratorprojekts mit dem folgenden Befehl ab:

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

7. Alle Ressourcen, die mit dem Workshop verknüpft sind, werden als Variablen in einer Datei „vars.sh“ gespeichert, die sich in einem GCS-Bucket im Terraform-Administratorprojekt befindet. Rufen Sie die Datei „vars.sh“ für Ihr Terraform-Administratorprojekt ab.

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. Klicken Sie auf den angezeigten Link, um die Cloud Build-Seite für das Terraform-Administratorprojekt zu öffnen und zu prüfen, ob der Build erfolgreich abgeschlossen wurde.

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

Wenn Sie zum ersten Mal auf die Cloud Console zugreifen, stimmen Sie den Google-Nutzungsbedingungen zu.

9. Klicken Sie auf der Seite Cloud Build in der linken Navigationsleiste auf den Link History und dann auf den letzten Build, um die Details des ersten Terraform-Apply-Vorgangs aufzurufen. Die folgenden Ressourcen werden im Rahmen des Terraform-Skripts erstellt. Sie können sich auch das Architekturdiagramm oben ansehen.

• 4 GCP-Projekte in der Organisation. Das angegebene Rechnungskonto ist mit jedem Projekt verknüpft.
• Ein Projekt ist das network host project für die freigegebene VPC. In diesem Projekt werden keine weiteren Ressourcen erstellt.
• Ein Projekt ist das ops project, das für GKE-Cluster der Istio-Steuerungsebene verwendet wird.
• Zwei Projekte repräsentieren zwei verschiedene Entwicklungsteams, die an ihren jeweiligen Diensten arbeiten.
• In jedem der drei Projekte ops, dev1 und dev2 werden zwei GKE-Cluster erstellt.
• Ein CSR-Repository mit dem Namen k8s-repo wird erstellt, das sechs Ordner für Kubernetes-Manifestdateien enthält. Ein Ordner pro GKE-Cluster. Dieses Repository wird verwendet, um Kubernetes-Manifeste im GitOps-Stil in den Clustern bereitzustellen.
• Ein Cloud Build-Trigger wird erstellt, sodass bei jedem Commit für den Master-Zweig von k8s-repo die Kubernetes-Manifeste aus den jeweiligen Ordnern in GKE-Clustern bereitgestellt werden.

Die Ausführung des Terraform-Skripts dauert 40 bis 50 Minuten.

10. Nach Abschluss des Builds im terraform admin project wird ein weiterer Build im Betriebsprojekt gestartet. Klicken Sie auf den angezeigten Link, um die Cloud Build-Seite für ops project zu öffnen, und prüfen Sie, ob der Cloud Build-Vorgang für k8s-repo erfolgreich abgeschlossen wurde.

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

Hinweis: Dieser Build muss abgeschlossen sein, bevor Sie die Istio-Installation überprüfen können.

Installation prüfen

11. Erstellen Sie kubeconfig-Dateien für alle Cluster. Führen Sie das folgende Skript aus.

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

Mit diesem Skript wird im Ordner gke eine neue kubeconfig-Datei mit dem Namen kubemesh erstellt.

12. Ändern Sie die Variable KUBECONFIG so, dass sie auf die neue kubeconfig-Datei verweist.

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

13. Fügen Sie die Variablen „vars.sh“ und „KUBECONFIG“ der Datei „.bashrc“ in Cloud Shell hinzu, damit sie bei jedem Neustart von Cloud Shell abgerufen werden.

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

14. Listen Sie Ihre Clusterkontexte auf. Sie sollten sechs Cluster sehen.

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

Istio-Installation prüfen

15. Prüfen Sie, ob Istio auf beiden Clustern installiert ist. Dazu müssen alle Pods ausgeführt werden und alle Jobs abgeschlossen sein.

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. Prüfen Sie, ob Istio auf beiden dev1-Clustern installiert ist. Nur Citadel, Sidecar-Injektor und CoreDNS werden in den dev1-Clustern ausgeführt. Sie verwenden eine gemeinsame Istio-Steuerungsebene, die im Cluster „ops-1“ ausgeführt wird.

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

17. Prüfen Sie, ob Istio auf beiden dev2-Clustern installiert ist. Nur Citadel, Sidecar-Injektor und CoreDNS werden in den dev2-Clustern ausgeführt. Sie verwenden eine gemeinsame Istio-Steuerungsebene, die im Cluster „ops-2“ ausgeführt wird.

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

Diensterkennung für gemeinsame Steuerungsebenen prüfen

18. Optional können Sie prüfen, ob die Secrets bereitgestellt wurden.

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

In diesem Workshop verwenden Sie eine einzelne freigegebene VPC, in der alle GKE-Cluster erstellt werden. Um Dienste clusterübergreifend zu erkennen, verwenden Sie die kubeconfig-Dateien (für jeden der Anwendungscluster), die als Secrets in den Ops-Clustern erstellt wurden. Pilot verwendet diese Secrets, um Dienste zu ermitteln, indem der Kube API-Server der Anwendungscluster abgefragt wird (authentifiziert über die oben genannten Secrets). Sie sehen, dass sich beide Operations-Cluster mit kubeconfig-erstellten Secrets bei allen App-Clustern authentifizieren können. In Ops-Clustern können Dienste automatisch mithilfe der kubeconfig-Dateien als Secret-Methode erkannt werden. Dazu muss der Pilot in den Betriebsclustern Zugriff auf den Kube API-Server aller anderen Cluster haben. Wenn Pilot die Kube API-Server nicht erreichen kann, müssen Sie Remote-Dienste manuell als ServiceEntries hinzufügen. Sie können sich ServiceEntries als DNS-Einträge in Ihrer Service Registry vorstellen. ServiceEntries definieren einen Dienst anhand eines vollständig qualifizierten DNS-Namens ( FQDN) und einer IP-Adresse, unter der er erreichbar ist. Weitere Informationen finden Sie in der Istio-Dokumentation zu Multicluster.

6. Infrastruktur-Repository

Cloud Build für die Infrastruktur

Die GCP-Ressourcen für den Workshop werden mit Cloud Build und einem infrastructure CSR-Repository erstellt. Sie haben gerade ein Bootstrap-Skript (unter scripts/bootstrap_workshop.sh) über Ihr lokales Terminal ausgeführt. Das Bootstrap-Skript erstellt einen GCP-Ordner, ein Terraform-Administratorprojekt und die entsprechenden IAM-Berechtigungen für das Cloud Build-Dienstkonto. Im Terraform-Administrationsprojekt werden Terraform-Zustände, Logs und verschiedene Skripts gespeichert. Es enthält die CSR-Repos infrastructure und k8s_repo. Diese Repos werden im nächsten Abschnitt ausführlich erläutert. Im Terraform-Administratorprojekt werden keine weiteren Workshop-Ressourcen erstellt. Das Cloud Build-Dienstkonto im Terraform-Administratorprojekt wird verwendet, um Ressourcen für den Workshop zu erstellen.

Eine cloudbuild.yaml-Datei im Ordner infrastructure wird verwendet, um GCP-Ressourcen für den Workshop zu erstellen. Es wird ein benutzerdefiniertes Builder-Image mit allen Tools erstellt, die zum Erstellen von GCP-Ressourcen erforderlich sind. Zu diesen Tools gehören das gcloud SDK, Terraform und andere Dienstprogramme wie Python, Git und JQ. Im benutzerdefinierten Builder-Image werden die terraform plan und apply für jede Ressource ausgeführt. Die Terraform-Dateien für jede Ressource befinden sich in separaten Ordnern (Details im nächsten Abschnitt). Die Ressourcen werden einzeln und in der Reihenfolge erstellt, in der sie normalerweise erstellt werden (z. B. wird ein GCP-Projekt erstellt, bevor die Ressourcen im Projekt erstellt werden). Weitere Informationen finden Sie in der Datei cloudbuild.yaml.

Cloud Build wird jedes Mal ausgelöst, wenn ein Commit an das infrastructure-Repository gesendet wird. Jede Änderung an der Infrastruktur wird als Infrastructure as Code (IaC) gespeichert und im Repository festgeschrieben. Der Status Ihres Workshops wird immer in diesem Repository gespeichert.

Ordnerstruktur – Teams, Umgebungen und Ressourcen

Im Infrastruktur-Repository werden die GCP-Infrastrukturressourcen für den Workshop eingerichtet. Sie ist in Ordner und Unterordner unterteilt. Die Basisordner im Repository stellen die team dar, die bestimmte GCP-Ressourcen enthalten. Die nächste Ebene von Ordnern stellt die spezifische environment für das Team dar (z. B. „dev“, „stage“, „prod“). Die nächste Ebene von Ordnern in der Umgebung stellt die spezifischen resource dar, z. B. „host_project“ oder „gke_clusters“. Die erforderlichen Skripts und Terraform-Dateien sind in den Ressourcenordnern vorhanden.

In diesem Workshop sind die folgenden vier Arten von Teams vertreten:

1. infrastructure: steht für das Cloud-Infrastrukturteam. Sie sind für die Erstellung der GCP-Ressourcen für alle anderen Teams verantwortlich. Sie verwenden das Terraform-Administratorprojekt für ihre Ressourcen. Das Infrastruktur-Repository selbst befindet sich im Terraform-Administratorprojekt, ebenso wie die Terraform-Zustandsdateien (siehe unten). Diese Ressourcen werden während des Bootstrap-Vorgangs durch ein Bash-Skript erstellt (siehe Modul 0 – Administrator-Workflow).
2. network: steht für das Netzwerkteam. Sie sind für VPC- und Netzwerkressourcen verantwortlich. Sie sind Inhaber der folgenden GCP-Ressourcen.
3. host project: Das gemeinsam genutzte VPC-Hostprojekt.
4. shared VPC – stellt die freigegebene VPC, die Subnetze, die sekundären IP-Bereiche, die Routen und die Firewallregeln dar.
5. ops: Steht für das Operations-/DevOps-Team. Sie sind Inhaber der folgenden Ressourcen.
6. ops project: Stellt ein Projekt für alle Betriebsressourcen dar.
7. gke clusters: Ein Operations-GKE-Cluster pro Region. Die Istio-Steuerungsebene ist in jedem der GKE-Cluster für den Betrieb installiert.
8. k8s-repo: Ein CSR-Repository, das GKE-Manifeste für alle GKE-Cluster enthält.
9. apps: Stellt die Anwendungsteams dar. In diesem Workshop werden zwei Teams simuliert: app1 und app2. Sie sind Inhaber der folgenden Ressourcen.
10. app projects: Jedes App-Team erhält eigene Projekte. So können sie die Abrechnung und IAM für ihr spezifisches Projekt steuern.
11. gke clusters: Das sind Anwendungscluster, in denen die Anwendungscontainer bzw. ‑Pods ausgeführt werden.
12. gce instances: optional, wenn sie Anwendungen haben, die auf GCE-Instanzen ausgeführt werden. In diesem Workshop hat app1 einige GCE-Instanzen, auf denen ein Teil der Anwendung ausgeführt wird.

In diesem Workshop stellt dieselbe App (Hipster Shop-App) sowohl app1 als auch app2 dar.

Anbieter, Status und Ausgaben – Back-Ends und gemeinsame Status

Die Anbieter google und google-beta befinden sich unter gcp/[environment]/gcp/provider.tf. Die Datei provider.tf ist in jedem Ressourcenordner symlinked. So können Sie den Anbieter an einem Ort ändern, anstatt Anbieter für jede Ressource einzeln zu verwalten.

Jede Ressource enthält eine backend.tf-Datei, in der der Speicherort für die tfstate-Datei der Ressource definiert ist. Diese backend.tf-Datei wird aus einer Vorlage (unter templates/backend.tf_tmpl) mit einem Skript (unter scripts/setup_terraform_admin_project) generiert und dann in den entsprechenden Ressourcenordner eingefügt. Für Backends werden Google Cloud Storage-Buckets (GCS) verwendet. Der Name des GCS-Bucket-Ordners entspricht dem Ressourcennamen. Alle Ressourcen-Back-Ends befinden sich im Terraform-Administratorprojekt.

Ressourcen mit voneinander abhängigen Werten enthalten eine output.tf-Datei. Die erforderlichen Ausgabewerte werden in der tfstate-Datei gespeichert, die im Backend für diese bestimmte Ressource definiert ist. Wenn Sie beispielsweise einen GKE-Cluster in einem Projekt erstellen möchten, benötigen Sie die Projekt-ID. Die Projekt-ID wird über „output.tf“ in die tfstate-Datei ausgegeben, die über eine terraform_remote_state-Datenquelle in der GKE-Clusterressource verwendet werden kann.

Die Datei „shared_state“ ist eine terraform_remote_state-Datenquelle, die auf die TFState-Datei einer Ressource verweist. In den Ressourcenordnern sind shared_state_[resource_name].tf-Dateien vorhanden, für die Ausgaben von anderen Ressourcen erforderlich sind. Im Ressourcenordner ops_gke sind beispielsweise shared_state-Dateien aus den Ressourcen ops_project und shared_vpc vorhanden, da Sie die Projekt-ID und die VPC-Details benötigen, um GKE-Cluster im Ops-Projekt zu erstellen. Die shared_state-Dateien werden aus einer Vorlage (unter templates/shared_state.tf_tmpl) mit einem Skript (unter scripts/setup_terraform_admin_project) generiert. Die shared_state-Dateien aller Ressourcen werden im Ordner gcp/[environment]/shared_states abgelegt. Die erforderlichen shared_state-Dateien sind in den entsprechenden Ressourcenordnern verlinkt. Wenn Sie alle shared_state-Dateien in einem Ordner ablegen und sie in den entsprechenden Ressourcenordnern verknüpfen, lassen sich alle Statusdateien ganz einfach an einem Ort verwalten.

Variablen

Alle Ressourcenwerte werden als Umgebungsvariablen gespeichert. Diese Variablen werden (als Exportanweisungen) in einer Datei mit dem Namen vars.sh gespeichert, die sich in einem GCS-Bucket im Terraform-Administratorprojekt befindet. Sie enthält die Organisations-ID, das Rechnungskonto, die Projekt-IDs, GKE-Clusterdetails usw. Sie können die vars.sh von einem beliebigen Terminal herunterladen und als Quelle verwenden, um die Werte für Ihre Einrichtung abzurufen.

Terraform-Variablen werden in vars.sh als TF_VAR_[variable name] gespeichert. Diese Variablen werden verwendet, um eine variables.tfvars-Datei im jeweiligen Ressourcenordner zu generieren. Die Datei variables.tfvars enthält alle Variablen mit ihren Werten. Die Datei variables.tfvars wird aus einer Vorlagendatei im selben Ordner mithilfe eines Skripts (unter scripts/setup_terraform_admin_project) generiert.

K8s-Repository erklärt

k8s_repo ist ein CSR-Repository (separat vom Infrastruktur-Repository) im Terraform-Administratorprojekt. Damit werden GKE-Manifeste in allen GKE-Clustern gespeichert und angewendet. k8s_repo wird von der Infrastruktur Cloud Build erstellt (siehe vorheriger Abschnitt). Während des ersten Cloud Build-Prozesses für die Infrastruktur werden insgesamt sechs GKE-Cluster erstellt. Im Ordner k8s_repo werden sechs Ordner erstellt. Jeder Ordner (Name entspricht dem GKE-Clusternamen) entspricht einem GKE-Cluster, der die entsprechenden Ressourcenmanifestdateien enthält. Ähnlich wie beim Erstellen der Infrastruktur wird Cloud Build verwendet, um die Kubernetes-Manifeste mithilfe des k8s_repo auf alle GKE-Cluster anzuwenden. Cloud Build wird jedes Mal ausgelöst, wenn ein Commit an das k8s_repo-Repository gesendet wird. Ähnlich wie bei der Infrastruktur werden alle Kubernetes-Manifeste als Code im k8s_repo-Repository gespeichert und der Status jedes GKE-Clusters wird immer im jeweiligen Ordner gespeichert.

Im Rahmen der anfänglichen Infrastrukturerstellung wird k8s_repo erstellt und Istio wird auf allen Clustern installiert.

Projekte, GKE-Cluster und Namespaces

Die Ressourcen in diesem Workshop sind in verschiedene GCP-Projekte unterteilt. Projekte sollten der Organisations- oder Teamstruktur Ihres Unternehmens entsprechen. Teams in Ihrer Organisation, die für verschiedene Projekte, Produkte oder Ressourcen verantwortlich sind, verwenden unterschiedliche GCP-Projekte. Durch separate Projekte können Sie separate IAM-Berechtigungen erstellen und die Abrechnung auf Projektebene verwalten. Außerdem werden Kontingente auch auf Projektebene verwaltet.

In diesem Workshop sind fünf Teams vertreten, die jeweils ein eigenes Projekt haben.

1. Das Infrastrukturteam, das GCP-Ressourcen erstellt, verwendet Terraform admin project. Sie verwalten die Infrastruktur als Code in einem CSR-Repository (infrastructure) und speichern alle Terraform-Statusinformationen zu Ressourcen, die in GCP erstellt wurden, in GCS-Buckets. Sie steuern den Zugriff auf das CSR-Repository und die GCS-Buckets für den Terraform-Status.
2. Das Netzwerkteam, das die freigegebene VPC erstellt, verwendet die host project. Dieses Projekt enthält die VPC, Subnetze, Routen und Firewallregeln. Mit einer freigegebenen VPC können sie das Netzwerk für GCP-Ressourcen zentral verwalten. Alle Projekte haben dieses eine freigegebene VPC-Netzwerk für die Vernetzung verwendet.
3. Das Betriebs-/Plattformteam, das GKE-Cluster und ASM-/Istio-Steuerungsebenen erstellt, verwendet die ops project. Sie verwalten den Lebenszyklus der GKE-Cluster und des Service Mesh. Sie sind für die Härtung der Cluster sowie für die Verwaltung der Resilienz und Skalierung der Kubernetes-Plattform verantwortlich. In diesem Workshop verwenden Sie die GitOps-Methode zum Bereitstellen von Ressourcen in Kubernetes. Im Betriebsprojekt ist ein CSR-Repository (mit dem Namen k8s_repo) vorhanden.
4. Schließlich verwenden die Teams dev1 und dev2 (die zwei Entwicklungsteams darstellen), die Anwendungen entwickeln, ihre eigenen dev1 und dev2 projects. Das sind die Anwendungen und Dienste, die Sie Ihren Kunden anbieten. Sie basieren auf der Plattform, die vom Betriebsteam verwaltet wird. Die Ressourcen (Bereitstellungen, Dienste usw.) werden an k8s_repo gesendet und in den entsprechenden Clustern bereitgestellt. In diesem Workshop geht es nicht um Best Practices und Tools für CI/CD. Mit Cloud Build automatisieren Sie die Bereitstellung von Kubernetes-Ressourcen direkt in den GKE-Clustern. In realen Produktionsszenarien würden Sie eine geeignete CI/CD-Lösung verwenden, um Anwendungen in GKE-Clustern bereitzustellen.

In diesem Workshop gibt es zwei Arten von GKE-Clustern.

1. Ops-Cluster: Werden vom Ops-Team zum Ausführen von DevOps-Tools verwendet. In diesem Workshop wird die ASM-/Istio-Steuerungsebene ausgeführt, um das Service Mesh zu verwalten.
2. Anwendungscluster – werden von den Entwicklungsteams zum Ausführen von Anwendungen verwendet. In diesem Workshop wird die Hipster Shop-App verwendet.

Durch die Trennung der Betriebs-/Verwaltungstools von den Clustern, auf denen die Anwendung ausgeführt wird, können Sie den Lebenszyklus jeder Ressource unabhängig verwalten. Die beiden Arten von Clustern sind auch in verschiedenen Projekten für das Team/Produkt vorhanden, das sie verwendet. Dadurch lassen sich IAM-Berechtigungen einfacher verwalten.

Es gibt insgesamt sechs GKE-Cluster. Im Operations-Projekt werden zwei regionale Operations-Cluster erstellt. Die ASM-/Istio-Steuerungsebene ist in beiden Betriebsclustern installiert. Jeder Operations-Cluster befindet sich in einer anderen Region. Außerdem gibt es vier zonale Anwendungscluster. Sie werden in eigenen Projekten erstellt. In diesem Workshop werden zwei Entwicklungsteams mit jeweils eigenen Projekten simuliert. Jedes Projekt enthält zwei App-Cluster. App-Cluster sind zonale Cluster in verschiedenen Zonen. Die vier App-Cluster befinden sich in zwei Regionen und vier Zonen. So erhalten Sie regionale und zonale Redundanz.

Die in diesem Workshop verwendete Anwendung, die Hipster Shop-App, wird in allen vier App-Clustern bereitgestellt. Jeder Mikrodienst befindet sich in seinem eigenen Namespace in jedem App-Cluster. Die Deployments (Pods) der Hipster Shop-Anwendung werden nicht in den Ops-Clustern bereitgestellt. Die Namespaces und Dienstressourcen für alle Mikrodienste werden jedoch auch in den Ops-Clustern erstellt. Die ASM-/Istio-Steuerungsebene verwendet die Kubernetes-Dienstregistrierungen für die Dienstermittlung. Wenn keine Services in den Operations-Clustern vorhanden sind, müssen Sie ServiceEntries für jeden Dienst, der im App-Cluster ausgeführt wird, manuell erstellen.

In diesem Workshop stellen Sie eine aus 10 Mikrodiensten bestehende Anwendung bereit. Die Anwendung ist eine webbasierte E-Commerce-App namens Hipster Shop, mit der Nutzer Artikel suchen, sie in den Einkaufswagen legen und dann kaufen können.

Kubernetes-Manifeste und k8s_repo

Mit k8s_repo fügen Sie allen GKE-Clustern Kubernetes-Ressourcen hinzu. Dazu kopieren Sie Kubernetes-Manifeste und committen sie in das k8s_repo. Alle Commits für k8s_repo lösen einen Cloud Build-Job aus, der die Kubernetes-Manifeste im jeweiligen Cluster bereitstellt. Das Manifest jedes Clusters befindet sich in einem separaten Ordner mit demselben Namen wie der Clustername.

Die sechs Clusternamen sind:

1. gke-asm-1-r1-prod: Der regionale Ops-Cluster in Region 1
2. gke-asm-2-r2-prod: Der regionale Ops-Cluster in Region 2
3. gke-1-apps-r1a-prod: Der App-Cluster in Zone a von Region 1
4. gke-2-apps-r1b-prod: Der App-Cluster in Zone b der Region 1
5. gke-3-apps-r2a-prod: Der App-Cluster in Zone a von Region 2
6. gke-4-apps-r2b-prod: Der App-Cluster in Zone b von Region 2

Der Ordner k8s_repo enthält Ordner, die diesen Clustern entsprechen. Alle Manifeste, die in diesen Ordnern abgelegt werden, werden auf den entsprechenden GKE-Cluster angewendet. Manifeste für jeden Cluster werden zur einfacheren Verwaltung in Unterordnern (im Hauptordner des Clusters) abgelegt. In diesem Workshop verwenden Sie Kustomize, um den Überblick über die bereitgestellten Ressourcen zu behalten. Weitere Informationen finden Sie in der offiziellen Kustomize-Dokumentation.

7. Beispiel-App bereitstellen

Ziel: Hipster Shop-App in App-Clustern bereitstellen

• Klon k8s-repo
• Hipster Shop-Manifeste in alle App-Cluster kopieren
• Dienste für die Hipster Shop-App in den Ops-Clustern erstellen
• loadgenerators in den Ops-Clustern einrichten, um die globale Konnektivität zu testen
• Sichere Verbindung zur Hipster Shop-App prüfen

FAST TRACK SCRIPT

Wenn Sie sich für diese Methode entscheiden, führen Sie das folgende Skript aus, um dieses Lab abzuschließen.

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

Lab-Anleitung für die Copy-and-Paste-Methode

Wenn Sie das Fast-Track-Script für dieses Lab bereits ausgeführt haben, führen Sie die Copy-and-Paste-Methode unten nicht aus**.**

Quell-Repository des Betriebsprojekts klonen

Im Rahmen des ersten Terraform-Infrastruktur-Builds wird k8s-repo bereits im Ops-Projekt erstellt.

1. Erstellen Sie ein leeres Verzeichnis für das Git-Repository:

mkdir $WORKDIR/k8s-repo
 

2. Git-Repository initialisieren, Remote-Repository hinzufügen und Master-Branch aus dem Remote-Repository abrufen:

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. Lokale Git-Konfiguration festlegen

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

Manifeste kopieren, Änderungen committen und pushen

4. Kopieren Sie die Hipster Shop-Namespaces und -Dienste in das Quell-Repository für alle Cluster.

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. Kopieren Sie die Datei „kustomization.yaml“ des App-Ordners in alle Cluster.

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. Kopieren Sie die Hipster Shop-Bereitstellungen, RBAC und PodSecurityPolicy in das Quell-Repository für die App-Cluster.

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. Entfernen Sie das cartservice-Deployment, RBAC und die PodSecurityPolicy aus allen Entwicklerclustern bis auf einen. Hipstershop wurde nicht für die Bereitstellung in mehreren Clustern entwickelt. Um inkonsistente Ergebnisse zu vermeiden, verwenden wir daher nur einen cartservice.

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

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

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

8. Fügen Sie die cartservice-Bereitstellung, RBAC und podsecuritypolicy nur im ersten Entwicklungscluster zu kustomization.yaml hinzu.

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. Entfernen Sie die Verzeichnisse „podsecuritypolicies“, „deployments“ und „rbac“ aus der Datei „kustomization.yaml“ der Ops-Cluster.

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. Ersetzen Sie die PROJECT_ID in den RBAC-Manifesten.

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. Kopieren Sie die IngressGateway- und VirtualService-Manifeste in das Quell-Repository für die Operations-Cluster.

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. Kopieren Sie die Config Connector-Ressourcen in einen der Cluster in jedem Projekt.

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. Ersetzen Sie die PROJECT_ID in den Config Connector-Manifesten.

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. Kopieren Sie loadgenerator-Manifeste (Deployment, PodSecurityPolicy und RBAC) in die Ops-Cluster. Die Hipster Shop-App wird über einen globalen Google Cloud Load Balancer (GCLB) bereitgestellt. Der GCLB empfängt Clienttraffic (der für frontend bestimmt ist) und sendet ihn an die nächstgelegene Instanz des Dienstes. Wenn Sie loadgenerator in beiden Operations-Clustern platzieren, wird der Traffic an beide Istio-Ingress-Gateways gesendet, die in den Operations-Clustern ausgeführt werden. Das Load-Balancing wird im folgenden Abschnitt ausführlich erläutert.

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. Ersetzen Sie die ID des Operations-Projekts in den loadgenerator-Manifesten für beide Operations-Cluster.

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. Fügen Sie die loadgenerator-Ressourcen für beide Betriebscluster zu kustomization.yaml hinzu.

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. Verpflichte dich zu 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. Sehen Sie sich den Status des Cloud Build-Vorgangs für das Ops-Projekt auf einem zuvor geöffneten Tab oder über den folgenden Link an:

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

Anwendungsbereitstellung überprüfen

19. Prüfen Sie, ob sich die Pods in allen Anwendungs-Namespaces mit Ausnahme von „cart“ in allen Entwicklerclustern im Status „Wird ausgeführt“ befinden.

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. Prüfen Sie, ob sich die Pods im Warenkorb-Namespace nur im ersten Entwicklungscluster im Status „Wird ausgeführt“ befinden.

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

Auf die Hipster Shop-Anwendung zugreifen

Globales Load-Balancing

Die Hipster Shop-App ist jetzt in allen vier App-Clustern bereitgestellt. Diese Cluster befinden sich in zwei Regionen und vier Zonen. Clients können auf die Hipster Shop-App zugreifen, indem sie auf den Dienst frontend zugreifen. Der frontend-Dienst wird in allen vier App-Clustern ausgeführt. Ein Google Cloud Load Balancer ( GCLB) wird verwendet, um Client-Traffic an alle vier Instanzen des frontend-Dienstes weiterzuleiten.

Istio-Ingress-Gateways werden nur in den Ops-Clustern ausgeführt und fungieren als regionaler Load Balancer für die beiden zonenbasierten Anwendungscluster in der Region. GCLB verwendet die beiden Istio-Ingress-Gateways (die in den beiden Operations-Clustern ausgeführt werden) als Back-Ends für den globalen Frontend-Dienst. Die Istio-Ingress-Gateways empfangen den Client-Traffic von der GCLB und leiten ihn dann an die Frontend-Pods weiter, die in den Anwendungsclustern ausgeführt werden.

Alternativ können Sie Istio-Ingress-Gateways direkt in den Anwendungsclustern platzieren und der GCLB kann diese als Back-Ends verwenden.

GKE Autoneg Controller

Der Istio Ingress-Gateway-Kubernetes-Dienst registriert sich als Back-End für den GCLB mithilfe von Netzwerk-Endpunktgruppen (NEGs). NEGs ermöglichen containernatives Load-Balancing mit GCLBs. NEGs werden über eine spezielle Annotation für einen Kubernetes-Dienst erstellt, damit er sich beim NEG-Controller registrieren kann. Der Autoneg-Controller ist ein spezieller GKE-Controller, der die Erstellung von NEGs automatisiert und sie mithilfe von Dienstannotationen als Backends einem GCLB zuweist. Istio-Steuerungsebenen, einschließlich der Istio-Ingress-Gateways, werden während des ersten Terraform Cloud Build für die Infrastruktur bereitgestellt. Die Konfiguration von GCLB und Autoneg erfolgt im Rahmen des ersten Cloud Build-Vorgangs für die Terraform-Infrastruktur.

Eingang mit Cloud Endpoints und verwalteten Zertifikaten sichern

Von GCP verwaltete Zertifikate werden verwendet, um den Client-Traffic zum frontend-GCLB-Dienst zu sichern. GCLB verwendet verwaltete Zertifikate für den globalen frontend-Dienst und das Zertifikat wird am GCLB beendet. In diesem Workshop verwenden Sie Cloud Endpoints als Domain für das verwaltete Zertifikat. Alternativ können Sie Ihre Domain und einen DNS-Namen für die frontend verwenden, um von GCP verwaltete Zertifikate zu erstellen.

21. Klicken Sie auf den Link, der als Ausgabe des folgenden Befehls angezeigt wird, um auf den Hipster Shop zuzugreifen.

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

22. Sie können die Gültigkeit des Zertifikats prüfen, indem Sie in der URL-Leiste Ihres Chrome-Tabs auf das Schloss-Symbol klicken.

Globales Load-Balancing prüfen

Im Rahmen der Anwendungsbereitstellung wurden in beiden Ops-Clustern Lastgeneratoren bereitgestellt, die Test-Traffic für den GCLB-Link für Cloud Endpoints für den Hipster Shop generieren. Prüfen Sie, ob der GCLB Traffic empfängt und an beide Istio-Ingress-Gateways sendet.

23. Rufen Sie den Link GCLB > Monitoring für das Betriebsprojekt ab, in dem die GCLB für den Hipster-Shop erstellt wurde.

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. Ändern Sie im Drop-down-Menü „Backend“ die Auswahl von Alle Backends zu istio-ingressgateway, wie unten dargestellt.

25. Beachten Sie den Traffic an beide istio-ingressgateways.

Pro istio-ingressgateway werden drei NEGs erstellt. Da die Operations-Cluster regionale Cluster sind, wird für jede Zone in der Region eine NEG erstellt. Die istio-ingressgateway-Pods werden jedoch in einer einzelnen Zone pro Region ausgeführt. Der Traffic wird an die istio-ingressgateway-Pods weitergeleitet.

Load-Generatoren werden in beiden Operations-Clustern ausgeführt und simulieren Clienttraffic aus den beiden Regionen, in denen sie sich befinden. Die in der Region 1 des Betriebsclusters generierte Last wird an istio-ingressgateway in Region 2 gesendet. Ebenso wird die in der Region 2 des Ops-Clusters generierte Last an istio-ingressgateway in Region 2 gesendet.

8. Beobachtbarkeit mit Stackdriver

Ziel: Istio-Telemetrie mit Stackdriver verbinden und validieren.

• istio-telemetry-Ressourcen installieren
• Dashboards für Istio-Dienste erstellen/aktualisieren
• Containerlogs ansehen
• Verteiltes Tracing in Stackdriver ansehen

FAST TRACK SCRIPT

Wenn Sie sich für diese Methode entscheiden, führen Sie das folgende Skript aus, um dieses Lab abzuschließen.

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

Lab-Anleitung für die Copy-and-Paste-Methode

Wenn Sie das Fast-Track-Script für dieses Lab bereits ausgeführt haben, führen Sie die Copy-and-Paste-Methode unten nicht aus**.**

Eines der wichtigsten Features von Istio ist die integrierte Observability („o11y“). Das bedeutet, dass Operatoren auch bei Blackbox-Containern ohne Instrumentierung den Traffic, der in diese Container ein- und aus ihnen herausgeht, beobachten können, um Kunden Dienste bereitzustellen. Das geschieht auf verschiedene Arten: Messwerte, Logs und Traces.

Wir verwenden auch das integrierte System zur Generierung von Last in Hipster Shop. Die Observability funktioniert in einem statischen System ohne Traffic nicht sehr gut. Durch die Lastgenerierung können wir sehen, wie sie funktioniert. Dieser Ladevorgang läuft bereits. Wir können ihn jetzt nur sehen.

1. Installieren Sie die Konfigurationsdatei „istio-to-stackdriver“.

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

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

2. Übernehmen Sie die Änderungen für das K8s-Repository.

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

3. Sehen Sie sich den Status des Cloud Build-Vorgangs für das Ops-Projekt auf einem zuvor geöffneten Tab oder über den folgenden Link an:

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

4. Istio → Stackdriver-Integration prüfen Rufen Sie die CRD für den Stackdriver-Handler ab.

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

Die Ausgabe sollte einen Handler mit dem Namen „stackdriver“ enthalten:

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

5. Prüfen Sie, ob der Export von Istio-Messwerten nach Stackdriver funktioniert. Klicken Sie auf den Link, der von diesem Befehl ausgegeben wird:

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

Sie werden aufgefordert, einen neuen Arbeitsbereich zu erstellen, der nach dem Ops-Projekt benannt ist. Wählen Sie einfach „OK“ aus. Wenn Sie aufgefordert werden, die neue Benutzeroberfläche zu verwenden, schließen Sie das Dialogfeld einfach.

Geben Sie im Messwert-Explorer unter „Ressourcentyp und Messwert finden“ istio ein, um Optionen wie „Anzahl der Serveranfragen“ für den Ressourcentyp „Kubernetes-Container“ aufzurufen. Das zeigt, dass die Messwerte vom Mesh in Stackdriver übertragen werden.

Wenn Sie die folgenden Zeilen sehen möchten, müssen Sie nach dem Label destination_service_name gruppieren.

Messwerte mit Dashboards visualisieren:

Nachdem unsere Messwerte im Stackdriver APM-System sind, möchten wir sie visualisieren. In diesem Abschnitt installieren wir ein vorgefertigtes Dashboard, auf dem drei der vier Golden Signals-Messwerte zu sehen sind: Traffic (Anfragen pro Sekunde), Latenz (in diesem Fall das 99. und 50. Perzentil) und Fehler (Sättigung wird in diesem Beispiel ausgeschlossen).

Der Envoy-Proxy von Istio bietet uns mehrere Messwerte, aber diese sind ein guter Anfang. Eine vollständige Liste finden Sie hier. Jeder Messwert hat eine Reihe von Labels, die zum Filtern und Aggregieren verwendet werden können, z. B. „destination_service“, „source_workload_namespace“, „response_code“ und „istio_tcp_received_bytes_total“.

6. Fügen wir nun die vordefinierten Messwerte zum Dashboard hinzu. Wir werden die Dashboard API direkt verwenden. Normalerweise würden Sie API-Aufrufe nicht manuell generieren. Das wäre Teil eines Automatisierungssystems oder Sie würden das Dashboard manuell in der Web-UI erstellen. So können wir schnell loslegen:

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. Klicken Sie auf den Ausgabelink unten, um das neu hinzugefügte „Services-Dashboard“ aufzurufen.

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

Wir könnten das Dashboard direkt über die Benutzeroberfläche bearbeiten, aber in unserem Fall fügen wir schnell ein neues Diagramm über die API hinzu. Dazu müssen Sie die aktuelle Version des Dashboards herunterladen, Ihre Änderungen vornehmen und es dann mit der HTTP-PATCH-Methode wieder hochladen.

8. Sie können ein vorhandenes Dashboard abrufen, indem Sie die Monitoring API abfragen. Rufen Sie das vorhandene Dashboard ab, das gerade hinzugefügt wurde:

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. Neues Diagramm hinzufügen (50. Perzentil der Latenz): [ API-Referenz] Jetzt können wir unserem Dashboard im Code ein neues Diagramm-Widget hinzufügen. Diese Änderung kann von Kollegen überprüft und in die Versionsverwaltung eingecheckt werden. Hier ist ein Widget, das Sie hinzufügen können und das die Latenz des 50. Perzentils (Medianlatenz) anzeigt.

Bearbeiten Sie das gerade erstellte Dashboard und fügen Sie einen neuen Abschnitt hinzu:

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. Vorhandenes Dienstleistungs-Dashboard aktualisieren:

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. Rufen Sie das aktualisierte Dashboard über den folgenden Ausgabelink auf:

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

12. Führen Sie eine einfache Loganalyse durch.

Istio bietet eine Reihe von strukturierten Logs für den gesamten Netzwerkverkehr im Mesh und lädt sie in Stackdriver Logging hoch, um clusterübergreifende Analysen in einem leistungsstarken Tool zu ermöglichen. Logs werden mit Metadaten auf Dienstebene wie Cluster, Container, App und connection_id versehen.

Ein Beispiel für einen Logeintrag (in diesem Fall das Envoy-Proxy-Zugriffsprotokoll) könnte so aussehen (gekürzt):

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

So rufen Sie Ihre Logs auf:

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

Sie können die Logs der Istio-Steuerungsebene aufrufen, indem Sie „Ressource“ > „Kubernetes-Container“ auswählen und nach „Pilot“ suchen:

Hier sehen wir, wie die Istio-Steuerungsebene die Proxykonfiguration an die Sidecar-Proxys für jeden Beispiel-App-Dienst überträgt. „CDS“, „LDS“ und „RDS“ stehen für verschiedene Envoy-APIs ( weitere Informationen).

Neben den Istio-Logs finden Sie in derselben Benutzeroberfläche auch Containerlogs sowie Infrastruktur- oder andere GCP-Dienstlogs. Hier finden Sie einige Beispielabfragen für Logs für GKE. Mit dem Log-Viewer können Sie auch Messwerte aus Logs erstellen, z. B. „Zähle jeden Fehler, der mit einem bestimmten String übereinstimmt“. Diese Messwerte können in einem Dashboard oder als Teil einer Benachrichtigung verwendet werden. Logs können auch in andere Analysetools wie BigQuery gestreamt werden.

Einige Beispielfilter für ein Hipster-Geschäft:

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

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

13. Weitere Informationen finden Sie unter „Verteilte Traces“.

Da Sie jetzt mit einem verteilten System arbeiten, benötigen Sie für das Debugging ein neues Tool: Verteiltes Tracing. Mit diesem Tool können Sie Statistiken zur Interaktion Ihrer Dienste abrufen, z. B. langsame Ereignisse, die aus dem Rahmen fallen (siehe Abbildung unten). Außerdem können Sie sich Rohdaten von Beispiel-Traces ansehen, um die Details der Vorgänge zu untersuchen.

In der Zeitachse werden alle Anfragen im Zeitverlauf dargestellt, wobei die Latenz oder die Zeit zwischen der ursprünglichen Anfrage über den Hipster-Stack bis zur endgültigen Antwort an den Endnutzer grafisch dargestellt wird. Je weiter oben die Punkte sind, desto langsamer ist die Nutzererfahrung und desto unzufriedener sind die Nutzer.

Wenn Sie auf einen Punkt klicken, wird die detaillierte Wasserfallansicht für die entsprechende Anfrage angezeigt. Diese Möglichkeit, die Rohdaten einer bestimmten Anfrage zu finden (nicht nur aggregierte Statistiken), ist entscheidend, um das Zusammenspiel zwischen Diensten zu verstehen, insbesondere wenn Sie nach seltenen, aber schlechten Interaktionen zwischen Diensten suchen.

Die Wasserfallansicht sollte jedem vertraut sein, der schon einmal einen Debugger verwendet hat. In diesem Fall wird jedoch nicht die Zeit angezeigt, die in verschiedenen Prozessen einer einzelnen Anwendung verbracht wurde, sondern die Zeit, die für das Durchlaufen unseres Mesh zwischen Diensten benötigt wird, die in separaten Containern ausgeführt werden.

So finden Sie Ihre Routen:

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

Beispiel-Screenshot des Tools:

9. Gegenseitige TLS-Authentifizierung

Ziel: Sichere Verbindung zwischen Mikrodiensten (AuthN).

• Mesh-weites mTLS aktivieren
• mTLS anhand von Logs prüfen

FAST TRACK SCRIPT

Wenn Sie sich für diese Methode entscheiden, führen Sie das folgende Skript aus, um dieses Lab abzuschließen.

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

Lab-Anleitung für die Copy-and-Paste-Methode

Wenn Sie das Fast-Track-Script für dieses Lab bereits ausgeführt haben, führen Sie die Copy-and-Paste-Methode unten nicht aus**.**

Nachdem unsere Apps installiert und die Observability eingerichtet ist, können wir mit der Sicherung der Verbindungen zwischen den Diensten beginnen und dafür sorgen, dass alles weiterhin funktioniert.

Auf dem Kiali-Dashboard sehen wir beispielsweise, dass unsere Dienste kein MTLS verwenden (kein Schloss-Symbol). Der Verkehr fließt und das System funktioniert einwandfrei. Unser Stackdriver-Dashboard mit den wichtigsten Messwerten gibt uns die Gewissheit, dass alles im Großen und Ganzen funktioniert.

1. Prüfen Sie MeshPolicy in Operations-Clustern. mTLS ist PERMISSIVE, sodass sowohl verschlüsselter als auch nicht-mTLS-Traffic möglich ist.

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 wird auf allen Clustern mit dem Istio-Operator konfiguriert, der die benutzerdefinierte Ressource (Custom Resource, CR) „IstioControlPlane“ verwendet. Wir konfigurieren mTLS in allen Clustern, indem wir die IstioControlPlane-CR aktualisieren und das k8s-Repo aktualisieren. Wenn Sie in der IstioControlPlane-CR „global > mTLS > enabled: true“ festlegen, führt dies zu den folgenden beiden Änderungen an der Istio-Steuerungsebene:

• MeshPolicy ist so festgelegt, dass mTLS mesh-weit für alle Dienste aktiviert wird, die in allen Clustern ausgeführt werden.
• Es wird eine DestinationRule erstellt, um ISTIO_MUTUAL-Traffic zwischen Diensten zu ermöglichen, die in allen Clustern ausgeführt werden.

2. Wir wenden einen Kustomize-Patch auf die CR „istioControlPlane“ an, um mTLS clusterweit zu aktivieren. Kopieren Sie den Patch in das entsprechende Verzeichnis für alle Cluster und fügen Sie einen Kustomize-Patch hinzu.

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. Übernehmen Sie die Änderungen für das K8s-Repository.

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

4. Sehen Sie sich den Status des Cloud Build-Vorgangs für das Ops-Projekt auf einem zuvor geöffneten Tab oder über den folgenden Link an:

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

 

mTLS überprüfen

5. MeshPolicy noch einmal in Betriebsclustern prüfen. Hinweis: mTLS ist nicht mehr PERMISSIVE und lässt nur noch mTLS-Traffic zu.

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

Ausgabe (nicht kopieren):

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

6. Beschreiben Sie die vom Istio-Operator-Controller erstellte DestinationRule.

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'

Ausgabe (nicht kopieren):

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

Die Migration von HTTP zu HTTPS ist ebenfalls in den Logs zu sehen.

Wir können dieses Feld aus den Logs in der Benutzeroberfläche verfügbar machen, indem wir auf einen Logeintrag und dann auf den Wert des Felds klicken, das wir anzeigen möchten. In diesem Fall klicken wir neben „protocol“ auf „http“:

So lässt sich die Umstellung gut visualisieren:

10. Canary-Deployments

Ziel: Eine neue Version des Frontend-Dienstes bereitstellen.

• Roll-out von frontend-v2 (nächste Produktionsversion) in einer Region
• Traffic mit DestinationRules und VirtualServices langsam zu frontend-v2 leiten
• GitOps-Bereitstellungspipeline prüfen, indem Sie eine Reihe von Commits für k8s-repo untersuchen

FAST TRACK SCRIPT

Wenn Sie sich für diese Methode entscheiden, führen Sie das folgende Skript aus, um dieses Lab abzuschließen.

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

Lab-Anleitung für die Copy-and-Paste-Methode

Wenn Sie das Fast-Track-Script für dieses Lab bereits ausgeführt haben, führen Sie die Copy-and-Paste-Methode unten nicht aus**.**

Ein Canary-Deployment ist ein schrittweises Rollout eines neuen Dienstes. Bei einer Canary-Bereitstellung wird eine zunehmende Menge an Traffic an die neue Version gesendet, während der verbleibende Prozentsatz weiterhin an die aktuelle Version gesendet wird. Ein gängiges Muster ist, in jeder Phase der Traffic-Aufteilung eine Canary-Analyse durchzuführen und die „Golden Signals“ der neuen Version (Latenz, Fehlerrate, Sättigung) mit einer Baseline zu vergleichen. So lassen sich Ausfälle vermeiden und die Stabilität des neuen Dienstes „v2“ in jeder Phase der Trafficaufteilung sicherstellen.

In diesem Abschnitt erfahren Sie, wie Sie mit Cloud Build und Istio-Traffic-Richtlinien eine einfache Canary-Bereitstellung für eine neue Version des frontend-Dienstes erstellen.

Zuerst führen wir die Canary-Pipeline in der DEV1-Region (us-west1) aus und stellen Frontend v2 in beiden Clustern in dieser Region bereit. Als Nächstes führen wir die Canary-Pipeline in der DEV2-Region (us-central) aus und stellen Version 2 auf beiden Clustern in dieser Region bereit. Wenn Sie die Pipeline in der Reihenfolge der Regionen ausführen und nicht parallel in allen Regionen, können Sie globale Ausfälle vermeiden, die durch eine fehlerhafte Konfiguration oder durch Fehler in der V2-App selbst verursacht werden.

Hinweis: Wir lösen die Canary-Pipeline in beiden Regionen manuell aus. In der Produktion würden Sie jedoch einen automatisierten Trigger verwenden, z. B. basierend auf einem neuen Docker-Image-Tag, das in eine Registry übertragen wird.

1. Definieren Sie in Cloud Shell einige Umgebungsvariablen, um die Ausführung der restlichen Befehle zu vereinfachen.

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

2. Führen Sie das Script „repo_setup.sh“ aus, um die Baseline-Manifeste in „k8s-repo“ zu kopieren.

$CANARY_DIR/repo-setup.sh 
 

Die folgenden Manifeste werden kopiert:

• frontend-v2-Deployment
• frontend-v1-Patch (mit dem Label „v1“ und einem Bild mit einem „/version“-Endpunkt)
• respy, ein kleiner Pod, der die Verteilung der HTTP-Antworten ausgibt und uns hilft, die Canary-Bereitstellung in Echtzeit zu visualisieren.
• Frontend-Istio-DestinationRule: Teilt den Frontend-Kubernetes-Dienst anhand des Bereitstellungslabels „version“ in zwei Teilmengen auf: v1 und v2.
• Frontend-Istio-VirtualService: leitet 100% des Traffics an Frontend v1 weiter. Dadurch wird das standardmäßige Round-Robin-Verhalten des Kubernetes-Dienstes überschrieben, bei dem sofort 50% des gesamten regionalen Dev1-Traffics an Frontend v2 gesendet würden.

3. Änderungen an k8s_repo übertragen:

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

4. Sehen Sie sich den Status des Cloud Build-Vorgangs für das Ops-Projekt auf einem zuvor geöffneten Tab oder über den folgenden Link an:

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

5. Rufen Sie in der Console Cloud Build für das OPS1-Projekt auf. Warten Sie, bis die Cloud Build-Pipeline abgeschlossen ist, und rufen Sie dann die Pods im Frontend-Namespace in beiden DEV1-Clustern ab. Sie sollten Folgendes sehen:

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

Hinweis: Drücken Sie Strg + C, um die watch-Befehle zu beenden.

Wir verwenden tmux, um das Cloud Shell-Fenster in zwei Bereiche aufzuteilen:

• Im unteren Bereich wird der Befehl „watch“ ausgeführt, um die Verteilung der HTTP-Antworten für den Frontend-Dienst zu beobachten.
• Im oberen Bereich wird das eigentliche Canary-Pipeline-Script ausgeführt.

6. Führen Sie den Befehl aus, um das Cloud Shell-Fenster zu teilen und den Watch-Befehl im unteren Bereich auszuführen.

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"
 

Ausgabe (nicht kopieren)

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

Wir sehen, dass der gesamte Traffic an die Frontend-Bereitstellung v1 geht, die im neuen VirtualService definiert ist.

7. Führen Sie die Canary-Pipeline in der Region „Dev1“ aus. Wir stellen ein Skript bereit, mit dem die Trafficprozentsätze für frontend-v2 im VirtualService aktualisiert werden (die Gewichte werden auf 20%, 50%, 80 % und dann 100 % aktualisiert). Zwischen den Updates wartet das Skript, bis die Cloud Build-Pipeline abgeschlossen ist. Führen Sie das Canary-Deployment-Skript für die Dev1-Region aus. Hinweis: Die Ausführung dieses Skripts dauert etwa 10 Minuten.

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

Die Aufteilung des Traffics wird in Echtzeit im unteren Fenster angezeigt, in dem Sie den respy-Befehl ausführen. Beispiel: Bei 20 %

Ausgabe (nicht kopieren)

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

8. Wenn das Dev2-Roll-out für frontend-v2 abgeschlossen ist, sollte am Ende des Skripts eine Erfolgsmeldung angezeigt werden:

    Output (do not copy) 
   

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

9. Der gesamte Frontend-Traffic von einem Dev2-Pod sollte an frontend-v2 gesendet werden:

    Output (do not copy) 
   

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

10. Schließen Sie den geteilten Bereich.

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

11. Rufen Sie Cloud Source Repositories über den generierten Link auf.

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

Für jeden Traffic-Prozentsatz sollte ein separater Commit angezeigt werden. Der letzte Commit steht oben in der Liste:

Wiederholen Sie nun denselben Vorgang für die Dev2-Region. Die Dev2-Region ist weiterhin auf Version 1 „gesperrt“. Das liegt daran, dass im Baseline-Skript „repo_setup“ ein VirtualService übertragen wurde, um den gesamten Traffic explizit an v1 zu senden. So konnten wir auf Dev1 einen regionalen Canary-Test durchführen und sicherstellen, dass er erfolgreich ausgeführt wurde, bevor wir die neue Version weltweit eingeführt haben.

12. Führen Sie den Befehl aus, um das Cloud Shell-Fenster zu teilen und den Watch-Befehl im unteren Bereich auszuführen.

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"
 

Ausgabe (nicht kopieren)

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

Wir sehen, dass der gesamte Traffic an die Frontend-Bereitstellung v1 geht, die im neuen VirtualService definiert ist.

13. Führen Sie die Canary-Pipeline in der Dev2-Region aus. Wir stellen ein Skript bereit, mit dem die Trafficprozentsätze für frontend-v2 im VirtualService aktualisiert werden (die Gewichte werden auf 20%, 50%, 80 % und dann 100 % aktualisiert). Zwischen den Updates wartet das Skript, bis die Cloud Build-Pipeline abgeschlossen ist. Führen Sie das Canary-Deployment-Skript für die Dev1-Region aus. Hinweis: Die Ausführung dieses Skripts dauert etwa 10 Minuten.

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

Ausgabe (nicht kopieren)

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

14. Beobachten Sie im Respy-Pod in Dev2, wie der Traffic von Dev2-Pods schrittweise von Frontend v1 zu v2 wechselt. Wenn das Skript abgeschlossen ist, sollten Sie Folgendes sehen:

Ausgabe (nicht kopieren)

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

15. Schließen Sie den geteilten Bereich.

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

In diesem Abschnitt wurde beschrieben, wie Sie Istio für regionale Canary-Bereitstellungen verwenden. In der Produktion können Sie dieses Canary-Skript anstelle eines manuellen Skripts automatisch als Cloud Build-Pipeline auslösen. Verwenden Sie dazu einen Trigger, z. B. ein neues getaggtes Image, das in eine Container-Registry übertragen wird. Außerdem sollten Sie zwischen den einzelnen Schritten eine Canary-Analyse einfügen, um die Latenz und Fehlerrate von Version 2 anhand eines vordefinierten Sicherheitsschwellenwerts zu analysieren, bevor Sie mehr Traffic senden.

11. Autorisierungsrichtlinien

Ziel: RBAC zwischen Mikrodiensten einrichten (AuthZ).

• AuthorizationPolicy erstellen, um den Zugriff auf einen Mikrodienst zu VERWEIGERN
• AuthorizationPolicy erstellen, um bestimmten Zugriff auf einen Mikrodienst ZU LASSEN

FAST TRACK SCRIPT

Wenn Sie sich für diese Methode entscheiden, führen Sie das folgende Skript aus, um dieses Lab abzuschließen.

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

Lab-Anleitung für die Copy-and-Paste-Methode

Wenn Sie das Fast-Track-Script für dieses Lab bereits ausgeführt haben, führen Sie die Copy-and-Paste-Methode unten nicht aus**.**

Im Gegensatz zu einer monolithischen Anwendung, die an einem Ort ausgeführt werden kann, senden global verteilte Mikrodienstanwendungen Aufrufe über Netzwerkgrenzen hinweg. Dies bedeutet mehr Einstiegspunkte in Ihre Anwendungen und mehr Möglichkeiten für bösartige Angriffe. Da Kubernetes-Pods temporäre IP-Adressen haben, sind herkömmliche IP-basierte Firewallregeln nicht für den sicheren Zugriff zwischen Arbeitslasten geeignet. In einer Mikrodienstarchitektur ist ein neuer Sicherheitsansatz erforderlich. Istio baut auf Kubernetes-Sicherheitsbausteinen wie Dienstkonten auf und bietet eine flexible Reihe von Sicherheitsrichtlinien für Ihre Anwendungen.

Istio-Richtlinien decken sowohl die Authentifizierung als auch die Autorisierung ab. Bei der Authentifizierung wird die Identität überprüft (ist dieser Server der, für den er sich ausgibt?). Bei der Autorisierung werden Berechtigungen überprüft (darf dieser Client das tun?). Wir haben die Istio-Authentifizierung im Abschnitt zur gegenseitigen TLS-Authentifizierung in Modul 1 (MeshPolicy) behandelt. In diesem Abschnitt erfahren Sie, wie Sie Istio-Autorisierungsrichtlinien verwenden, um den Zugriff auf eine unserer Anwendungsarbeitslasten, currencyservice, zu steuern.

Zuerst stellen wir eine AuthorizationPolicy in allen vier Entwicklungsclustern bereit. Dadurch wird der gesamte Zugriff auf den Währungsservice gesperrt und im Frontend wird ein Fehler ausgelöst. Anschließend erlauben wir nur dem Frontend-Dienst den Zugriff auf „currencyservice“.

1. Prüfen Sie den Inhalt von currency-deny-all.yaml. In dieser Richtlinie werden Selektoren für Bereitstellungs-Labels verwendet, um den Zugriff auf den Währungsservice einzuschränken. Beachten Sie, dass es kein spec-Feld gibt. Das bedeutet, dass diese Richtlinie den gesamten Zugriff auf den ausgewählten Dienst verweigert.

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

Ausgabe (nicht kopieren)

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

2. Kopieren Sie die Währungsrichtlinie in das K8s-Repository für die Betriebscluster in beiden Regionen.

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. Änderungen per Push übertragen

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

4. Prüfen Sie den Status des Cloud Build-Vorgangs für das Ops-Projekt auf einem zuvor geöffneten Tab oder indem Sie auf den folgenden Link klicken:

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

5. Nachdem der Build erfolgreich abgeschlossen wurde, versuchen Sie, das Hipstershop-Frontend in einem Browser über den folgenden Link aufzurufen:

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

Sie sollten einen Autorisierungsfehler von „currencyservice“ sehen:

6. Sehen wir uns an, wie der Währungsservice diese AuthorizationPolicy erzwingt. Aktivieren Sie zuerst Protokolle auf Trace-Ebene für den Envoy-Proxy für einen der Währungspods, da blockierte Autorisierungsaufrufe standardmäßig nicht protokolliert werden.

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. Rufen Sie die RBAC-Logs (Autorisierung) vom Sidecar-Proxy des Währungsdienstes ab. Sie sollten die Meldung „erzwungene Ablehnung“ sehen, die darauf hinweist, dass der Währungsservice so eingestellt ist, dass alle eingehenden Anfragen blockiert werden.

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

Ausgabe (nicht kopieren)

[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. Als Nächstes gewähren wir dem Frontend, aber nicht den anderen Backend-Diensten, Zugriff auf „currencyservice“. Öffnen Sie currency-allow-frontend.yaml und prüfen Sie den Inhalt. Wir haben die folgende Regel hinzugefügt:

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

Ausgabe (nicht kopieren)

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

Hier setzen wir ein bestimmtes source.principal (Client) auf die Zulassungsliste, um auf den Währungsservice zuzugreifen. Diese source.principal wird durch das Kubernetes-Dienstkonto definiert. In diesem Fall ist das Dienstkonto, das wir auf die Zulassungsliste setzen, das Frontend-Dienstkonto im Frontend-Namespace.

Hinweis:Wenn Sie Kubernetes-Dienstkonten in Istio-Autorisierungsrichtlinien verwenden, müssen Sie zuerst clusterweites Mutual TLS aktivieren, wie in Modul 1 beschrieben. So wird sichergestellt, dass Anmeldedaten für Dienstkonten in Anfragen eingebunden werden.

9. Aktualisierte Währungsrichtlinie kopieren

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. Änderungen per Push übertragen

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

11. Sehen Sie sich den Status des Cloud Build-Vorgangs für das Ops-Projekt auf einem zuvor geöffneten Tab oder über den folgenden Link an:

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

12. Nachdem der Build erfolgreich abgeschlossen wurde, öffnen Sie das Hipstershop-Frontend noch einmal. Diesmal sollten keine Fehler auf der Startseite angezeigt werden, da das Frontend explizit auf den aktuellen Dienst zugreifen darf.
13. Führen Sie nun einen Testkauf durch, indem Sie Artikel in den Einkaufswagen legen und auf „Bestellung aufgeben“ klicken. Dieses Mal sollte ein Fehler bei der Preisumrechnung vom Währungsservice angezeigt werden. Das liegt daran, dass wir nur das Frontend auf die weiße Liste gesetzt haben. Der Checkout-Service kann also weiterhin nicht auf den Währungsservice zugreifen.

14. Gewähren wir dem Abrechnungsdienst schließlich Zugriff auf die Währung, indem wir unserer AuthorizationPolicy für den Währungsdienst eine weitere Regel hinzufügen. Wir gewähren nur den beiden Diensten, die darauf zugreifen müssen, Zugriff auf die Währung: Frontend und Abrechnung. Die anderen Back-Ends werden weiterhin blockiert.
15. Öffnen Sie currency-allow-frontend-checkout.yaml und prüfen Sie den Inhalt. Die Liste der Regeln funktioniert als logisches ODER. Für die Währung werden nur Anfragen von Arbeitslasten mit einem der beiden Dienstkonten akzeptiert.

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

Ausgabe (nicht kopieren)

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. Kopieren Sie die endgültige Autorisierungsrichtlinie in das k8s-Repository.

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. Änderungen übertragen

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

18. Sehen Sie sich den Status des Cloud Build-Vorgangs für das Ops-Projekt auf einem zuvor geöffneten Tab oder über den folgenden Link an:

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

19. Nachdem der Build erfolgreich abgeschlossen wurde, versuchen Sie, einen Check-out auszuführen. Das sollte funktionieren.

In diesem Abschnitt wurde beschrieben, wie Sie mit Istio-Autorisierungsrichtlinien eine detaillierte Zugriffssteuerung auf Dienstebene erzwingen. In der Produktion erstellen Sie möglicherweise eine AuthorizationPolicy pro Dienst und verwenden beispielsweise eine Allow-all-Richtlinie, damit alle Arbeitslasten im selben Namespace aufeinander zugreifen können.

12. Skalierung der Infrastruktur

Ziel: Infrastruktur durch Hinzufügen neuer Regionen, Projekte und Cluster skalieren.

• infrastructure-Repository klonen
• Terraform-Dateien aktualisieren, um neue Ressourcen zu erstellen
• 2 Subnetze in der neuen Region (eines für das Betriebsprojekt und eines für das neue Projekt)
• Neuer Ops-Cluster in neuer Region (im neuen Subnetz)
• Neue Istio-Steuerungsebene für die neue Region
• 2 App-Cluster im neuen Projekt in der neuen Region
• Commit für das Repository infrastructure
• Installation prüfen

FAST TRACK SCRIPT

Wenn Sie sich für diese Methode entscheiden, führen Sie das folgende Skript aus, um dieses Lab abzuschließen.

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

Lab-Anleitung für die Copy-and-Paste-Methode

Wenn Sie das Fast-Track-Script für dieses Lab bereits ausgeführt haben, führen Sie die Copy-and-Paste-Methode unten nicht aus**.**

Es gibt verschiedene Möglichkeiten, eine Plattform zu skalieren. Sie können die Rechenleistung erhöhen, indem Sie vorhandenen Clustern Knoten hinzufügen. Sie können einer Region weitere Cluster hinzufügen. Oder Sie können der Plattform weitere Regionen hinzufügen. Welcher Aspekt der Plattform skaliert werden soll, hängt von den Anforderungen ab. Wenn Sie beispielsweise Cluster in allen drei Zonen einer Region haben, reicht es möglicherweise aus, den vorhandenen Clustern weitere Knoten oder Knotenpools hinzuzufügen. Wenn Sie jedoch Cluster in zwei von drei Zonen in einer einzelnen Region haben, erhalten Sie durch das Hinzufügen eines neuen Clusters in der dritten Zone Skalierung und eine zusätzliche Fehlerdomain (d.h. eine neue Zone). Ein weiterer Grund für das Hinzufügen eines neuen Clusters in einer Region kann die Notwendigkeit sein, einen Cluster mit einem einzelnen Mandanten zu erstellen, z. B. aus regulatorischen oder Compliance-Gründen (z. B. PCI oder ein Datenbankcluster, in dem personenbezogene Daten gespeichert werden). Wenn Ihr Unternehmen und Ihre Dienstleistungen wachsen, ist es unvermeidlich, neue Regionen hinzuzufügen, um Dienstleistungen näher an den Kunden anzubieten.

Die aktuelle Plattform besteht aus zwei Regionen und Clustern in zwei Zonen pro Region. Es gibt zwei Möglichkeiten, die Plattform zu skalieren:

• Vertikal: Innerhalb jeder Region durch Hinzufügen von mehr Rechenleistung. Dies geschieht entweder durch Hinzufügen weiterer Knoten (oder Knotenpools) zu vorhandenen Clustern oder durch Hinzufügen neuer Cluster in der Region. Dies erfolgt über das infrastructure-Repository. Am einfachsten ist es, Knoten zu vorhandenen Clustern hinzuzufügen. Hierfür ist keine zusätzliche Konfiguration erforderlich. Wenn Sie neue Cluster hinzufügen, sind möglicherweise zusätzliche Subnetze (und sekundäre Bereiche) erforderlich. Außerdem müssen Sie entsprechende Firewallregeln hinzufügen, die neuen Cluster der regionalen ASM-/Istio-Service-Mesh-Steuerungsebene hinzufügen und Anwendungsressourcen in den neuen Clustern bereitstellen.
• Horizontal: durch Hinzufügen weiterer Regionen. Auf der aktuellen Plattform erhalten Sie eine regionale Vorlage. Er besteht aus einem regionalen Betriebscluster, in dem sich die ASM-/Istio-Steuerungsebene befindet, und zwei (oder mehr) zonalen Anwendungsclustern, in denen Anwendungsressourcen bereitgestellt werden.

In diesem Workshop skalieren Sie die Plattform „horizontal“, da sie auch die vertikalen Anwendungsfallschritte umfasst. Um die Plattform horizontal zu skalieren, indem eine neue Region (r3) hinzugefügt wird, müssen die folgenden Ressourcen hinzugefügt werden:

1. Subnetze in der freigegebenen VPC des Hostprojekts in Region r3 für die neuen Betriebs- und Anwendungscluster.
2. Ein regionaler Operations-Cluster in der Region r3, in dem sich die ASM-/Istio-Steuerungsebene befindet.
3. Zwei zonale Anwendungscluster in zwei Zonen in Region r3.
4. Aktualisieren Sie das k8s-Repo:
5. Stellen Sie ASM-/Istio-Steuerungsebenenressourcen im Operations-Cluster in Region r3 bereit.
6. Stellen Sie ASM-/Istio-Ressourcen für die gemeinsame Steuerungsebene in den App-Clustern in Region r3 bereit.
7. Sie müssen kein neues Projekt erstellen. In den Schritten im Workshop wird jedoch gezeigt, wie Sie ein neues Projekt (dev3) hinzufügen, um den Anwendungsfall zu veranschaulichen, in dem ein neues Team zur Plattform hinzugefügt wird.

Das Infrastruktur-Repository wird verwendet, um die oben genannten neuen Ressourcen hinzuzufügen.

1. Wechseln Sie in Cloud Shell zu WORKDIR und klonen Sie das Repository 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. Klonen Sie das Quell-Repository des Workshops, den Zweig add-proj, in das Verzeichnis add-proj-repo.

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

 

3. Kopieren Sie Dateien aus dem add-proj-Branch im Quell-Workshop-Repository. Der Zweig add-proj enthält die Änderungen für diesen Abschnitt.

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

4. Ersetzen Sie das Verzeichnis infrastructure im Verzeichnis des add-proj-Repositorys durch einen Symlink zum Verzeichnis infra-repo, damit die Skripts im Zweig ausgeführt werden können.

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

5. Führen Sie das Skript add-project.sh aus, um die freigegebenen Status und Variablen in die neue Projektverzeichnisstruktur zu kopieren.

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

6. Änderungen committen und pushen, um ein neues Projekt zu erstellen

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

7. Der Commit löst aus, dass im infrastructure-Repository die Infrastruktur mit den neuen Ressourcen bereitgestellt wird. Klicken Sie auf die Ausgabe des folgenden Links und rufen Sie den neuesten Build oben auf, um den Fortschritt von Cloud Build zu sehen.

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

Dieser Schritt dauert 25 bis 30 Minuten. Zeit für eine Kaffeepause.

Im letzten Schritt von infrastructure werden neue Kubernetes-Ressourcen in k8s-repo erstellt. Dadurch wird der Cloud Build-Prozess im k8s-repo (im Ops-Projekt) ausgelöst. Die neuen Kubernetes-Ressourcen sind für die drei neuen Cluster, die im vorherigen Schritt hinzugefügt wurden. Die ASM-/Istio-Steuerungsebene und die Ressourcen der gemeinsam genutzten Steuerungsebene werden den neuen Clustern mit k8s-repo Cloud Build hinzugefügt.

8. Nachdem der Cloud Build-Vorgang für die Infrastruktur erfolgreich abgeschlossen wurde, rufen Sie den k8s-repo-Cloud Build-Lauf auf, indem Sie auf den folgenden Ausgabelink klicken.

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

9. Führen Sie das folgende Skript aus, um die neuen Cluster der Datei „vars“ und der kubeconfig-Datei hinzuzufügen.

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

10. Ändern Sie die Variable KUBECONFIG so, dass sie auf die neue kubeconfig-Datei verweist.

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

11. Listen Sie Ihre Clusterkontexte auf. Sie sollten acht Cluster sehen.

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

Istio-Installation prüfen

12. Prüfen Sie, ob Istio auf dem neuen Ops-Cluster installiert ist. Dazu müssen alle Pods ausgeführt werden und alle Jobs abgeschlossen sein.

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. Prüfen Sie, ob Istio auf beiden dev3-Clustern installiert ist. Nur Citadel, Sidecar-Injektor und CoreDNS werden in den dev3-Clustern ausgeführt. Sie verwenden eine gemeinsame Istio-Steuerungsebene, die im Cluster ops-3 ausgeführt wird.

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

Diensterkennung für gemeinsame Steuerungsebenen prüfen

14. Prüfen Sie, ob die Secrets in allen Operations-Clustern für alle sechs Anwendungscluster bereitgestellt werden.

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

Ziel: Implementieren Sie einen Trennschalter für den Versandservice.

• DestinationRule für den shipping-Dienst erstellen, um einen Circuit Breaker zu implementieren
• Verwenden Sie fortio (ein Dienstprogramm zum Generieren von Last), um den Leistungsschalter für den shipping-Dienst zu validieren, indem Sie den Leistungsschalter auslösen.

Anleitung für das Fast Track Script Lab

Das Fast Track Script Lab ist bald verfügbar.

Lab-Anleitung für die Copy-and-Paste-Methode

Nachdem wir einige grundlegende Strategien für Monitoring und Fehlerbehebung für Istio-fähige Dienste kennengelernt haben, sehen wir uns nun an, wie Istio Ihnen hilft, die Resilienz Ihrer Dienste zu verbessern und die Menge an Fehlerbehebung zu reduzieren, die Sie überhaupt durchführen müssen.

Eine Mikrodienstarchitektur birgt das Risiko von kaskadierenden Fehlern. Dabei kann sich der Fehler eines Dienstes auf seine Abhängigkeiten und die Abhängigkeiten dieser Abhängigkeiten auswirken. Dies kann zu einem Ausfall mit Welleneffekt führen, der sich möglicherweise auf Endnutzer auswirkt. Istio bietet eine Circuit Breaker-Trafficrichtlinie, mit der Sie Dienste isolieren können. So werden nachgelagerte (clientseitige) Dienste davor geschützt, auf fehlerhafte Dienste zu warten, und vorgelagerte (serverseitige) Dienste davor, bei der Reaktivierung von einer plötzlichen Flut nachgelagerten Traffics überlastet zu werden. Insgesamt können Sie mit Schutzschaltungen vermeiden, dass alle Ihre Dienste ihre SLOs aufgrund eines hängenden Backend-Dienstes nicht erfüllen.

Das Circuit Breaker-Muster ist nach einem elektrischen Schalter benannt, der „auslösen“ kann, wenn zu viel Strom fließt, um Geräte vor Überlastung zu schützen. In einer Istio-Einrichtung ist Envoy die Schutzschaltung, die die Anzahl der ausstehenden Anfragen für einen Dienst im Blick behält. In diesem standardmäßigen geschlossenen Zustand werden Anfragen ohne Unterbrechung über Envoy weitergeleitet.

Wenn die Anzahl der ausstehenden Anfragen jedoch den von Ihnen definierten Schwellenwert überschreitet, wird der Leistungsschalter ausgelöst (geöffnet) und Envoy gibt sofort einen Fehler zurück. So kann der Server schnell auf Fehler reagieren und verhindern, dass der Anwendungscode des Servers die Anfrage des Clients bei Überlastung empfängt.

Nach dem von Ihnen definierten Zeitlimit wechselt Envoy in einen halb offenen Zustand, in dem der Server probeweise wieder Anfragen empfangen kann. Wenn er erfolgreich auf Anfragen antworten kann, schließt sich der Leistungsschalter wieder und Anfragen an den Server werden wieder gesendet.

In diesem Diagramm wird das Istio-Trennschaltermuster zusammengefasst. Die blauen Rechtecke stehen für Envoy, der blau gefüllte Kreis für den Client und die weiß gefüllten Kreise für den Servercontainer:

Sie können Circuit Breaker-Richtlinien mit Istio DestinationRules definieren. In diesem Abschnitt wenden wir die folgende Richtlinie an, um einen Schutzschalter für den Versanddienst zu erzwingen:

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

Hier sind zwei DestinationRule-Felder zu beachten. connectionPool definiert die Anzahl der Verbindungen, die dieser Dienst zulässt. Im Feld „outlierDetection“ konfigurieren wir, wie Envoy den Schwellenwert bestimmt, ab dem der Leistungsschalter geöffnet wird. Hier zählt Envoy jede Sekunde (Intervall) die Anzahl der Fehler, die vom Servercontainer empfangen wurden. Wenn der Grenzwert von consecutiveErrors überschritten wird, wird der Envoy-Leistungsschalter geöffnet und 100% der productcatalog-Pods werden 10 Sekunden lang vor neuen Clientanfragen geschützt. Sobald der Envoy-Leistungsschalter geöffnet (d. h. aktiv) ist, erhalten Clients 503-Fehler (Service Unavailable). Im konkreten Einsatz ansehen

1. Legen Sie Umgebungsvariablen für das k8s-Repo und das ASM-Verzeichnis fest, um Befehle zu vereinfachen.

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

2. k8s-Repo aktualisieren

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

3. Aktualisieren Sie die DestinationRule für den Versandservice in beiden Ops-Clustern.

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. Kopieren Sie einen Fortio-Pod für die Lastgenerierung in den GKE_1-Cluster in der Region Dev1. Dies ist der Client-Pod, mit dem wir den Leistungsschalter für den Versandservice auslösen.

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. Führen Sie ein Commit für die Änderungen durch.

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

6. Warten Sie, bis Cloud Build abgeschlossen ist.
7. Verwenden Sie in Cloud Shell den Fortio-Pod, um gRPC-Traffic mit einer gleichzeitigen Verbindung und insgesamt 1.000 Anfragen an den Shippingservice zu senden. Dadurch wird der Leistungsschalter nicht ausgelöst, da die connectionPool-Einstellungen noch nicht überschritten wurden.

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 
 

Ausgabe (nicht kopieren)

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

8. Führen Sie Fortio noch einmal aus und erhöhen Sie die Anzahl der gleichzeitigen Verbindungen auf 2, während die Gesamtzahl der Anfragen konstant bleibt. Bei bis zu zwei Dritteln der Anfragen sollte der Fehler „overflow“ zurückgegeben werden, da der Leistungsschalter ausgelöst wurde:In der von uns definierten Richtlinie ist nur eine gleichzeitige Verbindung in einem 1-Sekunden-Intervall zulässig.

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 
 

Ausgabe (nicht kopieren)

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 erfasst mit dem Messwert upstream_rq_pending_overflow die Anzahl der Verbindungen, die bei aktivem Leistungsschalter getrennt wurden. So finden Sie das im Fortio-Pod:

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

Ausgabe (nicht kopieren)

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. Führen Sie eine Bereinigung durch und entfernen Sie dazu die Unterbrecherrichtlinie aus beiden Regionen.

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
 

In diesem Abschnitt wurde gezeigt, wie Sie eine einzelne Circuit Breaker-Richtlinie für einen Dienst einrichten. Es empfiehlt sich, für jeden Upstream-Dienst (Backend) einen Circuit Breaker einzurichten, der möglicherweise hängen bleibt. Durch die Anwendung von Istio-Sicherungsrichtlinien können Sie Ihre Mikrodienste isolieren, Fehlertoleranz in Ihre Architektur einbauen und das Risiko von kaskadierenden Fehlern bei hoher Last verringern.

14. Fault Injection

Ziel: Die Belastbarkeit des Empfehlungsdienstes testen, indem Verzögerungen eingeführt werden (bevor er in der Produktion eingesetzt wird).

• Erstellen Sie ein VirtualService für den recommendation-Dienst, um eine Verzögerung von 5 Sekunden einzuführen.
• Verzögerung mit dem fortio-Lastgenerator testen
• Entfernen Sie die Verzögerung in VirtualService und validieren Sie die Änderungen.

Anleitung für das Fast Track Script Lab

Das Fast Track Script Lab ist bald verfügbar.

Lab-Anleitung für die Copy-and-Paste-Methode

Wenn Sie Ihren Diensten Trennschalterrichtlinien hinzufügen, können Sie die Ausfallsicherheit von Diensten in der Produktion erhöhen. Das Unterbrechen von Stromkreisen führt jedoch zu Fehlern, möglicherweise zu Fehlern, die Nutzer sehen, was nicht ideal ist. Um diese Fehlerfälle zu vermeiden und besser vorherzusagen, wie Ihre Downstream-Dienste reagieren, wenn Backends Fehler zurückgeben, können Sie Chaos-Tests in einer Staging-Umgebung durchführen. Beim Chaos-Testen werden Ihre Dienste absichtlich unterbrochen, um Schwachstellen im System zu analysieren und die Fehlertoleranz zu verbessern. Sie können mit Chaos-Tests auch herausfinden, wie Sie nutzerorientierte Fehler minimieren können, wenn Back-Ends ausfallen. Das kann beispielsweise durch die Anzeige eines im Frontend zwischengespeicherten Ergebnisses geschehen.

Die Verwendung von Istio für die Fehlerinjektion ist hilfreich, da Sie Ihre Produktionsrelease-Images verwenden und den Fehler auf der Netzwerkschicht hinzufügen können, anstatt den Quellcode zu ändern. In der Produktionsumgebung können Sie ein vollwertiges Chaos-Testtool verwenden, um die Resilienz zusätzlich zur Netzwerkschicht auch auf der Kubernetes-/Compute-Schicht zu testen.

Sie können Istio für Chaos-Tests verwenden, indem Sie ein VirtualService mit dem Feld „fault“ anwenden. Istio unterstützt zwei Arten von Fehlern: Verzögerungsfehler (Timeout einfügen) und Abbruchfehler (HTTP-Fehler einfügen). In diesem Beispiel fügen wir dem Empfehlungsdienst einen Fehler mit einer Verzögerung von 5 Sekunden hinzu. Dieses Mal verwenden wir jedoch keinen Circuit Breaker, um bei diesem hängenden Dienst schnell einen Fehler zu melden, sondern zwingen die Downstream-Dienste, das vollständige Zeitlimit abzuwarten.

11. Wechseln Sie in das Verzeichnis für die Fehlerinjektion.

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

12. Öffnen Sie k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml, um den Inhalt zu prüfen. Istio bietet die Möglichkeit, den Fehler in einen bestimmten Prozentsatz der Anfragen einzufügen. Hier fügen wir ein Zeitlimit in alle „recommendationservice“-Anfragen ein.

Ausgabe (nicht kopieren)

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. Kopieren Sie den VirtualService in k8s_repo. Wir fügen den Fehler global in beiden Regionen ein.

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. Änderungen übertragen

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

15. Warten Sie, bis Cloud Build abgeschlossen ist.
16. Führen Sie den Befehl für den im Abschnitt „Circuit Breaker“ bereitgestellten Fortio-Pod aus und senden Sie etwas Traffic an „recommendationservice“.

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

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

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

Ausgabe (nicht kopieren)

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. Eine weitere Möglichkeit, den eingefügten Fehler in Aktion zu sehen, besteht darin, das Frontend in einem Webbrowser zu öffnen und auf ein beliebiges Produkt zu klicken. Das Laden einer Produktseite dauert fünf Sekunden länger, da die Empfehlungen abgerufen werden, die unten auf der Seite angezeigt werden.
18. Bereinigen Sie, indem Sie den Dienst für die Fehlerinjektion aus beiden Ops-Clustern entfernen.

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. Änderungen übertragen:

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

15. Istio-Steuerungsebene überwachen

ASM installiert vier wichtige Komponenten der Steuerungsebene: Pilot, Mixer, Galley und Citadel. Jeder sendet seine relevanten Monitoring-Messwerte an Prometheus. ASM wird mit Grafana-Dashboards ausgeliefert, mit denen Operatoren diese Monitoring-Daten visualisieren und den Zustand und die Leistung der Steuerungsebene bewerten können.

Dashboards aufrufen

20. Portweiterleitung für den mit Istio installierten Grafana-Dienst einrichten

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

21. Grafana im Browser öffnen
22. Klicken Sie rechts oben im Cloud Shell-Fenster auf das Symbol für die Webvorschau.
23. Klicken Sie auf „Vorschau auf Port 3000“ (Hinweis: Wenn der Port nicht 3000 ist, klicken Sie auf „Port ändern“ und wählen Sie Port 3000 aus).
24. Daraufhin wird in Ihrem Browser ein Tab mit einer URL wie BASE_URL/?orgId=1&authuser=0&environment_id=default geöffnet.
25. Verfügbare Dashboards ansehen
26. Ändern Sie die URL in BASE_URL/dashboard.
27. Klicken Sie auf den Ordner „istio“, um die verfügbaren Dashboards aufzurufen.
28. Klicken Sie auf eines dieser Dashboards, um die Leistung der entsprechenden Komponente aufzurufen. In den folgenden Abschnitten werden die wichtigen Messwerte für jede Komponente erläutert.

Monitoring Pilot

Pilot ist die Steuerungsebenenkomponente, die die Netzwerk- und Richtlinienkonfiguration an die Datenebene (die Envoy-Proxys) verteilt. Pilot wird in der Regel mit der Anzahl der Arbeitslasten und Bereitstellungen skaliert, aber nicht unbedingt mit dem Traffic zu diesen Arbeitslasten. Ein fehlerhafter Pilot kann Folgendes verursachen:

• mehr Ressourcen als nötig verbrauchen (CPU und/oder RAM)
• zu Verzögerungen beim Übertragen aktualisierter Konfigurationsinformationen an Envoys führen.

Hinweis: Wenn Pilot ausfällt oder es zu Verzögerungen kommt, wird für Ihre Arbeitslasten weiterhin Traffic bereitgestellt.

23. Rufen Sie in Ihrem Browser BASE_URL/dashboard/db/istio-pilot-dashboard auf, um Pilot-Messwerte aufzurufen.

Wichtige überwachte Messwerte

Ressourcennutzung

Die Seite zu Leistung und Skalierbarkeit von Istio enthält Richtwerte für die akzeptable Nutzung. Wenden Sie sich an den GCP-Support, wenn Sie eine deutlich höhere dauerhafte Ressourcennutzung feststellen.

Informationen zum Pilot-Push

In diesem Abschnitt wird die Übertragung von Pilotkonfigurationen an Ihre Envoy-Proxys überwacht.

• Unter Pilot-Pushes wird der Typ der Konfiguration angezeigt, die zu einem bestimmten Zeitpunkt übertragen wurde.
• Unter ADS Monitoring sehen Sie die Anzahl der virtuellen Dienste, Dienste und verbundenen Endpunkte im System.
• Unter Cluster ohne bekannte Endpunkte werden Endpunkte angezeigt, die konfiguriert wurden, aber keine Instanzen ausführen. Dies kann auf externe Dienste wie *.googleapis.com hinweisen.
• Unter Pilot Errors (Pilotfehler) sehen Sie die Anzahl der Fehler im Zeitverlauf.
• Unter Konflikte wird die Anzahl der Konflikte angezeigt, die auf mehrdeutigen Konfigurationen für Listener beruhen.

Wenn Sie Fehler oder Konflikte haben, ist die Konfiguration für mindestens einen Ihrer Dienste fehlerhaft oder inkonsistent. Weitere Informationen finden Sie unter „Fehlerbehebung bei der Datenebene“.

Envoy-Informationen

Dieser Abschnitt enthält Informationen zu den Envoy-Proxys, die die Steuerungsebene kontaktieren. Wenden Sie sich an den GCP-Support, wenn wiederholt XDS-Verbindungsfehler auftreten.

Monitoring Mixer

Mixer ist die Komponente, die Telemetriedaten von den Envoy-Proxys an Telemetrie-Back-Ends (in der Regel Prometheus, Stackdriver usw.) weiterleitet. In dieser Funktion befindet sich die Komponente nicht in der Datenebene. Sie wird als zwei Kubernetes-Jobs (Mixer) mit zwei verschiedenen Dienstnamen (istio-telemetry und istio-policy) bereitgestellt.

Mixer kann auch zur Integration in Richtliniensysteme verwendet werden. In dieser Funktion wirkt sich Mixer auf die Datenebene aus, da Richtlinienprüfungen für Mixer, die fehlschlagen, den Zugriff auf Ihre Dienste blockieren.

Mixer wird in der Regel mit dem Traffic-Volumen skaliert.

24. Rufen Sie in Ihrem Browser die URL BASE_URL/dashboard/db/istio-mixer-dashboard auf, um Mixer-Messwerte aufzurufen.

Wichtige überwachte Messwerte

Ressourcennutzung

Die Seite zu Leistung und Skalierbarkeit von Istio enthält Richtwerte für die akzeptable Nutzung. Wenden Sie sich an den GCP-Support, wenn Sie eine deutlich höhere dauerhafte Ressourcennutzung feststellen.

Mixer – Übersicht

• Die Antwortdauer ist ein wichtiger Messwert. Berichte an die Mixer-Telemetrie befinden sich nicht im Datenpfad. Wenn diese Latenzen jedoch hoch sind, wird die Leistung des Sidecar-Proxys definitiv verlangsamt. Das 90. Perzentil sollte im einstelligen Millisekundenbereich liegen und das 99. Perzentil unter 100 ms.

• Adapter Dispatch Duration (Dauer des Adapter-Dispatch) gibt die Latenz an, die bei Mixer beim Aufrufen von Adaptern auftritt (über die Informationen an Telemetrie- und Protokollierungssysteme gesendet werden). Hohe Latenzen wirken sich hier definitiv auf die Leistung im Mesh aus. Auch hier sollten die Latenzen für das 90. Perzentil unter 10 ms liegen.

Monitoring-Galerie

Galley ist die Istio-Komponente, die für Konfigurationsprüfung, Aufnahme, Verarbeitung und Verteilung zuständig ist. Sie überträgt die Konfiguration vom Kubernetes API-Server an Pilot. Wie Pilot skaliert es in der Regel mit der Anzahl der Dienste und Endpunkte im System.

25. Rufen Sie in Ihrem Browser BASE_URL/dashboard/db/istio-galley-dashboard auf, um Galley-Messwerte aufzurufen.

Wichtige überwachte Messwerte

Ressourcenvalidierung

Der wichtigste Messwert, der die Anzahl der Ressourcen verschiedener Typen wie Zielregeln, Gateways und Serviceeinträge angibt, die die Validierung bestehen oder nicht.

Verbundene Clients

Gibt an, wie viele Clients mit Galley verbunden sind. Normalerweise sind es 3 (pilot, istio-telemetry, istio-policy). Die Anzahl skaliert mit diesen Komponenten.

16. Fehlerbehebung bei Istio

Fehlerbehebung auf der Datenebene

Wenn in Ihrem Pilot-Dashboard Konfigurationsprobleme angezeigt werden, sollten Sie die Pilot-Logs prüfen oder mit istioctl nach Konfigurationsproblemen suchen.

Führen Sie zum Untersuchen von Pilot-Logs den folgenden Befehl aus: kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery. Ersetzen Sie dabei „istio-pilot-...“ durch die Pod-ID der Pilot-Instanz, bei der Sie die Fehlerbehebung durchführen möchten.

Suchen Sie im resultierenden Log nach einer Meldung vom Typ Push Status. Beispiel:

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="
}

Der Push-Status gibt an, ob beim Versuch, die Konfiguration an Envoy-Proxys zu übertragen, Probleme aufgetreten sind. In diesem Fall sehen wir mehrere Meldungen vom Typ „Duplicate cluster“ (Doppelter Cluster), die auf doppelte Upstream-Ziele hinweisen.

Wenn Sie Hilfe bei der Diagnose von Problemen benötigen, wenden Sie sich an den Google Cloud-Support.

Konfigurationsfehler finden

Wenn Sie istioctl verwenden möchten, um Ihre Konfiguration zu analysieren, führen Sie istioctl experimental analyze -k --context $OPS_GKE_1 aus. Dabei wird die Konfiguration in Ihrem System analysiert und es werden alle Probleme sowie entsprechende Änderungsvorschläge angezeigt. Eine vollständige Liste der Konfigurationsfehler, die mit diesem Befehl erkannt werden können, finden Sie in der Dokumentation.

17. Bereinigen

Die folgenden Schritte werden von einem Administrator nach Abschluss des Workshops ausgeführt.

Ein Administrator führt das Skript „cleanup_workshop.sh“ aus, um Ressourcen zu löschen, die vom Skript „bootstrap_workshop.sh“ erstellt wurden. Damit das Bereinigungsskript ausgeführt werden kann, benötigen Sie die folgenden Informationen.

• Name der Organisation, z. B. yourcompany.com
• Workshop-ID – z. B. im Format YYMMDD-NN, z. B. 200131-01
• Admin-GCS-Bucket: im Bootstrap-Skript definiert.

13. Öffnen Sie Cloud Shell und führen Sie alle unten aufgeführten Aktionen in Cloud Shell aus. Klicken Sie auf den Link unten.

CLOUD SHELL

14. Prüfen Sie, ob Sie mit dem gewünschten Administratornutzer in gcloud angemeldet sind.

gcloud config list
 

15. Rufen Sie den asm-Ordner auf.

cd ${WORKDIR}/asm
 

16. Geben Sie den Namen Ihrer Organisation und die zu löschende Workshop-ID an.

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

17. Führen Sie das Bereinigungsskript so aus:

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