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.
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 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 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 rencontre 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. Cela est moins important que les considérations liées 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'utilisateurs 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'administration 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 de défaillance. En cas d'interruption dans le cadre d'un scénario de défaillance, la durée (ordre) de l'interruption est également indiquée, si possible.
Défaillances de nœuds
Un nœud de Google Distributed Cloud peut cesser de fonctionner ou devenir inaccessible sur le réseau. Selon le pool de nœuds et le cluster auxquels la machine défaillante appartient, 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 (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 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 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 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'administrateur en mode HA pour réduire le risque d'interruption. | Déployez des clusters d'administrateur en mode HA pour réduire le risque 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, il y a une perturbation. | L'adresse IP virtuelle du plan de contrôle du cluster d'utilisateur se trouve sur un seul nœud d'équilibreur de charge. Si le pool de nœuds de l'équilibreur de charge du cluster utilisateur n'est pas à haute disponibilité, cela entraîne une interruption. | 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. | 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'é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. |
Si le mode haute disponibilité est activé, le basculement est automatique et se produit en quelques secondes. Si l'HA n'est pas activé, 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 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 ce n'est pas le cas, envisagez de déployer des nœuds d'équilibreur de charge supplémentaires. |
| Prévention | 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 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é. |
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 réserve, vous devez déployer d'autres nœuds répartis sur plusieurs zones de défaillance et déplacer les charges de travail défaillantes 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 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 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 HA, cela entraîne une interruption. 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 HA, 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 le risque d'interruption, déployez des clusters d'administrateur en mode HA. | Pour réduire le risque d'interruption, déployez des 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 réduire le risque d'interruption, déployez la charge de travail utilisateur en mode HA. | — | — | — |
Disque corrompu 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é dans les 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 segments défectueux. Cette fonctionnalité est disponible dans la version Fluent-Bit (v1.8.3) utilisée dans Google Distributed Cloud.
Adresse IP 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 remédier à cet épuisement des adresses IP, attribuez plus d'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) autosignée lors du processus d'installation du cluster. L'autorité de certification a une durée de validité 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 toute interruption du cluster. Vous pouvez faire pivoter 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 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 (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îne une interruption. | Si les autorités de certification des clusters d'administrateur expirent, cela entraîne 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. 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, aucune interruption n'est causée aux charges de travail existantes. Si la mise à niveau échoue sur un nœud de calcul particulier, les charges de travail sur ce nœud seront vidées et déplacées vers d'autres nœuds opérationnels si ceux-ci disposent d'une capacité 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, une interruption se produit 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 réessayée. Pour en savoir plus, découvrez comment diagnostiquer les problèmes de mise à niveau et reprendre. | La mise à niveau peut être réessayée. 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
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 la page 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, tels que la configuration de votre environnement, les journaux et les métriques.
- Composants compatibles.