Simuler une défaillance de zone dans des clusters régionaux GKE

Standard

---

Une exigence réglementaire courante est qu'une entreprise puisse démontrer sa capacité de reprise après sinistre (DR). Pour les applications exécutées dans le cloud, cette exigence inclut la fiabilité et la disponibilité des services lorsque les serveurs hébergés dans une zone deviennent indisponibles pendant un certain temps. Ce document s'adresse aux administrateurs et architectes, aux opérateurs et aux administrateurs de sauvegarde et de reprise après sinistre qui souhaitent apprendre à simuler un basculement de zone lors de l'utilisation d'un cluster régional standard Google Kubernetes Engine (GKE).

Les clusters régionaux GKE sont créés dans une région choisie par l'utilisateur et exécutent le plan de contrôle sur des VM situées dans plusieurs zones de la région choisie. Les clusters GKE Autopilot sont toujours régionaux, et les clusters GKE Standard peuvent être régionaux ou zonaux. Ce tutoriel utilise un cluster régional GKE Standard. Les nœuds de cluster communiquent avec le plan de contrôle via un équilibreur de charge, ce qui signifie que l'emplacement du nœud et celui de la VM du plan de contrôle ne correspondent pas toujours. Dans la console Google Cloud, vous ne pouvez pas désactiver une zone particulière lorsque vous utilisez un cluster régional. Pour en savoir plus, consultez la page Architecture d'un cluster GKE.

Ce tutoriel propose trois méthodes différentes pour simuler la défaillance d'une zone. Vous pouvez simuler une défaillance de zone et vérifier la réponse correcte de l'application en utilisant la méthode requise à des fins de conformité.

Les méthodes décrites dans ce document s'appliquent également aux clusters zonaux, y compris les clusters à zone unique et multizones. Ces méthodes n'affectent que les nœuds des zones ciblées, et le plan de contrôle GKE n'est pas affecté.

Objectifs

• Créer un cluster GKE Standard régional en utilisant la configuration par défaut.
• Déployer un exemple d'application de microservices sur le cluster régional.
• Simuler une défaillance de zone à l'aide de l'une des trois méthodes suivantes :
  • Réduire le nombre de zones du pool de nœuds dans un cluster régional.
  • Utiliser un pool de nœuds à zone unique.
  • Marquer comme non ordonnançables et drainer les nœuds de la zone de défaillance cible.
• Vérifier la disponibilité des microservices.

Coûts

Ce tutoriel utilise les composants facturables Google Cloud suivants :

• Compute Engine
• Cluster en mode GKE Standard

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.

Avant de commencer

1. Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.
2. Installez Google Cloud CLI.

3. Pour initialiser gcloudCLI, exécutez la commande suivante :

   gcloud init

4. Créez ou sélectionnez un projet Google Cloud.

   Remarque : Si vous ne comptez pas conserver les ressources créées dans cette procédure, créez un projet au lieu de sélectionner un projet existant. Après avoir suivi ces étapes, vous pouvez supprimer le projet. Cela entraîne la suppression de toutes les ressources qui lui sont associées.

   • Créez un projet Google Cloud :

     gcloud projects create PROJECT_ID

     Remplacez PROJECT_ID par le nom du projet Google Cloud que vous créez.

   • Sélectionnez le projet Google Cloud que vous avez créé :

     gcloud config set project PROJECT_ID

     Remplacez PROJECT_ID par le nom de votre projet Google Cloud.

5. Vérifiez que la facturation est activée pour votre projet Google Cloud.

6. Activer les API Kubernetes Engine API, Compute Engine :

   gcloud services enable container.googleapis.com compute.googleapis.com

7. Installez Google Cloud CLI.

8. Pour initialiser gcloudCLI, exécutez la commande suivante :

   gcloud init

9. Créez ou sélectionnez un projet Google Cloud.

   Remarque : Si vous ne comptez pas conserver les ressources créées dans cette procédure, créez un projet au lieu de sélectionner un projet existant. Après avoir suivi ces étapes, vous pouvez supprimer le projet. Cela entraîne la suppression de toutes les ressources qui lui sont associées.

   • Créez un projet Google Cloud :

     gcloud projects create PROJECT_ID

     Remplacez PROJECT_ID par le nom du projet Google Cloud que vous créez.

   • Sélectionnez le projet Google Cloud que vous avez créé :

     gcloud config set project PROJECT_ID

     Remplacez PROJECT_ID par le nom de votre projet Google Cloud.

