12.5. Résilience et récupération du plan de contrôle
Vous pouvez utiliser le jeu de machines du plan de contrôle pour améliorer la résilience du plan de contrôle de votre cluster OpenShift Container Platform.
12.5.1. Haute disponibilité et tolérance aux pannes avec domaines de défaillance
Dans la mesure du possible, le jeu de machines du plan de contrôle répartit les machines du plan de contrôle sur plusieurs domaines de défaillance. Cette configuration assure une haute disponibilité et une tolérance aux pannes au sein du plan de contrôle. Cette stratégie peut aider à protéger le plan de contrôle lorsque des problèmes surviennent au sein du fournisseur d'infrastructure.
12.5.1.1. Support et configuration de la plateforme du domaine de défaillance
Le concept d'ensemble de machines du plan de contrôle d'un domaine de défaillance est analogue aux concepts existants sur les fournisseurs de nuages. Toutes les plateformes ne prennent pas en charge l'utilisation des domaines de défaillance.
| Fournisseur d'informatique en nuage | Prise en charge des domaines de défaillance | Nomenclature des prestataires |
|---|---|---|
| Amazon Web Services (AWS) | X | |
| Microsoft Azure | X | |
| VMware vSphere | Sans objet |
La configuration du domaine de défaillance dans la ressource personnalisée (CR) du jeu de machines du plan de contrôle est spécifique à la plate-forme. Pour plus d'informations sur les paramètres du domaine de défaillance dans la CR, consultez l'exemple de configuration du domaine de défaillance de votre fournisseur.
12.5.1.2. Équilibrage des machines du plan de contrôle
L'ensemble de machines du plan de contrôle équilibre les machines du plan de contrôle dans les domaines de défaillance spécifiés dans la ressource personnalisée (CR).
Dans la mesure du possible, l'ensemble des machines du plan de contrôle utilise chaque domaine de défaillance de manière égale afin de garantir une tolérance aux pannes appropriée. S'il y a moins de domaines de panne que de machines du plan de contrôle, les domaines de panne sont sélectionnés pour être réutilisés dans l'ordre alphabétique des noms. Pour les clusters dont aucun domaine de panne n'est spécifié, toutes les machines du plan de contrôle sont placées dans un seul domaine de panne.
Certaines modifications apportées à la configuration des domaines de panne entraînent le rééquilibrage des machines du plan de contrôle par l'ensemble de machines du plan de contrôle. Par exemple, si vous ajoutez des domaines de panne à un cluster comportant moins de domaines de panne que de machines du plan de contrôle, le jeu de machines du plan de contrôle rééquilibre les machines sur tous les domaines de panne disponibles.
12.5.2. Récupération des machines du plan de contrôle défaillantes
L'opérateur de jeu de machines du plan de contrôle automatise la récupération des machines du plan de contrôle. Lorsqu'une machine du plan de contrôle est supprimée, l'opérateur crée une machine de remplacement avec la configuration spécifiée dans la ressource personnalisée (CR) ControlPlaneMachineSet.
Pour les clusters qui utilisent des jeux de machines du plan de contrôle, vous pouvez configurer un contrôle de l'état des machines. Le contrôle de l'état des machines supprime les machines du plan de contrôle qui ne sont pas en bonne santé afin qu'elles soient remplacées.
Si vous configurez une ressource MachineHealthCheck pour le plan de contrôle, définissez la valeur de maxUnhealthy sur 1.
Cette configuration garantit que le contrôle de l'état des machines ne prend aucune mesure lorsque plusieurs machines du plan de contrôle semblent être en mauvaise santé. Plusieurs machines de plan de contrôle malsaines peuvent indiquer que le cluster etcd est dégradé ou qu'une opération de mise à l'échelle visant à remplacer une machine défaillante est en cours.
Si le cluster etcd est dégradé, une intervention manuelle peut être nécessaire. Si une opération de mise à l'échelle est en cours, le bilan de santé de la machine doit permettre de la terminer.
Ressources complémentaires
12.5.3. Protection du quorum à l'aide de crochets de cycle de vie de la machine
Pour les clusters OpenShift Container Platform qui utilisent l'opérateur API Machine, l'opérateur etcd utilise des crochets de cycle de vie pour la phase de suppression de la machine afin de mettre en œuvre un mécanisme de protection du quorum.
En utilisant un crochet de cycle de vie preDrain, l'opérateur etcd peut contrôler quand les pods sur une machine de plan de contrôle sont vidés et supprimés. Pour protéger le quorum etcd, l'opérateur etcd empêche la suppression d'un membre etcd jusqu'à ce qu'il migre ce membre sur un nouveau nœud dans le cluster.
Ce mécanisme permet à l'opérateur etcd de contrôler précisément les membres du quorum etcd et à l'opérateur Machine API de créer et de supprimer en toute sécurité des machines du plan de contrôle sans connaissance opérationnelle spécifique du cluster etcd.
12.5.3.1. Suppression du plan de contrôle avec ordre de traitement de la protection du quorum
Lorsqu'une machine de plan de contrôle est remplacée dans une grappe qui utilise un ensemble de machines de plan de contrôle, la grappe a temporairement quatre machines de plan de contrôle. Lorsque le quatrième nœud de plan de contrôle rejoint la grappe, l'opérateur etcd démarre un nouveau membre etcd sur le nœud de remplacement. Lorsque l'opérateur etcd observe que l'ancienne machine de plan de contrôle est marquée pour suppression, il arrête le membre etcd sur l'ancien nœud et promeut le membre etcd de remplacement pour qu'il rejoigne le quorum de la grappe.
La phase de la machine du plan de contrôle Deleting se déroule dans l'ordre suivant :
- Une machine du plan de contrôle doit être supprimée.
-
La machine du plan de contrôle entre dans la phase
Deleting. Pour satisfaire le crochet de cycle de vie
preDrain, l'opérateur etcd entreprend les actions suivantes :-
L'opérateur etcd attend qu'une quatrième machine de plan de contrôle soit ajoutée au cluster en tant que membre etcd. Ce nouveau membre etcd a l'état
Runningmais pasreadyjusqu'à ce qu'il reçoive la mise à jour complète de la base de données de la part du leader etcd. - Lorsque le nouveau membre etcd reçoit la mise à jour complète de la base de données, l'opérateur etcd promeut le nouveau membre etcd en tant que membre votant et supprime l'ancien membre etcd du cluster.
Une fois cette transition terminée, l'ancien pod etcd et ses données peuvent être supprimés en toute sécurité, et le crochet de cycle de vie
preDrainest donc supprimé.-
L'opérateur etcd attend qu'une quatrième machine de plan de contrôle soit ajoutée au cluster en tant que membre etcd. Ce nouveau membre etcd a l'état
-
La condition d'état de la machine du plan de contrôle
Drainableest réglée surTrue. Le contrôleur de machine tente de drainer le nœud qui est soutenu par la machine du plan de contrôle.
-
Si la vidange échoue,
Drainedest défini surFalseet le contrôleur de machine tente de vidanger à nouveau le nœud. -
Si la vidange réussit,
DraineddevientTrue.
-
Si la vidange échoue,
-
La condition d'état de la machine du plan de contrôle
Drainedest réglée surTrue. -
Si aucun autre opérateur n'a ajouté un crochet de cycle de vie
preTerminate, la condition d'état de la machine du plan de contrôleTerminabledevientTrue. - Le contrôleur de machine supprime l'instance du fournisseur d'infrastructure.
-
Le contrôleur de machine supprime l'objet
Node.
Extrait YAML démontrant la protection du quorum etcd preDrain lifecycle hook
apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
...
spec:
lifecycleHooks:
preDrain:
- name: EtcdQuorumOperator 1
owner: clusteroperator/etcd 2
...
Ressources complémentaires
