Présentation

Les clusters Kubernetes sont configurés à l'aide de fichiers manifestes, ou configurations, écrits au format YAML ou JSON. Ces configurations comprennent d'importants objets Kubernetes tels que Namespaces, ClusterRoles, ClusterRoleBindings, Roles, RoleBindings, PodSecurityPolicy, NetworkPolicy, ResourceQuotas, etc.

Ces configurations déclaratives peuvent être appliquées manuellement ou à l'aide d'un outil automatisé. La méthode privilégiée consiste à utiliser un processus automatisé afin d'établir et de maintenir un environnement géré cohérent dès le début.

Anthos Config Management est une solution permettant de gérer ces ressources sous forme de configuration comme du code. Anthos Config Management utilise un dépôt Git avec contrôle des versions pour le stockage de la configuration, ainsi que des opérateurs de configuration qui appliquent les configurations aux clusters sélectionnés.

Anthos Config Management vous permet de gérer facilement la configuration de nombreux clusters. Les dépôts Git, qui stockent les configurations à appliquer aux clusters, sont au cœur de ce processus.

Objectifs

Cet atelier va vous apprendre à effectuer les tâches suivantes :

• Installer l'opérateur Config Management Operator et l'outil de ligne de commande nomos

• Configurer votre dépôt de configuration dans Cloud Source Repositories

• Connecter les clusters GKE au dépôt de configuration

• Examiner les configurations dans vos clusters et votre dépôt

• Filtrer l'application des configurations par espace de noms

• Vérifier la gestion automatisée de la dérive

• Mettre à jour une configuration dans le dépôt

Tâche 0 : Mettre en place l'atelier

Dans cette tâche, vous allez utiliser Qwiklabs pour procéder à l'initialisation de votre atelier.

Accéder à Qwiklabs

Pour chaque atelier, nous vous attribuons un nouveau projet Google Cloud et un nouvel ensemble de ressources pour une durée déterminée, sans frais.

1. Connectez-vous à Qwiklabs dans une fenêtre de navigation privée.

2. Vérifiez le temps imparti pour l'atelier (par exemple : 01:15:00) : vous devez pouvoir le terminer dans ce délai.
   Une fois l'atelier lancé, vous ne pouvez pas le mettre en pause. Si nécessaire, vous pourrez le redémarrer, mais vous devrez tout reprendre depuis le début.

3. Lorsque vous êtes prêt, cliquez sur Démarrer l'atelier.

4. Notez vos identifiants pour l'atelier (Nom d'utilisateur et Mot de passe). Ils vous serviront à vous connecter à Google Cloud Console.

5. Cliquez sur Ouvrir la console Google.

6. Cliquez sur Utiliser un autre compte, puis copiez-collez les identifiants de cet atelier lorsque vous y êtes invité.
   Si vous utilisez d'autres identifiants, des messages d'erreur s'afficheront ou des frais seront appliqués.

7. Acceptez les conditions d'utilisation et ignorez la page concernant les ressources de récupération des données.

Une fois la connexion initiale effectuée, le tableau de bord du projet s'affiche.

Cliquez sur Sélectionner un projet, puis sélectionnez l'ID de votre projet GCP. Cliquez ensuite sur OUVRIR.

Activer Google Cloud Shell

Google Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud.

Google Cloud Shell vous permet d'accéder à vos ressources Google Cloud grâce à une ligne de commande.

1. Dans la barre d'outils située en haut à droite dans la console Cloud, cliquez sur le bouton "Ouvrir Cloud Shell".

   

2. Cliquez sur Continuer.

Le provisionnement et la connexion à l'environnement prennent quelques instants. Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Par exemple :

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

• Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

Résultat :

Exemple de résultat :

• Vous pouvez lister les ID de projet à l'aide de cette commande :

Résultat :

Exemple de résultat :

Tâche 1 : Terminer et vérifier la configuration de l'atelier

1. Configurez l'environnement Cloud Shell pour accéder à vos clusters via la ligne de commande :

   export PROJECT_ID=$(gcloud config get-value project) export SHELL_IP=$(curl -s api.ipify.org) export KUBECONFIG=~/.kube/config export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} \ --format="value(projectNumber)") gcloud compute firewall-rules create shell-to-onprem \ --allow tcp \ --source-ranges $SHELL_IP gsutil cp gs://$PROJECT_ID-kops-onprem/config \ ~/.kube/config

2. Définissez kubectl de sorte à utiliser le contexte du cluster onprem :

   kubectx onprem.k8s.local

