Planifier les VM qui utilisent l'environnement d'exécution des VM sur Google Distributed Cloud

Ce document est destiné aux propriétaires d'applications et aux administrateurs de plate-forme qui exécutent GKE sur une solution Bare Metal. Ce document explique comment utiliser des configurations de planification telles que l'affinité et l'anti-affinité pour les VM qui utilisent l'environnement d'exécution des VM sur Google Distributed Cloud.

Avant de commencer

Pour suivre les instructions de ce document, vous devez disposer des ressources suivantes :

Un accès à GKE sur bare metal version 1.12.0 (anthosBareMetalVersion: 1.12.0) ou à un cluster supérieur. Vous pouvez utiliser n'importe quel type de cluster capable d'exécuter des charges de travail. Si nécessaire, essayez GKE sur Bare Metal sur Compute Engine ou consultez la présentation de la création de clusters.
L'outil client virtctl, installé en tant que plug-in de kubectl. Si nécessaire, installez l'outil client virtctl.

Présentation des configurations de planification

Les configurations de planification sont des valeurs facultatives dans l'environnement d'exécution des VM sur Google Distributed Cloud. Si aucune configuration de planification n'est spécifiée, la VM utilise le comportement de planification par défaut de Kubernetes.

Avec le comportement de planification par défaut, les VM sont réparties sur votre cluster. Le planificateur examine la disponibilité actuelle des ressources de nœuds, telles que le processeur et la mémoire, et planifie les VM sur les nœuds pour répartir les besoins de calcul. Si vous n'avez pas d'exigences spécifiques, vous n'avez pas besoin de définir de configurations de planification.

Les trois champs suivants sont disponibles pour planifier des VM :

nodeSelector : spécifie les libellés de nœud dont le nœud hôte d'une VM doit disposer. L'environnement d'exécution de VM sur Google Distributed Cloud ne planifie la VM que sur les nœuds portant le libellé spécifié.
Affinité : spécifie les règles d'affinité de la VM. Elle inclut l'affinité de nœuds, et l'affinité ou l'anti-affinité entre VM. Vous définissez une exigence souple ou stricte pour le planificateur :
- preferredDuringSchedulingIgnoredDuringExecution : est une exigence souple. Le planificateur tente de répondre à votre requête. Si le planificateur ne peut pas honorer la requête, la VM peut être programmée sur un nœud non préféré.
- requiredDuringSchedulingIgnoredDuringExecution : est une exigence stricte. Le planificateur tente de répondre à votre requête. Si aucun nœud ne correspond à vos besoins, la VM n'est pas planifiée.
Tolerations : permet de planifier la VM sur des nœuds avec des rejets correspondants.

Vous pouvez définir n'importe laquelle de ces configurations de planification pour répondre à vos besoins en matière de charges de travail de calcul et de planification. En plus des configurations de planification, la planification des VM dépend des ressources disponibles.

L'environnement d'exécution des VM sur Google Distributed Cloud utilise la même logique de planification de VM et la même structure de fichier manifeste que Kubernetes pour attribuer des pods aux nœuds. Pour en savoir plus sur ces configurations de planification, consultez les liens suivants :

Placer les VM sur un nœud spécifique

Si vous disposez de nœuds avec des configurations matérielles spécifiques, vous pouvez planifier les VM pour qu'elles ne s'exécutent que sur ces nœuds. Par exemple, votre VM peut avoir besoin d'un type de processeur spécifique ou nécessiter une compatibilité GPU. Vous pouvez utiliser un nodeSelector de base ou des règles d'affinité plus flexibles pour planifier l'exécution des VM sur ces nœuds.

nodeSelector

Le fichier manifeste VirtualMachine suivant utilise un nodeSelector pour une exigence de planification stricte. Si aucun nœud ne correspond à la configuration de planification, la VM ne peut pas être planifiée.

