Anthos Service Mesh-Workshop: Lab-Leitfaden

1. ALPHA-WORKSHOP

WICHTIGER HINWEIS: DIES IST EIN ALPHA-WORKSHOP UND IST STRENG ALPHA-TRAINING ALS CLASSROOM-SCHULUNG MIT LEHRKRÄFTEN.

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

2. Übersicht

Architekturdiagramm

In diesem praxisorientierten Workshop erfahren Sie, wie Sie global verteilte Dienste auf der GCP in der Produktion einrichten. Die wichtigsten Technologien sind Google Kubernetes Engine (GKE) für Computing und Istio Service Mesh, um sichere Konnektivität, Beobachtbarkeit und erweiterte Trafficmuster zu schaffen. Alle in diesem Workshop verwendeten Praktiken und Tools sind das, was Sie auch in der Produktion anwenden würden.

Inhalt

• Modul 0 – Einführung und Plattformeinrichtung
• Einführung und Architektur
• Einführung in Service Mesh und Istio/ASM
• Lab: Einrichtung der Infrastruktur: Nutzerworkflow
• Pause
• QnA
• Modul 1 – Anwendungen mit ASM installieren, sichern und überwachen
• Repository-Modell: Infrastruktur- und Kubernetes-Repositories erklärt
• Lab: Beispielanwendung bereitstellen
• Verteilte Dienste und Beobachtbarkeit
• Mittagessen
• Lab: Beobachtbarkeit mit Stackdriver
• QNA
• Modul 2 – DevOps – Canary-Roll-outs, Richtlinie/RBAC
• Multi-Cluster-Diensterkennung und -Sicherheit/Richtlinie
• Lab: Gegenseitiges TLS
• Canary-Bereitstellungen
• Lab: Canary-Bereitstellungen
• Sicheres globales Load-Balancing für mehrere Cluster
• Pause
• Lab: Autorisierungsrichtlinie
• QNA
• Modul 3 – Infrastrukturbetrieb – Plattformupgrades
• Bausteine des verteilten Dienstes
• Lab: Skalierung der Infrastruktur
• Nächste Schritte

Präsentationen

Die Folien für diesen Workshop findest du unter folgendem Link:

Folien für den ASM-Workshop

Vorbereitung

Bevor Sie mit diesem Workshop fortfahren können, müssen Sie Folgendes tun:

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

3. Infrastruktureinrichtung – Administratorworkflow

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

Wenn du ein Nutzer bist, der am Workshop teilnimmt, gehe zum nächsten Abschnitt mit dem Titel „Infrastructure Setup - User Workflow“.

Skript zum Bootstrap-Workshop erklärt

Mit einem Skript namens 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, falls Sie diesen Workshop als Training für mehrere Nutzer anbieten.

Für das Skript des Bootstrap-Workshops ist Folgendes als Eingabe erforderlich:

• Name der Organisation, z. B. yourcompany.com: Dies ist die Organisation, in der Sie die Umgebungen für den Workshop erstellen.
• Abrechnungs-ID (z. B. 12345-12345-12345): Mit dieser Abrechnungs-ID werden alle im Workshop verwendeten Ressourcen abgerechnet.
• Workshopnummer (z. B. 01): Eine zweistellige Nummer. Das ist nützlich, wenn Sie mehrere Workshops an einem Tag durchführen und diese separat im Auge behalten möchten. Aus Workshop-Nummern werden auch Projekt-IDs abgeleitet. Mit separaten Workshop-Nummern kannst du einfacher dafür sorgen, dass du jedes Mal eine eindeutige Projekt-ID erhältst. Neben der Workshopnummer wird auch das aktuelle Datum im Format YYMMDD für Projekt-IDs verwendet. Durch die Kombination aus Datum und Workshopnummer erhalten Sie eindeutige Projekt-IDs.
• Startnutzernummer, z. B. 1: Diese Zahl steht für den ersten Nutzer im Workshop. Wenn Sie beispielsweise einen Workshop für 10 Nutzer erstellen möchten, können Sie die Startnutzernummer 1 und die Endnutzernummer 10 haben.
• Endnutzernummer (z. B. 10): Diese Nummer bezeichnet den letzten Nutzer im Workshop. Wenn Sie beispielsweise einen Workshop für 10 Nutzer erstellen möchten, können Sie die Startnutzernummer 1 und die Endnutzernummer 10 haben. Wenn Sie eine einzelne Umgebung einrichten (z. B. für sich), achten Sie darauf, dass Start- und Endbenutzernummer identisch sind. Dadurch wird eine einzige Umgebung erstellt.

Neben Datum und Workshop-Nummer werden auch die Start- und Endanwendendennummern in die Projekt-IDs aufgenommen. Nutzer-IDs (für Nutzende, die den Workshop durchführen) werden von der Start- und Endbenutzernummer abgeleitet. User-IDs werden im Abschnitt User schema and permissions performing the workshop erläutert.

• Admin-GCS-Bucket (z. B. my-gcs-bucket-name): In einem GCS-Bucket werden Informationen zum Workshop gespeichert. Diese Informationen werden vom Skript cleanup_workshop.sh verwendet, um alle Ressourcen zu löschen, die während des Bootstrap-Workshop-Skripts erstellt wurden. Administratoren, die Workshops erstellen, müssen Lese-/Schreibberechtigungen für diesen Bucket haben.

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

Für das Bootstrapping des Workshops sind Administratorberechtigungen erforderlich

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

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

• Inhaber: Berechtigung des Projektinhabers 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 Ressourcen im Projekt.
• Administrator der Organisation
• Projektersteller – Kann Projekte in der Organisation erstellen.
• Projektlöscher: Kann Projekte in der Organisation löschen.
• Projekt-IAM-Administrator – Kann IAM-Regeln in allen Projekten der Organisation erstellen.

Außerdem muss ADMIN_USER der Abrechnungsadministrator für die Abrechnungs-ID sein, die für den Workshop verwendet wird.

Nutzerschema und Berechtigungen bei der Durchführung des Workshops

Wenn du diesen Workshop für andere Nutzer in deiner Organisation erstellen möchtest, musst du ein bestimmtes Nutzerbenennungsschema für MY_USERs verwenden. Während des Skripts bootstrap_workshop.sh geben Sie eine Start- und eine Endnutzernummer an. Aus diesen Nummern werden die folgenden Nutzernamen erstellt:

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

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

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

Diesen Nutzernamen werden Projektinhaberrollen für ihre spezifischen Projekte zugewiesen, die im Skript „setup_terraform_admin_project.sh“ erstellt wurden. Sie müssen sich an dieses Namensschema für Nutzer halten, wenn Sie das Bootstrap-Skript verwenden. Hier erfahren Sie, wie Sie in der G Suite mehrere Nutzer gleichzeitig hinzufügen.

Für den Workshop erforderliche Werkzeuge

Dieser Workshop ist für das Bootstrapping über Cloud Shell vorgesehen. Für diesen Workshop werden die folgenden Tools benötigt.

• gcloud (Version >= 270)
• kubectl
• sed (funktioniert mit sed unter Cloud Shell/Linux, nicht jedoch mit Mac OS)
• git (aktuell aktualisieren)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize

Alle Tools außer kustomize sind standardmäßig in Cloud Shell installiert. Wenn Kustomize nicht installiert ist, installieren Sie es mit dem Bash-Skript, das im obigen Link bereitgestellt wird. Achten Sie darauf, dass sich die Kustomize-Binärdatei in Ihrem Pfad befindet, und bestätigen Sie mit dem Befehl kustomize in Cloud Shell.

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

1. Öffnen Sie Cloud Shell und führen Sie alle folgenden 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 Workshopnummer und einen Administrator-GCS-Bucket für den Workshop an. Prüfen Sie die erforderlichen Berechtigungen für die Einrichtung des Workshops in den obigen Abschnitten.

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 
 

Die Start- und die Endnutzernummer müssen Sie nicht angeben, da Sie diese Einstellungen für sich selbst vornehmen.

Nach Abschluss des Skripts bootstrap_workshop.sh wird für jeden Nutzer in der Organisation ein GCP-Ordner erstellt. Innerhalb des Ordners wird ein Terraform-Administratorprojekt erstellt. Mit dem Terraform-Administratorprojekt werden die restlichen GCP-Ressourcen erstellt, die für diesen Workshop erforderlich sind. Die erforderlichen APIs werden im Terraform-Administratorprojekt aktiviert. Terraform-Pläne werden mit Cloud Build angewendet. Sie weisen dem Cloud Build-Dienstkonto die richtigen IAM-Rollen zu, damit es Ressourcen auf der GCP erstellen kann. Abschließend konfigurieren Sie ein Remote-Back-End 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 anzusehen, benötigen Sie die Terraform-Projekt-ID. Sie wird in der Datei vars/vars.sh im Verzeichnis asm gespeichert. Dieses Verzeichnis wird nur beibehalten, wenn Sie den Workshop für sich selbst als Administrator einrichten.

6. Variablendatei zum Festlegen von Umgebungsvariablen beschaffen

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 folgenden 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 Workshopnummer, die Start- und Endnutzernummer sowie einen GCS-Bucket für Administratoren für den Workshop an. Prüfen Sie die erforderlichen Berechtigungen für die Einrichtung des Workshops in den obigen Abschnitten.

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 für Administratoren 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

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

Lab-Pfad auswählen

Für die Labs in diesem Workshop gibt es zwei Möglichkeiten:

• Einfache, schnelle interaktive Skripts Weg
• Die Anleitung zum manuellen Kopieren und Einfügen Weg

Mit der Fast Track-Script-Methode können Sie für jedes Lab ein interaktives Skript 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 der einzelnen Schritte und der damit verbundenen Ergebnisse ausgeführt. Nach jedem Batch werden Sie aufgefordert, mit dem nächsten Batch von Befehlen fortzufahren. So können Sie die Labs in Ihrem Tempo ausführen. Die Fast-Track-Skripts sind idempotent. Das bedeutet, dass Sie diese Skripts mehrmals ausführen können, was zum gleichen Ergebnis führt.

Die Fast-Track-Skripts werden wie unten abgebildet in jedem Lab in einem grünen Feld angezeigt.

SKRIPT FÜR DEN SCHNELLEN TRACK

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

Die Kopieren- und Einfügen-Methode ist die traditionelle Methode, um einzelne Befehlsblöcke mit Erklärungen der Befehle zu kopieren und einzufügen. Diese Methode sollte nur einmal ausgeführt werden. Es gibt keine Garantie, dass durch wiederholtes Ausführen von Befehlen in dieser Methode dieselben Ergebnisse erzielt werden.

Wählen Sie beim Durchführen der Labs eine der beiden Methoden aus.

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

Fast Track-Skripteinrichtung

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

Nutzerinformationen abrufen

