Chapitre 4. Les tâches d’administrateur


4.1. Ajout d’opérateurs à un cluster

En utilisant Operator Lifecycle Manager (OLM), les administrateurs ayant le rôle d’administrateur dédié peuvent installer des opérateurs basés sur OLM dans un service Red Hat OpenShift sur le cluster AWS.

Note

Des informations sur la façon dont OLM gère les mises à jour pour les opérateurs installés situés dans le même espace de noms, ainsi qu’une méthode alternative pour installer des Opérateurs avec des groupes d’opérateurs mondiaux personnalisés, voir Multitenancy and Operator colocation.

4.1.1. Installation de l’opérateur avec OperatorHub

OperatorHub est une interface utilisateur pour découvrir les Opérateurs ; elle fonctionne en collaboration avec Operator Lifecycle Manager (OLM), qui installe et gère les Opérateurs sur un cluster.

En tant qu’administrateur dédié, vous pouvez installer un opérateur depuis OperatorHub en utilisant le service Red Hat OpenShift sur la console Web AWS ou CLI. L’abonnement d’un opérateur à un ou plusieurs espaces de noms met l’opérateur à la disposition des développeurs de votre cluster.

Lors de l’installation, vous devez déterminer les paramètres initiaux suivants pour l’opérateur:

Le mode d’installation
Choisissez Tous les espaces de noms du cluster (par défaut) pour que l’Opérateur soit installé sur tous les espaces de noms ou choisissez des espaces de noms individuels, le cas échéant, pour installer uniquement l’Opérateur sur les espaces de noms sélectionnés. Cet exemple choisit tous les espaces de noms… pour mettre l’opérateur à la disposition de tous les utilisateurs et projets.
Canal de mise à jour
Lorsqu’un Opérateur est disponible via plusieurs canaux, vous pouvez choisir le canal auquel vous souhaitez vous abonner. À titre d’exemple, pour déployer à partir du canal stable, s’il est disponible, sélectionnez-le dans la liste.
La stratégie d’approbation

Choisissez des mises à jour automatiques ou manuelles.

Lorsque vous choisissez des mises à jour automatiques pour un opérateur installé, lorsqu’une nouvelle version de cet opérateur est disponible dans le canal sélectionné, Operator Lifecycle Manager (OLM) met automatiquement à niveau l’instance en cours d’exécution de votre opérateur sans intervention humaine.

Lorsque vous sélectionnez des mises à jour manuelles, lorsqu’une version plus récente d’un opérateur est disponible, OLM crée une demande de mise à jour. En tant qu’administrateur dédié, vous devez ensuite approuver manuellement cette demande de mise à jour pour que l’opérateur soit mis à jour vers la nouvelle version.

4.1.2. Installation depuis OperatorHub à l’aide de la console Web

Il est possible d’installer et de s’abonner à un opérateur depuis OperatorHub en utilisant le service Red Hat OpenShift sur la console web AWS.

Conditions préalables

  • Accès à un service Red Hat OpenShift sur le cluster AWS à l’aide d’un compte avec le rôle d’administrateur dédié.