Créez un fichier manifeste VirtualMachine (my-scheduled-vm.yaml,, par exemple) dans l'éditeur de votre choix.
```
nano my-scheduled-vm.yaml
```
Copiez et collez le fichier manifeste YAML suivant :
```
apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
    nodeSelector:
      kubernetes.io/hostname: NODE_NAME
```
Remplacez les valeurs suivantes :
- VM_NAME : nom de votre VM.
- NODE_NAME : par le ou les nœuds sur lesquels vous souhaitez programmer votre VM.
Le disque de démarrage nommé VM_NAME-boot-dv doit déjà exister. Pour en savoir plus, consultez la section Créer un disque de démarrage de VM.
Enregistrez et fermez le fichier manifeste de VM dans votre éditeur.
Créez la VM et planifiez la configuration en utilisant kubectl :
```
kubectl apply -f my-scheduled-vm.yaml
```

Affinité

Le fichier manifeste VirtualMachine suivant utilise l'affinité pour une exigence de planification souple. Le planificateur tente de répondre à votre requête. Si le planificateur ne peut pas accepter la requête, la VM est planifiée sur un nœud non privilégié.

Créez un fichier manifeste VirtualMachine (my-scheduled-vm.yaml,, par exemple) dans l'éditeur de votre choix.
```
nano my-scheduled-vm.yaml
```

Copiez et collez le fichier manifeste YAML suivant :

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - NODE_NAME

Remplacez les valeurs suivantes :

VM_NAME : nom de votre VM.
NODE_NAME : par le ou les nœuds sur lesquels vous souhaitez programmer votre VM.

Le disque de démarrage nommé VM_NAME-boot-dv doit déjà exister. Pour en savoir plus, consultez la section Créer un disque de démarrage de VM.

Enregistrez et fermez le fichier manifeste de VM dans votre éditeur.
Créez la VM et planifiez la configuration en utilisant kubectl :
```
kubectl apply -f my-scheduled-vm.yaml
```

Ne placez pas de VM sur un nœud spécifique

Certaines VM peuvent avoir des charges de travail qui ne peuvent pas s'exécuter sur un nœud particulier. Vous pouvez utiliser des règles d'anti-affinité pour éviter de planifier des VM sur ces nœuds.

Le fichier manifeste VirtualMachine suivant utilise l'affinité pour une exigence de planification souple. Le planificateur tente de répondre à votre requête. Si le planificateur ne peut pas honorer la requête, la VM peut être programmée sur un nœud inapproprié.

Créez un fichier manifeste VirtualMachine (my-scheduled-vm.yaml,, par exemple) dans l'éditeur de votre choix.
```
nano my-scheduled-vm.yaml
```

Copiez et collez le fichier manifeste YAML suivant :

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VVM_NAME
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
    affinity:
      nodeAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          preference:
            matchExpressions:
            - key: kubernetes.io/hostname
              operator: NotIn
              values:
              - NODE_NAME

Remplacez les valeurs suivantes :

VM_NAME : nom de votre VM.
NODE_NAME : nœud sur lequel vous souhaitez planifier votre VM.

Le disque de démarrage nommé VM_NAME-boot-dv doit déjà exister. Pour en savoir plus, consultez la section Créer un disque de démarrage de VM.

Enregistrez et fermez le fichier manifeste de VM dans votre éditeur.
Créez la VM et planifiez la configuration en utilisant kubectl :
```
kubectl apply -f my-scheduled-vm.yaml
```

Dissocier les VM

Vos charges de travail de calcul peuvent comporter des VM réparties sur plusieurs nœuds pour offrir une haute disponibilité, par exemple un pool de VM frontend. Vous pouvez utiliser des règles d'anti-affinité entre les VM pour éviter de planifier plusieurs VM sur un même nœud.

Le fichier manifeste VirtualMachine suivant utilise l'affinité pour une exigence de planification souple. Le planificateur tente de répondre à votre requête. Si le planificateur ne peut pas honorer la requête, la VM peut être programmée sur un nœud inapproprié.

Créez un fichier manifeste VirtualMachine (my-scheduled-vm.yaml,, par exemple) dans l'éditeur de votre choix.
```
nano my-scheduled-vm.yaml
```
Copiez et collez le fichier manifeste YAML suivant :
```
apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
  labels:
    KEY:VALUE
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            topologyKey: kubernetes.io/hostname
            labelSelector:
              matchLabels:
                KEY:VALUE
```
Remplacez les valeurs suivantes :
- VM_NAME : nom de votre VM.
- KEY:VALUE : libellé key:value à appliquer aux VM que vous souhaitez planifier sur différents nœuds. Pour en savoir plus, consultez la section Libellés et sélecteurs.
Le disque de démarrage nommé VM_NAME-boot-dv doit déjà exister. Pour en savoir plus, consultez la section Créer un disque de démarrage de VM.