10. Vérifiez que la facturation est activée pour votre projet Google Cloud.

11. Activer les API Kubernetes Engine API, Compute Engine :

    gcloud services enable container.googleapis.com compute.googleapis.com

Créer un cluster standard régional

Avant de simuler la défaillance d'une zone, créez un cluster régional avec un pool de nœuds multizone. Le plan de contrôle et les nœuds du cluster sont répliqués sur plusieurs zones dans la région spécifiée.

Utilisez Google Cloud CLI pour créer le cluster :

1. Créez un cluster GKE Standard en utilisant la configuration par défaut :

   gcloud container clusters create CLUSTER_NAME \
     --region REGION \
     --num-nodes 2
   

   Remplacez les paramètres suivants :

   • CLUSTER_NAME : nom de votre cluster.
   • REGION : région choisie pour votre cluster, par exemple us-central1.

   GKE prend quelques minutes pour créer le cluster et vérifier que tout fonctionne correctement. Deux nœuds sont créés dans chaque zone de la région que vous spécifiez.

2. Vérifiez les zones de chaque nœud créé à l'étape précédente :

   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Le résultat ressemble à l'exemple suivant :

   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node1   asia-southeast1-c   10.128.0.37
   regional-cluster-1-default-pool-node2   asia-southeast1-c   10.128.0.36
   regional-cluster-1-default-pool-node3   asia-southeast1-b   10.128.0.38
   regional-cluster-1-default-pool-node4   asia-southeast1-b   10.128.0.33
   regional-cluster-1-default-pool-node5   asia-southeast1-a   10.128.0.35
   regional-cluster-1-default-pool-node6   asia-southeast1-a   10.128.0.34
   

3. Connectez-vous au cluster :

   gcloud container clusters get-credentials CLUSTER_NAME \
       --region REGION
   

Déployer un exemple d'application basée sur des microservices

Pour voir l'effet du basculement simulé dans le présent document, déployez un exemple d'application basée sur des microservices sur votre cluster. Dans ce document, vous allez utiliser l'exemple d'application Cymbal Bank :

1. Dans votre interface système, clonez le dépôt GitHub suivant et accédez au répertoire :

   git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
   cd bank-of-anthos/
   

2. Déployez l'exemple d'application Cymbal Bank sur le cluster GKE que vous avez créé dans la section précédente :

   kubectl apply -f ./extras/jwt/jwt-secret.yaml
   kubectl apply -f ./kubernetes-manifests
   

3. Attendez que les pods soient prêts :

   kubectl get pods
   

4. Après quelques minutes, les pods devraient s'afficher avec l'état Running.

   NAME                                  READY   STATUS    RESTARTS   AGE
   accounts-db-0                         1/1     Running   0          16s
   balancereader-7dc7d9ff57-sstm5        0/1     Running   0          15s
   contacts-7ddc76d94-rr28x              0/1     Running   0          14s
   frontend-747b84bff4-2mtlv             0/1     Running   0          13s
   ledger-db-0                           1/1     Running   0          13s
   ledgerwriter-f6cc7889d-9qjfg          0/1     Running   0          13s
   loadgenerator-57d4cb57cc-zqvqb        1/1     Running   0          13s
   transactionhistory-5dd7c7fd77-lwkv8   0/1     Running   0          12s
   userservice-cd5ddb4bb-wwhml           0/1     Running   0          12s
   

5. Lorsque les pods sont tous à l'état Running, obtenez l'adresse IP externe du service d'interface :

   kubectl get service frontend | awk '{print $4}'
   

6. Dans une fenêtre de navigateur Web, ouvrez l'adresse IP affichée dans le résultat de la commande kubectl get service pour accéder à votre instance de Cymbal Bank.

   Les identifiants par défaut sont renseignés automatiquement. Vous pouvez donc vous connecter à l'application et explorer certains exemples de transactions et de soldes. Vous n'avez rien à faire, si ce n'est vérifier que Cymbal Bank s'exécute correctement. Le démarrage correct de tous les services et la connexion à votre service peuvent prendre une ou deux minutes. Attendez que tous les pods soient à l'état Running et que vous puissiez vous connecter au site Cymbal Bank avant de passer à la section suivante et de simuler une défaillance de zone.

