Comprendre l'impact des défaillances dans GKE sur une solution Bare Metal

GKE sur Bare Metal est conçu pour limiter la portée des défaillances et donner la priorité aux fonctionnalités essentielles à la continuité de l'activité. Ce document explique en quoi les fonctionnalités de vos clusters sont affectées en cas de défaillance. Ces informations peuvent vous aider à prioriser les domaines à dépanner en cas de problème.

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Les fonctionnalités de base de GKE sur Bare Metal incluent les catégories suivantes:

  • Exécuter des charges de travail: les charges de travail existantes peuvent continuer à s'exécuter. Il s'agit de la considération la plus importante pour maintenir la continuité des activités. Même si votre cluster rencontre un problème, les charges de travail existantes peuvent continuer à s'exécuter sans interruption.
  • Gérer les charges de travail: vous pouvez créer, mettre à jour et supprimer des charges de travail. Il s'agit du deuxième élément le plus important à prendre en compte pour faire évoluer des charges de travail lorsque le trafic augmente, même en cas de problème pour le cluster.
  • Gérer des clusters d'utilisateur: vous pouvez gérer les nœuds, mettre à jour, mettre à niveau et supprimer des clusters d'utilisateur. Ce point est moins important que les considérations relatives au cycle de vie de l'application. Si de la capacité est disponible sur les nœuds existants, l'impossibilité de modifier les clusters d'utilisateur n'affecte pas les charges de travail des utilisateurs.
  • Gérer les clusters d'administrateur: vous pouvez mettre à jour et mettre à niveau le cluster d'administrateur.
    • Pour les déploiements qui utilisent des clusters d'administrateur et d'utilisateur distincts, il s'agit de la considération la moins importante, car le cluster d'administrateur n'héberge aucune charge de travail utilisateur. En cas de problème avec votre cluster d'administrateur, les charges de travail de votre application sur d'autres clusters continuent de s'exécuter sans interruption.
    • Si vous utilisez d'autres modèles de déploiement, tels que des modèles hybrides ou autonomes, le cluster d'administrateur exécute les charges de travail de l'application. Si le cluster d'administrateur rencontre un problème et que le plan de contrôle est arrêté, vous ne pouvez pas non plus gérer les charges de travail de l'application ni les composants du cluster d'utilisateur.

Les sections suivantes utilisent ces catégories de fonctionnalités de base pour décrire l'impact de types spécifiques de scénarios de défaillance. En cas de perturbation dans le cadre d'un scénario de défaillance, la durée (ordre) de l'interruption est également notée, dans la mesure du possible.

Défaillances de nœuds

Un nœud dans GKE sur Bare Metal peut cesser de fonctionner ou devenir inaccessible sur le réseau. Selon le pool de nœuds et le cluster dont fait partie la machine défaillante, il existe plusieurs modes de défaillance.

Nœud du plan de contrôle

Le tableau suivant décrit le comportement des nœuds faisant partie du plan de contrôle dans GKE sur une solution Bare Metal:

Exécuter des charges de travail Gérer les charges de travail Gérer les clusters d'utilisateur Gérer les clusters d'administrateur
Perturbation (durée) Aucune interruption Perturbation possible (inconnue) Perturbation possible (inconnue) Perturbation possible (inconnue)
Explication Si la défaillance d'un nœud affecte le nœud de plan de contrôle unique dans un cluster d'utilisateur à disponibilité élevée ou si elle affecte au moins la moitié des nœuds du plan de contrôle dans un cluster d'utilisateur haute disponibilité, il y a une perturbation. Le quorum du plan de contrôle du cluster d'utilisateur est perdu. Si la défaillance d'un nœud affecte le nœud de plan de contrôle unique dans un cluster d'administrateur standard ou si au moins la moitié des nœuds du plan de contrôle d'un cluster d'administrateur haute disponibilité sont affectés, une interruption se produit. Le quorum du plan de contrôle du cluster d'administrateur est perdu. Si la défaillance d'un nœud affecte le nœud de plan de contrôle unique dans un cluster d'administrateur standard ou si au moins la moitié des nœuds du plan de contrôle d'un cluster d'administrateur haute disponibilité sont affectés, une interruption se produit. Le quorum du plan de contrôle du cluster d'administrateur est perdu.
Récupération Pour en savoir plus, découvrez comment récupérer le quorum. Pour en savoir plus, découvrez comment récupérer le quorum. Pour en savoir plus, découvrez comment récupérer le quorum.
Prévention Déployez des clusters d'utilisateur en mode haute disponibilité pour minimiser les risques de perturbation. Déployez des clusters d'administrateur en mode haute disponibilité pour minimiser les risques de perturbation. Déployez des clusters d'administrateur en mode haute disponibilité pour minimiser les risques de perturbation.