Remarque : Pour une exigence de planification stricte, définissez requiredDuringSchedulingIgnoredDuringExecution plutôt que preferredDuringSchedulingIgnoredDuringExecution.
Enregistrez et fermez le fichier manifeste de VM dans votre éditeur.
Créez la VM et planifiez la configuration en utilisant kubectl :
```
kubectl apply -f my-scheduled-vm.yaml
```

Regrouper les VM

Vos charges de travail de calcul peuvent comporter des VM devant être regroupées sur un même nœud pour réduire la latence (middleware et niveau de base de données par exemple). Vous pouvez utiliser des règles d'affinité inter-VM pour planifier des VM ensemble sur des nœuds.

Le fichier manifeste VirtualMachine suivant utilise l'affinité pour une exigence de planification souple. Le planificateur tente de répondre à votre requête. Si le planificateur ne peut pas honorer la requête, la VM peut être programmée sur un nœud inapproprié.

Créez un fichier manifeste VirtualMachine (my-scheduled-vm.yaml,, par exemple) dans l'éditeur de votre choix.
```
nano my-scheduled-vm.yaml
```
Copiez et collez le fichier manifeste YAML suivant :
```
apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
  labels:
    KEY:VALUE
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
    affinity:
      podAffinity:
        preferredDuringSchedulingIgnoredDuringExecution
        - podAffinityTerm:
            topologyKey: kubernetes.io/hostname
            labelSelector:
              matchLabels:
                KEY:VALUE
          weight: 100
```
Remplacez les valeurs suivantes :
- VM_NAME : nom de votre VM.
- KEY:VALUE : paire de libellés key:value à appliquer aux VM que vous souhaitez planifier sur différents nœuds. Pour en savoir plus, consultez la section Libellés et sélecteurs.
Le disque de démarrage nommé VM_NAME-boot-dv doit déjà exister. Pour en savoir plus, consultez la section Créer un disque de démarrage de VM.

Remarque : Pour une exigence de planification stricte, définissez requiredDuringSchedulingIgnoredDuringExecution plutôt que preferredDuringSchedulingIgnoredDuringExecution.
Enregistrez et fermez le fichier manifeste de VM dans votre éditeur.
Créez la VM et planifiez la configuration en utilisant kubectl :
```
kubectl apply -f my-scheduled-vm.yaml
```

Planifier des VM sur des nœuds avec rejets

Les rejets sont une propriété de planification qui permet aux nœuds de n'autoriser que les VM avec des tolérances spécifiées à s'exécuter. Vous pouvez appliquer un rejet à un nœud, puis définir une tolérance pour que la VM s'exécute sur le nœud dans le fichier manifeste VirtualMachine. Pour plus d'informations, consultez la section Rejets et tolérances.

Créez un fichier manifeste VirtualMachine (my-scheduled-vm.yaml,, par exemple) dans l'éditeur de votre choix.
```
nano my-scheduled-vm.yaml
```
Copiez et collez le fichier manifeste YAML suivant :
```
apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
    tolerations:
    - key: KEY_NAME
      operator: "Equal"
      value: KEY_VALUE
      effect: "NoSchedule"
```
Remplacez les valeurs suivantes :
- VM_NAME : nom de votre VM.
- KEY_NAME : nom de clé de votre tolérance qui correspond au rejet sur le nœud.
- KEY_VALUE : valeur de clé de votre tolérance qui correspond au rejet sur le nœud.
Le disque de démarrage nommé VM_NAME-boot-dv doit déjà exister. Pour en savoir plus, consultez la section Créer un disque de démarrage de VM.
Enregistrez et fermez le fichier manifeste de VM dans votre éditeur.
Créez la VM et planifiez la configuration en utilisant kubectl :
```
kubectl apply -f my-scheduled-vm.yaml
```

Étapes suivantes

Modifiez une VM dans GKE sur une solution Bare Metal.