2.4. Gestionnaire du cycle de vie des opérateurs (OLM)

Operator Lifecycle Manager (OLM) aide les utilisateurs à installer, mettre à jour et gérer le cycle de vie des applications natives Kubernetes (Operators) et de leurs services associés s'exécutant sur leurs clusters OpenShift Container Platform. Il fait partie de l'Operator Framework, une boîte à outils open source conçue pour gérer les opérateurs de manière efficace, automatisée et évolutive.

Figure 2.2. Flux de travail du gestionnaire du cycle de vie de l'opérateur

OLM fonctionne par défaut dans OpenShift Container Platform 4.12, ce qui aide les administrateurs de clusters à installer, mettre à niveau et accorder l'accès aux opérateurs fonctionnant sur leur cluster. La console web d'OpenShift Container Platform fournit des écrans de gestion permettant aux administrateurs de cluster d'installer des opérateurs, ainsi que d'accorder à des projets spécifiques l'accès à l'utilisation du catalogue d'opérateurs disponibles sur le cluster.

Pour les développeurs, une expérience en libre-service permet de provisionner et de configurer des instances de bases de données, de surveillance et de services de big data sans avoir à être des experts en la matière, car l'opérateur dispose de ces connaissances.

Les définitions de ressources personnalisées (CRD) suivantes sont définies et gérées par Operator Lifecycle Manager (OLM) :

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  generation: 1
  name: example-catalog 1
  namespace: openshift-marketplace 2
  annotations:
    olm.catalogImageTemplate: 3
      "quay.io/example-org/example-catalog:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
spec:
  displayName: Example Catalog 4
  image: quay.io/example-org/example-catalog:v1 5
  priority: -400 6
  publisher: Example Org
  sourceType: grpc 7
  grpcPodConfig:
    securityContextConfig: <security_mode> 8
    nodeSelector: 9
      custom_label: <label>
    priorityClassName: system-cluster-critical 10
    tolerations: 11
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoSchedule"
  updateStrategy:
    registryPoll: 12
      interval: 30m0s
status:
  connectionState:
    address: example-catalog.openshift-marketplace.svc:50051
    lastConnect: 2021-08-26T18:14:31Z
    lastObservedState: READY 13
  latestImageRegistryPoll: 2021-08-26T18:46:25Z 14
  registryService: 15
    createdAt: 2021-08-26T16:16:37Z
    port: 50051
    protocol: grpc
    serviceName: example-catalog
    serviceNamespace: openshift-marketplace

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: example-namespace
spec:
  channel: stable
  name: example-operator
  source: example-catalog
  sourceNamespace: openshift-marketplace

registry.redhat.io/redhat/redhat-operator-index:v4.11

registry.redhat.io/redhat/redhat-operator-index:v4.12

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  generation: 1
  name: example-catalog
  namespace: openshift-marketplace
  annotations:
    olm.catalogImageTemplate:
      "quay.io/example-org/example-catalog:v{kube_major_version}.{kube_minor_version}"
spec:
  displayName: Example Catalog
  image: quay.io/example-org/example-catalog:v1.25
  priority: -400
  publisher: Example Org

quay.io/example-org/example-catalog:v1.25

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: example-namespace
spec:
  channel: stable
  name: example-operator
  source: example-catalog
  sourceNamespace: openshift-marketplace

apiVersion: operators.coreos.com/v1alpha1
kind: InstallPlan
metadata:
  name: install-abcde
  namespace: operators
spec:
  approval: Automatic
  approved: true
  clusterServiceVersionNames:
    - my-operator.v1.0.1
  generation: 1
status:
  ...
  catalogSources: []
  conditions:
    - lastTransitionTime: '2021-01-01T20:17:27Z'
      lastUpdateTime: '2021-01-01T20:17:27Z'
      status: 'True'
      type: Installed
  phase: Complete
  plan:
    - resolving: my-operator.v1.0.1
      resource:
        group: operators.coreos.com
        kind: ClusterServiceVersion
        manifest: >-
        ...
        name: my-operator.v1.0.1
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1alpha1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: apiextensions.k8s.io
        kind: CustomResourceDefinition
        manifest: >-
        ...
        name: webservers.web.servers.org
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1beta1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: ''
        kind: ServiceAccount
        manifest: >-
        ...
        name: my-operator
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: rbac.authorization.k8s.io
        kind: Role
        manifest: >-
        ...
        name: my-operator.v1.0.1-my-operator-6d7cbc6f57
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: rbac.authorization.k8s.io
        kind: RoleBinding
        manifest: >-
        ...
        name: my-operator.v1.0.1-my-operator-6d7cbc6f57
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
      ...

