Ce document est destiné aux propriétaires d'applications et aux administrateurs de plate-forme qui exécutent des clusters Anthos sur solution Bare Metal. Ce document explique comment utiliser des configurations de planification telles que l'affinité et l'anti-affinité pour les VM utilisant l'environnement d'exécution des VM Anthos.
Avant de commencer
Pour terminer ce document, vous devez disposer des ressources suivantes :
- Accès aux clusters Anthos sur solution Bare Metal version 1.12.0 (
anthosBareMetalVersion: 1.12.0
) ou cluster supérieur. Vous pouvez utiliser n'importe quel type de cluster capable d'exécuter des charges de travail. Si nécessaire, essayez les clusters Anthos sur solution 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 dekubectl
. 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 Anthos. 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 des VM Anthos ne programme la VM que sur les nœuds portant un 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 Anthos utilise la même logique de planification de VM et la même structure de manifeste que Kubernetes pour attribuer des pods à des 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.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éskey: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.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