Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

5.7. En travaillant avec des images groupées

Il est possible d’utiliser le SDK de l’opérateur pour emballer, déployer et mettre à niveau les Opérateurs dans le format bundle pour les utiliser sur Operator Lifecycle Manager (OLM).

Important

La version prise en charge par Red Hat de l’outil Operator SDK CLI, y compris les outils d’échafaudage et de test connexes pour les projets Opérateur, est dépréciée et devrait être supprimée dans une future version de Red Hat OpenShift Service sur AWS. Le Red Hat fournira des corrections de bogues et une prise en charge de cette fonctionnalité pendant le cycle de vie de la version actuelle, mais cette fonctionnalité ne recevra plus d’améliorations et sera supprimée du futur service Red Hat OpenShift sur les versions AWS.

La version prise en charge par Red Hat du SDK de l’opérateur n’est pas recommandée pour la création de nouveaux projets d’opérateur. Les auteurs d’opérateurs avec des projets d’opérateur existants peuvent utiliser la version de l’outil Operator SDK CLI publié avec Red Hat OpenShift Service sur AWS 4 pour maintenir leurs projets et créer des versions d’opérateur ciblant de nouvelles versions de Red Hat OpenShift Service sur AWS.

Les images de base suivantes pour les projets d’opérateur ne sont pas dépréciées. Les fonctionnalités d’exécution et les API de configuration de ces images de base sont toujours prises en charge pour les corrections de bogues et pour l’adressage des CVE.

  • L’image de base pour les projets d’opérateurs basés sur Ansible
  • L’image de base pour les projets d’opérateur basé sur Helm

Afin d’obtenir de l’information sur la version non prise en charge et gérée par la communauté du SDK de l’opérateur, voir Operator SDK (Operator Framework).

5.7.1. Groupement d’un opérateur
Copier lien

Le format de paquet Opérateur est la méthode d’emballage par défaut pour Operator SDK et Operator Lifecycle Manager (OLM). En utilisant le SDK de l’opérateur, vous pouvez préparer votre opérateur à une utilisation sur OLM pour construire et pousser votre projet Opérateur en tant qu’image groupée.

Conditions préalables

  • L’opérateur SDK CLI installé sur un poste de travail de développement
  • Installation d’OpenShift CLI (oc) v4+
  • Le projet d’opérateur initialisé à l’aide du SDK de l’opérateur
  • Dans le cas où votre opérateur est Go-based, votre projet doit être mis à jour pour utiliser les images prises en charge pour s’exécuter sur Red Hat OpenShift Service sur AWS

Procédure

  1. Exécutez les commandes suivantes dans votre répertoire de projet Opérateur pour construire et pousser l’image de votre opérateur. Modifiez l’argument IMG dans les étapes suivantes pour faire référence à un référentiel auquel vous avez accès. Il est possible d’obtenir un compte de stockage des conteneurs sur des sites de dépôt tels que Quay.io.

    1. Construire l’image: 

      $ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>
      Copy to Clipboard Toggle word wrap
      Note

      Le Dockerfile généré par le SDK pour l’opérateur renvoie explicitement GOARCH=amd64 pour la construction de go. Cela peut être modifié à GOARCH=$TARGETARCH pour les architectures non-AMD64. Docker définira automatiquement la variable d’environnement à la valeur spécifiée par -platform. Avec Buildah, le -build-arg devra être utilisé à cet effet. En savoir plus, consultez Multiple Architectures.

    2. Appuyez sur l’image vers un référentiel: 

      $ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>
      Copy to Clipboard Toggle word wrap

  2. Créez votre paquet Opérateur manifeste en exécutant la commande make bundle, qui invoque plusieurs commandes, y compris l’opérateur SDK génère des paquets et des sous-commandes validant: 

    $ make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>
    Copy to Clipboard Toggle word wrap

    Les manifestes de paquets pour un opérateur décrivent comment afficher, créer et gérer une application. La commande make bundle crée les fichiers et répertoires suivants dans votre projet Opérateur:

    • Le bundle manifeste un répertoire nommé bundle/manifests qui contient un objet ClusterServiceVersion
    • Annuaire de métadonnées groupé nommé bundle/metadata
    • L’ensemble des définitions de ressources personnalisées (CRD) dans un répertoire config/crd
    • Dockerfile bundle.Dockerfile

    Ces fichiers sont ensuite automatiquement validés en utilisant le bundle opérateur-sdk valide pour s’assurer que la représentation des faisceaux sur disque est correcte.

  3. Créez et poussez votre image de paquet en exécutant les commandes suivantes. L’OLM consomme des faisceaux d’opérateurs à l’aide d’une image d’index, qui référence à une ou plusieurs images groupées.

    1. Construisez l’image du bundle. Définissez BUNDLE_IMG avec les détails du registre, de l’espace de noms d’utilisateur et de la balise d’image où vous avez l’intention de pousser l’image: 

      $ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>
      Copy to Clipboard Toggle word wrap

    2. Appuyez sur l’image du paquet: 

      $ docker push <registry>/<user>/<bundle_image_name>:<tag>
      Copy to Clipboard Toggle word wrap

