Google Distributed Cloud est conçu pour limiter la portée des défaillances et donner la priorité aux fonctionnalités essentielles à la continuité des opérations. Ce document explique l'impact d'une défaillance sur le fonctionnement de vos clusters. Ces informations peuvent vous aider à hiérarchiser les problèmes à résoudre en cas de problème.
Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.Les principales fonctionnalités de Google Distributed Cloud sont les suivantes :
- Exécuter les charges de travail : les charges de travail existantes peuvent continuer à s'exécuter. Il s'agit du critère le plus important pour maintenir la continuité des opérations. 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 pour faire évoluer les charges de travail lorsque le trafic augmente, même si le cluster présente un problème.
- Gérer les clusters d'utilisateur : vous pouvez gérer les nœuds, mettre à jour, mettre à niveau et supprimer des clusters d'utilisateur. Cette étape est moins importante que les considérations relatives au cycle de vie de l'application. Si les nœuds existants disposent d'une capacité suffisante, 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, ce point est le moins important, car le cluster d'administrateur n'héberge aucune charge de travail d'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 hors service, vous ne pouvez pas non plus gérer les charges de travail des applications 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. Lorsqu'une perturbation survient dans le cadre d'un scénario de défaillance, la durée (ordre) de la perturbation est également indiquée, lorsque cela est possible.
Échecs de nœuds
Un nœud de Google Distributed Cloud peut cesser de fonctionner ou devenir inaccessible sur le réseau. En fonction du pool de nœuds et du 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 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 | Interruption possible (inconnue) | Interruption possible (inconnu) | Interruption 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 standard, ou si elle affecte au moins la moitié des nœuds du plan de contrôle d'un cluster d'utilisateur à haute disponibilité, cela entraîne une interruption. Le quorum du plan de contrôle du cluster d'utilisateur est perdu. | Si la défaillance du 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 d'un cluster d'administrateur à haute disponibilité, cela entraîne une interruption. Le quorum du plan de contrôle du cluster d'administrateur est perdu. | Si la défaillance du nœud affecte le seul nœud de plan de contrôle d'un cluster d'administrateur standard ou si elle affecte au moins la moitié des nœuds de plan de contrôle d'un cluster d'administrateur haute disponibilité, cela entraîne une interruption. Le quorum du plan de contrôle du cluster d'administrateur est perdu. |
| Récupération | — | Pour en savoir plus, consultez la section Effectuer une récupération après une perte de quorum. | Pour en savoir plus, consultez la section Effectuer une récupération après une perte de quorum. | Pour en savoir plus, consultez la section Effectuer une récupération après une perte de quorum. |
| Prévention | — | Déployez des clusters d'utilisateurs en mode HA pour réduire le risque d'interruption. | Déployez des clusters d'administration en mode HA pour réduire le risque d'interruption. | Déployez des clusters d'administrateur en mode haute disponibilité pour minimiser les risques d'interruption. |
Nœud de l'é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 avec le 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 | |
|---|---|---|---|---|
| Interruption (durée) | Interruption possible (varie) | Interruption possible (varie) | Interruption possible (varie) | Interruption possible (varie) |
| 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 ne disposez que d'un seul nœud d'équilibreur de charge, cela entraîne une interruption. | 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é, une interruption se produit. | 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é, une interruption se produit. | L'adresse IP virtuelle du plan de contrôle du cluster d'administrateur se trouve sur un seul 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é, une interruption se produit. |
| Récupération | S'il existe plusieurs nœuds d'équilibrage 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 déroule en quelques secondes. Si le système n'est pas à haute disponibilité, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires. |
Pour une haute disponibilité, le basculement est automatique et se déroule en quelques secondes. Si ce n'est pas le cas, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires. |
Si le mode haute disponibilité est activé, le basculement est automatique et se produit en quelques secondes. Si vous ne disposez pas de la haute disponibilité, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires. |
| Prévention | Pour réduire les risques d'interruption, déployez des pools de nœuds d'équilibreur de charge en mode haute disponibilité. | Pour réduire le risque d'interruption, déployez des pools de nœuds d'équilibreur de charge en mode haute disponibilité. | Pour réduire le risque d'interruption, déployez des pools de nœuds d'équilibreur de charge en mode haute disponibilité. | Pour réduire les risques d'interruption, déployez des pools de nœuds d'é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) | Interruption possible (ordre de secondes) | Aucune interruption | Aucune interruption | Aucune interruption |
| Explication | Les Si les applications utilisateur disposent d'une capacité de charge de travail supplémentaire et sont réparties sur plusieurs nœuds, les interruptions ne sont pas perceptibles par les clients qui mettent en œuvre de 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 avec plusieurs instances répliquées réparties sur plusieurs zones de défaillance afin de réduire le risque d'interruption. |
— | — | — |
Défaillance de l'espace de stockage
Le stockage dans Google Distributed Cloud peut cesser de fonctionner ou devenir inaccessible sur le réseau. Selon le stockage qui échoue, 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 brutal 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 des échecs 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 | Interruption possible (inconnue) | Interruption possible (inconnu) | Interruption 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'utilisateurs de plan de contrôle ou sur au moins la moitié des nœuds de plan de contrôle d'un cluster d'utilisateurs haute disponibilité, cela entraîne une interruption. 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é, 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 échoue sur au moins la moitié des nœuds du plan de contrôle dans un cluster d'administrateur à haute disponibilité, cela entraîne une interruption. Le quorum du plan de contrôle du cluster d'administrateur est perdu. |
| Récupération | — | Pour en savoir plus, consultez la section Effectuer une récupération après une perte de quorum. | Pour en savoir plus, consultez la section Effectuer une récupération après une perte de quorum. | Pour en savoir plus, consultez la section Effectuer une récupération après une perte de quorum. |
| Prévention | — | Pour réduire le risque d'interruption, déployez des clusters d'utilisateurs en mode HA. | Pour réduire les risques d'interruption, déployez les clusters d'administrateur en mode haute disponibilité. | Pour réduire le risque d'interruption, déployez des clusters d'administration en mode HA. |
Application utilisateur PersistentVolume
Le tableau suivant décrit le comportement des fonctionnalités de base en cas d'échec 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) | Interruption possible (inconnue) | Aucune interruption | Aucune interruption | Aucune interruption |
| Explication | Les charges de travail qui utilisent le PersistentVolume défaillant |
— | — | — |
| 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 de Fluent Bit
La corruption d'un disque Fluent Bit n'affecte aucune fonctionnalité de base, mais elle a un impact sur la possibilité de collecter et d'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 due à des journaux tampons corrompus sur le disque.
Fluent Bit dispose d'un mécanisme permettant de filtrer et de supprimer les fragments rompus. Cette fonctionnalité est disponible dans la version fluent-bit (v1.8.3) utilisée dans Google Distributed Cloud.
Adresse IP hors LoadBalancer
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 affecte la capacité des clients du service à communiquer avec les services LoadBalancer.
Pour résoudre ce problème d'é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. Effectuez une rotation régulière des certificats pour éviter les temps d'arrêt du cluster. Vous pouvez faire tourner les certificats en mettant à niveau votre cluster, ce qui est la méthode recommandée. Si vous ne parvenez pas à mettre à niveau votre cluster, vous pouvez effectuer une rotation de l'autorité de certification à la demande. 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 | |
|---|---|---|---|---|
| Interruption (durée) | Aucune interruption | Interruption possible (inconnue) | Interruption possible (inconnu) | Interruption possible (inconnue) |
| Explication | Si les charges de travail de l'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'utilisateurs expirent, cela entraînera une interruption. | Si les autorités de certification des clusters d'administrateur expirent, cela entraînera une interruption. | Si les autorités de certification des clusters d'utilisateurs expirent, cela entraîne une interruption. |
| Récupération | — | Suivez la procédure permettant de renouveler manuellement les certificats sur le cluster d'utilisateurs. |
Suivez les étapes permettant de renouveler manuellement les certificats sur le cluster d'utilisateur. |
Suivez la procédure permettant de renouveler manuellement les certificats sur le cluster d'utilisateur. |
| Prévention | Configurez des moniteurs pour 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 | Interruption possible (inconnue) | Interruption 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 de ce nœud seront drainées et déplacées vers d'autres nœuds opérationnels si la capacité supplémentaire de ces nœuds est supplémentaire. |
La mise à niveau s'arrête si l'un des nœuds du plan de contrôle ne parvient pas à être mis à niveau. Le cluster reste fonctionnel si la mise à niveau échoue si le cluster utilisateur est à haute disponibilité. | Si la mise à niveau échoue sur le plan de contrôle du cluster d'administrateur, il y a une interruption jusqu'à la fin de la mise à niveau. | Si la mise à niveau échoue sur le plan de contrôle du cluster d'administrateur, une interruption se produit jusqu'à la fin de la mise à niveau. |
| Récupération | — | — | La mise à niveau peut être relancée. Pour en savoir plus, découvrez comment diagnostiquer les problèmes de mise à niveau et reprendre la mise à niveau. | La mise à niveau peut être réessayée. Pour en savoir plus, découvrez comment diagnostiquer les problèmes de mise à niveau et reprendre la mise à niveau. |
| Prévention | — | — | Pour en savoir plus, consultez la section Créer une sauvegarde avant la mise à niveau. | Pour en savoir plus, consultez la section Créer une sauvegarde avant la mise à niveau. |
Étape suivante
Pour en savoir plus sur les problèmes connus liés aux produits et sur les solutions, consultez la page Problèmes connus dans Google Distributed Cloud.
- Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.