3. Extrayez le jeton du secret qui représente le compte de service Kubernetes qui sera utilisé pour GKE Connect :

   printf "\n$(kubectl describe secret remote-admin-sa| sed -ne 's/^token: *//p')\n\n"

   Résultat (ne pas copier)

   aSB3aWxsIG5vdCB0cnkgdG8gc3RlYWwgc29tZW9uZSBlbHNlcyB0b2tlbiBhZ2FpbgppIHdpbGwgbm90IHRyeSB0byBzdGVhbCBzb21lb25lIGVsc2VzIHRva2VuIGFnYWluCmkgd2lsbCBub3QgdHJ5IHRvIHN0ZWFsIHNvbWVvbmUgZWxzZXMgdG9rZW4gYWdhaW4KaSB3aWxsIG5vdCB0cnkgdG8gc3RlYWwgc29tZW9uZSBlbHNlcyB0b2tlbiBhZ2FpbgppIHdpbGwgbm90IHRyeSB0byBzdGVhbCBzb21lb25lIGVsc2VzIHRva2VuIGFnYWluCmkgd2lsbCBub3QgdHJ5IHRvIHN0ZWFsIHNvbWVvbmUgZWxzZXMgdG9rZW4gYWdhaW4KaSB3aWxsIG5vdCB0cnkgdG8gc3RlYWwgc29tZW9uZSBlbHNlcyB0b2tlbiBhZ2FpbgppIHdpbGwgbm90IHRyeSB0byBzdGVhbCBzb21lb25lIGVsc2VzIHRva2VuIGFnYWluCmkgd2lsbCBub3QgdHJ5IHRvIHN0ZWFsIHNvbWVvbmUgZWxzZXMgdG9rZW4gYWdhaW4K

4. Sélectionnez le contenu du jeton dans Cloud Shell. (Il est copié automatiquement.)

   Important : N'utilisez pas Ctrl+C ni Cmd+C pour copier du contenu dans le presse-papiers. Ces combinaisons de touches copient les retours à la ligne de l'affichage au lieu de traiter le jeton comme une seule ligne de texte.

   Il suffit de sélectionner le texte dans Cloud Shell pour placer le contenu dans le tampon de votre presse-papiers.

5. Accédez à Navigation > Kubernetes Engine > Clusters. Faites défiler l'écran vers la droite, puis cliquez sur les trois points pour ouvrir le menu déroulant de la ligne du cluster onprem-connect. Cliquez ensuite sur l'option Connexion.

   

6. Lorsque vous y êtes invité, sélectionnez Jeton comme type d'authentification, collez le jeton précédemment copié, puis cliquez sur Connexion.

   

   Vous devriez maintenant voir deux clusters répertoriés avec des coches vertes, indiquant que les deux clusters sont bien enregistrés.

   

7. Accédez à la page Services et entrée et recherchez l'adresse du service frontend-external pour chaque cluster.

   Supprimez les filtres (le cas échéant) pour afficher les adresses de service de frontend-external.

   

   Accédez à ces adresses dans de nouveaux onglets de navigateur et vérifiez que des applications indépendantes distinctes sont opérationnelles dans chaque cluster.

   

Tâche 2 : Installer l'opérateur Config Management Operator et l'outil de ligne de commande nomos

L'opérateur Config Management Operator est un contrôleur qui gère Anthos Config Management dans un cluster Kubernetes. Dans cette tâche, vous allez installer l'opérateur en tant que charge de travail du système sur les deux clusters. Vous installerez aussi l'outil de ligne de commande nomos, qui vous aide à connaître l'état d'Anthos Config Management dans vos clusters.

Installer l'opérateur Config Management Operator sur le cluster gke

1. Dans Cloud Shell, basculez votre contexte vers le cluster gke :

   kubectx gke=gke_${PROJECT_ID}_us-central1-b_gke kubectx gke

2. Téléchargez le fichier de configuration pour les ressources Config Management.

   export LAB_DIR=$HOME/acm-lab mkdir $LAB_DIR cd $LAB_DIR gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml

3. Examinez le fichier dans l'éditeur Cloud Shell pour avoir une idée de ce qui est créé dans votre cluster.

   Le fichier est acm-lab/config-management-operator.yaml.

   edit config-management-operator.yaml

   

   Vous devrez peut-être charger l'éditeur de code dans une nouvelle fenêtre lorsque vous lancerez l'atelier dans une fenêtre de navigation privée.

4. Quittez l'éditeur et appliquez la configuration au cluster gke :

   Vous devrez peut-être cliquer sur Ouvrir le terminal dans Cloud Shell.

   kubectl apply -f config-management-operator.yaml

   Résultat (ne pas copier)

   customresourcedefinition.apiextensions.k8s.io/configmanagements.addons.sigs.k8s.io created clusterrolebinding.rbac.authorization.k8s.io/config-management-operator created clusterrole.rbac.authorization.k8s.io/config-management-operator created serviceaccount/config-management-operator created deployment.apps/config-management-operator created namespace/config-management-system created