Le gestionnaire de cycle de vie de l’opérateur (OLM) vous aide à installer, mettre à jour et gérer le cycle de vie des Opérateurs et de leurs services associés sur un cluster Kubernetes. Le système OLM est installé par défaut sur Red Hat OpenShift Service sur AWS et s’exécute sous forme d’extension Kubernetes afin que vous puissiez utiliser la console Web et OpenShift CLI (oc) pour toutes les fonctions de gestion du cycle de vie de l’opérateur sans outils supplémentaires.

Le format de paquet opérateur est la méthode d’emballage par défaut pour l’opérateur SDK et OLM. Le SDK de l’opérateur permet d’exécuter rapidement une image groupée sur OLM afin de s’assurer qu’elle fonctionne correctement.

Conditions préalables

  • L’opérateur SDK CLI installé sur un poste de travail de développement
  • Ensemble d’image de l’opérateur construit et poussé à un registre
  • Installation OLM sur un cluster basé sur Kubernetes (v1.16.0 ou version ultérieure si vous utilisez apiextensions.k8s.io/v1 CRDs, par exemple Red Hat OpenShift Service sur AWS 4)
  • Connexion au cluster avec oc à l’aide d’un compte avec des autorisations d’administration dédiées
  • Dans le cas où votre opérateur est Go-based, votre projet doit être mis à jour pour utiliser les images prises en charge pour s’exécuter sur Red Hat OpenShift Service sur AWS

Procédure

  • Entrez la commande suivante pour exécuter l’opérateur sur le cluster: 

    $ operator-sdk run bundle \
    1 
    
    -n <namespace> \
    2 
    
    <registry>/<user>/<bundle_image_name>:<tag>
    3
    Copy to Clipboard Toggle word wrap
    1
    La commande run bundle crée un catalogue basé sur des fichiers valide et installe le paquet Opérateur sur votre cluster en utilisant OLM.
    2
    Facultatif: Par défaut, la commande installe l’opérateur dans le projet actuellement actif dans votre fichier ~/.kube/config. Il est possible d’ajouter le drapeau -n pour définir un espace de noms différent pour l’installation.
    3
    Dans le cas où vous ne spécifiez pas une image, la commande utilise quay.io/operator-framework/opm:latest comme image d’index par défaut. Lorsque vous spécifiez une image, la commande utilise l’image du faisceau lui-même comme image d’index.
    Important

    À partir de Red Hat OpenShift Service sur AWS 4.11, la commande run bundle prend en charge le format de catalogue basé sur des fichiers pour les catalogues d’opérateurs par défaut. Le format de base de données SQLite obsolète pour les catalogues d’opérateurs continue d’être pris en charge; cependant, il sera supprimé dans une version ultérieure. Il est recommandé aux auteurs de l’opérateur de migrer leurs flux de travail vers le format de catalogue basé sur les fichiers.

    Cette commande effectue les actions suivantes:

    • Créez une image d’index faisant référence à votre image de paquet. L’image de l’index est opaque et éphémère, mais reflète avec précision comment un paquet serait ajouté à un catalogue en production.
    • Créez une source de catalogue qui pointe vers votre nouvelle image d’index, ce qui permet à OperatorHub de découvrir votre opérateur.
    • Déployez votre opérateur dans votre cluster en créant un groupe d’opérateurs, un abonnement, un plan d’installation et toutes les autres ressources requises, y compris RBAC.