Procédure

  1. Accédez à la console Web vers la page Opérateurs OperatorHub.
  2. Faites défiler ou tapez un mot clé dans la zone Filtrer par mot-clé pour trouver l’opérateur que vous souhaitez. À titre d’exemple, tapez avancé pour trouver la gestion avancée des clusters pour Kubernetes Operator.

    Il est également possible de filtrer les options par Infrastructure Features. À titre d’exemple, sélectionnez Déconnecté si vous souhaitez voir les opérateurs qui fonctionnent dans des environnements déconnectés, également connus sous le nom d’environnements réseau restreints.

  3. Choisissez l’opérateur pour afficher des informations supplémentaires.

    Note

    Choisir un opérateur communautaire avertit que Red Hat ne certifie pas les opérateurs communautaires; vous devez en tenir compte avant de continuer.

  4. Lisez les informations sur l’opérateur et cliquez sur Installer.
  5. Dans la page Installer l’opérateur, configurez l’installation de votre opérateur:

    1. Dans le cas où vous souhaitez installer une version spécifique d’un opérateur, sélectionnez un canal de mise à jour et une version dans les listes. Il est possible de parcourir les différentes versions d’un opérateur sur tous les canaux qu’il peut avoir, d’afficher les métadonnées de ce canal et de cette version, et de sélectionner la version exacte que vous souhaitez installer.

      Note

      La sélection de la version par défaut à la dernière version pour le canal sélectionné. Lorsque la dernière version du canal est sélectionnée, la stratégie d’approbation automatique est activée par défaut. Dans le cas contraire, l’approbation manuelle est requise lorsque vous n’installez pas la dernière version du canal sélectionné.

      L’installation d’un opérateur avec l’approbation manuelle fait que tous les opérateurs installés dans l’espace de noms fonctionnent avec la stratégie d’approbation manuelle et tous les opérateurs sont mis à jour ensemble. Dans le cas où vous souhaitez mettre à jour les Opérateurs de manière indépendante, installez les Opérateurs dans des espaces de noms distincts.

    2. Confirmez le mode d’installation de l’opérateur:

      • L’ensemble des espaces de noms du cluster (par défaut) 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. Cette option n’est pas toujours disponible.
      • L’espace de noms spécifique sur le cluster vous permet de choisir un espace de noms unique spécifique dans lequel installer l’opérateur. L’opérateur ne regardera et sera mis à disposition que dans cet espace de noms unique.
    3. Dans le cas des clusters sur les fournisseurs de cloud avec authentification de jetons activé:

      • Dans le cas où le cluster utilise AWS Security Token Service (mode STS dans la console Web), entrez le nom de ressource Amazon (ARN) du rôle AWS IAM de votre compte de service dans le champ ARN des rôles. Afin de créer l’ARN du rôle, suivez la procédure décrite dans Préparer le compte AWS.
      • Lorsque le cluster utilise Microsoft Entra Workload ID (Workload Identity / Federated Identity Mode dans la console Web), ajoutez l’ID client, l’ID du locataire et l’ID d’abonnement dans les champs appropriés.
      • Lorsque le cluster utilise Google Cloud Platform Workload Identity (GCP Workload Identity / Federated Identity) dans la console Web, ajoutez le numéro de projet, l’ID de pool, l’ID du fournisseur et l’e-mail de compte de service dans les champs appropriés.
    4. Dans le cas de l’approbation de mise à jour, sélectionnez soit la stratégie d’approbation automatique ou la stratégie d’approbation manuelle.

      Important

      Lorsque la console Web montre que le cluster utilise AWS STS, Microsoft Entra Workload ID ou GCP Workload Identity, vous devez définir l’approbation de mise à jour sur Manuel.

      Les abonnements avec approbation automatique pour les mises à jour ne sont pas recommandés car il peut y avoir des modifications d’autorisation à apporter avant la mise à jour. Les abonnements avec approbation manuelle pour les mises à jour garantissent que les administrateurs ont la possibilité de vérifier les autorisations de la version ultérieure, de prendre toutes les mesures nécessaires, puis de mettre à jour.

  6. Cliquez sur Installer pour rendre l’opérateur disponible dans les espaces de noms sélectionnés sur ce service OpenShift Red Hat sur AWS cluster:

    1. Lorsque vous avez sélectionné une stratégie d’approbation manuelle, l’état de mise à niveau de l’abonnement reste mis à jour jusqu’à ce que vous révisiez et approuvez le plan d’installation.

      Après avoir approuvé sur la page Plan d’installation, l’état de mise à jour de l’abonnement passe à jour.

    2. Lorsque vous avez sélectionné une stratégie d’approbation automatique, l’état de mise à jour doit être résolu à jour sans intervention.

La vérification

  • Après que l’état de mise à jour de l’abonnement soit mis à jour, sélectionnez Opérateurs installés Opérateurs installés pour vérifier que la version de service de cluster (CSV) de l’opérateur installé s’affiche finalement. Le Statut devrait éventuellement résoudre à Succeed dans l’espace de noms pertinent.

    Note

    Dans le mode d’installation de Tous les espaces de noms, l’état se résout à Succeed dans l’espace de noms openshift-operators, mais l’état est copié si vous vérifiez d’autres espaces de noms.

    Dans le cas contraire:

    • Consultez les journaux de tous les pods du projet openshift-operators (ou d’un autre espace de noms pertinent si un espace de noms spécifique…​ mode d’installation a été sélectionné) sur la page Charges de travail Pods qui signalent des problèmes à résoudre plus loin.
  • Lorsque l’opérateur est installé, les métadonnées indiquent quel canal et quelle version sont installées.

    Note

    Les menus déroulants Channel et Version sont toujours disponibles pour visualiser d’autres métadonnées de version dans ce contexte de catalogue.