Le gestionnaire du cycle de vie des opérateurs (OLM) est composé de deux opérateurs : l'opérateur OLM et l'opérateur de catalogue.

Chacun de ces opérateurs est responsable de la gestion des définitions de ressources personnalisées (CRD) qui constituent la base du cadre OLM :

Chacun de ces opérateurs est également responsable de la création des ressources suivantes :

L'opérateur OLM est chargé de déployer les applications définies par les ressources CSV une fois que les ressources requises spécifiées dans le CSV sont présentes dans le cluster.

L'opérateur OLM ne s'occupe pas de la création des ressources nécessaires ; vous pouvez choisir de créer manuellement ces ressources à l'aide du CLI ou de l'opérateur de catalogue. Cette séparation des préoccupations permet aux utilisateurs de s'approprier progressivement la partie du cadre OLM qu'ils choisissent d'exploiter pour leur application.

L'opérateur OLM utilise le flux de travail suivant :

L'opérateur de catalogue est responsable de la résolution et de l'installation des versions de service de cluster (CSV) et des ressources requises qu'elles spécifient. Il est également chargé de surveiller les sources du catalogue pour détecter les mises à jour des paquets dans les canaux et de les mettre à niveau, automatiquement si nécessaire, vers les dernières versions disponibles.

Pour suivre un paquet dans un canal, vous pouvez créer un objet Subscription configurant le paquet souhaité, le canal et l'objet CatalogSource que vous souhaitez utiliser pour extraire les mises à jour. Lorsque des mises à jour sont trouvées, un objet InstallPlan approprié est écrit dans l'espace de noms au nom de l'utilisateur.

L'opérateur de catalogue utilise le flux de travail suivant :

Le registre de catalogue stocke les CSV et les CRD pour la création dans un cluster et stocke les métadonnées sur les paquets et les canaux.

Un site package manifest est une entrée dans le registre du catalogue qui associe une identité de paquet à des ensembles de CSV. Au sein d'un paquet, les canaux pointent vers un CSV particulier. Comme les CSV font explicitement référence au CSV qu'ils remplacent, un manifeste de paquet fournit à l'opérateur de catalogue toutes les informations nécessaires pour mettre à jour un CSV vers la dernière version d'un canal, en passant par chaque version intermédiaire.

Dans l'écosystème du gestionnaire du cycle de vie des opérateurs (OLM), les ressources suivantes sont utilisées pour résoudre les problèmes d'installation et de mise à niveau des opérateurs :

Les métadonnées des opérateurs, définies dans des fichiers CSV, peuvent être stockées dans une collection appelée source de catalogue. OLM utilise les sources du catalogue, qui utilisent l'API du registre des opérateurs, pour rechercher les opérateurs disponibles ainsi que les mises à niveau des opérateurs installés.

Figure 2.3. Vue d'ensemble des sources du catalogue

Au sein d'un catalogue source, les opérateurs sont organisés en packages et en flux de mises à jour appelés channels, ce qui devrait être un modèle de mise à jour familier d'OpenShift Container Platform ou d'autres logiciels à cycle de publication continu tels que les navigateurs Web.

Figure 2.4. Paquets et chaînes dans un catalogue source

Un utilisateur indique un paquet et un canal particuliers dans une source de catalogue particulière dans un subscription, par exemple un paquet etcd et son canal alpha. Si un abonnement est souscrit pour un paquet qui n'a pas encore été installé dans l'espace de nommage, le dernier opérateur pour ce paquet est installé.

