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 le fonctionnement de vos clusters. Ces informations peuvent vous aider à identifier les domaines à dépanner en cas de problème.
Les fonctionnalités de base 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 mettre à l'échelle 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. Cette fonctionnalité est moins importante que les considérations liées au cycle de vie des applications. Si les nœuds existants disposent d'une capacité disponible, 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, 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 qu'hybride ou autonome, 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. 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œud
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 auquel 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 les 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'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 instructions 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 les 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 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'é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 d'é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 d'équilibreur de charge du cluster d'administrateur 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 d'équilibreur de charge du cluster d'administrateur n'est pas à haute disponibilité, cela entraîne une interruption. |
| 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 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 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 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. |
| Prévention | Pour minimiser les risques d'interruption, déployez des pools de nœuds d'équilibreur de charge en mode haute disponibilité. | Pour minimiser les risques d'interruption, déployez des pools de nœuds d'équilibreur de charge en mode haute disponibilité. | Pour minimiser les risques d'interruption, déployez des pools de nœuds d'équilibreur de charge en mode haute disponibilité. | Pour minimiser 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 les 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 quelques 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é supplémentaire, vous devez déployer davantage de 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
L'espace de stockage de Google Distributed Cloud peut cesser de fonctionner ou devenir inaccessible sur le réseau. Selon l'espace de stockage défaillant, il existe plusieurs modes de défaillance différents.
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 de l'espace de stockage. Le tableau suivant décrit le comportement des fonctionnalités de base en cas d'échec d'un etcd :
| Exécuter les 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
échoue sur 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 etcd échoue sur un cluster d'administrateur à plan de contrôle unique, ou
échoue 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
échoue 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 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é. |
PersistentVolume d'application utilisateur
Le tableau suivant décrit le comportement des fonctionnalités de base en cas d'échec d'un PersistentVolume :
| Exécuter les 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 |
— | — | — |
| 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 Fluent Bit
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.
Adresse IP LoadBalancer manquante
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 davantage 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) auto-signée lors du processus d'installation du cluster. L'autorité de certification expire au bout de 10 ans et est responsable de la génération de certificats, qui expirent au bout d'un an. Faites tourner régulièrement les 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 Kubernetes.
Si les certificats de cluster ont expiré, ils doivent être renouvelés manuellement.
| Exécuter les 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 de l'utilisateur ne communiquent pas avec les composants du plan de contrôle Kubernetes il n'y aura pas d'interruption. | 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. 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 les 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 particulier, les charges de travail de 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 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 relancée. Pour en savoir plus, consultez la section Diagnostiquer les problèmes de mise à niveau et reprendre la mise à niveau. | La mise à niveau peut être relancée. Pour en savoir plus, consultez la section 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 au produit et sur les solutions de contournement, consultez la section Problèmes connus dans 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 en ce qui concerne les thématiques suivantes :
- Conditions requises pour ouvrir une demande d'assistance
- Outils pour vous aider à résoudre les problèmes liés à la configuration de votre environnement, les journaux et les métriques
- Composants acceptés