4.1.3. Installation depuis OperatorHub en utilisant le CLI

Au lieu d’utiliser le service Red Hat OpenShift sur la console web AWS, vous pouvez installer un opérateur depuis OperatorHub en utilisant le CLI. La commande oc permet de créer ou de mettre à jour un objet d’abonnement.

Dans le cas du mode d’installation de SingleNamespace, vous devez également vous assurer qu’un groupe opérateur approprié existe dans l’espace de noms associé. Le groupe Opérateur, défini par un objet OperatorGroup, sélectionne les espaces de noms cibles dans lesquels générer l’accès RBAC requis pour tous les Opérateurs dans le même espace de noms que le groupe Opérateurs.

Astuce

Dans la plupart des cas, la méthode de la console web de cette procédure est préférée car elle automatise les tâches en arrière-plan, telles que la gestion automatique de la création d’objets OperatorGroup et Abonnement lors du choix du mode SingleNamespace.

Conditions préalables

  • Accès à un service Red Hat OpenShift sur le cluster AWS à l’aide d’un compte avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Consultez la liste des opérateurs disponibles pour le cluster de OperatorHub:

    $ oc get packagemanifests -n openshift-marketplace
    Copy to Clipboard

    Exemple 4.1. Exemple de sortie

    NAME                               CATALOG               AGE
    3scale-operator                    Red Hat Operators     91m
    advanced-cluster-management        Red Hat Operators     91m
    amq7-cert-manager                  Red Hat Operators     91m
    # ...
    couchbase-enterprise-certified     Certified Operators   91m
    crunchy-postgres-operator          Certified Operators   91m
    mongodb-enterprise                 Certified Operators   91m
    # ...
    etcd                               Community Operators   91m
    jaeger                             Community Operators   91m
    kubefed                            Community Operators   91m
    # ...
    Copy to Clipboard

    Indiquez le catalogue de votre opérateur souhaité.

  2. Inspectez l’opérateur souhaité pour vérifier les modes d’installation pris en charge et les canaux disponibles:

    $ oc describe packagemanifests <operator_name> -n openshift-marketplace
    Copy to Clipboard

    Exemple 4.2. Exemple de sortie

    # ...
    Kind:         PackageManifest
    # ...
          Install Modes: 
    1
    
            Supported:  true
            Type:       OwnNamespace
            Supported:  true
            Type:       SingleNamespace
            Supported:  false
            Type:       MultiNamespace
            Supported:  true
            Type:       AllNamespaces
    # ...
        Entries:
          Name:       example-operator.v3.7.11
          Version:    3.7.11
          Name:       example-operator.v3.7.10
          Version:    3.7.10
        Name:         stable-3.7 
    2
    
    # ...
       Entries:
          Name:         example-operator.v3.8.5
          Version:      3.8.5
          Name:         example-operator.v3.8.4
          Version:      3.8.4
        Name:           stable-3.8 
    3
    
      Default Channel:  stable-3.8 
    4
    Copy to Clipboard
    1
    Indique quels modes d’installation sont pris en charge.
    2 3
    Exemple de noms de canaux.
    4
    Le canal sélectionné par défaut si un canal n’est pas spécifié.
    Astuce

    Il est possible d’imprimer la version d’un opérateur et de canaliser les informations au format YAML en exécutant la commande suivante:

    $ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
    Copy to Clipboard
    • Lorsque plus d’un catalogue est installé dans un espace de noms, exécutez la commande suivante pour rechercher les versions et canaux disponibles d’un opérateur à partir d’un catalogue spécifique:

      $ oc get packagemanifest \
         --selector=catalog=<catalogsource_name> \
         --field-selector metadata.name=<operator_name> \
         -n <catalog_namespace> -o yaml
      Copy to Clipboard
      Important

      Dans le cas où vous ne spécifiez pas le catalogue de l’opérateur, l’exécution de l’oc get packagemanifest et la description des commandes de packagemanifest peuvent renvoyer un paquet à partir d’un catalogue inattendu si les conditions suivantes sont remplies:

      • Des catalogues multiples sont installés dans le même espace de noms.
      • Les catalogues contiennent les mêmes Opérateurs ou Opérateurs avec le même nom.
  3. Lorsque l’opérateur que vous avez l’intention d’installer prend en charge le mode d’installation d’AllNamespaces, et que vous choisissez d’utiliser ce mode, passez cette étape, car l’espace de noms openshift-operators dispose déjà d’un groupe d’opérateurs approprié en place par défaut, appelé global-operators.

    Lorsque l’opérateur que vous avez l’intention d’installer prend en charge le mode d’installation de SingleNamespace et que vous choisissez d’utiliser ce mode, vous devez vous assurer qu’un groupe d’opérateurs approprié existe dans l’espace de noms correspondant. Dans le cas contraire, vous pouvez en créer une en suivant les étapes suivantes:

    Important

    Il n’y a qu’un seul groupe d’opérateurs par espace de noms. Consultez « Groupes d’opérateurs » pour plus d’informations.

    1. Créer un fichier OperatorGroup objet YAML, par exemple operatorgroup.yaml, pour le mode d’installation SingleNamespace:

      Exemple d’objet OperatorGroup pour le mode d’installation de SingleNamespace

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace> 
      1
      
      spec:
        targetNamespaces:
        - <namespace> 
      2
      Copy to Clipboard

      1 2
      Dans le mode d’installation de SingleNamespace, utilisez la même valeur &lt;namespace&gt; pour les champs métadonnées.namespace et spec.targetNamespaces.
    2. Créer l’objet OperatorGroup:

      $ oc apply -f operatorgroup.yaml
      Copy to Clipboard
  4. Créer un objet d’abonnement pour abonner un espace de noms à un opérateur:

    1. Créer un fichier YAML pour l’objet Abonnement, par exemple subscription.yaml:

      Note

      Lorsque vous souhaitez vous abonner à une version spécifique d’un opérateur, définissez le champ StartCSV sur la version souhaitée et définissez le champ installPlanApproval sur Manuel pour empêcher l’opérateur de mettre à niveau automatiquement si une version ultérieure existe dans le catalogue. Afin de plus de détails, voir « Exemple Subscription objet avec une version de départ spécifique de l’opérateur ».

      Exemple 4.3. Exemple d’objet d’abonnement

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: <subscription_name>
        namespace: <namespace_per_install_mode> 
      1
      
      spec:
        channel: <channel_name> 
      2
      
        name: <operator_name> 
      3
      
        source: <catalog_name> 
      4
      
        sourceNamespace: <catalog_source_namespace> 
      5
      
        config:
          env: 
      6
      
          - name: ARGS
            value: "-v=10"
          envFrom: 
      7
      
          - secretRef:
              name: license-secret
          volumes: 
      8
      
          - name: <volume_name>
            configMap:
              name: <configmap_name>
          volumeMounts: 
      9
      
          - mountPath: <directory_name>
            name: <volume_name>
          tolerations: 
      10
      
          - operator: "Exists"
          resources: 
      11
      
            requests:
              memory: "64Mi"
              cpu: "250m"
            limits:
              memory: "128Mi"
              cpu: "500m"
          nodeSelector: 
      12
      
            foo: bar
      Copy to Clipboard
      1
      Dans le cas de l’utilisation par défaut du mode d’installation d’AllNamespaces, spécifiez l’espace de noms openshift-operators. Alternativement, vous pouvez spécifier un espace de noms global personnalisé, si vous en avez créé un. Dans le cas de l’utilisation du mode d’installation de SingleNamespace, spécifiez l’espace de noms unique pertinent.
      2
      Le nom du canal auquel s’abonner.
      3
      Le nom de l’opérateur auquel s’abonner.
      4
      Le nom de la source du catalogue qui fournit l’opérateur.
      5
      Espace de noms de la source du catalogue. Utilisez openshift-marketplace pour les sources de catalogue OperatorHub par défaut.
      6
      Le paramètre env définit une liste de variables d’environnement qui doivent exister dans tous les conteneurs dans la pod créée par OLM.
      7
      Le paramètre envFrom définit une liste de sources pour peupler les variables d’environnement dans le conteneur.
      8
      Le paramètre volumes définit une liste de volumes qui doivent exister sur le pod créé par OLM.
      9
      Le paramètre VolumeMounts définit une liste de montages de volume qui doivent exister dans tous les conteneurs dans la pod créée par OLM. Lorsqu’un volumeMount fait référence à un volume qui n’existe pas, OLM ne parvient pas à déployer l’opérateur.
      10
      Le paramètre de tolérance définit une liste de tolérances pour le pod créé par OLM.
      11
      Le paramètre des ressources définit les contraintes de ressources pour tous les conteneurs dans la pod créée par OLM.
      12
      Le paramètre nodeSelector définit un NodeSelector pour le pod créé par OLM.

      Exemple 4.4. Exemple Objet d’abonnement avec une version de départ spécifique de l’opérateur

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: example-operator
        namespace: example-operator
      spec:
        channel: stable-3.7
        installPlanApproval: Manual 
      1
      
        name: example-operator
        source: custom-operators
        sourceNamespace: openshift-marketplace
        startingCSV: example-operator.v3.7.10 
      2
      Copy to Clipboard
      1
      Définissez la stratégie d’approbation sur Manuel dans le cas où votre version spécifiée est remplacée par une version ultérieure dans le catalogue. Ce plan empêche une mise à niveau automatique vers une version ultérieure et nécessite une approbation manuelle avant que le CSV de démarrage puisse terminer l’installation.
      2
      Définissez une version spécifique d’un opérateur CSV.
    2. Dans le cas des clusters sur les fournisseurs de cloud avec authentification de jetons activés, tels que Amazon Web Services (AWS) Security Token Service (STS), Microsoft Entra Workload ID, ou Google Cloud Platform Workload Identity, configurez votre objet Abonnement en suivant ces étapes:

      1. Assurez-vous que l’objet Abonnement est configuré pour les approbations manuelles de mise à jour:

        Exemple 4.5. Exemple Objet d’abonnement avec approbations manuelles de mise à jour

        kind: Subscription
        # ...
        spec:
          installPlanApproval: Manual 
        1
        Copy to Clipboard
        1
        Les abonnements avec approbation automatique pour les mises à jour ne sont pas recommandés car il peut y avoir des modifications d’autorisation à apporter avant la mise à jour. Les abonnements avec approbation manuelle pour les mises à jour garantissent que les administrateurs ont la possibilité de vérifier les autorisations de la version ultérieure, de prendre toutes les mesures nécessaires, puis de mettre à jour.
      2. Inclure les champs spécifiques aux fournisseurs de cloud pertinents dans la section Configuration de l’objet Abonnement:

        • Lorsque le cluster est en mode AWS STS, incluez les champs suivants:

          Exemple 4.6. Exemple d’objet d’abonnement avec des variables AWS STS

          kind: Subscription
          # ...
          spec:
            config:
              env:
              - name: ROLEARN
                value: "<role_arn>" 
          1
          Copy to Clipboard
          1
          Inclure le rôle ARN détails.
        • Lorsque le cluster est en mode ID de charge de travail, incluez les champs suivants:

          Exemple 4.7. Exemple Objet d’abonnement avec des variables ID de charge de travail

          kind: Subscription
          # ...
          spec:
           config:
             env:
             - name: CLIENTID
               value: "<client_id>" 
          1
          
             - name: TENANTID
               value: "<tenant_id>" 
          2
          
             - name: SUBSCRIPTIONID
               value: "<subscription_id>" 
          3
          Copy to Clipboard
          1
          Inclure l’identifiant du client.
          2
          Inclure l’identifiant du locataire.
          3
          Inclure l’identifiant d’abonnement.
        • Lorsque le cluster est en mode Identité de charge de travail GCP, incluez les champs suivants:

          Exemple 4.8. Exemple d’objet d’abonnement avec des variables d’identité de charge de travail GCP

          kind: Subscription
          # ...
          spec:
           config:
             env:
             - name: AUDIENCE
               value: "<audience_url>" 
          1
          
             - name: SERVICE_ACCOUNT_EMAIL
               value: "<service_account_email>" 
          2
          Copy to Clipboard

          là où:

          &lt;audience&gt;

          Créée en GCP par l’administrateur lors de la configuration de GCP Workload Identity, la valeur AUDIENCE doit être une URL préformatée dans le format suivant:

          //iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>
          Copy to Clipboard
          &lt;service_account_email&gt;

          La valeur SERVICE_ACCOUNT_EMAIL est un e-mail de compte de service GCP qui est usurpé lors de l’exploitation de l’opérateur, par exemple:

          <service_account_name>@<project_id>.iam.gserviceaccount.com
          Copy to Clipboard
    3. Créez l’objet Abonnement en exécutant la commande suivante:

      $ oc apply -f subscription.yaml
      Copy to Clipboard
  5. Lorsque vous définissez le champ installPlanApproval sur Manuel, approuver manuellement le plan d’installation en attente pour terminer l’installation de l’opérateur. En savoir plus, voir « Approuver manuellement une mise à jour de l’opérateur en attente ».

