Google Distributed Cloud est conçu pour limiter l'étendue des défaillances et donner la priorité aux fonctionnalités essentielles à la continuité des activités. Ce document explique l'impact sur les fonctionnalités de vos clusters en cas de défaillance. Ces informations peuvent vous aider à hiérarchiser les domaines à résoudre 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 Google Distributed Cloud 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 l'élément le plus important à prendre en compte pour assurer la continuité de l'activité. 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 aspect le plus important pour effectuer le scaling des charges de travail lorsque le trafic augmente, même si le cluster présente un problème.
- 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 liées au cycle de vie de l'application. S'il y a de la capacité disponible sur les nœuds existants, l'impossibilité de modifier des clusters d'utilisateur n'affecte pas les charges de travail des utilisateurs.
- Gérer les clusters d'administrateur: vous pouvez mettre à jour le cluster d'administrateur.
- Pour les déploiements qui utilisent des clusters d'administrateur et d'utilisateur distincts, il s'agit de l'élément le moins important à prendre en compte, car le cluster d'administrateur n'héberge aucune charge de travail utilisateur. Si votre cluster d'administrateur rencontre un problème, 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 les 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 indisponible, 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 de scénarios de défaillance spécifiques. En cas de perturbation dans un scénario de défaillance, la durée (l'ordre) de l'interruption est également indiquée, lorsque cela est possible.
Défaillances de nœuds
Un nœud dans Google Distributed Cloud 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 qui font partie du plan de contrôle dans Google Distributed Cloud:
| Exécuter des charges de travail | Gérer les charges de travail | Gérer les clusters d'utilisateur | Gérer les clusters d'administrateur | |
|---|---|---|---|---|
| Interruption (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 du 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é, une interruption se produit. 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 du plan de contrôle unique dans un cluster d'administrateur standard, ou si elle affecte au moins la moitié des nœuds du plan de contrôle dans un cluster d'administrateur haute disponibilité, 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 du plan de contrôle unique dans un cluster d'administrateur standard, ou si elle affecte au moins la moitié des nœuds du plan de contrôle dans un cluster d'administrateur haute disponibilité, 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 effectuer une récupération après une perte de quorum. | Pour en savoir plus, découvrez comment effectuer une récupération après une perte de quorum. | Pour en savoir plus, découvrez comment effectuer une récupération après une perte de 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 Google Distributed Cloud. Ces conseils ne s'appliquent qu'aux équilibreurs de charge groupés en mode de 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 | |
|---|---|---|---|---|
| Interruption (durée) | Perturbation possible (varie) | Perturbation possible (varie) | Perturbation possible (varie) | Perturbation possible (varie) |
| Explication | Si les charges de travail externes dépendent de l'équilibreur de charge du plan de données pour communiquer avec les charges de travail du cluster et que vous ne disposez que d'un seul nœud d'équilibrage de charge, une interruption se produit. | L'adresse IP virtuelle du plan de contrôle du cluster d'utilisateur réside sur un nœud de l'équilibreur de charge. Si le pool de nœuds de l'équilibreur de charge du cluster d'utilisateur n'est pas haute disponibilité, une interruption se produit. | L'adresse IP virtuelle du plan de contrôle du cluster d'administrateur réside sur un nœud de l'équilibreur de charge. Si le pool de nœuds de l'équilibreur de charge du cluster d'administrateur n'est pas haute disponibilité, une interruption se produit. | L'adresse IP virtuelle du plan de contrôle du cluster d'administrateur réside sur un nœud de l'équilibreur de charge. Si le pool de nœuds de l'équilibreur de charge du cluster d'administrateur n'est pas haute disponibilité, une interruption se produit. |
| 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. |
Pour une haute disponibilité, le basculement est automatique et se fait en quelques secondes. Si la haute disponibilité n'est pas disponible, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires |
Pour une haute disponibilité, le basculement est automatique et se fait en quelques secondes. Si ce n'est pas le cas, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires. |
Pour une haute disponibilité, le basculement est automatique et se fait 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 minimiser les risques de perturbation, déployez les pools de nœuds de l'équilibreur de charge en mode haute disponibilité. | Pour minimiser les risques de perturbation, déployez les pools de nœuds de l'équilibreur de charge en mode haute disponibilité. | Pour minimiser les risques de perturbation, déployez les pools de nœuds de l'équilibreur de charge en mode haute disponibilité. | Pour minimiser les risques de perturbation, 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 Google Distributed Cloud:
| Exécuter des charges de travail | Gérer les charges de travail | Gérer les clusters d'utilisateur | Gérer les clusters d'administrateur | |
|---|---|---|---|---|
| Interruption (durée) | Perturbation possible (de l'ordre de quelques secondes) | Aucune interruption | Aucune interruption | Aucune interruption |
| Explication | Les Si les applications utilisateur ont une capacité de charge de travail de secours et sont réparties sur plusieurs nœuds, l'interruption n'est pas observable par les clients qui implémentent les nouvelles tentatives. Les |
— | — | — |
| Récupération | Si le cluster ne dispose pas de 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 comportant plusieurs instances répliquées réparties sur plusieurs zones de défaillance afin de minimiser les risques de perturbation. |
— | — | — |
Défaillance de l'espace de stockage
Le stockage dans Google Distributed Cloud peut cesser de fonctionner ou devenir inaccessible sur le réseau. En fonction du stockage défaillant, il existe plusieurs modes de défaillance.
etcd
Le contenu des répertoires /var/lib/etcd et /var/lib/etcd-events peut être corrompu en cas d'arrêt inopiné du nœud ou de défaillance sous-jacente du stockage. Le tableau suivant décrit le comportement de la fonctionnalité de base 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 | |
|---|---|---|---|---|
| Interruption (durée) | Aucune interruption | Perturbation possible (inconnue) | Perturbation possible (inconnue) | Perturbation possible (inconnue) |
| Explication | Si les charges de travail existantes ne dépendent pas du plan de contrôle Kubernetes, elles continuent à 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 du plan de contrôle dans un cluster d'utilisateur à haute disponibilité, une interruption se produit. 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 du plan de contrôle dans un cluster d'administrateur haute disponibilité, une interruption se produit. 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 du plan de contrôle dans un cluster d'administrateur haute disponibilité, 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 effectuer une récupération après une perte de quorum. | Pour en savoir plus, découvrez comment effectuer une récupération après une perte de quorum. | Pour en savoir plus, découvrez comment effectuer une récupération après une perte de quorum. |
| Prévention | — | Pour minimiser les risques de perturbation, déployez les clusters d'utilisateur en mode haute disponibilité. | Pour minimiser les risques de perturbation, déployez les clusters d'administrateur en mode haute disponibilité. | Pour minimiser les risques de perturbation, 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 cas de 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 | |
|---|---|---|---|---|
| Interruption (durée) | Perturbation possible (inconnue) | Aucune interruption | Aucune interruption | Aucune interruption |
| Explication | Charges de travail qui utilisent la classe PersistentVolume ayant échoué |
— | — | — |
| Récupération | — | — | — | — |
| Prévention | Pour minimiser les risques d'interruption, déployez la charge de travail de l'utilisateur en mode haute disponibilité. | — | — | — |
Disque corrompu par le bit Fluent
La corruption d'un disque Fluent Bit n'affecte aucune fonctionnalité de base, mais affecte la capacité à collecter et à inspecter les journaux sur Google Cloud.
L'événement SIGSEGV peut parfois être observé à partir des journaux de stackdriver-log-forwarder. Cette erreur peut être causée par des journaux corrompus mis en mémoire tampon sur le disque.
Fluent Bit dispose d'un mécanisme pour filtrer et supprimer les fragments rompus. Cette fonctionnalité est disponible avec la version fluent-bit (v1.8.3) utilisée dans Google Distributed Cloud.
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 d'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
Google Distributed Cloud génère une autorité de certification autosignée pendant le 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 alterner les certificats en mettant à niveau votre cluster. La méthode recommandée est la méthode recommandée. Si vous ne parvenez pas à mettre à niveau votre cluster, vous pouvez effectuer une rotation des autorités de certification à la demande. Pour en savoir plus sur les certificats de cluster, consultez la page Certificats PKI et exigences dans la documentation de Kubernetes.
Si les certificats de cluster ont expiré, vous devez les renouveler 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 | |
|---|---|---|---|---|
| Interruption (durée) | Aucune interruption | Perturbation possible (inconnue) | Perturbation possible (inconnue) | Perturbation possible (inconnue) |
| Explication | Si les charges de travail utilisateur ne communiquent pas avec les composants du plan de contrôle Kubernetes, il n'y aura pas d'interruptions. | Si les autorités de certification des clusters d'utilisateur expirent, il y aura une interruption. | Si les autorités de certification des clusters d'administrateur expirent, cela provoquera une interruption. | Si les autorités de certification des clusters d'utilisateur expirent, cela 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 | Configurez 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 | |
|---|---|---|---|---|
| Interruption (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, les charges de travail existantes ne sont PAS interrompues. 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 si les nœuds sains offrent une capacité supplémentaire. |
La mise à niveau s'arrêtera si l'un des nœuds du plan de contrôle échoue. Le cluster fonctionne toujours si la mise à niveau échoue si le cluster d'utilisateur est haute disponibilité. | Si la mise à niveau échoue sur le plan de contrôle du cluster d'administrateur, une interruption se produit jusqu'à ce qu'elle soit terminée. | Si la mise à niveau échoue sur le plan de contrôle du cluster d'administrateur, une interruption se produit jusqu'à ce qu'elle soit terminée. |
| Récupération | — | — | La mise à niveau peut faire l'objet d'une nouvelle tentative. Pour en savoir plus, découvrez comment diagnostiquer les problèmes et reprendre la mise à niveau. | La mise à niveau peut faire l'objet d'une nouvelle tentative. Pour en savoir plus, découvrez comment diagnostiquer les problèmes et reprendre la mise à niveau. |
| 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
Pour en savoir plus sur les problèmes connus liés aux produits et sur les solutions de contournement, consultez la page Problèmes connus dans Google Distributed Cloud.
- Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.