Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

2.7. Opérateurs en clusters multilocataires

Le comportement par défaut pour Operator Lifecycle Manager (OLM) vise à fournir une simplicité lors de l’installation de l’opérateur. Cependant, ce comportement peut manquer de flexibilité, en particulier dans les clusters multilocataires. Afin que plusieurs locataires d’un Red Hat OpenShift Service sur AWS cluster utilisent un opérateur, le comportement par défaut de OLM exige que les administrateurs installent l’opérateur en mode Tous les espaces de noms, ce qui peut être considéré comme violant le principe du moindre privilège.

Considérez les scénarios suivants pour déterminer quel flux de travail d’installation de l’opérateur fonctionne le mieux pour votre environnement et vos exigences.

Lors de l’installation d’opérateurs avec la console Web en tant qu’administrateur, vous avez généralement deux choix pour le mode d’installation, en fonction des capacités de l’opérateur:

Espace de noms unique
Installe l’Opérateur dans l’espace de noms unique choisi et met à disposition toutes les autorisations que l’Opérateur demande dans cet espace de noms.
L’ensemble des espaces de noms
Installe l’opérateur dans l’espace de noms openshift-operators par défaut pour regarder et être mis à la disposition de tous les espaces de noms du cluster. Fournit toutes les autorisations demandées par l’Opérateur dans tous les espaces de noms. Dans certains cas, un auteur de l’opérateur peut définir des métadonnées pour donner à l’utilisateur une deuxième option pour l’espace de noms suggéré par cet opérateur.

Ce choix signifie également que les utilisateurs des espaces de noms concernés ont accès aux API Opérateurs, qui peuvent tirer parti des ressources personnalisées (CR) qu’ils possèdent, en fonction de leur rôle dans l’espace de noms:

  • Les rôles namespace-admin et namespace-edit peuvent lire/écrire dans les API de l’opérateur, ce qui signifie qu’ils peuvent les utiliser.
  • Le rôle d’affichage de l’espace de noms peut lire les objets CR de cet opérateur.

En mode espace de noms unique, parce que l’opérateur lui-même installe dans l’espace de noms choisi, son compte pod et service y sont également situés. Dans tous les modes d’espaces de noms, les privilèges de l’opérateur sont tous automatiquement élevés à des rôles de cluster, ce qui signifie que l’opérateur a ces autorisations dans tous les espaces de noms.

Bien qu’un mode d’installation Multinamespace existe, il est pris en charge par très peu d’opérateurs. En tant que solution intermédiaire entre tous les espaces de noms standard et les modes d’installation de l’espace de noms unique, vous pouvez installer plusieurs instances du même opérateur, une pour chaque locataire, en utilisant le flux de travail suivant:

  1. Créez un espace de noms pour l’opérateur locataire qui est séparé de l’espace de noms du locataire. C’est ce que vous pouvez faire en créant un projet.
  2. Créer un groupe d’opérateurs pour le locataire Opérateur étendu uniquement à l’espace de noms du locataire.
  3. Installez l’opérateur dans l’espace de noms de l’opérateur locataire.

En conséquence, l’Opérateur réside dans l’espace de noms de l’opérateur locataire et surveille l’espace de noms du locataire, mais ni la pod de l’Opérateur ni son compte de service ne sont visibles ou utilisables par le locataire.

Cette solution offre une meilleure séparation des locataires, moins un principe de privilège au coût de l’utilisation des ressources, et une orchestration supplémentaire pour s’assurer que les contraintes sont respectées. Dans le cas d’une procédure détaillée, voir « Préparation de multiples instances d’un opérateur pour les clusters multilocataires ».

Limites et considérations

Cette solution ne fonctionne que lorsque les contraintes suivantes sont remplies:

  • Chaque instance d’un même opérateur doit être la même version.
  • L’opérateur ne peut pas avoir de dépendances à l’égard d’autres opérateurs.
  • L’opérateur ne peut pas expédier un webhook de conversion CRD.
Important

Il est impossible d’utiliser différentes versions du même opérateur sur le même cluster. Finalement, l’installation d’une autre instance de l’opérateur serait bloquée lorsqu’elle remplit les conditions suivantes:

  • L’instance n’est pas la version la plus récente de l’opérateur.
  • L’instance expédie une révision plus ancienne des CRD qui manquent d’informations ou de versions que les révisions les plus récentes ont déjà utilisées sur le cluster.

2.7.3. Colocation d’opérateurs et groupes d’opérateurs
Copier lien

Le gestionnaire de cycle de vie de l’opérateur (OLM) gère les opérateurs gérés par OLM qui sont installés dans le même espace de noms, ce qui signifie que leurs ressources d’abonnement sont situées dans le même espace de noms, que les opérateurs associés. Bien qu’ils ne soient pas réellement liés, OLM considère leurs états, tels que leur version et leur politique de mise à jour, lorsque l’un d’entre eux est mis à jour.

Afin d’obtenir de plus amples informations sur la colocation de l’opérateur et l’utilisation efficace des groupes d’opérateurs, consultez Operator Lifecycle Manager (OLM) Multitenancy and Operator colocation.

Retour au début
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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2025 Red Hat