À ce stade, OLM est maintenant au courant de l’opérateur sélectionné. La version de service de cluster (CSV) pour l’opérateur devrait apparaître dans l’espace de noms cible, et les API fournies par l’opérateur devraient être disponibles pour la création.

La vérification

  1. Consultez l’état de l’objet Abonnement pour votre opérateur installé en exécutant la commande suivante:

    $ oc describe subscription <subscription_name> -n <namespace>
    Copy to Clipboard
  2. Lorsque vous avez créé un groupe d’opérateurs pour le mode d’installation de SingleNamespace, vérifiez l’état de l’objet OperatorGroup en exécutant la commande suivante:

    $ oc describe operatorgroup <operatorgroup_name> -n <namespace>
    Copy to Clipboard

4.1.4. La préparation de plusieurs instances d’un opérateur pour les clusters multilocataires

En tant qu’administrateur avec le rôle d’administrateur dédié, vous pouvez ajouter plusieurs instances d’un opérateur pour une utilisation dans des clusters multilocataires. Il s’agit d’une solution alternative à l’utilisation du mode d’installation standard Tous les espaces de noms, qui peut être considéré comme violant le principe du moindre privilège, ou le mode Multinamespace, qui n’est pas largement adopté. En savoir plus, voir « Opérations en grappes multilocataires ».

