Chapitre 2. Définition des politiques et des services

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 peut protéger contre les problèmes avec n’importe quel pod ou conteneur individuel. Le programmeur de nœud OpenShift 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 des commandes oc telles que d’autres types d’objets. Ils permettent de spécifier les 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 ROSA dispose d’un minimum de deux 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 une plus grande protection contre les pannes d’un seul nœud et assure une capacité de cluster appropriée pour les gousses reprogrammées en cas de défaillance du nœud.

Les clusters ROSA monoAZ ont au moins trois avions de contrôle et deux nœuds d’infrastructure dans la même zone de disponibilité (AZ) dans le sous-réseau privé.

Les clusters ROSA multi-AZ ont au moins trois nœuds de plan de contrôle et trois nœuds d’infrastructure qui sont préconfigurés pour une haute disponibilité, soit dans une seule zone, soit sur plusieurs zones, selon le type de cluster que vous avez sélectionné. Le plan de contrôle et les nœuds d’infrastructure ont la même résilience que les 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 du plan de contrôle, les API OpenShift ne fonctionneront pas, et les pods de nœuds existants ne sont pas affectés. Cependant, s’il y a aussi une panne de pod ou de nœud en même temps, les plans de contrôle doivent 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 sont pas disponibles jusqu’à ce que ces nœuds aient été récupérés.

La défaillance de la zone AWS 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, ROSA offre l’option pour les clusters qui sont répartis sur trois zones de disponibilité, connues sous le nom de clusters de zones de disponibilité multiples. 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.