Simuler une défaillance de zone

Dans cette section, vous allez simuler une défaillance de l'une des zones. Il existe trois manières différentes de simuler ce basculement. Vous ne devez choisir qu'une seule méthode. Simulez une défaillance de zone et vérifiez la réponse de l'application en utilisant la méthode requise en fonction de vos exigences de conformité spécifiques.

Remarque : Si vos applications contiennent des charges de travail avec état, telles que des bases de données, assurez-vous que les données sont stockées dans un volume de disque persistant dissocié et que les instances dupliquées avec accès en lecture sont déployées dans plusieurs zones. Vérifiez l'espace de stockage de données avant de supprimer un pool de nœuds (simuler une défaillance de zone) ou envisagez d'utiliser un disque persistant régional. Pour une protection supplémentaire, vous pouvez également utiliser Sauvegarde pour GKE. La stratégie de cohérence des données, de fiabilité et d'atténuation des risques pour les objets StatefulSet n'entre pas dans le cadre de ce document. Si vous ne prenez pas en compte ces facteurs de stockage, vous risquez de perdre des données. Consultez la documentation de votre base de données ou application avec état spécifique, telle que PostgreSQL, SQL Server, MongoDB, Redis ou Cassandra pour en savoir plus sur les stratégies de haute disponibilité et de reprise après sinistre recommandées.

Réduire les zones du pool de nœuds

Par défaut, un pool de nœuds d'un cluster régional comporte des nœuds couvrant toutes les zones de sa région. Dans le schéma suivant, Cloud Load Balancing répartit le trafic vers un pool de nœuds couvrant trois zones. Chaque zone comprend deux nœuds, et vos pods peuvent s'exécuter dans des nœuds de n'importe laquelle de ces zones.

Dans cette section, vous simulez une défaillance de zone en mettant à jour le pool de nœuds pour qu'il ne s'exécute que dans deux zones sur trois. Cette approche vérifie que votre application peut réagir à la perte d'une zone en redistribuant correctement les pods et le trafic entre d'autres zones.

Pour mettre à jour le pool de nœuds de sorte qu'il ne s'exécute que dans certaines zones et simuler une défaillance, procédez comme suit :

1. Vérifiez la disponibilité du cluster et des services régionaux :

   kubectl get po -o wide \
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Le résultat ressemble à ce qui suit :

   NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
   accounts-db-0                         1/1     Running   0          6m30s   10.28.1.5   regional-cluster-1-default-pool-node3
   balancereader-7dc7d9ff57-shwg5        1/1     Running   0          6m30s   10.28.5.6   regional-cluster-1-default-pool-node1
   contacts-7ddc76d94-qv4x5              1/1     Running   0          6m29s   10.28.4.6   regional-cluster-1-default-pool-node2
   frontend-747b84bff4-xvjxq             1/1     Running   0          6m29s   10.28.3.6   regional-cluster-1-default-pool-node6
   ledger-db-0                           1/1     Running   0          6m29s   10.28.5.7   regional-cluster-1-default-pool-node1
   ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          6m29s   10.28.1.6   regional-cluster-1-default-pool-node3
   loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          6m29s   10.28.4.7   regional-cluster-1-default-pool-node2
   transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          6m29s   10.28.3.7   regional-cluster-1-default-pool-node6
   userservice-cd5ddb4bb-zfr2g           1/1     Running   0          6m28s   10.28.5.8   regional-cluster-1-default-pool-node1
   
   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.6
   regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.7
   regional-cluster-1-default-pool-node2   asia-southeast1-a   10.148.0.8
   regional-cluster-1-default-pool-node1   asia-southeast1-a   10.148.0.9
   regional-cluster-1-default-pool-node3   asia-southeast1-b   10.148.0.5
   regional-cluster-1-default-pool-node4   asia-southeast1-b   10.148.0.4
   

   Dans cet exemple, toutes les charges de travail Cymbal Bank sont déployées dans toutes les zones. Pour simuler une défaillance, désactivez l'une des zones (par exemple asia-southeast1-c) dans laquelle le service d'interface est déployé.

