Opérateurs

Les manifestes de paquets font référence à un ensemble de manifestes Kubernetes qui définissent le déploiement et le modèle RBAC de l'opérateur.

Un bundle comprend un CSV par répertoire et généralement les CRD qui définissent les API propres au CSV dans son répertoire /manifests.

etcd
├── manifests
│   ├── etcdcluster.crd.yaml
│   └── etcdoperator.clusterserviceversion.yaml
│   └── secret.yaml
│   └── configmap.yaml
└── metadata
    └── annotations.yaml
    └── dependencies.yaml

etcd
├── manifests
│   ├── etcdcluster.crd.yaml
│   └── etcdoperator.clusterserviceversion.yaml
│   └── secret.yaml
│   └── configmap.yaml
└── metadata
    └── annotations.yaml
    └── dependencies.yaml

Autres objets pris en charge

Les types d'objets suivants peuvent également être inclus de manière facultative dans le répertoire /manifests d'une liasse :

Lorsque ces objets facultatifs sont inclus dans une liasse, Operator Lifecycle Manager (OLM) peut les créer à partir de la liasse et gérer leur cycle de vie en même temps que le CSV :

Une liasse comprend également un fichier annotations.yaml dans son répertoire /metadata. Ce fichier définit des données agrégées de plus haut niveau qui aident à décrire le format et les informations sur la manière dont l'offre groupée doit être ajoutée à un index d'offres groupées :

annotations:
  operators.operatorframework.io.bundle.mediatype.v1: "registry+v1" 
  operators.operatorframework.io.bundle.manifests.v1: "manifests/" 
  operators.operatorframework.io.bundle.metadata.v1: "metadata/" 
  operators.operatorframework.io.bundle.package.v1: "test-operator" 
  operators.operatorframework.io.bundle.channels.v1: "beta,stable" 
  operators.operatorframework.io.bundle.channel.default.v1: "stable" 

annotations:
  operators.operatorframework.io.bundle.mediatype.v1: "registry+v1" 

  operators.operatorframework.io.bundle.manifests.v1: "manifests/" 

  operators.operatorframework.io.bundle.metadata.v1: "metadata/" 

  operators.operatorframework.io.bundle.package.v1: "test-operator" 

  operators.operatorframework.io.bundle.channels.v1: "beta,stable" 

  operators.operatorframework.io.bundle.channel.default.v1: "stable" 

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

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

L'outil CLI opm est fourni par Operator Framework pour être utilisé avec le format Operator bundle. Cet outil vous permet de créer et de maintenir des catalogues d'opérateurs à partir d'une liste de bundles d'opérateurs qui sont similaires à des dépôts de logiciels. Le résultat est une image de conteneur qui peut être stockée dans un registre de conteneurs et ensuite installée sur un cluster.

Un catalogue contient une base de données de pointeurs vers le contenu du manifeste de l'opérateur qui peut être interrogé par le biais d'une API incluse qui est servie lorsque l'image du conteneur est exécutée. Sur OpenShift Container Platform, Operator Lifecycle Manager (OLM) peut référencer l'image dans une source de catalogue, définie par un objet CatalogSource, qui interroge l'image à intervalles réguliers pour permettre des mises à jour fréquentes des opérateurs installés sur le cluster.

Les catalogues basés sur des fichiers peuvent être stockés et chargés à partir de systèmes de fichiers basés sur des répertoires. Le CLI de opm charge le catalogue en parcourant le répertoire racine et en revenant sur les sous-répertoires. Il tente de charger tous les fichiers qu'il trouve et échoue en cas d'erreur.

Les fichiers hors catalogue peuvent être ignorés à l'aide des fichiers .indexignore, qui obéissent aux mêmes règles que les fichiers .gitignore en ce qui concerne les motifs et la priorité.

