Atelier Anthos Service Mesh: guide de l'atelier

1. ATELIER ALPHA

IMPORTANT : CET ATELIER EST EN VERSION ALPHA ET EST STRICTEMENT DESTINÉ À ÊTRE UNE FORMATION EN CLASSE ANIMÉE PAR UN FORMATEUR.

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 des services distribués à l'échelle mondiale sur GCP en production. 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, l'observabilité et le façonnage avancé 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 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écouverte des services multiclusters et sécurité/règles
• Atelier : TLS mutuel
• Déploiements Canary
• Atelier : Déploiements Canary
• Équilibrage de charge global multicluster sécurisé
• Pause
• Atelier : Règles d'autorisation
• QNA
• Module 3 : Opérations d'infrastructure : mises à niveau de la plate-forme
• Composants de base des services distribués
• Atelier : Mise à l'échelle de l'infrastructure
• Étapes suivantes

Slides

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

Diapositives de l'atelier ASM

Prérequis

Voici les conditions requises avant de commencer cet atelier :

1. Un nœud Organisation GCP
2. Un ID de compte de facturation (votre utilisateur doit être administrateur de la facturation pour ce compte de facturation)
3. Le rôle IAM d'administrateur de l'organisation au niveau de l'organisation pour votre utilisateur

3. Configuration de l'infrastructure : workflow de l'administrateur

Les étapes de cette section sont effectuées par un administrateur qui crée l'atelier.

Si vous êtes un utilisateur qui suit l'atelier, passez à la section suivante intitulée Infrastructure Setup - User Workflow.

Explication du script de l'atelier Bootstrap

Un script nommé bootstrap_workshop.sh est utilisé pour configurer l'environnement initial de l'atelier. Vous pouvez utiliser ce script pour configurer un seul environnement pour vous-même ou plusieurs environnements pour plusieurs utilisateurs si vous organisez cet atelier en tant que 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 des environnements pour l'atelier.
• ID de facturation (par exemple, 12345-12345-12345) : cet ID de facturation est utilisé pour facturer toutes les ressources utilisées pendant l'atelier.
• Numéro d'atelier (par exemple, 01) : nombre à deux chiffres. Cette option est utile si vous organisez plusieurs ateliers au cours d'une même journée et que vous souhaitez les suivre séparément. Les numéros d'atelier sont également utilisés pour dériver les ID de projet. En utilisant des numéros d'atelier distincts, vous pouvez plus facilement obtenir des ID de projet uniques à chaque fois. En plus du numéro de l'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 du premier utilisateur (par exemple, 1) : ce nombre indique le premier utilisateur de l'atelier. Par exemple, si vous souhaitez créer un atelier pour 10 utilisateurs, vous pouvez définir le numéro de l'utilisateur de début sur 1 et celui de l'utilisateur de fin sur 10.
• Numéro de l'utilisateur final (par exemple, 10) : ce numéro indique le dernier utilisateur de l'atelier. Par exemple, si vous souhaitez créer un atelier pour 10 utilisateurs, vous pouvez définir le numéro de l'utilisateur de début sur 1 et celui de l'utilisateur de fin sur 10. Si vous configurez un seul environnement (pour vous-même, par exemple), définissez le même nombre d'utilisateurs pour le début et la fin. Cela créera un seul environnement.

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

• Bucket GCS de l'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 d'atelier d'amorçage. Les administrateurs qui créent des ateliers doivent disposer d'autorisations en lecture/écriture pour ce bucket.

Le script de l'atelier d'amorçage utilise les valeurs fournies ci-dessus et sert de 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 amorcer l'atelier

Cet atelier comporte deux types d'utilisateurs. Un ADMIN_USER qui crée et supprime des 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 un enseignant et que vous créez cet atelier pour plusieurs élèves, vos ADMIN_USER et 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 dispose d'un seul dossier contenant toutes ses ressources dans le projet.
• Administrateur de l'organisation
• Créateur de projet : permet de créer des projets dans l'organisation.
• Suppresseur de projets : permet de supprimer des projets dans l'organisation.
• Administrateur IAM de projet : permet de créer des règles IAM dans tous les projets de l'organisation.

En plus de ces éléments, ADMIN_USER doit également être l'administrateur de la facturation pour l'ID de facturation utilisé pour l'atelier.

Schéma utilisateur et autorisations pour 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 de dénomination spécifique pour MY_USERs. Dans le script bootstrap_workshop.sh, vous fournissez un numéro d'utilisateur de début et de fin. Ces chiffres 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 le numéro d'utilisateur de début 1 et le numéro d'utilisateur de fin 3, dans votre organisation appelée votreentreprise.com, les environnements d'atelier pour les utilisateurs suivants sont créés :

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

Ces noms d'utilisateur sont associés au rôle de propriétaire de projet pour les projets spécifiques créés lors de l'exécution du script setup_terraform_admin_project.sh. Vous devez respecter ce schéma de dénomination des utilisateurs lorsque vous utilisez le script bootstrap. Consultez Ajouter plusieurs utilisateurs à la fois dans G Suite.

Outils requis pour l'atelier

Cet atelier est conçu pour être amorcé à partir de Cloud Shell. Les outils suivants sont nécessaires pour cet atelier.