2. Simulez une défaillance de zone. Mettez à jour le pool de nœuds existant (default-pool) pour ne spécifier que deux zones sur les trois zones :

     gcloud container node-pools update default-pool \
       --cluster=CLUSTER_NAME \
       --node-locations=ZONE_A, ZONE_B \
       --region=REGION
   

   Remplacez ZONE_A, ZONE_B par les deux zones dans lesquelles vous souhaitez continuer à exécuter le pool de nœuds.

3. Vérifiez la disponibilité des microservices après avoir mis à jour le pool de nœuds :

   kubectl get po -o wide
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Le résultat doit ressembler à l'exemple ci-dessous.

   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node2   asia-southeast1-a   10.148.0.8
   regional-cluster-1-default-pool-node1   asia-southeast1-a   10.148.0.9
   regional-cluster-1-default-pool-node3   asia-southeast1-b   10.148.0.5
   regional-cluster-1-default-pool-node4   asia-southeast1-b   10.148.0.4
   
   NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
   accounts-db-0                         1/1     Running   0          28m     10.28.1.5   regional-cluster-1-default-pool-node3
   balancereader-7dc7d9ff57-shwg5        1/1     Running   0          28m     10.28.5.6   regional-cluster-1-default-pool-node1
   contacts-7ddc76d94-qv4x5              1/1     Running   0          28m     10.28.4.6   regional-cluster-1-default-pool-node2
   frontend-747b84bff4-mdnkd             1/1     Running   0          9m21s   10.28.1.7   regional-cluster-1-default-pool-node3
   ledger-db-0                           1/1     Running   0          28m     10.28.5.7   regional-cluster-1-default-pool-node1
   ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   regional-cluster-1-default-pool-node3
   loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          28m     10.28.4.7   regional-cluster-1-default-pool-node2
   transactionhistory-5dd7c7fd77-w2vqs   1/1     Running   0          9m20s   10.28.4.8   regional-cluster-1-default-pool-node2
   userservice-cd5ddb4bb-zfr2g           1/1     Running   0          28m     10.28.5.8   regional-cluster-1-default-pool-node1
   

   Dans cet exemple de résultat, asia-southeast1-c n'est plus utilisé. Le service d'interface auquel vous accédez depuis un navigateur avec l'URL http://EXTERNAL_IP reste accessible. L'utilisateur pourrait toujours effectuer des actions de dépôt et de paiement, même si l'une des zones n'est plus disponible.

Utiliser un pool de nœuds à zone unique

Dans cette section, vous simulez une défaillance de zone en supprimant deux des pools de nœuds. Cette approche vérifie que votre application peut répondre à la perte d'un pool de nœuds en redistribuant correctement les pods et le trafic sur un pool de nœuds d'une autre zone. Pour simuler une défaillance de zone sur un cluster régional, vous devez développer le cluster de base créé précédemment, en exécutant l'application Cymbal Bank sur plusieurs pools de nœuds. Cette méthode de simulation de l'interruption de zone reflète plus fidèlement une défaillance de zone réelle que le premier exemple de mise à jour des zones actives dans un pool de nœuds, car il est plus courant que plusieurs pools de nœuds existent dans un cluster :

Le cluster que vous créez dans cette section pour simuler une défaillance d'un pool de nœuds à zone unique comprend les composants suivants :

• Le pool de nœuds par défaut, généralement créé lorsque vous créez un cluster GKE Standard régional, correspond à un pool de nœuds multizones (default-pool).

  Ce cluster avec le seul default-pool est celui que vous avez créé précédemment dans ce document.

• Des pools de nœuds supplémentaires (zonal-node-pool-1 et zonal-node-pool-2) qui exécutent également des services pour l'exemple d'application Cymbal Bank.

Les lignes en pointillés du schéma montrent comment le trafic ne diffuse zonal-node-pool-2 qu'après avoir simulé une défaillance dans default-pool et zonal-node-pool-1.

Pour créer des pools de nœuds supplémentaires et simuler une défaillance, procédez comme suit :