5. Utilisez la console GCP pour vérifier qu'une charge de travail du système appelée config-management-operator a été créée. Accédez à Navigation > Kubernetes Engine > Charges de travail.

   Supprimez le filtre pour afficher les objets système. Le déploiement devrait s'afficher.

   

Installer l'opérateur Config Management Operator sur le cluster onprem

6. Changez de contexte et appliquez le fichier de configuration au cluster onprem :

   kubectx onprem.k8s.local kubectl apply -f config-management-operator.yaml

7. À l'aide de la console ou de la commande kubectl, vérifiez que l'opérateur Config Management Operator a été déployé sur le cluster onprem.

Installer l'outil de ligne de commande nomos dans Cloud Shell

8. Dans Cloud Shell, téléchargez l'outil de ligne de commande nomos :

   cd $LAB_DIR gsutil cp gs://config-management-release/released/latest/linux_amd64/nomos nomos chmod +x ./nomos

9. Servez-vous de la commande nomos status pour vérifier qu'Anthos Config Management est correctement installé et configuré :

   ./nomos status

   Résultat (ne pas copier)

   Connecting to clusters... Failed to retrieve syncBranch for "onprem.k8s.local": configmanagements.configmanagement.gke.io "config-management" not found Failed to retrieve repos for "onprem.k8s.local": the server could not find the requested resource (get repos.configmanagement.gke.io) Failed to retrieve syncBranch for "gke": configmanagements.configmanagement.gke.io "config-management" not found Failed to retrieve repos for "gke": the server could not find the requested resource (get repos.configmanagement.gke.io) Current Context Sync Status Last Synced Token Sync Branch Resource Status ------- ------- ----------- ----------------- ----------- --------------- gke NOT CONFIGURED *onprem.k8s.local NOT CONFIGURED Config Management Errors: gke ConfigManagement resource is missing onprem.k8s.local ConfigManagement resource is missing

   Dans ce cas, Config Management est installé, mais n'est pas encore configuré pour vos clusters. L'état est signalé comme NON CONFIGURÉ pour les deux clusters.

   Les autres statuts peuvent être : NON INSTALLÉ et SYNCHRONISÉ.

   Lorsque nomos status signale une erreur, il affiche également tout message d'erreur supplémentaire disponible pour aider à diagnostiquer le problème sous les erreurs Config Management Errors.

   Vous corrigerez les problèmes que vous voyez ici dans les étapes suivantes.

Tâche 3 : Configurer votre dépôt Anthos Config Management

Anthos Config Management nécessite de stocker vos configurations dans un dépôt Git. Cette tâche vous amène à configurer ce dépôt.

Anthos Config Management est compatible avec tous les dépôts Git, y compris GitHub et Google Cloud Source Repositories. Dans cet atelier, vous allez utiliser Cloud Source Repositories.

Créer un dépôt de configuration local

1. Définissez le nom d'utilisateur et l'adresse e-mail de vos activités Git.

   export GCLOUD_EMAIL=$(gcloud config get-value account) echo $GCLOUD_EMAIL echo $USER git config --global user.email "$GCLOUD_EMAIL" git config --global user.name "$USER"

2. Obtenez des exemples de fichiers de configuration pour l'atelier :

   git clone https://github.com/GoogleCloudPlatform/training-data-analyst cd ./training-data-analyst/courses/ahybrid/v1.0/AHYBRID071/config

3. Prenez le temps de vérifier la structure du répertoire config. Cliquez sur le bouton Ouvrir l'éditeur dans Cloud Shell, puis affichez le détail de acm-lab/training-data-analyst/courses/ahybrid/v1.0/AHYBRID071/config dans la section de l'explorateur de l'éditeur.

   Prenez le temps d'examiner les sous-répertoires et le contenu des fichiers de configuration que vous trouvez.

4. Cliquez sur Ouvrir le terminal pour revenir à la ligne de commande Cloud Shell, puis initialisez le répertoire de configuration en tant que nouveau dépôt Git local :

   git init git add . git commit -m "Initial config repo commit."

   Résultat (ne pas copier)

   9 files changed, 67 insertions(+) create mode 100644 README.md create mode 100644 cluster/clusterrole-namespace-readers.yaml create mode 100644 cluster/clusterrolebinding-namespace-readers.yaml create mode 100644 namespaces/dev/namespace.yaml create mode 100644 namespaces/prod/namespace.yaml create mode 100644 namespaces/rolebinding-sre.yaml create mode 100644 namespaces/selector-sre-support.yaml create mode 100644 system/README.md create mode 100644 system/repo.yaml