Dieser Workshop wird mit einem temporären Nutzerkonto (oder einem Lab-Konto) durchgeführt, das vom Administrator des Workshops erstellt wurde. Das Lab-Konto ist Inhaber aller Projekte im Workshop. Der Administrator des Workshops stellt dem Nutzer, der den Workshop durchführt, die Anmeldedaten für das Lab-Konto (Nutzername und Passwort) bereit. Allen Projekten des Nutzers wird der Nutzername des Lab-Kontos vorangestellt, z. B. für das Lab-Konto [e-mail], die Terraform-Projekt-ID user001-200131-01-tf-abcde und so weiter für die restlichen Projekte. Jeder Nutzer muss sich mit dem vom Administrator des Workshops bereitgestellten Lab-Konto anmelden und den Workshop mit dem Lab-Konto durchführen.

Überprüfe deine geschäftliche E-Mail-Adresse. Das ist dieselbe E-Mail-Adresse, mit der du dich für den Workshop registriert hast. Sie sollten vom Administrator des Workshops eine E-Mail mit den Anmeldedaten Ihres Lab-Kontos (d.h. Nutzername und Passwort) erhalten haben. Die E-Mail sieht so aus.

1. Öffnen Sie Cloud Shell, indem Sie auf den Link unten klicken.

Cloud Shell

2. Melden Sie sich mit den Anmeldedaten für das Lab-Konto an (nicht mit Ihrem Unternehmenskonto oder privaten Konto). Das Lab-Konto hat das Format 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.

Mit diesem Schritt wird eine kleine Linux-Debian-VM bereitgestellt, mit der Sie auf Google Cloud-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. Neben Cloud Shell steht auch ein Code-Editor zur Verfügung, der die Bearbeitung von Konfigurationsdateien (Terraform, YAML usw.) vereinfacht. Standardmäßig ist der Cloud Shell-Bildschirm in die Cloud Shell-Shell-Umgebung (unten) und den Cloud Code-Editor (oben) unterteilt. Mit dem Stiftsymbol und den Symbolen für die Shell-Eingabeaufforderung oben rechts können Sie zwischen den beiden Symbolen (Shell und Code-Editor) wechseln. Sie können auch die mittlere Trennleiste nach oben oder unten ziehen und die Größe der einzelnen Fenster manuell ändern. 5. Erstellen Sie ein WORKDIR für diesen Workshop. Das WORKDIR ist ein Ordner, in dem Sie alle Labs für diesen Workshop bearbeiten. Führen Sie in Cloud Shell die folgenden Befehle aus, um das WORKDIR zu erstellen.

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

6. Exportieren Sie den Lab-Kontonutzer als Variable, die für diesen Workshop verwendet werden soll. Dies 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 du Administrator bist und den Workshop mit der Methode „-sufa“ selbst einrichtest, oder „–setup-for-admin“ setzen Sie MY_USER auf die E-Mail-Adresse des GCP-Kontos, mit dem Sie die Workshop-Projekte erstellt haben.

7. Führen Sie die folgenden Befehle aus, um sicherzustellen, dass beide Variablen richtig festgelegt sind.

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. Infrastruktureinrichtung – Nutzerworkflow

Ziel: Infrastruktur und Istio-Installation überprüfen

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

SKRIPT FÜR DEN SCHNELLEN TRACK

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

Ermitteln Sie nach Abschluss des Skripts den Bashrc, um die Variablen in der Cloud Shell-Sitzung zu aktualisieren.

source ${HOME}/.bashrc

Anleitung zum Kopieren und Einfügen für das Methoden-Lab

WICHTIG: Wenn Sie das Schnellverfahren für dieses Lab bereits ausgefüllt haben, verwenden Sie nicht die unten stehende Methode zum Kopieren und Einfügen**.**

Nutzerinformationen abrufen

Der Administrator, der den Workshop einrichtet, muss dem Nutzer den Nutzernamen und das Passwort mitteilen. Allen Projekten des Nutzers wird der Nutzername vorangestellt, z. B. für den Nutzer [e-mail], die Terraform-Projekt-ID user001-200131-01-tf-abcde und so weiter für die restlichen Projekte. Jeder Nutzer hat nur Zugriff auf seine eigene Workshop-Umgebung.

Für den Workshop erforderliche Werkzeuge

Dieser Workshop ist für das Bootstrapping über Cloud Shell vorgesehen. Für diesen Workshop werden die folgenden Tools benötigt.

Alle Tools außer kustomize und pv sind bereits standardmäßig in Cloud Shell installiert. Im Folgenden finden Sie eine Anleitung zur Installation der beiden Tools.

• gcloud (Version >= 270)
• kubectl
• sed (funktioniert mit sed unter Cloud Shell/Linux, nicht jedoch mit Mac OS)
• git (aktuell aktualisieren)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize
• pv

Auf Terraform-Administratorprojekt zugreifen

Nach Abschluss des Skripts bootstrap_workshop.sh wird für jeden Nutzer in der Organisation ein GCP-Ordner erstellt. Innerhalb des Ordners wird ein Terraform-Administratorprojekt erstellt. Mit dem Terraform-Administratorprojekt werden die restlichen GCP-Ressourcen erstellt, die für diesen Workshop erforderlich sind. Das Skript „setup-terraform-admin-project.sh“ aktiviert die erforderlichen APIs im Projekt „terraform admin“. Zum Anwenden von Terraform-Plänen wird Cloud Build verwendet. Über das Skript weisen Sie dem Cloud Build-Dienstkonto die richtigen IAM-Rollen zu, damit es Ressourcen auf der GCP erstellen kann. Schließlich wird ein Remote-Back-End 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 anzusehen, benötigen Sie die Terraform-Projekt-ID. Sie wird im GCS-Bucket für Administratoren gespeichert, der im Bootstrap-Skript angegeben wurde. Wenn Sie das Bootstrap-Skript für mehrere Nutzer ausführen, befinden sich alle IDs des Terraform-Administratorprojekts im GCS-Bucket.

Dieser Workshop soll in Cloud Shell und der Cloud Console durchgeführt werden. Führe die folgenden Schritte in einem INCOGNITO-Fenster aus, da du dich mit einem separaten Nutzernamen und Passwort anmeldest.

1. Klicken Sie auf den Link unten, um Cloud Shell zu öffnen (falls es nicht bereits im Abschnitt „Lab einrichten und vorbereiten“ geöffnet ist).

Cloud Shell

2. Installieren Sie Kustomize (falls nicht bereits installiert) 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 Ihre Bash-Eingabeaufforderung.

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 bei 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 des Terraform-Administratorprojekts ab, indem Sie den folgenden Befehl ausführen:

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

7. Alle mit dem Workshop verknüpften Ressourcen werden als Variablen in einer vars.sh-Datei gespeichert, die in einem GCS-Bucket im Terraform-Administratorprojekt gespeichert wird. 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 Nutzungsbedingungen von Google zu.

9. Sie sehen nun die Seite Cloud Build. Klicken Sie nun im linken Navigationsbereich auf den Link History und dann auf den neuesten Build, um die Details zu den ursprünglichen Terraform-Anwendungsdetails aufzurufen. Die folgenden Ressourcen werden als Teil des Terraform-Skripts erstellt. Weitere Informationen finden Sie auch im obigen Architekturdiagramm.

• Vier GCP-Projekte in der Organisation Das angegebene Rechnungskonto ist mit jedem Projekt verknüpft.
• Ein Projekt ist der network host project für die freigegebene VPC. In diesem Projekt werden keine weiteren Ressourcen erstellt.
• Eines der Projekte ist der ops project, der für GKE-Cluster der Istio-Steuerungsebene verwendet wird.
• Zwei Projekte stehen für 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 Rahmen von GitOps in den Clustern bereitzustellen.
• Ein Cloud Build-Trigger wird erstellt, sodass bei jedem Commit für den Master-Branch von k8s-repo die Kubernetes-Manifeste aus den jeweiligen Ordnern in GKE-Clustern bereitgestellt werden.

Das Terraform-Skript dauert 40 bis 50 Minuten.

10. Sobald der Build im terraform admin project abgeschlossen ist, wird ein weiterer Build im Ops-Projekt gestartet. Klicken Sie auf den angezeigten Link, um die Cloud Build-Seite für ops project zu öffnen und zu prüfen, ob das Cloud Build-Repository 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. kubeconfig-Dateien für alle Cluster erstellen 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 der Datei „.bashrc“ in Cloud Shell die Variablen vars .sh und KUBECONFIG hinzu, damit sie bei jedem Neustart von Cloud Shell abgerufen wird.

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

14. Listen Sie die 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 überprüfen

15. Achten Sie darauf, dass Istio in beiden Clustern installiert ist. Prüfen Sie dazu, ob alle Pods ausgeführt werden und die Jobs abgeschlossen wurden.

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. Achten Sie darauf, dass Istio in beiden dev1-Clustern installiert ist. In den dev1-Clustern werden nur Citadel, Sidecar-Injektor und Coredns ausgeführt. Sie nutzen eine Istio-Steuerungsebene, die im Ops-1-Cluster ausgeführt wird.

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

17. Achten Sie darauf, dass Istio in beiden dev2-Clustern installiert ist. In den dev2-Clustern werden nur Citadel, Sidecar-Injektor und Coredns ausgeführt. Sie nutzen eine Istio-Steuerungsebene, die im Ops-2-Cluster 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 freigegebene Steuerungsebenen prüfen

18. Prüfen Sie optional, 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 Vorgangsclustern erstellt wurden. Pilot verwendet diese Secrets, um Dienste durch Abfrage des Kube API-Servers der Anwendungscluster zu ermitteln (über die oben genannten Secrets authentifiziert). Sie sehen, dass sich beide Vorgangscluster mithilfe von Secrets, die in der Binärdatei erstellt wurden, bei allen Anwendungsclustern authentifizieren können. Ops-Cluster können Dienste automatisch mithilfe der kubeconfig-Dateien als Secret-Methode erkennen. Dazu muss der Pilot in den Vorgangsclustern Zugriff auf den Kube API-Server aller anderen Cluster haben. Wenn Pilot die Kube API-Server nicht erreichen kann, fügen Sie Remote-Dienste manuell als ServiceEntries hinzu. Sie können sich ServiceEntries als DNS-Einträge in Ihrer Dienstregistrierung vorstellen. ServiceEinträge definieren einen Dienst mithilfe eines voll qualifizierten DNS-Namens ( FQDN) und einer IP-Adresse, unter der er erreicht werden kann. Weitere Informationen finden Sie in der Istio-Multicluster-Dokumentation.

6. Infrastruktur-Repository

Infrastruktur von Cloud Build

Die GCP-Ressourcen für den Workshop werden mit Cloud Build und einem CSR-Repository infrastructure erstellt. Sie haben gerade ein Bootstrap-Skript (unter scripts/bootstrap_workshop.sh) von Ihrem lokalen Terminal aus ausgeführt. Das Bootstrap-Skript erstellt einen GCP-Ordner, ein Terraform-Administratorprojekt und die entsprechenden IAM-Berechtigungen für das Cloud Build-Dienstkonto. Ein Terraform-Administratorprojekt wird zum Speichern von Terraform-Status, Logs und verschiedenen Skripts verwendet. Sie enthält die CSR-Repositories infrastructure und k8s_repo. Diese Repositories werden im nächsten Abschnitt ausführlich erläutert. Im Terraform-Administratorprojekt werden keine anderen Workshop-Ressourcen erstellt. Das Cloud Build-Dienstkonto im Terraform-Administratorprojekt wird verwendet, um Ressourcen für den Workshop zu erstellen.

