Red Hat Summit5.6. Définition des versions de service cluster (CSV)
La version de service de cluster (CSV), définie par un objet ClusterServiceVersion, est un manifeste YAML créé à partir des métadonnées de l’opérateur qui aide le gestionnaire de cycle de vie de l’opérateur (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.
Le SDK de l’opérateur comprend le générateur CSV pour générer un CSV pour le projet opérateur actuel, personnalisé à l’aide des informations contenues dans les manifestes YAML et les fichiers source de l’opérateur.
La version prise en charge par Red Hat de l’outil Operator SDK CLI, y compris les outils d’échafaudage et de test connexes pour les projets Opérateur, est dépréciée et devrait être supprimée dans une future version de Red Hat OpenShift Service sur AWS. Le Red Hat fournira des corrections de bogues et une prise en charge de cette fonctionnalité pendant le cycle de vie de la version actuelle, mais cette fonctionnalité ne recevra plus d’améliorations et sera supprimée du futur service Red Hat OpenShift sur les versions AWS.
La version prise en charge par Red Hat du SDK de l’opérateur n’est pas recommandée pour la création de nouveaux projets d’opérateur. Les auteurs d’opérateurs avec des projets d’opérateur existants peuvent utiliser la version de l’outil Operator SDK CLI publié avec Red Hat OpenShift Service sur AWS 4 pour maintenir leurs projets et créer des versions d’opérateur ciblant de nouvelles versions de Red Hat OpenShift Service sur AWS.
Les images de base suivantes pour les projets d’opérateur ne sont pas dépréciées. Les fonctionnalités d’exécution et les API de configuration de ces images de base sont toujours prises en charge pour les corrections de bogues et pour l’adressage des CVE.
- L’image de base pour les projets d’opérateurs basés sur Ansible
- L’image de base pour les projets d’opérateur basé sur Helm
Afin d’obtenir de l’information sur la version non prise en charge et gérée par la communauté du SDK de l’opérateur, voir Operator SDK (Operator Framework).
La commande génératrice de CSV supprime la responsabilité des auteurs de l’opérateur ayant des connaissances approfondies en OLM afin que leur opérateur interagisse avec OLM ou publie des métadonnées dans le Registre de catalogue. De plus, étant donné que la spécification CSV changera probablement avec le temps à mesure que de nouvelles fonctionnalités Kubernetes et OLM seront mises en œuvre, le SDK de l’opérateur est équipé pour étendre facilement son système de mise à jour afin de gérer de nouvelles fonctionnalités CSV à l’avenir.
5.6.1. Comment fonctionne la génération de CSV
Les manifestes de paquets d’opérateurs, qui incluent des versions de service cluster (CSV), décrivent comment afficher, créer et gérer une application avec Operator Lifecycle Manager (OLM). Le générateur CSV dans le SDK de l’opérateur, appelé par la sous-commande de groupement génératrice, est la première étape vers la publication de votre opérateur dans un catalogue et le déployer avec OLM. La sous-commande nécessite certains manifestes d’entrée pour construire un manifeste CSV; toutes les entrées sont lues lorsque la commande est invoquée, avec une base CSV, pour générer ou régénérer idempotentement un CSV.
En règle générale, la sous-commande des manifestes de kustomize génératrice serait exécutée en premier pour générer les bases Kustomize d’entrée qui sont consommées par la sous-commande de paquets génératrices. Cependant, le SDK de l’opérateur fournit la commande make bundle, qui automatise plusieurs tâches, y compris l’exécution des sous-commandes suivantes dans l’ordre:
-
générer des manifestes de kustomize -
générer des paquets -
la validation du paquet
5.6.1.1. Fichiers et ressources générés
La commande make bundle crée les fichiers et répertoires suivants dans votre projet Opérateur:
- Le bundle manifeste un répertoire nommé bundle/manifests qui contient un objet ClusterServiceVersion (CSV)
- Annuaire de métadonnées groupé nommé bundle/metadata
- L’ensemble des définitions de ressources personnalisées (CRD) dans un répertoire config/crd
- Dockerfile bundle.Dockerfile
Les ressources suivantes sont généralement incluses dans un CSV:
- Le rôle
- Définit les autorisations de l’opérateur dans un espace de noms.
- ClusterRole
- Définit les autorisations de l’opérateur à l’échelle du cluster.
- Déploiement
- Définit comment un Operand d’un opérateur est exécuté en pods.
- CustomResourceDefinition (CRD)
- Définit des ressources personnalisées que votre opérateur réconcilie.
- Exemples de ressources personnalisées
- Exemples de ressources adhérant à la spécification d’un CRD particulier.
5.6.1.2. Gestion des versions
L’indicateur --version pour la sous-commande de paquet génératrice fournit une version sémantique pour votre paquet lors de la création d’un pour la première fois et lors de la mise à niveau d’une version existante.
En définissant la variable VERSION dans votre Makefile, l’indicateur --version est automatiquement invoqué à l’aide de cette valeur lorsque la sous-commande de paquet généré est exécutée par la commande make bundle. La version CSV est la même que la version de l’opérateur, et un nouveau CSV est généré lors de la mise à niveau des versions de l’opérateur.
5.6.2. Champs CSV définis manuellement
De nombreux champs CSV ne peuvent pas être peuplés à l’aide de manifestes génériques générés qui ne sont pas spécifiques à l’opérateur SDK. Ces champs sont principalement des métadonnées écrites par l’homme sur l’opérateur et diverses définitions de ressources personnalisées (CRD).
Les auteurs de l’opérateur doivent modifier directement leur fichier YAML version de service de cluster (CSV) en ajoutant des données personnalisées aux champs requis suivants. Le SDK d’opérateur donne un avertissement lors de la génération de CSV lorsqu’un manque de données dans l’un des champs requis est détecté.
Les tableaux suivants détaillent les champs CSV définis manuellement et qui sont facultatifs.
| Le champ | Description |
|---|---|
|
| C’est un nom unique pour ce CSV. La version de l’opérateur doit être incluse dans le nom pour assurer l’unicité, par exemple app-operator.v0.1.1. |
|
| Le niveau de capacité selon le modèle de maturité de l’opérateur. Les options incluent l’installation de base, les mises à niveau sans soudure, le cycle de vie complet, les informations approfondies et le pilote automatique. |
|
| Le nom public permettant d’identifier l’opérateur. |
|
| Brève description de la fonctionnalité de l’opérateur. |
|
| Les mots clés décrivant l’opérateur. |
|
| Entités humaines ou organisationnelles qui maintiennent l’opérateur, avec un nom et un courriel. |
|
| Le fournisseur de l’opérateur (généralement une organisation), avec un nom. |
|
| Paires clés-valeur à utiliser par les internes de l’opérateur. |
|
| La version sémantique de l’opérateur, par exemple 0.1.1. |
|
| Les CRD que l’Opérateur utilise. Ce champ est rempli automatiquement par le SDK de l’opérateur si des fichiers YAML CRD sont présents dans le déploiement/. Cependant, plusieurs champs qui ne figurent pas dans la spécification du manifeste CRD nécessitent l’entrée de l’utilisateur:
|
| Le champ | Description |
|---|---|
|
| Le nom du CSV étant remplacé par ce CSV. |
|
| Les URL (par exemple, sites Web et documentation) relatives à l’opérateur ou à l’application gérée, chacune avec un nom et une url. |
|
| Les sélecteurs par lesquels l’opérateur peut associer des ressources dans un cluster. |
|
| Icône encodée base64 unique à l’opérateur, définie dans un champ de données base64 avec un type média. |
|
| Le niveau de maturité que le logiciel a atteint à cette version. Les options comprennent la planification, pré-alpha, alpha, bêta, stable, mature, inactive et dépréciée. |
De plus amples détails sur les données que chaque champ ci-dessus devrait contenir sont trouvés dans la spécification CSV.
À l’heure actuelle, plusieurs champs YAML nécessitant une intervention de l’utilisateur peuvent potentiellement être analysés à partir du code opérateur.
5.6.3. Annotations de métadonnées de l’opérateur
Les développeurs d’opérateurs peuvent définir certaines annotations dans les métadonnées d’une version de service de cluster (CSV) pour activer des fonctionnalités ou mettre en évidence des fonctionnalités dans les interfaces utilisateur (UI), telles que OperatorHub ou Red Hat Ecosystem Catalog. Les annotations de métadonnées de l’opérateur sont définies manuellement en définissant le champ métadonnées.annotations dans le fichier CSV YAML.
5.6.3.1. L’infrastructure comporte des annotations
Les annotations dans le groupe features.operators.openshift.io détaillent les fonctionnalités d’infrastructure qu’un opérateur peut prendre en charge, spécifiées en définissant une valeur "vraie" ou "faux". Les utilisateurs peuvent visualiser et filtrer par ces fonctionnalités lors de la découverte des opérateurs via OperatorHub dans la console Web ou dans le catalogue de l’écosystème Red Hat. Ces annotations sont prises en charge dans Red Hat OpenShift Service sur AWS 4.10 et plus tard.
L’infrastructure Feature.operators.openshift.io comporte des annotations déprécater les annotations.openshift.io/infrastructures utilisées dans les versions antérieures de Red Hat OpenShift Service sur AWS. Consultez « Annotations de fonctionnalités d’infrastructure dépréciée » pour plus d’informations.
| Annotation | Description | Les valeurs valides[1] |
|---|---|---|
|
| Indiquez si un opérateur prend en charge la mise en miroir dans des catalogues déconnectés, y compris toutes les dépendances, et ne nécessite pas d’accès à Internet. L’opérateur utilise le champ spec.relatedImages CSV pour se référer à toute image liée par son digeste. | "vrai" ou "faux" |
|
| Indiquez si un opérateur accepte la configuration FIPS-140 de la plate-forme sous-jacente et fonctionne sur des nœuds qui sont démarrés en mode FIPS. Dans ce mode, l’opérateur et toutes les charges de travail qu’il gère (opérateurs) appellent uniquement la bibliothèque cryptographique Red Hat Enterprise Linux (RHEL) soumise pour validation FIPS-140. | "vrai" ou "faux" |
|
| Indiquez si un opérateur prend en charge l’exécution d’un cluster derrière un proxy en acceptant les variables d’environnement proxy HTTP_PROXY et HTTPS_PROXY standard. Le cas échéant, l’opérateur transmet ces informations à la charge de travail qu’il gère (opérateurs). | "vrai" ou "faux" |
|
| Indiquez si un opérateur met en œuvre des réglages bien connus pour modifier la suite de chiffrement TLS utilisée par l’opérateur et, le cas échéant, l’une des charges de travail qu’il gère (opérateurs). | "vrai" ou "faux" |
|
| Indiquez si un opérateur prend en charge la configuration pour l’authentification tokenized avec les API AWS via AWS Secure Token Service (STS) à l’aide de l’opérateur d’identification en nuage (CCO). | "vrai" ou "faux" |
|
| Indiquez si un opérateur prend en charge la configuration pour l’authentification tokenized avec les API Azure via Azure Managed Identity à l’aide de l’opérateur d’identification en nuage (CCO). | "vrai" ou "faux" |
|
| Indiquez si un opérateur prend en charge la configuration pour l’authentification tokenized avec les API Google Cloud via GCP Workload Identity Foundation (WIF) à l’aide de l’opérateur d’identification en nuage (CCO). | "vrai" ou "faux" |
|
| Indiquez si un opérateur fournit un plugin Kubernetes (Native Network Function) Cloud-Native Network Function (CNF). | "vrai" ou "faux" |
|
| Indiquez si un opérateur fournit un plugin Kubernetes (Container Network Interface) (CNI). | "vrai" ou "faux" |
|
| Indiquez si un opérateur fournit un plugin Kubernetes (CSI) Kubernetes. | "vrai" ou "faux" |
- Les valeurs valides sont affichées intentionnellement avec des guillemets doubles, car les annotations Kubernetes doivent être des chaînes.
Exemple CSV avec des annotations de fonctionnalités d’infrastructure
5.6.3.2. L’infrastructure dépréciée comporte des annotations
À partir de Red Hat OpenShift Service sur AWS 4.14, le groupe d’annotations operators.openshift.io/infrastructure-features est déprécié par le groupe d’annotations avec l’espace de noms features.operators.openshift.io. Bien que vous soyez encouragé à utiliser les annotations les plus récentes, les deux groupes sont actuellement acceptés lorsqu’ils sont utilisés en parallèle.
Ces annotations détaillent les caractéristiques de l’infrastructure qu’un opérateur prend en charge. Les utilisateurs peuvent visualiser et filtrer par ces fonctionnalités lors de la découverte des opérateurs via OperatorHub dans la console Web ou dans le catalogue de l’écosystème Red Hat.
| Les valeurs d’annotation valides | Description |
|---|---|
|
| L’opérateur prend en charge la mise en miroir dans des catalogues déconnectés, y compris toutes les dépendances, et ne nécessite pas d’accès à Internet. Les images associées requises pour la mise en miroir sont répertoriées par l’opérateur. |
|
| L’opérateur fournit un plugin Kubernetes (CNF) dans le Cloud-Native Network Functions (CNF). |
|
| L’opérateur fournit un plugin Kubernetes de Container Network Interface (CNI). |
|
| L’opérateur fournit un plugin Kubernetes d’interface de stockage de conteneurs (CSI). |
|
| L’opérateur accepte le mode FIPS de la plate-forme sous-jacente et fonctionne sur des nœuds qui sont démarrés en mode FIPS. Important Lors de l’exécution Red Hat Enterprise Linux (RHEL) ou Red Hat Enterprise Linux CoreOS (RHCOS) démarré en mode FIPS, Red Hat OpenShift Service sur les composants de base AWS utilisent les bibliothèques cryptographiques RHEL qui ont été soumises au NIST pour FIPS 140-2/140-3 Validation sur seulement les architectures x86_64, ppc64le et s390x. |
|
| L’opérateur prend en charge l’exécution d’un cluster derrière un proxy. L’opérateur accepte les variables d’environnement proxy standard HTTP_PROXY et HTTPS_PROXY, que le gestionnaire de cycle de vie de l’opérateur (OLM) fournit automatiquement à l’opérateur lorsque le cluster est configuré pour utiliser un proxy. Les variables d’environnement requises sont transmises à Operands pour les charges de travail gérées. |
Exemple CSV avec support déconnecté et proxy-aware
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
annotations:
operators.openshift.io/infrastructure-features: '["disconnected", "proxy-aware"]'
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
annotations:
operators.openshift.io/infrastructure-features: '["disconnected", "proxy-aware"]'5.6.3.3. Autres annotations facultatives
Les annotations suivantes de l’opérateur sont facultatives.
| Annotation | Description |
|---|---|
|
| Fournissez des modèles de définition de ressources personnalisées (CRD) avec un ensemble minimal de configuration. Compatible UIs pré-rempli ce modèle pour les utilisateurs à personnaliser davantage. |
|
| Indiquez une seule ressource personnalisée requise en ajoutant l’annotation de la ressource d’initialisation à la version de service cluster (CSV) pendant l’installation de l’opérateur. L’utilisateur est alors invité à créer la ressource personnalisée à l’aide d’un modèle fourni dans le CSV. Doit inclure un modèle contenant une définition complète de YAML. |
|
| Définissez un espace de noms suggéré où l’opérateur devrait être déployé. |
|
| Définissez un manifeste pour un objet Namespace avec le sélecteur de nœud par défaut pour l’espace de noms spécifié. |
|
| Le tableau de forme gratuite pour la liste des abonnements spécifiques qui sont nécessaires pour utiliser l’opérateur. À titre d’exemple, '["3Scale Commercial License", "Red Hat Managed Integration"] |
|
| Cache les CRD dans l’interface utilisateur qui ne sont pas destinés à la manipulation des utilisateurs. |
Exemple CSV avec un service OpenShift Red Hat sur l’exigence de licence AWS
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
annotations:
operators.openshift.io/valid-subscription: '["OpenShift Container Platform"]'
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
annotations:
operators.openshift.io/valid-subscription: '["OpenShift Container Platform"]'Exemple CSV avec une exigence de licence 3scale
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
annotations:
operators.openshift.io/valid-subscription: '["3Scale Commercial License", "Red Hat Managed Integration"]'
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
annotations:
operators.openshift.io/valid-subscription: '["3Scale Commercial License", "Red Hat Managed Integration"]'5.6.4. Activer votre opérateur pour les environnements réseau restreints
En tant qu’auteur de l’opérateur, votre opérateur doit répondre à des exigences supplémentaires pour fonctionner correctement dans un environnement restreint ou déconnecté.
Exigences de l’opérateur pour soutenir le mode déconnecté
- Le remplacement des références d’images codées en dur par des variables d’environnement.
Dans la version de service cluster (CSV) de votre opérateur:
- Énumérez toutes les images connexes, ou d’autres images de conteneurs dont votre opérateur pourrait avoir besoin pour exécuter leurs fonctions.
- Faites référence à toutes les images spécifiées par un digest (SHA) et non par une balise.
- Les dépendances de votre opérateur doivent également prendre en charge l’exécution en mode déconnecté.
- L’opérateur ne doit pas avoir besoin de ressources hors groupe.
Conditions préalables
- D’un projet d’opérateur avec un CSV. La procédure suivante utilise l’opérateur Memcached comme exemple pour les projets basés sur Go, Ansible et Helm.
Procédure
Définissez une variable d’environnement pour les références d’image supplémentaires utilisées par l’opérateur dans le fichier config/manager/manager.yaml:
Le remplacement des références d’image codées en dur par des variables d’environnement dans le fichier pertinent pour votre type de projet Opérateur:
Dans le cas des projets Go-based Operator, ajoutez la variable d’environnement au fichier Controllers/memcached_controller.go comme indiqué dans l’exemple suivant:
Exemple 5.3. Exemple de contrôleurs/memcached_controller.go fichier
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteLa fonction os.Getenv renvoie une chaîne vide si une variable n’est pas définie. Définissez le <related_image_environnement_variable> avant de modifier le fichier.
Dans le cas des projets d’opérateur basé sur Ansible, ajoutez la variable d’environnement au fichier role/memcached/tasks/main.yml comme indiqué dans l’exemple suivant:
Dans le cas des projets d’opérateur basé sur Helm, ajoutez le champ OverrideValues au fichier watch.yaml comme indiqué dans l’exemple suivant:
Exemple 5.5. Exemple watch.yaml fichier
Ajoutez la valeur du champ OverrideValues au fichier helm-charts/memchached/values.yaml comme indiqué dans l’exemple suivant:
Exemple de fichier helm-charts/memchached/values.yaml
... relatedImage: ""
... relatedImage: ""Copy to Clipboard Copied! Toggle word wrap Toggle overflow Éditez le modèle de graphique dans le fichier helm-charts/memcached/templates/deployment.yaml comme indiqué dans l’exemple suivant:
Ajoutez la définition de variable BUNDLE_GEN_FLAGS à votre Makefile avec les modifications suivantes:
Exemple de Makefile
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Afin de mettre à jour votre image de l’opérateur pour utiliser un digest (SHA) et non une balise, exécutez la commande make bundle et définissez USE_IMAGE_DIGESTS sur true:
make bundle USE_IMAGE_DIGESTS=true
$ make bundle USE_IMAGE_DIGESTS=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ajouter l’annotation déconnectée, qui indique que l’opérateur fonctionne dans un environnement déconnecté:
metadata: annotations: operators.openshift.io/infrastructure-features: '["disconnected"]'metadata: annotations: operators.openshift.io/infrastructure-features: '["disconnected"]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Les opérateurs peuvent être filtrés dans OperatorHub par cette fonctionnalité d’infrastructure.
5.6.5. Activer votre opérateur pour plusieurs architectures et systèmes d’exploitation
Le gestionnaire de cycle de vie de l’opérateur (OLM) suppose que tous les opérateurs s’exécutent sur des hôtes Linux. Cependant, en tant qu’auteur de l’opérateur, vous pouvez spécifier si votre opérateur prend en charge la gestion des charges de travail sur d’autres architectures, si les nœuds de travail sont disponibles dans le service Red Hat OpenShift sur le cluster AWS.
Dans le cas où votre opérateur prend en charge des variantes autres que AMD64 et Linux, vous pouvez ajouter des étiquettes à la version de service de cluster (CSV) qui fournit à l’opérateur la liste des variantes prises en charge. Les étiquettes indiquant les architectures et les systèmes d’exploitation pris en charge sont définies par ce qui suit:
labels:
operatorframework.io/arch.<arch>: supported
operatorframework.io/os.<os>: supported
labels:
operatorframework.io/arch.<arch>: supported
operatorframework.io/os.<os>: supported Il n’y a que les étiquettes sur la tête du canal par défaut pour filtrer les manifestes de paquets par étiquette. Cela signifie, par exemple, qu’il est possible de fournir une architecture supplémentaire à un opérateur dans le canal non par défaut, mais que cette architecture n’est pas disponible pour le filtrage dans l’API PackageManifest.
Dans le cas où un CSV n’inclut pas d’étiquette os, il est traité comme s’il avait l’étiquette de support Linux suivante par défaut:
labels:
operatorframework.io/os.linux: supported
labels:
operatorframework.io/os.linux: supportedLorsqu’un CSV n’inclut pas d’étiquette d’arche, il est traité comme s’il avait l’étiquette de support AMD64 suivante par défaut:
labels:
operatorframework.io/arch.amd64: supported
labels:
operatorframework.io/arch.amd64: supportedLorsqu’un opérateur prend en charge plusieurs architectures de nœuds ou systèmes d’exploitation, vous pouvez également ajouter plusieurs étiquettes.
Conditions préalables
- D’un projet d’opérateur avec un CSV.
- Afin de prendre en charge la liste de plusieurs architectures et systèmes d’exploitation, l’image de votre opérateur référencée dans le CSV doit être une image de liste manifeste.
- Afin que l’opérateur fonctionne correctement dans un réseau restreint, ou déconnecté, l’image référencée doit également être spécifiée à l’aide d’un digeste (SHA) et non par une balise.
Procédure
Ajoutez une étiquette dans les métadonnées.labels de votre CSV pour chaque architecture et système d’exploitation pris en charge par votre opérateur:
labels: operatorframework.io/arch.s390x: supported operatorframework.io/os.zos: supported operatorframework.io/os.linux: supported operatorframework.io/arch.amd64: supported
labels: operatorframework.io/arch.s390x: supported operatorframework.io/os.zos: supported operatorframework.io/os.linux: supported1 operatorframework.io/arch.amd64: supported2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.5.1. Architecture et support du système d’exploitation pour les opérateurs
Les chaînes suivantes sont prises en charge dans Operator Lifecycle Manager (OLM) sur Red Hat OpenShift Service sur AWS lors de l’étiquetage ou du filtrage des opérateurs qui prennent en charge plusieurs architectures et systèmes d’exploitation:
| Architecture | Chaîne de caractères |
|---|---|
| AMD64 |
|
| ARM64 |
|
| IBM Power® |
|
| IBM Z® |
|
| Le système d’exploitation | Chaîne de caractères |
|---|---|
| Linux |
|
| à propos de Z/OS |
|
Différentes versions de Red Hat OpenShift Service sur AWS et d’autres distributions basées sur Kubernetes peuvent prendre en charge un ensemble différent d’architectures et de systèmes d’exploitation.
5.6.6. Définition d’un espace de noms suggéré
Certains opérateurs doivent être déployés dans un espace de noms spécifique, ou avec des ressources accessoires dans des espaces de noms spécifiques, pour fonctionner correctement. En cas de résolution d’un abonnement, Operator Lifecycle Manager (OLM) par défaut des ressources d’un opérateur par défaut sur l’espace de noms de son abonnement.
En tant qu’auteur de l’opérateur, vous pouvez plutôt exprimer un espace de noms cible souhaité dans le cadre de votre version de service de cluster (CSV) afin de maintenir le contrôle sur les espaces de noms finaux des ressources installées pour leurs opérateurs. Lors de l’ajout de l’opérateur à un cluster en utilisant OperatorHub, cela permet à la console Web de remplir automatiquement l’espace de noms suggéré pour l’installateur pendant le processus d’installation.
Procédure
Dans votre CSV, définissez l’annotation operatorframework.io/suggéré-namespace à votre espace de noms suggéré:
metadata: annotations: operatorframework.io/suggested-namespace: <namespace>metadata: annotations: operatorframework.io/suggested-namespace: <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Définissez votre espace de noms suggéré.
5.6.7. Définir un espace de noms suggéré avec le sélecteur de nœud par défaut
Certains opérateurs s’attendent à fonctionner uniquement sur les nœuds de plan de contrôle, ce qui peut être fait en définissant un nodeSelector dans la spécification Pod par l’opérateur lui-même.
Afin d’éviter d’être dupliqués et potentiellement contradictoires, vous pouvez définir un sélecteur de nœuds par défaut sur l’espace de noms où l’opérateur s’exécute. Le sélecteur de nœud par défaut aura préséance sur le cluster par défaut, de sorte que le cluster par défaut ne sera pas appliqué aux pods dans l’espace de noms des opérateurs.
Lors de l’ajout de l’opérateur à un cluster en utilisant OperatorHub, la console Web peuple automatiquement l’espace de noms suggéré pour l’installateur pendant le processus d’installation. L’espace de noms suggéré est créé à l’aide du manifeste de l’espace de noms dans YAML qui est inclus dans la version de service cluster (CSV).
Procédure
Dans votre CSV, définissez l’opérateurframework.io/suggéré-namespace-template avec un manifeste pour un objet Namespace. L’échantillon suivant est un manifeste pour un exemple Namespace avec le sélecteur de nœud par défaut de namespace spécifié:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Définissez votre espace de noms suggéré.
NoteLorsque les annotations suggérées-namespace et suggéré-namespace-template sont présentes dans le CSV, le modèle suggéré-namespace-template devrait primer.
5.6.8. Conditions d’activation de l’opérateur
Le gestionnaire de cycle de vie de l’opérateur (OLM) fournit aux opérateurs un canal pour communiquer des états complexes qui influencent le comportement OLM tout en gérant l’opérateur. Par défaut, OLM crée une définition de ressource personnalisée OperatorCondition (CRD) lorsqu’elle installe un opérateur. En fonction des conditions définies dans la ressource personnalisée OperatorCondition (CR), le comportement de OLM change en conséquence.
Afin de prendre en charge les conditions de l’opérateur, un opérateur doit être en mesure de lire la version CR de l’opérateur créé par OLM et d’avoir la capacité d’accomplir les tâches suivantes:
- Ayez la condition spécifique.
- Définissez l’état d’une condition spécifique.
Cela peut être accompli en utilisant la bibliothèque opérateur-lib. L’auteur d’un opérateur peut fournir un client d’exécution du contrôleur dans son opérateur pour que la bibliothèque puisse accéder à la version CR de l’opérateur appartenant à l’opérateur dans le cluster.
La bibliothèque fournit une interface Conditions génériques, qui dispose des méthodes suivantes pour obtenir et définir un type de condition dans la version CR de l’opérateur:
J’obtiens- Afin d’obtenir la condition spécifique, la bibliothèque utilise la fonction client.Get de contrôleur-runtime, qui nécessite une ObjectKey des types de type.NamespacedName présent dans conditionAccessor.
Ensemble- Afin de mettre à jour l’état de la condition spécifique, la bibliothèque utilise la fonction client.Update à partir du contrôleur-runtime. L’erreur se produit si la conditionType n’est pas présente dans le CRD.
L’opérateur est autorisé à modifier uniquement la sous-ressource d’état du CR. Les opérateurs peuvent soit supprimer ou mettre à jour le tableau status.conditions pour inclure la condition. Afin de plus amples détails sur le format et la description des champs présents dans les conditions, voir l’Amont Condition GoDocs.
L’opérateur SDK 1.38.0 prend en charge la v0.11.0 de l’opérateur.
Conditions préalables
- Le projet d’opérateur généré à l’aide du SDK de l’opérateur.
Procédure
Activer les conditions de l’opérateur dans votre projet Opérateur:
Dans le fichier go.mod de votre projet Opérateur, ajoutez l’opérateur-cadre/opérateur-lib comme bibliothèque requise:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Écrivez votre propre constructeur dans votre logique d’opérateur qui se traduira par les résultats suivants:
- Accepte un client d’exécution de contrôleur.
- Accepte un type de condition.
- Il retourne une interface Condition pour mettre à jour ou ajouter des conditions.
Comme OLM prend actuellement en charge la condition Upgradeable, vous pouvez créer une interface qui dispose de méthodes pour accéder à la condition Upgradeable. À titre d’exemple:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Dans cet exemple, le constructeur NewUpgradeable est en outre utilisé pour créer un cond variable de type Condition. La variable cond aurait à son tour des méthodes Get and Set, qui peuvent être utilisées pour gérer la condition OLM Upgradeable.
5.6.9. Définir des webhooks
Les webhooks permettent aux auteurs de l’opérateur d’intercepter, de modifier et d’accepter ou de rejeter des ressources avant qu’elles ne soient enregistrées dans le magasin d’objets et traitées par le contrôleur de l’opérateur. Le gestionnaire de cycle de vie de l’opérateur (OLM) peut gérer le cycle de vie de ces webhooks lorsqu’ils sont expédiés aux côtés de votre opérateur.
La ressource de la version de service de cluster (CSV) d’un opérateur peut inclure une section Webhookdefinitions pour définir les types suivants de webhooks:
- Admission webhooks (validation et mutation)
- Conversion webhooks
Procédure
Ajoutez une section Webhookdefinitions à la section Spécifications du CSV de votre opérateur et incluez toutes les définitions de webhook à l’aide d’un type de ValidatingAdmissionWebhook, MutatingAdmissionWebhook ou ConversionWebhook. L’exemple suivant contient les trois types de webhooks:
CSV contenant des webhooks
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.9.1. Considérations Webhook pour OLM
Lorsque vous déployez un opérateur avec des webhooks à l’aide du gestionnaire de cycle de vie de l’opérateur (OLM), vous devez définir ce qui suit:
- Le champ type doit être défini sur ValidatingAdmissionWebhook, MutatingAdmissionWebhook ou ConversionWebhook, ou le CSV sera placé dans une phase défaillante.
- Le CSV doit contenir un déploiement dont le nom est équivalent à la valeur fournie dans le champ deploymentName de la définition webhook.
Lorsque le webhook est créé, OLM s’assure que le webhook agit uniquement sur les espaces de noms correspondant au groupe d’opérateur dans lequel l’opérateur est déployé.
Contraintes de l’autorité de certification
L’OLM est configurée pour fournir à chaque déploiement une seule autorité de certificat (CA). La logique qui génère et monte l’AC dans le déploiement a été utilisée à l’origine par la logique du cycle de vie de l’API. En conséquence:
- Le fichier de certificat TLS est monté au déploiement sur /apiserver.local.config/certificates/apiserver.crt.
- Le fichier clé TLS est monté au déploiement sur /apiserver.local.config/certificates/apiserver.key.
Les règles d’admission sur le webhook
Afin d’empêcher un opérateur de configurer le cluster dans un état non récupérable, OLM place le CSV dans la phase défaillante si les règles définies dans un webhook d’admission interceptent l’une des requêtes suivantes:
- Demandes qui ciblent tous les groupes
- Demande qui cible le groupe operators.coreos.com
- Demandes qui ciblent les ressources ValidatingWebhookConfigurations ou MutatingWebhookConfigurations
Contraintes de conversion webhook
L’OMM place le CSV dans la phase défaillante si une définition de webhook de conversion n’adhère pas aux contraintes suivantes:
- Les CSV dotés d’un webhook de conversion ne peuvent prendre en charge que le mode d’installation d’AllNamespaces.
- Le CRD ciblé par le webhook de conversion doit avoir son champ spec.preserveUnknownFields mis à faux ou nul.
- Le webhook de conversion défini dans le CSV doit cibler un CRD détenu.
- Il ne peut y avoir qu’un seul webhook de conversion sur l’ensemble du cluster pour un CRD donné.
5.6.10. Comprendre vos définitions de ressources personnalisées (CRD)
Il existe deux types de définitions de ressources personnalisées (CRD) que votre opérateur peut utiliser : celles qui lui appartiennent et celles dont elle dépend, qui sont nécessaires.
5.6.10.1. Les CRD possédés
Les définitions de ressources personnalisées (CRD) détenues par votre opérateur sont la partie la plus importante de votre CSV. Cela établit le lien entre votre opérateur et les règles RBAC requises, la gestion des dépendances et d’autres concepts de Kubernetes.
Il est courant pour votre opérateur d’utiliser plusieurs CRD pour relier des concepts, tels que la configuration de base de données de haut niveau dans un objet et une représentation des ensembles de répliques dans un autre. Chacun doit être indiqué dans le fichier CSV.
| Le champ | Description | Requis/facultatif |
|---|---|---|
|
| Le nom complet de votre CRD. | A) requis |
|
| La version de cette API objet. | A) requis |
|
| Le nom lisible par la machine de votre CRD. | A) requis |
|
| Il s’agit d’une version lisible humaine de votre nom CRD, par exemple MongoDB Standalone. | A) requis |
|
| Brève description de la façon dont ce CRD est utilisé par l’Opérateur ou une description de la fonctionnalité fournie par le CRD. | A) requis |
|
| Le groupe API auquel appartient ce CRD, par exemple Database.example.com. | Facultatif |
|
| Les CRD possèdent un ou plusieurs types d’objets Kubernetes. Ceux-ci sont listés dans la section ressources pour informer vos utilisateurs des objets dont ils pourraient avoir besoin pour résoudre les problèmes ou comment se connecter à l’application, comme la règle du service ou de l’entrée qui expose une base de données. Il est recommandé de ne énumérer que les objets qui sont importants pour un humain, pas une liste exhaustive de tout ce que vous orchestrez. À titre d’exemple, ne répertoriez pas les cartes de configuration qui stockent l’état interne qui ne sont pas destinés à être modifiés par un utilisateur. | Facultatif |
| Description des SpecDescripteurs, StatutDescripteurs et ActionDescripteurs | Ces descripteurs sont un moyen d’indiquer les UI avec certaines entrées ou sorties de votre opérateur qui sont les plus importantes pour un utilisateur final. Lorsque votre CRD contient le nom d’une carte secrète ou de configuration que l’utilisateur doit fournir, vous pouvez le spécifier ici. Ces éléments sont liés et mis en évidence dans les UI compatibles. Il existe trois types de descripteurs:
Les descripteurs acceptent les champs suivants:
Consultez également le projet openshift/console pour plus d’informations sur Descripteurs en général. | Facultatif |
L’exemple suivant représente un CRD autonome MongoDB qui nécessite une entrée de l’utilisateur sous la forme d’une carte secrète et de configuration, et orchestrate les services, les ensembles d’état, les pods et les cartes de configuration:
Exemple appartenant à CRD
5.6.10.2. CRD requis
Compter sur d’autres CRD requis est complètement facultatif et n’existe que pour réduire la portée des opérateurs individuels et fournir un moyen de composer plusieurs opérateurs ensemble pour résoudre un cas d’utilisation de bout en bout.
C’est un exemple d’opérateur qui pourrait configurer une application et installer un cluster etcd (à partir d’un opérateur etcd) à utiliser pour le verrouillage distribué et une base de données Postgres (à partir d’un opérateur Postgres) pour le stockage des données.
Le gestionnaire de cycle de vie de l’opérateur (OLM) vérifie les CRD et les opérateurs disponibles dans le cluster pour répondre à ces exigences. Lorsque des versions appropriées sont trouvées, les opérateurs sont lancés dans l’espace de noms souhaité et un compte de service créé pour chaque opérateur pour créer, surveiller et modifier les ressources Kubernetes requises.
| Le champ | Description | Requis/facultatif |
|---|---|---|
|
| Le nom complet du CRD dont vous avez besoin. | A) requis |
|
| La version de cette API objet. | A) requis |
|
| Le genre d’objets Kubernetes. | A) requis |
|
| C’est une version lisible par l’homme de la CRD. | A) requis |
|
| Le résumé de la façon dont le composant s’intègre dans votre architecture plus grande. | A) requis |
Exemple requis CRD
5.6.10.3. Les mises à niveau de CRD
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:
- Dans le nouveau CRD, toutes les versions de service existantes sont présentes dans le nouveau CRD.
- Les instances existantes, ou ressources personnalisées, associées aux versions de service du CRD sont valides lorsqu’elles sont validées par rapport au schéma de validation du nouveau CRD.
5.6.10.3.1. Ajout d’une nouvelle version CRD
Procédure
Ajouter une nouvelle version d’un CRD à votre opérateur:
Ajoutez une nouvelle entrée dans la ressource CRD dans la section versions de votre CSV.
Ainsi, si le CRD actuel possède une version v1alpha1 et que vous souhaitez ajouter une nouvelle version v1beta1 et la marquer comme nouvelle version de stockage, ajoutez une nouvelle entrée pour v1beta1:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- C’est une nouvelle entrée.
Assurez-vous que la version de référence de la CRD dans la section propre de votre CSV est mise à jour si le CSV a l’intention d’utiliser la nouvelle version:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Actualisez la version.
- Appuyez sur le CRD et le CSV mis à jour sur votre paquet.
5.6.10.3.2. Dépréciation ou suppression d’une version CRD
Le gestionnaire de cycle de vie de l’opérateur (OLM) ne permet pas de supprimer immédiatement une version de service d’une définition de ressource personnalisée (CRD). Au lieu de cela, une version obsolète du CRD doit d’abord être désactivée en définissant le champ servi dans le CRD à faux. Ensuite, la version non-servante peut être supprimée sur la mise à niveau CRD ultérieure.
Procédure
Déprécier et supprimer une version spécifique d’un CRD:
Marquer la version obsolète comme non-servant pour indiquer que cette version n’est plus utilisée et peut être supprimée dans une mise à jour ultérieure. À titre d’exemple:
versions: - name: v1alpha1 served: false storage: trueversions: - name: v1alpha1 served: false1 storage: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- J’ai mis sur false.
Basculez la version de stockage en version de service si la version à déprécier est actuellement la version de stockage. À titre d’exemple:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteAfin de supprimer une version spécifique qui est ou était la version de stockage d’un CRD, cette version doit être supprimée de la version stockée dans l’état du CRD. Les OLM tenteront de le faire pour vous s’il détecte qu’une version stockée n’existe plus dans le nouveau CRD.
- Améliorez le CRD avec les modifications ci-dessus.
Dans les cycles de mise à niveau ultérieurs, la version non-servante peut être complètement supprimée du CRD. À titre d’exemple:
versions: - name: v1beta1 served: true storage: trueversions: - name: v1beta1 served: true storage: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Assurez-vous que la version CRD de référence dans la section détenue de votre CSV est mise à jour en conséquence si cette version est supprimée du CRD.
5.6.10.4. Les modèles CRD
Les utilisateurs de votre opérateur doivent être informés des options requises par rapport aux options facultatives. Il est possible de fournir des modèles pour chacune de vos définitions de ressources personnalisées (CRD) avec un ensemble minimal de configuration sous forme d’annotation nommée alm-exemples. Compatible UIs pré-remplira ce modèle pour les utilisateurs à personnaliser davantage.
L’annotation se compose d’une liste du type, par exemple, le nom CRD et les métadonnées et spécifications correspondantes de l’objet Kubernetes.
L’exemple complet suivant fournit des modèles pour EtcdCluster, EtcdBackup et EtcdRestore:
metadata:
annotations:
alm-examples: >-
[{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdCluster","metadata":{"name":"example","namespace":"<operator_namespace>"},"spec":{"size":3,"version":"3.2.13"}},{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdRestore","metadata":{"name":"example-etcd-cluster"},"spec":{"etcdCluster":{"name":"example-etcd-cluster"},"backupStorageType":"S3","s3":{"path":"<full-s3-path>","awsSecret":"<aws-secret>"}}},{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdBackup","metadata":{"name":"example-etcd-cluster-backup"},"spec":{"etcdEndpoints":["<etcd-cluster-endpoints>"],"storageType":"S3","s3":{"path":"<full-s3-path>","awsSecret":"<aws-secret>"}}}]
metadata:
annotations:
alm-examples: >-
[{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdCluster","metadata":{"name":"example","namespace":"<operator_namespace>"},"spec":{"size":3,"version":"3.2.13"}},{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdRestore","metadata":{"name":"example-etcd-cluster"},"spec":{"etcdCluster":{"name":"example-etcd-cluster"},"backupStorageType":"S3","s3":{"path":"<full-s3-path>","awsSecret":"<aws-secret>"}}},{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdBackup","metadata":{"name":"example-etcd-cluster-backup"},"spec":{"etcdEndpoints":["<etcd-cluster-endpoints>"],"storageType":"S3","s3":{"path":"<full-s3-path>","awsSecret":"<aws-secret>"}}}]5.6.10.5. Cacher des objets internes
Il est courant pour les opérateurs d’utiliser des définitions de ressources personnalisées (CRD) en interne pour accomplir une tâche. Ces objets ne sont pas destinés aux utilisateurs à manipuler et peuvent être source de confusion pour les utilisateurs de l’opérateur. À titre d’exemple, un opérateur de base de données peut avoir un CRD de réplication qui est créé chaque fois qu’un utilisateur crée un objet de base de données avec réplication: true.
En tant qu’auteur de l’opérateur, vous pouvez cacher tous les CRD dans l’interface utilisateur qui ne sont pas destinés à la manipulation de l’utilisateur en ajoutant l’annotation d’objets internes à la version de service cluster (CSV) de votre opérateur.
Procédure
- Avant de marquer l’un de vos CRD en interne, assurez-vous que toute information de débogage ou configuration qui pourrait être nécessaire pour gérer l’application est reflétée sur le statut ou le bloc de spécifications de votre CR, le cas échéant à votre opérateur.
Ajoutez l’annotation d’un objet interne au CSV de votre opérateur pour spécifier les objets internes à cacher dans l’interface utilisateur:
Annotation interne d’objet
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Définissez n’importe quel CRD interne comme un tableau de chaînes.
5.6.10.6. Initialisation des ressources personnalisées requises
L’opérateur peut demander à l’utilisateur d’instancier une ressource personnalisée avant que l’opérateur puisse être pleinement fonctionnel. Cependant, il peut être difficile pour un utilisateur de déterminer ce qui est nécessaire ou comment définir la ressource.
En tant que développeur d’opérateur, vous pouvez spécifier une ressource personnalisée unique requise en ajoutant operatorframework.io/initialisation-ressource à la version de service cluster (CSV) pendant l’installation de l’opérateur. Il vous est alors demandé de créer la ressource personnalisée à l’aide d’un modèle fourni dans le CSV. L’annotation doit inclure un modèle qui contient une définition YAML complète qui est nécessaire pour initialiser la ressource pendant l’installation.
Lorsque cette annotation est définie, après avoir installé l’opérateur à partir du service Red Hat OpenShift sur la console web AWS, l’utilisateur est invité à créer la ressource à l’aide du modèle fourni dans le CSV.
Procédure
Ajoutez l’annotation operatorframework.io/initialisation-ressource au CSV de votre opérateur pour spécifier une ressource personnalisée requise. À titre d’exemple, l’annotation suivante nécessite la création d’une ressource StorageCluster et fournit une définition YAML complète:
Annotation des ressources d’initialisation
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.11. Comprendre vos services API
Comme pour les CRD, il existe deux types de services d’API que votre opérateur peut utiliser: possédés et requis.
5.6.11.1. Les services API possédés
Lorsqu’un CSV possède un service API, il est responsable de décrire le déploiement de l’extension api-server qui le soutient et du groupe/version/type (GVK) qu’il fournit.
Le service API est identifié de manière unique par le groupe/version qu’il fournit et peut être répertorié plusieurs fois pour désigner les différents types qu’il est censé fournir.
| Le champ | Description | Requis/facultatif |
|---|---|---|
|
| Groupe que le service API fournit, par exemple Database.example.com. | A) requis |
|
| La version du service API, par exemple v1alpha1. | A) requis |
|
| C’est une sorte que le service API devrait fournir. | A) requis |
|
| Le nom pluriel du service API fourni. | A) requis |
|
| Le nom du déploiement défini par votre CSV qui correspond à votre service API (requis pour les services API possédés). Au cours de la phase d’attente CSV, l’opérateur OLM effectue une recherche dans la stratégie d’installation de votre CSV pour trouver une spécification de déploiement avec un nom correspondant, et si elle n’est pas trouvée, ne transitionne pas le CSV vers la phase "Installer Prêt". | A) requis |
|
| Il s’agit d’une version lisible humaine du nom de votre service API, par exemple MongoDB Standalone. | A) requis |
|
| Brève description de la façon dont ce service API est utilisé par l’opérateur ou une description des fonctionnalités fournies par le service API. | A) requis |
|
| Les services API possèdent un ou plusieurs types d’objets Kubernetes. Ceux-ci sont listés dans la section ressources pour informer vos utilisateurs des objets dont ils pourraient avoir besoin pour résoudre les problèmes ou comment se connecter à l’application, comme la règle du service ou de l’entrée qui expose une base de données. Il est recommandé de ne énumérer que les objets qui sont importants pour un humain, pas une liste exhaustive de tout ce que vous orchestrez. À titre d’exemple, ne répertoriez pas les cartes de configuration qui stockent l’état interne qui ne sont pas destinés à être modifiés par un utilisateur. | Facultatif |
| Description des SpecDescripteurs, StatutDescripteurs et ActionDescripteurs | Essentiellement les mêmes que pour les CRD possédés. | Facultatif |
5.6.11.1.1. Création de ressources de service API
Le gestionnaire de cycle de vie de l’opérateur (OLM) est responsable de la création ou du remplacement des ressources de service et d’API pour chaque service d’API propriétaire unique:
- Les sélecteurs de pod de service sont copiés à partir du déploiement CSV correspondant au champ DeploymentName de la description du service API.
- La nouvelle paire clé/certificat CA est générée pour chaque installation et le paquet CA codé de base64 est intégré dans la ressource de service API respective.
5.6.11.1.2. Certificats de service API
Chaque fois qu’un service d’API est installé, OLM gère la génération d’une paire de clés/certificats de service. Le certificat de service a un nom commun (CN) contenant le nom d’hôte de la ressource Service généré et est signé par la clé privée du paquet CA intégré dans la ressource de service API correspondante.
Le certificat est stocké sous forme de secret de type kubernetes.io/tls dans l’espace de noms de déploiement, et un volume nommé apiservice-cert est automatiquement annexé à la section volumes du déploiement dans le CSV correspondant au champ DeploymentName de la description du service API.
Dans le cas contraire, une monture de volume avec un nom correspondant est également jointe à tous les conteneurs de ce déploiement. Cela permet aux utilisateurs de définir une monture de volume avec le nom attendu pour répondre à toutes les exigences de chemin personnalisé. Le chemin du montage de volume généré par défaut vers /apiserver.local.config/certificates et tous les montages de volume existants avec le même chemin sont remplacés.
5.6.11.2. Les services d’API requis
L’OLM s’assure que tous les CSV requis disposent d’un service API disponible et que tous les GVK attendus sont détectables avant de tenter l’installation. Cela permet à un CSV de s’appuyer sur des types spécifiques fournis par les services API qu’il ne possède pas.
| Le champ | Description | Requis/facultatif |
|---|---|---|
|
| Groupe que le service API fournit, par exemple Database.example.com. | A) requis |
|
| La version du service API, par exemple v1alpha1. | A) requis |
|
| C’est une sorte que le service API devrait fournir. | A) requis |
|
| Il s’agit d’une version lisible humaine du nom de votre service API, par exemple MongoDB Standalone. | A) requis |
|
| Brève description de la façon dont ce service API est utilisé par l’opérateur ou une description des fonctionnalités fournies par le service API. | A) requis |
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}