Que se passe-t-il lors d’une défaillance du plan de contrôle Kubernetes ?

Kubernetes est le principal orchestrateur pour la distribution d’instances de conteneur sur plusieurs nœuds physiques. Les nœuds sont gérés par le plan de contrôle Kubernetes, un ensemble de composants qui maintiennent l’état du cluster, répondent aux conditions changeantes et gèrent les décisions de planification.

Il est essentiel de comprendre le rôle du plan de contrôle lorsque vous exploitez des clusters nécessitant une disponibilité constante. Dans cet article, vous apprendrez ce qui se passe lorsque le plan de contrôle échoue afin que vous puissiez planifier à l’avance et mettre en œuvre des protections.

Comprendre le plan de contrôle

Le plan de contrôle Kubernetes est responsable des opérations globales de votre cluster. Il coordonne les actions qui affectent vos noeuds worker. Le plan de contrôle fournit également le stockage de données etcd pour le cluster, ainsi que le serveur d’API avec lequel vous interagissez à l’aide d’outils tels que Kubectl.

Voici quelques-unes des principales responsabilités du plan de contrôle :

• kube-apiserver héberge le serveur d’API Kubernetes.
• kube-controller-manager démarre et exécute les contrôleurs au sein de votre cluster, ce qui permet de détecter et d’appliquer les changements d’état demandés par le serveur d’API.
• kube-scheduler attribue des pods aux nœuds de travail en déterminant quel nœud est le mieux équipé pour prendre en charge chaque nouveau pod.
• etcd est un magasin de données clé-valeur qui contient toutes les données et informations d’état du cluster Kubernetes.

L’architecture Kubernetes repose sur la disponibilité permanente de ces composants. Ils travaillent ensemble pour créer l’état de fonctionnement normal où tout se passe bien et où votre cluster répond aux attentes.

Que se passe-t-il lors d’une défaillance du plan de contrôle ?

Le plan de contrôle n’est pas insensible aux défaillances. Le nombre élevé de composants impliqués signifie que des pièces individuelles peuvent cesser de fonctionner et provoquer des effets d’entraînement dans votre cluster. Un composant peut tomber en panne ou l’hôte physique exécutant le plan de contrôle peut subir une défaillance matérielle.

Les effets réels sur votre cluster varient en fonction du composant à l’origine du problème. Cependant, une défaillance du plan de contrôle vous empêchera généralement d’administrer votre cluster et pourrait empêcher les charges de travail existantes de réagir aux nouveaux événements :

• Si le serveur d’API tombe en panne, Kubectl, le tableau de bord Kubernetes et d’autres outils de gestion cesseront de fonctionner.
• Si le planificateur échoue, les nouveaux pods ne seront pas alloués aux nœuds, ils seront donc inaccessibles et apparaîtront comme bloqués dans l’état En attente. Cela affectera également les pods qui doivent être replanifiés parce qu’un nœud manque de ressources ou qu’une demande de mise à l’échelle a été envoyée.
• Lorsque le gestionnaire de contrôleur échoue, les modifications que vous appliquez à votre cluster ne seront pas récupérées, de sorte que vos charges de travail sembleront conserver leur état précédent.

Les défaillances du plan de contrôle vous empêchent de modifier efficacement l’état du cluster. Les modifications échoueront complètement ou n’auront aucun effet à l’intérieur du cluster.

Qu’en est-il des nœuds de travail et des pods en cours d’exécution ?

Le plan de contrôle est une couche de gestion qui se trouve au-dessus et s’étend sur vos nœuds de travail et leurs pods. Le plan de contrôle et les nœuds de calcul sont indépendants les uns des autres. Une fois qu’un pod a été planifié sur un nœud, ce nœud devient responsable de l’acquisition de l’image correcte et de l’exécution d’une instance de conteneur.

Cela signifie que les défaillances dans le plan de contrôle n’élimineront pas nécessairement les charges de travail qui sont déjà dans un état sain. Vous pouvez souvent continuer à accéder aux pods existants, même lorsque vous ne pouvez pas vous connecter à votre cluster avec Kubectl. Les utilisateurs ne remarqueront pas nécessairement une panne de plan de contrôle à court terme.