Créer un dépôt Cloud Source Repositories et le configurer en tant que dépôt distant pour le dépôt local

5. Créez un dépôt Cloud Source Repositories nommé anthos_config pour héberger votre code :

   gcloud source repos create anthos_config

6. Configurez gcloud.sh pour fournir vos identifiants d'accès à Git :

   git config credential.helper gcloud.sh

7. Ajoutez votre dépôt de configuration nouvellement créé en tant que Git distant :

   git remote add origin https://source.developers.google.com/p/$PROJECT_ID/r/anthos_config

8. Transférez votre code vers la branche principale du nouveau dépôt :

   git push origin master

9. Vérifiez que votre dépôt et votre code source ont été créés dans Cloud Source Repositories. Sélectionnez Navigation > Dépôts sources. Sélectionnez ensuite le dépôt anthos_config.

Générer des clés et créer des secrets sur vos clusters

Lors de son exécution sur vos clusters, l'opérateur de configuration Anthos Config Management a besoin d'un accès en lecture seule à votre dépôt Git pour pouvoir lire les dernières configurations validées, puis les vérifier ou les appliquer à vos clusters. Les identifiants pour cet accès en lecture seule à votre dépôt Git sont stockés dans le secret git-creds de chaque cluster enregistré.

Lorsque vous utilisez Cloud Source Repositories, il est recommandé d'utiliser une paire de clés SSH pour autoriser l'accès à votre dépôt.

10. Générez une paire de clés SSH avec Cloud Shell.

    export GCLOUD_EMAIL=$(gcloud config get-value account) cd $LAB_DIR ssh-keygen -t rsa -b 4096 \ -C "$GCLOUD_EMAIL" \ -N '' \ -f $HOME/.ssh/id_rsa.acm

11. Enregistrez la clé privée dans un secret sur chaque cluster :

    kubectx gke kubectl create secret generic git-creds \ --namespace=config-management-system \ --from-file=ssh=$HOME/.ssh/id_rsa.acm kubectx onprem.k8s.local kubectl create secret generic git-creds \ --namespace=config-management-system \ --from-file=ssh=$HOME/.ssh/id_rsa.acm

Gérer des clés dans Cloud Source Repositories

La partie correspondant à la clé publique SSH de la paire de clés SSH générée doit être enregistrée avec Cloud Source Repositories. Les opérateurs de configuration de vos clusters peuvent ensuite utiliser la clé privée SSH, stockée comme secret de cluster, pour accéder à votre dépôt de configuration.

12. Dans la console Cloud Source Repositories, cliquez sur l'icône de menu à trois points dans la barre d'outils supérieure droite, puis cliquez sur Gérer les clés SSH.

13. Cliquez sur Enregistrer la clé SSH.

14. Vous devrez peut-être entrer votre mot de passe d'utilisateur de Qwiklabs.

15. Saisissez config demo key dans le champ Nom de clé. Vous pouvez choisir un autre nom de clé au besoin.

16. À partir de Cloud Shell, copiez la valeur de la clé à partir du résultat de cette commande :

    cat $HOME/.ssh/id_rsa.acm.pub

    La clé commence par ssh- ou ecdsa-, et se termine par une adresse e-mail.

    Important : N'utilisez pas Ctrl+C ni Cmd+C pour copier du contenu dans le presse-papiers. Ces combinaisons de touches copient les retours à la ligne de l'affichage au lieu de traiter la valeur clé correctement.

    Il suffit de sélectionner le texte dans Cloud Shell pour placer le contenu dans le tampon de votre presse-papiers.

17. Revenez dans Cloud Source Repositories et collez la clé que vous avez copiée dans votre fichier de clé publique dans le champ Clé.

18. Cliquez sur Enregistrer.

    Vous devez maintenant voir la clé enregistrée.

    

Tâche 4 : Définir et déployer des opérateurs Config Management

Créer les fichiers YAML ConfigManagement

Pour configurer les opérateurs Config Management afin qu'ils lisent les données de votre dépôt, vous devez créer des fichiers de configuration pour les objets ConfigManagement CustomResources et les appliquer à vos clusters.

Des fichiers de configuration vous ont été fournis pour vos deux clusters. Vous devez modifier chacun d'entre eux pour qu'ils pointent vers votre dépôt hébergé.

1. À l'aide de l'éditeur de code Cloud Shell, ouvrez le fichier de configuration gke pour le modifier :

   edit ~/acm-lab/training-data-analyst/courses/ahybrid/v1.0/AHYBRID071/config-management/gke-config-management.yaml

2. Remplacez l'espace réservé [qwiklabs-user-email] par l'adresse e-mail de votre utilisateur Qwiklabs, comme indiqué dans l'angle supérieur gauche de la fenêtre Qwiklabs.

