Cette page explique comment configurer certains composants GKE On-Prem pour la haute disponibilité et comment effectuer une reprise après sinistre.
Fonctionnalité de base
GKE On-Prem est conçu pour garantir l'isolement des défaillances autant que possible dans un domaine fonctionnel et pour donner la priorité aux fonctionnalités essentielles à la continuité des opérations.
Les principales fonctionnalités de GKE On-Prem sont les suivantes :
Cycle de vie de l'application
Les charges de travail existantes peuvent s'exécuter en continu. Il s'agit de la fonctionnalité la plus importante pour assurer la continuité des opérations.
Vous pouvez créer, mettre à jour et supprimer des charges de travail. Il s'agit de la deuxième fonctionnalité la plus importante, car GKE On-Prem doit faire évoluer les charges de travail lorsque le trafic augmente.
Cycle de vie du cluster d'utilisateur
Vous pouvez ajouter, mettre à jour, mettre à niveau et supprimer des clusters d'utilisateurs. Cette fonctionnalité est moins importante, car l'impossibilité de modifier les clusters d'utilisateurs n'affecte pas les charges de travail des utilisateurs.
Cycle de vie du cluster d'administrateur
Vous pouvez mettre à jour et mettre à niveau le cluster d'administrateur. Cette fonctionnalité est la moins importante, car le cluster d'administrateur n'héberge aucune charge de travail d'utilisateur.
Modes de défaillance
Les types de défaillance suivants peuvent affecter les performances des clusters GKE On-Prem.
Défaillance de l'hôte ESXi
Un hôte ESXi qui exécute des instances de machine virtuelle (VM) hébergeant des nœuds Kubernetes peut cesser de fonctionner ou se transformer en réseau partitionné.
| Charges de travail existantes | Créer, mettre à jour et supprimer des charges de travail | Cycle de vie du cluster d'utilisateur | Cycle de vie du cluster d'administrateur |
|---|---|---|---|
| Interruption possible + Récupération automatique |
Interruption possible + Récupération automatique |
Interruption + Récupération automatique |
Interruption + Récupération automatique |
Les pods s'exécutant sur des VM hébergées par l'hôte défaillant sont interrompus et automatiquement replanifiés sur d'autres VM opérationnelles. 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. |
Si la défaillance de l'hôte affecte la VM de plan de contrôle dans un cluster d'utilisateur standard ou plusieurs VM de plan de contrôle dans un cluster d'utilisateur à haute disponibilité, cela entraîne une interruption. | Si la défaillance de l'hôte affecte la VM de plan de contrôle ou les VM de nœud de calcul du cluster d'administrateur, cela entraîne une interruption. | Si la défaillance de l'hôte affecte la VM de plan de contrôle dans le cluster d'administrateur, cela entraîne une interruption. |
| vSphere HA redémarre automatiquement les VM sur des hôtes opérationnels. | vSphere HA redémarre automatiquement les VM sur des hôtes opérationnels. | vSphere HA redémarre automatiquement les VM sur des hôtes opérationnels. | vSphere HA redémarre automatiquement les VM sur des hôtes opérationnels. |
| Déployez vos charges de travail sur un cluster à haute disponibilité de façon à réduire le risque d'interruption. | Utilisez des clusters d'utilisateurs à haute disponibilité pour minimiser les risques d'interruption. |
Défaillance de la VM
Une VM peut être supprimée de manière inattendue ou un disque de démarrage peut être endommagé. Une VM peut également être compromise en raison de problèmes liés au système d'exploitation.
| Charges de travail existantes | Créer, mettre à jour et supprimer des charges de travail | Cycle de vie du cluster d'utilisateur | Cycle de vie du cluster d'administrateur |
|---|---|---|---|
| Interruption possible + Récupération automatique |
Interruption possible + Récupération automatique |
Interruption + Récupération automatique/manuelle |
Interruption + Récupération manuelle |
Les pods s'exécutant sur les VM de nœud de calcul défaillantes sont interrompus. Ils sont automatiquement replanifiés sur d'autres VM opérationnelles par Kubernetes. 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. |
Si la VM avec plan de contrôle d'un cluster d'utilisateur standard ou plusieurs VM de plan de contrôle dans un cluster d'utilisateur haute disponibilité échouent, cela comporte une interruption. | En cas de défaillance de la VM du plan de contrôle ou des VM de nœud de calcul dans le cluster administrateur, il y a interruption. | Si la VM du plan de contrôle du cluster d'administrateur échoue, une interruption se produit. |
| La VM défaillante est automatiquement récupérée si la réparation automatique des nœuds est activée dans le cluster d'utilisateur. | La VM défaillante est automatiquement récupérée si la réparation automatique de nœuds est activée dans le cluster d'administrateur. | La VM de nœud de calcul défaillante dans le cluster d'administrateur sera automatiquement récupérée si la réparation automatique des nœuds est activée dans le cluster d'administrateur. Vous devez récupérer manuellement la VM de plan de contrôle défaillante dans le cluster d'administrateur. Pour obtenir de l'aide, contactez l'assistance Google. |
Vous devez récupérer manuellement la VM de plan de contrôle défaillante dans le cluster administrateur. Pour obtenir de l'aide, contactez l'assistance Google. |
| Déployez vos charges de travail sur un cluster à haute disponibilité de façon à réduire le risque d'interruption. | Utilisez des clusters d'utilisateurs à haute disponibilité pour minimiser les risques d'interruption. |
Défaillance de l'espace de stockage
Le contenu d'un fichier VMDK peut être altéré en raison d'une mise hors tension concertée d'une VM ou d'une défaillance du datastore ce qui peut provoquer la perte de données etcd et de volumes PersistentVolumes (PV).
défaillance etcd
| Charges de travail existantes | Créer, mettre à jour et supprimer des charges de travail | Cycle de vie du cluster d'utilisateur | Cycle de vie du cluster d'administrateur |
|---|---|---|---|
| Aucune interruption | Interruption possible + Récupération manuelle |
Interruption + Récupération manuelle |
Interruption + Récupération manuelle |
| En cas de défaillance du stockage etcd d'un cluster utilisateur standard ou de plusieurs instances dupliquées etcd dans un cluster utilisateur haute disponibilité, il y a une interruption. | En cas de défaillance du stockage etcd d'un cluster utilisateur standard ou de plusieurs instances dupliquées etcd dans un cluster utilisateur haute disponibilité, il y a une interruption. Si l'instance dupliquée etcd d'un cluster d'administrateur échoue, une interruption se produit. |
Si l'instance dupliquée etcd d'un cluster d'administrateur échoue, une interruption se produit. | |
| GKE On-Prem fournit un processus manuel de récupération après défaillance. | GKE On-Prem fournit un processus manuel de récupération après défaillance. | GKE On-Prem fournit un processus manuel de récupération après défaillance. |
Défaillance du PV de l'application utilisateur
| Charges de travail existantes | Créer, mettre à jour et supprimer des charges de travail | Cycle de vie du cluster d'utilisateur | Cycle de vie du cluster d'administrateur |
|---|---|---|---|
| Interruption possible | Aucune interruption | Aucune interruption | Aucune interruption |
Les charges de travail qui utilisent le PV défaillant sont concernées. Déployez vos charges de travail sur un cluster à haute disponibilité de façon à réduire le risque d'interruption. |
Défaillance de l'équilibreur de charge
Une défaillance de l'équilibreur de charge peut affecter les charges de travail des utilisateurs qui exposent des services de type LoadBalancer.
| Charges de travail existantes | Créer, mettre à jour et supprimer des charges de travail | Cycle de vie du cluster d'utilisateur | Cycle de vie du cluster d'administrateur |
|---|---|---|---|
| Interruption + Récupération manuelle |
|||
|
Quelques secondes d'interruption avant que l'équilibreur de charge de secours rétablisse la connexion d'adresse IP virtuelle du plan de contrôle administrateur. L'interruption de service peut prendre jusqu'à deux secondes en cas d'utilisation de Seesaw et jusqu'à 300 secondes avec F5. Seesaw HA détecte automatiquement l'échec et bascule vers l'utilisation de l'instance de sauvegarde. GKE On-Prem fournit un processus manuel pour la récupération après une défaillance de Seesaw. |
|||
Activer la haute disponibilité
vSphere et GKE On-Prem présentent un certain nombre de fonctionnalités qui contribuent à la haute disponibilité.
vSphere HA et vMotion
Nous vous recommandons d'activer les deux fonctionnalités suivantes dans le cluster vCenter qui héberge vos clusters GKE On-Prem :
Ces fonctionnalités améliorent la disponibilité et la récupération en cas de défaillance d'un hôte ESXi.
vCenter HA utilise plusieurs hôtes ESXi configurés en tant que cluster pour assurer une récupération rapide des pannes et une haute disponibilité économique pour les applications exécutées sur des machines virtuelles. Nous vous recommandons de provisionner votre cluster vCenter avec des hôtes supplémentaires et d'activer la surveillance de l'hôte vSphere HA avec Host Failure Response défini sur Restart VMs. Vos VM peuvent alors redémarrer automatiquement sur d'autres hôtes disponibles en cas de défaillance de l'hôte ESXi.
vMotion permet d'effectuer une migration à chaud sans interruption d'un hôte ESXi vers un autre hôte. Pour la maintenance planifiée de l'hôte, vous pouvez utiliser la migration à chaud vMotion pour éviter tout temps d'arrêt d'application et garantir la continuité de l'entreprise.
Cluster d'administrateur
GKE On-Prem n'est pas compatible avec l'exécution de plusieurs plans de contrôle pour le cluster d'administrateur. Toutefois, l'indisponibilité du plan de contrôle d'administrateur n'affecte pas les fonctionnalités existantes du cluster d'utilisateur ni les charges de travail exécutées dans ces clusters.
Un cluster d'administrateur comporte deux nœuds complémentaires. Si l'un est indisponible, l'autre peut toujours traiter les opérations du cluster d'administrateur. Pour la redondance, GKE On-Prem propage les services complémentaires essentiels, tels que kube-dns, sur les deux nœuds complémentaires.
Si vous définissez antiAffinityGroups.enabled sur true dans le fichier de configuration du cluster d'administrateur, GKE On-Prem crée automatiquement des règles d'anti-affinité vSphere DRS pour les nœuds complémentaires, ce qui entraîne leur répartition sur deux hôtes physiques afin d'assurer une haute disponibilité.
Cluster d'utilisateur
Vous pouvez activer la haute disponibilité pour un cluster d'utilisateur en définissant masterNode.replicas sur 3 dans le fichier de configuration du cluster d'utilisateur. Cette action génère trois nœuds dans le cluster d'administrateur, chacun exécutant un plan de contrôle pour le cluster d'utilisateur. Chacun de ces nœuds exécute également une instance dupliquée etcd. Le cluster d'utilisateur continuera de fonctionner tant qu'un plan de contrôle est en cours d'exécution et qu'il y a un quorum etcd. Un quorum etcd nécessite que deux des trois instances dupliquées etcd soient en cours d'exécution.
Si vous définissez antiAffinityGroups.enabled sur true dans le fichier de configuration du cluster d'administrateur, GKE On-Prem crée automatiquement des règles d'anti-affinité vSphere DRS pour les trois nœuds exécutant le plan de contrôle du cluster d'utilisateur.
Cela a pour effet de répartir les VM sur trois hôtes physiques.
GKE On-Prem crée également des règles d'anti-affinité vSphere DRS pour les nœuds de calcul de votre cluster d'utilisateur, ce qui entraîne la répartition de ces nœuds sur au moins trois hôtes physiques. Plusieurs règles d'anti-affinité DRS sont utilisées par chaque pool de nœuds du cluster d'utilisateur en fonction du nombre de nœuds. Ainsi, les nœuds de calcul peuvent trouver des hôtes sur lesquels s'exécuter, même lorsque le nombre d'hôtes est inférieur au nombre de VM dans le pool de nœuds du cluster d'utilisateur. Nous vous recommandons d'inclure des hôtes physiques supplémentaires dans le cluster vCenter. Configurez également la fonctionnalité DRS de manière à ce qu'elle soit entièrement automatisée. Ainsi, lorsqu'un hôte n'est plus disponible, le service DRS peut redémarrer automatiquement les VM sur d'autres hôtes disponibles sans enfreindre les règles d'anti-affinité de VM.
GKE On-Prem conserve un libellé de nœud spécial, onprem.gke.io/failure-domain-name, dont la valeur est définie sur le nom d'hôte ESXi sous-jacent. Les applications utilisateur qui souhaitent bénéficier de la haute disponibilité peuvent configurer des règles podAntiAffinity avec ce libellé comme topologyKey, pour garantir que leurs pods d'application sont propagés sur différentes VM et hôtes physiques.
Vous pouvez également configurer plusieurs pools de nœuds pour un cluster d'utilisateur avec différents datastores et des libellés de nœuds spéciaux. De même, vous pouvez configurer des règles podAntiAffinity en utilisant ce libellé de nœud spécial en tant qu'élément topologyKey afin d'améliorer la disponibilité en cas de défaillance du datastore.
Pour bénéficier de la haute disponibilité pour les charges de travail d'utilisateur, assurez-vous que le cluster d'utilisateur dispose d'un nombre suffisant d'instances dupliquées sous nodePools.replicas pour garantir l'exécution du nombre souhaité de nœuds de calcul dans le cluster d'utilisateur.
Pour isoler les défaillances des clusters d'administrateur et des clusters d'utilisateur, vous pouvez utiliser des datastores distincts.
Équilibreur de charge
Vous pouvez utiliser deux types d'équilibreurs de charge pour la haute disponibilité.
Équilibreur de charge groupé Seesaw
Pour l'équilibreur de charge groupé Seesaw, vous pouvez activer la haute disponibilité en définissant loadBalancer.seesaw.enableHA sur true dans le fichier de configuration du cluster.
Vous devez également activer une combinaison d'apprentissage MAC, de transmissions falsifiées et de mode promiscuité sur le groupe de ports de l'équilibreur de charge.
Avec la haute disponibilité, deux équilibreurs de charge sont configurés en mode actif-passif. Si l'équilibreur de charge actif présente un problème, le trafic est acheminé vers l'équilibreur de charge passif.
La mise à niveau d'un équilibreur de charge comporte quelques temps d'arrêt. Si le mode haute disponibilité est activé pour l'équilibreur de charge, le temps d'arrêt maximal est de deux secondes.
Équilibreur de charge F5 BIG-IP intégré
La plate-forme F5 BIG-IP fournit divers services pour vous aider à améliorer la sécurité, la disponibilité et les performances de vos applications. Pour GKE On-Prem, BIG-IP fournit un accès externe et des services d'équilibrage de charge L3/4.
Pour plus d'informations, consultez la section Haute disponibilité BIG-IP.
Récupération d'un cluster défectueux
Les sections suivantes expliquent comment récupérer un cluster défectueux.
Récupération après défaillance de l'hôte ESXi
GKE On-Prem s'appuie sur vSphere HA pour assurer une récupération en cas de défaillance de l'hôte ESXi. vSphere HA peut surveiller en continu les hôtes ESXi et redémarrer automatiquement les VM sur d'autres hôtes si nécessaire. Cette opération est transparente pour les utilisateurs de GKE On-Prem.
Récupération après une défaillance de la VM
Les défaillances de VM peuvent inclure les éléments suivants :
Suppression inattendue d'une VM.
Corruption du disque de démarrage de VM. Par exemple, un disque de démarrage est devenu en lecture seule en raison des journaux de journal anti-spam.
Échec du démarrage de la VM en raison de problèmes de performances du disque ou de la configuration du réseau. Par exemple, une VM ne peut pas démarrer, car une adresse IP ne peut pas être attribuée pour une raison quelconque.
Corruption du système de fichiers de superposition Docker.
Perte de la VM de plan de contrôle administrateur en raison d'un échec de mise à niveau.
Problèmes liés au système d'exploitation.
Les défaillances de VM décrites dans cette section n'incluent pas les corruptions ou les pertes de données sur le PV ou les disques de données etcd associés à la VM. Pour en savoir plus à ce sujet, consultez la section Récupération après une défaillance de datastore.
GKE On-Prem fournit un mécanisme de récupération automatique pour les nœuds complémentaires d'administrateur, les plans de contrôle d'utilisateur et les nœuds utilisateur. Cette fonctionnalité de réparation automatique des nœuds peut être activée pour chaque cluster d'administrateur et chaque cluster d'utilisateur.
La VM de plan de contrôle administrateur est spéciale, car elle n'est pas gérée par un cluster Kubernetes et sa disponibilité n'affecte pas la continuité des opérations. Pour la récupération des défaillances de VM de plan de contrôle administrateur, contactez l'assistance Google.
Récupération après une défaillance de l'espace de stockage
Certaines défaillances de l'espace de stockage peuvent être atténuées par vSphere HA et par VSAN sans affecter GKE On-Prem. Cependant, certains échecs de stockage peuvent se produire à partir du niveau vSphere, provoquant une corruption ou une perte de données sur divers composants GKE On-Prem.
Les informations avec état d'un cluster et des charges de travail d'utilisateur sont stockées aux emplacements suivants :
etcd
Chaque cluster (cluster d'administrateur et cluster d'utilisateur) dispose d'une base de données etcd qui stocke l'état (objets Kubernetes) du cluster.
PersistentVolumes
Utilisés par les composants du système et les charges de travail de l'utilisateur.
Récupération après corruption ou perte de données d'etcd
etcd est la base de données utilisée par Kubernetes pour stocker tous les états de cluster, y compris les fichiers manifestes de l'application d'utilisateur. Les opérations du cycle de vie de l'application cesseront de fonctionner si la base de données etcd du cluster d'utilisateur est corrompue ou perdue. Les opérations du cycle de vie du cluster d'utilisateur cesseront de fonctionner si la base de données etcd du cluster d'administrateur est corrompue ou perdue.
etcd ne dispose pas d'un mécanisme intégré fiable pour détecter la corruption des données. Vous devez consulter les journaux des pods de l'etcd si vous pensez que les données de l'etcd sont corrompues ou perdues.
Un pod etcd en attente/d'erreur/crash-looping ne signifie pas nécessairement que les données etcd sont corrompues ou perdues. Cela peut être dû à des erreurs sur les VM hébergeant les pods de l'etcd. Pour l'interruption ou la perte de données, vous devez vous cantonner à effectuer la récupération etcd suivante :
Pour pouvoir récupérer (un état de cluster récent) à partir d'une corruption ou d'une perte de données etcd, les données etcd doivent être sauvegardées après toute opération de cycle de vie dans le cluster (par exemple, création, mise à jour ou mise à niveau). Pour sauvegarder les données etcd, consultez les pages Sauvegarder un cluster d'administrateur et Sauvegarder un cluster d'utilisateur.
La restauration des données etcd rétablit l'état précédent du cluster. En d'autres termes, si une sauvegarde est effectuée avant le déploiement d'une application, puis utilisée pour restaurer le cluster, l'application ne s'exécutera pas dans le cluster restauré. Par exemple, si vous utilisez l'instantané etcd d'un cluster d'administrateur instantané avant de créer un cluster d'utilisateur, le plan de contrôle du cluster d'utilisateur restauré sera supprimé du cluster d'administrateur restauré. Par conséquent, nous vous recommandons de sauvegarder le cluster après chaque opération critique du cluster.
La corruption ou la perte des données d'etcd peut entraîner une défaillance dans les scénarios suivants.
Un nœud unique d'un cluster etcd à trois nœuds (cluster d'utilisateur haute disponibilité) est définitivement défectueux en raison d'une corruption ou d'une perte de données. Dans ce cas, un seul nœud est défectueux, mais le quorum etcd existe toujours. Cela peut se produire dans un cluster à haute disponibilité, dans lequel les données de l'une des instances dupliquées etcd sont corrompues ou perdues. Le problème peut être résolu, sans perte de données, en remplaçant l'instance dupliquée d'etcd défaillante par une nouvelle instance dans un état propre.
Deux nœuds d'un cluster etcd à trois nœuds (cluster d'utilisateur haute disponibilité) sont définitivement défectueux en raison d'une corruption ou d'une perte de données. Le quorum est perdu. Il n'est donc pas utile de remplacer les instances dupliquées etcd défaillantes par de nouvelles. L'état du cluster doit être restauré à partir de données de sauvegarde. Pour en savoir plus, consultez la page Restaurer un cluster d'utilisateur à partir d'une sauvegarde (haute disponibilité).
Un cluster etcd à nœud unique (cluster d'administrateur ou cluster d'utilisateur standard) est définitivement défectueux en raison d'une corruption ou d'une perte de données. Le quorum est perdu. Vous devez donc créer un cluster à partir de la sauvegarde. Pour plus d'informations, consultez la section Restaurer un cluster d'utilisateur à partir d'une sauvegarde (standard).
Récupération après perte ou corruption PV de l'application utilisateur.
Les clients GKE On-Prem peuvent utiliser certaines solutions de stockage de partenaires pour sauvegarder et restaurer des volumes persistants d'applications utilisateur.
Pour accéder à la liste des partenaires de stockage certifiés pour GKE On-Prem, consultez la page Partenaires de stockage Anthos Ready.
Récupération après une défaillance de l'équilibreur de charge
Pour l'équilibrage de charge groupé (Seesaw), vous pouvez récupérer les données en cas de défaillance en recréant l'équilibreur de charge. Pour recréer l'équilibreur de charge, effectuez une mise à niveau de Seesaw vers la même version que celle indiquée dans la section Mettre à niveau l'équilibreur de charge de votre cluster d'administrateur.
En cas de défaillance de l'équilibreur de charge du cluster d'administrateur, le plan de contrôle peut être hors de portée. Par conséquent, vous devez exécuter la mise à niveau sur la VM de plan de contrôle administrateur permettant un accès au plan de contrôle.
Pour les équilibreurs de charge intégrés (F5), veuillez vous rapprocher de l'assistance F5.
Utiliser plusieurs clusters pour la reprise après sinistre
Le déploiement d'applications dans plusieurs clusters sur plusieurs plates-formes vCenter ou Anthos peut assurer une disponibilité globale plus élevée et limiter le rayon d'action des interruptions.
Cette configuration utilise le cluster Anthos existant du centre de données secondaire pour la reprise après sinistre au lieu de configurer un nouveau cluster. Voici un résumé détaillé de cette action :
Créez un autre cluster d'administrateur et un autre cluster d'utilisateur dans le centre de données secondaire. Dans cette architecture multicluster, les utilisateurs doivent disposer de deux clusters d'administrateur dans chaque centre de données, et chaque cluster d'administrateur exécute un cluster d'utilisateur.
Le cluster d'utilisateur secondaire dispose d'un nombre minimal de nœuds de calcul (trois) et d'une instance de secours automatique (toujours en cours).
Les déploiements d'applications peuvent être répliqués sur les deux vCenter à l'aide d'Anthos Config Management, ou l'approche recommandée consiste à utiliser une chaîne d'outils DevOps (CI/CD, Spinnaker) d'application existante.
En cas de sinistre, le cluster d'utilisateur peut être redimensionné en fonction du nombre de nœuds.
De plus, un basculement DNS sera nécessaire pour acheminer le trafic entre les clusters vers le centre de données secondaire.