# Ignore everything except non-object .json and .yaml files
**/*
!*.json
!*.yaml
**/objects/*.json
**/objects/*.yaml

# Ignore everything except non-object .json and .yaml files
**/*
!*.json
!*.yaml
**/objects/*.json
**/objects/*.yaml

Les responsables des catalogues ont la possibilité de choisir la disposition qu'ils souhaitent, mais il est recommandé de stocker les blobs de catalogue basés sur les fichiers de chaque paquet dans des sous-répertoires distincts. Chaque fichier individuel peut être au format JSON ou YAML ; il n'est pas nécessaire que tous les fichiers d'un catalogue utilisent le même format.

catalog
├── packageA
│   └── index.yaml
├── packageB
│   ├── .indexignore
│   ├── index.yaml
│   └── objects
│       └── packageB.v0.1.0.clusterserviceversion.yaml
└── packageC
    └── index.json

catalog
├── packageA
│   └── index.yaml
├── packageB
│   ├── .indexignore
│   ├── index.yaml
│   └── objects
│       └── packageB.v0.1.0.clusterserviceversion.yaml
└── packageC
    └── index.json

Cette structure recommandée a la propriété que chaque sous-répertoire de la hiérarchie des répertoires est un catalogue autonome, ce qui rend la composition, la découverte et la navigation dans le catalogue des opérations triviales du système de fichiers. Le catalogue peut également être inclus dans un catalogue parent en le copiant dans le répertoire racine du catalogue parent.

Les catalogues basés sur des fichiers utilisent un format, basé sur la spécification du langage CUE, qui peut être étendu avec des schémas arbitraires. Le schéma CUE suivant ( _Meta ) définit le format auquel tous les blobs de catalogues basés sur des fichiers doivent adhérer :

_Meta: {
  // schema is required and must be a non-empty string
  schema: string & !=""

  // package is optional, but if it's defined, it must be a non-empty string
  package?: string & !=""

  // properties is optional, but if it's defined, it must be a list of 0 or more properties
  properties?: [... #Property]
}

#Property: {
  // type is required
  type: string & !=""

  // value is required, and it must not be null
  value: !=null
}

_Meta: {
  // schema is required and must be a non-empty string
  schema: string & !=""

  // package is optional, but if it's defined, it must be a non-empty string
  package?: string & !=""

  // properties is optional, but if it's defined, it must be a list of 0 or more properties
  properties?: [... #Property]
}

#Property: {
  // type is required
  type: string & !=""

  // value is required, and it must not be null
  value: !=null
}

Un catalogue Operator Lifecycle Manager (OLM) utilise actuellement trois schémas (olm.package, olm.channel, et olm.bundle), qui correspondent aux concepts existants de paquet et de liasse d'OLM.

Chaque paquet d'opérateurs d'un catalogue nécessite exactement un blob olm.package, au moins un blob olm.channel et un ou plusieurs blobs olm.bundle.

#Package: {
  schema: "olm.package"

  // Package name
  name: string & !=""

  // A description of the package
  description?: string

  // The package's default channel
  defaultChannel: string & !=""

  // An optional icon
  icon?: {
    base64data: string
    mediatype:  string
  }
}

#Package: {
  schema: "olm.package"

  // Package name
  name: string & !=""

  // A description of the package
  description?: string

  // The package's default channel
  defaultChannel: string & !=""

  // An optional icon
  icon?: {
    base64data: string
    mediatype:  string
  }
}

#Channel: {
  schema: "olm.channel"
  package: string & !=""
  name: string & !=""
  entries: [...#ChannelEntry]
}

#ChannelEntry: {
  // name is required. It is the name of an `olm.bundle` that
  // is present in the channel.
  name: string & !=""

  // replaces is optional. It is the name of bundle that is replaced
  // by this entry. It does not have to be present in the entry list.
  replaces?: string & !=""

  // skips is optional. It is a list of bundle names that are skipped by
  // this entry. The skipped bundles do not have to be present in the
  // entry list.
  skips?: [...string & !=""]

  // skipRange is optional. It is the semver range of bundle versions
  // that are skipped by this entry.
  skipRange?: string & !=""
}

#Channel: {
  schema: "olm.channel"
  package: string & !=""
  name: string & !=""
  entries: [...#ChannelEntry]
}

#ChannelEntry: {
  // name is required. It is the name of an `olm.bundle` that
  // is present in the channel.
  name: string & !=""

  // replaces is optional. It is the name of bundle that is replaced
  // by this entry. It does not have to be present in the entry list.
  replaces?: string & !=""

  // skips is optional. It is a list of bundle names that are skipped by
  // this entry. The skipped bundles do not have to be present in the
  // entry list.
  skips?: [...string & !=""]

  // skipRange is optional. It is the semver range of bundle versions
  // that are skipped by this entry.
  skipRange?: string & !=""
}

#Bundle: {
  schema: "olm.bundle"
  package: string & !=""
  name: string & !=""
  image: string & !=""
  properties: [...#Property]
  relatedImages?: [...#RelatedImage]
}

#Property: {
  // type is required
  type: string & !=""

  // value is required, and it must not be null
  value: !=null
}

#RelatedImage: {
  // image is the image reference
  image: string & !=""

  // name is an optional descriptive name for an image that
  // helps identify its purpose in the context of the bundle
  name?: string & !=""
}

#Bundle: {
  schema: "olm.bundle"
  package: string & !=""
  name: string & !=""
  image: string & !=""
  properties: [...#Property]
  relatedImages?: [...#RelatedImage]
}

#Property: {
  // type is required
  type: string & !=""

  // value is required, and it must not be null
  value: !=null
}

#RelatedImage: {
  // image is the image reference
  image: string & !=""

  // name is an optional descriptive name for an image that
  // helps identify its purpose in the context of the bundle
  name?: string & !=""
}

Les propriétés sont des éléments arbitraires de métadonnées qui peuvent être attachés à des schémas de catalogues basés sur des fichiers. Le champ type est une chaîne qui spécifie effectivement la signification sémantique et syntaxique du champ value. La valeur peut être n'importe quel JSON ou YAML arbitraire.

OLM définit une poignée de types de propriétés, en utilisant à nouveau le préfixe réservé olm.*.

#PropertyPackage: {
  type: "olm.package"
  value: {
    packageName: string & !=""
    version: string & !=""
  }
}

#PropertyPackage: {
  type: "olm.package"
  value: {
    packageName: string & !=""
    version: string & !=""
  }
}

#PropertyGVK: {
  type: "olm.gvk"
  value: {
    group: string & !=""
    version: string & !=""
    kind: string & !=""
  }
}

#PropertyGVK: {
  type: "olm.gvk"
  value: {
    group: string & !=""
    version: string & !=""
    kind: string & !=""
  }
}

#PropertyPackageRequired: {
  type: "olm.package.required"
  value: {
    packageName: string & !=""
    versionRange: string & !=""
  }
}

#PropertyPackageRequired: {
  type: "olm.package.required"
  value: {
    packageName: string & !=""
    versionRange: string & !=""
  }
}

#PropertyGVKRequired: {
  type: "olm.gvk.required"
  value: {
    group: string & !=""
    version: string & !=""
    kind: string & !=""
  }
}

#PropertyGVKRequired: {
  type: "olm.gvk.required"
  value: {
    group: string & !=""
    version: string & !=""
    kind: string & !=""
  }
}

Avec les catalogues basés sur des fichiers, les responsables des catalogues peuvent se concentrer sur la curation et la compatibilité des opérateurs. Comme les auteurs d'opérateurs ont déjà produit des catalogues spécifiques pour leurs opérateurs, les responsables de catalogues peuvent construire leur catalogue en rendant chaque catalogue d'opérateur dans un sous-répertoire du répertoire racine du catalogue.

Il existe de nombreuses façons de créer un catalogue basé sur des fichiers ; les étapes suivantes décrivent une approche simple :

Les lignes directrices suivantes doivent être prises en compte lors de la gestion de catalogues basés sur des fichiers.

Pour obtenir des instructions sur la création de catalogues basés sur des fichiers à l'aide de l'interface CLI de opm, reportez-vous à la section Gestion des catalogues personnalisés.

Pour obtenir une documentation de référence sur les commandes CLI de opm relatives à la gestion des catalogues basés sur des fichiers, voir Outils CLI.

Les auteurs d'opérateurs et les responsables de catalogues sont encouragés à automatiser la maintenance de leurs catalogues avec des flux de travail CI/CD. Les mainteneurs de catalogues peuvent encore améliorer cela en construisant une automatisation GitOps pour accomplir les tâches suivantes :

Un objet RukPak Bundle représente un contenu à mettre à la disposition d'autres consommateurs dans le cluster. Tout comme le contenu d'une image de conteneur doit être extrait et décompressé pour que le pod puisse commencer à l'utiliser, les objets Bundle sont utilisés pour référencer le contenu qui pourrait avoir besoin d'être extrait et décompressé. En ce sens, un bundle est une généralisation du concept d'image et peut être utilisé pour représenter n'importe quel type de contenu.

Les paquets ne peuvent rien faire par eux-mêmes ; ils ont besoin d'un provisionneur pour décompresser et rendre leur contenu disponible dans le cluster. Ils peuvent être décompressés sur n'importe quel support de stockage arbitraire, tel qu'un fichier tar.gz dans un répertoire monté dans les pods du provisionneur. Chaque objet Bundle est associé à un champ spec.provisionerClassName qui indique l'objet Provisioner qui surveille et décompresse ce type de paquet particulier.

apiVersion: core.rukpak.io/v1alpha1
kind: Bundle
metadata:
  name: my-bundle
spec:
  source:
    type: image
    image:
      ref: my-bundle@sha256:xyz123
  provisionerClassName: core-rukpak-io-plain

apiVersion: core.rukpak.io/v1alpha1
kind: Bundle
metadata:
  name: my-bundle
spec:
  source:
    type: image
    image:
      ref: my-bundle@sha256:xyz123
  provisionerClassName: core-rukpak-io-plain

oc apply -f -<<EOF
apiVersion: core.rukpak.io/v1alpha1
kind: Bundle
metadata:
  name: combo-tag-ref
spec:
  source:
    type: git
    git:
      ref:
        tag: v0.0.2
      repository: https://github.com/operator-framework/combo
  provisionerClassName: core-rukpak-io-plain
EOF

$ oc apply -f -<<EOF
apiVersion: core.rukpak.io/v1alpha1
kind: Bundle
metadata:
  name: combo-tag-ref
spec:
  source:
    type: git
    git:
      ref:
        tag: v0.0.2
      repository: https://github.com/operator-framework/combo
  provisionerClassName: core-rukpak-io-plain
EOF

bundle.core.rukpak.io/combo-tag-ref created

bundle.core.rukpak.io/combo-tag-ref created

oc patch bundle combo-tag-ref --type='merge' -p '{"spec":{"source":{"git":{"ref":{"tag":"v0.0.3"}}}}}'

$ oc patch bundle combo-tag-ref --type='merge' -p '{"spec":{"source":{"git":{"ref":{"tag":"v0.0.3"}}}}}'

Error from server (bundle.spec is immutable): admission webhook "vbundles.core.rukpak.io" denied the request: bundle.spec is immutable

Error from server (bundle.spec is immutable): admission webhook "vbundles.core.rukpak.io" denied the request: bundle.spec is immutable

manifests
├── namespace.yaml
├── cluster_role.yaml
├── role.yaml
├── serviceaccount.yaml
├── cluster_role_binding.yaml
├── role_binding.yaml
└── deployment.yaml

manifests
├── namespace.yaml
├── cluster_role.yaml
├── role.yaml
├── serviceaccount.yaml
├── cluster_role_binding.yaml
├── role_binding.yaml
└── deployment.yaml

L'API RukPak BundleDeployment pointe vers un objet Bundle et indique qu'il doit être actif. Cela permet notamment de pivoter à partir d'anciennes versions d'un ensemble actif. Un objet BundleDeployment peut également inclure une spécification intégrée pour un ensemble souhaité.

Tout comme les pods génèrent des instances d'images de conteneurs, un déploiement de bundle génère une version déployée d'un bundle. Le déploiement d'un bundle peut être considéré comme une généralisation du concept de pod.

Les spécificités de la manière dont un déploiement de bundle apporte des modifications à un cluster basé sur un bundle référencé sont définies par le provisionneur qui est configuré pour surveiller ce déploiement de bundle.

apiVersion: core.rukpak.io/v1alpha1
kind: BundleDeployment
metadata:
  name: my-bundle-deployment
spec:
  provisionerClassName: core-rukpak-io-plain
  template:
    metadata:
      labels:
        app: my-bundle
    spec:
      source:
        type: image
        image:
          ref: my-bundle@sha256:xyz123
      provisionerClassName: core-rukpak-io-plain

apiVersion: core.rukpak.io/v1alpha1
kind: BundleDeployment
metadata:
  name: my-bundle-deployment
spec:
  provisionerClassName: core-rukpak-io-plain
  template:
    metadata:
      labels:
        app: my-bundle
    spec:
      source:
        type: image
        image:
          ref: my-bundle@sha256:xyz123
      provisionerClassName: core-rukpak-io-plain

Un provisionneur RukPak est un contrôleur qui comprend les API BundleDeployment et Bundle et peut prendre des mesures. Chaque provisionneur se voit attribuer un identifiant unique et est chargé de rapprocher les objets Bundle et BundleDeployment avec un champ spec.provisionerClassName correspondant à cet identifiant particulier.

Par exemple, le "plain provisioner" est capable de décompresser un paquet plain v0 donné sur un cluster et de l'instancier, rendant ainsi le contenu du paquet disponible dans le cluster.

Dans le format bundle, un bundle est une collection d'un CSV d'opérateur, de manifestes et de métadonnées. Ensemble, ils forment une version unique d'un opérateur qui peut être installée sur le cluster.

Dans le format bundle, un bundle image est une image de conteneur construite à partir de manifestes d'opérateurs et contenant un bundle. Les images de bundle sont stockées et distribuées par des registres de conteneurs spécifiques à l'Open Container Initiative (OCI), tels que Quay.io ou DockerHub.

Un site catalog source représente un magasin de métadonnées qu'OLM peut interroger pour découvrir et installer des opérateurs et leurs dépendances.

Un channel définit un flux de mises à jour pour un opérateur et est utilisé pour déployer des mises à jour pour les abonnés. La tête pointe vers la dernière version de ce canal. Par exemple, un canal stable contient toutes les versions stables d'un opérateur, de la plus ancienne à la plus récente.

Un opérateur peut avoir plusieurs canaux, et un abonnement lié à un certain canal ne recherchera des mises à jour que dans ce canal.

Le site channel head fait référence à la dernière mise à jour connue d'un canal particulier.

Un cluster service version (CSV) est un manifeste YAML créé à partir des métadonnées de l'opérateur, qui aide OLM à exécuter l'opérateur dans un cluster. Il s'agit des métadonnées qui accompagnent l'image d'un conteneur Operator, utilisées pour remplir les interfaces utilisateur avec des informations telles que le logo, la description et la version.

Il s'agit également d'une source d'informations techniques nécessaires au fonctionnement de l'opérateur, comme les règles RBAC dont il a besoin et les ressources personnalisées (CR) qu'il gère ou dont il dépend.

Un opérateur peut avoir une dépendance dependency à l'égard d'un autre opérateur présent dans le cluster. Par exemple, l'opérateur Vault dépend de l'opérateur etcd pour sa couche de persistance des données.

OLM résout les dépendances en s'assurant que toutes les versions spécifiées des opérateurs et des CRD sont installées sur le cluster pendant la phase d'installation. Cette dépendance est résolue par la recherche et l'installation d'un opérateur dans un catalogue qui satisfait à l'API CRD requise et qui n'est pas lié à des paquets ou à des bundles.

Dans le format des bundles, un index image fait référence à une image d'une base de données (un instantané de base de données) qui contient des informations sur les bundles d'opérateurs, y compris les CSV et les CRD de toutes les versions. Cet index peut héberger un historique des opérateurs sur un cluster et être maintenu en ajoutant ou en supprimant des opérateurs à l'aide de l'outil CLI opm.

Un site install plan est une liste calculée de ressources à créer pour installer ou mettre à niveau automatiquement un CSV.

Un tenant dans OpenShift Container Platform est un utilisateur ou un groupe d'utilisateurs qui partagent un accès et des privilèges communs pour un ensemble de charges de travail déployées, généralement représentées par un espace de noms ou un projet. Vous pouvez utiliser les locataires pour fournir un niveau d'isolation entre différents groupes ou équipes.

Lorsqu'un cluster est partagé par plusieurs utilisateurs ou groupes, il est considéré comme un cluster multitenant.

Un Operator group configure tous les opérateurs déployés dans le même espace de noms que l'objet OperatorGroup pour qu'ils surveillent leur CR dans une liste d'espaces de noms ou à l'échelle du cluster.

Dans le format bundle, un package est un répertoire qui contient tout l'historique des versions publiées d'un opérateur pour chaque version. Une version publiée d'un opérateur est décrite dans un manifeste CSV à côté des CRD.

Le site registry est une base de données qui stocke des images de faisceaux d'opérateurs, chacun avec toutes ses versions récentes et historiques dans tous les canaux.

Un site subscription permet de maintenir les CSV à jour en suivant un canal dans un paquet.

Un site update graph relie les versions des CSV entre elles, de la même manière que le graphique de mise à jour de tout autre logiciel. Les opérateurs peuvent être installés de manière séquentielle ou certaines versions peuvent être ignorées. Le graphique de mise à jour ne devrait croître qu'en tête, avec l'ajout de nouvelles versions.

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

View larger image

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

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

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

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

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

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

View larger image

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

View larger image

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

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

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

Copier lien

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

Copy to Clipboard Toggle word wrap

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

Figure 2.6. Sauter des mises à jour

View larger image

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>

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. Prise en charge du flux Z

Copier lien

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

View larger image

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

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"'
  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 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> 
  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

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

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"

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

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

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"

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

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.

L'opérateur Marketplace gère une ressource personnalisée OperatorHub (CR) nommée cluster qui gère les objets CatalogSource par défaut fournis avec OperatorHub. Vous pouvez modifier cette ressource pour activer ou désactiver les catalogues par défaut, ce qui est utile lors de la configuration d'OpenShift Container Platform dans des environnements réseau restreints.

apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true 
  sources: [ 
    {
      name: "community-operators",
      disabled: false
    }
  ]

apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true 

  sources: [ 

    {
      name: "community-operators",
      disabled: false
    }
  ]

Dans l'API Kubernetes, un resource est un point d'extrémité qui stocke une collection d'objets API d'un certain type. Par exemple, la ressource intégrée Pods contient une collection d'objets Pod.

Un objet custom resource definition (CRD) définit un nouveau type d'objet unique, appelé kind, dans le cluster et laisse le serveur API Kubernetes gérer l'ensemble de son cycle de vie.

Custom resource (CR) sont créés à partir des CRD qui ont été ajoutés au cluster par un administrateur du cluster, ce qui permet à tous les utilisateurs du cluster d'ajouter le nouveau type de ressource dans les projets.

Lorsqu'un administrateur de cluster ajoute un nouveau CRD au cluster, le serveur API Kubernetes réagit en créant un nouveau chemin de ressources RESTful accessible à l'ensemble du cluster ou à un seul projet (espace de noms) et commence à servir le CR spécifié.

Les administrateurs de clusters qui souhaitent accorder l'accès au CRD à d'autres utilisateurs peuvent utiliser l'agrégation des rôles de clusters pour accorder l'accès aux utilisateurs ayant les rôles de clusters par défaut admin, edit, ou view. L'agrégation de rôles permet d'insérer des règles personnalisées dans ces rôles. Ce comportement intègre la nouvelle ressource dans la politique RBAC du cluster comme s'il s'agissait d'une ressource intégrée.

Les opérateurs, en particulier, utilisent les CRD en les intégrant à toute politique RBAC requise et à toute autre logique propre au logiciel. Les administrateurs de cluster peuvent également ajouter manuellement des CRD au cluster en dehors du cycle de vie d'un opérateur, les mettant ainsi à la disposition de tous les utilisateurs.

Pour créer des objets de ressources personnalisées (CR), les administrateurs de clusters doivent d'abord créer une définition de ressources personnalisées (CRD).

Les administrateurs de clusters peuvent accorder des autorisations à des définitions de ressources personnalisées (CRD) existantes et adaptées aux clusters. Si vous utilisez les rôles de cluster par défaut admin, edit, et view, vous pouvez tirer parti de l'agrégation des rôles de cluster pour leurs règles.

Une fois qu'une définition de ressource personnalisée (CRD) a été ajoutée au cluster, des ressources personnalisées (CR) peuvent être créées à l'aide de l'interface CLI à partir d'un fichier utilisant la spécification CR.

Vous pouvez inspecter les objets de ressources personnalisées (CR) qui existent dans votre cluster à l'aide de la CLI.