3. Remplacez l'espace réservé [qwiklabs-project] par l'ID de projet GCP affiché dans l'angle supérieur gauche de la fenêtre Qwiklabs.

   

   Notez aussi que plusieurs options peuvent être incluses pour configurer la manière dont la ressource interagit avec votre dépôt. Par exemple, secretType est configuré sur ssh pour indiquer que ConfigManagement doit utiliser les clés précédemment stockées.

   Consultez les instructions d'installation pour en savoir plus sur les champs.

4. Enregistrez les modifications dans votre fichier.

5. Répétez le processus pour le fichier de configuration onprem.

   edit ~/acm-lab/training-data-analyst/courses/ahybrid/v1.0/AHYBRID071/config-management/onprem-config-management.yaml

   Vous pouvez copier la ligne depuis gke-config-management.yaml.

Vérifier l'état actuel de vos clusters

6. Retournez dans Cloud Shell, basculez les contextes vers votre cluster gke et répertoriez les espaces de noms :

   kubectx gke kubectl get namespace

   Résultat (ne pas copier)

   NAME STATUS AGE config-management-system Active 6m31s default Active 26m gke-connect Active 25m istio-system Active 25m kube-node-lease Active 27m kube-public Active 27m kube-system Active 27m prod Active 24m
   • Un espace de noms prod s'affiche-t-il ?
   • Qu'en est-il d'un espace de noms dev ?

7. Décrivez l'espace de noms prod et notez les étiquettes que vous voyez :

   kubectl describe namespace prod

   Résultat (ne pas copier)

   Name: prod Labels: istio.io/rev=asm-173-6 Annotations: <none> Status: Active Resource Quotas Name: gke-resource-quotas Resource Used Hard -------- --- --- count/ingresses.extensions 0 100 count/jobs.batch 0 5k pods 12 1500 services 12 500 No LimitRange resource.

8. Répertoriez les objets ClusterRole et ClusterRoleBinding sur le cluster gke.

   kubectl get clusterroles

   Résultat (ne pas copier)

   NAME system:node-bootstrapper system:node-problem-detector system:node-proxier system:persistent-volume-provisioner system:public-info-viewer system:volume-scheduler view

   et

   kubectl get clusterrolebindings

   Résultat (ne pas copier)

   NAME system:metrics-server system:node system:node-proxier system:public-info-viewer system:volume-scheduler
   • Voyez-vous des références aux namespace-readers ?

9. Répertoriez les objets RoleBinding pour le service prod.

   kubectl get rolebindings -n prod

   Résultat (ne pas copier)

   Aucune ressource trouvée dans l'espace de noms prod.
   • Voyez-vous une référence à sre@foo-corp.com ?

Examiner les configurations stockées dans votre dépôt

10. Dans l'éditeur Cloud Shell, accédez à acm-lab/training-data-analyst/courses/ahybrid/v1.0/AHYBRID071/config. Notez la structure des dossiers.

    • Le dossier cluster comporte des configurations qui s'appliquent aux clusters gérés.
    • Le dossier namespaces contient des configurations qui s'appliquent aux espaces de noms sur les clusters gérés.

11. Dans le dossier cluster, ouvrez et examinez les fichiers de configuration que vous trouvez. L'un définit un ClusterRole que vous souhaitez ajouter à chaque cluster, et l'autre définit un ClusterRoleBinding que vous souhaitez ajouter à chaque cluster.

12. Dans le dossier namespaces, ouvrez le dossier dev, puis le fichier namespace.yaml. Ce fichier définit un espace de noms que vous souhaitez créer sur chaque cluster.

13. Dans le dossier namespaces, ouvrez le dossier prod, puis le fichier namespace.yaml. Ce fichier définit un espace de noms que vous souhaitez créer sur chaque cluster. Notez l'étiquette env.

14. Dans le dossier namespaces, ouvrez le fichier selector-sre-support.yaml. Notez que NamespaceSelector ne sélectionne que les espaces de noms ayant une étiquette donnée. Dans ce cas, l'étiquette est env:prod. Seul l'espace de noms prod est affecté par les configurations qui utilisent ce sélecteur.

15. Dans le dossier namespaces, ouvrez le fichier rolebinding-sre.yaml. Notez les annotations indiquant que cette configuration doit être appliquée à l'aide d'un sélecteur.

    

    Lorsque ces configurations sont appliquées, vous devez vous retrouver avec les éléments suivants en place :

    • Un ClusterRole nommé namespace-readers
    • Un ClusterRoleBinding pour Cheryl
    • Un espace de noms dev
    • Un espace de noms prod avec les étiquettes env et istio-injection
    • Un RoleBinding dans l'espace de noms prod pour sre@foo-corp.com