Des périodes d’indisponibilité plus longues augmentent la probabilité que les nœuds de travail commencent également à rencontrer des problèmes. Les nœuds ne pourront pas réconcilier leur état, des incohérences pourraient donc se produire. Le réseau peut également commencer à se rompre si le DNS ne fonctionne pas et que le contenu des requêtes mises en cache expire.

Une défaillance peut devenir plus grave si un nœud de travail commence à rencontrer des problèmes alors que le plan de contrôle est en panne. Dans cette situation, les pods sur le nœud peuvent cesser de fonctionner, mais le reste du cluster sera inconscient de ce qui se passe. Il sera impossible de reprogrammer les pods vers un autre nœud car les nœuds fonctionnent indépendamment en l’absence du plan de contrôle. Cela entraînera la mise hors ligne de votre charge de travail.

Éviter l’échec du plan de contrôle

Vous pouvez vous défendre contre les défaillances du plan de contrôle en configurant un cluster hautement disponible qui réplique les fonctions du plan de contrôle sur plusieurs machines. De la même manière que vous utilisez Kubernetes pour distribuer et mettre à l’échelle vos propres conteneurs, vous pouvez appliquer la haute disponibilité (HA) à Kubernetes lui-même pour augmenter la résilience.

Kubernetes propose deux mécanismes pour configurer la mise en œuvre d’un plan de contrôle HA :

1. Utilisation de nœuds de plan de contrôle « empilés ». – Cette approche nécessite moins d’infrastructure et fonctionne avec un minimum de trois machines. Chaque machine exécutera son propre plan de contrôle qui réplique les données des autres. Un hôte assumera la responsabilité du cluster en étant désigné comme leader. Si le leader se déconnecte, les autres nœuds remarqueront son absence et un nouveau leader sera élu. Idéalement, vous avez besoin d’un nombre impair d’hôtes, par exemple 3, 5 ou 7, pour optimiser le processus d’élection.
2. Utilisation d’un magasin de données etcd externe. – Cette approche est similaire au modèle empilé mais avec une différence essentielle. Il s’appuie sur une instance etcd externe qui sera partagée par vos nœuds de plan de contrôle. Cela peut éviter une réplication de données inutile. Vous devez envisager de configurer manuellement la réplication du cluster etcd afin qu’il ne devienne pas un point de défaillance distinct.

Kubernetes prend désormais bien en charge les clusters avec plusieurs plans de contrôle. Si vous administrez votre propre cluster, vous pouvez ajouter un autre nœud de plan de contrôle en incluant simplement le --control-plane drapeau lorsque vous exécutez le kubeadm join commande:

$ kubeadm join <cluster-control-plane-leader-ip>:6443 
    --token <cluster-join-token>
    --discovery-token-ca-cert-hash sha256:<cluster-discovery-token-ca-cert-hash>  
    --certificate-key <cluster-certificate-key> 
    --control-plane

Sommaire

Le plan de contrôle Kubernetes est responsable de la maintenance des opérations au niveau du cluster. Il supervise vos nœuds de travail, gère les demandes d’API et applique des actions à l’intérieur du cluster pour atteindre l’état souhaité.

Lorsque le plan de contrôle tombera en panne, ces fonctions seront indisponibles, mais vous devriez pouvoir continuer à utiliser les pods existants pendant une période limitée. Le plan de contrôle est ce qui assemble les nœuds pour former un cluster ; sans cela, les nœuds sont obligés de fonctionner indépendamment, sans aucune connaissance les uns des autres.

Comme le plan de contrôle est un point de défaillance centralisé unique, les clusters critiques doivent le répliquer sur plusieurs nœuds maîtres pour maximiser la fiabilité. Les clusters multimaîtres distribuent les fonctions de gestion de cluster de la même manière que les nœuds de travail rendent vos conteneurs hautement disponibles. Bien qu’ils puissent être plus difficiles à configurer, la redondance supplémentaire en vaut la peine. Un plan de contrôle hautement disponible est également proposé en tant que fonctionnalité des offres Kubernetes gérées de nombreux fournisseurs de cloud.