Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Configurer des VM compatibles avec NUMA

Ce document explique comment configurer des clusters et des VM pour prendre en charge les charges de travail à hautes performances et à faible latence grâce aux avantages de calcul de l'accès mémoire non uniforme (NUMA). Des instructions permettent d'ajuster les paramètres Kubernetes pour les nœuds de cluster. Ce document explique également comment configurer des machines virtuelles (VM) avec une affinité NUMA afin qu'elles soient planifiées sur les nœuds NUMA et qu'elles en tirent parti.

Avec une VM compatible avec NUMA, toutes les communications au sein de la VM sont locales au nœud NUMA. La VM compatible avec NUMA évite les transactions de données vers et depuis des ressources distantes qui peuvent dégrader les performances de la VM.

Configurer des nœuds pour utiliser NUMA

Les sections suivantes expliquent comment configurer les composants Kubernetes essentiels pour ajuster le nœud et s'assurer qu'il peut planifier des conteneurs compatibles avec NUMA. Ces nœuds NUMA sont ajustés pour optimiser les performances du processeur et de la mémoire. Suivez les instructions pour chaque nœud sur lequel vous souhaitez exécuter des VM compatibles avec NUMA.

Mettre à jour la configuration de kubelet

Dans le cadre de la configuration du nœud pour prendre en charge l'affinité de nœud NUMA, vous devez apporter les modifications suivantes à la configuration de kubelet :

Activer le gestionnaire de processeur avec une règle static
Activer le gestionnaire de mémoire avec une règle Static
Activer le gestionnaire de topologie avec une topologie restricted

Pour configurer kubelet sur votre nœud de calcul :

Recherchez le fichier kubelet sur votre nœud de calcul et ouvrez-le pour le modifier :
```
edit /etc/default/kubelet
```
Si le fichier kubelet n'apparaît pas, créez-le à l'aide de la commande suivante :
```
echo "KUBELET_EXTRA_ARGS=\"\"" >> /etc/default/kubelet
```
Cette commande crée le kubelet fichier avec une section vide KUBELET_EXTRA_ARGS="".
Pour activer le gestionnaire de processeur avec une static règle, ajoutez l' --cpu-manager-policy=static option à la KUBELET_EXTRA_ARGS="" section du fichier :
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static"
```
Pour activer le gestionnaire de mémoire avec une règle Static, ajoutez l' --memory-manager-policy=Static à la KUBELET_EXTRA_ARGS="" du fichier :
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static"
```
Pour activer le gestionnaire de topologie avec une restricted règle, ajoutez l' --topology-manager-policy=restricted option à la KUBELET_EXTRA_ARGS="" section du fichier :
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static --topology-manager-policy=restricted"
```

Vérifiez la quantité de mémoire actuellement réservée par Google Distributed Cloud :

cat /var/lib/kubelet/kubeadm-flags.env

Le résultat doit se présenter sous la forme suivante :

KUBELET_KUBEADM_ARGS="--anonymous-auth=false --authentication-token-webhook=true --authorization-mode=Webhook --container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock --feature-gates=SeccompDefault=true --kube-reserved=cpu=100m,memory=3470Mi --max-pods=110 --node-ip=192.168.1.190 --node-labels=baremetal.cluster.gke.io/k8s-ip=192.168.1.190,baremetal.cluster.gke.io/namespace=cluster-user001,baremetal.cluster.gke.io/node-pool=node-pool-1,cloud.google.com/gke-nodepool=node-pool-1 --pod-infra-container-image=gcr.io/anthos-baremetal-release/pause-amd64:3.1-gke.5 --provider-id=baremetal://192.168.1.190 --read-only-port=10255 --rotate-server-certificates=true --seccomp-default=true"

Le paramètre --kube-reserved=cpu=100m,memory=3470Mi indique que Google Distributed Cloud a réservé 3 470 mébioctets de mémoire sur le nœud.

Définissez l'option --reserved-memory dans la section KUBELET_EXTRA_ARGS du fichier kubelet sur 100 mébioctets de plus que la mémoire réservée actuelle pour tenir compte du seuil d'éviction. S'il n'y a pas de mémoire réservée, vous pouvez ignorer cette étape.

Par exemple, avec la mémoire réservée de 3470Mi de l'exemple de l'étape précédente, vous réservez 3570Mi de mémoire dans le fichier kubelet :
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static --topology-manager-policy=restricted --reserved-memory=0:memory=3570Mi"
```
Supprimez les fichiers d'état du processeur et de la mémoire du répertoire /var/lib :
```
rm /var/lib/cpu_manager_state
rm /var/lib/memory_manager_state
```
Redémarrez kubelet :
```
systemctl start kubelet
```

