2.4. Gestionnaire du cycle de vie de l’opérateur (OLM)

L’opérateur Lifecycle Manager (OLM) Classic aide les utilisateurs à installer, mettre à jour et gérer le cycle de vie des applications natives Kubernetes (Operators) et de leurs services associés qui s’exécutent sur leur service OpenShift Red Hat sur les clusters AWS. Il s’inscrit dans le cadre de l’opérateur, 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 OLM (Classic)

View larger image

Le service OLM fonctionne par défaut dans Red Hat OpenShift Service sur AWS 4, qui aide les administrateurs avec le rôle d’administrateur dédié dans l’installation, la mise à niveau et l’octroi d’un accès aux opérateurs fonctionnant sur leur cluster. Le service OpenShift Red Hat sur la console web AWS fournit des écrans de gestion aux administrateurs dédiés pour installer les opérateurs, ainsi que l’accès à des projets spécifiques pour utiliser le catalogue des opérateurs disponibles sur le cluster.

En ce qui concerne les développeurs, une expérience en libre-service permet de fournir 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 (DCR) 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 
  namespace: openshift-marketplace 
  annotations:
    olm.catalogImageTemplate: 
      "quay.io/example-org/example-catalog:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
spec:
  displayName: Example Catalog 
  image: quay.io/example-org/example-catalog:v1 
  priority: -400 
  publisher: Example Org
  sourceType: grpc 
  grpcPodConfig:
    securityContextConfig: <security_mode> 
    nodeSelector: 
      custom_label: <label>
    priorityClassName: system-cluster-critical 
    tolerations: 
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoSchedule"
  updateStrategy:
    registryPoll: 
      interval: 30m0s
status:
  connectionState:
    address: example-catalog.openshift-marketplace.svc:50051
    lastConnect: 2021-08-26T18:14:31Z
    lastObservedState: READY 
  latestImageRegistryPoll: 2021-08-26T18:46:25Z 
  registryService: 
    createdAt: 2021-08-26T16:16:37Z
    port: 50051
    protocol: grpc
    serviceName: example-catalog
    serviceNamespace: openshift-marketplace

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}.{kube_patch_version}"
spec:
  displayName: Example Catalog 

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

  priority: -400 

  publisher: Example Org
  sourceType: grpc 

  grpcPodConfig:
    securityContextConfig: <security_mode> 

    nodeSelector: 

      custom_label: <label>
    priorityClassName: system-cluster-critical 

    tolerations: 

      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoSchedule"
  updateStrategy:
    registryPoll: 

      interval: 30m0s
status:
  connectionState:
    address: example-catalog.openshift-marketplace.svc:50051
    lastConnect: 2021-08-26T18:14:31Z
    lastObservedState: READY 

  latestImageRegistryPoll: 2021-08-26T18:46:25Z 

  registryService: 

    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

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

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

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

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

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.31
  priority: -400
  publisher: Example Org

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.31
  priority: -400
  publisher: Example Org

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

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

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

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 de l’opérateur (OLM) est composé de deux opérateurs : l’opérateur OLM et l’opérateur de catalogue.

Les OLM et les opérateurs de catalogue sont responsables de la gestion des définitions de ressources personnalisées (DRC) 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 responsable du déploiement des 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 n’est pas concerné par la création des ressources requises; vous pouvez choisir de créer manuellement ces ressources à l’aide du CLI ou à l’aide de l’opérateur de catalogue. Cette séparation des préoccupations permet aux utilisateurs d’adhérer progressivement en fonction de la quantité du cadre OLM qu’ils choisissent d’utiliser 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 services de cluster (CSV) et des ressources requises qu’ils spécifient. Il est également responsable de regarder les sources de catalogue pour les mises à jour des paquets dans les canaux et de les mettre à niveau, automatiquement si désiré, vers les dernières versions disponibles.