1. Vérifiez la disponibilité du cluster régional :

   gcloud container node-pools list \
       --cluster=CLUSTER_NAME \
       --region REGION
   
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Le résultat ressemble à ce qui suit :

   NAME: default-pool
   MACHINE_TYPE: e2-medium
   DISK_SIZE_GB: 100
   NODE_VERSION: 1.27.8-gke.1067004
   
   NAME                                         ZONE.               INT_IP
   regional-cluster-1-default-pool-node5-pzmc   asia-southeast1-c   10.148.0.6
   regional-cluster-1-default-pool-node6-qf1l   asia-southeast1-c   10.148.0.7
   regional-cluster-1-default-pool-node2-dlk2   asia-southeast1-a   10.148.0.8
   regional-cluster-1-default-pool-node1-pkfd   asia-southeast1-a   10.148.0.9
   regional-cluster-1-default-pool-node3-6b6n   asia-southeast1-b   10.148.0.5
   regional-cluster-1-default-pool-node4-h0lc   asia-southeast1-b   10.148.0.4
   

   Dans cet exemple de résultat, tous les pods Cymbal Bank sont déployés dans toutes les zones du même cluster et s'exécutent dans le default-pool existant.

2. Créez deux pools de nœuds à zone unique :

   gcloud beta container node-pools create zonal-node-pool-1 \
     --cluster CLUSTER_NAME \
     --region REGION \
     --num-nodes 4 \
     --node-locations ZONE_A
   
   gcloud beta container node-pools create zonal-node-pool-2 \
       --cluster CLUSTER_NAME \
       --region REGION \
       --num-nodes 4 \
       --node-locations ZONE_B
   

   Remplacez ZONE_A et ZONE_B par les deux zones dans lesquelles vous souhaitez exécuter les nouveaux pools de nœuds à zone unique.

3. Pour simuler la défaillance d'une zone, supprimez le pool de nœuds régional default-pool et l'un des nouveaux pools de nœuds à zone unique :

   gcloud container node-pools delete default-pool \
       --cluster=CLUSTER_NAME \
       --region=REGION
   
   gcloud container node-pools delete zonal-node-pool-1 \
       --cluster=CLUSTER_NAME \
       --region=REGION
   

   Au cours du processus de suppression node-pool, les charges de travail sont arrêtées et reprogrammées vers un autre pool de nœuds disponible. Lorsque ce processus se produit, les services et les déploiements ne sont pas disponibles. Ce comportement signifie que des intervalles de temps d'arrêt doivent être spécifiés pour la création de rapports de reprise après sinistre (DR) ou de documentation.

   Vérifiez la disponibilité continue des microservices :

   kubectl get po -o wide \
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Le résultat doit ressembler à l'exemple ci-dessous :

   NAME                                  ZONE                INT_IP
   regional-cluster-1-node-pool3-node1   asia-southeast1-b   10.148.0.8
   regional-cluster-1-node-pool3-node2   asia-southeast1-b   10.148.0.9
   regional-cluster-1-node-pool3-node3   asia-southeast1-b   10.148.0.5
   regional-cluster-1-node-pool3-node4   asia-southeast1-b   10.148.0.4
   
   NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
   accounts-db-0                         1/1     Running   0          28m     10.28.1.5   regional-cluster-1-zonal-node-pool-2-node3
   balancereader-7dc7d9ff57-shwg5        1/1     Running   0          28m     10.28.5.6   regional-cluster-1-zonal-node-pool-2-node1
   contacts-7ddc76d94-qv4x5              1/1     Running   0          28m     10.28.4.6   regional-cluster-1-zonal-node-pool-2-node2
   frontend-747b84bff4-mdnkd             1/1     Running   0          9m21s   10.28.1.7   regional-cluster-1-zonal-node-pool-2-node3
   ledger-db-0                           1/1     Running   0          28m     10.28.5.7   regional-cluster-1-zonal-node-pool-2-node4
   ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   regional-cluster-1-zonal-node-pool-2-node3
   loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          28m     10.28.4.7   regional-cluster-1-zonal-node-pool-2-node2
   transactionhistory-5dd7c7fd77-w2vqs   1/1     Running   0          9m20s   10.28.4.8   regional-cluster-1-zonal-node-pool-2-node2
   userservice-cd5ddb4bb-zfr2g           1/1     Running   0          28m     10.28.5.8   regional-cluster-1-zonal-node-pool-2-node1
   

   Dans cet exemple de résultat, comme default-pool et zonal-node-pool-1 n'existent plus, tous les services s'exécutent dans zonal-node-pool-2.

