Version 1.15. Cette version n'est plus compatible. Pour en savoir plus sur la mise à niveau vers la version 1.16, consultez la section Mettre à niveau des clusters dans la dernière documentation. Pour en savoir plus sur les versions compatibles et non compatibles, consultez la page Historique des versions dans la dernière documentation.

Configurer la planification des VM avec NUMA

Ce document explique comment configurer des clusters et des VM pour gérer des charges de travail hautes performances et à faible latence avec l'efficacité informatique de l'accès non uniforme à la mémoire (NUMA). Vous y trouverez des instructions pour régler les paramètres Kubernetes pour les nœuds de cluster. Ce document comprend également des instructions sur la configuration de machines virtuelles (VM) avec affinité NUMA afin qu'elles soient programmées et exploitent les nœuds NUMA.

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

Configurer les nœuds pour utiliser NUMA

Les sections suivantes décrivent comment configurer les composants essentiels de Kubernetes pour régler le nœud et vous assurer qu'il peut programmer des conteneurs compatibles avec NUMA. Ces nœuds NUMA sont réglé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 du kubelet

Dans le cadre de la configuration des nœuds pour accepter l'affinité de nœuds NUMA, vous devez apporter les modifications suivantes à la configuration du kubelet:

Activer le gestionnaire de processeurs avec une règle static
Activer le gestionnaire de mémoire avec une règle Static
Activer le gestionnaire de topologie avec la 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 vous ne voyez pas le fichier kubelet, créez-le à l'aide de la commande suivante:
```
echo "KUBELET_EXTRA_ARGS=\"\"" >> /etc/default/kubelet
```
Cette commande crée le fichier kubelet avec une section KUBELET_EXTRA_ARGS="" vide.
Pour activer le gestionnaire de processeurs avec une règle static, ajoutez l'option --cpu-manager-policy=static à la section KUBELET_EXTRA_ARGS="" du fichier:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static"
```
Pour activer le gestionnaire de mémoire avec une règle Static, ajoutez l'option --memory-manager-policy=Static à la section KUBELET_EXTRA_ARGS="" du fichier:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static"
```
Pour activer le gestionnaire de topologie avec une règle restricted, ajoutez l'option --topology-manager-policy=restricted à la section KUBELET_EXTRA_ARGS="" du fichier:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static --topology-manager-policy=restricted"
```

Vérifiez la quantité actuelle de mémoire réservée par GKE sur une solution Bare Metal:

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 GKE sur Bare Metal 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 afin de 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 stratégie, consultez la documentation Kubernetes suivante:

Configurer le nœud pour utiliser "hugepages"

Une fois que vous avez activé le gestionnaire de mémoire avec la règle Static, vous pouvez ajouter de très grandes pages pour améliorer davantage les performances des charges de travail de conteneurs sur vos nœuds NUMA. Les très grandes pages, comme leur nom l'indique, vous permettent de spécifier des pages de mémoire d'une taille supérieure à la taille standard de 4 kibioctets (Kio). L'environnement d'exécution de VM sur GDC accepte les énormes pages de 2 mébioctet (Mio) et 1 gibioctet (Gio). Vous pouvez définir "hugepages" pour un nœud au moment de l'exécution ou au démarrage de la machine. Nous vous recommandons de configurer de grandes pages sur chaque nœud sur lequel vous souhaitez exécuter des VM compatibles avec NUMA.

Pour configurer le nombre de bigpages 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 grandes pages à allouer pour la taille spécifiée.
- NUMA_NODE: nœud NUMA, tel que node0, auquel vous allouez des énormespages.
- HUGEPAGE_SIZE: taille des grossespages 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 réglé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, procédez comme suit:

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

Utilisez les paramètres compute suivants pour configurer votre VM pour qu'elle soit compatible avec NUMA:
- spec.compute.guaranteed: définissez guaranteed sur true. Avec ce paramètre, le pod virt-launcher est configuré pour être placé dans la classe de qualité de service (QoS) garantie par Kubernetes.
- spec.compute.advancedCompute:
  - dedicatedCPUPlacement: définissez dedicatedCPUPlacement sur true. Ce paramètre épingle les processeurs virtuels aux processeurs physiques du nœud.
  - hugePageSize: définissez hugePageSize sur 2Mi ou 1Gi pour spécifier la taille de très grandespages que votre VM doit utiliser (2 mébioctet 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 de VirtualMachine suivant montre à quoi pourrait 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
```