4.9. Gestion des catalogues personnalisés
Les administrateurs de clusters et les responsables du catalogue Operator peuvent créer et gérer des catalogues personnalisés emballés à l'aide du format bundle sur Operator Lifecycle Manager (OLM) dans OpenShift Container Platform.
Kubernetes déprécie périodiquement certaines API qui sont supprimées dans les versions ultérieures. Par conséquent, les opérateurs ne peuvent pas utiliser les API supprimées à partir de la version d'OpenShift Container Platform qui utilise la version de Kubernetes qui a supprimé l'API.
Si votre cluster utilise des catalogues personnalisés, consultez Contrôle de la compatibilité des opérateurs avec les versions d'OpenShift Container Platform pour plus de détails sur la façon dont les auteurs d'opérateurs peuvent mettre à jour leurs projets afin d'éviter les problèmes de charge de travail et d'empêcher les mises à niveau incompatibles.
4.9.1. Conditions préalables Copier lienLien copié sur presse-papiers!
-
Installez le CLI
opm
.
4.9.2. Catalogues basés sur des fichiers Copier lienLien copié sur presse-papiers!
File-based catalogs sont la dernière itération du format de catalogue dans Operator Lifecycle Manager (OLM). Il s'agit d'une évolution du format de base de données SQLite, basée sur du texte brut (JSON ou YAML) et une configuration déclarative, et il est entièrement rétrocompatible.
À partir d'OpenShift Container Platform 4.11, le catalogue Operator fourni par Red Hat par défaut est publié dans le format de catalogue basé sur des fichiers. Les catalogues Operator fournis par Red Hat par défaut pour OpenShift Container Platform 4.6 à 4.10 sont publiés dans le format de base de données SQLite déprécié.
Les sous-commandes, drapeaux et fonctionnalités de opm
liés au format de base de données SQLite sont également obsolètes et seront supprimés dans une prochaine version. Ces fonctionnalités sont toujours prises en charge et doivent être utilisées pour les catalogues qui utilisent le format de base de données SQLite obsolète.
La plupart des sous-commandes et des drapeaux de opm
pour travailler avec le format de base de données SQLite, tels que opm index prune
, ne fonctionnent pas avec le format de catalogue basé sur des fichiers. Pour plus d'informations sur l'utilisation des catalogues basés sur des fichiers, voir Format d'empaquetage d'Operator Framework et Mise en miroir des images pour une installation déconnectée à l'aide du plugin oc-mirror.
4.9.2.1. Création d'une image de catalogue basée sur des fichiers Copier lienLien copié sur presse-papiers!
Vous pouvez créer une image de catalogue qui utilise le format de texte brut file-based catalog (JSON ou YAML), qui remplace le format de base de données SQLite obsolète. L'interface CLI de opm
fournit des outils qui permettent d'initialiser un catalogue au format fichier, d'y rendre de nouveaux enregistrements et de valider la validité du catalogue.
Conditions préalables
-
opm
-
podman
version 1.9.3 - Une image de bundle construite et poussée vers un registre qui prend en charge Docker v2-2
Procédure
Initialiser un catalogue pour un catalogue basé sur des fichiers :
Créer un répertoire pour le catalogue :
mkdir <nom_de_l'opérateur>-index
$ mkdir <nom_de_l'opérateur>-index
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer un fichier Docker qui peut construire une image de catalogue :
Exemple
<operator_name>-index.Dockerfile
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le fichier Docker doit se trouver dans le même répertoire parent que le répertoire du catalogue que vous avez créé à l'étape précédente :
Exemple de structure de répertoire
. ├── <operator_name>-index └── <operator_name>-index.Dockerfile
. ├── <operator_name>-index └── <operator_name>-index.Dockerfile
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Remplissez le catalogue avec la définition de votre paquet :
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Nom de l'opérateur ou du paquet.
- 2
- Canal que l'abonnement utilisera par défaut s'il n'est pas spécifié.
- 3
- Chemin d'accès au site de l'opérateur
README.md
ou à d'autres documents. - 4
- Chemin d'accès à l'icône de l'opérateur.
- 5
- Format de sortie : JSON ou YAML.
- 6
- Chemin d'accès pour la création du fichier de configuration du catalogue.
Cette commande génère un blob de configuration déclarative
olm.package
dans le fichier de configuration du catalogue spécifié.
Ajouter une liasse au catalogue :
opm render <registry>/<namespace>/<bundle_image_name>:<tag> \ --output=yaml \ >> <operator_name>-index/index.yaml
$ opm render <registry>/<namespace>/<bundle_image_name>:<tag> \
1 --output=yaml \ >> <operator_name>-index/index.yaml
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow La commande
opm render
génère un blob de configuration déclaratif à partir des images de catalogue et de bundle fournies.NoteLes chaînes doivent contenir au moins une liasse.
Ajoutez une entrée de canal pour l'offre groupée. Par exemple, modifiez l'exemple suivant selon vos spécifications et ajoutez-le à votre fichier
<operator_name>-index/index.yaml
:Exemple d'entrée de canal
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Veillez à inclure le point (
.
) après<operator_name>
mais avantv
dans la version. Sinon, l'entrée ne passera pas la commandeopm validate
.
Valider le catalogue basé sur les fichiers :
Exécutez la commande
opm validate
dans le répertoire du catalogue :opm validate <nom_de_l'opérateur>-index
$ opm validate <nom_de_l'opérateur>-index
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Vérifiez que le code d'erreur est bien
0
:echo $?
$ echo $?
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
0
0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Construire l'image du catalogue :
podman build . \ -f <operator_name>-index.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>
$ podman build . \ -f <operator_name>-index.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pousser l'image du catalogue vers un registre :
Si nécessaire, authentifiez-vous auprès de votre registre cible :
podman login <registry>
$ podman login <registry>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pousser l'image du catalogue :
podman push <registry>/<namespace>/<catalog_image_name>:<tag>
$ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.3. Catalogues basés sur SQLite Copier lienLien copié sur presse-papiers!
Le format de base de données SQLite pour les catalogues d'opérateurs est une fonctionnalité obsolète. La fonctionnalité dépréciée est toujours incluse dans OpenShift Container Platform et continue d'être prise en charge ; cependant, elle sera supprimée dans une prochaine version de ce produit et n'est pas recommandée pour les nouveaux déploiements.
Pour obtenir la liste la plus récente des fonctionnalités majeures qui ont été dépréciées ou supprimées dans OpenShift Container Platform, consultez la section Deprecated and removed features des notes de version d'OpenShift Container Platform.
4.9.3.1. Création d'une image d'index basée sur SQLite Copier lienLien copié sur presse-papiers!
Vous pouvez créer une image d'index basée sur le format de base de données SQLite en utilisant le CLI opm
.
Conditions préalables
-
opm
-
podman
version 1.9.3 - Une image de bundle construite et poussée vers un registre qui prend en charge Docker v2-2
Procédure
Commencer un nouvel index :
opm index add \ --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \ --tag <registry>/<namespace>/<index_image_name>:<tag> \ [--binary-image <registry_base_image>]
$ opm index add \ --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \
1 --tag <registry>/<namespace>/<index_image_name>:<tag> \
2 [--binary-image <registry_base_image>]
3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pousser l'image de l'index vers un registre.
Si nécessaire, authentifiez-vous auprès de votre registre cible :
podman login <registry>
$ podman login <registry>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Appuyez sur l'image d'index :
podman push <registry>/<namespace>/<index_image_name>:<tag>
$ podman push <registry>/<namespace>/<index_image_name>:<tag>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.3.2. Mise à jour d'une image d'index basée sur SQLite Copier lienLien copié sur presse-papiers!
Après avoir configuré OperatorHub pour utiliser une source de catalogue qui fait référence à une image d'index personnalisée, les administrateurs de cluster peuvent maintenir les opérateurs disponibles sur leur cluster à jour en ajoutant des images de bundle à l'image d'index.
Vous pouvez mettre à jour une image d'index existante à l'aide de la commande opm index add
.
Conditions préalables
-
opm
-
podman
version 1.9.3 - Une image d'index est construite et poussée vers un registre.
- Une source de catalogue existante référençant l'image d'index.
Procédure
Mettre à jour l'index existant en ajoutant des images de liasses :
opm index add \ --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \ --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \ --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \ --pull-tool podman
$ opm index add \ --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \
1 --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \
2 --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \
3 --pull-tool podman
4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- L'option
--bundles
spécifie une liste séparée par des virgules d'images supplémentaires à ajouter à l'index. - 2
- Le drapeau
--from-index
spécifie l'index précédemment poussé. - 3
- L'option
--tag
spécifie la balise d'image à appliquer à l'image d'index mise à jour. - 4
- L'option
--pull-tool
spécifie l'outil utilisé pour extraire les images des conteneurs.
où :
<registry>
-
Spécifie le nom d'hôte du registre, par exemple
quay.io
oumirror.example.com
. <namespace>
-
Spécifie l'espace de noms du registre, par exemple
ocs-dev
ouabc
. <new_bundle_image>
-
Spécifie la nouvelle image de paquet à ajouter au registre, par exemple
ocs-operator
. <digest>
-
Spécifie l'ID de l'image SHA, ou condensé, de l'image de la liasse, par exemple
c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41
. <existing_index_image>
-
Spécifie l'image précédemment poussée, telle que
abc-redhat-operator-index
. <existing_tag>
-
Spécifie une balise d'image précédemment poussée, telle que
4.12
. <updated_tag>
-
Spécifie la balise d'image à appliquer à l'image d'index mise à jour, par exemple
4.12.1
.
Example command
opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4.12 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.12.1 \ --pull-tool podman
$ opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4.12 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.12.1 \ --pull-tool podman
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pousser l'image d'index mise à jour :
podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
$ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Une fois que Operator Lifecycle Manager (OLM) a interrogé automatiquement l'image d'index référencée dans la source du catalogue à intervalles réguliers, vérifiez que les nouveaux paquets ont été ajoutés avec succès :
oc get packagemanifests -n openshift-marketplace
$ oc get packagemanifests -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.3.3. Filtrage d'une image d'index basée sur SQLite Copier lienLien copié sur presse-papiers!
Une image d'index, basée sur le format Operator bundle, est un instantané conteneurisé d'un catalogue d'opérateurs. Vous pouvez filtrer, ou prune, un index de tous les paquets à l'exception d'une liste spécifiée, ce qui crée une copie de l'index source contenant uniquement les opérateurs que vous souhaitez.
Conditions préalables
-
podman
version 1.9.3 -
grpcurl
(outil de ligne de commande tiers) -
opm
- Accès à un registre qui prend en charge Docker v2-2
Procédure
S'authentifier avec le registre cible :
podman login <target_registry>
$ podman login <target_registry>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Déterminez la liste des paquets que vous souhaitez inclure dans votre index élagué.
Exécutez l'image de l'index source que vous souhaitez élaguer dans un conteneur. Par exemple :
podman run -p50051:50051 \ -it registry.redhat.io/redhat/redhat-operator-index:v4.12
$ podman run -p50051:50051 \ -it registry.redhat.io/redhat/redhat-operator-index:v4.12
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.12... Getting image source signatures Copying blob ae8a0c23f5b1 done ... INFO[0000] serving registry database=/database/index.db port=50051
Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.12... Getting image source signatures Copying blob ae8a0c23f5b1 done ... INFO[0000] serving registry database=/database/index.db port=50051
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Dans une autre session de terminal, utilisez la commande
grpcurl
pour obtenir une liste des paquets fournis par l'index :grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Inspectez le fichier
packages.out
et identifiez les noms de paquets de cette liste que vous souhaitez conserver dans votre index élagué. Par exemple :Exemples de listes de paquets
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Dans la session de terminal où vous avez exécuté la commande
podman run
, appuyez sur Ctrl et C pour arrêter le processus de conteneur.
Exécutez la commande suivante pour élaguer l'index source de tous les paquets, à l'exception des paquets spécifiés :
opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4.12 \ -p advanced-cluster-management,jaeger-product,quay-operator \ [-i registry.redhat.io/openshift4/ose-operator-registry:v4.9] \ -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.12
$ opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4.12 \
1 -p advanced-cluster-management,jaeger-product,quay-operator \
2 [-i registry.redhat.io/openshift4/ose-operator-registry:v4.9] \
3 -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.12
4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Index pour la taille.
- 2
- Liste de paquets à conserver, séparés par des virgules.
- 3
- Requis uniquement pour les images IBM Power et IBM zSystems : L'image de base Operator Registry avec le tag qui correspond à la version majeure et mineure du cluster OpenShift Container Platform cible.
- 4
- Balise personnalisée pour la nouvelle image d'index en cours de construction.
Exécutez la commande suivante pour transférer la nouvelle image d'index dans votre registre cible :
podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.12
$ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.12
Copy to Clipboard Copied! Toggle word wrap Toggle overflow où
<namespace>
est un espace de noms existant dans le registre.
4.9.4. Cataloguer les sources et podifier l'admission à la sécurité Copier lienLien copié sur presse-papiers!
Pod security admission a été introduit dans OpenShift Container Platform 4.11 pour garantir les normes de sécurité des pods. Les sources de catalogue construites à l'aide du format de catalogue basé sur SQLite et d'une version de l'outil CLI opm
publiée avant OpenShift Container Platform 4.11 ne peuvent pas fonctionner dans le cadre d'une application restreinte de la sécurité des pods.
Dans OpenShift Container Platform 4.12, les espaces de noms n'ont pas de mise en œuvre de la sécurité restreinte des pods par défaut et le mode de sécurité de la source du catalogue par défaut est défini sur legacy
.
L'application restreinte par défaut pour tous les espaces de noms est prévue pour être incluse dans une prochaine version d'OpenShift Container Platform. Lorsque l'application restreinte se produit, le contexte de sécurité de la spécification de pod pour les pods de source de catalogue doit correspondre à la norme de sécurité de pod restreinte. Si votre image source de catalogue nécessite une norme de sécurité pod différente, l'étiquette des admissions de sécurité pod pour l'espace de noms doit être explicitement définie.
Si vous ne souhaitez pas exécuter vos pods de source de catalogue basés sur SQLite en tant que restreint, vous n'avez pas besoin de mettre à jour votre source de catalogue dans OpenShift Container Platform 4.12.
Cependant, il est recommandé de prendre des mesures dès maintenant pour s'assurer que vos sources de catalogue s'exécutent dans le cadre de l'application de la sécurité des pods restreints. Si vous ne le faites pas, vos sources de catalogue risquent de ne pas fonctionner dans les prochaines versions d'OpenShift Container Platform.
En tant qu'auteur de catalogue, vous pouvez activer la compatibilité avec l'application de la sécurité des pods restreints en effectuant l'une des actions suivantes :
- Migrez votre catalogue vers le format de catalogue basé sur les fichiers.
-
Mettez à jour votre image de catalogue avec une version de l'outil
opm
CLI publiée avec OpenShift Container Platform 4.11 ou une version ultérieure.
Le format de catalogue de base de données SQLite est obsolète, mais toujours pris en charge par Red Hat. Dans une prochaine version, le format de base de données SQLite ne sera pas pris en charge et les catalogues devront migrer vers le format de catalogue basé sur des fichiers. À partir d'OpenShift Container Platform 4.11, le catalogue Operator fourni par Red Hat par défaut est publié dans le format de catalogue basé sur des fichiers. Les catalogues basés sur des fichiers sont compatibles avec l'application de la sécurité des pods restreints.
Si vous ne souhaitez pas mettre à jour l'image du catalogue de votre base de données SQLite ou migrer votre catalogue vers le format de catalogue basé sur des fichiers, vous pouvez configurer votre catalogue pour qu'il s'exécute avec des autorisations élevées.
4.9.4.1. Migration des catalogues de bases de données SQLite vers le format de catalogue basé sur des fichiers Copier lienLien copié sur presse-papiers!
Vous pouvez mettre à jour vos catalogues au format de base de données SQLite, qui est obsolète, au format de catalogue basé sur des fichiers.
Conditions préalables
- Source du catalogue de la base de données SQLite
- Autorisations de l'administrateur du cluster
-
La dernière version de l'outil
opm
CLI est disponible avec OpenShift Container Platform 4.12 sur station de travail
Procédure
Migrez le catalogue de votre base de données SQLite vers un catalogue basé sur des fichiers en exécutant la commande suivante :
opm migrate <registry_image> <fbc_directory>
$ opm migrate <registry_image> <fbc_directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Générez un fichier Docker pour votre catalogue basé sur les fichiers en exécutant la commande suivante :
opm generate dockerfile <fbc_directory> \ --binary-image \ registry.redhat.io/openshift4/ose-operator-registry:v4.12
$ opm generate dockerfile <fbc_directory> \ --binary-image \ registry.redhat.io/openshift4/ose-operator-registry:v4.12
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Prochaines étapes
- Le fichier Docker généré peut être construit, étiqueté et poussé vers votre registre.
4.9.4.2. Reconstruction des images de catalogues de bases de données SQLite Copier lienLien copié sur presse-papiers!
Vous pouvez reconstruire votre image de catalogue de base de données SQLite avec la dernière version de l'outil opm
CLI qui est disponible avec votre version d'OpenShift Container Platform.
Conditions préalables
- Source du catalogue de la base de données SQLite
- Autorisations de l'administrateur du cluster
-
La dernière version de l'outil
opm
CLI est disponible avec OpenShift Container Platform 4.12 sur station de travail
Procédure
Exécutez la commande suivante pour reconstruire votre catalogue avec une version plus récente de l'outil CLI
opm
:opm index add --binary-image \ registry.redhat.io/openshift4/ose-operator-registry:v4.12 \ --from-index <your_registry_image> \ --bundles "" -t \<your_registry_image>
$ opm index add --binary-image \ registry.redhat.io/openshift4/ose-operator-registry:v4.12 \ --from-index <your_registry_image> \ --bundles "" -t \<your_registry_image>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.4.3. Configurer les catalogues pour qu'ils s'exécutent avec des autorisations élevées Copier lienLien copié sur presse-papiers!
Si vous ne souhaitez pas mettre à jour votre image de catalogue de base de données SQLite ou migrer votre catalogue vers le format de catalogue basé sur des fichiers, vous pouvez effectuer les actions suivantes pour vous assurer que votre source de catalogue s'exécute lorsque l'application de la sécurité du pod par défaut passe à restreinte :
- Définissez manuellement le mode de sécurité du catalogue sur legacy dans la définition de la source du catalogue. Cette action garantit que votre catalogue s'exécute avec des autorisations héritées, même si le mode de sécurité du catalogue par défaut devient restreint.
- Étiqueter l'espace de noms de la source du catalogue pour l'application de la sécurité de la ligne de base ou du pod privilégié.
Le format de catalogue de base de données SQLite est obsolète, mais toujours pris en charge par Red Hat. Dans une prochaine version, le format de base de données SQLite ne sera plus pris en charge et les catalogues devront migrer vers le format de catalogue basé sur des fichiers. Les catalogues basés sur des fichiers sont compatibles avec l'application de la sécurité des pods restreints.
Conditions préalables
- Source du catalogue de la base de données SQLite
- Autorisations de l'administrateur du cluster
-
Espace de noms cible qui prend en charge l'exécution de pods avec la norme élevée d'admission à la sécurité des pods de
baseline
ou deprivileged
Procédure
Modifiez la définition de
CatalogSource
en remplaçant l'étiquettespec.grpcPodConfig.securityContextConfig
parlegacy
, comme le montre l'exemple suivant :Exemple
CatalogSource
définitionCopy to Clipboard Copied! Toggle word wrap Toggle overflow AstuceDans OpenShift Container Platform 4.12, le champ
spec.grpcPodConfig.securityContextConfig
est défini par défaut surlegacy
. Dans une prochaine version d'OpenShift Container Platform, il est prévu que le paramètre par défaut deviennerestricted
. Si votre catalogue ne peut pas s'exécuter sous une application restreinte, il est recommandé de définir manuellement ce champ àlegacy
.Modifiez votre fichier
<namespace>.yaml
pour ajouter les normes d'admission à la sécurité des pods élevés à l'espace de noms de la source de votre catalogue, comme le montre l'exemple suivant :Exemple de fichier
<namespace>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Désactivez la synchronisation des étiquettes de sécurité des pods en ajoutant l'étiquette
security.openshift.io/scc.podSecurityLabelSync=false
à l'espace de noms. - 2
- Appliquez l'étiquette d'admission à la sécurité du pod
pod-security.kubernetes.io/enforce
. Définissez l'étiquette surbaseline
ouprivileged
. Utilisez le profil de sécurité du podbaseline
à moins que d'autres charges de travail dans l'espace de noms ne nécessitent un profilprivileged
.
4.9.5. Ajout d'une source de catalogue à un cluster Copier lienLien copié sur presse-papiers!
L'ajout d'une source de catalogue à un cluster OpenShift Container Platform permet la découverte et l'installation d'opérateurs pour les utilisateurs. Les administrateurs de cluster peuvent créer un objet CatalogSource
qui référence une image d'index. OperatorHub utilise des sources de catalogue pour remplir l'interface utilisateur.
Conditions préalables
- Une image d'index est construite et poussée vers un registre.
Procédure
Créez un objet
CatalogSource
qui fait référence à votre image d'index.Modifiez le texte suivant selon vos spécifications et sauvegardez-le sous forme de fichier
catalogSource.yaml
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Si vous souhaitez que la source du catalogue soit disponible globalement pour les utilisateurs de tous les espaces de noms, spécifiez l'espace de noms
openshift-marketplace
. Sinon, vous pouvez spécifier un espace de noms différent pour que le catalogue soit délimité et disponible uniquement pour cet espace de noms. - 2
- Facultatif : Définissez l'annotation
olm.catalogImageTemplate
avec le nom de votre image d'index et utilisez une ou plusieurs variables de version du cluster Kubernetes comme indiqué lors de la construction du modèle pour la balise d'image. - 3
- Spécifiez la valeur de
legacy
ourestricted
. Si le champ n'est pas défini, la valeur par défaut estlegacy
. Dans une prochaine version d'OpenShift Container Platform, il est prévu que la valeur par défaut soitrestricted
. Si votre catalogue ne peut pas s'exécuter avec les autorisationsrestricted
, il est recommandé de définir manuellement ce champ surlegacy
. - 4
- Spécifiez votre image d'index. Si vous spécifiez une balise après le nom de l'image, par exemple
:v4.12
, le pod source du catalogue utilise une politique d'extraction d'image deAlways
, ce qui signifie que le pod extrait toujours l'image avant de démarrer le conteneur. Si vous spécifiez un condensé, par exemple@sha256:<id>
, la politique d'extraction d'image estIfNotPresent
, ce qui signifie que le module n'extrait l'image que si elle n'existe pas déjà sur le nœud. - 5
- Indiquez votre nom ou le nom d'une organisation qui publie le catalogue.
- 6
- Les sources du catalogue peuvent automatiquement vérifier la présence de nouvelles versions pour rester à jour.
Utilisez le fichier pour créer l'objet
CatalogSource
:oc apply -f catalogSource.yaml
$ oc apply -f catalogSource.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Vérifiez que les ressources suivantes ont bien été créées.
Vérifier les gousses :
oc get pods -n openshift-marketplace
$ oc get pods -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME READY STATUS RESTARTS AGE my-operator-catalog-6njx6 1/1 Running 0 28s marketplace-operator-d9f549946-96sgr 1/1 Running 0 26h
NAME READY STATUS RESTARTS AGE my-operator-catalog-6njx6 1/1 Running 0 28s marketplace-operator-d9f549946-96sgr 1/1 Running 0 26h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Vérifier la source du catalogue :
oc get catalogsource -n openshift-marketplace
$ oc get catalogsource -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5s
NAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Vérifier le manifeste du paquet :
oc get packagemanifest -n openshift-marketplace
$ oc get packagemanifest -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME CATALOG AGE jaeger-product My Operator Catalog 93s
NAME CATALOG AGE jaeger-product My Operator Catalog 93s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Vous pouvez maintenant installer les opérateurs à partir de la page OperatorHub de votre console web OpenShift Container Platform.
4.9.6. Accès aux images des opérateurs à partir de registres privés Copier lienLien copié sur presse-papiers!
Si certaines images pertinentes pour les opérateurs gérés par Operator Lifecycle Manager (OLM) sont hébergées dans un registre d'images de conteneurs authentifié, également connu sous le nom de registre privé, OLM et OperatorHub ne peuvent pas extraire les images par défaut. Pour permettre l'accès, vous pouvez créer un secret d'extraction qui contient les informations d'authentification pour le registre. En référençant un ou plusieurs secrets d'extraction dans une source de catalogue, OLM peut se charger de placer les secrets dans l'espace de noms de l'opérateur et du catalogue pour permettre l'installation.
D'autres images requises par un opérateur ou ses opérandes peuvent également nécessiter l'accès à des registres privés. OLM ne gère pas le placement des secrets dans les espaces de noms des locataires cibles pour ce scénario, mais des références d'authentification peuvent être ajoutées au secret d'extraction du cluster global ou aux comptes de service de l'espace de noms individuel pour permettre l'accès requis.
Les types d'images suivants doivent être pris en compte pour déterminer si les opérateurs gérés par OLM disposent d'un accès au tirage approprié :
- Images de l'index
-
Un objet
CatalogSource
peut faire référence à une image d'index, qui utilise le format Operator bundle et est une source de catalogue conditionnée sous forme d'images conteneurisées hébergées dans des registres d'images. Si une image d'index est hébergée dans un registre privé, un secret peut être utilisé pour permettre l'accès en pull. - Images de l'ensemble
- Les images d'ensemble d'opérateurs sont des métadonnées et des manifestes présentés sous forme d'images conteneurisées qui représentent une version unique d'un opérateur. Si des images d'ensemble référencées dans une source de catalogue sont hébergées dans un ou plusieurs registres privés, un secret peut être utilisé pour permettre l'accès en mode "pull".
- Images des opérateurs et des opérandes
Si un opérateur installé à partir d'une source de catalogue utilise une image privée, que ce soit pour l'image de l'opérateur elle-même ou pour l'une des images d'opérandes qu'elle surveille, l'installation de l'opérateur échouera car le déploiement n'aura pas accès à l'authentification de registre requise. Le fait de référencer des secrets dans une source de catalogue ne permet pas à OLM de placer les secrets dans les espaces de noms des locataires cibles dans lesquels les opérateurs sont installés.
Au lieu de cela, les détails d'authentification peuvent être ajoutés au secret d'extraction du cluster global dans l'espace de noms
openshift-config
, qui donne accès à tous les espaces de noms du cluster. Si l'accès à l'ensemble du cluster n'est pas autorisé, le secret d'extraction peut être ajouté aux comptes de servicedefault
des espaces de noms des locataires cibles.
Conditions préalables
Au moins un des éléments suivants hébergé dans un registre privé :
- Une image d'index ou de catalogue.
- Une image du faisceau d'opérateurs.
- Une image d'opérateur ou d'opérande.
Procédure
Créez un secret pour chaque registre privé requis.
Connectez-vous au registre privé pour créer ou mettre à jour votre fichier d'informations d'identification :
podman login <registry>:<port>
$ podman login <registry>:<port>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteLe chemin d'accès au fichier des informations d'identification du registre peut varier en fonction de l'outil conteneur utilisé pour se connecter au registre. Pour l'interface de programmation
podman
, l'emplacement par défaut est${XDG_RUNTIME_DIR}/containers/auth.json
. Pour le CLIdocker
, l'emplacement par défaut est/root/.docker/config.json
.Il est recommandé d'inclure des informations d'identification pour un seul registre par secret et de gérer les informations d'identification pour plusieurs registres dans des secrets distincts. Plusieurs secrets peuvent être inclus dans un objet
CatalogSource
lors d'étapes ultérieures, et OpenShift Container Platform fusionnera les secrets en un seul fichier d'informations d'identification virtuel à utiliser lors d'une extraction d'image.Un fichier d'informations d'identification de registre peut, par défaut, contenir des informations relatives à plusieurs registres ou à plusieurs référentiels d'un même registre. Vérifiez le contenu actuel de votre fichier. Par exemple :
Fichier stockant les informations d'identification pour plusieurs registres
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ce fichier étant utilisé pour créer des secrets dans les étapes suivantes, assurez-vous que vous ne stockez les détails que pour un seul registre par fichier. Pour ce faire, vous pouvez utiliser l'une des méthodes suivantes :
-
Utilisez la commande
podman logout <registry>
pour supprimer les informations d'identification des registres supplémentaires jusqu'à ce qu'il ne reste plus que le registre souhaité. Modifiez votre fichier d'informations d'identification du registre et séparez les détails du registre à stocker dans plusieurs fichiers. Par exemple :
Fichier stockant les informations d'identification pour un registre
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Fichier stockant les informations d'identification pour un autre registre
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Utilisez la commande
Créez un secret dans l'espace de noms
openshift-marketplace
qui contient les informations d'authentification pour un registre privé :oc create secret generic <secret_name> \ -n openshift-marketplace \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
$ oc create secret generic <secret_name> \ -n openshift-marketplace \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Répétez cette étape pour créer des secrets supplémentaires pour tout autre registre privé requis, en mettant à jour l'indicateur
--from-file
pour spécifier un autre chemin d'accès au fichier d'informations d'identification du registre.
Créer ou mettre à jour un objet
CatalogSource
existant pour référencer un ou plusieurs secrets :Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ajoutez une section
spec.secrets
et spécifiez les secrets requis. - 2
- Spécifiez la valeur de
legacy
ourestricted
. Si le champ n'est pas défini, la valeur par défaut estlegacy
. Dans une prochaine version d'OpenShift Container Platform, il est prévu que la valeur par défaut soitrestricted
. Si votre catalogue ne peut pas s'exécuter avec les autorisationsrestricted
, il est recommandé de définir manuellement ce champ surlegacy
.
Si des images d'opérateurs ou d'opérandes référencées par un opérateur abonné nécessitent l'accès à un registre privé, vous pouvez soit fournir un accès à tous les espaces de noms du cluster, soit à des espaces de noms de locataires cibles individuels.
Pour permettre l'accès à tous les espaces de noms du cluster, ajoutez des détails d'authentification au secret d'extraction du cluster global dans l'espace de noms
openshift-config
.AvertissementLes ressources du cluster doivent s'adapter au nouveau secret de tirage global, ce qui peut limiter temporairement la capacité d'utilisation du cluster.
Extraire le fichier
.dockerconfigjson
du secret d'extraction global :oc extract secret/pull-secret -n openshift-config --confirm
$ oc extract secret/pull-secret -n openshift-config --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Mettez à jour le fichier
.dockerconfigjson
avec vos informations d'authentification pour le ou les registres privés requis et enregistrez-le dans un nouveau fichier :cat .dockerconfigjson | \ jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \ jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \ > new_dockerconfigjson > new_dockerconfigjson
$ cat .dockerconfigjson | \ jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \
1 > new_dockerconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Remplacez
<registry>:<port>/<namespace>
par les détails du registre privé et<token>
par vos identifiants d'authentification.
Mettre à jour le secret d'extraction global avec le nouveau fichier :
oc set data secret/pull-secret -n openshift-config \ --from-file=.dockerconfigjson=new_dockerconfigjson
$ oc set data secret/pull-secret -n openshift-config \ --from-file=.dockerconfigjson=new_dockerconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Pour mettre à jour un espace de noms individuel, ajoutez un secret d'extraction au compte de service de l'opérateur qui a besoin d'un accès dans l'espace de noms du locataire cible.
Recréez le secret que vous avez créé pour
openshift-marketplace
dans l'espace de noms du locataire :oc create secret generic <secret_name> \ -n <tenant_namespace> \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
$ oc create secret generic <secret_name> \ -n <tenant_namespace> \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Vérifiez le nom du compte de service de l'opérateur en effectuant une recherche dans l'espace de noms du locataire :
oc get sa -n <tenant_namespace>
oc get sa -n <tenant_namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Si l'opérateur a été installé dans un espace de noms particulier, recherchez dans cet espace de noms. Si l'opérateur a été installé dans tous les espaces de noms, recherchez l'espace de noms
openshift-operators
.
Exemple de sortie
NAME SECRETS AGE builder 2 6m1s default 2 6m1s deployer 2 6m1s etcd-operator 2 5m18s
NAME SECRETS AGE builder 2 6m1s default 2 6m1s deployer 2 6m1s etcd-operator 2 5m18s
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Compte de service pour un opérateur etcd installé.
Lier le secret au compte de service de l'opérateur :
oc secrets link <operator_sa> \ -n <tenant_namespace> \ <secret_name> \ --for=pull
$ oc secrets link <operator_sa> \ -n <tenant_namespace> \ <secret_name> \ --for=pull
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.7. Disabling the default OperatorHub catalog sources Copier lienLien copié sur presse-papiers!
Les catalogues d'opérateurs que le contenu source fourni par Red Hat et les projets communautaires sont configurés pour OperatorHub par défaut lors d'une installation d'OpenShift Container Platform. En tant qu'administrateur de cluster, vous pouvez désactiver l'ensemble des catalogues par défaut.
Procédure
Disable the sources for the default catalogs by adding
disableAllDefaultSources: true
to theOperatorHub
object:oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Alternatively, you can use the web console to manage catalog sources. From the Administration
4.9.8. Suppression des catalogues personnalisés Copier lienLien copié sur presse-papiers!
En tant qu'administrateur de cluster, vous pouvez supprimer les catalogues d'opérateurs personnalisés qui ont été précédemment ajoutés à votre cluster en supprimant la source de catalogue correspondante.
Procédure
-
Dans la perspective Administrator de la console web, naviguez vers Administration
Cluster Settings. - Cliquez sur l'onglet Configuration, puis sur OperatorHub.
- Cliquez sur l'onglet Sources.
-
Sélectionnez le menu Options
du catalogue que vous souhaitez supprimer, puis cliquez sur Delete CatalogSource.