5.12. Détection et prise en charge des clusters à haute disponibilité ou à nœud unique
Un cluster OpenShift Container Platform peut être configuré en mode haute disponibilité (HA), qui utilise plusieurs nœuds, ou en mode non-HA, qui utilise un seul nœud. Un cluster à nœud unique, également connu sous le nom d'OpenShift à nœud unique, est susceptible d'avoir des contraintes de ressources plus conservatrices. Par conséquent, il est important que les opérateurs installés sur un cluster à nœud unique puissent s'adapter en conséquence et continuer à bien fonctionner.
En accédant à l'API du mode de haute disponibilité du cluster fournie dans OpenShift Container Platform, les auteurs d'opérateurs peuvent utiliser le SDK de l'opérateur pour permettre à leur opérateur de détecter la topologie de l'infrastructure d'un cluster, que ce soit en mode HA ou non HA. Il est possible de développer une logique d'opérateur personnalisée qui utilise la topologie de cluster détectée pour basculer automatiquement les besoins en ressources, à la fois pour l'opérateur et pour tous les opérateurs ou charges de travail qu'il gère, vers un profil qui correspond le mieux à la topologie.
5.12.1. À propos de l'API du mode de haute disponibilité des clusters
OpenShift Container Platform fournit une API de mode de haute disponibilité de cluster qui peut être utilisée par les opérateurs pour aider à détecter la topologie de l'infrastructure. L'API Infrastructure contient des informations sur l'infrastructure à l'échelle du cluster. Les opérateurs gérés par Operator Lifecycle Manager (OLM) peuvent utiliser l'API Infrastructure s'ils ont besoin de configurer un Operand ou une charge de travail gérée différemment en fonction du mode de haute disponibilité.
Dans l'API Infrastructure, le statut infrastructureTopology
exprime les attentes pour les services d'infrastructure qui ne s'exécutent pas sur les nœuds du plan de contrôle, généralement indiqués par un sélecteur de nœud pour une valeur role
autre que master
. Le statut controlPlaneTopology
exprime les attentes pour les opérandes qui s'exécutent normalement sur les nœuds du plan de contrôle.
Le paramètre par défaut pour l'un ou l'autre état est HighlyAvailable
, ce qui représente le comportement des opérateurs dans les clusters à plusieurs nœuds. Le paramètre SingleReplica
est utilisé dans les clusters à nœud unique, également connus sous le nom d'OpenShift à nœud unique, et indique que les opérateurs ne doivent pas configurer leurs Operands pour un fonctionnement en haute disponibilité.
Le programme d'installation d'OpenShift Container Platform définit les champs d'état controlPlaneTopology
et infrastructureTopology
en fonction du nombre de répliques du cluster lors de sa création, conformément aux règles suivantes :
-
Lorsque le nombre de répliques du plan de contrôle est inférieur à 3, l'état
controlPlaneTopology
est défini surSingleReplica
. Dans le cas contraire, il est défini surHighlyAvailable
. -
Lorsque le nombre de répliques de travailleurs est égal à 0, les nœuds du plan de contrôle sont également configurés en tant que travailleurs. Par conséquent, l'état
infrastructureTopology
sera le même que l'étatcontrolPlaneTopology
. -
Lorsque le nombre de répliques de travailleurs est égal à 1, la valeur de
infrastructureTopology
est fixée àSingleReplica
. Dans le cas contraire, il est défini surHighlyAvailable
.
5.12.2. Exemple d'utilisation de l'API dans les projets d'opérateurs
En tant qu'auteur d'Operator, vous pouvez mettre à jour votre projet Operator pour accéder à l'API d'infrastructure en utilisant des constructions Kubernetes normales et la bibliothèque controller-runtime
, comme le montrent les exemples suivants :
controller-runtime
exemple de bibliothèque
// Simple query nn := types.NamespacedName{ Name: "cluster", } infraConfig := &configv1.Infrastructure{} err = crClient.Get(context.Background(), nn, infraConfig) if err != nil { return err } fmt.Printf("using crclient: %v\n", infraConfig.Status.ControlPlaneTopology) fmt.Printf("using crclient: %v\n", infraConfig.Status.InfrastructureTopology)
Exemple de construction de Kubernetes
operatorConfigInformer := configinformer.NewSharedInformerFactoryWithOptions(configClient, 2*time.Second) infrastructureLister = operatorConfigInformer.Config().V1().Infrastructures().Lister() infraConfig, err := configClient.ConfigV1().Infrastructures().Get(context.Background(), "cluster", metav1.GetOptions{}) if err != nil { return err } // fmt.Printf("%v\n", infraConfig) fmt.Printf("%v\n", infraConfig.Status.ControlPlaneTopology) fmt.Printf("%v\n", infraConfig.Status.InfrastructureTopology)