Mit der Datei cloudbuild.yaml im Ordner infrastructure werden GCP-Ressourcen für den Workshop erstellt. 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, jq usw. Das benutzerdefinierte Builder-Image führt terraform plan und apply für jede Ressource aus. Die Terraform-Dateien jeder Ressource befinden sich in separaten Ordnern. Weitere Informationen finden Sie im nächsten Abschnitt. Die Ressourcen werden einzeln in der Reihenfolge erstellt, wie sie normalerweise aufgebaut werden (z. B. wird ein GCP-Projekt vor den Ressourcen im Projekt erstellt). Weitere Informationen finden Sie in der Datei cloudbuild.yaml.

Cloud Build wird jedes Mal ausgelöst, wenn ein Commit für das Repository infrastructure vorhanden ist. Jede Änderung an der Infrastruktur wird als Infrastruktur als Code (IaC) gespeichert und per Commit in das Repository übertragen. Der Status Ihres Workshops wird immer in diesem Repository gespeichert.

Ordnerstruktur – Teams, Umgebungen und Ressourcen

Das Infrastruktur-Repository richtet die GCP-Infrastrukturressourcen für den Workshop ein. Sie ist in Ordnern und Unterordnern strukturiert. Die Basisordner im Repository stellen die team dar, die bestimmte GCP-Ressourcen besitzen. Die nächste Ordnerebene stellt die spezifische environment für das Team dar (z. B. für Entwicklung, Phase, Produktion). Die nächste Ordnerebene in der Umgebung stellt die spezifische resource dar, z. B. „host_project“ oder „gke_clusters“. Die erforderlichen Skripts und Terraform-Dateien befinden sich in den Ressourcenordnern.

Die folgenden vier Arten von Teams sind in diesem Workshop vertreten:

1. Infrastructure – Vertreten für das Cloud-Infrastrukturteam. Er ist für die Erstellung der GCP-Ressourcen für alle anderen Teams verantwortlich. Er verwendet für seine Ressourcen das Terraform-Administratorprojekt. Das Infrastruktur-Repository selbst befindet sich im Terraform-Administratorprojekt sowie in den Terraform-Zustandsdateien (siehe unten). Diese Ressourcen werden während des Bootstrap-Prozesses von einem Bash-Skript erstellt (weitere Details finden Sie in Modul 0 – Administrator-Workflow).
2. network – steht für das Netzwerkteam. Er ist für VPC- und Netzwerkressourcen verantwortlich. Sie sind Inhaber der folgenden GCP-Ressourcen.
3. host project: steht für das freigegebene VPC-Hostprojekt.
4. shared VPC: steht für die freigegebene VPC, die Subnetze, sekundäre IP-Bereiche, Routen und Firewallregeln.
5. Ops: steht für das Operations-/DevOps-Team. Ihnen gehören die folgenden Ressourcen.
6. ops project: steht für ein Projekt für alle Vorgangsressourcen.
7. gke clusters: ein GKE-Cluster für Ops pro Region. Die Istio-Steuerungsebene ist in jedem der GKE-Cluster der Operation installiert.
8. k8s-repo: ein CSR-Repository, das GKE-Manifeste für alle GKE-Cluster enthält.
9. apps steht für die Anwendungsteams. In diesem Workshop werden zwei Teams simuliert, nämlich app1 und app2. Ihnen gehören die folgenden Ressourcen.
10. app projects: Jedes App-Team erhält seine eigenen Projekte. Auf diese Weise können sie die Abrechnung und IAM für ihr Projekt steuern.
11. gke clusters: Dies sind Anwendungscluster, in denen die Anwendungscontainer/-Pods ausgeführt werden.
12. gce instances – optional, wenn Anwendungen auf GCE-Instanzen ausgeführt werden In diesem Workshop gibt es für app1 einige GCE-Instanzen, in denen ein Teil der Anwendung ausgeführt wird.

In diesem Workshop repräsentiert dieselbe App (Hipster Shop-App) sowohl app1 als auch app2.

Anbieter, Status und Ausgaben: Back-Ends und freigegebene Status

Die Anbieter google und google-beta befinden sich unter gcp/[environment]/gcp/provider.tf. Die Datei provider.tf wird in jedem Ressourcenordner über symlinked verknüpft. 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 (templates/backend.tf_tmpl) mithilfe eines Skripts (unter scripts/setup_terraform_admin_project) generiert und dann im entsprechenden Ressourcenordner abgelegt. Google Cloud Storage-Buckets (GCS) werden für Back-Ends verwendet. Der Name des GCS-Bucket-Ordners stimmt mit dem Ressourcennamen überein. 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 Back-End für die jeweilige Ressource definiert ist. Wenn Sie beispielsweise einen GKE-Cluster in einem Projekt erstellen möchten, müssen Sie die Projekt-ID kennen. Die Projekt-ID wird über die Datei „output.tf“ an die tfstate-Datei ausgegeben, die über eine terraform_remote_state-Datenquelle in der GKE-Clusterressource verwendet werden kann.

Die Datei „shared_state“ ist eine Datenquelle terraform_remote_state, die auf die tfstate-Datei einer Ressource verweist. In den Ressourcenordnern, die Ausgaben von anderen Ressourcen benötigen, sind eine oder mehrere shared_state_[resource_name].tf-Dateien vorhanden. Im Ressourcenordner ops_gke befinden sich beispielsweise „shared_state“-Dateien der Ressourcen ops_project und shared_vpc, 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) mithilfe eines Scripts (unter scripts/setup_terraform_admin_project) generiert. Alle Ressourcen „shared_state“-Dateien werden im Ordner „gcp/[environment]/shared_states“ abgelegt. Die erforderlichen „shared_state“-Dateien werden in den entsprechenden Ressourcenordnern per Symlink verknüpft. Durch das Ablegen aller Dateien vom Typ „shared_state“ in einem Ordner und das Verknüpfen mit einem Sym in den entsprechenden Ressourcenordnern können alle Statusdateien zentral verwaltet werden.

Variablen

Alle Ressourcenwerte werden als Umgebungsvariablen gespeichert. Diese Variablen werden als Exportanweisungen in einer Datei namens vars.sh gespeichert, die sich in einem GCS-Bucket im Terraform-Administratorprojekt befindet. Enthält Organisations-ID, Rechnungskonto, Projekt-IDs, Details zum GKE-Cluster usw. Sie können vars.sh von jedem Terminal herunterladen und beschaffen, um die Werte für Ihre Einrichtung zu erhalten.

Terraform-Variablen werden in vars.sh als TF_VAR_[variable name] gespeichert. Mit diesen Variablen wird eine variables.tfvars-Datei im jeweiligen Ressourcenordner generiert. Die Datei variables.tfvars enthält alle Variablen und die zugehörigen Werte. Die Datei variables.tfvars wird mithilfe eines Skripts (unter scripts/setup_terraform_admin_project) aus einer Vorlagendatei im selben Ordner generiert.

Erklärung zum K8s-Repository

k8s_repo ist ein vom Infrastruktur-Repository getrenntes CSR-Repository im Terraform-Administratorprojekt. Damit werden GKE-Manifeste gespeichert und auf alle GKE-Cluster angewendet. k8s_repo wird von der Infrastruktur von Cloud Build erstellt. Weitere Informationen finden Sie im vorherigen Abschnitt. Während der anfänglichen Infrastruktur von Cloud Build werden insgesamt sechs GKE-Cluster erstellt. Im k8s_repo werden sechs Ordner erstellt. Jeder Ordner (Name, der dem GKE-Clusternamen entspricht) entspricht einem GKE-Cluster, der die entsprechenden Ressourcenmanifestdateien enthält. Ähnlich wie beim Erstellen von Infrastruktur werden mit Cloud Build die Kubernetes-Manifeste mithilfe von k8s_repo auf alle GKE-Cluster angewendet. Cloud Build wird jedes Mal ausgelöst, wenn ein Commit für das Repository k8s_repo vorliegt. Ähnlich wie bei der Infrastruktur werden alle Kubernetes-Manifeste als Code im Repository k8s_repo gespeichert und der Status jedes GKE-Clusters wird immer im entsprechenden Ordner gespeichert.

Im Rahmen des ersten Infrastruktur-Builds wird k8s_repo erstellt und Istio auf allen Clustern installiert.

Projekte, GKE-Cluster und Namespaces

Die Ressourcen in diesem Workshop sind auf verschiedene GCP-Projekte aufgeteilt. Projekte sollten der Organisations- oder Teamstruktur Ihres Unternehmens entsprechen. Teams in Ihrer Organisation, die für verschiedene Projekte/Produkte/Ressourcen verantwortlich sind, verwenden unterschiedliche GCP-Projekte. Mit separaten Projekten können Sie separate IAM-Berechtigungen erstellen und die Abrechnung auf Projektebene verwalten. Darüber hinaus werden Kontingente auch auf Projektebene verwaltet.

In diesem Workshop werden fünf Teams vertreten, die jeweils ihr eigenes Projekt haben.

1. Das Infrastrukturteam, das GCP-Ressourcen erstellt, verwendet die Terraform admin project. Sie verwalten die Infrastruktur als Code in einem CSR-Repository (mit dem Namen infrastructure) und speichern alle Terraform-Statusinformationen zu Ressourcen, die in der GCP in GCS-Buckets erstellt wurden. Sie steuern den Zugriff auf die GCS-Buckets für das CSR-Repository und 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 Netzwerke für GCP-Ressourcen zentral verwalten. Alle Projekte haben diese einzelne freigegebene VPC für das Netzwerk verwendet.
3. Das Ops/Platform-Team, 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 Ausfallsicherheit und Skalierung der Kubernetes-Plattform verantwortlich. In diesem Workshop verwenden Sie die gitops-Methode, um Ressourcen in Kubernetes bereitzustellen. Im Ops-Projekt ist ein CSR-Repository (mit dem Namen k8s_repo) vorhanden.
4. Zu guter Letzt verwenden die dev1- und dev2-Teams (vertreten für zwei Entwicklungsteams), die Anwendungen erstellen, ihre eigenen dev1 und dev2 projects. Dies sind die Anwendungen und Dienste, die Sie Ihren Kunden anbieten. Diese basieren auf der Plattform, die das Ops-Team verwaltet. Die Ressourcen (Deployments, Dienste usw.) werden per Push an k8s_repo übertragen und in den entsprechenden Clustern bereitgestellt. Beachten Sie, dass sich dieser Workshop nicht auf Best Practices und Tools für CI/CD konzentriert. Mit Cloud Build können Sie das direkte Bereitstellen von Kubernetes-Ressourcen in den GKE-Clustern automatisieren. 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 verwendet, um DevOps-Tools auszuführen. In diesem Workshop führen sie die ASM/Istio-Steuerungsebene aus, um das Service Mesh zu verwalten.
2. Anwendungscluster (Apps) – werden von den Entwicklungsteams zum Ausführen von Anwendungen verwendet. In diesem Workshop wird die Hipster-Shop-App eingesetzt.

