L'architecture NUMA (Non-Uniform Memory Access) vous permet de prendre en charge des charges de travail hautes performances et à faible latence sur des clusters et des machines virtuelles (VM). Le réglage des paramètres Kubernetes sur les nœuds de cluster et la configuration des VM avec une affinité NUMA permettent de s'assurer que les charges de travail sont planifiées directement sur les nœuds NUMA.
Dans une VM compatible NUMA, toutes les communications restent locales au nœud NUMA. Cette architecture empêche les transferts de données à distance qui peuvent dégrader les performances.
Configurer les nœuds pour utiliser NUMA
Les sections suivantes expliquent comment configurer les composants Kubernetes critiques pour régler le nœud et s'assurer qu'il peut planifier 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 de kubelet
Dans le cadre de la configuration des nœuds 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 la topologie
restricted
Pour configurer kubelet sur votre nœud de calcul :
Recherchez le fichier
kubeletsur votre nœud de calcul et ouvrez-le pour le modifier :edit /etc/default/kubeletSi vous ne voyez pas le fichier
kubelet, créez-le à l'aide de la commande suivante :echo "KUBELET_EXTRA_ARGS=\"\"" >> /etc/default/kubeletCette commande crée le fichier
kubeletavec une sectionKUBELET_EXTRA_ARGS=""vide.Pour activer le gestionnaire de processeur avec une règle
static, ajoutez l'option--cpu-manager-policy=staticà la sectionKUBELET_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 sectionKUBELET_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 sectionKUBELET_EXTRA_ARGS=""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.envLe 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=3470Miindique que Google Distributed Cloud a réservé 3 470 mébioctets de mémoire sur le nœud.Définissez l'option
--reserved-memorydans la sectionKUBELET_EXTRA_ARGSdu fichierkubeletsur 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
3470Mide l'exemple de l'étape précédente, vous réservez3570Mide mémoire dans le fichierkubelet: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_stateRedémarrez kubelet :
systemctl start kubelet
Pour en savoir plus sur ces paramètres de stratégie, consultez la documentation Kubernetes suivante :
- Règles de gestion du processeur
- Configuration du gestionnaire de mémoire
- Règle limitée du gestionnaire de topologie
Configurer le nœud pour utiliser des "hugepages"
Une fois que vous avez activé Memory Manager avec la règle Static, vous pouvez ajouter des pages "hugepages" pour améliorer davantage les performances des charges de travail des conteneurs sur vos nœuds NUMA.
Comme leur nom l'indique, les hugepages vous permettent de spécifier des pages de mémoire plus volumineuses que la taille standard de 4 kibioctets (Kio). L'environnement d'exécution de VM sur GDC est compatible avec les pages "hugepages" de 2 mébioctets (Mio) et de 1 gibioctet (Gio). Vous pouvez définir des pages volumineuses 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_hugepagesRemplacez les éléments suivants :
HUGEPAGE_QTY: nombre de "hugepages" à allouer de la taille spécifiée.NUMA_NODE: nœud NUMA, tel quenode0, auquel vous allouez des pages volumineuses.HUGEPAGE_SIZE: taille des hugepages en kibioctets,2048(2 Mio) ou1048576(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 NUMA :
Suivez les instructions pour créer une VM à partir d'un fichier manifeste.
Utilisez les paramètres
computesuivants pour configurer votre VM afin qu'elle soit compatible avec NUMA :spec.compute.guaranteed: définissezguaranteedsurtrue. Avec ce paramètre, le podvirt-launcherest configuré pour être placé dans la classe de qualité de service (QoS) garantie de Kubernetes.spec.compute.advancedCompute:dedicatedCPUPlacement: définissezdedicatedCPUPlacementsurtrue. Ce paramètre associe les processeurs virtuels aux processeurs physiques du nœud.hugePageSize: définissezhugePageSizesur2Miou1Gipour spécifier la taille des pages volumineuses 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 l'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