Chaque CSV a un paramètre replaces qui indique l'opérateur qu'il remplace. Il en résulte un graphe de CSV qui peut être interrogé par OLM et dont les mises à jour peuvent être partagées entre les canaux. Les canaux peuvent être considérés comme des points d'entrée dans le graphe des mises à jour :

Figure 2.5. Graphique OLM des mises à jour des canaux disponibles

packageName: example
channels:
- name: alpha
  currentCSV: example.v0.1.2
- name: beta
  currentCSV: example.v0.1.3
defaultChannel: alpha

Pour qu'OLM puisse demander avec succès des mises à jour, compte tenu d'une source de catalogue, d'un paquet, d'un canal et d'un CSV, un catalogue doit pouvoir renvoyer, sans ambiguïté et de manière déterministe, un CSV unique qui replaces le CSV d'entrée.

2.4.3.1.2. Sauter des mises à niveau

Le chemin de base pour les mises à niveau dans OLM est le suivant :

• Une source de catalogue est mise à jour avec une ou plusieurs mises à jour d'un opérateur.
• OLM parcourt toutes les versions de l'opérateur jusqu'à la dernière version que contient la source du catalogue.

Cependant, il arrive que cette opération ne soit pas sûre. Dans certains cas, une version publiée d'un opérateur ne doit jamais être installée sur un cluster si ce n'est pas déjà fait, par exemple parce qu'une version introduit une vulnérabilité grave.

Dans ce cas, OLM doit prendre en compte deux états de la grappe et fournir un graphique de mise à jour qui prenne en charge les deux états :

• L'opérateur intermédiaire "bad" a été vu par le cluster et installé.
• L'opérateur intermédiaire "bad" n'a pas encore été installé sur le cluster.

En envoyant un nouveau catalogue et en ajoutant une version skipped, OLM est assuré de toujours recevoir une mise à jour unique, quel que soit l'état du cluster et qu'il ait ou non déjà vu la mauvaise mise à jour.

Exemple de CSV avec la version sautée

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  name: etcdoperator.v0.9.2
  namespace: placeholder
  annotations:
spec:
    displayName: etcd
    description: Etcd Operator
    replaces: etcdoperator.v0.9.0
    skips:
    - etcdoperator.v0.9.1

Prenons l'exemple suivant : Old CatalogSource et New CatalogSource.

Figure 2.6. Sauter des mises à jour

Ce graphique le confirme :

• Tout opérateur trouvé dans Old CatalogSource a un seul remplaçant dans New CatalogSource.
• Tout opérateur trouvé dans New CatalogSource a un seul remplaçant dans New CatalogSource.
• Si la mauvaise mise à jour n'a pas encore été installée, elle ne le sera jamais.

olm.skipRange : <semver_range>

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
    name: elasticsearch-operator.v4.1.2
    namespace: <namespace>
    annotations:
        olm.skipRange: '>=4.1.0 <4.1.2'

2.4.3.1.4. Prise en charge du flux Z

Une version z-stream, ou patch, doit remplacer toutes les versions précédentes de z-stream pour la même version mineure. OLM ne tient pas compte des versions majeures, mineures ou des correctifs, il lui suffit de construire le graphique correct dans un catalogue.

En d'autres termes, OLM doit être capable de prendre un graphique comme dans Old CatalogSource et, comme précédemment, de générer un graphique comme dans New CatalogSource:

Figure 2.7. Remplacement de plusieurs opérateurs

Ce graphique le confirme :

• Tout opérateur trouvé dans Old CatalogSource a un seul remplaçant dans New CatalogSource.
• Tout opérateur trouvé dans New CatalogSource a un seul remplaçant dans New CatalogSource.
• Toute version de z-stream dans Old CatalogSource sera mise à jour avec la dernière version de z-stream dans New CatalogSource.
• Les rejets non disponibles peuvent être considérés comme des nœuds de graphe "virtuels" ; leur contenu n'a pas besoin d'exister, le registre doit simplement répondre comme si le graphe ressemblait à ceci.

Le gestionnaire du cycle de vie des opérateurs (OLM) gère la résolution des dépendances et le cycle de vie des mises à jour des opérateurs en cours d'exécution. À bien des égards, les problèmes rencontrés par OLM sont similaires à ceux d'autres gestionnaires de paquets de systèmes ou de langues, tels que yum et rpm.