Afin d’installer et de gérer les opérateurs, le gestionnaire de cycle de vie de l’opérateur (OLM) exige que les paquets d’opérateurs soient listés dans une image d’index, qui est référencée par un catalogue sur le cluster. En tant qu’auteur de l’opérateur, vous pouvez utiliser le SDK de l’opérateur pour créer un index contenant le paquet pour votre opérateur et toutes ses dépendances. Ceci est utile pour tester les clusters distants et publier dans des registres de conteneurs.

Note

Le SDK d’opérateur utilise l’opm CLI pour faciliter la création d’images d’index. L’expérience avec la commande opm n’est pas requise. Dans les cas avancés d’utilisation, la commande opm peut être utilisée directement au lieu du SDK de l’opérateur.

Conditions préalables

  • L’opérateur SDK CLI installé sur un poste de travail de développement
  • Ensemble d’image de l’opérateur construit et poussé à un registre
  • Installation OLM sur un cluster basé sur Kubernetes (v1.16.0 ou version ultérieure si vous utilisez apiextensions.k8s.io/v1 CRDs, par exemple Red Hat OpenShift Service sur AWS 4)
  • Connexion au cluster avec oc à l’aide d’un compte avec des autorisations d’administration dédiées

Procédure

  1. Exécutez la commande make suivante dans votre répertoire de projet Opérateur pour créer une image d’index contenant votre paquet Opérateur: 

    $ make catalog-build CATALOG_IMG=<registry>/<user>/<index_image_name>:<tag>
    Copy to Clipboard Toggle word wrap

    lorsque l’argument CATALOG_IMG fait référence à un référentiel auquel vous avez accès. Il est possible d’obtenir un compte de stockage des conteneurs sur des sites de dépôt tels que Quay.io.

  2. Appuyez sur l’image d’index construite vers un référentiel: 

    $ make catalog-push CATALOG_IMG=<registry>/<user>/<index_image_name>:<tag>
    Copy to Clipboard Toggle word wrap
    Astuce

    Il est possible d’utiliser les commandes de l’opérateur SDK si vous préférez effectuer plusieurs actions en séquence à la fois. Ainsi, si vous n’avez pas encore construit une image groupée pour votre projet Opérateur, vous pouvez construire et pousser à la fois une image de paquet et une image d’index avec la syntaxe suivante: 

    $ make bundle-build bundle-push catalog-build catalog-push \
    BUNDLE_IMG=<bundle_image_pull_spec> \
    CATALOG_IMG=<index_image_pull_spec>
    Copy to Clipboard Toggle word wrap

    Alternativement, vous pouvez définir le champ IMAGE_TAG_BASE dans votre Makefile sur un référentiel existant: 

    IMAGE_TAG_BASE=quay.io/example/my-operator
    Copy to Clipboard Toggle word wrap

    Ensuite, vous pouvez utiliser la syntaxe suivante pour créer et pousser des images avec des noms générés automatiquement, tels que quay.io/example/my-operator-bundle:v0.0.1 pour l’image de paquet et quay.io/example/my-operator-catalog:v0.0.1 pour l’image d’index: 

    $ make bundle-build bundle-push catalog-build catalog-push
    Copy to Clipboard Toggle word wrap

  3. Définissez un objet CatalogSource qui fait référence à l’image d’index que vous venez de générer, puis créez l’objet en utilisant la commande oc Apply ou la console web:

    Exemple CatalogSource YAML

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: cs-memcached
  namespace: <operator_namespace>
spec:
  displayName: My Test
  publisher: Company
  sourceType: grpc
  grpcPodConfig:
    securityContextConfig: <security_mode>
    1 
    
  image: quay.io/example/memcached-catalog:v0.0.1
    2 
    
  updateStrategy:
    registryPoll:
      interval: 10m
    Copy to Clipboard Toggle word wrap

    1
    Indiquez la valeur de l’héritage ou de la restriction. Lorsque le champ n’est pas défini, la valeur par défaut est héritée. Dans un futur service Red Hat OpenShift sur AWS, il est prévu que la valeur par défaut soit limitée. Dans le cas où votre catalogue ne peut pas fonctionner avec des autorisations restreintes, il est recommandé de définir manuellement ce champ sur l’héritage.
    2
    Définissez l’image sur la spécification d’extraction de l’image que vous avez utilisée précédemment avec l’argument CATALOG_IMG.

  4. Consultez la source du catalogue: 

    $ oc get catalogsource
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME           DISPLAY     TYPE   PUBLISHER   AGE
cs-memcached   My Test     grpc   Company     4h31m
    Copy to Clipboard Toggle word wrap