Durch die Trennung der Vorgangs-/Admin-Tools von den Clustern, auf denen die Anwendung ausgeführt wird, können Sie den Lebenszyklus jeder Ressource unabhängig verwalten. Die beiden Clustertypen existieren auch in verschiedenen Projekten zu dem Team/Produkt, von dem sie verwendet werden, was die Verwaltung von IAM-Berechtigungen erleichtert.

Es gibt insgesamt sechs GKE-Cluster. Im Ops-Projekt werden zwei regionale Vorgangscluster erstellt. Die ASM/Istio-Steuerungsebene ist in beiden Ops-Clustern installiert. Jeder Vorgangscluster befindet sich in einer anderen Region. Darüber hinaus gibt es vier zonale Anwendungscluster. Diese werden in eigenen Projekten erstellt. In diesem Workshop werden zwei Entwicklungsteams mit jeweils eigenen Projekten simuliert. Jedes Projekt enthält zwei Anwendungscluster. Anwendungscluster sind zonale Cluster in verschiedenen Zonen. Die vier Anwendungscluster befinden sich in zwei Regionen und vier Zonen. Auf diese Weise erhalten Sie regionale und zonale Redundanz.

Die in diesem Workshop verwendete Anwendung, die Hipster Shop-Anwendung, wird in allen vier Anwendungs-Clustern bereitgestellt. Jeder Mikrodienst befindet sich in jedem Anwendungscluster in einem eigenen Namespace. Deployments (Pods) der Hipster Shop-Anwendung werden nicht in den Vorgangsclustern bereitgestellt. Die Namespaces und Dienstressourcen für alle Mikrodienste werden jedoch auch in den Vorgangsclustern erstellt. Die ASM-/Istio-Steuerungsebene verwendet die Dienstregistrierungen von Kubernetes für die Diensterkennung. Falls keine Dienste vorhanden sind (in den Vorgangsclustern), müssen Sie für jeden im Anwendungscluster ausgeführten Dienst manuell ServiceEntries erstellen.

In diesem Workshop stellen Sie eine zehnstufige Mikrodienstanwendung bereit. Die Anwendung ist eine webbasierte E-Commerce-App namens Hipster Shop wo Nutzer nach Artikeln suchen, sie in den Warenkorb legen und sie kaufen können.

Kubernetes-Manifeste und k8s_repo

Mit k8s_repo fügen Sie allen GKE-Clustern Kubernetes-Ressourcen hinzu. Kopieren Sie dazu Kubernetes-Manifeste und übergeben Sie ein Commit an 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, der nach dem Clusternamen benannt ist.

Die sechs Clusternamen sind:

1. gke-asm-1-r1-prod – der regionale Vorgangscluster in Region 1
2. gke-asm-2-r2-prod – der regionale Vorgangscluster in Region 2
3. gke-1-apps-r1a-prod – der Anwendungscluster in Region 1, Zone a
4. gke-2-apps-r1b-prod – der Anwendungscluster in Region 1, Zone b
5. gke-3-apps-r2a-prod – der Anwendungscluster in Region 2, Zone a
6. gke-4-apps-r2b-prod – der Anwendungscluster in Region 2, Zone b

k8s_repo enthält Ordner, die diesen Clustern entsprechen. Jedes Manifest, das sich in diesen Ordnern befindet, wird 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 bereitgestellte Ressourcen zu behalten. Weitere Informationen finden Sie in der offiziellen Kustomize-Dokumentation.

7. Beispielanwendung bereitstellen

Ziel: Hipster Shop-Anwendung in Anwendungsclustern bereitstellen

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

SKRIPT FÜR DEN SCHNELLEN TRACK

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

Anleitung zum Kopieren und Einfügen für das Methoden-Lab

Wenn Sie das Schnellverfahren für dieses Lab bereits ausgefüllt haben, führen Sie nicht die unten gezeigte Methode zum Kopieren und Einfügen aus**.**

Quell-Repository des Ops-Projekts klonen

Als Teil des ersten Terraform-Infrastruktur-Builds wurde die k8s-repo bereits im Ops-Projekt erstellt.

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

mkdir $WORKDIR/k8s-repo
 

2. Starten Sie das Git-Repository, fügen Sie remote hinzu und rufen Sie den Master aus dem Remote-Repository ab:

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. Legen Sie die lokale Konfiguration für das lokale Git fest.

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, Commit durchführen und Push übertragen

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 den Anwendungsordner „kustomization.yaml“ 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-Deployments, RBAC und PodSecurityPolicy in das Quell-Repository für die Anwendungscluster.

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, den rbac und die podsecuritypolicy aus allen Entwicklungsclustern bis auf einen. Hipstershop wurde nicht für die Multi-Cluster-Bereitstellung entwickelt. Um inkonsistente Ergebnisse zu vermeiden, verwenden wir nur einen Einkaufswagendienst.

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 der Datei „kustomization.yaml“ im ersten Entwicklungscluster die Bereitstellung von „cartservice“, rbac und podsecuritypolicy 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 von podsecuritypolicies, Deployments und rbac-Verzeichnissen aus Ops-Clustern kustomization.yaml

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

10. 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 Manifeste IngressGateway und VirtualService in das Quell-Repository für die Vorgangscluster.

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 Vorgangscluster. Die Anwendung "Hipster Shop" wird über einen globalen Google Cloud Load Balancer (GCLB) bereitgestellt. Der GCLB empfängt Client-Traffic (für frontend bestimmt) und sendet ihn an die nächstgelegene Instanz des Dienstes. Wenn Sie loadgenerator in beiden Vorgangsclustern platzieren, wird der Traffic an beide Istio-Ingress-Gateways gesendet, die in den Vorgangsclustern 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 Vorgangsprojekt-ID in den loadgenerator-Manifesten für beide Vorgangscluster.

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 der Datei „kustomization.yaml“ für beide Vorgangscluster die loadgenerator-Ressourcen 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. Commit von 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 Ops-Projekts Cloud Build in einem zuvor geöffneten Tab oder durch Klicken auf den folgenden Link an:

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

Anwendungsbereitstellung prüfen

19. Prüfen Sie, ob Pods in allen Anwendungs-Namespaces mit Ausnahme des Einkaufswagens in allen Entwicklungsclustern den Status „Wird ausgeführt“ haben.

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 Pods im Einkaufswagen-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

Sie haben jetzt die Hipster Shop-Anwendung in allen vier Anwendungsclustern bereitgestellt. Diese Cluster befinden sich in zwei Regionen und vier Zonen. Clients können über den Dienst frontend auf die Hipster Shop-Anwendung zugreifen. Der Dienst frontend wird auf allen vier Anwendungsclustern ausgeführt. Ein Google Cloud Load Balancer ( GCLB) wird verwendet, um Client-Traffic zu allen vier Instanzen des frontend-Dienstes zu erhalten.

Istio-Ingress-Gateways werden nur in den Vorgangsclustern ausgeführt und dienen als regionaler Load-Balancer für die beiden zonalen Anwendungscluster innerhalb der Region. GCLB verwendet die beiden Istio-Ingress-Gateways, die in den beiden Vorgangsclustern ausgeführt werden, als Back-Ends für den globalen Front-End-Dienst. Die Istio-Ingress-Gateways empfangen den Clienttraffic vom GCLB und senden ihn dann weiter an die Front-End-Pods, die in den Anwendungsclustern ausgeführt werden.

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

GKE Autoneg-Controller

Kubernetes Service des Istio-Ingress-Gateways registriert sich beim GCLB mithilfe von Netzwerk-Endpunktgruppen (NEGs) als Back-End. NEGs ermöglichen containernatives Load-Balancing mithilfe von GCLBs. NEGs werden über eine spezielle Annotation in einem Kubernetes-Dienst erstellt, damit sie 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 Back-Ends einem GCLB zuweist. Istio-Steuerungsebenen, einschließlich der Istio-Ingress-Gateways, werden während der ersten Terraform-Infrastruktur von Cloud Build bereitgestellt. Die Konfiguration von GCLB und autoneg erfolgt im Rahmen der ersten Terraform-Infrastruktur von Cloud Build.

Eingehenden Traffic mit Cloud Endpoints und verwalteten Zertifikaten sichern

GCP-verwaltete Zertifikate werden verwendet, um den Clienttraffic zum GCLB-Dienst frontend zu sichern. Der GCLB verwendet verwaltete Zertifikate für den globalen frontend-Dienst und das Zertifikat wird beim 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 der GCP verwaltete Zertifikate zu erstellen.

21. Klicken Sie auf die Linkausgabe des folgenden Befehls, 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 überprü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 operativen Clustern Lastgeneratoren bereitgestellt, die Test-Traffic zum Cloud Endpoints-Link GCLB Hipster Shop generieren. Prüfen Sie, ob der GCLB Traffic empfängt und an beide Ingress-Gateways von Istio sendet.

23. GCLB herunterladen > Monitoring-Link für das Ops-Projekt, in dem der Google Cloud-Speicher „Hipster Shop“ erstellt wird.

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ü „Back-End“ wie unten gezeigt von All Backends (Alle Backends) zu istio-ingressgateway.

25. Beachten Sie, dass Traffic zu beiden istio-ingressgateways fließt.

Pro istio-ingressgateway werden drei NEGs erstellt. Da es sich bei den Vorgangsclustern um regionale Cluster handelt, 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 Ops-Clustern ausgeführt, um den Clienttraffic aus den beiden Regionen zu simulieren, in denen sie sich befinden. Die in der Region 1 des Vorgangs-Clusters generierte Last wird an istio-ingressgateway in Region 2 gesendet. Analog wird die in der Region 2 des Vorgangs-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

SKRIPT FÜR DEN SCHNELLEN TRACK

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

Anleitung zum Kopieren und Einfügen für das Methoden-Lab

Wenn Sie das Schnellverfahren für dieses Lab bereits ausgefüllt haben, führen Sie nicht die unten gezeigte Methode zum Kopieren und Einfügen aus**.**

Eines der Hauptfunktionen von Istio ist die integrierte Beobachtbarkeit („o11y“). Das bedeutet, dass Betreiber auch mit nicht instrumentierten Blackbox-Containern den Traffic in und aus diesen Containern beobachten können und so Dienste für ihre Kunden bereitstellen. Dabei gibt es verschiedene Methoden: Messwerte, Logs und Traces.

Wir werden auch das integrierte System zur Lastgenerierung in Hipster Shop verwenden. Die Beobachtbarkeit funktioniert in einem statischen System ohne Traffic nicht sehr gut. Daher hilft uns die Lastgenerierung, zu verstehen, wie sie funktioniert. Dieser Ladevorgang wird bereits ausgeführt. Jetzt können wir ihn nur noch sehen.

1. Installieren Sie die Istio-für-Stackdriver-Konfigurationsdatei.

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. Commit für k8s-repo.

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

3. Sehen Sie sich den Status des Ops-Projekts Cloud Build in einem zuvor geöffneten Tab oder durch Klicken auf den folgenden Link an:

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

