Parcours de formation : Applications évolutives - Simuler une interruption


Cet ensemble de tutoriels est destiné aux administrateurs et aux opérateurs informatiques qui souhaitent déployer, exécuter et gérer des environnements d'applications modernes exécutés sur l'édition Enterprise de Google Kubernetes Engine (GKE). Au fur et à mesure que vous progresserez dans cette série de tutoriels, vous allez apprendre à configurer la surveillance et les alertes, à effectuer le scaling des charges de travail et à simuler des défaillances, le tout en utilisant l'exemple d'application de microservices Cymbal Bank :

  1. Créer un cluster et déployer un exemple d'application
  2. Surveiller avec Google Cloud Managed Service pour Prometheus
  3. Effectuer le scaling des charges de travail
  4. Simuler une défaillance (ce tutoriel)

Présentation et objectifs

Les applications doivent pouvoir tolérer les pannes et les défaillances. Cela permet aux utilisateurs de continuer à accéder à vos applications même en cas de problème. L'exemple d'application Cymbal Bank est conçu de façon à pouvoir gérer les défaillances et continuer à s'exécuter sans que vous ayez besoin de résoudre les problèmes. Pour assurer cette résilience, les clusters régionaux GKE répartissent les nœuds de calcul entre les zones, et le contrôleur Kubernetes répond automatiquement aux problèmes de service au sein du cluster.

Dans ce tutoriel, vous allez apprendre à simuler une défaillance dans Google Cloud et observer comment les services d'application de votre cluster Google Kubernetes Engine (GKE) édition Enterprise réagissent. Vous allez apprendre à effectuer les tâches suivantes :

  • Examiner la distribution des nœuds et des services.
  • Simuler une défaillance de nœud ou de zone.
  • Vérifier que les services continuent de s'exécuter sur les nœuds restants.

Coûts

L'activation de GKE Enterprise et le déploiement de l'exemple d'application Cymbal Bank pour cette série de tutoriels entraînent des frais par cluster pour GKE Enterprise sur Google Cloud, comme indiqué sur notre Page des tarifs, jusqu'à ce que vous désactiviez GKE Enterprise ou que vous supprimiez le projet.

Vous êtes également responsable des autres coûts Google Cloud engendrés par l'exécution de l'exemple d'application Cymbal Bank, tels que les frais pour les VM Compute Engine.

Avant de commencer

Pour apprendre à simuler une défaillance, vous devez suivre le premier tutoriel afin de créer un cluster GKE qui utilise Autopilot et déployer l'exemple d'application basée sur des microservices Cymbal Bank.

Nous vous recommandons de suivre cette série de tutoriels pour Cymbal Bank dans l'ordre. Au fil de votre progression dans les tutoriels, vous apprendrez de nouvelles compétences et utilisez d'autres produits et services Google Cloud.

Examiner la distribution des nœuds et des services

Dans Google Cloud, une région est un emplacement géographique spécifique au sein duquel vous pouvez héberger vos ressources. Les régions comportent trois zones ou plus. Par exemple, la région us-central1 est une région du Midwest des États-Unis qui comporte plusieurs zones, telles queus-central1-a, us-central1-b et us-central1-c. Les zones d'une même région bénéficient entre elles de connexions réseau à haut débit et à faible latence.

Pour déployer des applications tolérantes aux pannes et à haute disponibilité, Google recommande de déployer les applications sur plusieurs zones et régions. Cette approche permet de protéger les applications en cas de défaillance inattendue d'un composant, y compris dans une zone ou une région donnée.