La vérification

  1. Installez l’opérateur à l’aide de votre catalogue:

    1. Définissez un objet OperatorGroup et créez-le en utilisant la commande oc Apply ou la console web:

      Exemple d’opérateur Groupe YAML

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-test
  namespace: <operator_namespace>
spec:
  targetNamespaces:
  - <operator_namespace>
      Copy to Clipboard Toggle word wrap

    2. Définissez un objet d’abonnement et créez-le en utilisant la commande oc Apply ou la console web:

      Exemple d’abonnement YAML

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: catalogtest
  namespace: <catalog_namespace>
spec:
  channel: "alpha"
  installPlanApproval: Manual
  name: catalog
  source: cs-memcached
  sourceNamespace: <operator_namespace>
  startingCSV: memcached-operator.v0.0.1
      Copy to Clipboard Toggle word wrap

  2. L’opérateur installé est en cours d’exécution:

    1. Consultez le groupe d’opérateurs: 

      $ oc get og
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME             AGE
my-test           4h40m
      Copy to Clipboard Toggle word wrap

    2. Consultez la version du service cluster (CSV): 

      $ oc get csv
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME                        DISPLAY   VERSION   REPLACES   PHASE
memcached-operator.v0.0.1   Test      0.0.1                Succeeded
      Copy to Clipboard Toggle word wrap

    3. Consultez les pods pour l’opérateur: 

      $ oc get pods
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME                                                              READY   STATUS      RESTARTS   AGE
9098d908802769fbde8bd45255e69710a9f8420a8f3d814abe88b68f8ervdj6   0/1     Completed   0          4h33m
catalog-controller-manager-7fd5b7b987-69s4n                       2/2     Running     0          4h32m
cs-memcached-7622r                                                1/1     Running     0          4h33m
      Copy to Clipboard Toggle word wrap

Il est possible de tester rapidement la mise à niveau de votre opérateur en utilisant l’intégration du gestionnaire de cycle de vie de l’opérateur (OLM) dans le SDK de l’opérateur, sans avoir à gérer manuellement les images d’index et les sources de catalogue.

La sous-commande run bundle-upgrade automatise le déclenchement d’un opérateur installé pour passer à une version ultérieure en spécifiant une image de paquet pour la version ultérieure.

Conditions préalables

  • L’opérateur installé avec OLM soit à l’aide de la sous-commande run bundle ou avec l’installation OLM traditionnelle
  • Image groupée qui représente une version ultérieure de l’opérateur installé

Procédure

  1. Dans le cas où votre opérateur n’a pas déjà été installé avec OLM, installez la version précédente soit en utilisant la sous-commande run bundle ou avec l’installation OLM traditionnelle.

    Note

    Lorsque la version antérieure du paquet a été installée traditionnellement à l’aide d’ODM, le nouveau paquet que vous avez l’intention de mettre à niveau ne doit pas exister dans l’image d’index référencée par la source du catalogue. Dans le cas contraire, l’exécution de la sous-commande de mise à niveau de paquets d’exécution entraînera l’échec de la pod de registre parce que le nouveau paquet est déjà référencé par l’index qui fournit la version de service de paquet et de cluster (CSV).

    À titre d’exemple, vous pouvez utiliser la sous-commande de paquets d’exécution suivante pour un opérateur Memcached en spécifiant l’image du paquet précédent: 

    $ operator-sdk run bundle <registry>/<user>/memcached-operator:v0.0.1
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    INFO[0006] Creating a File-Based Catalog of the bundle "quay.io/demo/memcached-operator:v0.0.1"
INFO[0008] Generated a valid File-Based Catalog
INFO[0012] Created registry pod: quay-io-demo-memcached-operator-v1-0-1
INFO[0012] Created CatalogSource: memcached-operator-catalog
INFO[0012] OperatorGroup "operator-sdk-og" created
INFO[0012] Created Subscription: memcached-operator-v0-0-1-sub
INFO[0015] Approved InstallPlan install-h9666 for the Subscription: memcached-operator-v0-0-1-sub
INFO[0015] Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.1" to reach 'Succeeded' phase
INFO[0015] Waiting for ClusterServiceVersion ""my-project/memcached-operator.v0.0.1" to appear
INFO[0026] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.1" phase: Pending
INFO[0028] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.1" phase: Installing
INFO[0059] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.1" phase: Succeeded
INFO[0059] OLM has successfully installed "memcached-operator.v0.0.1"
    Copy to Clipboard Toggle word wrap

  2. Améliorez l’opérateur installé en spécifiant l’image du paquet pour la version ultérieure de l’opérateur: 

    $ operator-sdk run bundle-upgrade <registry>/<user>/memcached-operator:v0.0.2
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    INFO[0002] Found existing subscription with name memcached-operator-v0-0-1-sub and namespace my-project
INFO[0002] Found existing catalog source with name memcached-operator-catalog and namespace my-project
INFO[0008] Generated a valid Upgraded File-Based Catalog
INFO[0009] Created registry pod: quay-io-demo-memcached-operator-v0-0-2
INFO[0009] Updated catalog source memcached-operator-catalog with address and annotations
INFO[0010] Deleted previous registry pod with name "quay-io-demo-memcached-operator-v0-0-1"
INFO[0041] Approved InstallPlan install-gvcjh for the Subscription: memcached-operator-v0-0-1-sub
INFO[0042] Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.2" to reach 'Succeeded' phase
INFO[0019] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: Pending
INFO[0042] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: InstallReady
INFO[0043] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: Installing
INFO[0044] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: Succeeded
INFO[0044] Successfully upgraded to "memcached-operator.v0.0.2"
    Copy to Clipboard Toggle word wrap

  3. Nettoyer les opérateurs installés: 

    $ operator-sdk cleanup memcached-operator
    Copy to Clipboard Toggle word wrap
