Google Distributed Cloud est conçu pour limiter l'étendue des défaillances et pour donner la priorité aux fonctionnalités essentielles à la continuité des opérations. Ce document explique l'impact d'une défaillance sur les fonctionnalités de vos clusters. Ces informations peuvent vous aider à identifier les domaines à résoudre en priorité en cas de problème.
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 de la considération la plus importante pour assurer la continuité des opérations. Même si votre cluster présente 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 de la deuxième considération la plus importante 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. C'est moins important que les considérations relatives au cycle de vie de l'application. S'il y a de la capacité 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 d'utilisateur. Si votre cluster d'administrateur rencontre un problème, vos charges de travail d'application sur d'autres clusters continuent de s'exécuter sans interruption.
- Si vous utilisez d'autres modèles de déploiement, tels que hybride ou autonome, le cluster d'administrateur exécute les charges de travail des applications. 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 d'échec. En cas d'interruption dans un scénario de défaillance, la durée (ordre) de l'interruption est également indiquée, si possible.
Défaillances de nœuds
Il est possible qu'un nœud de Google Distributed Cloud cesse de fonctionner ou devienne inaccessible sur le réseau. Selon le pool de nœuds et le cluster auxquels appartient la machine défaillante, il existe plusieurs modes de défaillance différents.
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 (inconnue) | 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 d'un nœud affecte le nœud de plan de contrôle unique dans 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. | 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 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'utilisateur en mode haute disponibilité pour minimiser les risques d'interruption. | Déployez des clusters d'administrateur en mode haute disponibilité pour minimiser les risques 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 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) | Interruption possible (variable) | Interruption possible (variable) | Interruption possible (variable) | Interruption possible (variable) |
| Explication | Si des 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, il y aura 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é, cela entraîne une interruption. | 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 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. |
| Récupération | S'il existe plusieurs nœuds d'équilibreur de charge, le basculement MetalLB se produit en quelques secondes. Si la haute disponibilité n'est pas activée, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires. |
Si la haute disponibilité est activée, le basculement est automatique et prend quelques secondes. Si la haute disponibilité n'est pas activée, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires. |
Si la haute disponibilité est activée, le basculement est automatique et prend quelques secondes. Si la haute disponibilité n'est pas activée, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires. |
Si la haute disponibilité est activée, le basculement est automatique et prend quelques secondes. Si la haute disponibilité n'est pas activée, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires. |
| Prévention | Pour minimiser le risque d'interruption, déployez des pools de nœuds d'équilibreur de charge en mode haute disponibilité. | Pour minimiser le risque d'interruption, déployez des pools de nœuds d'équilibreur de charge en mode haute disponibilité. | Pour minimiser le risque d'interruption, déployez des pools de nœuds d'équilibreur de charge en mode haute disponibilité. | Pour minimiser le risque 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 grandeur : 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é excédentaire, 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 tombe en panne, 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 du stockage sous-jacent. Le tableau suivant décrit le comportement des fonctionnalités de base en cas d'échec d'un 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 (inconnue) | Interruption possible (inconnue) |
| Explication | Si les charges de travail existantes ne dépendent pas du plan de contrôle Kubernetes, elles continuent de fonctionner sans interruption. | Si etcd échoue sur un cluster d'utilisateur à plan de contrôle unique ou sur au moins la moitié des nœuds de 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 etcd échoue sur un cluster d'administrateur à plan de contrôle unique, ou sur 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 etcd échoue sur un cluster d'administrateur à plan de contrôle unique, ou sur 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. |
| 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 minimiser les risques d'interruption, déployez les clusters d'utilisateurs en mode HA. | Pour minimiser les risques d'interruption, déployez les clusters d'administrateur en mode HA. | Pour minimiser les risques d'interruption, déployez les clusters d'administrateur 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 utilisateur en mode haute disponibilité. | — | — | — |
Disque Fluent Bit corrompu
La corruption d'un disque Fluent Bit n'affecte aucune fonctionnalité de base, mais a un impact sur 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 due à des journaux tampons corrompus sur le disque.
Fluent Bit dispose d'un mécanisme permettant de filtrer et de supprimer les blocs endommagés. Cette fonctionnalité est disponible dans la version fluent-bit (v1.8.3) utilisée dans Google Distributed Cloud.
sur LoadBalancer adresses 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 un impact sur 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 (CA) auto-signée lors du processus d'installation du cluster. L'AC a une durée de validité de 10 ans et est responsable de la génération des certificats, qui expirent au bout d'un an. Effectuez régulièrement une rotation des certificats pour éviter les temps d'arrêt du cluster. Vous pouvez alterner les 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 des certificats sur demande. Pour en savoir plus sur les certificats de cluster, consultez Certificats et exigences PKI dans la documentation Kubernetes.
Si les certificats du 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 | Interruption possible (inconnue) | Interruption possible (inconnue) | Interruption 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'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'utilisateur. |
Suivez la procédure 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. Un exemple de métrique kubelet_certificate_manager_server_expiration_seconds est disponible 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, les charges de travail existantes ne sont PAS interrompues. Si la mise à niveau échoue sur un nœud de calcul spécifique, les charges de travail sur ce nœud seront drainées et déplacées vers d'autres nœuds opérationnels s'il y a une capacité supplémentaire sur les nœuds opérationnels. |
La mise à niveau s'arrête si l'un des nœuds du plan de contrôle ne peut 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, une interruption se produit jusqu'à ce qu'elle se termine. | Si la mise à niveau échoue sur le plan de contrôle du cluster d'administrateur, une interruption se produit jusqu'à ce qu'elle se termine. |
| Récupération | — | — | La mise à niveau peut être relancée. Pour en savoir plus, consultez Diagnostiquer les problèmes de mise à niveau et reprendre. | La mise à niveau peut être relancée. Pour en savoir plus, consultez Diagnostiquer les problèmes de mise à niveau et reprendre. |
| Prévention | — | — | Pour en savoir plus, consultez Créer une sauvegarde avant la mise à niveau. | Pour en savoir plus, consultez Créer une sauvegarde avant la mise à niveau. |
Étapes suivantes
Pour en savoir plus sur les problèmes connus du produit et les solutions de contournement, consultez la section Problèmes connus de Google Distributed Cloud.
Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care. Vous pouvez également consulter Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris les suivantes :
- Conditions requises pour ouvrir une demande d'assistance.
- Des outils pour vous aider à résoudre les problèmes, comme la configuration de votre environnement, les journaux et les métriques.
- Composants acceptés.