Chapitre 4. Les tâches d’administrateur

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 mettre l’opérateur à la disposition des espaces de noms sélectionnés sur ce cluster dédié OpenShift:

   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.

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 <namespace> 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ù:

           <audience>

           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

           <service_account_email>

           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 ».

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

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

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

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.

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é.