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 sur SingleReplica. Dans le cas contraire, il est défini sur HighlyAvailable.
  • 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'état controlPlaneTopology.
  • 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 sur HighlyAvailable.

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)

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.