Chapitre 4. Tâches de l'administrateur
4.1. Ajouter des opérateurs à une grappe
Grâce à Operator Lifecycle Manager (OLM), les administrateurs de clusters peuvent installer des opérateurs basés sur OLM dans un cluster OpenShift Container Platform.
4.1.1. A propos de l'installation de l'opérateur avec OperatorHub
OperatorHub est une interface utilisateur permettant de découvrir les opérateurs ; il fonctionne en conjonction avec Operator Lifecycle Manager (OLM), qui installe et gère les opérateurs sur un cluster.
En tant qu'utilisateur disposant des permissions appropriées, vous pouvez installer un opérateur à partir d'OperatorHub en utilisant la console web ou le CLI d'OpenShift Container Platform.
Lors de l'installation, vous devez déterminer les paramètres initiaux suivants pour l'opérateur :
- Mode d'installation
- Choisissez un espace de noms spécifique dans lequel installer l'opérateur.
- Canal de mise à jour
- Si un opérateur est disponible sur plusieurs canaux, vous pouvez choisir le canal auquel vous souhaitez vous abonner. Par exemple, pour déployer à partir du canal stable, s'il est disponible, sélectionnez-le dans la liste.
- Stratégie d'approbation
Vous pouvez choisir des mises à jour automatiques ou manuelles.
Si vous choisissez les mises à jour automatiques pour un opérateur installé, lorsqu'une nouvelle version de cet opérateur est disponible dans le canal sélectionné, Operator Lifecycle Manager (OLM) met automatiquement à jour l'instance en cours d'exécution de votre opérateur sans intervention humaine.
Si vous sélectionnez les mises à jour manuelles, lorsqu'une version plus récente d'un opérateur est disponible, OLM crée une demande de mise à jour. En tant qu'administrateur de cluster, vous devez ensuite approuver manuellement cette demande de mise à jour pour que l'opérateur soit mis à jour avec la nouvelle version.
4.1.2. Installation à partir d'OperatorHub en utilisant la console web
Vous pouvez installer et vous abonner à un opérateur à partir d'OperatorHub en utilisant la console web d'OpenShift Container Platform.
Conditions préalables
-
Accès à un cluster OpenShift Container Platform à l'aide d'un compte disposant des autorisations
cluster-admin
. - Accès à un cluster OpenShift Container Platform à l'aide d'un compte disposant des permissions d'installation de l'opérateur.
Procédure
-
Naviguez dans la console web jusqu'à la page Operators
OperatorHub. Faites défiler ou tapez un mot-clé dans la case Filter by keyword pour trouver l'opérateur souhaité. Par exemple, tapez
advanced
pour trouver l'opérateur Advanced Cluster Management for Kubernetes.Vous pouvez également filtrer les options par Infrastructure Features. Par exemple, sélectionnez Disconnected si vous voulez voir les opérateurs qui travaillent dans des environnements déconnectés, également connus sous le nom d'environnements réseau restreints.
Sélectionnez l'opérateur pour afficher des informations supplémentaires.
NoteLe choix d'un Opérateur communautaire vous avertit que Red Hat ne certifie pas les Opérateurs communautaires ; vous devez accuser réception de cet avertissement avant de continuer.
- Lisez les informations sur l'opérateur et cliquez sur Install.
Sur la page Install Operator:
Sélectionnez l'un des éléments suivants :
-
All namespaces on the cluster (default) installe l'opérateur dans l'espace de noms par défaut
openshift-operators
pour qu'il soit surveillé et mis à la disposition de tous les espaces de noms du cluster. Cette option n'est pas toujours disponible. - A specific namespace on the cluster vous permet de choisir un seul espace de noms spécifique dans lequel installer l'opérateur. L'opérateur ne surveillera et ne pourra être utilisé que dans ce seul espace de noms.
-
All namespaces on the cluster (default) installe l'opérateur dans l'espace de noms par défaut
- Choisissez un espace de noms unique et spécifique dans lequel installer l'Opérateur. L'opérateur ne surveillera et ne pourra être utilisé que dans ce seul espace de noms.
- Sélectionnez une adresse Update Channel (si plusieurs sont disponibles).
- Sélectionnez la stratégie d'approbation Automatic ou Manual, comme décrit précédemment.
Cliquez sur Install pour rendre l'opérateur disponible pour les espaces de noms sélectionnés sur ce cluster OpenShift Container Platform.
Si vous avez sélectionné une stratégie d'approbation Manual, le statut de mise à niveau de l'abonnement reste Upgrading jusqu'à ce que vous examiniez et approuviez le plan d'installation.
Après approbation sur la page Install Plan, le statut de la mise à niveau de l'abonnement passe à Up to date.
- Si vous avez sélectionné une stratégie d'approbation Automatic, le statut du surclassement devrait être résolu à Up to date sans intervention.
Une fois que l'état de mise à niveau de l'abonnement est Up to date, sélectionnez Operators
Installed Operators pour vérifier que la version du service de cluster (CSV) de l'opérateur installé s'affiche finalement. L'adresse Status devrait finalement se résoudre en InstallSucceeded dans l'espace de noms concerné. NotePour le mode d'installation All namespaces…, le statut se résout en InstallSucceeded dans l'espace de noms
openshift-operators
, mais le statut est Copied si vous vérifiez dans d'autres espaces de noms.Si ce n'est pas le cas :
-
Vérifiez les journaux de tous les pods du projet
openshift-operators
(ou d'un autre espace de noms pertinent si le mode d'installation A specific namespace… a été sélectionné) sur la page WorkloadsPods qui signalent des problèmes afin de les résoudre.
-
Vérifiez les journaux de tous les pods du projet
4.1.3. Installation à partir d'OperatorHub en utilisant le CLI
Au lieu d'utiliser la console web de OpenShift Container Platform, vous pouvez installer un Operator depuis OperatorHub en utilisant le CLI. Utilisez la commande oc
pour créer ou mettre à jour un objet Subscription
.
Conditions préalables
- Accès à un cluster OpenShift Container Platform à l'aide d'un compte disposant des permissions d'installation de l'opérateur.
-
Installez la commande
oc
sur votre système local.
Procédure
Voir la liste des opérateurs disponibles pour la grappe à partir d'OperatorHub :
$ oc get packagemanifests -n openshift-marketplace
Exemple de sortie
NAME CATALOG AGE 3scale-operator Red Hat Operators 91m advanced-cluster-management Red Hat Operators 91m amq7-cert-manager Red Hat Operators 91m ... couchbase-enterprise-certified Certified Operators 91m crunchy-postgres-operator Certified Operators 91m mongodb-enterprise Certified Operators 91m ... etcd Community Operators 91m jaeger Community Operators 91m kubefed Community Operators 91m ...
Notez le catalogue de l'opérateur souhaité.
Inspectez l'opérateur de votre choix pour vérifier les modes d'installation pris en charge et les canaux disponibles :
oc describe packagemanifests <operator_name> -n openshift-marketplace
Un groupe d'opérateurs, défini par un objet
OperatorGroup
, sélectionne des espaces de noms cibles dans lesquels générer l'accès RBAC requis pour tous les opérateurs dans le même espace de noms que le groupe d'opérateurs.L'espace de noms auquel vous abonnez l'opérateur doit avoir un groupe d'opérateurs qui correspond au mode d'installation de l'opérateur, soit le mode
AllNamespaces
ouSingleNamespace
. Si l'opérateur que vous avez l'intention d'installer utilise le modeAllNamespaces
, l'espace de nomsopenshift-operators
dispose déjà d'un groupe d'opérateurs approprié.Cependant, si l'opérateur utilise le mode
SingleNamespace
et que vous n'avez pas déjà un groupe d'opérateurs approprié en place, vous devez en créer un.NoteLa version console web de cette procédure gère la création des objets
OperatorGroup
etSubscription
automatiquement dans les coulisses lorsque vous choisissez le modeSingleNamespace
.Créez un fichier YAML de l'objet
OperatorGroup
, par exempleoperatorgroup.yaml
:Exemple d'objet
OperatorGroup
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: <operatorgroup_name> namespace: <namespace> spec: targetNamespaces: - <namespace>
Créer l'objet
OperatorGroup
:$ oc apply -f operatorgroup.yaml
Créez un fichier YAML de l'objet
Subscription
pour abonner un espace de noms à un opérateur, par exemplesub.yaml
:Exemple d'objet
Subscription
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: <subscription_name> namespace: openshift-operators 1 spec: channel: <channel_name> 2 name: <operator_name> 3 source: redhat-operators 4 sourceNamespace: openshift-marketplace 5 config: env: 6 - name: ARGS value: "-v=10" envFrom: 7 - secretRef: name: license-secret volumes: 8 - name: <volume_name> configMap: name: <configmap_name> volumeMounts: 9 - mountPath: <directory_name> name: <volume_name> tolerations: 10 - operator: "Exists" resources: 11 requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" nodeSelector: 12 foo: bar
- 1
- Pour l'utilisation du mode d'installation
AllNamespaces
, indiquez l'espace de nomsopenshift-operators
. Sinon, indiquez l'espace de noms unique correspondant à l'utilisation du mode d'installationSingleNamespace
. - 2
- Nom du canal auquel s'abonner.
- 3
- Nom de l'opérateur auquel s'abonner.
- 4
- Nom de la source du catalogue qui fournit l'opérateur.
- 5
- Espace de noms de la source de catalogue. Utilisez
openshift-marketplace
pour les sources de catalogue par défaut d'OperatorHub. - 6
- Le paramètre
env
définit une liste de variables d'environnement qui doivent exister dans tous les conteneurs du module créé par OLM. - 7
- Le paramètre
envFrom
définit une liste de sources pour alimenter les variables d'environnement dans le conteneur. - 8
- Le paramètre
volumes
définit une liste de volumes qui doivent exister sur le pod créé par OLM. - 9
- Le paramètre
volumeMounts
définit une liste de VolumeMounts qui doivent exister dans tous les conteneurs du pod créé par OLM. Si unvolumeMount
fait référence à unvolume
qui n'existe pas, OLM ne parvient pas à déployer l'opérateur. - 10
- Le paramètre
tolerations
définit une liste de tolérances pour le module créé par OLM. - 11
- Le paramètre
resources
définit les contraintes de ressources pour tous les conteneurs du module créé par OLM. - 12
- Le paramètre
nodeSelector
définit unNodeSelector
pour le module créé par OLM.
Créer l'objet
Subscription
:$ oc apply -f sub.yaml
A ce stade, OLM connaît l'opérateur sélectionné. Une version de service de cluster (CSV) pour l'opérateur devrait apparaître dans l'espace de noms cible, et les API fournies par l'opérateur devraient être disponibles pour la création.
Ressources supplémentaires
4.1.4. Installer une version spécifique d'un opérateur
Vous pouvez installer une version spécifique d'un opérateur en définissant la version du service de cluster (CSV) dans un objet Subscription
.
Conditions préalables
- Accès à un cluster OpenShift Container Platform à l'aide d'un compte disposant des autorisations d'installation de l'opérateur
-
OpenShift CLI (
oc
) installé
Procédure
Créez un fichier YAML de l'objet
Subscription
qui abonne un espace de noms à un opérateur avec une version spécifique en définissant le champstartingCSV
. Définissez le champinstallPlanApproval
surManual
pour empêcher l'opérateur d'effectuer une mise à niveau automatique si une version plus récente existe dans le catalogue.Par exemple, le fichier
sub.yaml
suivant peut être utilisé pour installer Red Hat Quay Operator spécifiquement à la version 3.4.0 :Abonnement avec une version de départ spécifique de l'opérateur
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: quay-operator namespace: quay spec: channel: quay-v3.4 installPlanApproval: Manual 1 name: quay-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: quay-operator.v3.4.0 2
- 1
- Définissez la stratégie d'approbation sur
Manual
au cas où la version spécifiée serait remplacée par une version ultérieure dans le catalogue. Ce plan empêche une mise à niveau automatique vers une version ultérieure et nécessite une approbation manuelle avant que le CSV de départ ne puisse terminer l'installation. - 2
- Définir une version spécifique d'un CSV opérateur.
Créer l'objet
Subscription
:$ oc apply -f sub.yaml
- Approuver manuellement le plan d'installation en attente pour terminer l'installation de l'opérateur.
Ressources supplémentaires
4.1.5. Préparer plusieurs instances d'un opérateur pour les clusters multitenants
En tant qu'administrateur de cluster, vous pouvez ajouter plusieurs instances d'un opérateur pour une utilisation dans des clusters multitenant. Il s'agit d'une solution alternative à l'utilisation du mode d'installation standard All namespaces, qui peut être considéré comme une violation du principe du moindre privilège, ou du mode Multinamespace, qui n'est pas largement adopté. Pour plus d'informations, voir "Operators in multitenant clusters".
Dans la procédure suivante, tenant 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. Le tenant Operator est l'instance d'un opérateur qui est destiné à être utilisé uniquement par ce locataire.
Conditions préalables
Toutes les instances de l'opérateur que vous souhaitez installer doivent être de la même version dans un cluster donné.
ImportantPour plus d'informations sur ce point et d'autres limitations, voir "Operators in multitenant clusters".
Procédure
Avant d'installer l'Opérateur, créez un espace de noms pour l'Opérateur du locataire qui soit distinct de l'espace de noms du locataire. Par exemple, si l'espace de noms du locataire est
team1
, vous pouvez créer un espace de nomsteam1-operator
:Définissez une ressource
Namespace
et enregistrez le fichier YAML, par exempleteam1-operator.yaml
:apiVersion: v1 kind: Namespace metadata: name: team1-operator
Créez l'espace de noms en exécutant la commande suivante :
$ oc create -f team1-operator.yaml
Créer un groupe d'opérateurs pour l'opérateur du locataire, limité à l'espace de noms du locataire, avec une seule entrée d'espace de noms dans la liste
spec.targetNamespaces
:Définissez une ressource
OperatorGroup
et enregistrez le fichier YAML, par exempleteam1-operatorgroup.yaml
:apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: team1-operatorgroup namespace: team1-operator spec: targetNamespaces: - team1 1
- 1
- Définissez uniquement l'espace de noms du locataire dans la liste
spec.targetNamespaces
.
Créez le groupe Operator en exécutant la commande suivante :
$ oc create -f team1-operatorgroup.yaml
Prochaines étapes
Installer l'Opérateur dans l'espace de noms de l'Opérateur du locataire. Cette tâche est plus facile à réaliser en utilisant l'OperatorHub dans la console web plutôt que le CLI ; pour une procédure détaillée, voir Installer à partir de l'OperatorHub en utilisant la console web.
NoteUne fois l'installation de l'opérateur terminée, l'opérateur réside dans l'espace de noms de l'opérateur du locataire et surveille l'espace de noms du locataire, mais ni le pod de l'opérateur ni son compte de service ne sont visibles ou utilisables par le locataire.
Ressources supplémentaires
4.1.6. Installation d'opérateurs globaux dans des espaces de noms personnalisés
Lors de l'installation d'opérateurs avec la console web d'OpenShift Container Platform, le comportement par défaut installe les opérateurs qui prennent en charge le mode d'installation All namespaces dans l'espace de noms global par défaut openshift-operators
. Cela peut entraîner des problèmes liés au partage des plans d'installation et des politiques de mise à jour entre tous les opérateurs de l'espace de noms. Pour plus de détails sur ces limitations, voir "Colocation d'opérateurs dans un espace de noms".
En tant qu'administrateur de cluster, vous pouvez contourner manuellement ce comportement par défaut en créant un espace de noms global personnalisé et en utilisant cet espace de noms pour installer votre propre ensemble d'opérateurs et leurs dépendances.
Procédure
Avant d'installer l'opérateur, créez un espace de noms pour l'installation de l'opérateur de votre choix. Cet espace de noms d'installation deviendra l'espace de noms global personnalisé :
Définissez une ressource
Namespace
et enregistrez le fichier YAML, par exempleglobal-operators.yaml
:apiVersion: v1 kind: Namespace metadata: name: global-operators
Créez l'espace de noms en exécutant la commande suivante :
$ oc create -f global-operators.yaml
Créez un global Operator group personnalisé, qui est un groupe d'opérateurs qui surveille tous les espaces de noms :
Définissez une ressource
OperatorGroup
et enregistrez le fichier YAML, par exempleglobal-operatorgroup.yaml
. Omettez les champsspec.selector
etspec.targetNamespaces
pour en faire une ressource global Operator group, qui sélectionne tous les espaces de noms :apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: global-operatorgroup namespace: global-operators
NoteLe site
status.namespaces
d'un groupe d'opérateurs global créé contient la chaîne vide (""
), qui signale à un opérateur consommateur qu'il doit surveiller tous les espaces de noms.Créez le groupe Operator en exécutant la commande suivante :
$ oc create -f global-operatorgroup.yaml
Prochaines étapes
Installez l'opérateur souhaité dans l'espace de noms d'installation. Cette tâche est plus facile à réaliser en utilisant l'OperatorHub dans la console web plutôt que le CLI ; pour une procédure détaillée, voir Installer à partir de l'OperatorHub en utilisant la console web.
NoteLorsque vous lancez l'installation d'un opérateur, si celui-ci a des dépendances, celles-ci sont également installées automatiquement dans l'espace de noms global personnalisé. Par conséquent, les opérateurs dépendants peuvent avoir la même politique de mise à jour et les mêmes plans d'installation partagés.
Ressources supplémentaires
4.1.7. Placement en pods des charges de travail des opérateurs
Par défaut, Operator Lifecycle Manager (OLM) place les pods sur des nœuds de travail arbitraires lors de l'installation d'un opérateur ou du déploiement de charges de travail Operand. En tant qu'administrateur, vous pouvez utiliser des projets avec une combinaison de sélecteurs de nœuds, de taints et de tolérances pour contrôler le placement d'opérateurs et d'opérandes sur des nœuds spécifiques.
Le contrôle du placement des charges de travail de l'opérateur et de l'opérande dans le pod est soumis aux conditions préalables suivantes :
-
Déterminez un nœud ou un ensemble de nœuds à cibler pour les modules en fonction de vos besoins. Si elle est disponible, notez une étiquette existante, telle que
node-role.kubernetes.io/app
, qui identifie le ou les nœuds. Sinon, ajoutez une étiquette, telle quemyoperator
, en utilisant un ensemble de machines de calcul ou en modifiant le nœud directement. Vous utiliserez cette étiquette dans une étape ultérieure comme sélecteur de nœuds dans votre projet. -
Si vous voulez vous assurer que seuls les pods ayant une certaine étiquette sont autorisés à s'exécuter sur les nœuds, tout en dirigeant les charges de travail non liées vers d'autres nœuds, ajoutez une altération au(x) nœud(s) en utilisant un ensemble de machines de calcul ou en modifiant le nœud directement. Utilisez un effet qui garantit que les nouveaux pods qui ne correspondent pas à l'erreur ne peuvent pas être planifiés sur les nœuds. Par exemple, un effet
myoperator:NoSchedule
garantit que les nouveaux modules qui ne correspondent pas à l'effet ne sont pas programmés sur ce nœud, mais que les modules existants sur le nœud sont autorisés à rester. - Créez un projet configuré avec un sélecteur de nœuds par défaut et, si vous avez ajouté une taint, une tolérance correspondante.
À ce stade, le projet que vous avez créé peut être utilisé pour diriger les pods vers les nœuds spécifiés dans les scénarios suivants :
- Pour les cabines d'opérateurs
-
Les administrateurs peuvent créer un objet
Subscription
dans le projet comme décrit dans la section suivante. En conséquence, les pods de l'opérateur sont placés sur les nœuds spécifiés. - Pour les pods d'opérandes
- En utilisant un opérateur installé, les utilisateurs peuvent créer une application dans le projet, qui place la ressource personnalisée (CR) appartenant à l'opérateur dans le projet. Par conséquent, les pods de l'Opérateur sont placés sur les nœuds spécifiés, à moins que l'Opérateur ne déploie des objets à l'échelle du cluster ou des ressources dans d'autres espaces de noms, auquel cas ce placement de pods personnalisés ne s'applique pas.
Ressources supplémentaires
4.1.8. Contrôler l'endroit où un opérateur est installé
Par défaut, lorsque vous installez un Operator, OpenShift Container Platform installe le pod Operator sur l'un de vos nœuds de travail de manière aléatoire. Cependant, il peut y avoir des situations où vous voulez que ce pod soit planifié sur un nœud spécifique ou un ensemble de nœuds.
Les exemples suivants décrivent des situations dans lesquelles vous pourriez vouloir planifier un pod opérateur sur un nœud ou un ensemble de nœuds spécifique :
-
Si un opérateur a besoin d'une plateforme particulière, telle que
amd64
ouarm64
- Si un opérateur nécessite un système d'exploitation particulier, tel que Linux ou Windows
- Si vous souhaitez que les opérateurs qui travaillent ensemble soient programmés sur le même hôte ou sur des hôtes situés sur le même rack
- Si vous souhaitez que les opérateurs soient dispersés dans l'infrastructure afin d'éviter les temps d'arrêt dus à des problèmes de réseau ou de matériel
Vous pouvez contrôler l'endroit où un pod d'opérateur est installé en ajoutant des contraintes d'affinité de nœud, d'affinité de pod ou d'anti-affinité de pod à l'objet Subscription
de l'opérateur. L'affinité de nœud est un ensemble de règles utilisées par le planificateur pour déterminer où un module peut être placé. L'affinité de pod vous permet de vous assurer que des pods liés sont planifiés sur le même nœud. L'anti-affinité de pod vous permet d'empêcher un pod d'être planifié sur un nœud.
Les exemples suivants montrent comment utiliser l'affinité de nœud ou l'anti-affinité de pod pour installer une instance de Custom Metrics Autoscaler Operator sur un nœud spécifique du cluster :
Exemple d'affinité de nœud qui place le pod de l'opérateur sur un nœud spécifique
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: openshift-custom-metrics-autoscaler-operator
namespace: openshift-keda
spec:
name: my-package
source: my-operators
sourceNamespace: operator-registries
config:
affinity:
nodeAffinity: 1
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- ip-10-0-163-94.us-west-2.compute.internal
...
- 1
- Une affinité de nœud qui exige que le pod de l'opérateur soit programmé sur un nœud nommé
ip-10-0-163-94.us-west-2.compute.internal
.
Exemple d'affinité de nœud qui place le pod de l'opérateur sur un nœud avec une plate-forme spécifique
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: openshift-custom-metrics-autoscaler-operator
namespace: openshift-keda
spec:
name: my-package
source: my-operators
sourceNamespace: operator-registries
config:
affinity:
nodeAffinity: 1
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- arm64
- key: kubernetes.io/os
operator: In
values:
- linux
- 1
- Une affinité de nœud qui exige que le pod de l'opérateur soit programmé sur un nœud avec les étiquettes
kubernetes.io/arch=arm64
etkubernetes.io/os=linux
.
Exemple d'affinité de pod qui place le pod de l'opérateur sur un ou plusieurs nœuds spécifiques
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: openshift-custom-metrics-autoscaler-operator
namespace: openshift-keda
spec:
name: my-package
source: my-operators
sourceNamespace: operator-registries
config:
affinity:
podAffinity: 1
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- test
topologyKey: kubernetes.io/hostname
- 1
- Une affinité de pod qui place le pod de l'opérateur sur un nœud qui a des pods avec le label
app=test
.
Exemple d'anti-affinité de pods qui empêche le pod Operator d'accéder à un ou plusieurs nœuds spécifiques
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: openshift-custom-metrics-autoscaler-operator
namespace: openshift-keda
spec:
name: my-package
source: my-operators
sourceNamespace: operator-registries
config:
affinity:
podAntiAffinity: 1
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: cpu
operator: In
values:
- high
topologyKey: kubernetes.io/hostname
...
- 1
- Une anti-affinité de pods qui empêche le pod de l'opérateur d'être planifié sur un nœud qui a des pods avec le label
cpu=high
.
Procédure
Pour contrôler l'emplacement d'une nacelle d'opérateur, procédez comme suit :
- Installez l'opérateur comme d'habitude.
- Si nécessaire, assurez-vous que vos nœuds sont étiquetés de manière à répondre correctement à l'affinité.
Modifiez l'objet Operator
Subscription
pour ajouter une affinité :apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-custom-metrics-autoscaler-operator namespace: openshift-keda spec: name: my-package source: my-operators sourceNamespace: operator-registries config: affinity: 1 nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - ip-10-0-185-229.ec2.internal ...
- 1
- Ajoutez un
nodeAffinity
, unpodAffinity
ou unpodAntiAffinity
. Reportez-vous à la section Ressources supplémentaires qui suit pour obtenir des informations sur la création d'une affinité.
Vérification
Pour s'assurer que le pod est déployé sur le nœud spécifique, exécutez la commande suivante :
$ oc get pods -o wide
Exemple de sortie
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES custom-metrics-autoscaler-operator-5dcc45d656-bhshg 1/1 Running 0 50s 10.131.0.20 ip-10-0-185-229.ec2.internal <none> <none>