Afin de suivre un paquet dans un canal, vous pouvez créer un objet d’abonnement configurant le paquet, le canal et l’objet CatalogSource que vous souhaitez utiliser pour tirer les mises à jour. Lorsque des mises à jour sont trouvées, un objet InstallPlan approprié est écrit dans l’espace de noms pour le compte 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.

Le manifeste de paquet est une entrée dans le Registre de catalogue qui associe une identité de paquet à des ensembles de CSV. Dans un paquet, les canaux pointent vers un CSV particulier. Comme les CSV se réfèrent explicitement au CSV qu’ils remplacent, un manifeste de paquets fournit à l’opérateur de catalogue toutes les informations nécessaires pour mettre à jour un CSV vers la dernière version d’un canal, passant par chaque version intermédiaire.

Dans l’écosystème Gestionnaire du cycle de vie de l’opérateur (GLO), les ressources suivantes sont utilisées pour résoudre les installations et les mises à niveau de l’opérateur:

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

Figure 2.3. Aperçu de la source du catalogue

View larger image

Au sein d’une source de catalogue, les opérateurs sont organisés en paquets et en flux de mises à jour appelées canaux, ce qui devrait être un modèle de mise à jour familier de Red Hat OpenShift Service sur AWS ou d’autres logiciels sur un cycle de publication continu comme les navigateurs Web.

Figure 2.4. Forfaits et canaux dans une source de catalogue

View larger image

L’utilisateur indique un paquet et un canal particuliers dans une source de catalogue particulière dans un abonnement, par exemple un paquet etcd et son canal alpha. Lorsqu’un abonnement est effectué à un paquet qui n’a pas encore été installé dans l’espace de noms, le dernier opérateur de ce paquet est installé.

Chaque CSV a un paramètre de remplacement qui indique quel opérateur il remplace. Cela crée un graphique de CSV qui peut être interrogé par OLM, et 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 graphique des mises à jour:

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

View larger image

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

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

Afin que OLM puisse interroger avec succès les mises à jour, compte tenu d’une source de catalogue, d’un paquet, d’un canal et d’un CSV, un catalogue doit pouvoir retourner, sans ambiguïté et de façon déterministe, un seul CSV qui remplace le CSV d’entrée.

2.4.3.1.2. Des mises à niveau de saut

Copier lien

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

• La source du catalogue est mise à jour avec une ou plusieurs mises à jour d’un opérateur.
• L’OLM traverse toutes les versions de l’Opérateur jusqu’à atteindre la dernière version que contient la source du catalogue.

Cependant, parfois, ce n’est pas une opération sûre à effectuer. Il y aura des cas où une version publiée d’un opérateur ne devrait jamais être installée sur un cluster s’il ne l’a pas déjà fait, par exemple parce qu’une version introduit une vulnérabilité grave.

Dans ces cas, OLM doit tenir compte de deux états de cluster et fournir un graphique de mise à jour qui prend en charge les deux:

• Le "mauvais" opérateur intermédiaire a été vu par le cluster et installé.
• Le "mauvais" opérateur intermédiaire n’a pas encore été installé sur le cluster.

En expédiant un nouveau catalogue et en ajoutant une version sautée, OLM est assuré qu’il peut toujours obtenir une seule mise à jour unique quel que soit l’état du cluster et s’il a vu la mauvaise mise à jour encore.

Exemple CSV avec 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

Copy to Clipboard Toggle word wrap

Considérez l’exemple suivant de Old CatalogSource et New CatalogSource.

Figure 2.6. Sauter les mises à jour

View larger image

Ce graphique maintient que:

• Chaque opérateur trouvé dans Old CatalogSource a un seul remplacement dans New CatalogSource.
• Chaque opérateur trouvé dans New CatalogSource a un seul remplacement dans New CatalogSource.
• Lorsque la mauvaise mise à jour n’a pas encore été installée, elle ne le sera jamais.

olm.skipRange: <semver_range>

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'

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. Le support Z-stream