Cependant, il existe une contrainte que les systèmes similaires n'ont généralement pas et qu'OLM respecte : comme les opérateurs sont toujours en cours d'exécution, OLM s'efforce de garantir que vous ne vous retrouvez jamais avec un ensemble d'opérateurs qui ne fonctionnent pas les uns avec les autres.

Par conséquent, OLM ne doit jamais créer les scénarios suivants :

Cela est possible grâce à deux types de données :

OLM convertit ces propriétés et ces contraintes en un système de formules booléennes et les transmet à un solveur SAT, un programme qui établit la satisfiabilité booléenne, qui se charge de déterminer quels opérateurs doivent être installés.

Tous les opérateurs d'un catalogue ont les propriétés suivantes :

Des propriétés supplémentaires peuvent également être déclarées directement par l'auteur d'un opérateur en incluant un fichier properties.yaml dans le répertoire metadata/ de l'ensemble Operator.

properties:
- type: olm.kubeversion
  value:
    version: "1.16.0"

properties:
  - property:
      type: color
      value: red
  - property:
      type: shape
      value: square
  - property:
      type: olm.gvk
      value:
        group: olm.coreos.io
        version: v1alpha1
        kind: myresource

Les dépendances d'un Opérateur sont listées dans un fichier dependencies.yaml dans le dossier metadata/ d'un bundle. Ce fichier est facultatif et n'est actuellement utilisé que pour spécifier les dépendances explicites de la version de l'opérateur.

La liste des dépendances contient un champ type pour chaque élément afin de spécifier de quel type de dépendance il s'agit. Les types de dépendances de l'opérateur suivants sont pris en charge :

Dans l'exemple suivant, des dépendances sont spécifiées pour un opérateur Prometheus et des CRD etcd :

dependencies:
  - type: olm.package
    value:
      packageName: prometheus
      version: ">0.27.0"
  - type: olm.gvk
    value:
      group: etcd.database.coreos.com
      kind: EtcdCluster
      version: v1beta2

Une propriété olm.constraint déclare une contrainte de dépendance d'un type particulier, en distinguant les propriétés sans contrainte et les propriétés avec contrainte. Son champ value est un objet contenant un champ failureMessage qui contient une représentation sous forme de chaîne de caractères du message de la contrainte. Ce message est affiché sous la forme d'un commentaire informatif à l'intention des utilisateurs si la contrainte n'est pas satisfaisable au moment de l'exécution.

Les clés suivantes indiquent les types de contraintes disponibles :

type: olm.constraint
value:
  failureMessage: 'require to have "certified"'
  cel:
    rule: 'properties.exists(p, p.type == "certified")'

type: olm.constraint
value:
  failureMessage: 'require to have "certified" and "stable" properties'
  cel:
    rule: 'properties.exists(p, p.type == "certified") && properties.exists(p, p.type == "stable")'

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
    failureMessage: All are required for Red because...
    all:
      constraints:
      - failureMessage: Package blue is needed for...
        package:
          name: blue
          versionRange: '>=1.0.0'
      - failureMessage: GVK Green/v1 is needed for...
        gvk:
          group: greens.example.com
          version: v1
          kind: Green

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
    failureMessage: Any are required for Red because...
    any:
      constraints:
      - gvk:
          group: blues.example.com
          version: v1beta1
          kind: Blue
      - gvk:
          group: blues.example.com
          version: v1beta2
          kind: Blue
      - gvk:
          group: blues.example.com
          version: v1
          kind: Blue

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
  all:
    constraints:
    - failureMessage: Package blue is needed for...
      package:
        name: blue
        versionRange: '>=1.0.0'
    - failureMessage: Cannot be required for Red because...
      not:
        constraints:
        - gvk:
            group: greens.example.com
            version: v1alpha1
            kind: greens

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
    failureMessage: Required for Red because...
    any:
      constraints:
      - all:
          constraints:
          - package:
              name: blue
              versionRange: '>=1.0.0'
          - gvk:
              group: blues.example.com
              version: v1
              kind: Blue
      - all:
          constraints:
          - package:
              name: blue
              versionRange: '<1.0.0'
          - gvk:
              group: blues.example.com
              version: v1beta1
              kind: Blue