Nœud d'équilibreur de charge

Le tableau suivant décrit le comportement des nœuds qui hébergent les équilibreurs de charge dans GKE sur une solution Bare Metal. Ces conseils ne s'appliquent qu'aux équilibreurs de charge groupés en mode couche 2. Pour l'équilibrage de charge manuel, consultez les modes de défaillance de vos équilibreurs de charge externes:

Exécuter des charges de travail Gérer les charges de travail Gérer les clusters d'utilisateur Gérer les clusters d'administrateur
Perturbation (durée) Perturbation possible (variable) Perturbation possible (variable) Perturbation possible (variable) Perturbation possible (variable)
Explication Si les charges de travail externes s'appuient sur l'équilibreur de charge du plan de données pour communiquer avec les charges de travail du cluster et que vous n'avez qu'un seul nœud d'équilibreur de charge, cela entraîne des interruptions. L'adresse IP virtuelle du plan de contrôle du cluster d'utilisateur réside sur un nœud d'équilibreur de charge. Si le pool de nœuds de l'équilibreur de charge du cluster d'utilisateur n'est pas à haute disponibilité, des interruptions se produisent. L'adresse IP virtuelle du plan de contrôle du cluster d'administrateur réside sur un nœud d'équilibreur de charge. Si le pool de nœuds de l'équilibreur de charge du cluster d'administrateur n'est pas à haute disponibilité, des interruptions se produisent. L'adresse IP virtuelle du plan de contrôle du cluster d'administrateur réside sur un nœud d'équilibreur de charge. Si le pool de nœuds de l'équilibreur de charge du cluster d'administrateur n'est pas à haute disponibilité, des interruptions se produisent.
Récupération

S'il existe plusieurs nœuds d'équilibreur de charge, le basculement MetalLB se produit en quelques secondes.

Si ce n'est pas le cas, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires.

Avec la haute disponibilité, le basculement est automatique et s'effectue en quelques secondes.

Si la haute disponibilité n'est pas disponible, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires

Avec la haute disponibilité, le basculement est automatique et s'effectue en quelques secondes.

Si ce n'est pas le cas, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires.

Avec la haute disponibilité, le basculement est automatique et s'effectue en quelques secondes.

Si ce n'est pas le cas, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires.

Prévention Pour réduire les risques de perturbations, déployez les pools de nœuds de l'équilibreur de charge en mode haute disponibilité. Pour réduire les risques de perturbations, déployez les pools de nœuds de l'équilibreur de charge en mode haute disponibilité. Pour réduire les risques de perturbations, déployez les pools de nœuds de l'équilibreur de charge en mode haute disponibilité. Pour réduire les risques de perturbations, déployez les pools de nœuds de l'équilibreur de charge en mode haute disponibilité.

Nœud de calcul

Le tableau suivant décrit le comportement des nœuds de calcul dans GKE sur une solution Bare Metal:

Exécuter des charges de travail Gérer les charges de travail Gérer les clusters d'utilisateur Gérer les clusters d'administrateur
Perturbation (durée) Perturbation possible (ordre de secondes) Aucune interruption Aucune interruption Aucune interruption
Explication

Les Pods qui s'exécutent sur le nœud en échec sont interrompues et sont automatiquement reprogrammées sur d'autres nœuds opérationnels avec un délai avant expiration par défaut de l'éviction de 5 minutes.

Si les applications utilisateur disposent d'une capacité de charge de travail libre et sont réparties sur plusieurs nœuds, l'interruption n'est pas observable par les clients qui implémentent les nouvelles tentatives.