4. Prüfen Sie die Istio → Stackdriver-Integration. Rufen Sie die Stackdriver-Handler-CRD 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 für die Ausgabe dieses Befehls:

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. Klicken Sie einfach auf „OK“. Wenn Sie zur neuen Benutzeroberfläche gefragt werden, schließen Sie einfach das Dialogfeld.

Im Metrics Explorer unter „Ressourcentyp und Messwert finden“ Gib „istio“ ein um Optionen wie "Anzahl der Serveranfragen" für den „Kubernetes Container“ Ressourcentyp. Dies zeigt, dass die Messwerte vom Mesh-Netzwerk an Stackdriver übertragen werden.

(Sie müssen das Label „Gruppieren nach“ destination_service_name verwenden, wenn Sie die Linien unten sehen möchten.)

Messwerte mit Dashboards visualisieren:

Da sich unsere Messwerte nun im Stackdriver APM-System befinden, möchten wir sie visualisieren. In diesem Abschnitt installieren wir ein vordefiniertes Dashboard, das uns die drei der vier „ Goldene Signale“ von Messwerten: Traffic (Anfragen pro Sekunde), Latenz (in diesem Fall 99. und 50. Perzentil) und Fehler (in diesem Beispiel schließen wir die Sättigung aus).

Der Envoy-Proxy von Istio stellt uns mehrere Messwerte bereit, die jedoch für den Anfang gut geeignet sind. Eine vollständige Liste finden Sie hier. Beachten Sie, dass jeder Messwert eine Reihe von Labels hat, die zum Filtern und Zusammenfassen verwendet werden können, z. B. „destination_service“, „source_workload_namespace“, „response_code“, „istio_tcp_received_bytes_total“ usw.

6. Fügen wir nun das Dashboard mit vordefinierten Messwerten hinzu. Wir verwenden direkt die Dashboard API. Dies würden Sie normalerweise nicht tun, indem Sie API-Aufrufe manuell generieren, es 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. Gehen Sie zum Ausgabelink unten, um das neu hinzugefügte „Services-Dashboard“ anzusehen.

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

Wir könnten das Dashboard direkt mit der UX bearbeiten, aber in unserem Fall werden wir mit der API schnell eine neue Grafik hinzufügen. Dazu sollten Sie die neueste Version des Dashboards herunterladen, Ihre Änderungen anwenden und sie dann mit der HTTP-PATCH-Methode wieder nach oben verschieben.

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. Perzentillatenz): [ 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, das eine Latenz von 50 % (Medianlatenz) anzeigt.

Versuchen Sie, das soeben erhaltene Dashboard zu bearbeiten, indem Sie eine neue Stanza hinzufügen:

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. Aktualisieren Sie das vorhandene Service-Dashboard:

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 einige einfache Loganalysen durch.

Istio bietet eine Reihe von strukturierten Logs für den gesamten In-Mesh-Netzwerktraffic und lädt diese in Stackdriver Logging hoch, um eine clusterübergreifende Analyse in einem leistungsstarken Tool zu ermöglichen. Logs werden mit Metadaten auf Dienstebene wie Cluster, Container, Anwendung, connection_id usw. annotiert.

Ein Beispiel-Logeintrag (in diesem Fall das Zugriffslog des Envoy-Proxys) könnte wie folgt aussehen (abgeschnitten):

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

Sehen Sie sich Ihre Logs hier an:

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

Sie können die Logs der Steuerungsebene von Istio unter „Ressource“ > „Ressourcen“ aufrufen. Kubernetes-Container und die Suche nach „Pilot“ –

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

Neben den Logs von Istio finden Sie auch Containerlogs sowie Infrastruktur- oder andere GCP-Dienste-Logs über dieselbe Schnittstelle. Hier sind einige Beispiel-Logabfragen für GKE. In der Loganzeige können Sie außerdem Messwerte aus Logs erstellen (z. B. „Jeden Fehler zählen, der mit einem String übereinstimmt“), die in einem Dashboard oder als Teil einer Benachrichtigung verwendet werden können. Logs können auch in andere Analysetools wie BigQuery gestreamt werden.

Hier sind einige Beispielfilter für den Hipster-Shop:

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

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

13. Verteilte Traces ausprobieren

Da Sie nun mit einem verteilten System arbeiten, ist für die Fehlerbehebung ein neues Tool erforderlich: Verteiltes Tracing. Mit diesem Tool können Sie Statistiken dazu abrufen, wie Ihre Dienste interagieren, wie z. B. langsame Ereignisse in der Abbildung unten, die sich außerhalb liegen lassen, und in Rohbeispiel-Traces eintauchen, um die Details zu untersuchen.

In der Zeitachsenansicht werden alle Anfragen im Zeitverlauf dargestellt, dargestellt als ihre Latenz oder die Zeit, die zwischen der ersten Anfrage über den Hipster-Stack verstreicht, um dem Endnutzer zu antworten. Je höher die Punkte, desto langsamer (und weniger zufrieden!) ist die User Experience.

Sie können auf einen Punkt klicken, um die detaillierte Wasserfall-Ansicht für diese bestimmte Anfrage aufzurufen. Diese Fähigkeit, die rohen Details einer bestimmten Anfrage zu finden (nicht nur aggregierte Statistiken), ist entscheidend für das Verständnis des Zusammenspiels zwischen Diensten, insbesondere bei der Suche nach seltenen, aber schlechten Interaktionen zwischen Diensten.

Die Wasserfallansicht sollte jedem, der einen Debugger verwendet hat, vertraut sein. In diesem Fall wird jedoch nicht die Zeit angezeigt, die in verschiedenen Prozessen einer einzelnen Anwendung verbracht wurde, sondern die Zeit, die beim Durchlaufen unseres Mesh-Netzwerks, zwischen Diensten, in separaten Containern ausgeführt wird.

Hier finden Sie Ihre Traces:

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 durch Prüfen von Logs prüfen

SKRIPT FÜR DEN SCHNELLEN TRACK

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

Anleitung zum Kopieren und Einfügen für das Methoden-Lab

Wenn Sie das Schnellverfahren für dieses Lab bereits ausgefüllt haben, führen Sie nicht die unten gezeigte Methode zum Kopieren und Einfügen aus**.**

Nachdem unsere Apps installiert und die Beobachtbarkeit eingerichtet ist, können wir damit beginnen, die Verbindungen zwischen Diensten zu sichern und dafür zu sorgen, dass sie weiterhin funktioniert.

Beispielsweise können wir im Kiali-Dashboard sehen, dass unsere Dienste kein MTLS verwenden (kein Schloss-Symbol). Aber der Verkehr fließt und das System funktioniert einwandfrei. Unser StackDriver Golden Metrics-Dashboard gibt uns die Gewissheit, dass alles funktioniert.

1. MeshPolicy in Vorgangsclustern prüfen. Hinweis: mTLS ist PERMISSIVE, was sowohl verschlüsselten als auch Nicht-mTLS-Traffic ermöglicht.

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 "IstioControlPlane" verwendet. Wir konfigurieren mTLS in allen Clustern, indem wir die Antwortvorlage „IstioControlPlane“ und das k8s-Repository aktualisieren. Einstellung global > mTLS > enabled: true in der Antwortvorlage "IstioControlPlane" führt zu den folgenden beiden Änderungen an der Istio-Steuerungsebene:

• MeshPolicy ist so eingestellt, dass mTLS-weites Mesh-Netzwerk für alle Dienste aktiviert ist, die in allen Clustern ausgeführt werden.
• Es wird eine DestinationRule erstellt, die ISTIO_MUTUAL-Traffic zwischen Diensten zulässt, 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 benutzerdefinierten 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. Commit für k8s-repo.

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

4. Sehen Sie sich den Status des Ops-Projekts Cloud Build in einem zuvor geöffneten Tab oder durch Klicken auf den folgenden Link an:

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

 

mTLS überprüfen

5. Prüfen Sie MeshPolicy noch einmal in den Vorgangsclustern. 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
      }
   }
}

In den Protokollen ist auch der Wechsel von HTTP zu HTTPS zu erkennen.

Wir können dieses bestimmte Feld aus den Protokollen in der Benutzeroberfläche sichtbar machen, indem wir auf einen Logeintrag und dann auf den Wert des anzuzeigenden Feldes klicken. In unserem Fall klicken Sie auf "http". neben „Protokoll:

So lässt sich der Wechsel gut visualisieren:

10. Canary-Bereitstellungen

Ziel: Roll-out einer neuen Version des Front-End-Dienstes ausführen.

• Roll-out des Dienstes frontend-v2 (nächste Produktionsversion) in einer Region ausführen
• DestinationRules und VirtualServices verwenden, um den Verkehr langsam auf frontend-v2 zu lenken
• GitOps-Bereitstellungspipeline durch Überprüfen einer Reihe von Commits für den k8s-repo prüfen

SKRIPT FÜR DEN SCHNELLEN TRACK

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

Anleitung zum Kopieren und Einfügen für das Methoden-Lab

Wenn Sie das Schnellverfahren für dieses Lab bereits ausgefüllt haben, führen Sie nicht die unten gezeigte Methode zum Kopieren und Einfügen aus**.**

Ein Canary-Deployment ist ein schrittweises Roll-out eines neuen Dienstes. Bei einer Canary-Bereitstellung senden Sie eine zunehmende Menge an Traffic an die neue Version, während der verbleibende Prozentsatz weiterhin an die aktuelle Version gesendet wird. Ein gängiges Muster ist die Durchführung einer Canary-Analyse in jeder Phase der Traffic-Aufteilung und der Vergleich der goldenen Signale. der neuen Version (Latenz, Fehlerrate, Sättigung) im Vergleich zu einer Referenz. So lassen sich Ausfälle vermeiden und die Stabilität der neuen Version 2 in jeder Phase der Traffic-Aufteilung.

In diesem Abschnitt erfahren Sie, wie Sie mithilfe von Cloud Build- und Istio-Trafficrichtlinien ein einfaches Canary-Deployment für eine neue Version des Diensts frontend erstellen.

Zuerst führen wir die Canary-Pipeline in der DEV1-Region (us-west1) aus und führen Frontend v2 auf beiden Clustern in dieser Region ein. Dann führen wir die Canary-Pipeline in der DEV2-Region (us-central) aus und stellen v2 in beiden Clustern in dieser Region bereit. Wenn Sie die Pipeline auf Regionen geordnet und parallel über alle Regionen hinweg ausführen, können Sie globale Ausfälle vermeiden, die durch eine fehlerhafte Konfiguration oder Fehler in der v2-Anwendung selbst verursacht werden.

Hinweis: Die Canary-Pipeline wird in beiden Regionen manuell ausgelöst. In der Produktion würden Sie jedoch einen automatisierten Trigger verwenden, z. B. auf Grundlage eines neuen Docker-Image-Tags, 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 Skript „repo_setup.sh“ aus, um die Referenzmanifeste in das Repository „k8s-repo“ zu kopieren.

$CANARY_DIR/repo-setup.sh 
 

Die folgenden Manifeste werden kopiert:

