2.3. Glossaire du cadre opérateur des termes communs

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

Dans le format de paquet, une image de paquet est une image de conteneur qui est construite à partir des manifestes de l’opérateur et qui contient un paquet. Les images groupées sont stockées et distribuées par les registres de conteneurs spec Open Container Initiative (OCI), tels que Quay.io ou DockerHub.

La source d’un catalogue représente une réserve de métadonnées que OLM peut interroger pour découvrir et installer des opérateurs et leurs dépendances.

Le canal 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. À titre d’exemple, un canal stable aurait toutes les versions stables d’un opérateur disposées du plus tôt au dernier.

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

La tête de canal fait référence à la dernière mise à jour connue d’un canal particulier.

La version de service de cluster (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. Ce sont les métadonnées qui accompagnent une image de conteneur d’opérateur, utilisée pour peupler les interfaces utilisateur avec des informations telles que son logo, sa description et sa version.

C’est aussi une source d’informations techniques qui est nécessaire pour exécuter l’opérateur, comme les règles RBAC qu’il exige et de quelles ressources personnalisées (CR) il gère ou dépend.

L’opérateur peut dépendre de la présence d’un autre opérateur dans le cluster. À titre d’exemple, l’opérateur Vault dépend de l’opérateur etcd pour sa couche de persistance des données.

L’OLM résout les dépendances en veillant à ce que toutes les versions spécifiées des opérateurs et des CRD soient 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 n’est pas lié à des paquets ou des paquets.

Les extensions permettent aux administrateurs de clusters d’étendre les capacités des utilisateurs de leur service Red Hat OpenShift sur le cluster AWS. Les extensions sont gérées par Operator Lifecycle Manager (OLM) v1.

L’API ClusterExtension simplifie la gestion des extensions installées, qui inclut des opérateurs via le format de paquet Register+v1, en consolidant les API face à l’utilisateur en un seul objet. Les administrateurs et les SRE peuvent utiliser l’API pour automatiser les processus et définir les états souhaités en utilisant les principes GitOps.

Dans le format de paquet, une image d’index se réfère à une image d’une base de données (un instantané de base de données) qui contient des informations sur les paquets Opérateur, y compris les CSV et les CRD de toutes les versions. Cet index peut héberger un historique d’opérateurs sur un cluster et être maintenu en ajoutant ou en supprimant des opérateurs à l’aide de l’outil Opm CLI.

Le plan d’installation est une liste calculée de ressources à créer pour installer ou mettre à niveau automatiquement un CSV.

Le locataire de Red Hat OpenShift Service sur AWS 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. Il est possible d’utiliser les locataires pour assurer un niveau d’isolement entre différents groupes ou équipes.

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

Les opérateurs constituent une méthode de mise en package, de déploiement et de gestion d’une application Kubernetes. L’application Kubernetes est une application qui est déployée sur Kubernetes et gérée à l’aide des API Kubernetes et des outils kubectl ou oc.

Dans Operator Lifecycle Manager (OLM) v1, l’API ClusterExtension simplifie la gestion des extensions installées, qui inclut les opérateurs via le format de paquet Register+v1.

Le groupe d’opérateurs configure tous les opérateurs déployés dans le même espace de noms que l’objet OperatorGroup pour surveiller leur CR dans une liste d’espaces de noms ou de clusters.

Dans le format de paquet, un paquet est un répertoire qui contient tout l’historique publié d’un opérateur avec chaque version. La version publiée d’un opérateur est décrite dans un manifeste CSV aux côtés des CRD.

Le registre est une base de données qui stocke des images groupées d’opérateurs, chacune avec toutes ses versions les plus récentes et historiques dans tous les canaux.

L’abonnement maintient les CSV à jour en suivant un canal dans un paquet.

Le graphique de mise à jour relie les versions de CSV ensemble, comme le graphique de mise à jour de tout autre logiciel emballé. Les opérateurs peuvent être installés de manière séquentielle, ou certaines versions peuvent être ignorées. Le graphique de mise à jour devrait croître uniquement en tête avec de nouvelles versions ajoutées.

Également connu sous le nom de bords de mise à jour ou chemins de mise à jour.