Copier lien

La version z-stream ou patch doit remplacer toutes les versions précédentes de z-stream pour la même version mineure. L’OLM ne considère pas les versions majeures, mineures ou patchées, il suffit de construire le graphique correct dans un catalogue.

En d’autres termes, OLM doit pouvoir prendre un graphique comme dans Old CatalogSource et, comme auparavant, générer un graphique comme dans New CatalogSource:

Figure 2.7. Le remplacement de plusieurs opérateurs

View larger image

Ce graphique maintient que:

• Chaque opérateur trouvé dans Old CatalogSource a un seul remplacement dans New CatalogSource.
• Chaque opérateur trouvé dans New CatalogSource a un seul remplacement dans New CatalogSource.
• Chaque version z-stream dans Old CatalogSource sera mise à jour vers la dernière version z-stream dans New CatalogSource.
• Les versions indisponibles peuvent être considérées comme des nœuds graphiques « virtuels » ; leur contenu n’a pas besoin d’exister, le registre doit simplement répondre comme si le graphique ressemblait à cela.

Le gestionnaire de cycle de vie de l’opérateur (OLM) gère la résolution de dépendance et la mise à niveau du cycle de vie des opérateurs en cours d’exécution. À bien des égards, les problèmes auxquels OLM est confronté sont similaires à d’autres gestionnaires de systèmes ou de paquets linguistiques, tels que yum et rpm.

Cependant, il y a une contrainte que les systèmes similaires n’ont généralement pas que OLM: parce que les opérateurs sont toujours en cours d’exécution, OLM tente de s’assurer que vous ne restez jamais avec un ensemble d’opérateurs qui ne fonctionnent pas les uns avec les autres.

En conséquence, OLM ne doit jamais créer les scénarios suivants:

Cela est rendu possible avec deux types de données:

L’OLM convertit ces propriétés et contraintes en un système de formules booléennes et les transmet à un solveur SAT, un programme qui établit la satisfaction booléenne, qui fait le travail de déterminer ce que les opérateurs devraient être installés.

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 un auteur de l’opérateur en incluant un fichier properties.yaml dans les métadonnées/annuaire du paquet Opérateur.

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

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

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 de dépendances.yaml dans le dossier métadonnées d’un bundle. Ce fichier est facultatif et actuellement utilisé uniquement pour spécifier des dépendances explicites de version d’opérateur.

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

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

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

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

La propriété olm.constraint déclare une contrainte de dépendance d’un type particulier, différenciant les propriétés non contraintes et les propriétés de contrainte. Le champ de valeur est un objet contenant un champ failMessage tenant une chaîne-représentation du message de contrainte. Ce message est présenté comme un commentaire informatif aux utilisateurs si la contrainte n’est pas satisfaisante au moment de l’exécution.

Les touches suivantes indiquent les types de contrainte 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"'
  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")'

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

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 de nombreuses options qui répondent également à une dépendance d’un opérateur. Le résolveur de dépendance dans Operator Lifecycle Manager (OLM) détermine quelle option correspond le mieux aux exigences de l’opérateur demandé. En tant qu’auteur ou utilisateur de l’opérateur, il peut être important de comprendre comment ces choix sont faits afin que la résolution de dépendance soit claire.

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

apiVersion: "operators.coreos.com/v1alpha1"
kind: "CatalogSource"
metadata:
  name: "my-operators"
  namespace: "operators"
spec:
  sourceType: grpc
  grpcPodConfig:
    securityContextConfig: <security_mode> 

  image: example.com/my/operator-index:v1
  displayName: "My Operators"
  priority: 100

L’ODM met immédiatement à niveau une définition de ressource personnalisée (CRD) s’il appartient à une version de service de cluster singulier (CSV). Lorsqu’un CRD est détenu par plusieurs CSV, le CRD est mis à niveau lorsqu’il a satisfait à toutes les conditions suivantes:

Lorsque vous spécifiez les dépendances, il existe des pratiques exemplaires que vous devriez considérer.

Lorsque vous spécifiez des dépendances, il y a des mises en garde que vous devriez considérer.

Dans les exemples suivants, un fournisseur est un opérateur qui « possède » un service CRD ou API.

Exemple : Dépréciation des API dépendantes

A et B sont des API (CRD):

Il en résulte:

C’est un cas que OLM empêche avec sa stratégie de mise à niveau.

Exemple : dans l’impasse de version

A et B sont des API:

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

C’est un autre cas que OLM empêche avec sa stratégie de mise à niveau.

Le groupe d’opérateurs, défini par la ressource OperatorGroup, fournit une configuration multilocataires aux Opérateurs installés par OLM. Le groupe d’opérateur sélectionne les espaces de noms cibles dans lesquels générer l’accès RBAC requis pour ses opérateurs membres.

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

L’opérateur est considéré comme un membre d’un groupe d’opérateurs si les conditions suivantes sont vraies:

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

Il est possible de nommer explicitement l’espace de noms cible pour un groupe d’opérateurs en utilisant le paramètre spec.targetNamespaces:

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

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

Alternativement, vous pouvez spécifier un espace de noms à l’aide d’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"

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

Lorsque spec.targetNamespaces et spec.selector sont définis, spec.selector est ignoré. Alternativement, vous pouvez omettre à la fois spec.selector et spec.targetNamespaces pour spécifier un groupe d’opérateur global, qui sélectionne tous les espaces de noms:

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

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

L’ensemble résolu d’espaces de noms sélectionnés est affiché dans le paramètre status.namespaces d’un groupe Opeator. Le status.namespace d’un groupe d’opérateur mondial contient la chaîne vide (""), qui signale à un opérateur consommant qu’il devrait regarder tous les espaces de noms.

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

Groupe/version/type (GVK) est un identifiant unique pour une API Kubernetes. Les informations sur ce que les GVK sont fournis par un groupe d’opérateurs sont affichées dans une annotation des API olm. La valeur de l’annotation est une chaîne composée de &lt;kind&gt;.&lt;version&gt;.<group> délimitée avec des virgules. Les GVK de CRD et les 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: {}
  serviceAccountName:
    metadata:
      creationTimestamp: null
  targetNamespaces:
  - local
status:
  lastUpdated: 2019-02-19T16:18:28Z
  namespaces:
  - local

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  annotations:
    olm.providedAPIs: PackageManifest.v1alpha1.packages.apps.redhat.com
  name: olm-operators
  namespace: local
  ...
spec:
  selector: {}
  serviceAccountName:
    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 cluster sont générés. Chacune contient une seule règle d’agrégation avec un sélecteur de rôle de cluster défini pour correspondre à une étiquette, comme indiqué 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éfaillant avec la raison InterOperatorGroupOwnerConflict:

L’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. Le but d’un CSV copié est de dire aux utilisateurs d’un espace de noms cible qu’un opérateur spécifique est configuré pour regarder les ressources créées là-bas.

Les CSV copiés ont une raison de statut Copié et sont mis à jour pour correspondre à l’état de leur CSV source. L’annotation olm.targetNamespaces est dépouillé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 leur CSV source n’existe plus ou que le groupe Opérateur que leur source CSV appartient à ne plus cibler l’espace de noms du CSV copié.

Le groupe opérateur est statique si son champ spec.staticProvidedAPIs est défini sur true. En conséquence, OLM ne modifie pas l’annotation olm.suppldAPIs d’un groupe d’opérateurs, ce qui signifie qu’il peut être défini à l’avance. Ceci 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 n’a pas de CSV membre actif qui fournissent les API pour ces ressources.