• Bereitstellung von frontend-v2
• frontend-v1-Patch (um das Label "v1" und ein Image mit einem Endpunkt "/version" einzuschließen)
• respy, einem kleinen Pod, der die Verteilung der HTTP-Antwort ausgibt und uns hilft, das Canary-Deployment in Echtzeit zu visualisieren.
• Frontend-Istio DestinationRule: teilt den Kubernetes-Dienst des Frontends basierend auf der "Version" in zwei Teilmengen, v1 und v2, auf. Bereitstellungslabel
• 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 werden.

3. Commit für Änderungen an k8s_repo durchführen:

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

4. Sehen Sie sich den Status des Ops-Projekts Cloud Build in einem zuvor geöffneten Tab oder durch Klicken auf 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 für das OPS1-Projekt Cloud Build auf. Warten Sie, bis die Cloud Build-Pipeline abgeschlossen ist und rufen Sie dann Pods im Front-End-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: Strg+C zum Beenden der Uhr-Befehle

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

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

6. Teilen Sie das Cloud Shell-Fenster mit dem Befehl auf und führen Sie im unteren Bereich den Befehl „watch“ aus.

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%            |
|          |                   |
+----------+-------------------+

Sie sehen, dass der gesamte Traffic zum Frontend v1-Deployment geht, das im neuen VirtualService definiert ist.

7. Führen Sie die Canary-Pipeline in der Dev1-Region aus. Wir stellen ein Skript bereit, mit dem die Prozentsätze des Frontend-v2-Traffics im VirtualService aktualisiert werden (die Gewichtungen werden auf 20%, 50%, 80 % und dann 100 % aktualisiert). Zwischen den Aktualisierungen wartet das Skript auf den Abschluss der Cloud Build-Pipeline. Führen Sie das Canary-Bereitstellungsskript für die Region Dev1 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
 

Sie können die Trafficaufteilung in Echtzeit im unteren Fenster sehen, in dem Sie den Befehl „respy“ ausführen. Zum Beispiel an der 20-%-Marke :

Ausgabe (nicht kopieren)

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

8. Sobald das Dev2-Roll-out für frontend-v2 abgeschlossen ist, sollten Sie am Ende des Skripts eine Erfolgsmeldung sehen:

    Output (do not copy) 
   

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

9. Und der gesamte Frontend-Traffic von einem Dev2-Pod sollte an frontend-v2 gehen:

    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 neueste Commit steht dabei ganz oben in der Liste:

Jetzt wiederholen Sie diesen Vorgang für die Dev2-Region. Beachten Sie, dass die Dev2-Region immer noch "gesperrt" ist. zu v1. Das liegt daran, dass im Basisskript repo_setup ein VirtualService gesendet wurde, um den gesamten Traffic explizit an v1 zu senden. Auf diese Weise konnten wir einen regionalen Canary-Test auf Dev1 ausführen und prüfen, ob er erfolgreich ausgeführt wurde, bevor die neue Version global eingeführt wurde.

12. Teilen Sie das Cloud Shell-Fenster mit dem Befehl auf und führen Sie im unteren Bereich den Befehl „watch“ aus.

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%            |
|          |                   |
+----------+-------------------+

Sie sehen, dass der gesamte Traffic zum Frontend v1-Deployment geht, das 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 Prozentsätze des Frontend-v2-Traffics im VirtualService aktualisiert werden (die Gewichtungen werden auf 20%, 50%, 80 % und dann 100 % aktualisiert). Zwischen den Aktualisierungen wartet das Skript auf den Abschluss der Cloud Build-Pipeline. Führen Sie das Canary-Bereitstellungsskript für die Region Dev1 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 sich der Traffic von Dev2-Pods schrittweise von Frontend v1 zu v2 ändert. Sobald 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 die Verwendung von Istio für regionale Canary-Deployments erläutert. 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 hochgeladen wird. Außerdem können Sie zwischen den einzelnen Schritten eine Canary-Analyse hinzufügen, um die Latenz und Fehlerrate von V2 anhand eines vordefinierten Sicherheitsgrenzwerts zu analysieren, bevor mehr Traffic gesendet wird.

11. Autorisierungsrichtlinien

Ziel: RBAC zwischen Mikrodiensten (AuthZ) einrichten.

• Erstellen Sie AuthorizationPolicy, um den Zugriff auf einen Mikrodienst VERWEISEN zu lassen
• Erstellen Sie AuthorizationPolicy, um bestimmten Zugriff auf einen Mikrodienst zu gewähren.

SKRIPT FÜR DEN SCHNELLEN TRACK

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

Anleitung zum Kopieren und Einfügen für das Methoden-Lab

Wenn Sie das Schnellverfahren für dieses Lab bereits ausgefüllt haben, führen Sie nicht die unten gezeigte Methode zum Kopieren und Einfügen aus**.**

Im Gegensatz zu einer monolithischen Anwendung, die möglicherweise an einem Ort ausgeführt wird, senden global verteilte Mikrodienstanwendungen Aufrufe über Netzwerkgrenzen hinweg. Das bedeutet mehr Einstiegspunkte in Ihre Anwendungen und mehr Möglichkeiten für schädliche Angriffe. Da Kubernetes-Pods außerdem vorübergehende IP-Adressen haben, eignen sich herkömmliche IP-basierte Firewallregeln nicht mehr für einen sicheren Zugriff zwischen Arbeitslasten. In einer Mikrodienstarchitektur ist ein neuer Sicherheitsansatz erforderlich. Istio basiert auf Sicherheitsbausteinen von Kubernetes wie Dienstkonten und bietet flexible Sicherheitsrichtlinien für Ihre Anwendungen.

Istio-Richtlinien decken sowohl die Authentifizierung als auch die Autorisierung ab. Mit der Authentifizierung wird die Identität überprüft (Ist dieser Server der angegebene Server?) und mit der Autorisierung werden die Berechtigungen überprüft. Darf der Client das tun? Wir haben die Istio-Authentifizierung im Abschnitt zu gegenseitiger TLS-Authentifizierung in Modul 1 (MeshPolicy) behandelt. In diesem Abschnitt erfahren Sie, wie Sie mit Istio-Autorisierungsrichtlinien den Zugriff auf eine unserer Anwendungsarbeitslasten currencyservice steuern.

Zuerst stellen wir eine AuthorizationPolicy in allen vier Entwicklungsclustern bereit, sperren den Zugriff auf currencyservice und lösen im Front-End einen Fehler aus. Dann wird nur dem Front-End-Dienst der Zugriff auf "currencyservice" gewährt.

1. Prüfen Sie den Inhalt von currency-deny-all.yaml. Diese Richtlinie verwendet die Auswahl von Deployment-Labels, um den Zugriff auf den Currencyservice einzuschränken. Sie sehen, dass das Feld „spec“ nicht vorhanden ist. 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 für die Vorgangscluster in beiden Regionen in das k8s-Repository.

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 Ops-Projekts Cloud Build in einem zuvor geöffneten Tab oder klicken Sie auf den folgenden Link:

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

5. Versuchen Sie nach erfolgreicher Fertigstellung des Builds, das Hipstershop-Front-End in einem Browser über den folgenden Link zu erreichen:

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

Es sollte ein Autorisierungsfehler voncurrencyservice angezeigt werden:

6. Sehen wir uns an, wie der Währungsdienst diese AuthorizationPolicy durchsetzt. Aktivieren Sie zuerst Trace-Logs auf dem Envoy-Proxy für einen der Währungs-Pods, da blockierte Autorisierungsaufrufe nicht standardmäßig 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 (Autorisierungslogs) vom Sidecar-Proxy des Währungsdienstes ab. Sie sollten den Hinweis „erzwungen abgelehnt“ sehen und gibt an, dass der Currencyservice 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. Lassen Sie zu, dass das Front-End, aber nicht die anderen Back-End-Dienste, auf "currencyservice" zugreifen. Öffnen Sie currency-allow-frontend.yaml und sehen Sie sich den Inhalt an. Beachten Sie, dass wir die folgende Regel hinzugefügt haben:

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 einen bestimmten source.principal (Client) auf die weiße Liste, um auf den Währungsdienst zuzugreifen. Dieses „source.principal“ wird durch das Kubernetes-Dienstkonto definiert. In diesem Fall ist das Dienstkonto, das wir auf die weiße Liste setzen, das Frontend-Dienstkonto im Frontend-Namespace.

Hinweis:Wenn Sie Kubernetes-Dienstkonten in Istio-AuthorizationPolicies verwenden, müssen Sie zuerst die clusterweite gegenseitige TLS-Authentifizierung aktivieren, wie in Modul 1 beschrieben. Dadurch wird sichergestellt, dass die Anmeldedaten des Dienstkontos in Anfragen bereitgestellt 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 Ops-Projekts Cloud Build in einem zuvor geöffneten Tab oder durch Klicken auf 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-Front-End erneut. Dieses Mal sollten keine Fehler auf der Startseite angezeigt werden. Das liegt daran, dass das Front-End explizit auf den aktuellen Dienst zugreifen darf.
13. Versuchen Sie nun, einen Bezahlvorgang durchzuführen, indem Sie Artikel in den Einkaufswagen legen und auf „Bestellung aufgeben“ klicken. Dieses Mal sollte ein Fehler bei der Preisumrechnung vom Währungsdienst angezeigt werden. Dies liegt daran, dass wir nur das Front-End auf die weiße Liste gesetzt haben, sodass der Checkoutservice immer noch nicht auf den Währungsdienst zugreifen kann.

14. Zum Schluss gewähren wir dem Checkout-Dienst Zugriff auf die Währung, indem wir der AuthorizationPolicy von „currencyservice“ eine weitere Regel hinzufügen. Beachten Sie, dass der Währungszugriff nur auf die beiden Dienste möglich ist, für die der Zugriff erforderlich ist: Front-End und Checkout. Die anderen Back-Ends werden weiterhin blockiert.
15. Öffnen Sie currency-allow-frontend-checkout.yaml und sehen Sie sich den Inhalt an. Beachten Sie, dass die Liste der Regeln als logisches ODER funktioniert. Die Währung akzeptiert nur Anfragen von Arbeitslasten mit einem dieser beiden Dienstkonten.

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 Ops-Projekts Cloud Build in einem zuvor geöffneten Tab oder durch Klicken auf den folgenden Link an:

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

19. Versuchen Sie nach erfolgreichem Abschluss des Builds, einen Bezahlvorgang auszuführen – dies sollte funktionieren.

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

12. Infrastrukturskalierung

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 Vorgangsprojekt und eines für das neue Projekt)
• Neuer Vorgangscluster in neuer Region (im neuen Subnetz)
• Neue Istio-Steuerungsebene für die neue Region
• 2 Anwendungscluster im neuen Projekt in der neuen Region
• Commit für infrastructure-Repository durchführen
• Installation prüfen

SKRIPT FÜR DEN SCHNELLEN TRACK

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

Anleitung zum Kopieren und Einfügen für das Methoden-Lab

Wenn Sie das Schnellverfahren für dieses Lab bereits ausgefüllt haben, führen Sie nicht die unten gezeigte Methode zum Kopieren und Einfügen aus**.**