Les Pods sont automatiquement redémarrés sur les nœuds sains.

Si le cluster ne dispose pas d'une capacité de secours, l'interruption peut durer jusqu'à ce que de nouveaux nœuds soient ajoutés au cluster.

Récupération Si le cluster ne dispose pas d'une capacité de secours, vous devez déployer davantage de nœuds répartis sur plusieurs zones de défaillance et déplacer les charges de travail ayant échoué vers les nouveaux nœuds.
Prévention

Déployez des nœuds répartis sur plusieurs zones de défaillance.

Déployez des charges de travail avec plusieurs instances répliquées réparties sur plusieurs zones de défaillance afin de minimiser les risques de perturbations.

Défaillance de l'espace de stockage

Le stockage dans GKE sur Bare Metal peut cesser de fonctionner ou devenir inaccessible sur le réseau. Il existe plusieurs modes de défaillance en fonction de l'espace de stockage défaillant.

etcd

Le contenu des répertoires /var/lib/etcd et /var/lib/etcd-events peut être corrompu en cas d'arrêt incorrect du nœud ou de défaillance sous-jacente du stockage. Le tableau suivant décrit le comportement de la fonctionnalité principale en raison d'échecs de etcd:

Exécuter des charges de travail Gérer les charges de travail Gérer les clusters d'utilisateur Gérer les clusters d'administrateur
Perturbation (durée) Aucune interruption Perturbation possible (inconnue) Perturbation possible (inconnue) Perturbation possible (inconnue)
Explication Si les charges de travail existantes ne reposent pas sur le plan de contrôle Kubernetes, elles continuent de fonctionner sans interruption. Si etcd échoue sur un seul cluster d'utilisateur de plan de contrôle ou sur au moins la moitié des nœuds de plan de contrôle d'un cluster d'utilisateur haute disponibilité, cela entraîne des interruptions. Le quorum du plan de contrôle du cluster d'utilisateur est perdu. Si etcd échoue sur un seul cluster d'administrateur de plan de contrôle ou sur au moins la moitié des nœuds de plan de contrôle d'un cluster d'administrateur haute disponibilité, cela entraîne des interruptions. Le quorum du plan de contrôle du cluster d'administrateur est perdu. Si etcd échoue sur un seul cluster d'administrateur de plan de contrôle ou sur au moins la moitié des nœuds de plan de contrôle d'un cluster d'administrateur haute disponibilité, cela entraîne des interruptions. Le quorum du plan de contrôle du cluster d'administrateur est perdu.
Récupération Pour en savoir plus, découvrez comment récupérer le quorum. Pour en savoir plus, découvrez comment récupérer le quorum. Pour en savoir plus, découvrez comment récupérer le quorum.
Prévention Pour réduire les risques de perturbations, déployez les clusters d'utilisateur en mode haute disponibilité. Pour réduire les risques de perturbations, déployez les clusters d'administrateur en mode haute disponibilité. Pour réduire les risques de perturbations, déployez les clusters d'administrateur en mode haute disponibilité.

Application utilisateur PersistentVolume

Le tableau suivant décrit le comportement de la fonctionnalité de base en raison de la défaillance d'un PersistentVolume:

Exécuter des charges de travail Gérer les charges de travail Gérer les clusters d'utilisateur Gérer les clusters d'administrateur
Perturbation (durée) Perturbation possible (inconnue) Aucune interruption Aucune interruption Aucune interruption
Explication Les charges de travail qui utilisent le PersistentVolume are affected. ayant échoué
Récupération
Prévention Pour réduire les risques de perturbations, déployez la charge de travail de l'utilisateur en mode haute disponibilité.

Disque corrompu par Fluent Bit

La corruption d'un disque Fluent Bit n'affecte aucune fonctionnalité de base, mais a une incidence sur la capacité à collecter et à inspecter les journaux dans Google Cloud.

L'événement SIGSEGV peut parfois être observé à partir des journaux de stackdriver-log-forwarder. Cette erreur peut être causée par les journaux mis en mémoire tampon corrompus sur le disque.

Fluent Bit dispose d'un mécanisme pour filtrer et supprimer les morceaux cassés. Cette fonctionnalité est disponible dans la version fluent-bit (v1.8.3) utilisée dans GKE sur Bare Metal.

