Atelier Anthos Service Mesh: guide de l'atelier

1. ATELIER ALPHA

REMARQUE IMPORTANTE: CECI EST UN ATELIER ALPHA ET UNE FORMATION STRICTEMENT CONÇUE POUR UNE FORMATION FORMATION PAR UN enseignant.

Lien vers l'atelier de programmation bit.ly/asm-workshop

2. Présentation

Schéma de l'architecture

Cet atelier est une expérience immersive pratique qui explique comment configurer en production des services GCP distribués à l'échelle mondiale. Les principales technologies utilisées sont Google Kubernetes Engine (GKE) pour le calcul et le maillage de services Istio pour créer une connectivité sécurisée, une observabilité et une mise en forme avancée du trafic. Toutes les pratiques et tous les outils utilisés dans cet atelier sont ceux que vous utiliseriez en production.

Sommaire

• Module 0 – Introduction et configuration de la plate-forme
• Introduction et architecture
• Présentation du maillage de services et d'Istio/ASM
• Atelier: Configuration de l'infrastructure: Workflow utilisateur
• Pause
• QnA
• Module 1 : Installer, sécuriser et surveiller des applications avec ASM
• Modèle de dépôt: explication des dépôts d'infrastructure et de Kubernetes
• Atelier: Déployer un exemple d'application
• Services distribués et observabilité
• Déjeuner
• Atelier: Observabilité avec Stackdriver
• QNA
• Module 2 – DevOps – Déploiements Canary, règles/RBAC
• Détection de services multiclusters et sécurité/règles
• Atelier: TLS mutuel
• Déploiements Canary
• Atelier: Déploiements Canary
• Équilibrage de charge global sécurisé sur plusieurs clusters
• Pause
• Atelier: Règles d'autorisation
• QNA
• Module 3 - Opérations d'infrastructure - Mises à niveau de la plate-forme
• Composants de service distribué
• Atelier: Scaling de l'infrastructure
• Étapes suivantes

Slides

Les diapositives de cet atelier sont disponibles à l'adresse suivante:

Diapositives de l'atelier ASM

Prérequis

Avant de commencer cet atelier, vous devez fournir les informations suivantes:

1. Un nœud d'organisation GCP
2. Un ID de compte de facturation (votre utilisateur doit disposer du rôle Administrateur de la facturation sur ce compte de facturation)
3. Rôle IAM d'administrateur de l'organisation au niveau de l'organisation pour votre utilisateur

3. Configuration de l'infrastructure : Workflow d'administration

Les étapes de cette section sont réalisées par un administrateur qui crée l’atelier.

Si vous participez à l'atelier, passez à la section suivante, intitulée Infrastructure Setup - User Workflow.

Explication du script de l'atelier d'amorçage

Un script appelé bootstrap_workshop.sh permet de configurer l'environnement initial de l'atelier. Vous pouvez utiliser ce script afin de configurer un environnement unique pour vous-même ou plusieurs environnements pour plusieurs utilisateurs au cas où vous donneriez cet atelier à des fins de formation pour plusieurs utilisateurs.

Le script de l'atelier d'amorçage nécessite les entrées suivantes:

• Nom de l'organisation (par exemple, yourcompany.com) : il s'agit de l'organisation dans laquelle vous créez les environnements pour l'atelier.
• N° compte facturation (par exemple 12345-12345-12345) : cet ID est utilisé pour facturer toutes les ressources utilisées pendant l'atelier.
• Numéro d'atelier (par exemple, 01) : numéro à deux chiffres. Vous pouvez l'utiliser si vous organisez plusieurs ateliers dans une même journée et que vous souhaitez en effectuer le suivi séparément. Les numéros d'atelier sont également utilisés pour déduire les ID de projet. Le fait d'avoir des numéros d'atelier distincts vous permet de vous assurer plus facilement d'obtenir des ID de projet uniques à chaque fois. En plus du numéro d'atelier, la date actuelle (au format YYMMDD) est également utilisée pour les ID de projet. La combinaison de la date et du numéro d'atelier fournit des ID de projet uniques.
• Numéro de l'utilisateur débutant (par exemple, 1) : ce nombre correspond au premier utilisateur de l'atelier. Par exemple, si vous souhaitez créer un atelier pour 10 utilisateurs, vous pouvez avoir le nombre d'utilisateurs de départ 1 et le nombre d'utilisateurs finaux 10.
• Numéro d'utilisateur final (par exemple, 10) : numéro correspondant au dernier utilisateur de l'atelier. Par exemple, si vous souhaitez créer un atelier pour 10 utilisateurs, vous pouvez avoir le nombre d'utilisateurs de départ 1 et le nombre d'utilisateurs finaux 10. Si vous configurez un environnement unique (par exemple, vous-même), assurez-vous que les numéros d'utilisateur de départ et d'utilisateur final sont identiques. Cette opération permet de créer un environnement unique.