Dans la procédure suivante, le locataire est un utilisateur ou un groupe d’utilisateurs qui partagent un accès et des privilèges communs pour un ensemble de charges de travail déployées. L’opérateur locataire est l’instance d’un opérateur qui est destiné à être utilisé uniquement par ce locataire.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • Chaque instance de l’opérateur que vous souhaitez installer doit être la même version sur un cluster donné.

    Important

    Afin d’obtenir de plus amples renseignements sur cette question et sur d’autres limites, voir « Opérations en grappes multilocataires ».

Procédure

  1. Avant d’installer l’opérateur, 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. Ainsi, si l’espace de noms du locataire est team1, vous pouvez créer un projet team1-operator:

    $ oc new-project team1-operator
    Copy to Clipboard
  2. Créer un groupe d’opérateurs pour le locataire Opérateur étendu à l’espace de noms du locataire, avec seulement une entrée d’espace de noms dans la liste spec.targetNamespaces:

    1. Définissez une ressource OperatorGroup et enregistrez le fichier YAML, par exemple team1-operatorgroup.yaml:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: team1-operatorgroup
        namespace: team1-operator
      spec:
        targetNamespaces:
        - team1 
      1
      Copy to Clipboard
      1 1
      Définissez uniquement l’espace de noms du locataire dans la liste spec.targetNamespaces.
    2. Créez le groupe Opérateur en exécutant la commande suivante:

      $ oc create -f team1-operatorgroup.yaml
      Copy to Clipboard