Lorsque vous avez créé votre cluster GKE Enterprise dans le premier tutoriel, certaines valeurs de configuration par défaut ont été utilisées. Par défaut, un cluster GKE Enterprise qui utilise Autopilot crée et exécute des nœuds qui s'étendent sur plusieurs zones de la région que vous spécifiez. Cette approche signifie que l'exemple d'application Cymbal Bank est déjà déployé dans plusieurs zones, ce qui permet de se protéger contre les défaillances inattendues.

  1. Vérifiez la distribution des nœuds dans votre cluster GKE Enterprise :

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

    Le résultat est semblable à l'exemple de résultat suivant, qui montre que les nœuds sont répartis dans les trois zones de la région :

    NAME                         ZONE            INT_IP
    scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
    scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
    scalable-apps-pool-2-node2   us-central1-a   10.148.0.8
    scalable-apps-pool-2-node1   us-central1-a   10.148.0.9
    scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
    scalable-apps-pool-2-node4   us-central1-b   10.148.0.4
    
  2. Vérifiez la distribution des services de l'exemple d'application Cymbal Bank sur vos nœuds de cluster GKE Enterprise :

    kubectl get pods -o wide
    

    L'exemple de résultat suivant montre que les services sont distribués entre les nœuds du cluster. Le résultat de l'étape précédente, qui consistait à vérifier la répartition des nœuds, montre que les services s'exécutent dans les différentes zones de la région :

    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
    accounts-db-0                         1/1     Running   0          6m30s   10.28.1.5   scalable-apps-pool-2-node3
    balancereader-7dc7d9ff57-shwg5        1/1     Running   0          6m30s   10.28.5.6   scalable-apps-pool-2-node1
    contacts-7ddc76d94-qv4x5              1/1     Running   0          6m29s   10.28.4.6   scalable-apps-pool-2-node2
    frontend-747b84bff4-xvjxq             1/1     Running   0          6m29s   10.28.3.6   scalable-apps-pool-2-node6
    ledger-db-0                           1/1     Running   0          6m29s   10.28.5.7   scalable-apps-pool-2-node1
    ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          6m29s   10.28.1.6   scalable-apps-pool-2-node3
    loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          6m29s   10.28.4.7   scalable-apps-pool-2-node2
    transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          6m29s   10.28.3.7   scalable-apps-pool-2-node6
    userservice-cd5ddb4bb-zfr2g           1/1     Running   0          6m28s   10.28.5.8   scalable-apps-pool-2-node1
    

Simuler une interruption

Google conçoit les zones de façon à minimiser le risque de défaillances corrélées liées à des pannes d'infrastructure matérielle, telles que l'alimentation, le refroidissement ou la mise en réseau. Cependant, des problèmes inattendus peuvent survenir. Si un nœud ou une zone devient indisponible, vous souhaitez que les services continuent de s'exécuter sur d'autres nœuds ou dans d'autres zones de la même région.

Le contrôleur Kubernetes surveille l'état des nœuds, des services et des déploiements de votre cluster. En cas de panne inattendue, le contrôleur redémarre les ressources concernées et le trafic est acheminé vers les nœuds fonctionnels.

Pour simuler une interruption dans ce tutoriel, vous devez marquer les nœuds comme non ordonnançables et les drainer dans l'une de vos zones. Cette approche simule ce qui se passe en cas de défaillance d'un nœud ou lorsqu'une zone entière rencontre un problème. Le contrôleur Kubernetes doit reconnaître que certains services ne sont plus disponibles et doivent être redémarrés sur des nœuds situés dans d'autres zones :

  • Marquez les nœuds comme non ordonnançables et drainez-les dans l'une des zones. L'exemple suivant cible les deux nœuds dans us-central1-a :

    kubectl drain scalable-apps-pool-2-node1 \
        --delete-emptydir-data --ignore-daemonsets
    
    kubectl drain scalable-apps-pool-2-node2 \
        --delete-emptydir-data --ignore-daemonsets
    

    Cette commande marque les nœuds comme non programmables afin que les pods ne puissent plus s'exécuter sur ces nœuds. Kubernetes reprogramme les pods sur d'autres nœuds dans les zones opérationnelles.

Vérifier la réponse à une défaillance simulée