Il peut y avoir plusieurs options qui répondent également à une dépendance d'un opérateur. Le résolveur de dépendances du gestionnaire du cycle de vie des opérateurs (OLM) détermine l'option qui répond le mieux aux exigences de l'opérateur demandé. En tant qu'auteur ou utilisateur d'un opérateur, il peut être important de comprendre comment ces choix sont faits afin que la résolution des dépendances soit claire.

apiVersion: "operators.coreos.com/v1alpha1"
kind: "CatalogSource"
metadata:
  name: "my-operators"
  namespace: "operators"
spec:
  sourceType: grpc
  grpcPodConfig:
    securityContextConfig: <security_mode> 1
  image: example.com/my/operator-index:v1
  displayName: "My Operators"
  priority: 100

OLM met à niveau une définition de ressource personnalisée (CRD) immédiatement si elle appartient à une seule version de service de cluster (CSV). Si une CRD appartient à plusieurs CSV, elle est mise à niveau lorsqu'elle remplit toutes les conditions de compatibilité ascendante suivantes :

Lorsque vous spécifiez des dépendances, vous devez tenir compte de certaines bonnes pratiques.

Lorsque vous spécifiez des dépendances, vous devez tenir compte de certaines mises en garde.

Dans les exemples suivants, provider est un opérateur qui "possède" un service de CRD ou d'API.

Exemple : Déclassement d'API dépendantes

A et B sont des API (CRD) :

Il en résulte que :

C'est un cas qu'OLM évite grâce à sa stratégie de mise à jour.

Exemple : Blocage de la version

A et B sont des API :

Si OLM tente de mettre à jour A sans mettre simultanément à jour B, ou vice-versa, il ne peut pas passer à de nouvelles versions des opérateurs, même si un nouvel ensemble compatible peut être trouvé.

Il s'agit d'un autre cas où OLM empêche la mise en œuvre de sa stratégie de mise à niveau.

Le gestionnaire du cycle de vie des opérateurs (OLM) traite 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 Subscription sont hébergées dans le même espace de noms, comme des opérateurs liés. Même s'ils ne sont pas réellement liés, OLM prend en compte leurs états, tels que leur version et leur politique de mise à jour, lorsque l'un d'entre eux est mis à jour.

Ce comportement par défaut se manifeste de deux manières :

Ces scénarios peuvent entraîner les problèmes suivants :

Ces problèmes apparaissent généralement parce que, lors de l'installation d'opérateurs avec la console web d'OpenShift Container Platform, le comportement par défaut installe les opérateurs qui prennent en charge le mode d'installation All namespaces dans l'espace de noms global par défaut openshift-operators.

En tant qu'administrateur de cluster, vous pouvez contourner manuellement ce comportement par défaut en utilisant le flux de travail suivant :

Si l'opérateur a des dépendances, celles-ci sont automatiquement installées dans l'espace de noms pré-créé. Par conséquent, les opérateurs dépendants peuvent avoir la même politique de mise à jour et des plans d'installation partagés. Pour une procédure détaillée, voir "Installer des opérateurs globaux dans des espaces de noms personnalisés".

Un site Operator group, défini par la ressource OperatorGroup, fournit une configuration multitenant aux opérateurs installés dans OLM. Un groupe d'opérateurs sélectionne des espaces de noms cibles dans lesquels générer l'accès RBAC requis pour les opérateurs qui en font partie.

L'ensemble des espaces de noms cibles est fourni par une chaîne délimitée par des virgules, stockée dans l'annotation olm.targetNamespaces d'une version de service de cluster (CSV). Cette annotation est appliquée aux instances CSV des opérateurs membres et est projetée dans leurs déploiements.

Un opérateur est considéré comme member d'un groupe d'opérateurs si les conditions suivantes sont remplies :

Un mode d'installation dans un CSV se compose d'un champ InstallModeType et d'un champ booléen Supported. La spécification d'un CSV peut contenir un ensemble de modes d'installation de quatre InstallModeTypes distincts :

