Rechercher

Chapitre 4. Tâches de l'administrateur

download PDF

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

  1. Naviguez dans la console web jusqu'à la page Operators OperatorHub.
  2. 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.

  3. Sélectionnez l'opérateur pour afficher des informations supplémentaires.

    Note

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

  4. Lisez les informations sur l'opérateur et cliquez sur Install.
  5. Sur la page Install Operator:

    1. 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.
    2. 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.
    3. Sélectionnez une adresse Update Channel (si plusieurs sont disponibles).
    4. Sélectionnez la stratégie d'approbation Automatic ou Manual, comme décrit précédemment.
  6. Cliquez sur Install pour rendre l'opérateur disponible pour les espaces de noms sélectionnés sur ce cluster OpenShift Container Platform.

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

    2. Si vous avez sélectionné une stratégie d'approbation Automatic, le statut du surclassement devrait être résolu à Up to date sans intervention.
  7. 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é.

    Note

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

    1. 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 Workloads Pods qui signalent des problèmes afin de les résoudre.

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

  1. 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é.

  2. 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
  3. 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 ou SingleNamespace. Si l'opérateur que vous avez l'intention d'installer utilise le mode AllNamespaces, l'espace de noms openshift-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.

    Note

    La version console web de cette procédure gère la création des objets OperatorGroup et Subscription automatiquement dans les coulisses lorsque vous choisissez le mode SingleNamespace.

    1. Créez un fichier YAML de l'objet OperatorGroup, par exemple operatorgroup.yaml:

      Exemple d'objet OperatorGroup

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

    2. Créer l'objet OperatorGroup:

      $ oc apply -f operatorgroup.yaml
  4. Créez un fichier YAML de l'objet Subscription pour abonner un espace de noms à un opérateur, par exemple sub.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 noms openshift-operators. Sinon, indiquez l'espace de noms unique correspondant à l'utilisation du mode d'installation SingleNamespace.
    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 un volumeMount fait référence à un volume 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 un NodeSelector pour le module créé par OLM.
  5. 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

  1. 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 champ startingCSV. Définissez le champ installPlanApproval sur Manual 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.
  2. Créer l'objet Subscription:

    $ oc apply -f sub.yaml
  3. Approuver manuellement le plan d'installation en attente pour terminer l'installation de l'opérateur.

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

    Important

    Pour plus d'informations sur ce point et d'autres limitations, voir "Operators in multitenant clusters".

Procédure

  1. 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 noms team1-operator:

    1. Définissez une ressource Namespace et enregistrez le fichier YAML, par exemple team1-operator.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: team1-operator
    2. Créez l'espace de noms en exécutant la commande suivante :

      $ oc create -f team1-operator.yaml
  2. 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:

    1. Définissez une ressource OperatorGroup et enregistrez le fichier YAML, par exemple team1-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.
    2. 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.

    Note

    Une 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

  1. 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é :

    1. Définissez une ressource Namespace et enregistrez le fichier YAML, par exemple global-operators.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: global-operators
    2. Créez l'espace de noms en exécutant la commande suivante :

      $ oc create -f global-operators.yaml
  2. Créez un global Operator group personnalisé, qui est un groupe d'opérateurs qui surveille tous les espaces de noms :

    1. Définissez une ressource OperatorGroup et enregistrez le fichier YAML, par exemple global-operatorgroup.yaml. Omettez les champs spec.selector et spec.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
      Note

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

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

    Note

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

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 :

  1. 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 que myoperator, 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.
  2. 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.
  3. 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.

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 ou arm64
  • 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 et kubernetes.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 :

  1. Installez l'opérateur comme d'habitude.
  2. Si nécessaire, assurez-vous que vos nœuds sont étiquetés de manière à répondre correctement à l'affinité.
  3. 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, un podAffinity ou un podAntiAffinity. 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>

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.