Pour en savoir plus sur ces paramètres de règle, consultez la documentation Kubernetes suivante :

Configurer le nœud pour utiliser des "hugepages"

Une fois que vous avez activé le gestionnaire de mémoire avec la règle Static, vous pouvez ajouter des "hugepages" pour améliorer davantage les performances de la charge de travail du conteneur sur vos nœuds NUMA. Comme leur nom l'indique, les "hugepages" vous permettent de spécifier des pages de mémoire plus grandes que les 4 kibioctets (Kio) standards. L'environnement d'exécution de VM sur GDC prend en charge les "hugepages" de 2 mébioctets (Mio) et de 1 gibioctet (Gio). Vous pouvez définir des "hugepages" pour un nœud au moment de l'exécution ou au démarrage de la machine du nœud. Nous vous recommandons de configurer des "hugepages" sur chaque nœud sur lequel vous souhaitez exécuter des VM compatibles avec NUMA.

Pour configurer le nombre de "hugepages" d'une taille spécifique sur votre nœud NUMA au moment de l'exécution, utilisez la commande suivante :
```
echo HUGEPAGE_QTY > \
    /sys/devices/system/node/NUMA_NODE/hugepages/hugepages-HUGEPAGE_SIZEkB/nr_hugepages
```
Remplacez les éléments suivants :
- HUGEPAGE_QTY : nombre de "hugepages" à allouer de la taille spécifiée.
- NUMA_NODE: nœud NUMA, tel que node0, auquel vous allouez des "hugepages".
- HUGEPAGE_SIZE: taille des "hugepages" en kibioctets, 2048 (2 Mio) ou 1048576 (1 Gio).

Configurer une VM pour utiliser le nœud NUMA

Une fois que les nœuds de votre cluster sont ajustés pour NUMA, vous pouvez créer des VM compatibles avec NUMA. Les VM compatibles avec NUMA sont planifiées sur des nœuds NUMA.

Pour créer une VM compatible avec NUMA :

Suivez les instructions pour créer une VM à partir d'un fichier manifeste.

Utilisez les paramètres compute suivants pour configurer votre VM afin qu'elle soit compatible avec NUMA :
- spec.compute.guaranteed: définissez guaranteed sur true. Avec ce paramètre, le virt-launcher Pod est configuré pour être placé dans la classe de qualité de service (QoS) garantie de Kubernetes Guaranteed Quality of Service (QoS) class.
- spec.compute.advancedCompute :
  - dedicatedCPUPlacement: définissez dedicatedCPUPlacement sur true. Ce paramètre associe les processeurs virtuels aux processeurs physiques du nœud.
  - hugePageSize: définissez hugePageSize sur 2Mi ou 1Gi pour spécifier la taille des "hugepages" que votre VM doit utiliser, soit 2 mébioctets ou 1 gibioctet.
  - numaGuestMappingPassthrough: incluez une structure vide ({}) pour ce paramètre. Ce paramètre établit une affinité NUMA afin que votre VM ne soit planifiée que sur des nœuds NUMA.
L'exemple de fichier manifeste VirtualMachine suivant montre à quoi peut ressembler une configuration de VM compatible avec NUMA :
```
apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: vm1
spec:
  compute:
    cpu:
      vcpus: 2
    guaranteed: true
    advancedCompute:
      dedicatedCPUPlacement: true
      hugePageSize: 2Mi
      numaGuestMappingPassthrough: {}
    memory:
      capacity: 256Mi
  interfaces:
  - name: eth0
    networkName: pod-network
    default: true
  disks:
  - virtualMachineDiskName: disk-from-gcs
    boot: true
    readOnly: true
```