Vous pouvez nommer explicitement l'espace de noms cible d'un groupe d'opérateurs à l'aide du paramètre spec.targetNamespaces:

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace
spec:
  targetNamespaces:
  - my-namespace

Vous pouvez également spécifier un espace de noms en utilisant un sélecteur d'étiquettes avec le paramètre spec.selector:

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace
spec:
  selector:
    cool.io/prod: "true"

Si spec.targetNamespaces et spec.selector sont tous deux définis, spec.selector est ignoré. Vous pouvez également omettre spec.selector et spec.targetNamespaces pour spécifier un groupe d'opérateurs global, qui sélectionne tous les espaces de noms :

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace

L'ensemble résolu des espaces de noms sélectionnés est indiqué dans le paramètre status.namespaces d'un groupe d'opérateurs. Le paramètre status.namespace d'un groupe d'opérateurs global contient la chaîne vide (""), qui signale à un opérateur consommateur qu'il doit surveiller tous les espaces de noms.

Les CSV membres d'un groupe d'opérateurs ont les annotations suivantes :

Un group/version/kind (GVK) est un identifiant unique pour une API Kubernetes. Les informations sur les GVK fournis par un groupe d'opérateurs sont indiquées dans une annotation olm.providedAPIs. La valeur de l'annotation est une chaîne composée de <kind>.<version>.<group> délimitée par des virgules. Les GVK des CRD et des services API fournis par tous les CSV membres actifs d'un groupe d'opérateurs sont inclus.

Examinez l'exemple suivant d'un objet OperatorGroup avec un seul membre actif CSV qui fournit la ressource PackageManifest:

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  annotations:
    olm.providedAPIs: PackageManifest.v1alpha1.packages.apps.redhat.com
  name: olm-operators
  namespace: local
  ...
spec:
  selector: {}
  serviceAccount:
    metadata:
      creationTimestamp: null
  targetNamespaces:
  - local
status:
  lastUpdated: 2019-02-19T16:18:28Z
  namespaces:
  - local

Lorsqu'un groupe d'opérateurs est créé, trois rôles de grappe sont générés. Chacun contient une règle d'agrégation unique avec un sélecteur de rôle de cluster défini pour correspondre à une étiquette, comme illustré ci-dessous :

Les ressources RBAC suivantes sont générées lorsqu'un CSV devient un membre actif d'un groupe d'opérateurs, tant que le CSV surveille tous les espaces de noms avec le mode d'installation AllNamespaces et n'est pas dans un état d'échec avec la raison InterOperatorGroupOwnerConflict:

OLM crée des copies de tous les CSV membres actifs d'un groupe d'opérateurs dans chacun des espaces de noms cibles de ce groupe d'opérateurs. L'objectif d'une copie de CSV est d'indiquer aux utilisateurs d'un espace de noms cible qu'un opérateur spécifique est configuré pour surveiller les ressources créées dans cet espace.

Les CSV copiés ont un motif de statut Copied et sont mis à jour pour correspondre au statut de leur CSV source. L'annotation olm.targetNamespaces est supprimée des CSV copiés avant qu'ils ne soient créés sur le cluster. L'omission de la sélection de l'espace de noms cible évite la duplication des espaces de noms cibles entre les locataires.

Les CSV copiés sont supprimés lorsque le CSV source n'existe plus ou que le groupe d'opérateurs auquel appartient le CSV source ne cible plus l'espace de noms du CSV copié.

Un groupe d'opérateurs est static si son champ spec.staticProvidedAPIs est défini sur true. Par conséquent, OLM ne modifie pas l'annotation olm.providedAPIs d'un groupe d'opérateurs, ce qui signifie qu'elle peut être définie à l'avance. Cela est utile lorsqu'un utilisateur souhaite utiliser un groupe d'opérateurs pour empêcher la contention des ressources dans un ensemble d'espaces de noms, mais qu'il ne dispose pas de CSV membres actifs qui fournissent les API pour ces ressources.