Ci-dessous est un exemple d’un groupe d’opérateurs qui protège les ressources Prometheus dans tous les espaces de noms avec le something.cool.io/cluster-monitoring: "vrai" annotation:

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"

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 auraient des API fournies si l’intersection de leurs jeux d’espace de noms n’est pas vide et que l’intersection des jeux d’API fournis, définies par les annotations olm.providedAPIs, n’est pas un ensemble vide.

Le problème potentiel réside dans le fait que les groupes d’opérateurs dotés d’API intersectées peuvent rivaliser pour les mêmes ressources dans l’ensemble des espaces de noms croisés.

Les règles pour l’intersection

Chaque fois qu’un membre actif se synchronise, OLM interroge le cluster pour l’ensemble d’intersecting fourni des API entre le groupe Opérateur du CSV et tous les autres. Ensuite, OLM vérifie si cet ensemble est un jeu vide:

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

Le service OpenShift Red Hat sur AWS fournit une prise en charge limitée pour l’installation simultanée de différentes versions d’un opérateur sur le même cluster. Le gestionnaire de cycle de vie de l’opérateur (OLM) installe des opérateurs plusieurs fois dans différents espaces de noms. L’une des contraintes est que les versions API de l’opérateur doivent être les mêmes.

Les opérateurs sont des extensions de plan de contrôle en raison de leur utilisation des objets CustomResourceDefinition (CRD), qui sont des ressources globales dans Kubernetes. 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.

Les locataires, ou espaces de noms, partagent le même plan de contrôle d’un cluster. Ainsi, les locataires d’un cluster multilocataires partagent également des CRD mondiaux, ce qui limite les scénarios dans lesquels différents cas d’un même opérateur peuvent être utilisés en parallèle sur le même cluster.

Les scénarios pris en charge comprennent les éléments suivants:

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 existe plusieurs CRD concurrents ou qui se chevauchent de différentes versions de l’opérateur à concilier sur le même cluster.

Adhésion

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

Ce comportement par défaut se manifeste de deux façons:

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 le service Red Hat OpenShift sur la console Web AWS, le comportement par défaut installe des 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.

En tant qu’administrateur avec le rôle admin dédié, vous pouvez contourner ce comportement par défaut manuellement en utilisant le flux de travail suivant:

Lorsque l’opérateur a des dépendances, les dépendances sont automatiquement installées dans l’espace de noms pré-créé. 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. Dans le cadre d’une procédure détaillée, voir « Installation des opérateurs mondiaux dans des espaces de noms personnalisés ».

Dans le cadre de son rôle dans la gestion du cycle de vie d’un opérateur, Operator Lifecycle Manager (OLM) infère 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 exploitant est dans un état donné, il existe de nombreux cas où un opérateur pourrait avoir besoin de communiquer des informations à OLM qui ne pourraient pas être déduits autrement. Ces informations peuvent ensuite être utilisées par OLM pour mieux gérer le cycle de vie de l’opérateur.

L’ODM fournit une définition de ressource personnalisée (CRD) appelée OperatorCondition qui permet aux opérateurs de communiquer les conditions à OLM. Il existe un ensemble de conditions supportées qui influencent la gestion de l’opérateur par OLM lorsqu’elles sont présentes dans la gamme Spec.Conditions d’une ressource OperatorCondition.

Gestionnaire de 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 
    status: "False" 
    reason: "migration"
    message: "The Operator is performing a migration."
    lastTransitionTime: "2020-08-24T23:15:55Z"

apiVersion: operators.coreos.com/v1
kind: OperatorCondition
metadata:
  name: my-operator
  namespace: operators
spec:
  conditions:
  - type: Upgradeable 

    status: "False" 

    reason: "migration"
    message: "The Operator is performing a migration."
    lastTransitionTime: "2020-08-24T23:15:55Z"

Le gestionnaire de cycle de vie de l’opérateur (OLM) expose certaines ressources spécifiques aux OLM destinées à être utilisées par le service Red Hat OpenShift basé sur Prometheus sur la pile de surveillance de cluster AWS.