Les prochaines étapes

  • Installez l’opérateur dans l’espace de noms de l’opérateur locataire. Cette tâche est plus facile à effectuer en utilisant le OperatorHub dans la console Web au lieu du CLI; pour une procédure détaillée, voir Installing from OperatorHub à l’aide de la console Web.

    Note

    Après avoir terminé l’installation de l’Opérateur, 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.

4.1.5. Installation d’opérateurs globaux dans des espaces de noms personnalisés

Lors de l’installation des opérateurs avec le service Red Hat OpenShift sur la console Web AWS, le comportement par défaut installe les opérateurs qui prennent en charge le mode d’installation de Tous les espaces de noms dans l’espace de noms global openshift-operators par défaut. Cela peut causer des problèmes liés aux plans d’installation partagés et aux stratégies de mise à jour entre tous les opérateurs dans l’espace de noms. En savoir plus sur ces limitations, voir « Multiculturalité et colocation de l’opérateur ».

En tant qu’administrateur avec le rôle d’administrateur dédié, vous pouvez contourner manuellement ce comportement par défaut en créant un espace de noms global personnalisé et en utilisant cet espace de noms pour installer votre ensemble individuel ou étendu d’opérateurs et leurs dépendances.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.

Procédure

  1. Avant d’installer l’opérateur, créez un espace de noms pour l’installation de votre opérateur souhaité. C’est ce que vous pouvez faire en créant un projet. L’espace de noms de ce projet deviendra l’espace de noms global personnalisé:

    $ oc new-project global-operators
    Copy to Clipboard
  2. Créer un groupe d’opérateurs mondial personnalisé, qui est un groupe d’opérateurs qui surveille tous les espaces de noms:

    1. Définissez une ressource OperatorGroup et enregistrez le fichier YAML, par exemple global-operatorgroup.yaml. Évitez les champs spec.selector et spec.targetNamespaces pour en faire un groupe d’opérateur global, qui sélectionne tous les espaces de noms:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: global-operatorgroup
        namespace: global-operators
      Copy to Clipboard
      Note

      Le status.namespaces d’un groupe d’opérateur mondial créé contient la chaîne vide (""), qui signale à un opérateur consommant qu’il devrait regarder tous les espaces de noms.

    2. Créez le groupe Opérateur en exécutant la commande suivante:

      $ oc create -f global-operatorgroup.yaml
      Copy to Clipboard

