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 :
- Créer un cluster et déployer un exemple d'application
- Surveiller avec Google Cloud Managed Service pour Prometheus
- Effectuer le scaling des charges de travail
- 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.
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.4Vérifiez la distribution des services de l'exemple d'application Cymbal Bank sur vos nœuds de cluster GKE Enterprise :
kubectl get pods -o wideL'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-daemonsetsCette 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.
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.4Le 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 wideL'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-node1Examinez l'
AGEdes 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éé.
- Dans la console Google Cloud, accédez à la page Gérer les ressources.
- Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
- Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.
É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.