Sur LoadBalancer IP

Si toutes les adresses IP des pools attribués sont actuellement occupées, les services LoadBalancer nouvellement créés ne peuvent pas acquérir une adresse IP LoadBalancer. Ce scénario a une incidence sur la capacité des clients du service à communiquer avec les services LoadBalancer.

Pour récupérer de cet épuisement des adresses IP, attribuez d'autres adresses IP au pool d'adresses en modifiant la ressource personnalisée du cluster.

Expiration du certificat

GKE sur Bare Metal génère une autorité de certification (CA) autosignée lors du processus d'installation du cluster. L'autorité de certification a un délai d'expiration de 10 ans et est chargée de générer des certificats, qui expirent au bout d'un an. Alternez régulièrement les certificats pour éviter les temps d'arrêt du cluster. Vous pouvez effectuer une rotation des certificats en mettant à niveau votre cluster. Il s'agit de la méthode recommandée. Si vous ne parvenez pas à mettre à niveau votre cluster, vous pouvez effectuer une rotation à la demande des autorités de certification. Pour en savoir plus sur les certificats de cluster, consultez la section Certificats et exigences PKI dans la documentation de Kubernetes.

Si les certificats du cluster ont expiré, ils doivent être renouvelés manuellement.

Exécuter des charges de travail Gérer les charges de travail Gérer les clusters d'utilisateur Gérer les clusters d'administrateur
Perturbation (durée) Aucune interruption Perturbation possible (inconnue) Perturbation possible (inconnue) Perturbation possible (inconnue)
Explication Si les charges de travail des utilisateurs ne communiquent pas avec les composants du plan de contrôle Kubernetes, il n'y aura pas de perturbations. L'expiration des autorités de certification des clusters d'utilisateur entraîne une interruption. L'expiration des autorités de certification des clusters d'administrateur entraîne une interruption. L'expiration des autorités de certification des clusters d'utilisateur entraîne une interruption.
Récupération

Suivez les étapes pour renouveler manuellement les certificats sur le cluster d'utilisateur.

Suivez les étapes pour renouveler manuellement les certificats sur le cluster d'utilisateur.

Suivez les étapes pour renouveler manuellement les certificats sur le cluster d'utilisateur.

Prévention Configurer la surveillance de l'expiration des certificats Vous trouverez un exemple de métrique kubelet_certificate_manager_server_expiration_seconds dans la liste des métriques.

Échecs de mise à niveau

Exécuter des charges de travail Gérer les charges de travail Gérer les clusters d'utilisateur Gérer les clusters d'administrateur
Perturbation (durée) Aucune interruption Aucune interruption Perturbation possible (inconnue) Perturbation possible (inconnue)
Explication

Si la mise à niveau échoue sur le plan de contrôle du cluster d'utilisateur, il n'y a AUCUNE interruption des charges de travail existantes.

Si la mise à niveau échoue sur un nœud de calcul particulier, les charges de travail sur ce nœud sont drainées et déplacées vers d'autres nœuds opérationnels s'ils disposent d'une capacité supplémentaire.

La mise à niveau s'arrête si l'un des nœuds du plan de contrôle n'est pas mis à niveau. Si le cluster d'utilisateur est à haute disponibilité, le cluster fonctionne toujours en cas d'échec de la mise à niveau. Si la mise à niveau échoue sur le plan de contrôle du cluster d'administrateur, cela entraîne des interruptions jusqu'à la fin de l'opération. Si la mise à niveau échoue sur le plan de contrôle du cluster d'administrateur, cela entraîne des interruptions jusqu'à la fin de l'opération.
Récupération Vous pouvez réessayer la mise à niveau. Pour en savoir plus, découvrez comment diagnostiquer les problèmes de mise à niveau et reprendre. Vous pouvez réessayer la mise à niveau. Pour en savoir plus, découvrez comment diagnostiquer les problèmes de mise à niveau et reprendre.
Prévention Pour en savoir plus, découvrez comment créer une sauvegarde avant la mise à niveau. Pour en savoir plus, découvrez comment créer une sauvegarde avant la mise à niveau.

Étapes suivantes