Déployer l'opérateur Config Management

16. Dans Cloud Shell, appliquez la configuration au cluster gke.

    kubectx gke kubectl apply -f ~/acm-lab/training-data-analyst/courses/ahybrid/v1.0/AHYBRID071/config-management/gke-config-management.yaml

    Résultat (ne pas copier)

    configmanagement.configmanagement.gke.io/config-management created

17. Appliquez la configuration au cluster onprem.

    kubectx onprem.k8s.local kubectl apply -f ~/acm-lab/training-data-analyst/courses/ahybrid/v1.0/AHYBRID071/config-management/onprem-config-management.yaml

    Résultat (ne pas copier)

    configmanagement.configmanagement.gke.io/config-management created

18. Patientez 30 secondes, puis utilisez nomos status pour voir si Anthos Config Management est correctement installé et configuré. Si les clusters ne sont pas synchronisés, attendez encore 30 secondes, puis réessayez. Ils doivent être synchronisés à ce stade.

    ./nomos status

    Résultat (ne pas copier)

    Connecting to clusters... Current Context Sync Status ... Sync Branch ... ------- ------- ----------- ----------- gke SYNCED master *onprem.k8s.local SYNCED master

Tâche 5 : Vérifier que les clusters sont synchronisés à partir de l'interface utilisateur d'Anthos Config Management

1. Dans Google Cloud Console, accédez à Navigation > Anthos > Fonctionnalités.

2. Dans la fonctionnalité Config Management, cliquez sur Activer, puis à nouveau dans la fenêtre pop-up, cliquez sur Activer Config Management.

   

3. Dans le panneau latéral, accédez à Config Management pour vérifier que les deux clusters sont synchronisés. Notez que l'affichage des clusters peut prendre une à deux minutes.

   

4. Sélectionnez l'un des agents du cluster, puis cliquez sur "Configurer". Vous y trouverez les informations git que nous avons configurées dans les tâches précédentes.

Tâche 6 : Vérifier que les configurations ont été appliquées à vos clusters

1. Définissez votre contexte kubectl et répertoriez les espaces de noms dans le cluster gke :

   kubectx gke kubectl get namespaces
   • Les espaces de noms dev et prod s'affichent-ils ?

2. Répertoriez les ClusterRoles du cluster gke :

   kubectl get clusterroles
   • Une entrée s'affiche-t-elle pour namespace-readers ?

3. Répertoriez les ClusterRoleBindings du cluster gke :

   kubectl get clusterrolebindings
   • Une entrée s'affiche-t-elle pour namespace-readers ?

4. Décrivez le ClusterRoleBinding de namespace-readers :

   kubectl describe clusterrolebinding namespace-readers
   • Le rôle a-t-il été attribué à Cheryl ?

5. Consultez les RoleBindings de l'espace de noms dev :

   kubectl get rolebindings -n dev
   • Existe-t-il des liaisons pour l'espace de noms dev ?

6. Consultez les RoleBindings de l'espace de noms prod :

   kubectl get rolebindings -n prod
   • Existe-t-il des liaisons pour l'espace de noms prod ? Notez que le sélecteur d'espace de noms a limité l'application de cette configuration à l'espace de noms prod uniquement.

   Vos configurations, stockées dans Cloud Source Repositories, ont été appliquées au cluster gke. Vérifiez maintenant si elles ont été appliquées au cluster onprem.

7. Définissez votre contexte kubectl :

   kubectx onprem.k8s.local

8. Répétez les étapes que vous avez effectuées sur le cluster gke. Vérifiez que les modifications ont également été appliquées au cluster onprem.

Tâche 7 : Vérifier la gestion automatisée de la dérive

Cette tâche vous amène à vérifier qu'Anthos Config Management assure la synchronisation des objets avec les configurations dans votre dépôt, même si des modifications manuelles y sont apportées.

Configurer des volets tmux dans Cloud Shell

Vous allez configurer trois volets Cloud Shell de manière à pouvoir exécuter des commandes dans un volet et à surveiller les effets sur les deux clusters dans les autres volets.

1. Divisez l'écran de session avec l'utilitaire tmux intégré à Cloud Shell en utilisant <Ctrl>+b, puis %. Deux volets doivent s'afficher dans Cloud Shell.

   

   Chaque fois que vous interagissez avec tmux, vous devez commencer par la combinaison <Ctrl>+b qui signale une commande à tmux.

2. Passez au volet de gauche en saisissant ce qui suit :

   • <Ctrl>+b
   • <Flèche vers la gauche>

