Versione 1.15. Questa versione non è più supportata. Per informazioni su come eseguire l'upgrade alla versione 1.16, vedi Eseguire l'upgrade dei cluster nella documentazione più recente. Per ulteriori informazioni sulle versioni supportate e non supportate, consulta la pagina Cronologia delle versioni nella documentazione più recente.

Configura la pianificazione delle VM con riconoscimento NUMA

Questo documento descrive come configurare cluster e VM per supportare carichi di lavoro ad alte prestazioni e a bassa latenza con le efficienze di calcolo dell'accesso alla memoria non uniforme (NUMA). Esistono istruzioni per l'ottimizzazione delle impostazioni di Kubernetes per i nodi cluster. Questo documento include anche le istruzioni per configurare le macchine virtuali (VM) con l'affinità NUMA in modo che vengano pianificate e che sfruttino i nodi NUMA.

Con una VM sensibile a NUMA, tutte le comunicazioni all'interno della VM sono locali rispetto al nodo NUMA. La VM sensibile a NUMA evita le transazioni di dati da e verso le risorse remote che possono ridurre le prestazioni delle VM.

Configura i nodi per l'utilizzo di NUMA

Le seguenti sezioni descrivono come configurare i componenti critici di Kubernetes per ottimizzare il nodo e assicurarsi che possa pianificare container NUMA-aware. Questi NUMA nodi sono ottimizzati per ottimizzare le prestazioni di CPU e memoria. Segui le istruzioni per ciascun nodo in cui vuoi eseguire VM compatibili con NUMA.

Aggiorna la configurazione kubelet

Come parte della configurazione dei nodi per supportare l'affinità dei nodi NUMA, devi apportare le seguenti modifiche alla configurazione kubelet:

Abilita gestore CPU con un criterio static
Attiva Gestione memoria con un criterio Static
Attiva gestore di topologia con topologia restricted

Per configurare kubelet sul tuo nodo worker:

Individua il file kubelet sul tuo nodo worker e aprilo per la modifica:
```
edit /etc/default/kubelet
```
Se non vedi il file kubelet, crealo con il seguente comando:
```
echo "KUBELET_EXTRA_ARGS=\"\"" >> /etc/default/kubelet
```
Questo comando crea il file kubelet con una sezione KUBELET_EXTRA_ARGS="" vuota.
Per abilitare il gestore CPU con un criterio static, aggiungi il flag --cpu-manager-policy=static alla sezione KUBELET_EXTRA_ARGS="" del file:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static"
```
Per abilitare Gestione memoria con un criterio Static, aggiungi il flag --memory-manager-policy=Static alla sezione KUBELET_EXTRA_ARGS="" del file:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static"
```
Per abilitare Topology Manager con un criterio restricted, aggiungi il flag --topology-manager-policy=restricted alla sezione KUBELET_EXTRA_ARGS="" del file:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static --topology-manager-policy=restricted"
```

Controlla la quantità attuale di memoria prenotata da GKE su Bare Metal:

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

L'output dovrebbe essere simile al seguente:

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"

L'impostazione --kube-reserved=cpu=100m,memory=3470Mi indica che GKE su Bare Metal ha riservato 3470 mebibyte di memoria sul nodo.

Imposta il flag --reserved-memory nella sezione KUBELET_EXTRA_ARGS del file kubelet su 100 mebibyte in più rispetto alla memoria attualmente prenotata per tenere conto della soglia di rimozione. Se non è presente memoria riservata, puoi saltare questo passaggio.

Ad esempio, con la memoria riservata di 3470Mi dell'esempio nel passaggio precedente, prenoti 3570Mi di memoria nel file kubelet:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static --topology-manager-policy=restricted --reserved-memory=0:memory=3570Mi"
```
Rimuovi i file di stato della CPU e della memoria dalla directory /var/lib:
```
rm /var/lib/cpu_manager_state
rm /var/lib/memory_manager_state
```
Riavvia kubelet:
```
systemctl start kubelet
```

Per ulteriori informazioni su queste impostazioni dei criteri, consulta la seguente documentazione relativa a Kubernetes:

Configura il nodo per l'uso di pagine giganti

Dopo aver abilitato Gestore della memoria con il criterio Static, puoi aggiungere pagine giganti per migliorare ulteriormente le prestazioni dei carichi di lavoro dei container sui nodi NUMA. Giantpages, come suggerisce il nome, ti consente di specificare pagine di memoria più grandi rispetto ai 4 kibibyte (KiB) standard. Il runtime VM su GDC supporta enormi pagine da 2 mebibyte (MiB) e 1 gibibyte (GiB). Puoi impostare pagine giganti per un nodo in fase di runtime o per l'avvio della macchina. Ti consigliamo di configurare pagine giganti su ciascun nodo in cui vuoi eseguire VM con riconoscimento NUMA.

Per configurare il numero di pagine enormi di una dimensione specifica sul nodo NUMA in fase di runtime, utilizza il seguente comando:
```
echo HUGEPAGE_QTY > \
    /sys/devices/system/node/NUMA_NODE/hugepages/hugepages-HUGEPAGE_SIZEkB/nr_hugepages
```
Sostituisci quanto segue:
- HUGEPAGE_QTY: il numero di pagine giganti da allocare delle dimensioni specificate.
- NUMA_NODE: il nodo NUMA, ad esempio node0, a cui stai assegnando le pagine giganti.
- HUGEPAGE_SIZE: la dimensione delle pagine enormi in kibibyte, 2048 (2 MiB) o1048576 (1 GiB).

Configura una VM per utilizzare il nodo NUMA

Dopo che i nodi del cluster sono ottimizzati per NUMA, puoi creare VM sensibili a NUMA. Le VM sensibili a NUMA sono pianificate su NUMA nodi.

Per creare una VM con riconoscimento NUMA:

Segui le istruzioni per creare una VM da un manifest.

Utilizza le seguenti impostazioni di compute per configurare la VM in modo che sia sensibile a NUMA:
- spec.compute.guaranteed: imposta guaranteed su true. Con questa impostazione, il pod virt-launcher è configurato per essere inserito nella classe QoS (Qualità del servizio) garantita da Kubernetes.
- spec.compute.advancedCompute:
  - dedicatedCPUPlacement: imposta dedicatedCPUPlacement su true. Questa impostazione fissa le CPU virtuali alle CPU fisiche del nodo.
  - hugePageSize: imposta hugePageSize su 2Mi o 1Gi per specificare le dimensioni enormi delle pagine da utilizzare per la VM, 2 mebibyte o 1 gibibyte.
  - numaGuestMappingPassthrough: includi una struttura vuota ({}) per questa impostazione. Questa impostazione stabilisce l'affinità NUMA in modo che la VM venga pianificata solo su nodi NUMA.
Il seguente manifest VirtualMachine di esempio mostra l'aspetto di una configurazione VM con riconoscimento 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
```