Important

Kubernetes déprécie périodiquement certaines API qui sont supprimées dans les versions ultérieures. Lorsque votre opérateur utilise une API obsolète, il se peut que cela ne fonctionne plus après la mise à niveau du service Red Hat OpenShift sur le cluster AWS vers la version Kubernetes où l’API a été supprimée.

En tant qu’auteur de l’opérateur, il est fortement recommandé de consulter le Guide de migration de l’API obsolète dans la documentation Kubernetes et de garder vos projets d’opérateur à jour afin d’éviter d’utiliser des API dépréciées et supprimées. Idéalement, vous devriez mettre à jour votre opérateur avant la sortie d’une future version de Red Hat OpenShift Service sur AWS qui rendrait l’opérateur incompatible.

Lorsqu’une API est supprimée d’un service Red Hat OpenShift sur la version AWS, les opérateurs fonctionnant sur cette version de cluster qui utilisent toujours des API supprimées ne fonctionneront plus correctement. En tant qu’auteur de l’opérateur, vous devez prévoir de mettre à jour vos projets d’opérateur afin de tenir compte de la déprécation et de la suppression de l’API afin d’éviter les interruptions pour les utilisateurs de votre opérateur.

Astuce

Consultez les alertes d’événements de vos opérateurs pour savoir s’il y a des avertissements sur les API actuellement utilisées. Les alertes suivantes s’allument lorsqu’elles détectent une API utilisée qui sera supprimée dans la prochaine version:

APIRemovedInNextReleaseInUse
API qui seront supprimées dans la prochaine Red Hat OpenShift Service sur AWS.
APIRemovedInNextEUSReleaseInUse
API qui seront supprimées dans la prochaine version de Red Hat OpenShift Service sur AWS Extended Update Support (EUS).

Lorsqu’un administrateur de cluster a installé votre opérateur, avant de passer à la prochaine version de Red Hat OpenShift Service sur AWS, il doit s’assurer qu’une version de votre opérateur est installée et compatible avec la prochaine version du cluster. Bien qu’il soit recommandé de mettre à jour vos projets d’opérateur pour ne plus utiliser des API désappropriées ou supprimées, si vous avez encore besoin de publier vos paquets Opérateur avec des API supprimées pour une utilisation continue sur les versions antérieures de Red Hat OpenShift Service sur AWS, assurez-vous que le paquet est configuré en conséquence.

La procédure suivante empêche les administrateurs d’installer des versions de votre opérateur sur une version incompatible de Red Hat OpenShift Service sur AWS. Ces étapes empêchent également les administrateurs de passer à une nouvelle version de Red Hat OpenShift Service sur AWS qui est incompatible avec la version de votre opérateur qui est actuellement installée sur leur cluster.