3. Pour redimensionner le volet de gauche, procédez comme suit :

   • Appuyez sur <Ctrl>+b pour commencer à interagir avec tmux
   • Saisissez : pour obtenir une invite de commande tmux.
   • Saisissez resize-pane -L 35 pour rendre le volet de gauche plus étroit.

   

   Vos volets doivent se présenter comme suit :

   

4. Passez au volet de droite en saisissant ce qui suit :

   • <Ctrl>+b
   • <Flèche vers la droite>

5. Divisez le volet de droite en saisissant ce qui suit :

   • <Ctrl>+b
   • %

   Vous devez normalement avoir trois volets de même largeur environ.

   

Essayer de supprimer un objet géré par Anthos Config Management

6. Passez au volet de gauche (<Ctrl>+b, <flèche vers la droite>), définissez le contexte kubectl et demandez à kubectl de surveiller les modifications apportées au ClusterRoleBinding de namespace-readers sur le cluster gke.

   clear kubectx gke kubectl get clusterrolebinding namespace-readers --watch-only

7. Passez au volet central (<Ctrl>+b, <flèche vers la droite>), définissez le contexte kubectl et demandez à kubectl de surveiller les modifications apportées au ClusterRoleBinding de namespace-readers sur le cluster onprem.

   clear kubectx onprem.k8s.local kubectl get clusterrolebinding namespace-readers --watch-only

8. Passez au volet de droite (<Ctrl>+b, <flèche vers la droite>) et supprimez le ClusterRoleBinding sur les deux clusters.

   clear kubectx gke kubectl delete clusterrolebinding namespace-readers kubectx onprem.k8s.local kubectl delete clusterrolebinding namespace-readers

   Deux mises à jour devraient s'afficher dans chacun des volets dans lesquels vous surveillez les modifications d'objet. L'une indiquant la suppression de l'objet et l'autre montrant la création de l'objet pour que le cluster respecte la configuration définie.

   

9. Dans le volet de droite, vérifiez que le ClusterRoleBinding a été recréé sur le cluster gke :

   kubectx gke kubectl describe ClusterRoleBinding namespace-readers

   Résultat (ne pas copier)

   Name: namespace-readers Labels: app.kubernetes.io/managed-by=configmanagement.gke.io Annotations: configmanagement.gke.io/cluster-name: gke configmanagement.gke.io/managed: enabled configmanagement.gke.io/source-path: cluster/clusterrolebinding-namespace-reader.yaml configmanagement.gke.io/token: 7275a22cd4315133d180139e0ee6a444ced1b86e Role: Kind: ClusterRole Name: namespace-reader Subjects: Kind Name Namespace ---- ---- --------- User cheryl@anthos-labs.com

   Répétez le processus pour le cluster onprem.

Essayez de mettre à jour un objet géré par Anthos Config Management

10. Passez au volet de gauche (<Ctrl>+b, <flèche de droite>) et annulez la commande de surveillance de kubectl en utilisant <Ctrl>+c.

11. Démarrez une nouvelle commande de surveillance, cette fois pour observer les modifications apportées aux étiquettes de l'espace de noms prod sur le cluster gke, puis affichez la configuration de l'espace de noms en détail :

    clear kubectx gke kubectl get namespace prod -o custom-columns=NAME:.metadata.labels \ --watch-only

12. Passez au volet central (<Ctrl>+b, <flèche vers la droite>), puis annulez la commande de surveillance de kubectl en utilisant <Ctrl>+c.

13. Démarrez une nouvelle commande de surveillance, cette fois pour observer les modifications apportées aux étiquettes de l'espace de noms prod sur le cluster onprem, et affichez la configuration de l'espace de noms en détail :

    clear kubectx onprem.k8s.local kubectl get namespace prod -o custom-columns=NAME:.metadata.labels \ --watch-only

14. Passez au volet de droite (<Ctrl>+b, <flèche vers la droite> ), puis supprimez l'étiquette env: prod des espaces de noms "prod" sur les deux clusters.

    clear kubectx gke kubectl label namespace prod env- kubectx onprem.k8s.local kubectl label namespace prod env-

    Deux messages doivent s'afficher dans chacun des volets sur lesquels vous surveillerez les modifications d'objets. Le premier affiche les étiquettes de l'espace de noms après la suppression de l'étiquette env:prod. Le second affiche les étiquettes après leur nouvel ajout.

    

Tâche 8 : Mettre à jour une configuration dans le dépôt

Cette tâche vous amène à vérifier qu'Anthos Config Management met à jour les objets gérés lorsque les configurations de votre dépôt changent.

Vérifier la configuration actuelle et configurer les montres

1. Passez au volet de gauche (<Ctrl>+b, <flèche vers la droite>) et annulez l'opération de surveillance de kubectl en utilisant <Ctrl>+c.