Les prochaines étapes

  • Installez l’opérateur souhaité dans votre espace de noms global personnalisé. Étant donné que la console Web ne remplit pas le menu Namespace installé pendant l’installation de l’opérateur avec des espaces de noms globaux personnalisés, cette tâche ne peut être effectuée qu’avec l’OpenShift CLI (oc). Dans le cas d’une procédure détaillée, voir Installing from OperatorHub à l’aide du CLI.

    Note

    Lorsque vous lancez l’installation de l’opérateur, si l’opérateur a des dépendances, les dépendances sont également installées automatiquement dans l’espace de noms global personnalisé. En conséquence, il est alors valable pour les opérateurs de dépendance d’avoir la même stratégie de mise à jour et des plans d’installation partagés.

4.1.6. Emplacement de la pod des charges de travail de l’opérateur

Le gestionnaire de cycle de vie de l’opérateur (OLM) place des pods sur des nœuds de travail arbitraires lors de l’installation d’un opérateur ou du déploiement de charges de travail Operand. En tant qu’administrateur, vous pouvez utiliser des projets avec une combinaison de sélecteurs de nœuds, de taintes et de tolérances pour contrôler le placement des Opérateurs et Operands sur des nœuds spécifiques.

Le contrôle du placement des pods des charges de travail de l’opérateur et de l’exploitation comporte les conditions préalables suivantes:

  1. Déterminez un nœud ou un ensemble de nœuds à cibler pour les gousses selon vos besoins. Le cas échéant, notez une étiquette existante, telle que node-role.kubernetes.io/app, qui identifie le nœud ou les nœuds. Dans le cas contraire, ajoutez une étiquette, telle que myoperator, en utilisant un ensemble de machines de calcul ou en éditant directement le nœud. Dans une étape ultérieure, vous utiliserez cette étiquette comme sélecteur de nœud sur votre projet.
  2. Lorsque vous voulez vous assurer que seuls les pods avec une certaine étiquette sont autorisés à fonctionner sur les nœuds, tout en dirigeant des charges de travail non liées à d’autres nœuds, ajoutez un taint au nœud ou aux nœuds en utilisant un ensemble de machines de calcul ou en éditant le nœud directement. Faites appel à un effet qui garantit que les nouveaux pods qui ne correspondent pas à la tainte ne peuvent pas être programmés sur les nœuds. À titre d’exemple, une tainte myoperator:NoSchedule garantit que les nouveaux pods qui ne correspondent pas à la tainte ne sont pas programmés sur ce nœud, mais les gousses existantes sur le nœud sont autorisées à rester.
  3. Créez un projet configuré avec un sélecteur de nœud par défaut et, si vous avez ajouté une tainte, une tolérance correspondante.

À ce stade, le projet que vous avez créé peut être utilisé pour orienter les pods vers les nœuds spécifiés dans les scénarios suivants:

Les pods d’opérateur
Les administrateurs peuvent créer un objet d’abonnement dans le projet comme décrit dans la section suivante. En conséquence, les pods d’opérateur sont placés sur les nœuds spécifiés.
Les gousses d’opérand
À l’aide d’un opérateur installé, les utilisateurs peuvent créer une application dans le projet, qui place la ressource personnalisée (CR) détenue par l’opérateur dans le projet. En conséquence, les pods Operand sont placés sur les nœuds spécifiés, sauf si l’Opérateur déploie des objets ou des ressources à l’échelle du cluster dans d’autres espaces de noms, auquel cas ce placement de pod personnalisé ne s’applique pas.

4.1.7. Contrôler l’endroit où un opérateur est installé