Es gibt mehrere Möglichkeiten, eine Plattform zu skalieren. Sie können vorhandenen Clustern Knoten hinzufügen, um mehr Rechenleistung zu nutzen. Sie können weitere Cluster in einer Region hinzufügen. Sie können der Plattform auch weitere Regionen hinzufügen. Die Entscheidung, welcher Aspekt der Plattform skaliert werden soll, hängt von den Anforderungen ab. Wenn Sie beispielsweise Cluster in allen drei Zonen in einer Region haben, kann es ausreichen, dem vorhandenen Cluster weitere Knoten (oder Knotenpools) hinzuzufügen. Wenn Sie jedoch Cluster in zwei von drei Zonen in einer einzelnen Region haben, erhalten Sie durch Hinzufügen eines neuen Clusters in der dritten Zone Skalierung und eine zusätzliche Fehlerdomäne (d.h. eine neue Zone). Ein weiterer Grund für das Hinzufügen eines neuen Clusters in einer Region kann die Notwendigkeit sein, einen einzelnen Mandantencluster zu erstellen – aus regulatorischen Gründen oder aus Compliancegründen (z. B. PCI oder ein Datenbankcluster mit personenidentifizierbaren Informationen). Mit der Expansion Ihres Unternehmens und Ihrer Dienstleistungen wird das Hinzufügen neuer Regionen unvermeidlich, um Ihre Dienstleistungen näher am Kunden zu erbringen.

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

• Vertikal – in jeder Region durch Hinzufügen weiterer Rechenressourcen. Dies geschieht entweder durch Hinzufügen weiterer Knoten (oder Knotenpools) zu vorhandenen Clustern oder durch Hinzufügen neuer Cluster innerhalb der Region. Dies erfolgt über das Repository infrastructure. Der einfachste Weg ist das Hinzufügen von Knoten zu vorhandenen Clustern. Hierfür ist keine zusätzliche Konfiguration erforderlich. Für das Hinzufügen neuer Cluster sind möglicherweise zusätzliche Subnetze (und sekundäre Bereiche), entsprechende Firewallregeln erforderlich, das Hinzufügen der neuen Cluster zur Steuerungsebene des regionalen ASM/Istio-Service-Mesh und das Bereitstellen von Anwendungsressourcen in den neuen Clustern.
• Horizontal – durch Hinzufügen weiterer Regionen Die aktuelle Plattform stellt Ihnen eine regionale Vorlage zur Verfügung. Sie besteht aus einem regionalen Betriebscluster, in dem sich die ASM/Istio-Steuerung befindet, und zwei (oder mehr) zonalen Anwendungsclustern, in denen Anwendungsressourcen bereitgestellt werden.

In diesem Workshop skalieren Sie die Plattform „horizontal“. da sie auch die Schritte der vertikalen Anwendungsfälle umfasst. Um die Plattform horizontal zu skalieren, indem Sie der Plattform eine neue Region (r3) hinzufügen, müssen die folgenden Ressourcen hinzugefügt werden:

1. Subnetze in der freigegebenen VPC des Hostprojekts in Region r3 für die neuen Vorgangs- und Anwendungscluster.
2. Ein regionaler Ops-Cluster in 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-Repository:
5. Stellen Sie Ressourcen der ASM/Istio-Steuerungsebene im Betriebscluster in Region r3 bereit.
6. Stellen Sie Ressourcen der freigegebenen ASM/Istio-Steuerungsebene für die Anwendungscluster in Region r3 bereit.
7. Sie müssen zwar kein neues Projekt erstellen, aber die Schritte im Workshop zeigen das Hinzufügen eines neuen Projekts dev3, um den Anwendungsfall des Hinzufügens eines neuen Teams zur Plattform abzudecken.

Das Infrastruktur-Repository wird zum Hinzufügen der oben genannten neuen Ressourcen verwendet.

1. Gehen 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 den Zweig des Workshop-Quell-Repositorys 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. Dateien aus dem Zweig add-proj im Quell-Workshop-Repository kopieren. Der add-proj-Zweig 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 Repository-Verzeichnis „add-proj“ 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. Commit durchführen und Änderungen per Push zum Erstellen eines neuen Projekts übertragen

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

7. Der Commit löst das Repository infrastructure aus, um die Infrastruktur mit den neuen Ressourcen bereitzustellen. Sehen Sie sich den Cloud Build-Fortschritt an. Klicken Sie dazu auf die Ausgabe des folgenden Links und gehen Sie oben zum neuesten Build.

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

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

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

8. Nachdem die Infrastruktur von Cloud Build erfolgreich erstellt wurde, rufen Sie die k8s-repo-letzte Ausführung von Cloud Build auf. Klicken Sie dazu auf den folgenden Ausgabelink.

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 zu den Variablen "vars" und "kubectl" 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 die 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 überprüfen

12. Achten Sie darauf, dass Istio auf dem neuen Vorgangscluster installiert ist. Prüfen Sie dazu, ob alle Pods ausgeführt werden und die Jobs abgeschlossen wurden.

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. Achten Sie darauf, dass Istio in beiden dev3-Clustern installiert ist. In den dev3-Clustern werden nur Citadel, Sidecar-Injektor und Coredns ausgeführt. Sie nutzen eine 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 freigegebene Steuerungsebenen prüfen

14. Prüfen Sie, ob die Secrets in allen Vorgangsclustern 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: Schutzschalter für den Versandservice implementieren.

• DestinationRule für den Dienst shipping erstellen, um einen Schutzschalter zu implementieren
• Verwenden Sie fortio (ein Dienstprogramm für die Lastgenerierung), um den Schutzschalter für den Dienst shipping durch Erzwingen eines Auslösens des Stromkreises zu prüfen.

Anleitung für das Fast-Track-Script-Lab

Das Fast-Track-Skript-Lab ist bald verfügbar!

Anleitung zum Kopieren und Einfügen für das Methoden-Lab

Sie haben nun einige grundlegende Monitoring- und Fehlerbehebungsstrategien für Istio-fähige Dienste kennengelernt. Sehen wir uns nun an, wie Istio Sie dabei unterstützt, die Robustheit Ihrer Dienste zu verbessern und so den Aufwand für die Fehlerbehebung zu reduzieren.

Eine Mikrodienstarchitektur birgt das Risiko von kaskadierenden Fehlern, bei denen sich der Ausfall eines Dienstes auf seine Abhängigkeiten und die Abhängigkeiten dieser Abhängigkeiten übertragen kann, was zu einer Welleneffekt führt. die Endnutzer beeinträchtigen können. Istio bietet eine Circuit Breaker-Trafficrichtlinie, mit der Sie Dienste isolieren können, um nachgelagerte (clientseitige) Dienste vor dem Warten auf fehlerhafte Dienste zu schützen und Upstream-Dienste (serverseitig) vor einer plötzlichen Flut von Downstream-Traffic zu schützen, wenn sie wieder online sind. Insgesamt können Sie mit Schutzschaltern verhindern, dass alle Ihre SLOs aufgrund eines hängenden Back-End-Dienstes fehlschlagen.

Das Muster für den Schutzschalter ist nach einem elektrischen Schalter benannt, der „ausschalten“ kann wenn zu viel Strom durchfließt, um Geräte vor Überlastung zu schützen. In einer Istio-Einrichtung bedeutet dies, dass Envoy der Schutzschalter ist und die Anzahl der ausstehenden Anfragen für einen Dienst verfolgt. In diesem standardmäßig geschlossenen Status werden Anfragen ohne Unterbrechungen durch Envoy geleitet.

Wenn die Anzahl der ausstehenden Anfragen jedoch den definierten Grenzwert überschreitet, löst der Schutzschalter aus (öffnet) und Envoy gibt sofort einen Fehler zurück. Dadurch kann der Server für den Client schnell ausfallen und verhindert, dass der Serveranwendungscode die Anfrage des Clients empfängt, wenn er überlastet ist.

Nach der festgelegten Zeitüberschreitung wird Envoy in einen halb offenen Status versetzt, in dem der Server in der Probezeit wieder Anfragen empfangen kann. Wenn er erfolgreich auf Anfragen antworten kann, wird der Schutzschalter geschlossen und Anfragen an den Server werden wieder verarbeitet.

In diesem Diagramm wird das Schutzschaltermuster von Istio zusammengefasst. Die blauen Rechtecke stehen für Envoy, der blau ausgefüllte Kreis für den Client und die weißen Kreise für den Servercontainer:

Sie können Schutzschalterrichtlinien mithilfe von Istio-Zielregeln definieren. In diesem Abschnitt wenden wir die folgende Richtlinie an, um einen Schutzschalter für den Versandservice 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

Es gibt zwei DestinationRule-Felder, die hier zu beachten sind. connectionPool definiert die Anzahl der Verbindungen, die dieser Dienst zulässt. Im Feld „outlierDetection“ konfigurieren wir, wie Envoy den Grenzwert bestimmt, bei dem der Schutzschalter geöffnet werden soll. Hier zählt Envoy in jeder Sekunde (Intervall) die Anzahl der Fehler, die vom Servercontainer empfangen wurden. Wenn er den Grenzwert consecutiveErrors überschreitet, öffnet sich der Schutzschalter von Envoy und 100% der productcatalog-Pods werden 10 Sekunden lang von neuen Clientanfragen abgeschirmt. Sobald der Schutzschalter für Envoy geöffnet (d. h. aktiv) ist, erhalten Clients den Fehler 503 (Dienst nicht verfügbar). Im konkreten Einsatz ansehen

1. Legen Sie Umgebungsvariablen für „k8s-repo“ und „asm dir“ fest, um Befehle zu vereinfachen.

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

2. k8s-Repository aktualisieren

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

3. Aktualisieren Sie die DestinationRule des Versanddienstes 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-Load-Generator-Pod in den GKE_1-Cluster in der Dev1-Region. Das ist der Client-Pod, den wir für "trip" verwenden. den Schutzschalter für den Versandservice.

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 einen Commit für Ä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 „shippingservice“ zu senden. Der Schutzschalter wird dadurch nicht ausgelöst, da die Einstellungen für connectionPool 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 nun fortio erneut 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 ein "overflow"-Fehler , da der Schutzschalter ausgelöst wurde: In der von uns definierten Richtlinie ist nur eine gleichzeitige Verbindung in einem 1-sekündigen 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 verfolgt mit dem Messwert upstream_rq_pending_overflow die Anzahl der Verbindungen, die bei aktivem Schutzschalter unterbrochen wurden. Sehen wir uns das im Fortio-Pod an:

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, indem Sie die Schutzschalterrichtlinie aus beiden Regionen entfernen.

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 eine einzelne Schutzschalterrichtlinie für einen Dienst eingerichtet wird. Es empfiehlt sich, einen Schutzschalter für jeden vorgelagerten Dienst (Back-End) einzurichten, der sich aufhängen kann. Durch die Anwendung von Schutzschalterrichtlinien von Istio können Sie Ihre Mikrodienste isolieren, Fehlertoleranz in Ihre Architektur einbinden und das Risiko von Fehlerkaskaden unter hoher Last reduzieren.

14. Fault Injection (Fehlerinjektion)

Ziel: Testen Sie die Ausfallsicherheit des Empfehlungsdienstes, indem Sie Verzögerungen einführen, bevor er in die Produktion übernommen wird.