2. Dans le volet de gauche, examinez le ClusterRoleBinding de namespace-readers sur le cluster gke :

   clear kubectx gke kubectl get clusterrolebindings namespace-readers -o yaml

   Résultat (ne pas copier)

   subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: cheryl@anthos_labs.com

3. Configurez kubectl pour surveiller les modifications apportées aux objets de ce ClusterRoleBinding sur le cluster gke.

   clear kubectx gke kubectl get clusterrolebinding namespace-readers -o \ custom-columns=NAME:.subjects --watch-only

4. Passez au volet central (<Ctrl>+b, <flèche vers la droite>), puis annulez la commande de surveillance de kubectl en utilisant <Ctrl>+c.

5. Dans le volet du milieu, examinez le ClusterRoleBinding de namespace-readers sur le cluster onprem :

   clear kubectx onprem.k8s.local kubectl get clusterrolebindings namespace-readers -o yaml

   Résultat (ne pas copier)

   subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: cheryl@anthos_labs.com

6. Configurez kubectl pour surveiller les modifications apportées aux objets de ce ClusterRoleBinding sur le cluster onprem.

   clear kubectx onprem.k8s.local kubectl get clusterrolebinding namespace-readers -o \ custom-columns=NAME:.subjects --watch-only

7. Passez au volet de droite (<Ctrl>+b, <flèche vers la droite>), puis effacez le volet :

   clear

Mettre à jour le dépôt de configuration du cluster

8. À l'aide de l'éditeur de code Cloud Shell, modifiez le fichier de configuration du ClusterRoleBinding :

   edit ~/acm-lab/training-data-analyst/courses/ahybrid/v1.0/AHYBRID071/config/cluster/clusterrolebinding-namespace-readers.yaml

9. Ajoutez un nouveau bloc d'utilisateur dans le champ subjects pour jane@anthos_labs.com. Vous pouvez copier l'intégralité de l'utilisateur cheryl@anthos_labs.com vers un nouvel utilisateur et remplacer le nom par jane@anthos_labs.com.

   Le nouveau bloc subjects présente le contenu suivant :

   subjects: - kind: User name: cheryl@anthos_labs.com apiGroup: rbac.authorization.k8s.io - kind: User name: jane@anthos_labs.com apiGroup: rbac.authorization.k8s.io

   Enregistrez les modifications.

Insérer la modification dans votre dépôt de configuration

10. Dans le volet droit, vérifiez que les modifications apportées à votre configuration sont valides d'un point de vue syntaxique.

    export LAB_DIR=$HOME/acm-lab cd $LAB_DIR ./nomos vet --path=training-data-analyst/courses/ahybrid/v1.0/AHYBRID071/config

    Aucune erreur n'est indiquée, la configuration est donc valide.

11. Dans le volet droit, créez un commit et envoyez la modification vers votre dépôt.

    cd ~/acm-lab/training-data-analyst/courses/ahybrid/v1.0/AHYBRID071/config git add . git commit -m "Add Jane to namespace-reader." git push origin master

    Dans les quelques secondes qui suivent la transmission, un message doit s'afficher dans chacun des volets sur lesquels vous observez les modifications d'objets. Ils devraient montrer qu'il existe maintenant des entrées pour Cheryl et Jane.

    

Récapitulatif

Dans cet atelier, vous avez configuré Anthos Config Management et exploré certaines de ses fonctions utiles. Vous avez connecté un dépôt Git pour la gestion des modifications avec une configuration comme du code. Vous avez configuré un opérateur Config Operator pour gérer vos clusters et vous avez vérifié que l'opérateur maintient l'état de vos clusters pour qu'ils correspondent à votre dépôt.

Terminer l'atelier

Une fois l'atelier terminé, cliquez sur Terminer l'atelier. Google Cloud Skills Boost supprime les ressources que vous avez utilisées, puis efface le compte.

Si vous le souhaitez, vous pouvez noter l'atelier. Sélectionnez un nombre d'étoiles, saisissez un commentaire, puis cliquez sur Envoyer.

Le nombre d'étoiles correspond à votre degré de satisfaction :

• 1 étoile = très insatisfait(e)
• 2 étoiles = insatisfait(e)
• 3 étoiles = ni insatisfait(e), ni satisfait(e)
• 4 étoiles = satisfait(e)
• 5 étoiles = très satisfait(e)

Si vous ne souhaitez pas donner votre avis, vous pouvez fermer la boîte de dialogue.

Pour soumettre des commentaires, suggestions ou corrections, veuillez accéder à l'onglet Assistance.

Copyright 2026 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms de société et de produit peuvent être des marques des sociétés auxquelles ils sont associés.