Lorsque vous installez un opérateur, Red Hat OpenShift Service sur AWS installe par défaut la pod d’opérateur sur l’un de vos nœuds de travail au hasard. Cependant, il peut y avoir des situations où vous voulez que ce pod soit programmé sur un nœud spécifique ou un ensemble de nœuds.

Les exemples suivants décrivent des situations où vous voudrez peut-être planifier un pod d’opérateur à un nœud spécifique ou à un ensemble de nœuds:

  • Les opérateurs qui travaillent ensemble sur le même hôte ou sur des hôtes situés sur le même rack
  • · si vous voulez que les opérateurs soient dispersés dans toute l’infrastructure pour éviter les temps d’arrêt en raison de problèmes de réseau ou de matériel

Il est possible de contrôler l’installation d’une pod d’opérateur en ajoutant des contraintes d’affinité des nœuds, d’affinité de pod ou de pod anti-affinité à l’objet Abonnement de l’opérateur. L’affinité des nœuds est un ensemble de règles utilisées par le planificateur pour déterminer où un pod peut être placé. L’affinité de pod vous permet de vous assurer que les gousses associées sont programmées au même nœud. La pod anti-affinité vous permet d’empêcher une gousse d’être programmée sur un nœud.

Les exemples suivants montrent comment utiliser l’affinité des nœuds ou la pod anti-affinité pour installer une instance du Custom Metrics Autoscaler Operator à un nœud spécifique dans le cluster:

Exemple d’affinité des nœuds qui place la pod de l’opérateur sur un nœud spécifique

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity: 
1

        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-163-94.us-west-2.compute.internal
#...
Copy to Clipboard

1
Affinité du nœud qui exige que la gousse de l’opérateur soit programmée sur un nœud nommé ip-10-0-163-94.us-west-2.compute.internal.

Exemple d’affinité des nœuds qui place le pod de l’opérateur sur un nœud avec une plate-forme spécifique

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity: 
1

        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/arch
              operator: In
              values:
              - arm64
            - key: kubernetes.io/os
              operator: In
              values:
              - linux
#...
Copy to Clipboard

1
Affinité du nœud qui exige que la gousse de l’opérateur soit programmée sur un nœud avec les étiquettes kubernetes.io/arch=arm64 et kubernetes.io/os=linux.

Exemple d’affinité de pod qui place la pod de l’opérateur sur un ou plusieurs nœuds spécifiques

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAffinity: 
1

        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - test
          topologyKey: kubernetes.io/hostname
#...
Copy to Clipboard

1
Affinité de pod qui place la gousse de l’opérateur sur un nœud qui a des pods avec l’étiquette app=test.

Exemple de pod anti-affinité qui empêche la gousse d’opérateur d’un ou de plusieurs nœuds spécifiques

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAntiAffinity: 
1

        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: cpu
              operator: In
              values:
              - high
          topologyKey: kubernetes.io/hostname
#...
Copy to Clipboard

1
La pod anti-affinité qui empêche la gousse de l’opérateur d’être programmée sur un nœud qui a des pods avec l’étiquette cpu=haute.

Procédure

Afin de contrôler le placement d’une gousse d’opérateur, remplissez les étapes suivantes:

  1. Installez l’opérateur comme d’habitude.
  2. Au besoin, assurez-vous que vos nœuds sont étiquetés pour répondre correctement à l’affinité.
  3. Éditer l’objet d’abonnement opérateur pour ajouter une affinité:

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: openshift-custom-metrics-autoscaler-operator
      namespace: openshift-keda
    spec:
      name: my-package
      source: my-operators
      sourceNamespace: operator-registries
      config:
        affinity: 
    1
    
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                  - ip-10-0-185-229.ec2.internal
    #...
    Copy to Clipboard
    1
    Ajouter un nodeAffinity, podAffinity ou podAntiAffinity. Consultez la section Ressources supplémentaires qui suit pour obtenir de l’information sur la création de l’affinité.

La vérification

  • Afin de s’assurer que le pod est déployé sur le nœud spécifique, exécutez la commande suivante:

    $ oc get pods -o wide
    Copy to Clipboard

    Exemple de sortie

    NAME                                                  READY   STATUS    RESTARTS   AGE   IP            NODE                           NOMINATED NODE   READINESS GATES
    custom-metrics-autoscaler-operator-5dcc45d656-bhshg   1/1     Running   0          50s   10.131.0.20   ip-10-0-185-229.ec2.internal   <none>           <none>
    Copy to Clipboard

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