Voici un exemple de groupe d'opérateurs qui protège les ressources Prometheus dans tous les espaces de noms avec l'annotation something.cool.io/cluster-monitoring: "true":

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-monitoring
  namespace: cluster-monitoring
  annotations:
    olm.providedAPIs: Alertmanager.v1.monitoring.coreos.com,Prometheus.v1.monitoring.coreos.com,PrometheusRule.v1.monitoring.coreos.com,ServiceMonitor.v1.monitoring.coreos.com
spec:
  staticProvidedAPIs: true
  selector:
    matchLabels:
      something.cool.io/cluster-monitoring: "true"

Deux groupes d'opérateurs sont considérés comme ayant intersecting provided APIs si l'intersection de leurs ensembles d'espaces de noms cibles n'est pas un ensemble vide et si l'intersection de leurs ensembles d'API fournis, définis par les annotations olm.providedAPIs, n'est pas un ensemble vide.

Un problème potentiel est que les groupes d'opérateurs dont les API fournies se recoupent peuvent être en concurrence pour les mêmes ressources dans l'ensemble des espaces de noms qui se recoupent.

Règles d'intersection

Chaque fois qu'un membre actif du CSV se synchronise, OLM interroge le cluster pour connaître l'ensemble des API fournies qui se croisent entre le groupe d'opérateurs du CSV et tous les autres. OLM vérifie ensuite si cet ensemble est vide :

Les actions suivantes sont effectuées à chaque fois qu'un groupe d'opérateurs se synchronise :

OpenShift Container Platform offre un support limité pour l'installation simultanée de différentes versions d'un opérateur sur le même cluster. Operator Lifecycle Manager (OLM) installe les opérateurs plusieurs fois dans différents espaces de noms. L'une des contraintes est que les versions de l'API de l'opérateur doivent être identiques.

Les opérateurs sont des extensions du plan de contrôle en raison de leur utilisation des objets CustomResourceDefinition (CRD), qui sont des ressources globales dans Kubernetes. Les différentes versions majeures d'un opérateur ont souvent des CRD incompatibles. Cela les rend incompatibles à installer simultanément dans différents espaces de noms sur un cluster.

Tous les locataires, ou espaces de noms, partagent le même plan de contrôle d'un cluster. Par conséquent, les locataires d'un cluster multi-locataires partagent également des CRD globaux, ce qui limite les scénarios dans lesquels différentes instances du même opérateur peuvent être utilisées en parallèle sur le même cluster.

Les scénarios pris en charge sont les suivants :

Tous les autres scénarios ne sont pas pris en charge, car l'intégrité des données du cluster ne peut pas être garantie s'il y a plusieurs CRD concurrents ou se chevauchant, provenant de différentes versions de l'opérateur, à réconcilier sur le même cluster.

L'adhésion

Dans le cadre de son rôle de gestion du cycle de vie d'un opérateur, Operator Lifecycle Manager (OLM) déduit l'état d'un opérateur à partir de l'état des ressources Kubernetes qui définissent l'opérateur. Bien que cette approche fournisse un certain niveau d'assurance qu'un opérateur est dans un état donné, il y a de nombreux cas où un opérateur peut avoir besoin de communiquer des informations à OLM qui ne pourraient pas être déduites autrement. Ces informations peuvent alors être utilisées par OLM pour mieux gérer le cycle de vie de l'opérateur.

OLM fournit une définition de ressource personnalisée (CRD) appelée OperatorCondition qui permet aux opérateurs de communiquer des conditions à OLM. Il existe un ensemble de conditions prises en charge qui influencent la gestion de l'opérateur par OLM lorsqu'elles sont présentes dans le tableau Spec.Conditions d'une ressource OperatorCondition.

Le gestionnaire du cycle de vie de l'opérateur (OLM) prend en charge les conditions suivantes de l'opérateur.

apiVersion: operators.coreos.com/v1
kind: OperatorCondition
metadata:
  name: my-operator
  namespace: operators
spec:
  conditions:
  - type: Upgradeable 1
    status: "False" 2
    reason: "migration"
    message: "The Operator is performing a migration."
    lastTransitionTime: "2020-08-24T23:15:55Z"

Operator Lifecycle Manager (OLM) expose certaines ressources spécifiques à OLM pour une utilisation par la pile de surveillance de cluster OpenShift Container Platform basée sur Prometheus.