• VirtualService für den Dienst recommendation erstellen, um eine Verzögerung von 5 Sekunden einzuführen
• Verzögerung mit dem Load-Generator fortio testen
• Entfernen Sie die Verzögerung in VirtualService und validieren Sie sie

Anleitung für das Fast-Track-Script-Lab

Das Fast-Track-Skript-Lab ist bald verfügbar!

Anleitung zum Kopieren und Einfügen für das Methoden-Lab

Das Hinzufügen von Schutzschalterrichtlinien zu Ihren Diensten ist eine Möglichkeit, um Widerstandsfähigkeit gegenüber Diensten in der Produktion zu erhöhen. Aber Schutzschaltungen führen zu Fehlern – potenziell für den Nutzer sichtbare Fehler –, was nicht ideal ist. Um diesen Fehlern einen Schritt voraus zu sein und besser vorherzusagen, wie Ihre nachgelagerten Dienste reagieren könnten, wenn Back-Ends Fehler zurückgeben, können Sie Chaostests in einer Staging-Umgebung einführen. Chaos Testing bezeichnet die absichtliche Störung Ihrer Dienste, um Schwachstellen im System zu analysieren und die Fehlertoleranz zu verbessern. Sie können auch Chaostests verwenden, um Möglichkeiten zu ermitteln, wie Sie nutzerseitige Fehler bei einem Back-End-Fehler minimieren können, indem Sie beispielsweise ein im Cache gespeichertes Ergebnis in einem Front-End anzeigen.

Die Verwendung von Istio für die Fehlerinjektion ist hilfreich, da Sie Ihre Produktions-Release-Images verwenden und den Fehler auf Netzwerkebene hinzufügen können, anstatt den Quellcode zu ändern. In der Produktion können Sie ein vollwertiges Chaostesttool verwenden, um die Ausfallsicherheit nicht nur auf der Netzwerkebene, sondern auch auf der Kubernetes-/Computing-Ebene zu testen.

Sie können Istio für Chaostests verwenden, indem Sie einen VirtualService mit dem „Fehler“ anwenden ein. Istio unterstützt zwei Arten von Fehlern: Verzögerungsfehler (Zeitüberschreitung einfügen) und abbrechen von Fehlern (Injection-HTTP-Fehler). In diesem Beispiel fügen wir dem Empfehlungsdienst den Fehler 5-Sekunden-Verzögerung hinzu. Statt jedoch einen Schutzschalter zu verwenden, gegen diesen hängenden Dienst an.

11. Wechseln Sie in das Fehlerinjektionsverzeichnis.

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 sich den Inhalt anzusehen. Beachten Sie, dass Istio eine Option hat, um den Fehler in einen Prozentsatz der Anfragen einzuschleusen. Hier fügen wir ein Zeitlimit in alle Empfehlungsdienst-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 beide 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 die Ausführung im Fortio-Pod aus, der im Bereich für Schutzschalter bereitgestellt ist, und senden Sie Traffic an den Empfehlungsdienst.

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 andere Möglichkeit, den von uns eingefügten Fehler in Aktion zu sehen, besteht darin, das Front-End in einem Webbrowser zu öffnen und auf ein beliebiges Produkt zu klicken. Das Laden einer Produktseite dauert 5 Sekunden länger, da unten auf der Seite angezeigte Empfehlungen abgerufen werden.
18. Führen Sie eine Bereinigung durch, indem Sie den Fehlerinjektionsdienst 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 per Push ü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 und ASM wird mit Grafana-Dashboards ausgeliefert, mit denen Operatoren diese Monitoringdaten visualisieren und den Zustand und die Leistung der Steuerungsebene bewerten können.

Dashboards anzeigen

20. Führen Sie eine Portweiterleitung für Ihren mit Istio installierten Grafana-Dienst durch.

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

21. Grafana in Ihrem Browser öffnen
22. Klicken Sie auf den Link "Webvorschau". oben rechts im Cloud Shell-Fenster.
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. Dadurch wird in Ihrem Browser ein Tab mit einer URL wie „ BASE_URL/?orgId=1&authuser=0&environment_id=default"
25. Verfügbare Dashboards ansehen
26. Ändern Sie die URL zu " BASE_URL/dashboard"
27. Klicken Sie auf „istio“. Ordner zum Anzeigen der verfügbaren Dashboards
28. Klicken Sie auf eines der Dashboards, um die Leistung der entsprechenden Komponente zu sehen. In den folgenden Abschnitten werden die Messwerte für die einzelnen Komponenten näher erläutert.

Monitoring-Pilotprojekt

Pilot ist die Komponente der Steuerungsebene, die die Netzwerk- und Richtlinienkonfiguration auf die Datenebene (die Envoy-Proxys) verteilt. Pilot skaliert in der Regel mit der Anzahl der Arbeitslasten und Bereitstellungen, jedoch nicht unbedingt mit der Menge des Traffics zu diesen Arbeitslasten. Ein fehlerhafter Pilot kann:

• mehr Ressourcen als erforderlich verbrauchen (CPU und/oder RAM)
• zu Verzögerungen bei der Übertragung aktualisierter Konfigurationsinformationen an Envoys

Hinweis: Wenn der Pilot nicht verfügbar ist oder es Verzögerungen gibt, wird der Traffic weiterhin über Ihre Arbeitslasten bereitgestellt.

23. Navigieren Sie zu " BASE_URL/dashboard/db/istio-pilot-dashboard" in Ihrem Browser, um Pilot-Messwerte aufzurufen.

Wichtige überwachte Messwerte

Ressourcennutzung

Verwenden Sie die Seite Istio-Leistung und -Skalierbarkeit als Leitfaden für die akzeptable Nutzungszahlen. Wenden Sie sich an den GCP-Support, wenn die Ressourcennutzung deutlich höher ausfällt.

Push-Informationen zum Pilotprojekt

In diesem Abschnitt werden Pilot-Übertragungen von Konfigurationen an Ihre Envoy-Proxys überwacht.

• Pilot-Pushes zeigt die Art der Konfiguration an, die zu einem bestimmten Zeitpunkt übertragen wird.
• ADS Monitoring zeigt die Anzahl der virtuellen Dienste, Dienste und verbundenen Endpunkte im System an.
• Cluster ohne bekannte Endpunkte zeigt Endpunkte an, die konfiguriert wurden, auf denen aber keine Instanzen ausgeführt werden. Dies kann auf externe Dienste wie *.googleapis.com hinweisen.
• Pilotfehler zeigt die Anzahl der aufgetretenen Fehler im Zeitverlauf.
• Unter Konflikte wird die Anzahl der Konflikte angezeigt, bei denen die Konfiguration auf Listenern nicht eindeutig ist.

Wenn Fehler oder Konflikte auftreten, 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 darüber, wie die Envoy-Proxys 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 zu Telemetrie-Back-Ends (normalerweise Prometheus, Stackdriver usw.) weiterleitet. In dieser Funktion befindet sie sich 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 Einbindung in Richtliniensysteme verwendet werden. In dieser Funktion hat Mixer Auswirkungen auf die Datenebene, da Richtlinienprüfungen für Mixer fehlschlagen, um den Zugriff auf Ihre Dienste zu blockieren.

Mixer skaliert in der Regel mit dem Traffic-Volumen.

24. Navigieren Sie zu " BASE_URL/dashboard/db/istio-mixer-dashboard" im Browser, um Mixer-Messwerte zu sehen.

Wichtige überwachte Messwerte

Ressourcennutzung

Verwenden Sie die Seite Istio-Leistung und -Skalierbarkeit als Leitfaden für die akzeptable Nutzungszahlen. Wenden Sie sich an den GCP-Support, wenn die Ressourcennutzung deutlich höher ausfällt.

Mixer – Übersicht

• Die Antwortdauer ist ein wichtiger Messwert. Berichte an Mixer-Telemetrie befinden sich zwar nicht im Datenpfad, aber wenn diese Latenzen hoch sind, wird die Leistung des Sidecar-Proxys definitiv verlangsamt. Sie sollten davon ausgehen, dass das 90. Perzentil im einstelligen Millisekundenbereich und das 99. Perzentil unter 100 ms liegt.

• Dauer der Adapterfreigabe gibt die Latenz des Mixers beim Aufrufen von Adaptern an, über die Informationen an Telemetrie- und Logging-Systeme gesendet werden. Hohe Latenzen wirken sich hier absolut auf die Leistung des Mesh-Netzwerks aus. Auch hier sollten die P90-Latenzen unter 10 ms liegen.

Überwachungsgalerie

Die Galerie ist die Istio-Komponente für Konfigurationsvalidierung, Aufnahme, Verarbeitung und Verteilung. 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. Navigieren Sie zu " BASE_URL/dashboard/db/istio-galley-dashboard" in Ihrem Browser, um Galley-Messwerte aufzurufen.

Wichtige überwachte Messwerte

Ressourcenvalidierung

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

Verbundene Clients

Gibt an, wie viele Clients mit Galley verbunden sind; In der Regel ist dies 3 (Pilot, istio-telemetry, istio-policy) und wird entsprechend der Skalierung dieser Komponenten skaliert.

16. Fehlerbehebung bei Istio

Fehlerbehebung für die Datenebene

Wenn in Ihrem Pilot-Dashboard auf Konfigurationsprobleme hingewiesen wird, sollten Sie die PIlot-Logs überprüfen oder mit istioctl Konfigurationsprobleme finden.

Führen Sie zum Prüfen der Pilot-Logs den Befehl „kubectl -n“ istio-system-Logs istio-pilot-69db46c598-45m44 aus und ersetzen Sie dabei istio-pilot-... durch die Pod-ID der Pilotinstanz, für die Sie eine Fehlerbehebung durchführen möchten.

Suchen Sie im resultierenden Protokoll nach einer Push Status-Nachricht. 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 alle Probleme an, die beim Versuch, die Konfiguration per Push an Envoy-Proxys zu übertragen, aufgetreten sind. In diesem Fall sehen Sie mehrere Clusterduplikate die doppelte vorgelagerte Ziele anzeigen.

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

Konfigurationsfehler finden

Führen Sie istioctl experimental analyze -k --context $OPS_GKE_1 aus, um Ihre Konfiguration mit istioctl zu analysieren. Dadurch wird eine Analyse der Konfiguration in Ihrem System durchgeführt, mögliche Probleme zusammen mit vorgeschlagenen Änderungen angezeigt. Eine vollständige Liste der Konfigurationsfehler, die mit diesem Befehl erkannt werden, finden Sie in der Dokumentation.

17. Bereinigen

Die folgenden Schritte werden nach Abschluss des Workshops von einem Administrator 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. Sie benötigen die folgenden Informationen, damit das Bereinigungsskript ausgeführt werden kann.

• Name der Organisation, z. B. yourcompany.com
• Workshop-ID – 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 folgenden 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. Navigieren Sie im asm-Ordner.

cd ${WORKDIR}/asm
 

16. Geben Sie den Namen Ihrer Organisation und die Workshop-ID an, die gelöscht werden sollen.

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 wie folgt aus.

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