Marquer comme non ordonnançables et drainer les nœuds d'une zone

Dans cette section, vous allez marquer les nœuds de votre cluster comme non ordonnançables et les drainer. Vous marquez comme non ordonnançables et drainez tous les nœuds dans une seule zone, ce qui simule la perte des pods qui s'exécutent sur ces nœuds dans la zone :

Dans ce schéma, vous marquez les nœuds de la première zone comme non ordonnançables et les drainez. Les nœuds des deux autres zones continuent de fonctionner. Cette approche vérifie que votre application peut répondre à la perte de tous les nœuds d'une zone en redistribuant correctement les pods et le trafic entre les nœuds exécutés dans d'autres zones.

Pour marquer les nœuds comme non ordonnançables et les drainer dans l'une des zones, avec pour effet de simuler une défaillance, procédez comme suit :

1. Vérifiez la disponibilité du cluster régional et des services. Examinez les noms de nœuds de la zone de défaillance cible. Vous souhaitez spécifier une zone dans laquelle s'exécutent les pods d'interface :

   kubectl get pods -o wide
   

   Le résultat doit ressembler à l'exemple ci-dessous.

   NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE
   accounts-db-0                         1/1     Running   0          4m7s    10.96.4.4    regional-cluster-1-default-pool-node2
   balancereader-7dc7d9ff57-lv4z7        1/1     Running   0          4m7s    10.96.1.5    regional-cluster-1-default-pool-node1
   contacts-7ddc76d94-wxvg5              1/1     Running   0          4m7s    10.96.6.11   regional-cluster-1-default-pool-node3
   frontend-747b84bff4-gvktl             1/1     Running   0          4m7s    10.96.1.4    regional-cluster-1-default-pool-node1
   ledger-db-0                           1/1     Running   0          4m7s    10.96.4.5    regional-cluster-1-default-pool-node2
   ledger-db-1                           1/1     Running   0          3m50s   10.96.0.13   regional-cluster-1-default-pool-node5
   ledgerwriter-f6cc7889d-4hqbm          1/1     Running   0          4m6s    10.96.0.12   regional-cluster-1-default-pool-node5
   loadgenerator-57d4cb57cc-fmq52        1/1     Running   0          4m6s    10.96.4.6    regional-cluster-1-default-pool-node2
   transactionhistory-5dd7c7fd77-72zpx   1/1     Running   0          4m6s    10.96.6.12   regional-cluster-1-default-pool-node3
   userservice-cd5ddb4bb-b7862           1/1     Running   0          4m6s    10.96.1.6    regional-cluster-1-default-pool-node1
   

2. Associez les pods répertoriés dans la sortie précédente à la zone du nœud :

   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Le résultat doit ressembler à l'exemple ci-dessous.

   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node1   asia-southeast1-b   10.148.0.41
   regional-cluster-1-default-pool-node2   asia-southeast1-b   10.148.0.42
   regional-cluster-1-default-pool-node3   asia-southeast1-a   10.148.0.37
   regional-cluster-1-default-pool-node4   asia-southeast1-a   10.148.0.38
   regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.40
   regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.39
   

   Dans l'exemple de résultat précédent, les pods d'interface sont situés dans regional-cluster-1-default-pool-node1, dans la zone asia-southeast1-b.

   À l'étape suivante, vous tracez tous les nœuds de la zone asia-southeast1-b, qui dans cet exemple sont regional-cluster-1-default-pool-node1 et regional-cluster-1-default-pool-node2.

