Configura le VM NUMA-aware

Questo documento descrive come configurare cluster e VM per supportare un prestazioni e carichi di lavoro a bassa latenza con le efficienze di calcolo accesso non uniforme alla memoria (NUMA). Esistono istruzioni per ottimizzare le impostazioni di Kubernetes per i nodi del cluster. Il presente documento include anche istruzioni per configurando macchine virtuali (VM) con affinità NUMA in modo che vengano pianificate e sfruttare i NUMA nodi.

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

Configurare i nodi per l'utilizzo di NUMA

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

Aggiorna la configurazione di Kubelet

Nell'ambito della configurazione del nodo per supportare l'affinità dei nodi NUMA, devi apporta le seguenti modifiche alla configurazione del kubelet:

  • Attivare Gestione CPU con un criterio static
  • Abilita Gestione memoria con un criterio Static
  • Attivare Gestione della topologia con la topologia restricted

Per configurare kubelet sul nodo worker:

  1. Individua il file kubelet sul tuo nodo di lavoro e aprilo per la modifica:

    edit /etc/default/kubelet
    

    Se non vedi il file kubelet, crealo con questo comando:

    echo "KUBELET_EXTRA_ARGS=\"\"" >> /etc/default/kubelet
    

    Questo comando crea il file kubelet con una sezione KUBELET_EXTRA_ARGS="" vuota.

  2. Per abilitare il Gestore CPU con un criterio static, aggiungi il metodo flag --cpu-manager-policy=static per KUBELET_EXTRA_ARGS="" sezione del file:

    KUBELET_EXTRA_ARGS="--cpu-manager-policy=static"
    
  3. Per abilitare il Gestore memoria con un criterio Static, aggiungi il metodo flag --memory-manager-policy=Static per KUBELET_EXTRA_ARGS="" sezione del file:

    KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static"
    
  4. Per abilitare Topology Manager con un criterio restricted, aggiungi il token flag --topology-manager-policy=restricted per KUBELET_EXTRA_ARGS="" sezione del file:

    KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static --topology-manager-policy=restricted"
    
  5. Controlla la quantità attuale di memoria prenotata da Google Distributed Cloud:

    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 Google Distributed Cloud ha riservato 3.470 mebibyte di memoria sul nodo.

  6. Imposta il flag --reserved-memory nella sezione KUBELET_EXTRA_ARGS del file kubelet su 100 mebibyte in più rispetto alla memoria riservata corrente per tener conto della soglia di espulsione. Se non c'è una memoria riservata, puoi: saltare questo passaggio.

    Ad esempio, con la memoria riservata di 3470Mi dell'esempio nel passaggio precedente, puoi riservare 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"
    
  7. Rimuovi i file dello stato della CPU e della memoria dalla directory /var/lib:

    rm /var/lib/cpu_manager_state
    rm /var/lib/memory_manager_state
    
  8. Riavvia kubelet:

    systemctl start kubelet
    

Per ulteriori informazioni su queste impostazioni dei criteri, consulta le seguenti risorse documentazione di Kubernetes:

Configura il nodo per l'utilizzo di hugepages

Dopo aver abilitato Gestione memoria con il criterio Static, puoi aggiungere enormi pagine per migliorare ulteriormente le prestazioni dei carichi di lavoro dei container sui tuoi nodi NUMA. Le pagine Huge, come suggerisce il nome, consentono di specificare le pagine di memoria più grandi rispetto ai 4 kibibyte (KiB) standard. Il runtime VM su GDC supporta 2 mebibyte (MiB) e 1 gibibyte (GiB) Hugepages. Puoi impostare enormi pagine per un nodo in fase di runtime o in fase di avvio della macchina nodo. Ti consigliamo di configurare Hugepages su ogni nodo su cui vuoi eseguire VM NUMA-aware.

  1. Per configurare il numero di pagine enormi di una dimensione specifica sul nodo NUMA in usa questo comando:

    echo HUGEPAGE_QTY > \
        /sys/devices/system/node/NUMA_NODE/hugepages/hugepages-HUGEPAGE_SIZEkB/nr_hugepages
    

    Sostituisci quanto segue:

    • HUGEPAGE_QTY: il numero di enormi pagine da allocare della dimensione specificata.

    • NUMA_NODE: il nodo NUMA, ad esempio node0, a cui stai allocando le pagine enormi.

    • 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 NUMA-aware sono pianificate su nodi NUMA.

Per creare una VM NUMA-aware:

  1. Segui le istruzioni per creare una VM da un manifest.

    Utilizza le seguenti impostazioni compute per configurare la VM in modo che sia compatibile con NUMA:

    • spec.compute.guaranteed: imposta guaranteed su true. Con questa impostazione, il pod virt-launcher è configurato per essere inserito nella classe di qualità del servizio (QoS) garantita di Kubernetes.

    • spec.compute.advancedCompute:

      • dedicatedCPUPlacement: imposta dedicatedCPUPlacement su true. Questa impostazione blocca le CPU virtuali alle CPU fisiche del nodo.
      • hugePageSize: imposta hugePageSize su 2Mi o 1Gi per specificare la dimensione delle pagine enormi 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 sui nodi NUMA.

    Il seguente esempio di manifest VirtualMachine mostra come una VM NUMA-aware potrebbe avere il seguente aspetto:

    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