• gcloud (version >= 270)
• kubectl
• sed (fonctionne avec sed sur Cloud Shell/Linux, mais pas sur 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 PATH et confirmez-le en exécutant la commande kustomize dans Cloud Shell.

Configurer l'atelier pour vous-même (configuration pour un seul utilisateur)

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 le compte administrateur souhaité.

gcloud config list
 

3. Créez un 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, l'ID de facturation, le numéro de l'atelier et un bucket GCS administrateur à utiliser pour l'atelier. Consultez 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 d'utilisateur de début et de fin, car vous configurez cette fonctionnalité pour 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'administration Terraform est créé dans le dossier. Le projet d'administrateur Terraform permet de créer le reste des ressources GCP requises pour cet atelier. Vous activez les API requises dans le projet administrateur Terraform. Vous utilisez Cloud Build pour appliquer les plans Terraform. 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, vous configurez 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 du projet d'administration Terraform. Ces informations sont stockées 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. Définir les variables d'environnement en sourçant le fichier de variables

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

Configurer l'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 le compte administrateur souhaité.

gcloud config list
 

9. Créez un 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, votre ID de facturation, le numéro de l'atelier, le nombre d'utilisateurs de début et de fin, ainsi qu'un bucket GCS administrateur à utiliser pour l'atelier. Consultez 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 workshop.txt depuis le bucket GCS de l'administrateur 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. Configuration et préparation de l'atelier

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

Choisir votre parcours d'atelier

Vous pouvez effectuer les ateliers de ce workshop de deux manières :

• La méthode des scripts interactifs simples et rapides
• La méthode copier-coller manuellement chaque instruction

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

Les scripts de procédure accélérée s'affichent en haut de chaque atelier dans une zone verte, comme illustré ci-dessous.

SCRIPT DE LA PROCÉDURE ACCÉLÉRÉE

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

La méthode du copier-coller est la méthode traditionnelle qui consiste à copier-coller des blocs de commandes individuels avec des explications sur les commandes. Cette méthode n'est censée être exécutée qu'une seule fois. Rien ne garantit que l'exécution de commandes dans cette méthode vous donnera les mêmes résultats.

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

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

Configuration rapide du script

Une fois le script de démarrage rapide terminé, vous avez terminé cet atelier. Ne suivez pas les instructions de l'atelier "Copier et coller".

Obtenir des informations sur l'utilisateur

Cet atelier est réalisé à l'aide d'un compte utilisateur temporaire (ou d'un compte de laboratoire) 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 laboratoire (nom d'utilisateur et mot de passe) à l'utilisateur qui participe à l'atelier. Tous les projets de l'utilisateur sont précédés du nom d'utilisateur du compte de l'atelier. Par exemple, pour le compte de l'atelier [e-mail], l'ID du projet d'administrateur Terraform serait user001-200131-01-tf-abcde, et ainsi de suite pour les autres projets. Chaque utilisateur doit se connecter avec le compte de laboratoire fourni par l'administrateur de l'atelier et suivre l'atelier à l'aide de ce compte.

Consultez votre adresse e-mail professionnelle (celle que vous avez utilisée pour vous inscrire à l'atelier). Vous devriez avoir reçu un e-mail de l'administrateur de l'atelier contenant les identifiants de votre compte de laboratoire (nom d'utilisateur et mot de passe). L'e-mail se présente comme suit.

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

CLOUD SHELL

2. Connectez-vous avec les identifiants du compte de l'atelier (ne vous connectez pas avec votre compte professionnel ni 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 Linux Debian que vous pouvez utiliser pour accéder aux ressources GCP. Chaque compte dispose d'une VM Cloud Shell. La connexion avec le compte de l'atelier provisionne le compte et vous connecte à l'aide de ses identifiants. En plus de Cloud Shell, un éditeur de code est également provisionné, ce qui facilite la modification des fichiers de configuration (terraform, YAML, etc.). Par défaut, l'écran Cloud Shell est divisé en deux : l'environnement shell Cloud Shell (en bas) et l'éditeur Cloud Code (en haut).  Les icônes en forme de crayon  et d'invite de commande  en haut à droite vous permettent de basculer entre les deux (shell et éditeur de code). Vous pouvez également faire glisser la barre de séparation centrale (vers le haut ou vers le bas) pour modifier manuellement la taille de chaque fenêtre. 5. Créez un WORKDIR pour cet atelier. 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 même compte que celui 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 à l'aide des indicateurs "-sufa" ou "–setup-for-admin", 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. Affichez les variables WORKDIR et MY_USER pour vous assurer qu'elles sont 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'installation de l'infrastructure et d'Istio

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

SCRIPT DE LA PROCÉDURE ACCÉLÉRÉE

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 le script terminé, sourcez votre bashrc pour mettre à jour les variables dans votre session Cloud Shell.

source ${HOME}/.bashrc

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

IMPORTANT : Si vous avez déjà exécuté le script de démarrage rapide pour cet atelier, n'effectuez pas la méthode de 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 à 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 du projet d'administration 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 conçu pour être amorcé à partir de Cloud Shell. Les outils suivants sont nécessaires 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 les instructions pour installer les deux.

• gcloud (version >= 270)
• kubectl
• sed (fonctionne avec sed sur Cloud Shell/Linux, mais pas sur 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'administration Terraform est créé dans le dossier. Le projet d'administrateur Terraform permet de créer le reste des ressources GCP requises pour cet atelier. Le script setup-terraform-admin-project.sh active les API requises dans le projet administrateur Terraform. Cloud Build est utilisé pour appliquer les plans Terraform. Grâce au 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 du projet d'administration Terraform. Il est stocké dans le bucket GCS de l'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 conçu pour être réalisé dans Cloud Shell et la console Cloud. Effectuez les étapes suivantes dans une fenêtre INCOGNITO, car vous allez vous connecter avec un nom d'utilisateur et un mot de passe distincts.

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

CLOUD SHELL

2. Installez kustomize (si ce n'est pas déjà fait) 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 de commande 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 concerné.

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 sous forme de variables dans un fichier vars.sh stocké dans un bucket GCS du projet d'administration Terraform. Obtenez le fichier vars.sh pour votre projet Terraform d'administrateur.

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 d'administration Terraform et vérifiez 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 à la console Cloud 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 panneau de navigation de gauche, puis sur la dernière compilation pour afficher les détails de la première application Terraform. Les ressources suivantes sont créées dans le script Terraform. Vous pouvez également consulter le schéma d'architecture ci-dessus.

• 4 projets GCP dans l'organisation Le compte de facturation fourni est associé à chaque projet.
• Un projet est le network host project du VPC partagé. Aucune autre ressource n'est créée dans ce projet.
• Un projet est le ops project utilisé pour les clusters GKE du plan de contrôle Istio.
• Deux projets représentent deux équipes de développement différentes travaillant 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 est utilisé pour déployer des fichiers manifestes Kubernetes sur les clusters de manière GitOps.
• Un déclencheur Cloud Build est créé pour que chaque commit dans la branche principale de k8s-repo déploie les manifestes Kubernetes sur les clusters GKE à partir de leurs dossiers respectifs.

Le script Terraform prend entre 40 et 50 minutes.

10. Une fois la compilation terminée dans terraform admin project, une autre compilation démarre dans le projet d'opérations. Cliquez sur le lien affiché pour ouvrir la page Cloud Build de ops project et vérifiez que la compilation k8s-repo Cloud Build s'est terminée correctement.

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

Remarque : Vous devez terminer cette compilation avant de pouvoir valider 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 nommé kubemesh dans le dossier gke.

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 à .bashrc dans Cloud Shell afin qu'elles soient sourcées à 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. Affichez la liste des 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 jobs sont terminés.

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 Citadel, sidecar-injector et coredns s'exécutent dans les clusters dev1. Ils partagent un plan de contrôle Istio exécuté 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 Citadel, sidecar-injector et coredns s'exécutent dans les clusters dev2. Ils partagent un plan de contrôle Istio exécuté 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écouverte de services pour les plans de contrôle partagés

18. Vous pouvez éventuellement 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 seront créés. Pour découvrir les services entre les clusters, vous utilisez les fichiers kubeconfig (pour chacun des clusters d'application) créés en tant que secrets dans les clusters d'opérations. Pilot utilise ces secrets pour découvrir les services en interrogeant le serveur d'API Kube des clusters d'applications (authentifiés via les secrets ci-dessus). Vous pouvez constater que les deux clusters d'opérations peuvent s'authentifier auprès de tous les clusters d'applications à l'aide des secrets créés par kubeconfig. Les clusters d'opérations peuvent découvrir automatiquement les services à l'aide des fichiers kubeconfig comme méthode secrète. Pour cela, le composant Pilot des clusters d'opérations doit avoir accès au serveur de l'API Kube de tous les autres clusters. Si Pilot ne peut pas accéder aux serveurs d'API Kube, vous devez ajouter manuellement des services distants en tant que ServiceEntries. Vous pouvez considérer les ServiceEntries comme des entrées DNS dans votre registre de services. Les ServiceEntries définissent un service à l'aide d'un nom DNS complet ( FQDN) et d'une adresse IP à laquelle il est accessible. Pour en savoir plus, consultez la documentation Istio Multicluster.

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

Infrastructure Cloud Build

Les ressources GCP de l'atelier sont 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é à l'adresse scripts/bootstrap_workshop.sh) depuis votre terminal local. Le script d'amorçage crée un dossier GCP, un projet d'administrateur Terraform et les autorisations IAM appropriées pour le compte de service Cloud Build. Le projet administrateur Terraform est utilisé pour stocker les états, les journaux et les scripts divers de Terraform. Il contient les dépôts RSE infrastructure et k8s_repo. Ces dépôts sont expliqués en détail dans la section suivante. Aucune autre ressource d'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 des ressources pour l'atelier.

Un fichier cloudbuild.yaml situé dans le dossier infrastructure est utilisé pour créer des ressources GCP pour l'atelier. Il crée une image de compilation personnalisée avec tous les outils nécessaires pour créer des ressources GCP. Ces outils incluent le SDK gcloud, Terraform et d'autres utilitaires tels que Python, git, jq, etc. L'image de compilateur personnalisée exécute terraform plan et apply pour chaque ressource. Les fichiers Terraform de chaque ressource se trouvent dans des dossiers distincts (plus de détails dans la section suivante). Les ressources sont créées une par une et dans l'ordre dans lequel elles le seraient normalement (par exemple, un projet GCP est créé avant les ressources 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 sous forme d'Infrastructure as Code (IaC) et est 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 d'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 le environment spécifique à l'équipe (par exemple, "dev", "stage" ou "prod"). La couche suivante de dossiers dans l'environnement représente le resource spécifique (par exemple, host_project, gke_clusters, etc.). Les scripts et 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. Ils sont chargés de créer les ressources GCP pour toutes les autres équipes. Ils utilisent le projet administrateur Terraform pour leurs ressources. Le dépôt d'infrastructure lui-même se trouve dans le projet d'administration Terraform, tout comme les fichiers d'état Terraform (expliqués ci-dessous). Ces ressources sont créées par un script Bash lors du processus d'amorçage (pour en savoir plus, consultez le module 0 : Workflow de l'administrateur).
2. network : représente l'équipe réseau. Ils sont responsables des ressources VPC et réseau. Ils sont propriétaires des ressources GCP suivantes.
3. host project : représente le projet hôte de 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. Ils sont propriétaires des ressources suivantes.
6. ops project : représente un projet pour toutes les ressources d'opérations.
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 d'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 d'application. Cet atelier simule deux équipes, app1 et app2. Ils sont propriétaires des ressources suivantes.
10. app projects : chaque équipe d'application dispose de son propre ensemble de projets. Il pourra ainsi contrôler la facturation et IAM pour son projet spécifique.
11. gke clusters : il s'agit de clusters d'applications dans lesquels les conteneurs/pods d'application s'exécutent.
12. gce instances : facultatif, si l'utilisateur dispose d'applications qui s'exécutent sur des instances GCE. Dans cet atelier, app1 comporte plusieurs instances GCE sur lesquelles une partie de l'application s'exécute.

Dans cet atelier, la même application (Hipster Shop) représente 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 symlinked dans chaque dossier de ressources. Vous pouvez ainsi modifier le fournisseur à un seul endroit au lieu de gérer individuellement les fournisseurs 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é à l'adresse templates/backend.tf_tmpl) à l'aide d'un script (situé à l'adresse 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 résident dans le projet administrateur Terraform.

Les ressources dont les valeurs sont 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 spécifique. 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 du cluster GKE.

Le fichier shared_state est une source de données terraform_remote_state qui pointe vers le fichier tfstate d'une ressource. Un ou plusieurs fichiers shared_state_[resource_name].tf existent dans les dossiers de ressources qui nécessitent des sorties d'autres ressources. Par exemple, dans le dossier de ressources ops_gke, il existe des fichiers shared_state provenant des ressources ops_project et shared_vpc, car vous avez besoin de l'ID de projet et des détails du VPC pour créer des clusters GKE dans le projet d'opérations. Les fichiers shared_state sont générés à partir d'un modèle (situé à l'adresse templates/shared_state.tf_tmpl) à l'aide d'un script (situé à l'adresse scripts/setup_terraform_admin_project). Tous les fichiers shared_state des ressources sont placés dans le dossier gcp/[environment]/shared_states. Les fichiers shared_state requis sont liés symboliquement dans les dossiers de ressources respectifs. Placer tous les fichiers shared_state dans un même dossier et créer des liens symboliques vers les dossiers de ressources appropriés permet de gérer facilement 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 (sous forme d'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 obtenir le fichier vars.sh à partir de n'importe quel terminal pour obtenir les valeurs de votre configuration.

Les variables Terraform sont stockées dans vars.sh sous la forme 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 avec leurs valeurs. Le fichier variables.tfvars est généré à partir d'un fichier de modèle situé dans le même dossier à l'aide d'un script (situé à l'adresse 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 est utilisé pour stocker et appliquer des fichiers manifestes GKE à tous les clusters GKE. k8s_repo est créé par l'infrastructure Cloud Build (pour en savoir plus, consultez la section précédente). Lors du processus Cloud Build de l'infrastructure initiale, six clusters GKE sont créés au total. Six dossiers sont créés dans k8s_repo. Chaque dossier (dont le nom correspond à celui du cluster GKE) correspond à un cluster GKE contenant ses fichiers manifestes de ressources respectifs. Comme pour la création d'infrastructure, Cloud Build est utilisé pour appliquer les fichiers manifestes Kubernetes à tous les clusters GKE à l'aide de 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 manifestes Kubernetes sont stockés sous forme de code dans le dépôt k8s_repo. L'état de chaque cluster GKE est toujours stocké dans son dossier respectif.

Lors de la création de l'infrastructure initiale, 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 dans différents projets GCP. Les projets doivent correspondre à la structure organisationnelle (ou d'équipe) de votre entreprise. Les équipes (de votre organisation) responsables de différents projets/produits/ressources utilisent différents projets GCP. Avoir des projets distincts vous permet de créer des ensembles distincts d'autorisations IAM et de gérer la facturation au niveau du projet. De plus, les quotas sont également gérés au niveau du projet.

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

1. L'équipe d'infrastructure qui crée des ressources GCP utilise Terraform admin project. Ils gèrent l'infrastructure en tant que code dans un dépôt CSR (appelé infrastructure) et stockent toutes les informations sur l'état Terraform concernant les ressources créées dans GCP dans des 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 host project. Ce projet contient le VPC, les sous-réseaux, les routes et les règles de pare-feu. 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 même VPC partagé 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 ops project. Ils gèrent le cycle de vie des clusters GKE et du maillage de services. Ils sont responsables du renforcement des clusters, ainsi que de la gestion de la résilience et de l'évolutivité de la plate-forme Kubernetes. Dans cet atelier, vous allez utiliser la méthode GitOps pour déployer des ressources sur Kubernetes. Un dépôt CSR (appelé k8s_repo) existe dans le projet d'opérations.
4. Enfin, les équipes dev1 et dev2 (qui 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. Elles sont basées 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 k8s_repo et déployées sur les clusters appropriés. Il est important de noter que cet atelier ne se concentre pas sur les bonnes pratiques et les outils de CI/CD. Vous utilisez Cloud Build pour automatiser le déploiement des ressources Kubernetes directement sur les clusters GKE. Dans des scénarios de production réels, vous utiliserez une solution CI/CD appropriée pour déployer des applications sur des clusters GKE.

Cet atelier comporte deux types de clusters GKE.

1. Clusters d'opérations : utilisés par l'équipe des opérations pour 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 : utilisés par les équipes de développement pour exécuter des applications. Dans cet atelier, l'application Hipster Shop est utilisée.

En séparant les outils d'administration/d'opérations des clusters exécutant l'application, vous pouvez gérer le cycle de vie de chaque ressource de manière indépendante. Les deux types de clusters existent également dans différents projets liés à l'équipe ou au produit qui les utilise, ce qui facilite également la gestion des autorisations IAM.

Il y a au total six clusters GKE. Deux clusters d'opérations régionaux sont créés dans le projet d'opérations. 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. De plus, il existe quatre clusters d'applications zonaux. Elles sont créées dans leurs propres projets. Cet atelier simule deux équipes de développement, chacune avec ses propres projets. Chaque projet contient deux clusters d'applications. Les clusters d'applications sont des clusters zonaux situés dans différentes zones. Les quatre clusters d'applications sont situés dans deux régions et quatre zones. Vous bénéficiez ainsi d'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 réside dans son propre espace de noms dans chaque cluster d'applications. Les déploiements (pods) de l'application Hipster Shop ne sont pas déployés sur les clusters d'opérations. Toutefois, les espaces de noms et les ressources de service pour tous les microservices sont également créés dans les clusters d'opérations. Le plan de contrôle ASM/Istio utilise les registres de services Kubernetes pour la découverte des services. En l'absence de services (dans les clusters d'opérations), vous devrez créer manuellement des ServiceEntries pour chaque service exécuté dans le cluster d'applications.

Dans cet atelier, vous allez déployer une application de microservices à 10 niveaux. Cette application Web d'e-commerce appelée Hipster Shop permet aux utilisateurs de parcourir des articles, de les ajouter à un panier et de les acheter.

Manifestes Kubernetes et k8s_repo

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

Voici les six noms de clusters :

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'application dans la zone a de la région 1
4. gke-2-apps-r1b-prod : cluster d'application dans la zone b de la région 1
5. gke-3-apps-r2a-prod : cluster d'application dans la zone a de la région 2
6. gke-4-apps-r2b-prod : cluster d'application dans la zone b de la région 2

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

7. Déployer l'application exemple

Objectif : déployer l'application Hipster Shop sur les 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 d'opérations
• Configurer loadgenerators dans les clusters d'opérations pour tester la connectivité globale
• Vérifier la connectivité sécurisée à l'application Hipster Shop

SCRIPT DE LA PROCÉDURE ACCÉLÉRÉE

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 du copier-coller

Si vous avez déjà exécuté le script de démarrage rapide pour cet atelier, n'effectuez pas la méthode de copier-coller ci-dessous.

Cloner le dépôt source du projet d'opérations

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

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

mkdir $WORKDIR/k8s-repo
 

2. Initialisez le dépôt Git, ajoutez un dépôt distant et extrayez la branche principale 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éfinissez la configuration Git locale.

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 les 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 fichier kustomization.yaml du dossier de l'application sur 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, RBAC et PodSecurityPolicy Hipster Shop 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. Supprimez le déploiement cartservice, rbac et podsecuritypolicy de tous les clusters de développement, sauf un. Hipstershop n'a pas été conçu pour le déploiement multicluster. Pour éviter les résultats incohérents, nous n'utilisons qu'un seul cartservice.

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

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

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

8. Ajoutez le déploiement cartservice, rbac et podsecuritypolicy à kustomization.yaml dans le premier cluster de développement uniquement.

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. Supprimez les répertoires podsecuritypolicies, deployments et rbac de ops clusters kustomization.yaml.

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

10. 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 d'opérations.

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 dans 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 manifestes 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. En plaçant loadgenerator sur les deux clusters d'opérations, vous vous assurez 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 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 à 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. S'abonner à 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 de Cloud Build du projet Ops dans un onglet précédemment 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 d'application, à l'exception du panier, sont à l'état "Running" (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 du panier sont à l'état "Running" (En cours d'exécution) uniquement dans le premier cluster de développement.

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 désormais déployée sur les quatre clusters d'applications. Ces clusters se trouvent dans deux régions et quatre zones. Les clients peuvent accéder à l'application Hipster Shop en accédant au service frontend. Le service frontend s'exécute sur les quatre clusters d'applications. Un équilibreur de charge Google Cloud ( GCLB) est utilisé pour 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 pour les deux clusters d'applications zonaux de la région. GCLB utilise les deux passerelles d'entrée Istio (exécutées dans les deux clusters d'opérations) en tant que backends pour le service de frontend global. Les passerelles d'entrée Istio reçoivent le trafic client du GCLB, puis l'envoient aux pods de frontend s'exécutant dans les clusters d'application.

Vous pouvez également placer des passerelles d'entrée Istio directement sur les clusters d'application, que l'équilibreur de charge Google Cloud peut 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'équilibreur de charge Google Cloud à l'aide de groupes de points de terminaison du réseau (NEG). Les NEG permettent d'équilibrer la charge native des conteneurs à l'aide des équilibreurs de charge Google Cloud. Les NEG sont créés à l'aide d'une annotation spéciale sur un service Kubernetes, ce qui leur permet de s'enregistrer auprès du contrôleur NEG. Le contrôleur Autoneg est un contrôleur GKE spécial qui automatise la création de NEG et leur attribution en tant que backends à un équilibreur de charge réseau Google Cloud à 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 création initiale de l'infrastructure Terraform Cloud Build. La configuration GCLB et autoneg est effectuée dans le cadre de la première infrastructure Terraform Cloud Build.

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

Les certificats gérés par GCP sont utilisés pour sécuriser le trafic client vers le service GCLB frontend. GCLB utilise des certificats gérés pour le service frontend mondial, et le certificat est résilié au niveau de GCLB. Dans cet atelier, vous utilisez 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 à la boutique Hipster, cliquez sur le lien généré par la commande suivante.

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

22. Pour vérifier que le certificat est valide, cliquez sur le symbole en forme de cadenas dans la barre d'adresse de votre 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. Ils génèrent du trafic de test vers le lien Cloud Endpoints de la boutique Hipster Shop GCLB. Vérifiez que l'équilibreur de charge Google Cloud reçoit du trafic et l'envoie aux deux passerelles d'entrée Istio.

23. Obtenez le lien Équilibrage de charge Cloud > Monitoring pour le projet d'opérations dans lequel l'équilibreur de charge Cloud 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", passez de Tous les backends à istio-ingressgateway, comme indiqué ci-dessous.

25. Notez le trafic acheminé vers les deux istio-ingressgateways.

Trois NEG sont créés par istio-ingressgateway. Étant donné que les clusters d'opérations sont des clusters régionaux, un NEG est créé pour chaque zone de la région. Toutefois, les pods istio-ingressgateway s'exécutent dans une seule zone par région. Le trafic est dirigé vers les pods istio-ingressgateway.

Les générateurs de charge s'exécutent dans les deux clusters d'opérations, simulant le trafic client 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 la valider.

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

SCRIPT DE LA PROCÉDURE ACCÉLÉRÉE

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 du copier-coller

Si vous avez déjà exécuté le script de démarrage rapide pour cet atelier, n'effectuez pas la méthode de copier-coller ci-dessous.

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

Nous utiliserons également le système de génération de charge intégré à 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 à voir comment elle fonctionne. Cette charge est déjà en cours d'exécution. Nous allons simplement pouvoir la voir.

1. Installez le fichier de configuration istio-to-stackdriver.

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

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

2. Validez les modifications dans k8s-repo.

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

3. Affichez l'état de Cloud Build du projet Ops dans un onglet précédemment 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 le CRD du gestionnaire Stackdriver.

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 lien généré par 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. Cliquez simplement sur "OK". Si une boîte de dialogue s'affiche pour vous présenter la nouvelle interface utilisateur, fermez-la.

Dans l'explorateur de métriques, sous "Rechercher un type de ressource et une métrique", saisissez "istio" pour afficher des options telles que "Nombre de requêtes du serveur" pour le type de ressource "Conteneur Kubernetes". Cela nous montre que les métriques sont transmises du maillage à Stackdriver.

(Vous devrez regrouper par libellé destination_service_name si vous souhaitez voir les lignes ci-dessous.)

Visualiser les métriques avec les tableaux de bord :

Maintenant que nos métriques sont dans le système Stackdriver APM, nous voulons les visualiser. Dans cette section, nous allons installer un tableau de bord prédéfini qui nous montre trois des quatre signaux clés de métriques : Trafic (requêtes par seconde), Latence (dans ce cas, les 99e et 50e centiles) et Erreurs (nous excluons Saturation dans cet exemple).

Le proxy Envoy d'Istio nous fournit plusieurs métriques, mais celles-ci constituent un bon point de départ. (la liste exhaustive est disponible ici). Notez que chaque métrique comporte un ensemble de libellés pouvant être utilisés 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 n'effectuez normalement pas en générant manuellement des appels d'API. Elle fait partie d'un système d'automatisation ou vous créez le tableau de bord manuellement dans l'interface utilisateur Web. Voici comment démarrer 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 tableau de bord des services qui vient d'être ajouté.

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'UX, mais dans notre cas, nous allons rapidement ajouter un graphique à l'aide de l'API. Pour ce faire, vous devez extraire la dernière version du tableau de bord, appliquer vos modifications, puis la renvoyer à 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 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 graphique (latence du 50e centile) : [Documentation de l'API] Nous pouvons maintenant ajouter un widget de graphique à notre tableau de bord dans le code. Cette modification peut être examinée par des pairs et enregistrée dans le contrôle des versions. Voici un widget à ajouter qui affiche la latence à 50e centile (latence médiane).

Essayez de modifier le tableau de bord que vous venez d'obtenir en ajoutant une nouvelle strophe :

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 existants :

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 simple des journaux.

Istio fournit un ensemble de journaux structurés pour l'ensemble du trafic réseau dans le maillage et les importe dans Stackdriver Logging pour permettre une analyse inter-clusters dans un outil puissant. 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.

Voici un exemple d'entrée de journal (dans ce cas, accesslog du proxy Envoy) :

*** 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, puis en recherchant "pilot" :

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

En plus des journaux d'Istio, vous pouvez également trouver les journaux de conteneur, ainsi que les journaux d'infrastructure ou d'autres services GCP, le tout dans la même interface. Voici quelques exemples de requêtes de journaux pour GKE. Le lecteur 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 une alerte. Les journaux peuvent également être diffusés vers d'autres outils d'analyse tels que BigQuery.

Voici quelques exemples de filtres pour la boutique hipster :

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

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

13. Consultez la section "Traces distribuées".

Maintenant que vous travaillez avec 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 (par exemple, en trouvant des événements lents aberrants dans l'image ci-dessous), ainsi que d'examiner les traces d'échantillons bruts pour étudier en détail ce qui se passe réellement.

La vue chronologique affiche toutes les requêtes au fil du temps, représentées sous forme de graphique en fonction de leur latence (temps écoulé entre la requête initiale, via la pile Hipster, et la réponse finale à l'utilisateur final). Plus les points sont élevés, plus l'expérience utilisateur est lente (et moins agréable !).

Vous pouvez cliquer sur un point pour afficher la vue en cascade détaillée de cette requête spécifique. Cette capacité à trouver les détails bruts d'une requête spécifique (et pas seulement des statistiques agrégées) est essentielle pour comprendre l'interaction entre les services, en particulier lorsqu'il s'agit de dénicher des interactions rares, mais mauvaises, entre les services.

La vue en cascade devrait être familière à tous ceux qui ont utilisé un débogueur. Toutefois, au lieu d'afficher le temps passé dans différents processus d'une même application, elle indique le temps passé à parcourir notre maillage, entre les services, qui s'exécutent dans des conteneurs distincts.

Voici où trouver vos traces :

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

Exemple de capture d'écran de l'outil :

9. Authentification TLS mutuelle

Objectif : sécuriser la connectivité entre les microservices (authentification).

• Activer l'authentification mTLS à l'échelle du maillage
• Vérifier mTLS en inspectant les journaux

SCRIPT DE LA PROCÉDURE ACCÉLÉRÉE

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 du copier-coller

Si vous avez déjà exécuté le script de démarrage rapide pour cet atelier, n'effectuez pas la méthode de 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'elles continuent de fonctionner.

Par exemple, nous pouvons voir sur le tableau de bord Kiali que nos services n'utilisent pas le protocole mTLS (aucune icône en forme de cadenas). mais le trafic est fluide et le système fonctionne correctement. Notre tableau de bord Stackdriver sur les métriques d'or nous rassure sur le bon fonctionnement global.

1. Vérifiez MeshPolicy dans les clusters d'opérations. Notez que l'authentification mTLS est PERMISSIVE, ce qui permet 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 (CR). Nous allons configurer mTLS dans tous les clusters en mettant à jour le CR IstioControlPlane et le k8s-repo. Si vous définissez "global > mTLS > enabled: true" dans le CR IstioControlPlane, les deux modifications suivantes sont apportées au plan de contrôle Istio :

• MeshPolicy est défini pour activer l'authentification mTLS à l'échelle du maillage 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 ressource personnalisée istioControlPlane pour activer le protocole 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. Validez les modifications dans k8s-repo.

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

4. Affichez l'état de Cloud Build du projet Ops dans un onglet précédemment 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 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 DestinationRule créée par le contrôleur de l'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 voir le passage de HTTP à HTTPS dans les journaux.

Nous pouvons exposer ce champ particulier des journaux dans l'UI en cliquant 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 "protocol:".

Cela permet de visualiser facilement le changement :

10. Déploiements Canary

Objectif : Déployer une nouvelle version du service d'interface.

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

SCRIPT DE LA PROCÉDURE ACCÉLÉRÉE

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 du copier-coller

Si vous avez déjà exécuté le script de démarrage rapide pour cet atelier, n'effectuez pas la méthode de 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 continuant à envoyer le pourcentage restant vers la version actuelle. Un schéma courant consiste à effectuer une analyse Canary à chaque étape de la répartition du trafic et à comparer les "signaux clés" de la nouvelle version (latence, taux d'erreur, saturation) à une référence. Cela permet d'éviter les pannes et d'assurer la stabilité du nouveau service "v2" à chaque étape de la répartition du trafic.

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

Nous allons d'abord exécuter le pipeline Canary dans la région DEV1 (us-west1) et 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 2 sur les deux clusters de cette région. L'exécution du pipeline dans les régions, dans l'ordre, plutôt qu'en parallèle dans toutes les régions, permet d'éviter les pannes mondiales 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 du reste des 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
• Patch frontend-v1 (pour inclure le libellé "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 Istio de l'interface : divise le service Kubernetes de l'interface en deux sous-ensembles, v1 et v2, en fonction du libellé de déploiement "version".
• VirtualService Istio de frontend : achemine 100 % du trafic vers frontend v1. Cela remplace le comportement par défaut du service Kubernetes (round robin), qui enverrait immédiatement 50 % de tout le trafic régional Dev1 vers l'interface utilisateur v2.

3. Validez les modifications apportées à k8s_repo :

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

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

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

5. Accédez à Cloud Build dans la console du projet OPS1. Attendez que le pipeline Cloud Build soit terminé, puis récupérez les pods dans l'espace de noms frontend des 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 watch.

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

• Le volet inférieur exécutera la commande watch pour observer la distribution des réponses HTTP pour le service de frontend.
• Le volet supérieur exécutera le script de pipeline canary proprement dit.

6. Exécutez la commande pour fractionner la fenêtre Cloud Shell et exécutez 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 pouvons voir que tout le trafic est dirigé vers le déploiement frontend v1, défini dans le nouveau VirtualService.

7. Exécutez le pipeline Canary dans la région Dev1. Nous fournissons un script qui met à jour les pourcentages de trafic frontend-v2 dans le VirtualService (en mettant à jour les pondérations à 20 %, 50 %, 80 %, puis 100 %). Entre les mises à jour, le script attend la fin du pipeline Cloud Build. 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, à 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. De plus, tout le trafic de l'interface utilisateur provenant d'un pod Dev2 doit être acheminé 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 fractionné.

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

11. Accédez à Cloud Source Repositories en cliquant sur le lien généré.

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

Un commit distinct doit s'afficher pour chaque pourcentage de trafic, le commit le plus récent étant en haut de la liste :

Répétez maintenant la même procédure pour la région Dev2. Notez que la région Dev2 est toujours "verrouillée" dans la version 1. En effet, dans le script baseline repo_setup, nous avons envoyé un VirtualService pour envoyer explicitement tout le trafic vers la version 1. Nous avons ainsi pu effectuer un canary régional sur Dev1 en toute sécurité et nous assurer qu'il fonctionnait correctement avant de déployer la nouvelle version à l'échelle mondiale.

12. Exécutez la commande pour fractionner la fenêtre Cloud Shell et exécutez 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 pouvons voir que tout le trafic est dirigé vers le déploiement frontend v1, défini dans le nouveau VirtualService.

13. Exécutez le pipeline Canary dans la région Dev2. Nous fournissons un script qui met à jour les pourcentages de trafic frontend-v2 dans le VirtualService (en mettant à jour les pondérations à 20 %, 50 %, 80 %, puis 100 %). Entre les mises à jour, le script attend la fin du pipeline Cloud Build. 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. Depuis le pod Respy dans Dev2, observez le trafic des pods Dev2 passer progressivement du frontend v1 au frontend v2. Une fois le script terminé, 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 fractionné.

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

Cette section a présenté l'utilisation d'Istio pour les déploiements Canary régionaux. En production, au lieu d'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 envoyée à un registre de conteneurs. Vous devez é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 plus de trafic.

11. Règles d'autorisation

Objectif : configurer le RBAC entre les microservices (autorisation).

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

SCRIPT DE LA PROCÉDURE ACCÉLÉRÉE

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 du copier-coller

Si vous avez déjà exécuté le script de démarrage rapide pour cet atelier, n'effectuez pas la méthode de copier-coller ci-dessous.

Contrairement à une application monolithique pouvant être exécutée au même endroit, les applications de microservices distribuées à l'échelle mondiale effectuent des appels au-delà des limites du réseau. Cela signifie qu'elles présentent un plus grand nombre de points d'entrée dans vos applications et davantage de possibilités pour les attaques malveillantes. De plus, étant donné que les pods Kubernetes ont des adresses IP temporaires, les règles de pare-feu basées sur l'adresse IP traditionnelles ne permettent plus de 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. S'appuyant sur les blocs de construction 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 règles Istio couvrent à la fois l'authentification et l'autorisation. L'authentification vérifie l'identité (ce serveur est-il bien celui qu'il prétend être ?), tandis que l'autorisation vérifie les autorisations (ce client est-il autorisé à effectuer cette action ?). Nous avons abordé l'authentification Istio dans la section sur le protocole TLS mutuel du module 1 (MeshPolicy). Dans cette section, nous allons apprendre à utiliser les règles d'autorisation Istio pour contrôler l'accès à l'une de nos charges de travail d'application, currencyservice.

Nous allons d'abord déployer une AuthorizationPolicy sur les quatre clusters de développement, en bloquant tout accès à currencyservice et en déclenchant une erreur dans le frontend. Nous autoriserons ensuite uniquement le service d'interface à accéder à currencyservice.

1. Inspectez le contenu de currency-deny-all.yaml. Cette règle utilise des sélecteurs de libellés de déploiement pour restreindre l'accès au service de devises. 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 le règlement sur les devises dans k8s-repo pour les clusters d'opérations dans les 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. Appliquez les modifications.

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

4. Vérifiez l'état de Cloud Build du projet Ops dans un onglet précédemment 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 utilisateur de hipstershop dans un navigateur en cliquant sur le lien suivant :

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

Une erreur d'autorisation doit s'afficher pour le service de devises :

6. Voyons comment le service de devises applique cette AuthorizationPolicy. Tout d'abord, activez les journaux au niveau de la trace sur le proxy Envoy pour l'un des pods de devise, car les appels d'autorisation bloqués ne sont pas enregistré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 (autorisation) à partir du proxy side-car du service de devises. Un message "Refus appliqué" doit s'afficher, indiquant que le service de devises est configuré pour bloquer toutes les requêtes 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. À présent, autorisons le frontend (mais pas les autres services de backend) à accéder à currencyservice. 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 un source.principal (client) spécifique à la liste blanche pour accéder au service de devises. Ce source.principal est défini par le compte de service Kubernetes. Dans ce cas, le compte de service que nous ajoutons à la liste d'autorisation est le compte de service frontend dans l'espace de noms frontend.

Remarque : Lorsque vous utilisez des comptes de service Kubernetes dans les AuthorizationPolicies Istio, vous devez d'abord activer le TLS mutuel à l'échelle du cluster, comme nous l'avons fait dans le module 1. Cela permet de s'assurer que les identifiants du compte de service sont inclus dans les requêtes.

9. Copier la règle mise à jour sur les devises

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

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

11. Affichez l'état de Cloud Build du projet Ops dans un onglet précédemment 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, rouvrez le frontend Hipstershop. Cette fois, aucune erreur ne devrait s'afficher sur la page d'accueil, car le frontend est explicitement autorisé à accéder au service actuel.
13. Maintenant, essayez de passer une commande en ajoutant des articles à votre panier et en cliquant sur "Passer la commande". Cette fois, vous devriez voir une erreur de conversion de prix provenant du service de devises. En effet, nous n'avons autorisé que le frontend, de sorte que le checkoutservice ne peut toujours pas accéder à currencyservice.

14. Enfin, autorisons le service de paiement à accéder à la devise en ajoutant une autre règle à notre AuthorizationPolicy currencyservice. Notez que nous n'ouvrons l'accès aux devises qu'aux deux services qui en ont besoin : l'interface et le paiement. Les autres backends resteront bloqués.
15. Ouvrez currency-allow-frontend-checkout.yaml et examinez son contenu. Notez que la liste des règles fonctionne comme un OR logique : la devise n'acceptera que les requêtes provenant de charges de travail avec 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. Appliquer les modifications

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

18. Affichez l'état de Cloud Build du projet Ops dans un onglet précédemment 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 paiement. Il devrait fonctionner.

Cette section vous a montré comment utiliser les règles d'autorisation Istio pour appliquer un contrôle d'accès précis au niveau de chaque service. En production, vous pouvez créer une AuthorizationPolicy par service et, par exemple, utiliser une règle "tout autoriser" pour permettre à toutes les charges de travail du 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 d'opérations et un pour le nouveau projet)
• Nouveau cluster d'opérations dans une 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 de la nouvelle région
• Valider dans le dépôt infrastructure
• Vérifier l'installation

SCRIPT DE LA PROCÉDURE ACCÉLÉRÉE

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 du copier-coller

Si vous avez déjà exécuté le script de démarrage rapide pour cet atelier, n'effectuez pas la méthode de copier-coller ci-dessous.

Il existe plusieurs façons de faire évoluer une plate-forme. Vous pouvez ajouter de la puissance de calcul en ajoutant des nœuds aux clusters existants. Vous pouvez ajouter des clusters dans une région. Vous pouvez également ajouter d'autres régions à la plate-forme. La décision concernant l'aspect de la plate-forme à faire évoluer dépend des exigences. Par exemple, si vous avez des clusters dans les trois zones d'une région, il peut suffire d'ajouter des nœuds (ou des pools de nœuds) aux clusters existants. Toutefois, si vous avez des clusters dans deux des trois zones d'une même région, l'ajout d'un cluster dans la troisième zone vous permet de bénéficier d'un scaling et d'un domaine de défaillance supplémentaire (c'est-à-dire une nouvelle zone). Une autre raison d'ajouter un cluster dans une région peut être la nécessité de créer un cluster à locataire unique pour des raisons réglementaires ou de conformité (par exemple, PCI ou un cluster de base de données contenant 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 plus proches des clients.

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

• Verticalement : en ajoutant plus de puissance de calcul dans chaque région. Pour ce faire, vous pouvez ajouter des nœuds (ou des pools de nœuds) aux clusters existants ou ajouter des clusters dans la région. Pour ce faire, utilisez le dépôt infrastructure. Le moyen le plus simple consiste à ajouter des nœuds à des clusters existants. Aucune configuration supplémentaire n'est requise. L'ajout de clusters peut nécessiter des sous-réseaux (et des plages secondaires) supplémentaires, 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 dans les nouveaux clusters.
• Horizontalement : en ajoutant des régions. La plate-forme actuelle vous fournit un modèle régional. Il se compose d'un cluster d'opérations régional où réside le plan de contrôle ASM/Istio et de deux clusters d'application zonaux (ou plus) où les ressources d'application sont déployées.

Dans cet atelier, vous allez faire évoluer la plate-forme de manière "horizontale", car elle englobe également les étapes du cas d'utilisation vertical. Pour mettre à l'échelle la plate-forme horizontalement en ajoutant une nouvelle région (r3), les ressources suivantes doivent être ajoutées :

1. Sous-réseaux dans le VPC partagé du projet hôte dans la région r3 pour les nouveaux clusters d'opérations et d'applications.
2. 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 k8s-repo :
5. Déployez les ressources du plan de contrôle ASM/Istio sur le cluster d'opérations dans la région r3.
6. Déployez les ressources de plan de contrôle partagé ASM/Istio sur les clusters d'application de la région r3.
7. Bien que vous n'ayez pas besoin de créer un projet, les étapes de l'atelier montrent comment ajouter un projet dev3 pour couvrir le cas d'utilisation de l'ajout d'une nouvelle équipe à la plate-forme.

Le dépôt d'infrastructure permet d'ajouter les ressources mentionné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 de l'atelier source. 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 sur 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 variables partagés dans la nouvelle structure de répertoire du projet.

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

6. Valider et envoyer 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éploiement de l'infrastructure avec les nouvelles ressources dans le dépôt infrastructure. Pour afficher la progression de Cloud Build, cliquez sur le résultat du lien suivant et accédez à la dernière compilation en haut de la page.

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 faire une pause-café.

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

8. Une fois l'exécution Cloud Build de l'infrastructure 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 fichiers vars et 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. Affichez la liste des 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 jobs sont terminés.

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 Citadel, sidecar-injector et coredns s'exécutent dans les clusters dev3. Ils partagent un plan de contrôle Istio exécuté 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écouverte 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'applications.

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 coupe-circuit du service shipping en déclenchant le circuit de force.

Instructions de l'atelier Fast Track Script

Fast Track Script Lab sera bientôt disponible !

Instructions de l'atelier sur la méthode du 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 Istio vous aide à améliorer la résilience de vos services, ce qui réduit la quantité de dépannage que vous aurez à effectuer en premier lieu.

Une architecture de microservices introduit le risque de défaillances en cascade, où la défaillance d'un service peut se propager à ses dépendances, et aux dépendances de ces dépendances, provoquant une panne en cascade qui peut potentiellement affecter les utilisateurs finaux. Istio fournit une règle de trafic de disjoncteur pour vous aider à isoler les services, à protéger les services en aval (côté client) contre l'attente des services défaillants et à protéger les services en amont (côté serveur) contre un afflux soudain de trafic en aval lorsqu'ils reviennent en ligne. En résumé, l'utilisation de disjoncteurs peut vous aider à éviter que tous vos services ne respectent pas leurs SLO à cause d'un service de backend bloqué.

Le modèle de disjoncteur tire son nom d'un interrupteur électrique qui peut "sauter" lorsqu'un trop grand courant électrique le traverse, protégeant ainsi les appareils contre les surcharges. Dans une configuration Istio, cela signifie qu'Envoy est le disjoncteur qui suit le 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 que vous avez 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 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 d'attente que vous avez défini, Envoy passe à un état semi-ouvert, dans lequel le serveur peut recommencer à recevoir des requêtes de manière probatoire. S'il peut y répondre correctement, le disjoncteur se referme et les requêtes recommencent à être envoyées au serveur.

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

Vous pouvez définir des règles de disjoncteur à l'aide d'Istio DestinationRules. Dans cette section, nous allons appliquer la règle suivante pour appliquer un disjoncteur au 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 façon dont Envoy déterminera le seuil à partir duquel le coupe-circuit doit être ouvert. Ici, à chaque seconde (intervalle), Envoy comptabilise le nombre d'erreurs reçues du conteneur de serveur. S'il dépasse le seuil consecutiveErrors, le disjoncteur Envoy s'ouvre et 100 % des pods productcatalog sont protégés contre les nouvelles requêtes client pendant 10 secondes. Une fois le coupe-circuit Envoy ouvert (c'est-à-dire actif), les clients reçoivent des erreurs 503 (Service Unavailable). Prenons un exemple concret.

1. Définissez des variables d'environnement pour les répertoires k8s-repo et asm afin de simplifier les commandes.

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

2. Mettre à jour k8s-repo

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

3. Mettez à jour la 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 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 déclencher le disjoncteur pour shippingservice.

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

5. Validez les modifications.

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

6. Attendez la fin de Cloud Build.
7. De retour dans Cloud Shell, utilisez le pod fortio pour envoyer du trafic gRPC à shippingservice avec une connexion simultanée et 1 000 requêtes au total. Cela ne déclenchera pas le disjoncteur, 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 augmentant le nombre de connexions simultanées à 2, mais en conservant le nombre total de requêtes constant. Nous devrions voir jusqu'aux deux tiers des requêtes renvoyer une erreur "overflow" (dépassement), car le disjoncteur a été déclenché : dans le règlement que nous avons défini, une seule connexion simultanée est autorisée dans 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 suit le nombre de connexions qu'il a abandonnées lorsque le disjoncteur est actif, avec la métrique upstream_rq_pending_overflow. Recherchons-le dans le pod 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 du coupe-circuit 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 a montré comment configurer une seule règle de disjoncteur pour un service. Une bonne pratique consiste à configurer un disjoncteur pour tout service en amont (backend) susceptible de se bloquer. En appliquant des règles de disjoncteur 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 délais (avant qu'il ne soit déployé en production).

• Créez un VirtualService pour le service recommendation afin d'introduire un délai de cinq secondes.
• Tester le délai à l'aide du générateur de charge fortio
• Supprimer le délai dans VirtualService et valider

Instructions de l'atelier Fast Track Script

Fast Track Script Lab sera bientôt disponible !

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

L'ajout de règles de disjoncteur à vos services est un moyen de renforcer la résilience des services en production. Cependant, l'interruption de circuit entraîne des défaillances (potentiellement des erreurs visibles par 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 le chaos testing dans un environnement de staging. Le chaos testing consiste à casser 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 d'atténuer les erreurs visibles par les utilisateurs lorsque les backends échouent, par exemple en affichant un résultat mis en cache dans un frontend.

L'utilisation d'Istio pour l'injection de pannes est utile, car vous pouvez utiliser vos images de version de production et ajouter la panne au niveau du 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 Kubernetes/Compute en plus du niveau réseau.

Vous pouvez utiliser Istio pour les tests du chaos en appliquant un VirtualService avec le champ "fault" (défaillance). Istio accepte deux types de défaillances : les défaillances de délai (qui injectent un délai avant expiration) et les défaillances d'abandon (qui injectent des erreurs HTTP). Dans cet exemple, nous allons injecter un défaut de retard de 5 secondes dans le service de recommandations. Mais cette fois, au lieu d'utiliser un disjoncteur pour "échouer rapidement" face à ce service suspendu, nous allons forcer les services en aval à supporter le délai d'attente complet.

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

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. Notez qu'Istio permet d'injecter la défaillance dans un pourcentage des requêtes. Ici, nous allons introduire un délai avant expiration dans 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 VirtualService dans k8s_repo. Nous allons injecter la défaillance à l'échelle mondiale, 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. Appliquer les modifications

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

15. Attendez la fin de Cloud Build.
16. Exécutez le pod fortio déployé dans la section sur le coupe-circuit et envoyez du trafic à recommendationservice.

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

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

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

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. Pour voir le défaut que nous avons injecté en action, vous pouvez également ouvrir l'interface utilisateur dans un navigateur Web et cliquer sur n'importe quel produit. Une page produit devrait prendre cinq secondes de plus à charger, 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 défaillance 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. Appliquer 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 Citadel. Chacun envoie ses métriques de surveillance pertinentes à Prometheus. 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.

Afficher les tableaux de bord

20. Rediriger le port de votre service Grafana installé avec Istio

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

21. Ouvrir Grafana dans votre navigateur
22. Cliquez sur l'icône "Aperçu sur le Web" en haut à droite de la fenêtre Cloud Shell.
23. Cliquez sur "Preview on port 3000" (Prévisualiser sur le port 3000). Remarque : Si le port n'est pas le port 3000, cliquez sur "Change port" (Modifier le port) et sélectionnez le port 3000.
24. Un onglet s'ouvre dans votre navigateur avec une URL semblable à 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 le dossier "istio" pour afficher les tableaux de bord disponibles.
28. Cliquez sur l'un de ces tableaux de bord pour afficher les performances du composant. Nous examinerons les métriques importantes pour chaque composant dans les sections suivantes.

Pilote de surveillance

Pilot est le composant du plan de contrôle qui distribue la configuration réseau et des règles au plan de données (proxys Envoy). Pilot a tendance à évoluer en fonction du nombre de charges de travail et de déploiements, mais pas nécessairement en fonction du 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îner des retards dans la transmission des informations de configuration mises à jour aux Envoys.

Remarque : Si Pilot est hors service ou s'il y a des retards, vos charges de travail continuent de diffuser du trafic.

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

Métriques importantes à surveiller

Utilisation des ressources

Consultez la page Performances et évolutivité d'Istio pour connaître les chiffres d'utilisation acceptables. Contactez l'assistance GCP si vous constatez une utilisation soutenue des ressources nettement supérieure à celle-ci.

Informations sur les notifications push du pilote

Cette section surveille les envois de configuration de Pilot à vos proxys Envoy.

• Pushes pilotes indique le type de configuration envoyé à un moment donné.
• ADS Monitoring indique le nombre de services virtuels, de services et de points de terminaison connectés dans le système.
• Clusters sans points de terminaison connus : affiche les points de terminaison qui ont été configurés, mais pour lesquels aucune instance n'est en cours d'exécution (ce qui peut indiquer des services externes, tels que *.googleapis.com).
• Erreurs de pilote : nombre d'erreurs rencontrées au fil du temps.
• La section Conflits indique le nombre de conflits, qui correspondent à des configurations ambiguës sur les écouteurs.

Si des erreurs ou des conflits s'affichent, cela signifie que la configuration d'un ou de 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 des échecs de connexion XDS à plusieurs reprises.

Monitoring Mixer

Mixer est le composant qui canalise 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 n'est 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 utilisé pour s'intégrer aux systèmes de règles. À ce titre, Mixer affecte le plan de données, car les vérifications de règles qui échouent bloquent l'accès à vos services.

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

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

Métriques importantes à surveiller

Utilisation des ressources

Consultez la page Performances et évolutivité d'Istio pour connaître les chiffres d'utilisation acceptables. Contactez l'assistance GCP si vous constatez une utilisation soutenue des ressources nettement supérieure à celle-ci.

Présentation du mixeur

• La durée de la réponse est une métrique importante. Bien que les rapports sur la télémétrie Mixer ne soient pas dans le chemin de données, si ces latences sont élevées, les performances du proxy side-car seront certainement ralenties. Le 90e centile devrait se situer dans la plage des millisecondes à un chiffre, et le 99e centile devrait être inférieur à 100 ms.

• Adapter Dispatch Duration (Durée de distribution de l'adaptateur) indique la latence rencontrée par Mixer lors de l'appel des adaptateurs (par lesquels il envoie des informations aux systèmes de télémétrie et de journalisation). Des latences élevées à ce niveau auront un impact certain sur les performances du réseau maillé. Là encore, les latences P90 doivent être inférieures à 10 ms.

Surveillance de la galerie

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

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

Métriques importantes à surveiller

Validation des ressources

Il s'agit de la métrique la plus importante à suivre. Elle indique le nombre de ressources de différents types (règles de destination, passerelles et entrées de service, par exemple) qui réussissent ou échouent la validation.

Clients connectés

Indique le nombre de clients connectés à Galley. Il est généralement de 3 (pilot, istio-telemetry, istio-policy) et évolue en fonction de la mise à l'échelle de ces composants.

16. Dépannage d'Istio

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

Si votre tableau de bord Pilot indique que vous avez des problèmes de configuration, vous devez examiner les journaux Pilot ou utiliser istioctl pour trouver les problèmes de configuration.

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

Dans le journal qui s'affiche, recherchez un message État de la notification push. 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 du push indique les problèmes survenus lors de la tentative d'envoi de la configuration aux proxys Envoy. Dans ce cas, plusieurs messages "Cluster en double" s'affichent, ce qui indique des destinations en amont en double.

Pour obtenir de l'aide afin de diagnostiquer les problèmes, contactez l'assistance Google Cloud.

Identifier les erreurs de configuration

Pour utiliser istioctl afin d'analyser votre configuration, exécutez istioctl experimental analyze -k --context $OPS_GKE_1. Cela permet d'analyser la configuration de votre système, d'indiquer les problèmes et de suggérer des modifications. 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 effectué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. Pour que le script de nettoyage s'exécute, vous avez besoin des informations suivantes.

• Nom de l'organisation (par exemple, yourcompany.com)
• ID de l'atelier : au format YYMMDD-NN, par exemple 200131-01
• Bucket GCS de l'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 le compte administrateur souhaité.

gcloud config list
 

15. Accédez au dossier "asm".

cd ${WORKDIR}/asm
 

16. Définissez le nom de votre organisation et l'ID de l'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}