2.5. Comprendre la disponibilité pour OpenShift Dedicated

D’après la conception, les gousses sont censées exister pendant une courte période. La mise à l’échelle appropriée des services de sorte que plusieurs instances de vos pods d’application sont en cours d’exécution protège contre les problèmes avec n’importe quel pod ou conteneur individuel. Le programmeur de nœuds peut également s’assurer que ces charges de travail sont réparties entre différents nœuds de travail afin d’améliorer encore la résilience.

Lors de la prise en compte des éventuelles défaillances de pod, il est également important de comprendre comment le stockage est attaché à vos applications. Les volumes persistants uniques attachés à des pods uniques ne peuvent pas tirer parti de tous les avantages de la mise à l’échelle des pod, tandis que les bases de données reproduites, les services de base de données ou le stockage partagé peuvent.

Afin d’éviter les perturbations de vos applications lors de la maintenance planifiée, comme les mises à niveau, il est important de définir un budget de perturbation de pod. Ceux-ci font partie de l’API Kubernetes et peuvent être gérés avec l’OpenShift CLI (oc) comme d’autres types d’objets. Ils permettent la spécification des contraintes de sécurité sur les gousses pendant les opérations, telles que l’évacuation d’un nœud pour l’entretien.

Les nœuds ouvriers sont les machines virtuelles qui contiennent vos pods d’application. Par défaut, un cluster dédié OpenShift dispose d’un minimum de quatre nœuds de travail pour un cluster de zone de disponibilité unique. En cas de défaillance d’un nœud ouvrier, les gousses sont transférées vers des nœuds de travail fonctionnels, tant qu’il y a suffisamment de capacité, jusqu’à ce que tout problème avec un nœud existant soit résolu ou que le nœud soit remplacé. Le plus grand nombre de nœuds de travail signifie plus de protection contre les pannes de nœuds uniques et assure une capacité de cluster appropriée pour les gousses reprogrammées en cas de défaillance du nœud.

Les clusters dédiés OpenShift ont au moins trois nœuds de plan de contrôle et trois nœuds d’infrastructure préconfigurés pour une haute disponibilité, soit dans une seule zone, soit sur plusieurs zones en fonction du type de cluster que vous avez sélectionné. Cela signifie que l’avion de contrôle et les nœuds d’infrastructure ont la même résilience des nœuds ouvriers, avec l’avantage supplémentaire d’être entièrement géré par Red Hat.

Dans le cas d’une panne complète des nœuds de plan de contrôle, les API OpenShift ne fonctionneront pas, et les pods de nœuds de travail existants ne seront pas affectés. Cependant, s’il y a aussi une panne de gousse ou de nœud en même temps, les nœuds de plan de contrôle devront récupérer avant que de nouveaux gousses ou nœuds puissent être ajoutés ou programmés.

L’ensemble des services fonctionnant sur les nœuds d’infrastructure sont configurés par Red Hat pour être hautement disponibles et distribués à travers les nœuds d’infrastructure. En cas de panne complète de l’infrastructure, ces services ne seront pas disponibles jusqu’à ce que ces nœuds aient été récupérés.

La défaillance d’une zone d’un fournisseur de cloud public affecte tous les composants virtuels, tels que les nœuds de travail, le blocage ou le stockage partagé, et les équilibreurs de charge spécifiques à une seule zone de disponibilité. Afin de se protéger contre une défaillance de zone, OpenShift Dedicated offre l’option pour les clusters qui sont répartis sur trois zones de disponibilité, appelées clusters de zone multidisponibilité. Les charges de travail apatrides existantes sont redistribuées dans des zones non affectées en cas de panne, tant qu’il y a suffisamment de capacité.

Lorsque vous avez déployé une application étatique, le stockage est un composant essentiel et doit être pris en compte lors de la réflexion sur la haute disponibilité. Le PV de stockage d’un seul bloc est incapable de résister aux pannes même au niveau de la pod. Les meilleurs moyens de maintenir la disponibilité du stockage sont d’utiliser des solutions de stockage répliquées, un stockage partagé qui n’est pas affecté par des pannes, ou un service de base de données indépendant du cluster.