Dans un tutoriel précédent de cette série, vous avez appris à configurer l'instance Prometheus gérée pour votre cluster GKE Enterprise afin de surveiller certains services et générer des alertes en cas de problème. Si des pods s'exécutaient sur des nœuds dans la zone dans laquelle vous avez simulé une panne, vous recevez des messages de notification Slack à partir des alertes générées par Prometheus. Ce comportement montre comment créer un environnement d'application moderne qui surveille l'état de vos déploiements, vous avertit en cas de problème et peut s'ajuster automatiquement en cas de modification de la charge ou de défaillances.

Votre cluster GKE Enterprise répond automatiquement à la panne simulée. Tous les services sur les nœuds concernés sont redémarrés sur les nœuds restants.

  1. Vérifiez à nouveau la distribution des nœuds dans votre cluster GKE Enterprise :

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

    Le résultat est semblable à l'exemple de résultat suivant, qui montre que les nœuds ne sont désormais répartis que sur deux des zones de la région :

    NAME                         ZONE            INT_IP
    scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
    scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
    scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
    scalable-apps-pool-2-node4   us-central1-b   10.148.0.4
    
  2. Le contrôleur Kubernetes reconnaît que deux des nœuds ne sont plus disponibles et redistribue les services entre les nœuds disponibles. Tous les services devraient continuer à fonctionner.

    Vérifiez la distribution des services de l'exemple d'application Cymbal Bank sur vos nœuds de cluster GKE Enterprise :

    kubectl get pods -o wide
    

    L'exemple de résultat suivant montre que les services sont distribués entre les nœuds restants du cluster. Le résultat de l'étape précédente, qui consistait à vérifier la répartition des nœuds, montre que les services ne s'exécutent désormais que dans deux zones de la région :

    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
    accounts-db-0                         1/1     Running   0          28m     10.28.1.5   scalable-apps-pool-2-node3
    balancereader-7dc7d9ff57-shwg5        1/1     Running   0          9m21s   10.28.5.6   scalable-apps-pool-2-node5
    contacts-7ddc76d94-qv4x5              1/1     Running   0          9m20s   10.28.4.6   scalable-apps-pool-2-node4
    frontend-747b84bff4-xvjxq             1/1     Running   0          28m     10.28.3.6   scalable-apps-pool-2-node6
    ledger-db-0                           1/1     Running   0          9m24s   10.28.5.7   scalable-apps-pool-2-node3
    ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   scalable-apps-pool-2-node3
    loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          9m21s   10.28.4.7   scalable-apps-pool-2-node5
    transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          28m     10.28.3.7   scalable-apps-pool-2-node6
    userservice-cd5ddb4bb-zfr2g           1/1     Running   0          9m20s   10.28.5.8   scalable-apps-pool-2-node1
    
  3. Examinez l'AGE des services. Dans l'exemple de résultat précédent, certains services ont un âge plus jeune que d'autres dans l'exemple d'application Cymbal Bank. Ces services plus jeunes s'exécutaient précédemment sur l'un des nœuds où vous avez simulé une défaillance. Le contrôleur Kubernetes a redémarré ces services sur les nœuds disponibles.

Dans un scénario réel, il faudrait résoudre le problème ou attendre que le problème de maintenance sous-jacent soit résolu. Si vous avez configuré Prometheus pour envoyer des messages Slack en fonction d'alertes, ces notifications vous sont transmises. Vous pouvez également répéter les étapes du tutoriel précédent pour effectuer le scaling des ressources afin de voir comment votre cluster GKE Enterprise réagit à une charge accrue lorsque seules deux zones sont disponibles dans la région. Le cluster doit effectuer un scaling à la hausse avec les deux zones restantes disponibles.

Effectuer un nettoyage

Pour éviter que les ressources utilisées dans ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet que vous avez créé.

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Étapes suivantes

Avant de commencer à créer votre propre environnement de cluster GKE Enterprise semblable à celui que vous avez découvert dans cette série de tutoriels, examinez certaines considérations relatives à la production.