Cette procédure est également utile lorsque vous savez que la version actuelle de votre opérateur ne fonctionnera pas bien, pour quelque raison que ce soit, sur un service Red Hat OpenShift spécifique sur la version AWS. En définissant les versions de cluster où l’opérateur doit être distribué, vous vous assurez que l’opérateur n’apparaît pas dans un catalogue d’une version de cluster qui est en dehors de la plage autorisée.

Important

Les opérateurs qui utilisent des API obsolètes peuvent avoir un impact négatif sur les charges de travail critiques lorsque les administrateurs de cluster passent à une future version de Red Hat OpenShift Service sur AWS où l’API n’est plus prise en charge. Lorsque votre opérateur utilise des API obsolètes, vous devez configurer les paramètres suivants dans votre projet Opérateur dès que possible.

Conditions préalables

  • D’un projet opérateur existant

Procédure

  1. Lorsque vous savez qu’un paquet spécifique de votre opérateur n’est pas pris en charge et ne fonctionne pas correctement sur Red Hat OpenShift Service sur AWS plus tard qu’une certaine version de cluster, configurez la version maximale de Red Hat OpenShift Service sur AWS avec laquelle votre opérateur est compatible. Dans la version de service cluster de votre projet Opérateur (CSV), définissez l’annotation olm.maxOpenShiftVersion pour empêcher les administrateurs de mettre à niveau leur cluster avant de mettre à niveau l’opérateur installé vers une version compatible:

    Important

    Il faut utiliser l’annotation olm.maxOpenShiftVersion uniquement si la version de votre bundle Opérateur ne peut pas fonctionner dans les versions ultérieures. Gardez à l’esprit que les administrateurs de clusters ne peuvent pas mettre à jour leurs clusters avec votre solution installée. Dans le cas où vous ne fournissez pas une version ultérieure et un chemin de mise à niveau valide, les administrateurs peuvent désinstaller votre opérateur et mettre à niveau la version du cluster.

    Exemple CSV avec olm.maxOpenShiftVersion annotation

    apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  annotations:
    "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<cluster_version>"}]'
    1
    Copy to Clipboard Toggle word wrap

    1
    Indiquez la version de cluster maximale de Red Hat OpenShift Service sur AWS avec laquelle votre opérateur est compatible. À titre d’exemple, le réglage de la valeur à 4.9 empêche les mises à niveau de cluster vers Red Hat OpenShift Service sur les versions AWS plus tard que 4.9 lorsque ce paquet est installé sur un cluster.

  2. Configurez les versions compatibles de Red Hat OpenShift Service sur AWS pour votre opérateur en définissant les propriétés suivantes. Cette configuration garantit que votre opérateur n’est inclus que dans les catalogues ciblant les versions compatibles de Red Hat OpenShift Service sur AWS:

    Note

    Cette étape n’est valable que lorsque vous publiez des opérateurs dans des catalogues fournis par Red Hat. Dans le cas où votre paquet n’est destiné qu’à la distribution dans un catalogue personnalisé, vous pouvez sauter cette étape. En savoir plus, voir "Catalogues de l’opérateur fourni par le chapeau rouge".

    1. Définissez l’annotation com.redhat.openshift.versions dans le fichier bundle/metadata/annotations.yaml de votre projet:

      Exemple de fichier bundle/metadata/annotations.yaml avec des versions compatibles

      com.redhat.openshift.versions: "v4.7-v4.9"
      1
      Copy to Clipboard Toggle word wrap

      1
      Défini sur une gamme ou une seule version.

    2. Afin d’éviter que votre paquet ne soit transmis à une version incompatible de Red Hat OpenShift Service sur AWS, assurez-vous que l’image d’index est générée avec l’étiquette com.redhat.openshift.versions appropriée dans l’image du paquet de votre opérateur. À titre d’exemple, si votre projet a été généré à l’aide du SDK de l’opérateur, mettez à jour le fichier bundle.Dockerfile:

      Exemple bundle.Dockerfile avec des versions compatibles

      LABEL com.redhat.openshift.versions="<versions>"
      1
      Copy to Clipboard Toggle word wrap

      1
      Défini sur une plage ou une seule version, par exemple v4.7-v4.9. Ce paramètre définit les versions de cluster où l’opérateur doit être distribué, et l’opérateur n’apparaît pas dans un catalogue d’une version de cluster qui est en dehors de la plage.

Désormais, vous pouvez regrouper une nouvelle version de votre opérateur et publier la version mise à jour dans un catalogue pour distribution.

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