En plus de la date et du numéro d’atelier, les numéros d’utilisateur de début et d’utilisateur final sont également incorporés dans les ID de projet. Les ID utilisateur (pour les utilisateurs participant à l'atelier) sont dérivés du numéro de l'utilisateur début et de l'utilisateur final. Les ID utilisateur sont expliqués dans la section User schema and permissions performing the workshop.

• Bucket GCS administrateur (par exemple, my-gcs-bucket-name) : un bucket GCS est utilisé pour stocker les informations liées à l'atelier. Ces informations sont utilisées par le script cleanup_workshop.sh pour supprimer correctement toutes les ressources créées lors du script de l'atelier d'amorçage. Les administrateurs qui créent des ateliers doivent disposer d'autorisations de lecture/écriture sur ce bucket.

Le script de l'atelier d'amorçage utilise les valeurs fournies ci-dessus et agit comme un script wrapper qui appelle le script setup-terraform-admin-project.sh. Le script setup-terraform-admin-project.sh crée l'environnement de l'atelier pour un seul utilisateur.

Autorisations d'administrateur requises pour démarrer l'atelier

Il existe deux types d’utilisateurs dans cet atelier. Un ADMIN_USER, qui crée et supprime les ressources pour cet atelier. Le deuxième est MY_USER, qui effectue les étapes de l'atelier. MY_USER n'a accès qu'à ses propres ressources. ADMIN_USER a accès à toutes les configurations utilisateur. Si vous créez cette configuration pour vous-même, ADMIN_USER et MY_USER sont identiques. Si vous êtes enseignant et que vous créez cet atelier pour plusieurs élèves, votre ADMIN_USER et votre MY_USER seront différents.

Les autorisations suivantes au niveau de l'organisation sont requises pour ADMIN_USER:

• Propriétaire : autorisation de propriétaire de projet pour tous les projets de l'organisation.
• Administrateur de dossier : peut créer et supprimer des dossiers dans l'organisation. Chaque utilisateur obtient un dossier unique avec toutes ses ressources dans le projet.
• Administrateur de l'organisation
• Créateur de projet : peut créer des projets dans l'organisation.
• Suppresseur de projets : permet de supprimer des projets dans l'organisation.
• Administrateur IAM de projet : peut créer des règles IAM dans tous les projets de l'organisation.

En outre, ADMIN_USER doit également être l'administrateur de la facturation associé à l'ID de compte de facturation utilisé lors de l'atelier.

Schéma de l'utilisateur et autorisations lors de l'atelier

Si vous prévoyez de créer cet atelier pour des utilisateurs (autres que vous) de votre organisation, vous devez suivre un schéma d'attribution de noms spécifique pour MY_USERs. Dans le script bootstrap_workshop.sh, vous fournissez un numéro de démarrage et un numéro d'utilisateur final. Ces numéros sont utilisés pour créer les noms d'utilisateur suivants:

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

Par exemple, si vous exécutez le script de l'atelier d'amorçage avec un numéro d'utilisateur de départ et un utilisateur final de trois, dans votre organisation votreentreprise.com, les environnements d'atelier pour les utilisateurs suivants sont créés:

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

Ces noms d'utilisateur se voient attribuer le rôle de propriétaire de projet pour les projets qu'ils ont créés lors du script setup_terraform_admin_project.sh. Vous devez respecter ce schéma de dénomination utilisateur lorsque vous utilisez le script d'amorçage. Découvrez comment ajouter plusieurs utilisateurs simultanément dans G Suite.

Outils requis pour l'atelier

Cet atelier est destiné à être amorcé à partir de Cloud Shell. Les outils suivants sont requis pour cet atelier.

• gcloud (version 270 ou ultérieure)
• kubectl
• sed (fonctionne avec sed sous Cloud Shell/Linux, mais pas sous Mac OS)
• git (assurez-vous d'être à jour)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize

Tous les outils, à l'exception de kustomize, sont déjà installés par défaut dans Cloud Shell. Si kustomize n'est pas installé, installez-le à l'aide du script bash fourni dans le lien ci-dessus. Assurez-vous que le binaire kustomize se trouve dans votre chemin d'accès et vérifiez en exécutant la commande kustomize dans Cloud Shell.

Configuration de l'atelier pour vous-même (configuration utilisateur unique)

1. Ouvrez Cloud Shell et effectuez toutes les actions ci-dessous dans Cloud Shell. Cliquez sur le lien ci-dessous.

CLOUD SHELL

2. Vérifiez que vous êtes connecté à gcloud avec l'utilisateur administrateur souhaité.

gcloud config list
 

3. Créez un fichier WORKDIR et clonez le dépôt de l'atelier.

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

4. Définissez le nom de votre organisation, son ID de compte de facturation, son numéro d'atelier et un bucket GCS d'administrateur à utiliser pour l'atelier. Examinez les autorisations requises pour configurer l'atelier dans les sections ci-dessus.

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. Exécutez le script bootstrap_workshop.sh. Ce script peut prendre quelques minutes.

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 
 

Notez que vous n'avez pas besoin de définir le numéro de début et de fin de l'utilisateur, car vous effectuez cette configuration vous-même.

Une fois le script bootstrap_workshop.sh terminé, un dossier GCP est créé pour chaque utilisateur de l'organisation. Un projet d'administrateur Terraform est créé dans ce dossier. Le projet d'administration Terraform permet de créer le reste des ressources GCP nécessaires pour cet atelier. Vous activez les API requises dans le projet d'administration Terraform. Vous allez utiliser Cloud Build pour appliquer des plans Terraform. Vous devez attribuer les rôles IAM appropriés au compte de service Cloud Build afin qu'il puisse créer des ressources sur GCP. Enfin, vous allez configurer un backend distant dans un bucket Google Cloud Storage (GCS) pour stocker les états Terraform de toutes les ressources GCP.

Pour afficher les tâches Cloud Build dans le projet d'administration Terraform, vous avez besoin de l'ID de ce projet. Il est stocké dans le fichier vars/vars.sh de votre répertoire asm. Ce répertoire n'est conservé que si vous configurez l'atelier pour vous-même en tant qu'administrateur.

6. Utiliser le fichier de variables pour définir des variables d'environnement

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

Mise en place d'un atelier pour plusieurs utilisateurs (configuration multi-utilisateur)

7. Ouvrez Cloud Shell et effectuez toutes les actions ci-dessous dans Cloud Shell. Cliquez sur le lien ci-dessous.

CLOUD SHELL

8. Vérifiez que vous êtes connecté à gcloud avec l'utilisateur administrateur souhaité.

gcloud config list
 

9. Créez un fichier WORKDIR et clonez le dépôt de l'atelier.

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

10. Définissez le nom de votre organisation, le numéro de compte de facturation, le numéro de l'atelier, le numéro de l'utilisateur final et du début, ainsi qu'un bucket GCS d'administrateur à utiliser pour l'atelier. Examinez les autorisations requises pour configurer l'atelier dans les sections ci-dessus.

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. Exécutez le script bootstrap_workshop.sh. Ce script peut prendre quelques minutes.

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. Récupérez le fichier "atelier.txt" dans le bucket GCS Admin pour récupérer les ID de projet Terraform.

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

4. Préparation de l'atelier

Les utilisateurs qui participent à l'atelier commencent ici. Effectuez toutes les étapes à partir d'une fenêtre INCOGNITO dans Chrome ou Firefox.

Choisissez votre parcours d'atelier

Les ateliers de cet atelier peuvent être réalisés de deux manières:

• Scripts interactifs faciles à suivre chemin
• Copier et coller manuellement chaque instruction chemin

La méthode de scripts accélérés vous permet d'exécuter un script interactif unique pour chaque atelier, en exécutant automatiquement les commandes correspondantes. Les commandes sont exécutées par lots, avec des explications concises sur chaque étape et ce qu'elles accomplissent. Après chaque lot, vous êtes invité à passer au lot suivant de commandes. Vous pourrez ainsi suivre les ateliers à votre rythme. Les scripts accélérés sont idempotents, ce qui signifie que vous pouvez les exécuter plusieurs fois pour obtenir le même résultat.

Ces scripts apparaissent dans un cadre vert en haut de chaque atelier, comme illustré ci-dessous.

SCRIPT POUR RAPIDITÉ

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

La méthode copier-coller est la méthode traditionnelle qui consiste à copier et coller des blocs de commandes individuels avec des explications sur les commandes. Cette méthode ne doit être exécutée qu'une seule fois. Rien ne garantit que des commandes réexécutées vous donneront les mêmes résultats.

Lorsque vous effectuez les ateliers, veuillez choisir l'une des deux méthodes.

Une fois que vous avez choisi une méthode et que vous avez suivi les étapes correspondantes, n'effectuez pas celles de l'autre méthode.

Configuration du script Fast Track

Une fois le script de suivi rapide terminé, l'atelier est terminé. N'exécutez pas les étapes décrites dans les instructions de l'atelier de copier-coller.

Obtenir des informations sur l'utilisateur

Cet atelier est réalisé à l'aide d'un compte utilisateur temporaire (ou d'un compte d'atelier) créé par l'administrateur de l'atelier. Le compte de l'atelier est propriétaire de tous les projets de l'atelier. L'administrateur de l'atelier fournit les identifiants du compte de l'atelier (nom d'utilisateur et mot de passe) à l'utilisateur participant à l'atelier. Tous les projets de l'utilisateur sont précédés du nom d'utilisateur du compte d'atelier. Par exemple, pour le compte d'atelier [e-mail], l'ID de projet administrateur Terraform est user001-200131-01-tf-abcde, et ainsi de suite pour les autres projets. Chaque utilisateur doit se connecter avec le compte fourni par l'administrateur de l'atelier et suivre l'atelier à l'aide de ce compte.

Consultez votre adresse e-mail professionnelle (la même que celle que vous avez utilisée pour vous inscrire à l'atelier). Vous devez avoir reçu un e-mail de l'administrateur de l'atelier contenant les identifiants de votre compte pour l'atelier (c'est-à-dire le nom d'utilisateur et le mot de passe). L'e-mail ressemble à ceci.

1. Ouvrez Cloud Shell en cliquant sur le lien ci-dessous.

CLOUD SHELL

2. Connectez-vous à l'aide des identifiants du compte associé à l'atelier (ne vous connectez pas avec votre compte professionnel ou personnel). Le compte de l'atelier ressemble à userXYZ@<workshop_domain>.com.
3. Comme il s'agit d'un nouveau compte, vous êtes invité à accepter les Conditions d'utilisation de Google. Cliquez sur "Accepter".

4. Sur l'écran suivant, cochez la case pour accepter les Conditions d'utilisation de Google, puis cliquez sur Start Cloud Shell.

Cette étape provisionne une petite VM Debian Linux que vous pouvez utiliser pour accéder aux ressources GCP. Chaque compte reçoit une VM Cloud Shell. Connectez-vous avec le compte de l'atelier et connectez-vous à l'aide de ses identifiants. En plus de Cloud Shell, un éditeur de code est fourni pour faciliter la modification des fichiers de configuration (terraform, YAML, etc.). Par défaut, l'écran Cloud Shell est divisé en deux environnements : l'environnement Cloud Shell (en bas) et l'éditeur Cloud Code (en haut). L'icône en forme de crayon et l'icône de l'invite de l'interface système en haut à droite vous permettent de basculer entre les deux (interface système et éditeur de code). Vous pouvez également faire glisser la barre de séparation centrale (vers le haut ou le bas) et modifier manuellement la taille de chaque fenêtre. 5. Créez un WORKDIR pour cet atelier. Le répertoire WORKDIR est un dossier à partir duquel vous effectuez tous les ateliers de cet atelier. Exécutez les commandes suivantes dans Cloud Shell pour créer le WORKDIR.

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

6. Exportez l'utilisateur du compte de l'atelier en tant que variable à utiliser pour cet atelier. Il s'agit du compte avec lequel vous vous êtes connecté à Cloud Shell.

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

Remarque: Si vous êtes administrateur et que vous configurez l'atelier pour vous-même en utilisant le paramètre "-sufa" ou "–setup-for-admin" puis définissez MY_USER sur l'adresse e-mail du compte GCP que vous avez utilisé pour créer les projets de l'atelier.

7. Répétez les variables WORKDIR et MY_USER pour vous assurer qu'elles sont toutes les deux correctement définies en exécutant les commandes suivantes.

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

8. Clonez le dépôt de l'atelier.

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

5. Configuration de l'infrastructure : workflow utilisateur

Objectif: Vérifier l'infrastructure et l'installation d'Istio

• Installer les outils de l'atelier
• Cloner le dépôt de l'atelier
• Valider l'installation de Infrastructure
• Valider l'installation de k8s-repo
• Vérifier l'installation d'Istio

SCRIPT POUR RAPIDITÉ

Si vous choisissez cette méthode, exécutez le script suivant pour terminer cet atelier.

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

Une fois l'exécution du script terminée, source votre bashrc pour mettre à jour les variables dans votre session Cloud Shell.

source ${HOME}/.bashrc

Instructions de l'atelier sur la méthode copier-coller

IMPORTANT: Si vous avez déjà terminé le script de suivi rapide de cet atelier, n'exécutez pas la méthode copier-coller ci-dessous**.**

Obtenir des informations sur l'utilisateur

L'administrateur qui configure l'atelier doit fournir le nom d'utilisateur et le mot de passe de l'utilisateur. Tous les projets de l'utilisateur seront précédés du nom d'utilisateur. Par exemple, pour l'utilisateur [e-mail], l'ID de projet administrateur Terraform sera user001-200131-01-tf-abcde, et ainsi de suite pour les autres projets. Chaque utilisateur n'a accès qu'à son propre environnement d'atelier.

Outils requis pour l'atelier

Cet atelier est destiné à être amorcé à partir de Cloud Shell. Les outils suivants sont requis pour cet atelier.

Tous les outils, à l'exception de kustomize et pv, sont déjà installés par défaut dans Cloud Shell. Vous trouverez ci-dessous des instructions pour installer les deux.

• gcloud (version 270 ou ultérieure)
• kubectl
• sed (fonctionne avec sed sous Cloud Shell/Linux, mais pas sous Mac OS)
• git (assurez-vous d'être à jour)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize
• pv

Accéder au projet administrateur Terraform

Une fois le script bootstrap_workshop.sh terminé, un dossier GCP est créé pour chaque utilisateur de l'organisation. Un projet d'administrateur Terraform est créé dans ce dossier. Le projet d'administration Terraform permet de créer le reste des ressources GCP nécessaires pour cet atelier. Le script setup-terraform-admin-project.sh active les API requises dans le projet d'administration Terraform. Cloud Build permet d'appliquer des plans Terraform. À l'aide du script, vous attribuez au compte de service Cloud Build les rôles IAM appropriés pour qu'il puisse créer des ressources sur GCP. Enfin, un backend distant est configuré dans un bucket Google Cloud Storage (GCS) pour stocker les états Terraform de toutes les ressources GCP.

Pour afficher les tâches Cloud Build dans le projet d'administration Terraform, vous avez besoin de l'ID de ce projet. Il est stocké dans le bucket GCS administrateur spécifié dans le script d'amorçage. Si vous exécutez le script d'amorçage pour plusieurs utilisateurs, tous les ID de projet administrateur Terraform se trouvent dans le bucket GCS.

Cet atelier est destiné à être effectué dans Cloud Shell et la console Cloud. Procédez comme suit dans une fenêtre INCOGNITO, puisque vous vous connecterez avec un nom d'utilisateur et un mot de passe distincts.

1. Ouvrez Cloud Shell (s'il n'est pas déjà ouvert depuis la section "Configuration et préparation de l'atelier") en cliquant sur le lien ci-dessous.

CLOUD SHELL

2. Installez kustomize (s'il n'est pas déjà installé) dans le dossier $HOME/bin et ajoutez le dossier $HOME/bin à $PATH.

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

3. Installez pv et déplacez-le vers $HOME/bin/pv.

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

4. Mettez à jour votre invite bash.

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

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

5. Vérifiez que vous êtes connecté à gcloud avec le compte utilisateur souhaité.

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

6. Obtenez l'ID de votre projet administrateur Terraform en exécutant la commande suivante:

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

7. Toutes les ressources associées à l'atelier sont stockées en tant que variables dans un fichier vars.sh stocké dans un bucket GCS du projet d'administration Terraform. Récupérez le fichier vars.sh de votre projet administrateur Terraform.

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

8. Cliquez sur le lien affiché pour ouvrir la page Cloud Build du projet administrateur Terraform et vérifier que la compilation s'est bien déroulée.

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

Si vous accédez à Cloud Console pour la première fois, acceptez les conditions d'utilisation de Google.

9. Maintenant que vous êtes sur la page Cloud Build, cliquez sur le lien History dans le menu de navigation de gauche, puis sur la dernière compilation pour afficher les détails de l'application Terraform initiale. Les ressources suivantes sont créées dans le cadre du script Terraform. Vous pouvez également consulter le schéma de l'architecture ci-dessus.

• Quatre projets GCP dans l'organisation. Le compte de facturation fourni est associé à chaque projet.
• L'un des projets correspond au projet network host project pour le VPC partagé. Aucune autre ressource n'est créée dans ce projet.
• L'un des projets est le projet ops project utilisé pour les clusters GKE du plan de contrôle Istio.
• Deux projets représentent deux équipes de développement différentes qui travaillent sur leurs services respectifs.
• Deux clusters GKE sont créés dans chacun des trois projets ops, dev1 et dev2.
• Un dépôt CSR nommé k8s-repo est créé. Il contient six dossiers pour les fichiers manifestes Kubernetes. Un dossier par cluster GKE. Ce dépôt permet de déployer des fichiers manifestes Kubernetes sur les clusters en mode GitOps.
• Un déclencheur Cloud Build est créé de sorte que chaque fois qu'un commit est effectué sur la branche principale de k8s-repo, il déploie les fichiers manifestes Kubernetes sur les clusters GKE à partir de leurs dossiers respectifs.

L'exécution du script Terraform prend entre 40 et 50 minutes.

10. Une fois la compilation terminée dans terraform admin project, une autre compilation démarre sur le projet opérationnel. Cliquez sur le lien affiché pour ouvrir la page Cloud Build de ops project et vérifiez que la compilation Cloud Build k8s-repo a bien été exécutée.

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

Remarque: Cette compilation doit être terminée pour que vous puissiez vérifier l'installation d'Istio.

Vérifier l'installation

11. Créez des fichiers kubeconfig pour tous les clusters. Exécutez le script ci-après.

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

Ce script crée un fichier kubeconfig dans le dossier gke appelé kubemesh.

12. Modifiez la variable KUBECONFIG pour qu'elle pointe vers le nouveau fichier kubeconfig.

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

13. Ajoutez les variables vars.sh et KUBECONFIG au fichier .bashrc dans Cloud Shell, afin que sa source soit récupérée à chaque redémarrage de Cloud Shell.

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

14. Listez les contextes de votre cluster. Vous devriez voir six clusters.

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

Vérifier l'installation d'Istio

15. Assurez-vous qu'Istio est installé sur les deux clusters en vérifiant que tous les pods sont en cours d'exécution et que les tâches sont terminées.

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. Assurez-vous qu'Istio est installé sur les deux clusters dev1. Seuls citadelle, side-injector et Coredns s'exécutent dans les clusters dev1. Elles partagent un plan de contrôle Istio s'exécutant dans le cluster ops-1.

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

17. Assurez-vous qu'Istio est installé sur les deux clusters dev2. Seuls citadelle, side-injector et Coredns s'exécutent dans les clusters dev2. Elles partagent un plan de contrôle Istio s'exécutant dans le cluster ops-2.

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

    `Output (do not copy)`

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

Vérifier la détection de services pour les plans de contrôle partagés

18. Vous pouvez également vérifier que les secrets sont déployés.

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

Dans cet atelier, vous allez utiliser un seul VPC partagé dans lequel tous les clusters GKE sont créés. Pour découvrir les services sur les clusters, utilisez les fichiers kubeconfig (pour chacun des clusters d'application) créés en tant que secrets dans les clusters d'opérations. Il utilise ces secrets pour découvrir les services en interrogeant le serveur d'API Kube des clusters d'application (authentifiés via les secrets ci-dessus). Vous constatez que les deux clusters d'opérations peuvent s'authentifier auprès de tous les clusters d'application à l'aide de secrets créés par kubeconfig. Les clusters Ops peuvent découvrir automatiquement des services en utilisant les fichiers kubeconfig comme méthode secrète. Pour ce faire, le Pilot des clusters d'opérations doit avoir accès au serveur d'API Kube de tous les autres clusters. Si Pilot ne peut pas accéder aux serveurs d'API Kube, vous devez ajouter manuellement les services distants en tant qu'ServiceEntries. Vous pouvez considérer les entrées ServiceEntry comme des entrées DNS dans votre registre de services. Les entrées de service définissent un service à l'aide d'un nom DNS complet ( FQDN) et d'une adresse IP accessible. Pour en savoir plus, consultez la documentation sur le multicluster Istio.

6. Présentation du dépôt d'infrastructure

Infrastructure Cloud Build

Les ressources GCP pour cet atelier ont été créées à l'aide de Cloud Build et d'un dépôt CSR infrastructure. Vous venez d'exécuter un script d'amorçage (situé dans scripts/bootstrap_workshop.sh) à partir de votre terminal local. Le script d'amorçage crée un dossier GCP, un projet administrateur Terraform et les autorisations IAM appropriées pour le compte de service Cloud Build. Le projet d'administration Terraform permet de stocker les états, les journaux et divers scripts Terraform. Il contient les dépôts CSR infrastructure et k8s_repo. Ces dépôts sont expliqués en détail dans la section suivante. Aucune autre ressource de l'atelier n'est créée dans le projet d'administration Terraform. Le compte de service Cloud Build du projet administrateur Terraform est utilisé pour créer les ressources de l'atelier.

Un fichier cloudbuild.yaml situé dans le dossier infrastructure permet de créer des ressources GCP pour l'atelier. Il crée une image de compilateur personnalisée avec tous les outils nécessaires à la création de ressources GCP. Ces outils incluent le SDK gcloud, Terraform et d'autres utilitaires tels que Python, Git, jq, etc. L'image du compilateur personnalisé exécute terraform plan et apply pour chaque ressource. Les fichiers Terraform de chaque ressource se trouvent dans des dossiers distincts (plus d'informations dans la section suivante). Les ressources sont compilées une par une, dans l'ordre habituel (par exemple, un projet GCP est créé avant que les ressources ne soient créées dans le projet). Pour en savoir plus, veuillez consulter le fichier cloudbuild.yaml.

Cloud Build est déclenché à chaque fois qu'un commit est effectué dans le dépôt infrastructure. Toute modification apportée à l'infrastructure est stockée en tant que Infrastructure as Code (IaC) et validée dans le dépôt. L'état de votre atelier est toujours stocké dans ce dépôt.

Structure des dossiers (équipes, environnements et ressources)

Le dépôt Infrastructure configure les ressources d'infrastructure GCP pour l'atelier. Il est structuré en dossiers et sous-dossiers. Les dossiers de base du dépôt représentent les team qui possèdent des ressources GCP spécifiques. La couche de dossiers suivante représente l'élément environment spécifique de l'équipe (par exemple, "dev", "stage" et "prod"). La couche de dossiers suivante dans l'environnement représente le resource spécifique (par exemple, host_project, gke_clusters, etc.). Les scripts et les fichiers Terraform requis se trouvent dans les dossiers de ressources.

Les quatre types d'équipes suivants sont représentés dans cet atelier:

1. Infrastructure : représente l'équipe chargée de l'infrastructure cloud. Il est responsable de la création des ressources GCP pour toutes les autres équipes. Ils utilisent le projet d'administration Terraform pour leurs ressources. Le dépôt d'infrastructure lui-même se trouve dans le projet d'administration Terraform, ainsi que dans les fichiers d'état Terraform (expliqués ci-dessous). Ces ressources sont créées par un script bash au cours du processus d'amorçage (pour en savoir plus, consultez le Module 0 : Workflow d'administrateur).
2. network : représente l'équipe de mise en réseau. Ils sont responsables du VPC et des ressources réseau. Il possède les ressources GCP suivantes.
3. host project : représente le projet hôte du VPC partagé.
4. shared VPC : représente le VPC partagé, les sous-réseaux, les plages d'adresses IP secondaires, les routes et les règles de pare-feu.
5. ops : représente l'équipe chargée des opérations/devops. Il est propriétaire des ressources ci-dessous.
6. ops project : représente un projet pour toutes les ressources opérationnelles.
7. gke clusters : un cluster GKE d'opérations par région. Le plan de contrôle Istio est installé dans chacun des clusters GKE des opérations.
8. k8s-repo : dépôt CSR contenant les fichiers manifestes GKE pour tous les clusters GKE.
9. apps : représente les équipes applications. Cet atelier simule deux équipes : app1 et app2. Il est propriétaire des ressources ci-dessous.
10. app projects : chaque équipe chargée des applications bénéficie de son propre ensemble de projets. Cela leur permet de contrôler la facturation et IAM pour leur projet spécifique.
11. gke clusters : clusters d'application sur lesquels s'exécutent les conteneurs/pods d'applications.
12. gce instances, éventuellement si les applications s'exécutent sur des instances GCE Dans cet atelier, app1 dispose de quelques instances GCE dans lesquelles une partie de l'application s'exécute.

Dans cet atelier, la même application (Hipster Shop) représente à la fois app1 et app2.

Fournisseur, états et sorties : backends et états partagés

Les fournisseurs google et google-beta se trouvent à l'adresse gcp/[environment]/gcp/provider.tf. Le fichier provider.tf est associé à un lien symbolique dans chaque dossier de ressources. Cela vous permet de modifier le fournisseur à un seul endroit plutôt que de les gérer individuellement pour chaque ressource.

Chaque ressource contient un fichier backend.tf qui définit l'emplacement du fichier tfstate de la ressource. Ce fichier backend.tf est généré à partir d'un modèle (situé dans templates/backend.tf_tmpl) à l'aide d'un script (situé dans scripts/setup_terraform_admin_project), puis placé dans le dossier de ressources correspondant. Les buckets Google Cloud Storage (GCS) sont utilisés pour les backends. Le nom du dossier du bucket GCS correspond au nom de la ressource. Tous les backends de ressources se trouvent dans le projet d'administration Terraform.

Les ressources avec des valeurs interdépendantes contiennent un fichier output.tf. Les valeurs de sortie requises sont stockées dans le fichier tfstate défini dans le backend pour cette ressource particulière. Par exemple, pour créer un cluster GKE dans un projet, vous devez connaître l'ID du projet. L'ID du projet est généré via output.tf dans le fichier tfstate, qui peut être utilisé via une source de données terraform_remote_state dans la ressource de cluster GKE.

Le fichier shared_state est une source de données terraform_remote_state pointant vers le fichier tfstate d'une ressource. Il existe un ou plusieurs fichiers shared_state_[resource_name].tf dans les dossiers de ressources qui nécessitent des sorties d'autres ressources. Par exemple, le dossier de ressources ops_gke contient des fichiers shared_state de ressources ops_project et shared_vpc, car vous avez besoin de l'ID du projet et des détails du VPC pour créer des clusters GKE dans le projet Ops. Les fichiers shared_state sont générés à partir d'un modèle (situé dans templates/shared_state.tf_tmpl) à l'aide d'un script (situé dans scripts/setup_terraform_admin_project). Toutes les ressources Les fichiers shared_state sont placés dans le dossier gcp/[environment]/shared_states. Les fichiers partagés_state requis sont associés à un lien symbolique dans les dossiers de ressources respectifs. Le fait de placer tous les fichiers shared_state dans un dossier et de les associer par sym dans les dossiers de ressources appropriés facilite la gestion de tous les fichiers d'état en un seul endroit.

Variables

Toutes les valeurs de ressources sont stockées en tant que variables d'environnement. Ces variables sont stockées (en tant qu'instructions d'exportation) dans un fichier nommé vars.sh, situé dans un bucket GCS du projet d'administration Terraform. Il contient l'ID de l'organisation, le compte de facturation, les ID de projet, les détails du cluster GKE, etc. Vous pouvez télécharger et générer le vars.sh à partir de n'importe quel terminal afin d'obtenir les valeurs pour votre configuration.

Les variables Terraform sont stockées dans vars.sh en tant que TF_VAR_[variable name]. Ces variables permettent de générer un fichier variables.tfvars dans le dossier de ressources correspondant. Le fichier variables.tfvars contient toutes les variables et leurs valeurs. Le fichier variables.tfvars est généré à partir d'un fichier de modèle situé dans le même dossier et à l'aide d'un script (situé dans scripts/setup_terraform_admin_project).

Explication du dépôt K8s

k8s_repo est un dépôt CSR (distinct du dépôt d'infrastructure) situé dans le projet d'administration Terraform. Il permet de stocker et d'appliquer les fichiers manifestes GKE à tous les clusters GKE. k8s_repo est créé par l'infrastructure Cloud Build (consultez la section précédente pour en savoir plus). Au cours du processus initial d'infrastructure Cloud Build, six clusters GKE au total sont créés. Dans k8s_repo, six dossiers sont créés. Chaque dossier (dont le nom correspond au nom du cluster GKE) correspond à un cluster GKE contenant ses fichiers manifestes de ressources respectifs. Comme pour la création d'une infrastructure, Cloud Build permet d'appliquer les fichiers manifestes Kubernetes à tous les clusters GKE à l'aide du dépôt k8s_repo. Cloud Build est déclenché à chaque fois qu'un commit est effectué dans le dépôt k8s_repo. Comme pour l'infrastructure, tous les fichiers manifestes Kubernetes sont stockés sous forme de code dans le dépôt k8s_repo, et l'état de chaque cluster GKE est toujours stocké dans son dossier respectif.

Lors de la compilation initiale de l'infrastructure, k8s_repo est créé et Istio est installé sur tous les clusters.

Projets, clusters GKE et espaces de noms

Les ressources de cet atelier sont réparties entre différents projets GCP. Les projets doivent correspondre à la structure organisationnelle (ou équipe) de votre entreprise. Les équipes de votre organisation responsables de différents projets, produits et ressources utilisent différents projets GCP. Le fait d'avoir des projets distincts vous permet de créer des ensembles distincts d'autorisations IAM et de gérer la facturation au niveau d'un projet. De plus, les quotas sont également gérés au niveau du projet.

Cinq équipes sont représentées dans cet atelier, chacune ayant son propre projet.

1. L'équipe chargée de l'infrastructure qui crée les ressources GCP utilise l'Terraform admin project. Ils gèrent l'Infrastructure as Code dans un dépôt CSR (appelé infrastructure) et stockent toutes les informations d'état Terraform concernant les ressources créées dans GCP dans les buckets GCS. Ils contrôlent l'accès au dépôt CSR et aux buckets GCS d'état Terraform.
2. L'équipe réseau qui crée le VPC partagé utilise l'host project. Ce projet contient le VPC, les sous-réseaux, les routes et les règles de pare-feu. Le fait de disposer d'un VPC partagé leur permet de gérer de manière centralisée la mise en réseau des ressources GCP. Tous les projets utilisaient ce VPC partagé unique pour la mise en réseau.
3. L'équipe chargée des opérations/de la plate-forme qui crée les clusters GKE et les plans de contrôle ASM/Istio utilise le ops project. Ils gèrent le cycle de vie des clusters GKE et du maillage de services. Ils sont chargés de renforcer les clusters, de gérer la résilience et l'évolutivité de la plate-forme Kubernetes. Dans cet atelier, vous allez déployer des ressources dans Kubernetes à l'aide de la méthode Gitops. Le projet Ops contient un dépôt CSR (appelé k8s_repo).
4. Enfin, les équipes dev1 et dev2 (représentent deux équipes de développement) qui créent des applications utilisent leurs propres dev1 et dev2 projects. Il s'agit des applications et services que vous fournissez à vos clients. Ils sont basés sur la plate-forme gérée par l'équipe chargée des opérations. Les ressources (déploiements, services, etc.) sont transférées vers le k8s_repo et déployées vers les clusters appropriés. Il est important de noter que cet atelier ne porte pas sur les bonnes pratiques et les outils de CI/CD. Vous allez utiliser Cloud Build pour automatiser le déploiement des ressources Kubernetes directement sur les clusters GKE. Dans des scénarios de production réels, vous devez utiliser une solution CI/CD appropriée pour déployer des applications sur des clusters GKE.

Il existe deux types de clusters GKE dans cet atelier.

1. Clusters Ops : permet à l'équipe des opérations d'exécuter des outils DevOps. Dans cet atelier, ils exécutent le plan de contrôle ASM/Istio pour gérer le maillage de services.
2. Clusters d'applications (applications) : permet aux équipes de développement d'exécuter des applications. Dans cet atelier, nous allons utiliser l'application Hipster Shop.

En séparant les outils ops/admin des clusters exécutant l'application, vous pouvez gérer le cycle de vie de chaque ressource indépendamment. Les deux types de clusters existent également dans différents projets en lien avec l'équipe ou le produit qui les utilise, ce qui facilite la gestion des autorisations IAM.

Il existe un total de six clusters GKE. Deux clusters d'opérations régionaux sont créés dans le projet opérationnel. Le plan de contrôle ASM/Istio est installé sur les deux clusters d'opérations. Chaque cluster d'opérations se trouve dans une région différente. Il existe également quatre clusters d'application zonaux. Celles-ci sont créées dans leurs propres projets. Cet atelier simule deux équipes de développement, chacune avec son propre projet. Chaque projet contient deux clusters d'application. Les clusters d'applications sont des clusters zonaux dans différentes zones. Les quatre clusters d'application sont situés dans deux régions et quatre zones. Vous obtenez ainsi une redondance régionale et zonale.

L'application utilisée dans cet atelier, l'application Hipster Shop, est déployée sur les quatre clusters d'applications. Chaque microservice se trouve dans son propre espace de noms dans chaque cluster d'application. Les déploiements (pods) d'applications Hipster Shop ne sont pas déployés sur les clusters d'opérations. Toutefois, les espaces de noms et les ressources de service de tous les microservices sont également créés dans les clusters ops. Le plan de contrôle ASM/Istio utilise les registres de services Kubernetes pour la détection de services. En l'absence de services (dans les clusters "ops"), vous devrez créer manuellement des entrées ServiceEntry pour chaque service exécuté dans le cluster d'applications.

Dans cet atelier, vous allez déployer une application de microservices à 10 niveaux. Il s'agit d'une application Web d'e-commerce appelée " Hipster Shop" où les utilisateurs peuvent parcourir les articles, les ajouter au panier et les acheter.

Fichiers manifestes Kubernetes et k8s_repo

Vous utiliserez k8s_repo pour ajouter des ressources Kubernetes à tous les clusters GKE. Pour ce faire, vous devez copier les fichiers manifestes Kubernetes et effectuer un commit sur k8s_repo. Tous les commits effectués sur k8s_repo déclenchent une tâche Cloud Build qui déploie les fichiers manifestes Kubernetes dans le cluster correspondant. Le fichier manifeste de chaque cluster se trouve dans un dossier distinct portant le même nom que le cluster.

Les six noms de cluster sont les suivants:

1. gke-asm-1-r1-prod : cluster d'opérations régional dans la région 1
2. gke-asm-2-r2-prod : cluster d'opérations régional dans la région 2
3. gke-1-apps-r1a-prod : cluster d'applications dans la zone a de la région 1
4. gke-2-apps-r1b-prod : cluster d'applications dans la région 1, zone b
5. gke-3-apps-r2a-prod : cluster d'applications dans la zone a de la région 2
6. gke-4-apps-r2b-prod : cluster d'applications dans la région 2 zone b

k8s_repo contient des dossiers correspondant à ces clusters. Tout fichier manifeste placé dans ces dossiers est appliqué au cluster GKE correspondant. Les fichiers manifestes de chaque cluster sont placés dans des sous-dossiers (dans le dossier principal du cluster) pour faciliter la gestion. Dans cet atelier, vous allez effectuer le suivi des ressources déployées à l'aide de Kustomize. Pour en savoir plus, veuillez consulter la documentation officielle de Kustomize.

7. Déployer l'exemple d'application

Objectif: Déployer l'application Hipster Shop sur des clusters d'applications

• Cloner k8s-repo
• Copier les fichiers manifestes Hipster Shop dans tous les clusters d'applications
• Créer des services pour l'application Hipster Shop dans les clusters des opérations
• Configurer loadgenerators dans les clusters d'opérations pour tester la connectivité globale
• Vérifier une connectivité sécurisée à l'application Hipster Shop

SCRIPT POUR RAPIDITÉ

Si vous choisissez cette méthode, exécutez le script suivant pour terminer cet atelier.

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

Instructions de l'atelier sur la méthode copier-coller

Si vous avez déjà terminé le script de suivi rapide de cet atelier, n'exécutez pas la méthode copier-coller ci-dessous**.**

Cloner le dépôt source du projet Ops

Lors de la compilation initiale de l'infrastructure Terraform, k8s-repo est déjà créé dans le projet opérationnel.

1. Créez un répertoire vide pour le dépôt Git:

mkdir $WORKDIR/k8s-repo
 

2. Ouvrez le dépôt Git, ajoutez un dépôt distant et extrayez le maître à partir du dépôt distant:

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. Définir la configuration locale Git

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

Copier des fichiers manifestes, valider et transférer

4. Copiez les espaces de noms et les services Hipster Shop dans le dépôt source pour tous les clusters.

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. Copiez le dossier de l'application kustomization.yaml dans tous les clusters.

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. Copiez les déploiements Hipster Shop, RBAC et PodSecurityPolicy dans le dépôt source des clusters d'applications.

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. Suppression du déploiement cartservice, rbac et podsecuritypolicy de tous les clusters de développement, sauf un. Hipster Shop n'a pas été conçu pour le déploiement multicluster. Par conséquent, pour éviter des résultats incohérents, nous n'utilisons qu'un seul panier.

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. Ajoutez le déploiement de cartservice, rbac et podsecuritypolicy à kustomization.yaml uniquement dans le premier cluster de développement.

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. Suppression des règles Podsecuritypolicies, des déploiements et des répertoires rbac du cluster d'opérations 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. Remplacez PROJECT_ID dans les fichiers manifestes RBAC.

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

11. Copiez les fichiers manifestes IngressGateway et VirtualService dans le dépôt source des clusters Ops.

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. Copiez les ressources Config Connector sur l'un des clusters de chaque projet.

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. Remplacez PROJECT_ID dans les fichiers manifestes de Config Connector.

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

14. Copiez les fichiers manifestes loadgenerator (déploiement, PodSecurityPolicy et RBAC) dans les clusters d'opérations. L'application Hipster Shop est exposée à l'aide d'un équilibreur de charge Google Cloud (GCLB) mondial. GCLB reçoit le trafic client (destiné à frontend) et l'envoie à l'instance de service la plus proche. L'utilisation de loadgenerator sur les deux clusters d'opérations garantit que le trafic est envoyé aux deux passerelles d'entrée Istio exécutées dans les clusters d'opérations. L'équilibrage de charge est expliqué en détail dans la section suivante.

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. Remplacez l'ID du projet d'opérations dans les fichiers manifestes loadgenerator pour les deux clusters d'opérations.

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. Ajoutez les ressources loadgenerator au fichier kustomization.yaml pour les deux clusters d'opérations.

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. Engagez-vous sur 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. Affichez l'état du projet Ops Cloud Build dans un onglet ouvert ou en cliquant sur le lien suivant:

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

Vérifier le déploiement de l'application

19. Vérifiez que les pods de tous les espaces de noms de l'application, à l'exception du panier, sont en cours d'exécution dans tous les clusters de développement.

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. Vérifiez que les pods de l'espace de noms "cart" sont en cours d'exécution dans le premier cluster de développement uniquement.

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

Accéder à l'application Hipster Shop

Équilibrage de charge au niveau mondial

L'application Hipster Shop est maintenant déployée sur les quatre clusters d'application. Ces clusters sont répartis dans deux régions et quatre zones. Les clients peuvent accéder à l'application Hipster Shop via le service frontend. Le service frontend s'exécute sur les quatre clusters d'application. Un équilibreur de charge Google Cloud ( GCLB) permet d'acheminer le trafic client vers les quatre instances du service frontend.

Les passerelles d'entrée Istio ne s'exécutent que dans les clusters d'opérations et agissent comme un équilibreur de charge régional vers les deux clusters d'application zonaux de la région. GCLB utilise les deux passerelles d'entrée Istio (s'exécutant dans les deux clusters d'opérations) comme backends vers le service d'interface global. Les passerelles d'entrée Istio reçoivent le trafic client provenant de GCLB, puis l'envoient aux pods frontend exécutés dans les clusters d'application.

Vous pouvez également placer directement les passerelles d'entrée Istio sur les clusters d'application, et GCLB pourra les utiliser comme backends.

Contrôleur GKE Autoneg

Le service Kubernetes de la passerelle d'entrée Istio s'enregistre en tant que backend auprès de l'outil GCLB à l'aide de groupes de points de terminaison du réseau (NEG). Les NEG permettent un équilibrage de charge natif en conteneurs à l'aide de GCLB. Les NEG sont créés via une annotation spéciale sur un service Kubernetes, afin qu'ils puissent s'enregistrer dans le contrôleur NEG. Le contrôleur Autoneg est un contrôleur GKE spécial qui automatise la création des NEG et leur affectation en tant que backends à un GCLB à l'aide d'annotations de service. Les plans de contrôle Istio, y compris les passerelles d'entrée Istio, sont déployés lors de la compilation Terraform Cloud Build initiale de l'infrastructure. La configuration de GCLB et d'autoneg est effectuée dans le cadre de la compilation Cloud Build initiale de l'infrastructure Terraform.

Sécuriser l'entrée à l'aide de Cloud Endpoints et de certificats gérés

Les certificats gérés par GCP permettent de sécuriser le trafic client vers le service GCLB frontend. GCLB utilise des certificats gérés pour le service frontend mondial, qui sont arrêtés au niveau de GCLB. Dans cet atelier, vous allez utiliser Cloud Endpoints comme domaine pour le certificat géré. Vous pouvez également utiliser votre domaine et un nom DNS pour frontend afin de créer des certificats gérés par GCP.

21. Pour accéder au magasin Hipster, cliquez sur le lien de sortie de la commande suivante.

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

22. Vous pouvez vérifier la validité du certificat en cliquant sur le symbole en forme de cadenas dans la barre d'adresse de l'onglet Chrome.

Vérifier l'équilibrage de charge global

Lors du déploiement de l'application, des générateurs de charge ont été déployés dans les deux clusters d'opérations qui génèrent du trafic de test vers le lien Cloud Endpoints du magasin GCLB Hipster. Vérifiez que l'équilibreur de charge Google Cloud reçoit le trafic et l'envoie aux deux passerelles d'entrée Istio.

23. Obtenez le GCLB > Monitoring du projet opérationnel dans lequel l'objet GCLB de Hipster Shop est créé.

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. Dans le menu déroulant "Backend", remplacez Tous les backends par istio-ingressgateway, comme indiqué ci-dessous.

25. Le trafic des notes va à la fois vers istio-ingressgateways.

Trois NEG sont créés par istio-ingressgateway. Les clusters d'opérations étant des clusters régionaux, un NEG est créé pour chaque zone de la région. En revanche, les pods istio-ingressgateway s'exécutent dans une seule zone par région. Le trafic est affiché en direction des pods istio-ingressgateway.

Les générateurs de charge s'exécutent dans les deux clusters d'opérations simulant le trafic client provenant des deux régions dans lesquelles ils se trouvent. La charge générée dans la région 1 du cluster d'opérations est envoyée à istio-ingressgateway dans la région 2. De même, la charge générée dans la région 2 du cluster d'opérations est envoyée à istio-ingressgateway dans la région 2.

8. Observabilité avec Stackdriver

Objectif: Connecter la télémétrie Istio à Stackdriver et procéder à la validation

• Installer istio-telemetry ressources
• Créer/mettre à jour des tableaux de bord de services Istio
• Afficher les journaux du conteneur
• Afficher le traçage distribué dans Stackdriver

SCRIPT POUR RAPIDITÉ

Si vous choisissez cette méthode, exécutez le script suivant pour terminer cet atelier.

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

Instructions de l'atelier sur la méthode copier-coller

Si vous avez déjà terminé le script de suivi rapide de cet atelier, n'exécutez pas la méthode copier-coller ci-dessous**.**

L'une des principales fonctionnalités d'Istio est l'observabilité intégrée ("o11y"). Cela signifie que même avec des conteneurs non instrumentés par boîte noire, les opérateurs peuvent toujours observer le trafic entrant et sortant de ces conteneurs, fournissant ainsi des services aux clients. Cette observation prend la forme de différentes méthodes: les métriques, les journaux et les traces.

Nous utiliserons également le système de génération de charge intégré dans Hipster Shop. L'observabilité ne fonctionne pas très bien dans un système statique sans trafic. La génération de charge nous aide donc à comprendre son fonctionnement. Cette charge est déjà en cours d'exécution, nous allons maintenant pouvoir la voir.

1. Installez le fichier de configuration Istio vers Stackdriver.

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

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

2. Effectuez un commit sur k8s-repo.

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

3. Affichez l'état du projet Ops Cloud Build dans un onglet ouvert ou en cliquant sur le lien suivant:

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

4. Vérifiez l'intégration Istio → Stackdriver. Obtenez l'objet CRD Stackdriver Handler.

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

Le résultat doit afficher un gestionnaire nommé "stackdriver" :

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

5. Vérifiez que l'exportation des métriques Istio vers Stackdriver fonctionne. Cliquez sur le résultat du lien de cette commande:

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

Vous serez invité à créer un espace de travail portant le nom du projet Ops. Il vous suffit de cliquer sur "OK". Si vous êtes invité à ouvrir la nouvelle interface utilisateur, il vous suffit de fermer la boîte de dialogue.

Dans l'Explorateur de métriques, sous "Find resource type and metric" (Rechercher un type de ressource et une métrique), saisissez "istio" pour voir des options comme "Nombre de requêtes du serveur" sur le conteneur Kubernetes type de ressource. Cela nous montre que les métriques circulent depuis le maillage vers Stackdriver.

Pour afficher les lignes ci-dessous, vous devez appliquer le libellé "Grouper par" destination_service_name.

Visualiser des métriques à l'aide de tableaux de bord:

Maintenant que nos métriques se trouvent dans le système Stackdriver APM, nous souhaitons les visualiser. Dans cette section, nous allons installer un tableau de bord prédéfini qui nous montre les trois Golden Signals" de métriques: Trafic (requêtes par seconde), Latence (dans ce cas, 99e et 50e centiles) et Erreurs (nous excluons la Saturation dans cet exemple).

Le proxy Envoy d'Istio fournit plusieurs métriques, mais celles-ci constituent un bon ensemble pour commencer. Vous trouverez une liste exhaustive sur cette page. Notez que chaque métrique comporte un ensemble d'étiquettes pouvant être utilisées pour le filtrage et l'agrégation, par exemple: destination_service, source_workload_namespace, response_code, istio_tcp_received_bytes_total, etc.

6. Ajoutons maintenant notre tableau de bord de métriques prédéfinies. Nous allons utiliser directement l'API Dashboard. Il s'agit d'une opération que vous ne feriez normalement pas en générant manuellement des appels d'API. Cela ferait partie d'un système d'automatisation, ou vous créeriez manuellement le tableau de bord dans l'UI Web. Cela nous permettra de commencer rapidement:

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. Accédez au lien de sortie ci-dessous pour afficher le nouveau tableau de bord des services.

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

Nous pourrions modifier le tableau de bord sur place à l'aide de l'expérience utilisateur, mais dans notre cas, nous allons rapidement ajouter un nouveau graphique à l'aide de l'API. Pour ce faire, ouvrez la dernière version du tableau de bord, appliquez vos modifications, puis remontez-la à l'aide de la méthode HTTP PATCH.

8. Vous pouvez obtenir un tableau de bord existant en interrogeant l'API Monitoring. Récupérez le tableau de bord existant qui vient d'être ajouté:

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. Ajouter un nouveau graphique: (50e centile latence): [ Documentation de référence de l'API] Nous pouvons maintenant ajouter un nouveau widget de graphique à notre tableau de bord dans le code. Cette modification peut être examinée par des pairs et vérifiée dans le contrôle des versions. Voici un widget à ajouter qui affiche la latence au 50e centile (latence médiane).

Essayez de modifier le tableau de bord que vous venez de recevoir, en ajoutant un nouveau bloc:

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. Mettez à jour le tableau de bord des services existant:

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. Pour afficher le tableau de bord mis à jour, accédez au lien de sortie suivant:

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

12. Effectuez une analyse de journaux simple.

Istio fournit un ensemble de journaux structurés pour l'ensemble du trafic réseau d'un réseau maillé et les importe dans Stackdriver Logging pour permettre une analyse multicluster dans un seul et même outil performant. Les journaux sont annotés avec des métadonnées au niveau du service telles que le cluster, le conteneur, l'application, connection_id, etc.

Un exemple d'entrée de journal (dans ce cas, le journal d'accès du proxy Envoy) peut ressembler à ceci (abrégé):

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

Affichez vos journaux ici:

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

Vous pouvez afficher les journaux du plan de contrôle d'Istio en sélectionnant Ressource > conteneur Kubernetes et la recherche "pilote"

Ici, nous pouvons voir le plan de contrôle Istio qui transmet la configuration du proxy aux proxys side-car pour chaque exemple de service d'application. « CDS », "LDS" et « RDS » représentent différentes API Envoy ( en savoir plus).

Au-delà des journaux d'Istio, les journaux de conteneurs ainsi que les journaux d'infrastructure ou d'autres services GCP sont disponibles dans la même interface. Voici quelques exemples de requêtes de journaux pour GKE. La visionneuse de journaux vous permet également de créer des métriques à partir des journaux (par exemple, "compter chaque erreur correspondant à une chaîne") qui peuvent être utilisées dans un tableau de bord ou dans le cadre d'une alerte. Les journaux peuvent également être diffusés vers d'autres outils d'analyse tels que BigQuery.

Exemples de filtres pour une boutique hipster:

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

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

13. Découvrez les traces distribuées.

Maintenant que vous utilisez un système distribué, le débogage nécessite un nouvel outil: le traçage distribué. Cet outil vous permet de découvrir des statistiques sur la façon dont vos services interagissent (comme les événements lents aberrants illustrés ci-dessous). Il vous permet également de parcourir des échantillons de traces brutes pour examiner en détail la situation réelle.

La vue chronologique affiche toutes les requêtes au fil du temps, représentées dans un graphique en fonction de leur latence ou du temps passé entre la requête initiale, via la pile Hipster, pour répondre enfin à l'utilisateur final. Plus les points sont élevés, plus l'expérience utilisateur est lente (et moins heureuse !)

Vous pouvez cliquer sur un point pour obtenir la vue détaillée en cascade de cette requête spécifique. Cette capacité à trouver les détails bruts d'une requête spécifique (et pas seulement des statistiques globales) est essentielle pour comprendre l'interaction entre les services, en particulier lorsque vous recherchez des interactions rares, mais mauvaises, entre les services.

La vue en cascade devrait être connue pour tous ceux qui ont utilisé un débogueur. Toutefois, dans ce cas, au lieu d'afficher le temps passé dans les différents processus d'une même application, il s'agit du temps passé à parcourir notre réseau maillé entre les services, qui s'exécutent dans des conteneurs distincts.

Vous y trouverez vos traces:

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

Capture d'écran de l'outil:

9. Authentification TLS mutuelle

Objectif: Sécuriser la connectivité entre les microservices (AuthN).

• Activer l'authentification mTLS au niveau du réseau maillé
• Vérifier mTLS en inspectant les journaux

SCRIPT POUR RAPIDITÉ

Si vous choisissez cette méthode, exécutez le script suivant pour terminer cet atelier.

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

Instructions de l'atelier sur la méthode copier-coller

Si vous avez déjà terminé le script de suivi rapide de cet atelier, n'exécutez pas la méthode copier-coller ci-dessous**.**

Maintenant que nos applications sont installées et que l'observabilité est configurée, nous pouvons commencer à sécuriser les connexions entre les services et nous assurer qu'elle continue de fonctionner.

Par exemple, nous pouvons voir dans le tableau de bord Kiali que nos services n'utilisent pas MTLS (pas d'icône en forme de cadenas). Mais le trafic circule et le système fonctionne correctement. Notre tableau de bord des métriques d'or de StackDriver nous permet de nous assurer que tout fonctionne dans l'ensemble.

1. Vérifiez la règle MeshPolicy dans les clusters d'opérations. Notez que mTLS est PERMISSIVE, ce qui permet à la fois le trafic chiffré et non-mTLS.

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

    `Output (do not copy)`

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

Istio est configuré sur tous les clusters à l'aide de l'opérateur Istio, qui utilise la ressource personnalisée IstioControlPlane. Nous allons configurer l'authentification mTLS dans tous les clusters en mettant à jour la RS IstioControlPlane et le dépôt k8s. Configuration globale > mTLS > enabled: true dans la RS d'IstioControlPlane entraîne les deux modifications suivantes au plan de contrôle Istio:

• MeshPolicy est configuré pour activer l'authentification mTLS à l'échelle du réseau maillé pour tous les services exécutés dans tous les clusters.
• Une règle DestinationRule est créée pour autoriser le trafic ISTIO_MUTUAL entre les services exécutés dans tous les clusters.

2. Nous allons appliquer un correctif kustomize à la RS d'istioControlPlane pour activer l'authentification mTLS à l'échelle du cluster. Copiez le correctif dans le répertoire approprié pour tous les clusters et ajoutez un correctif kustomize.

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

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

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

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

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

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

3. Effectuez un commit sur k8s-repo.

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

4. Affichez l'état du projet Ops Cloud Build dans un onglet ouvert ou en cliquant sur le lien suivant:

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

 

Valider mTLS

5. Vérifiez à nouveau MeshPolicy dans les clusters d'opérations. Notez que mTLS n'est plus PERMISSIVE et n'autorisera que le trafic mTLS.

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

Résultat (ne pas copier) :

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

6. Décrivez la règle DestinationRule créée par le contrôleur d'opérateur Istio.

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

Résultat (ne pas copier) :

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

Nous pouvons également observer le passage du protocole HTTP au protocole HTTPS dans les journaux.

Pour afficher ce champ à partir des journaux de l'interface utilisateur, cliquez sur une entrée de journal, puis sur la valeur du champ que vous souhaitez afficher. Dans notre cas, cliquez sur "http". à côté de "protocole:

Vous pouvez ainsi visualiser le changement :

10. Déploiements Canary

Objectif: déployer une nouvelle version du service de frontend.

• Déployer le service frontend-v2 (prochaine version de production) dans une région
• Utiliser DestinationRules et VirtualServices pour orienter lentement le trafic vers frontend-v2
• Vérifier le pipeline de déploiement GitOps en inspectant la série de commits dans k8s-repo

SCRIPT POUR RAPIDITÉ

Si vous choisissez cette méthode, exécutez le script suivant pour terminer cet atelier.

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

Instructions de l'atelier sur la méthode copier-coller

Si vous avez déjà terminé le script de suivi rapide de cet atelier, n'exécutez pas la méthode copier-coller ci-dessous**.**

Un déploiement Canary est un déploiement progressif d'un nouveau service. Dans un déploiement Canary, vous envoyez une quantité croissante de trafic vers la nouvelle version, tout en envoyant le pourcentage restant à la version actuelle. Une méthode courante consiste à effectuer une analyse Canary à chaque étape de répartition du trafic et à comparer les "signaux clés" de la nouvelle version (latence, taux d'erreur, saturation) par rapport à une référence. Cela permet d'éviter les pannes et de garantir la stabilité de la nouvelle version 2. à chaque étape de la répartition du trafic.

Dans cette section, vous allez apprendre à utiliser les règles de trafic Cloud Build et Istio afin de créer un déploiement Canary de base pour une nouvelle version du service frontend.

Tout d'abord, nous allons exécuter le pipeline Canary dans la région DEV1 (us-west1), puis déployer l'interface v2 sur les deux clusters de cette région. Ensuite, nous exécuterons le pipeline Canary dans la région DEV2 (us-central) et déploierons la version v2 sur les deux clusters de cette région. Exécuter le pipeline dans l'ordre des régions plutôt qu'en parallèle dans toutes les régions permet d'éviter les pannes globales causées par une mauvaise configuration ou par des bugs dans l'application v2 elle-même.

Remarque: Nous déclencherons manuellement le pipeline Canary dans les deux régions, mais en production, vous utiliserez un déclencheur automatisé, par exemple basé sur un nouveau tag d'image Docker transféré vers un registre.

1. Dans Cloud Shell, définissez des variables d'environnement pour simplifier l'exécution des autres commandes.

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

2. Exécutez le script repo_setup.sh pour copier les fichiers manifestes de référence dans k8s-repo.

$CANARY_DIR/repo-setup.sh 
 

Les fichiers manifestes suivants sont copiés:

• Déploiement frontend-v2
• Correctif frontend-v1 (pour inclure l'étiquette "v1" et une image avec un point de terminaison "/version")
• respy, un petit pod qui imprimera la distribution des réponses HTTP et nous aidera à visualiser le déploiement Canary en temps réel.
• DestinationRule de l'interface Istio : divise le service Kubernetes de l'interface en deux sous-ensembles, v1 et v2, en fonction de la "version" étiquette de déploiement
• VirtualService Istio de l'interface : achemine 100% du trafic vers l'interface v1. Ce comportement remplace le comportement à tour de rôle par défaut du service Kubernetes, qui envoie immédiatement 50% du trafic régional Dev1 vers l'interface v2.

3. Validez les modifications dans k8s_repo:

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

4. Affichez l'état du projet Ops Cloud Build dans un onglet ouvert ou en cliquant sur le lien suivant:

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

5. Dans la console, accédez à Cloud Build pour le projet OPS1. Attendez que le pipeline Cloud Build soit terminé, puis récupérez les pods de l'espace de noms de l'interface dans les deux clusters DEV1. Le résultat suivant doit s'afficher :

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

Remarque: Appuyez sur Ctrl+C pour quitter les commandes de la montre.

Nous allons utiliser tmux pour diviser notre fenêtre Cloud Shell en deux volets:

• Le volet du bas exécute la commande "watch" pour observer la distribution des réponses HTTP pour le service de frontend.
• Le volet supérieur exécute le script de pipeline Canary.

6. Exécutez la commande suivante pour diviser la fenêtre Cloud Shell et exécuter la commande "watch" dans le volet inférieur.

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"
 

Résultat (ne pas copier)

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

Nous constatons que tout le trafic est dirigé vers le déploiement de l'interface v1, défini dans le nouveau service virtuel.

7. Exécuter le pipeline Canary dans la région Dev1 Nous fournissons un script qui met à jour les pourcentages de trafic frontend-v2 dans le service virtuel (mise à jour des pondérations à 20%, 50%, 80%, puis 100%). Entre les mises à jour, le script attend que le pipeline Cloud Build se termine. Exécutez le script de déploiement Canary pour la région Dev1. Remarque : L'exécution de ce script prend environ 10 minutes.

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

Vous pouvez voir la répartition du trafic en temps réel dans la fenêtre inférieure où vous exécutez la commande respy. Par exemple, à la marque 20 % :

Résultat (ne pas copier)

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

8. Une fois le déploiement Dev2 terminé pour frontend-v2, un message de réussite devrait s'afficher à la fin du script:

    Output (do not copy) 
   

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

9. L'ensemble du trafic frontend provenant d'un pod Dev2 doit être dirigé vers frontend-v2:

    Output (do not copy) 
   

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

10. Fermez le volet divisé.

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

11. Accédez à Cloud Source Repos au niveau du lien généré.

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

Vous devriez voir un commit distinct pour chaque pourcentage de trafic, avec le commit le plus récent en haut de la liste:

Vous allez maintenant répéter le même processus pour la région Dev2. Notez que la région Dev2 est toujours "verrouillée". v1. En effet, dans le script repo_setup de référence, nous avons déployé un service virtuel pour envoyer explicitement tout le trafic vers la version 1. Nous avons ainsi pu exécuter une version Canary régionale en toute sécurité sur Dev1 et nous assurer qu'elle fonctionnait correctement avant de déployer la nouvelle version à l'échelle mondiale.

12. Exécutez la commande suivante pour diviser la fenêtre Cloud Shell et exécuter la commande "watch" dans le volet inférieur.

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"
 

Résultat (ne pas copier)

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

Nous constatons que tout le trafic est dirigé vers le déploiement de l'interface v1, défini dans le nouveau service virtuel.

13. Exécuter le pipeline Canary dans la région Dev2 Nous fournissons un script qui met à jour les pourcentages de trafic frontend-v2 dans le service virtuel (mise à jour des pondérations à 20%, 50%, 80%, puis 100%). Entre les mises à jour, le script attend que le pipeline Cloud Build se termine. Exécutez le script de déploiement Canary pour la région Dev1. Remarque : L'exécution de ce script prend environ 10 minutes.

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

Résultat (ne pas copier)

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

14. À partir du pod Respy dans Dev2, surveillez le trafic des pods Dev2 passer progressivement de la version 1 à la version 2 de l'interface. Une fois l'exécution du script terminée, le résultat suivant doit s'afficher:

Résultat (ne pas copier)

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

15. Fermez le volet divisé.

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

Cette section explique comment utiliser Istio pour effectuer des déploiements Canary régionaux. En production, au lieu d'utiliser un script manuel, vous pouvez déclencher automatiquement ce script Canary en tant que pipeline Cloud Build, à l'aide d'un déclencheur tel qu'une nouvelle image taguée transférée vers un registre de conteneurs. Vous pouvez également ajouter une analyse Canary entre chaque étape, en analysant la latence et le taux d'erreur de la version 2 par rapport à un seuil de sécurité prédéfini, avant d'envoyer davantage de trafic.

11. Règles d'autorisation

Objectif: Configurer le contrôle RBAC entre les microservices (AuthZ)

• Créer AuthorizationPolicy pour REFUSER l'accès à un microservice
• Créer AuthorizationPolicy pour AUTORISER un accès spécifique à un microservice

SCRIPT POUR RAPIDITÉ

Si vous choisissez cette méthode, exécutez le script suivant pour terminer cet atelier.

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

Instructions de l'atelier sur la méthode copier-coller

Si vous avez déjà terminé le script de suivi rapide de cet atelier, n'exécutez pas la méthode copier-coller ci-dessous**.**

Contrairement à une application monolithique qui peut s'exécuter au même endroit, les applications de microservices distribuées dans le monde entier effectuent des appels au-delà des limites du réseau. Cela se traduit par davantage de points d'entrée dans vos applications et plus de risques d'attaques malveillantes. Étant donné que les pods Kubernetes ont des adresses IP temporaires, les règles de pare-feu traditionnelles basées sur les adresses IP ne sont plus adéquates pour sécuriser l'accès entre les charges de travail. Dans une architecture de microservices, une nouvelle approche de la sécurité est nécessaire. En s'appuyant sur les composants de sécurité Kubernetes tels que les comptes de service, Istio fournit un ensemble flexible de règles de sécurité pour vos applications.

Les stratégies Istio couvrent à la fois l'authentification et l'autorisation. L'authentification vérifie l'identité (ce serveur est-il bien tel qu'il prétend être ?), tandis que l'autorisation vérifie les autorisations (ce client est-il autorisé à le faire ?). Nous avons abordé l'authentification Istio dans la section sur l'authentification TLS mutuelle du module 1 (MeshPolicy). Dans cette section, nous allons apprendre à utiliser les règles d'autorisation d'Istio pour contrôler l'accès à l'une de nos charges de travail d'application, currencyservice.

Tout d'abord, nous allons déployer une règle AuthorizationPolicy dans les quatre clusters Dev, en fermant tout accès à currencyservice et en déclenchant une erreur dans l'interface. Ensuite, nous n'autoriserons que le service frontend à accéder à currencyservice.

1. Inspectez le contenu de currency-deny-all.yaml. Cette règle utilise des sélecteurs d'étiquettes de déploiement pour restreindre l'accès au service de change. Notez qu'il n'y a pas de champ spec. Cela signifie que cette règle refusera tout accès au service sélectionné.

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

Résultat (ne pas copier)

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

2. Copiez la règle de devise dans k8s-repo, pour les clusters d'opérations des deux régions.

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. Déployer les modifications

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

4. Vérifiez l'état du projet Ops Cloud Build dans un onglet ouvert ou en cliquant sur le lien suivant:

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

5. Une fois la compilation terminée, essayez d'accéder à l'interface de hipstershop dans un navigateur à l'aide du lien suivant:

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

Une erreur d'autorisation de currencyservice doit s'afficher:

6. Analysons comment le service de change applique cette stratégie AuthorizationPolicy. Tout d'abord, activez les journaux en mode trace sur le proxy Envoy pour l'un des pods de devise, car les appels d'autorisation bloqués ne sont pas consignés par défaut.

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. Obtenez les journaux RBAC (autorisations) à partir du proxy side-car du service de change. La mention "enforced denied" (application forcée refusée) doit s'afficher. indiquant que le service de change est configuré pour bloquer toutes les demandes entrantes.

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

Résultat (ne pas copier)

[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. Nous allons maintenant autoriser l'interface, mais pas les autres services de backend, à accéder au service de change. Ouvrez currency-allow-frontend.yaml et examinez son contenu. Notez que nous avons ajouté la règle suivante:

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

Résultat (ne pas copier)

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

Ici, nous ajoutons à la liste blanche un compte source.principal (client) spécifique pour accéder au service de change. Ce fichier source.principal est défini par un compte de service Kubernetes. Dans ce cas, le compte de service que nous ajoutons à la liste blanche est le compte de service de frontend dans l'espace de noms de l'interface.

Remarque:Lorsque vous utilisez des comptes de service Kubernetes dans les stratégies d'autorisation d'Istio, vous devez d'abord activer l'authentification TLS mutuelle au niveau du cluster, comme nous l'avons fait dans le module 1. Cela permet de s'assurer que les identifiants du compte de service sont installés dans les requêtes.

9. Copiez le règlement sur les devises mis à jour

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. Déployer les modifications

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

11. Affichez l'état du projet Ops Cloud Build dans un onglet ouvert ou en cliquant sur le lien suivant:

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

12. Une fois la compilation terminée, ouvrez à nouveau l'interface de Hipster Shop. Cette fois, aucune erreur ne devrait s'afficher sur la page d'accueil, car l'interface est explicitement autorisée à accéder au service actuel.
13. Essayez maintenant de passer la commande en ajoutant des articles à votre panier et en cliquant sur "Passer la commande". Cette fois-ci, vous devriez voir une erreur de conversion des prix du service de change. En effet, nous n'avons ajouté que l'interface à la liste blanche, ce qui signifie que le service de paiement ne peut toujours pas accéder au service de change.

14. Enfin, autorisez le service de paiement à accéder à la devise en ajoutant une autre règle à notre AuthorizationPolicy currencyservice. Notez que nous ouvrons l'accès aux devises uniquement pour les deux services qui doivent y accéder : l'interface et le paiement. Les autres backends seront toujours bloqués.
15. Ouvrez currency-allow-frontend-checkout.yaml et examinez son contenu. Notez que la liste des règles fonctionne comme une devise "OU" logique. Elle n'acceptera que les requêtes provenant de charges de travail associées à l'un de ces deux comptes de service.

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

Résultat (ne pas copier)

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. Copiez la règle d'autorisation finale dans k8s-repo.

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

17. Déployer les modifications

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

18. Affichez l'état du projet Ops Cloud Build dans un onglet ouvert ou en cliquant sur le lien suivant:

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

19. Une fois la compilation terminée, essayez d'exécuter un règlement. Tout devrait fonctionner correctement.

Cette section vous a expliqué comment utiliser les règles d'autorisation Istio pour mettre en place un contrôle des accès précis au niveau de chaque service. En production, vous pouvez créer une règle AuthorizationPolicy par service et, par exemple, utiliser une règle allow-all pour permettre à toutes les charges de travail d'un même espace de noms d'accéder les unes aux autres.

12. Scaling de l'infrastructure

Objectif: Faire évoluer l'infrastructure en ajoutant une région, un projet et des clusters.

• Cloner le dépôt infrastructure
• Mettre à jour les fichiers Terraform pour créer des ressources
• Deux sous-réseaux dans la nouvelle région (un pour le projet opérationnel et un pour le nouveau projet)
• Nouveau cluster d'opérations dans la nouvelle région (dans le nouveau sous-réseau)
• Nouveau plan de contrôle Istio pour la nouvelle région
• Deux clusters d'applications dans le nouveau projet, dans la nouvelle région
• Valider le dépôt infrastructure
• Vérifier l'installation

SCRIPT POUR RAPIDITÉ

Si vous choisissez cette méthode, exécutez le script suivant pour terminer cet atelier.

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

Instructions de l'atelier sur la méthode copier-coller

Si vous avez déjà terminé le script de suivi rapide de cet atelier, n'exécutez pas la méthode copier-coller ci-dessous**.**

Il existe plusieurs façons de faire évoluer une plate-forme. Vous pouvez augmenter la capacité de calcul en ajoutant des nœuds à des clusters existants. Vous pouvez ajouter d'autres clusters à une région. Vous pouvez également ajouter d'autres régions à la plate-forme. La décision d'adapter l'aspect de la plate-forme dépend des exigences. Par exemple, si vous avez des clusters dans les trois zones d'une région, il peut suffire d'ajouter d'autres nœuds (ou pools de nœuds) au cluster existant. Toutefois, si vous avez des clusters dans deux des trois zones d'une même région, l'ajout d'un nouveau cluster dans la troisième zone vous permet d'effectuer un scaling et un domaine de défaillance supplémentaire (c'est-à-dire une nouvelle zone). L'ajout d'un cluster dans une région peut également s'expliquer par le besoin de créer un cluster à locataire unique pour des raisons réglementaires ou de conformité (par exemple, pour la norme PCI ou un cluster de base de données qui héberge des informations permettant d'identifier personnellement l'utilisateur). À mesure que votre entreprise et vos services se développent, il devient inévitable d'ajouter de nouvelles régions pour fournir des services au plus près des clients.

La plate-forme actuelle se compose de deux régions et de clusters répartis dans deux zones par région. Vous pouvez envisager le scaling de la plate-forme de deux manières:

• Verticalement : dans chaque région en ajoutant des ressources de calcul. Pour ce faire, vous pouvez ajouter des nœuds (ou pools de nœuds) aux clusters existants ou ajouter de nouveaux clusters dans la région. Pour ce faire, utilisez le dépôt infrastructure. Le plus simple consiste à ajouter des nœuds à des clusters existants. Aucune configuration supplémentaire n'est requise. L'ajout de nouveaux clusters peut nécessiter des sous-réseaux supplémentaires (et des plages secondaires), l'ajout de règles de pare-feu appropriées, l'ajout des nouveaux clusters au plan de contrôle régional du maillage de services ASM/Istio et le déploiement des ressources d'application sur les nouveaux clusters.
• Horizontalement : en ajoutant d'autres régions La plate-forme actuelle fournit un modèle régional. Il se compose d'un cluster d'opérations régional dans lequel réside le contrôle ASM/Istio, et d'au moins deux clusters d'application zonaux sur lesquels les ressources d'application sont déployées.

Dans cet atelier, vous redimensionnerez la plate-forme "horizontalement" car elle englobe aussi les étapes du cas d'utilisation vertical. Pour effectuer un scaling horizontal de la plate-forme en y ajoutant une région (r3), vous devez ajouter les ressources suivantes:

1. Sous-réseaux du VPC partagé du projet hôte dans la région r3 pour les nouveaux clusters d'opérations et d'applications.
2. Un cluster d'opérations régional dans la région r3 où réside le plan de contrôle ASM/Istio.
3. Deux clusters d'application zonaux dans deux zones de la région r3.
4. Mettez à jour le dépôt k8s-repo:
5. Déployez des ressources de plan de contrôle ASM/Istio sur le cluster d'opérations dans la région r3.
6. Déployez des ressources de plan de contrôle partagé ASM/Istio sur les clusters d'applications de la région r3.
7. Bien qu'il ne soit pas nécessaire de créer un nouveau projet, les étapes de l'atelier montrent comment ajouter un nouveau projet dev3 pour couvrir le cas d'utilisation de l'ajout d'une nouvelle équipe à la plateforme.

Infrastructure Repo permet d'ajouter les nouvelles ressources indiquées ci-dessus.

1. Dans Cloud Shell, accédez à WORKDIR et clonez le dépôt 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. Clonez la branche add-proj du dépôt source de l'atelier dans le répertoire add-proj-repo.

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

 

3. Copiez les fichiers de la branche add-proj dans le dépôt source de l'atelier. La branche add-proj contient les modifications apportées à cette section.

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

4. Remplacez le répertoire infrastructure dans le répertoire du dépôt add-proj par un lien symbolique vers le répertoire infra-repo pour permettre l'exécution des scripts de la branche.

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

5. Exécutez le script add-project.sh pour copier les états et les variables partagés dans la nouvelle structure de répertoires du projet.

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

6. Validez et déployez les modifications pour créer un projet

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

7. Le commit déclenche le dépôt infrastructure pour déployer l'infrastructure avec les nouvelles ressources. Suivez la progression de Cloud Build en cliquant sur le résultat du lien suivant et en accédant à la dernière compilation en haut.

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

Cette étape prend entre 25 et 30 minutes. C'est le moment idéal pour prendre un café.

La dernière étape de infrastructure Cloud Build crée des ressources Kubernetes dans le k8s-repo. Cette opération déclenche Cloud Build dans le projet k8s-repo (dans le projet opérationnel). Les nouvelles ressources Kubernetes concernent les trois nouveaux clusters ajoutés à l'étape précédente. Les ressources de plan de contrôle ASM/Istio et de plan de contrôle partagé sont ajoutées aux nouveaux clusters avec la compilation Cloud Build k8s-repo.

8. Une fois l'infrastructure Cloud Build terminée, accédez à la dernière exécution Cloud Build k8s-repo en cliquant sur le lien de sortie suivant.

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

9. Exécutez le script suivant pour ajouter les nouveaux clusters aux variables et au fichier kubeconfig.

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

10. Modifiez la variable KUBECONFIG pour qu'elle pointe vers le nouveau fichier kubeconfig.

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

11. Listez les contextes de votre cluster. Vous devriez voir huit clusters.

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

Vérifier l'installation d'Istio

12. Assurez-vous qu'Istio est installé sur le nouveau cluster d'opérations en vérifiant que tous les pods sont en cours d'exécution et que les tâches sont terminées.

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. Assurez-vous qu'Istio est installé sur les deux clusters dev3. Seuls citadelle, side-injector et Coredns s'exécutent dans les clusters dev3. Ils partagent un plan de contrôle Istio s'exécutant dans le cluster ops-3.

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

    `Output (do not copy)`

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

Vérifier la détection de services pour les plans de contrôle partagés

14. Vérifiez que les secrets sont déployés dans tous les clusters d'opérations pour les six clusters d'application.

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. Ruptures de circuit

Objectif: implémenter un disjoncteur pour le service de livraison.

• Créez un DestinationRule pour le service shipping afin d'implémenter un disjoncteur.
• Utilisez fortio (un utilitaire de génération de charge) pour valider le disjoncteur du service shipping en forçant le déclenchement du circuit.

Instructions pour l'atelier concernant le script Fast Track

L'atelier de création de script Fast Track sera bientôt disponible !

Instructions de l'atelier sur la méthode copier-coller

Maintenant que nous avons appris quelques stratégies de base de surveillance et de dépannage pour les services compatibles avec Istio, voyons comment ce service vous aide à améliorer la résilience de vos services, en réduisant le nombre de tâches de dépannage à effectuer.

Une architecture de microservices présente un risque de défaillances en cascade : la défaillance d'un service peut se propager à ses dépendances, et les dépendances de ces dépendances, ce qui entraîne un "effet d'ondulation". susceptibles d'affecter les utilisateurs finaux. Istio propose une règle de trafic de disjoncteur pour vous aider à isoler les services, en empêchant les services en aval (côté client) d'attendre des services défaillants, et en protégeant les services en amont (côté serveur) d'un flot soudain de trafic en aval lorsqu'ils se reconnectent. Dans l'ensemble, l'utilisation de disjoncteurs peut vous aider à éviter que tous vos services ne réussissent leurs SLO en raison d'un service de backend en attente.

Le modèle du disjoncteur est nommé d'après un interrupteur électrique qui peut "déclencher" lorsqu'il y a trop d'électricité, protégeant ainsi les appareils de la surcharge. Dans une configuration Istio, cela signifie que Envoy est le disjoncteur et assure le suivi du nombre de requêtes en attente pour un service. Dans cet état fermé par défaut, les requêtes transitent par Envoy sans interruption.

Toutefois, lorsque le nombre de requêtes en attente dépasse le seuil défini, le disjoncteur se déclenche (s'ouvre) et Envoy renvoie immédiatement une erreur. Cela permet au serveur d'échouer rapidement pour le client et cela empêche le code de l'application serveur de recevoir la requête du client en cas de surcharge.

Ensuite, après le délai que vous avez défini, Envoy passe à l'état semi-ouvert, où le serveur peut recommencer à recevoir des requêtes de manière probationnaire. S'il parvient à y répondre, le disjoncteur se ferme à nouveau et les requêtes adressées au serveur recommencent à circuler.

Ce diagramme résume le modèle de disjoncteur Istio. Les rectangles bleus représentent Envoy, les cercles bleus le client et les cercles blancs représentent le conteneur serveur:

Vous pouvez définir des stratégies de disjoncteur à l'aide d'Istio DestinationRules. Dans cette section, nous allons appliquer la règle suivante pour mettre en place un disjoncteur pour le service de livraison:

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

Deux champs DestinationRule sont à noter ici. connectionPool définit le nombre de connexions que ce service autorisera. Le champ "outlierDetection" permet de configurer la manière dont Envoy va déterminer le seuil à partir duquel le disjoncteur doit être ouvert. Ici, Envoy compte chaque seconde (intervalle) le nombre d'erreurs reçues du conteneur serveur. S'il dépasse le seuil de consecutiveErrors, le disjoncteur Envoy s'ouvre et 100% des pods productcatalog sont protégés contre les nouvelles requêtes client pendant 10 secondes. Lorsque le disjoncteur Envoy est ouvert (actif), les clients reçoivent une erreur 503 (Service non disponible). Passons à la démonstration !

1. Définissez des variables d'environnement pour le dépôt k8s-repo et le répertoire asm afin de simplifier les commandes.

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

2. Mettre à jour le dépôt k8s-repo

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

3. Mettez à jour la règle DestinationRule du service de livraison sur les deux clusters Ops.

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. Copiez un pod de générateur de charge Fortio dans le cluster GKE_1 de la région Dev1. Il s'agit du pod client que nous utiliserons pour « trip » le disjoncteur du service de livraison.

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. Validez les modifications.

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

6. Attendez la fin de l'exécution de Cloud Build.
7. De retour dans Cloud Shell, utilisez le pod Fortio pour envoyer le trafic gRPC au service de livraison avec une connexion simultanée et 1 000 requêtes au total. Le disjoncteur ne se déclenchera pas, car nous n'avons pas encore dépassé les paramètres connectionPool.

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

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

Résultat (ne pas copier)

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

8. Exécutez à nouveau Fortio, en portant le nombre de connexions simultanées à 2, sans changer le nombre total de requêtes. Nous devrions voir jusqu'à deux tiers des requêtes renvoyer un "overflow" s'affiche, car le disjoncteur a été déclenché:dans la règle que nous avons définie, une seule connexion simultanée est autorisée sur un intervalle d'une seconde.

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 
 

Résultat (ne pas copier)

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 effectue le suivi du nombre de connexions abandonnées lorsque le disjoncteur est actif, à l'aide de la métrique upstream_rq_pending_overflow. Retrouvons-la dans le module Fortio:

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

Résultat (ne pas copier)

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. Effectuez un nettoyage en supprimant la règle concernant le disjoncteur des deux régions.

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
 

Cette section explique comment configurer une règle pour un disjoncteur unique pour un service. Une bonne pratique consiste à configurer un disjoncteur pour tout service (backend) en amont susceptible de se bloquer. En appliquant les règles de disjoncteur d'Istio, vous contribuez à isoler vos microservices, à intégrer la tolérance aux pannes dans votre architecture et à réduire le risque de défaillances en cascade en cas de charge élevée.

14. Injection de pannes

Objectif: tester la résilience du service de recommandation en introduisant des retards (avant qu'il ne passe en production).

• Créer un VirtualService pour le service recommendation afin d'introduire un délai de 5 s
• Tester le délai à l'aide du générateur de charge fortio
• Supprimez le retard dans VirtualService et validez.

Instructions pour l'atelier concernant le script Fast Track

L'atelier de création de script Fast Track sera bientôt disponible !

Instructions de l'atelier sur la méthode copier-coller

L'ajout de règles de disjoncteur à vos services est un moyen de renforcer la résilience vis-à-vis des services en production. Toutefois, une rupture de circuit entraîne des défaillances (susceptibles d'être confrontées à l'utilisateur), ce qui n'est pas idéal. Pour anticiper ces cas d'erreur et mieux prédire la façon dont vos services en aval peuvent répondre lorsque les backends renvoient des erreurs, vous pouvez adopter les tests du chaos dans un environnement de préproduction. Le test du chaos consiste à interrompre délibérément vos services afin d'analyser les points faibles du système et d'améliorer la tolérance aux pannes. Vous pouvez également utiliser les tests du chaos pour identifier des moyens de limiter les erreurs rencontrées par les utilisateurs en cas d'échec des backends, par exemple en affichant un résultat mis en cache dans une interface.

L'utilisation d'Istio pour l'injection de pannes est utile, car vous pouvez utiliser vos images de version de production et ajouter la défaillance au niveau de la couche réseau au lieu de modifier le code source. En production, vous pouvez utiliser un outil de test du chaos complet pour tester la résilience au niveau de la couche Kubernetes/de calcul en plus de la couche réseau.

Vous pouvez utiliser Istio pour effectuer des tests de chaos en appliquant un VirtualService avec la valeur "fault" . Istio accepte deux types de pannes: les erreurs de retard (injecter un délai avant expiration) et les erreurs d'abandon (injecter des erreurs HTTP). Dans cet exemple, nous allons injecter une erreur de délai de cinq secondes dans le service Recommendations. Mais cette fois, au lieu d'utiliser un disjoncteur pour faire des "failles rapides" par rapport à ce service inutilisé, nous allons forcer les services en aval à subir le délai d'expiration complet.

11. Accédez au répertoire d'injection de pannes.

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

12. Ouvrez k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml pour inspecter son contenu. Vous remarquerez qu'Istio dispose d'une option qui permet d'injecter l'erreur dans un certain pourcentage des requêtes. Ici, nous allons ajouter un délai avant expiration à toutes les requêtes RecommendationService.

Résultat (ne pas copier)

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. Copiez le service virtuel dans k8s_repo. Nous injecterons la faille dans le monde entier, dans les deux régions.

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. Déployer les modifications

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

15. Attendez la fin de l'exécution de Cloud Build.
16. Exécuter dans le pod Fortio déployé dans la section du disjoncteur, puis envoyer du trafic vers le service de recommandation

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:

Résultat (ne pas copier)

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. Une autre façon de voir l'erreur que nous avons injectée en action est d'ouvrir l'interface dans un navigateur Web et de cliquer sur n'importe quel produit. Le chargement d'une page de produit devrait prendre cinq secondes supplémentaires, car elle récupère les recommandations affichées en bas de la page.
18. Effectuez un nettoyage en supprimant le service d'injection de pannes des deux clusters Ops.

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. Déployer les modifications:

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

15. Surveiller le plan de contrôle Istio

ASM installe quatre composants importants du plan de contrôle: Pilot, Mixer, Galley et citadelle. Chacun d'eux envoie les métriques de surveillance pertinentes à Prometheus, et ASM est fourni avec des tableaux de bord Grafana, qui permettent aux opérateurs de visualiser ces données de surveillance, et d'évaluer l'état et les performances du plan de contrôle.

Affichage des tableaux de bord

20. Transférer le port du service Grafana installé avec Istio

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

21. Ouvrez Grafana dans votre navigateur
22. Cliquez sur "Aperçu sur le Web" dans l'angle supérieur droit de votre fenêtre Cloud Shell
23. Cliquez sur "Prévisualiser sur le port 3000". (Remarque: si le port n'est pas 3000, cliquez sur "Changer de port", puis sélectionnez le port 3000.)
24. Cela ouvrira dans votre navigateur un onglet dont l'URL ressemble à " BASE_URL/?orgId=1&authuser=0&environment_id=default"
25. Afficher les tableaux de bord disponibles
26. Remplacez l'URL par " BASE_URL/dashboard"
27. Cliquez sur "istio". dossier pour afficher les tableaux de bord disponibles
28. Cliquez sur l'un de ces tableaux de bord pour afficher les performances de ce composant. Les sections suivantes présentent les principales métriques associées à chaque composant.

Pilote de surveillance

Pilot est le composant du plan de contrôle qui distribue la configuration de la mise en réseau et des règles au plan de données (les proxys Envoy). Pilot a tendance à évoluer avec le nombre de charges de travail et de déploiements, mais pas nécessairement avec le volume de trafic vers ces charges de travail. Un pilote non opérationnel peut:

• consomment plus de ressources que nécessaire (processeur et/ou RAM)
• entraîne des retards lors de la transmission des informations de configuration mises à jour à Envoy.

Remarque: Si Pilot est en panne ou en cas de retard, vos charges de travail diffusent toujours du trafic.

23. Accédez à " BASE_URL/dashboard/db/istio-pilot-dashboard" dans votre navigateur pour afficher les métriques du pilote.

Métriques surveillées importantes

Utilisation des ressources

Consultez la page Performances et évolutivité d'Istio comme guide pour connaître les chiffres d'utilisation acceptables. Contactez l'assistance GCP si vous constatez une utilisation beaucoup plus soutenue des ressources.

Informations push du pilote

Cette section surveille les transferts de configuration pilotes vers vos proxys Envoy.

• La section Déploiements pilotes indique le type de configuration appliquée à un moment donné.
• Surveillance des annonces indique le nombre de services virtuels, de services et de points de terminaison connectés dans le système.
• La page Clusters sans point de terminaison connu indique les points de terminaison qui ont été configurés, mais qui n'ont pas d'instance en cours d'exécution (ce qui peut indiquer des services externes, tels que *.googleapis.com).
• La section Erreurs pilotes indique le nombre d'erreurs rencontrées au fil du temps.
• La section Conflits indique le nombre de conflits présentant une configuration ambiguë sur les écouteurs.

Si vous avez des erreurs ou des conflits, cela signifie que la configuration d'un ou plusieurs de vos services est incorrecte ou incohérente. Pour en savoir plus, consultez "Dépannage du plan de données".

Informations sur Envoy

Cette section contient des informations sur les proxys Envoy qui contactent le plan de contrôle. Contactez l'assistance GCP si vous constatez que la connexion à XDS échoue à plusieurs reprises.

Mixeur de surveillance

Mixer est le composant qui achemine la télémétrie des proxys Envoy vers les backends de télémétrie (généralement Prometheus, Stackdriver, etc.). À ce titre, il ne se trouve pas dans le plan de données. Il est déployé sous la forme de deux jobs Kubernetes (appelés Mixer) avec deux noms de service différents (istio-telemetry et istio-policy).

Mixer peut également être intégré à des systèmes de règles. À ce titre, Mixer affecte le plan de données, car les vérifications des règles appliquées à cet outil échouent et bloquent l'accès à vos services.

Mixer a tendance à s'adapter au volume du trafic.

24. Accédez à " BASE_URL/dashboard/db/istio-mixer-dashboard" dans votre navigateur pour afficher les métriques Mixer.

Métriques surveillées importantes

Utilisation des ressources

Consultez la page Performances et évolutivité d'Istio comme guide pour connaître les chiffres d'utilisation acceptables. Contactez l'assistance GCP si vous constatez une utilisation beaucoup plus soutenue des ressources.

Présentation du robot

• La durée de la réponse est une métrique importante. Les rapports envoyés à la télémétrie de Mixer ne se trouvent pas dans le chemin de données. Toutefois, si ces latences sont élevées, cela ralentira certainement les performances du proxy side-car. Vous devez vous attendre à ce que le 90e centile se situe en millisecondes, et que le 99e centile soit en dessous de 100 ms.

• La valeur Durée de diffusion de l'adaptateur indique la latence que Mixer rencontre lors de l'appel des adaptateurs (par le biais duquel il envoie des informations aux systèmes de télémétrie et de journalisation). Les latences élevées présentes ici affecteront absolument les performances sur le réseau maillé. Là encore, les latences p90 doivent être inférieures à 10 ms.

Galerie de surveillance

Galley est le composant de validation, d'ingestion, de traitement et de distribution de la configuration d'Istio. Il transmet la configuration du serveur d'API Kubernetes à Pilot. Comme pour Pilot, il a tendance à évoluer avec le nombre de services et de points de terminaison du système.

25. Accédez à " BASE_URL/dashboard/db/istio-galley-dashboard" dans votre navigateur pour afficher les métriques Galley.

Métriques surveillées importantes

Validation des ressources

La métrique la plus importante à suivre, qui indique le nombre de ressources de divers types, comme les règles de destination, les passerelles et les entrées de service, qui réussissent ou échouent la validation.

Clients connectés

Indique le nombre de clients connectés à Galley. Il s'agit généralement de 3 (pilote, istio-telemetry, istio-policy), qui évolueront au fur et à mesure de l'évolution de ces composants.

16. Résoudre les problèmes liés à Istio

Résoudre les problèmes liés au plan de données

Si le tableau de bord Pilot indique que vous rencontrez des problèmes de configuration, vous devez examiner les journaux PIlot ou utiliser istioctl pour détecter les problèmes de configuration.

Pour examiner les journaux Pilot, exécutez la commande kubectl -n istio-system logs istio-pilot-69db46c598-45m44 en remplaçant istio-pilot-... par l'identifiant de pod de l'instance Pilot que vous souhaitez dépanner.

Dans le journal obtenu, recherchez le message État de l'envoi. Exemple :

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

L'état de transfert indique les problèmes survenus lors du transfert de la configuration vers les proxys Envoy. Dans ce cas, nous voyons plusieurs problèmes "Cluster en double". indiquant des destinations en double en amont.

Pour obtenir de l'aide, contactez l'assistance Google Cloud en cas de problème.

Rechercher les erreurs de configuration

Si vous souhaitez analyser votre configuration avec istioctl, exécutez istioctl experimental analyze -k --context $OPS_GKE_1. Une analyse de la configuration de votre système est alors effectuée, et les éventuels problèmes sont signalés, et des modifications sont suggérées. Consultez la documentation pour obtenir la liste complète des erreurs de configuration que cette commande peut détecter.

17. Nettoyage

Les étapes suivantes sont réalisées par un administrateur une fois l'atelier terminé.

Un administrateur exécute le script cleanup_workshop.sh pour supprimer les ressources créées par le script bootstrap_workshop.sh. Vous avez besoin des informations suivantes pour exécuter le script de nettoyage.

• Nom de l'organisation (par exemple, yourcompany.com)
• ID de l'atelier : au format YYMMDD-NN, par exemple 200131-01
• Bucket GCS administrateur : défini dans le script d'amorçage.

13. Ouvrez Cloud Shell et effectuez toutes les actions ci-dessous dans Cloud Shell. Cliquez sur le lien ci-dessous.

CLOUD SHELL

14. Vérifiez que vous êtes connecté à gcloud avec l'utilisateur administrateur souhaité.

gcloud config list
 

15. Accédez au dossier asm.

cd ${WORKDIR}/asm
 

16. Définissez le nom de l'organisation et l'ID d'atelier à supprimer.

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

17. Exécutez le script de nettoyage comme suit.

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