3. Marquer comme non ordonnançables et drainer les nœuds cibles dans l'une des zones. Dans cet exemple, il s'agit des deux nœuds dans asia-southeast1-b :

   kubectl drain regional-cluster-1-default-pool-node1 \
       --delete-emptydir-data --ignore-daemonsets
   
   kubectl drain regional-cluster-1-default-pool-node2 \
       --delete-emptydir-data --ignore-daemonsets
   

   Cette commande marque les nœuds comme non ordonnançables et simule des défaillances des nœuds. Kubernetes replanifie les pods sur d'autres nœuds dans les zones opérationnelles.

4. Découvrez où les nouveaux pods d'interface et autres pods d'exemple Cymbal Bank qui s'exécutaient précédemment sur le nœud dans la zone de défaillance sont désormais reprogrammés :

   kubectl get po -o wide
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Le résultat doit ressembler à l'exemple ci-dessous.

   NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE
   accounts-db-0                         1/1     Running   0          4m7s    10.96.4.4    regional-cluster-1-default-pool-node4
   balancereader-7dc7d9ff57-lv4z7        1/1     Running   0          4m7s    10.96.1.5    regional-cluster-1-default-pool-node6
   contacts-7ddc76d94-wxvg5              1/1     Running   0          4m7s    10.96.6.11   regional-cluster-1-default-pool-node3
   frontend-747b84bff4-gvktl             1/1     Running   0          4m7s    10.96.1.4    regional-cluster-1-default-pool-node3
   ledger-db-0                           1/1     Running   0          4m7s    10.96.4.5    regional-cluster-1-default-pool-node6
   ledger-db-1                           1/1     Running   0          3m50s   10.96.0.13   regional-cluster-1-default-pool-node5
   ledgerwriter-f6cc7889d-4hqbm          1/1     Running   0          4m6s    10.96.0.12   regional-cluster-1-default-pool-node5
   loadgenerator-57d4cb57cc-fmq52        1/1     Running   0          4m6s    10.96.4.6    regional-cluster-1-default-pool-node4
   transactionhistory-5dd7c7fd77-72zpx   1/1     Running   0          4m6s    10.96.6.12   regional-cluster-1-default-pool-node3
   userservice-cd5ddb4bb-b7862           1/1     Running   0          4m6s    10.96.1.6    regional-cluster-1-default-pool-node3
   
   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node3   asia-southeast1-a   10.148.0.37
   regional-cluster-1-default-pool-node4   asia-southeast1-a   10.148.0.38
   regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.40
   regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.39
   

   Dans cet exemple de résultat, aucun pod d'exemple Cymbal Bank n'est exécuté sur des nœuds marqués comme non ordonnançables, et tous les pods ne s'exécutent désormais que dans les deux autres zones.

   Les budgets d'interruption de pod (PDB) sur les nœuds peuvent bloquer le drainage des nœuds. Évaluez les stratégies PDB avant de marquer comme non ordonnaçables et de drainer les nœuds. Pour en savoir plus sur le budget d'interruption de pod (PDB) et sa relation avec la gestion des interruptions, découvrez comment garantir la fiabilité et la disponibilité de votre cluster GKE.

   Remarque : Après avoir simulé la défaillance, vous pouvez utiliser kubectl uncordon pour autoriser à nouveau la planification des pods sur les nœuds.

Effectuer un nettoyage

Pour éviter que les ressources utilisées dans ce tutoriel soient facturées sur votre compte Google Cloud, procédez comme suit :

Supprimer le projet

Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.

Attention : La suppression d'un projet aura les effets suivants :

• Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches de ce document, lorsque vous le supprimez, vous supprimez également tout autre travail effectué dans le projet.
• Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

1. Dans la console Google Cloud, accédez à la page Gérer les ressources.

   Accéder à la page Gérer les ressources

2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Étapes suivantes

• Découvrez comment simuler une défaillance de zone pour un groupe d'instances géré (MIG) régional.
• Découvrez la reprise après sinistre (DR) sur Google Cloud.
• Configurez la haute disponibilité PostgreSQL sur plusieurs zones.
• Considérations relatives au budget d'interruptions de pods.
• Apprenez-en plus sur les disques persistants zonaux et régionaux.
• Découvrez comment exécuter des bases de données à haute disponibilité dans GKE.
• Découvrez les bonnes pratiques de reprise après sinistre dans Google Cloud.
• Apprenez-en plus sur le service de Sauvegarde pour GKE.