6.2. Spécifier des nœuds pour les composants d'OpenShift Virtualization

Spécifiez les nœuds où vous souhaitez déployer les opérateurs de virtualisation OpenShift, les charges de travail et les contrôleurs en configurant les règles de placement des nœuds.

Note

Vous pouvez configurer le placement des nœuds pour certains composants après avoir installé OpenShift Virtualization, mais il ne doit pas y avoir de machines virtuelles présentes si vous souhaitez configurer le placement des nœuds pour les charges de travail.

6.2.1. A propos de l'emplacement des nœuds pour les composants de virtualisation

Vous pourriez vouloir personnaliser l'endroit où OpenShift Virtualization déploie ses composants pour vous assurer que :

Les machines virtuelles ne se déploient que sur les nœuds destinés aux charges de travail de virtualisation.
Les opérateurs ne se déploient que sur les nœuds d'infrastructure.
Certains nœuds ne sont pas affectés par OpenShift Virtualization. Par exemple, vous avez des charges de travail non liées à la virtualisation qui s'exécutent sur votre cluster, et vous voulez que ces charges de travail soient isolées d'OpenShift Virtualization.

6.2.1.1. Comment appliquer les règles de placement des nœuds aux composants de virtualisation ?

Vous pouvez spécifier les règles de placement des nœuds pour un composant en éditant l'objet correspondant directement ou en utilisant la console web.

Pour les opérateurs de virtualisation OpenShift que Operator Lifecycle Manager (OLM) déploie, modifiez directement l'objet OLM Subscription. Actuellement, vous ne pouvez pas configurer les règles de placement des nœuds pour l'objet Subscription à l'aide de la console Web.
Pour les composants que les opérateurs de virtualisation OpenShift déploient, modifiez directement l'objet HyperConverged ou configurez-le à l'aide de la console web lors de l'installation d'OpenShift Virtualization.
Pour le provisionneur de chemins d'accès, modifiez l'objet HostPathProvisioner directement ou configurez-le à l'aide de la console Web.
Avertissement
Vous devez planifier le hostpath provisioner et les composants de virtualisation sur les mêmes nœuds. Sinon, les pods de virtualisation qui utilisent le hostpath provisioner ne peuvent pas s'exécuter.

En fonction de l'objet, vous pouvez utiliser un ou plusieurs des types de règles suivants :

nodeSelector: Permet aux pods d'être planifiés sur des nœuds étiquetés avec la ou les paires clé-valeur que vous spécifiez dans ce champ. Le nœud doit avoir des étiquettes qui correspondent exactement à toutes les paires répertoriées.
affinity: Permet d'utiliser une syntaxe plus expressive pour définir des règles qui font correspondre des nœuds à des pods. Affinity permet également de nuancer la manière dont les règles sont appliquées. Par exemple, vous pouvez spécifier qu'une règle est une préférence plutôt qu'une exigence absolue, de sorte que les modules sont toujours programmés si la règle n'est pas respectée.
tolerations: Permet aux pods d'être planifiés sur des nœuds qui ont des taches correspondantes. Si une tare est appliquée à un nœud, ce nœud n'accepte que les pods qui tolèrent la tare.

6.2.1.2. Emplacement du nœud dans l'objet OLM Subscription

Pour spécifier les nœuds où OLM déploie les opérateurs de virtualisation OpenShift, modifiez l'objet Subscription pendant l'installation de la virtualisation OpenShift. Vous pouvez inclure des règles de placement des nœuds dans le champ spec.config, comme le montre l'exemple suivant :

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  startingCSV: kubevirt-hyperconverged-operator.v4.12.2
  channel: "stable"
  config: 1

1: Le champ config prend en charge nodeSelector et tolerations, mais pas affinity.

6.2.1.3. Placement des nœuds dans l'objet HyperConverged

Pour spécifier les nœuds où OpenShift Virtualization déploie ses composants, vous pouvez inclure l'objet nodePlacement dans le fichier de ressources personnalisées (CR) HyperConverged Cluster que vous créez lors de l'installation d'OpenShift Virtualization. Vous pouvez inclure nodePlacement dans les champs spec.infra et spec.workloads, comme le montre l'exemple suivant :

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  infra:
    nodePlacement: 1
    ...
  workloads:
    nodePlacement:
    ...

1: Les champs nodePlacement supportent les champs nodeSelector, affinity et tolerations.

6.2.1.4. Placement du nœud dans l'objet HostPathProvisioner

Vous pouvez configurer les règles de placement des nœuds dans le champ spec.workload de l'objet HostPathProvisioner que vous créez lorsque vous installez le provisionneur de chemins d'accès.

apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
kind: HostPathProvisioner
metadata:
  name: hostpath-provisioner
spec:
  imagePullPolicy: IfNotPresent
  pathConfig:
    path: "</path/to/backing/directory>"
    useNamingPrefix: false
  workload: 1

1: Le champ workload supporte les champs nodeSelector, affinity et tolerations.

6.2.1.5. Ressources supplémentaires

6.2.2. Exemples de manifestes

Les exemples de fichiers YAML suivants utilisent les objets nodePlacement, affinity, et tolerations pour personnaliser l'emplacement des nœuds pour les composants OpenShift Virtualization.

6.2.2.1. Objet d'abonnement du gestionnaire du cycle de vie de l'opérateur

6.2.2.1.1. Exemple : Placement d'un nœud avec nodeSelector dans l'objet OLM Subscription

Dans cet exemple, nodeSelector est configuré pour qu'OLM place les opérateurs de virtualisation OpenShift sur les nœuds étiquetés example.io/example-infra-key = example-infra-value.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  startingCSV: kubevirt-hyperconverged-operator.v4.12.2
  channel: "stable"
  config:
    nodeSelector:
      example.io/example-infra-key: example-infra-value

6.2.2.1.2. Exemple : Placement des nœuds avec tolérances dans l'objet OLM Abonnement

Dans cet exemple, les nœuds réservés à OLM pour déployer les opérateurs de virtualisation OpenShift sont étiquetés avec le taint key=virtualization:NoSchedule. Seuls les pods avec les tolérances correspondantes sont planifiés sur ces nœuds.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  startingCSV: kubevirt-hyperconverged-operator.v4.12.2
  channel: "stable"
  config:
    tolerations:
    - key: "key"
      operator: "Equal"
      value: "virtualization"
      effect: "NoSchedule"

6.2.2.2. Objet hyperconvergé

6.2.2.2.1. Exemple : Placement d'un nœud avec nodeSelector dans le cluster hyperconvergé CR

Dans cet exemple, nodeSelector est configuré de manière à ce que les ressources d'infrastructure soient placées sur les nœuds identifiés par example.io/example-infra-key = example-infra-value et que les charges de travail soient placées sur les nœuds identifiés par example.io/example-workloads-key = example-workloads-value.

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  infra:
    nodePlacement:
      nodeSelector:
        example.io/example-infra-key: example-infra-value
  workloads:
    nodePlacement:
      nodeSelector:
        example.io/example-workloads-key: example-workloads-value

6.2.2.2.2. Exemple : Placement de nœuds avec affinité dans le cluster hyperconvergé CR

Dans cet exemple, affinity est configuré de manière à ce que les ressources d'infrastructure soient placées sur les nœuds identifiés par example.io/example-infra-key = example-value et que les charges de travail soient placées sur les nœuds identifiés par example.io/example-workloads-key = example-workloads-value. Les nœuds disposant de plus de huit CPU sont privilégiés pour les charges de travail, mais s'ils ne sont pas disponibles, les pods sont tout de même planifiés.

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  infra:
    nodePlacement:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: example.io/example-infra-key
                operator: In
                values:
                - example-infra-value
  workloads:
    nodePlacement:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: example.io/example-workloads-key
                operator: In
                values:
                - example-workloads-value
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: example.io/num-cpus
                operator: Gt
                values:
                - 8

6.2.2.2.3. Exemple : Placement de nœuds avec tolérances dans le cluster hyperconvergé CR

Dans cet exemple, les nœuds réservés aux composants OpenShift Virtualization sont étiquetés avec le taint key=virtualization:NoSchedule. Seuls les pods avec les tolérances correspondantes sont planifiés sur ces nœuds.

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  workloads:
    nodePlacement:
      tolerations:
      - key: "key"
        operator: "Equal"
        value: "virtualization"
        effect: "NoSchedule"

6.2.2.3. Objet HostPathProvisioner

6.2.2.3.1. Exemple : Placement d'un nœud avec nodeSelector dans l'objet HostPathProvisioner

Dans cet exemple, nodeSelector est configuré de manière à ce que les charges de travail soient placées sur les nœuds identifiés par example.io/example-workloads-key = example-workloads-value.

apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
kind: HostPathProvisioner
metadata:
  name: hostpath-provisioner
spec:
  imagePullPolicy: IfNotPresent
  pathConfig:
    path: "</path/to/backing/directory>"
    useNamingPrefix: false
  workload:
    nodeSelector:
      example.io/example-workloads-key: example-workloads-value