Anthos Clusters on Bare Metal sind jetzt Google Distributed Cloud (nur Software) für Bare Metal. Weitere Informationen finden Sie in der Produktübersicht.

NUMA-sensitive VMs konfigurieren

In diesem Dokument wird beschrieben, wie Sie Cluster und VMs so konfigurieren, dass Arbeitslasten mit hoher Leistung und niedriger Latenz mit der Recheneffizienz des uneinheitlichen Arbeitsspeicherzugriffs (NUMA) unterstützt werden. Dort finden Sie Anleitungen zum Anpassen der Kubernetes-Einstellungen für Clusterknoten. Dieses Dokument enthält auch eine Anleitung zum Konfigurieren von virtuellen Maschinen (VMs) mit NUMA-Affinität, damit sie geplant werden und die NUMA-Knoten nutzen.

Bei einer NUMA-fähigen VM erfolgt die gesamte Kommunikation innerhalb der VM lokal auf dem NUMA-Knoten. Die NUMA-sensitive VM vermeidet Datentransaktionen zu und von Remote-Ressourcen, die die VM-Leistung beeinträchtigen können.

Knoten für die Verwendung von NUMA konfigurieren

In den folgenden Abschnitten wird beschrieben, wie Sie die wichtigen Kubernetes-Komponenten konfigurieren, um den Knoten zu optimieren und dafür zu sorgen, dass NUMA-fähige Container geplant werden können. Diese NUMA Knoten sind auf die Optimierung der CPU- und Arbeitsspeicherleistung abgestimmt. Folgen Sie der Anleitung für jeden Knoten, auf dem Sie NUMA-fähige VMs ausführen möchten.

Kubelet-Konfiguration aktualisieren

Nehmen Sie im Rahmen der Knotenkonfiguration zur Unterstützung der NUMA-Knotenaffinität folgende Änderungen an der Kubelet-Konfiguration vor:

CPU-Manager mit einer static-Richtlinie aktivieren
Speichermanager mit einer Static-Richtlinie aktivieren
Topologiemanager mit Topologie restricted aktivieren

So konfigurieren Sie kubelet auf Ihrem Worker-Knoten:

Suchen Sie die Datei kubelet auf Ihrem Worker-Knoten und öffnen Sie sie zum Bearbeiten:
```
edit /etc/default/kubelet
```
Wenn die Datei kubelet nicht angezeigt wird, erstellen Sie sie mit dem folgenden Befehl:
```
echo "KUBELET_EXTRA_ARGS=\"\"" >> /etc/default/kubelet
```
Mit diesem Befehl wird die Datei kubelet mit einem leeren Abschnitt KUBELET_EXTRA_ARGS="" erstellt.
Zum Aktivieren von CPU Manager mit der Richtlinie static fügen Sie dem Abschnitt KUBELET_EXTRA_ARGS="" der Datei das Flag --cpu-manager-policy=static hinzu:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static"
```
Zum Aktivieren des Arbeitsspeicher-Managers mit einer Static-Richtlinie fügen Sie das Flag --memory-manager-policy=Static im Abschnitt KUBELET_EXTRA_ARGS="" der Datei hinzu:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static"
```
Zum Aktivieren von Topologiemanager mit einer Richtlinie restricted fügen Sie im Abschnitt KUBELET_EXTRA_ARGS="" der Datei das Flag --topology-manager-policy=restricted hinzu:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static --topology-manager-policy=restricted"
```

Prüfen Sie, wie viel Arbeitsspeicher aktuell von GKE on Bare Metal reserviert ist:

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

Die Ausgabe sollte so aussehen:

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"

Die Einstellung --kube-reserved=cpu=100m,memory=3470Mi gibt an,dass GKE on Bare Metal 3.470 Mebibyte Arbeitsspeicher auf dem Knoten reserviert hat.

Legen Sie das Flag --reserved-memory im Abschnitt KUBELET_EXTRA_ARGS der Datei kubelet auf 100 Mebibyte mehr als den aktuell reservierten Arbeitsspeicher fest, um den Bereinigungsschwellenwert zu berücksichtigen. Wenn kein reservierter Arbeitsspeicher vorhanden ist, können Sie diesen Schritt überspringen.

Mit dem reservierten Arbeitsspeicher von 3470Mi aus dem Beispiel im vorherigen Schritt reservieren Sie beispielsweise 3570Mi Arbeitsspeicher in der Datei kubelet:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static --topology-manager-policy=restricted --reserved-memory=0:memory=3570Mi"
```
Entfernen Sie CPU- und Arbeitsspeicherstatusdateien aus dem Verzeichnis /var/lib:
```
rm /var/lib/cpu_manager_state
rm /var/lib/memory_manager_state
```
Starten Sie Kubelet neu:
```
systemctl start kubelet
```

Weitere Informationen zu diesen Richtlinieneinstellungen finden Sie in der folgenden Kubernetes-Dokumentation:

Knoten für die Verwendung von großen Seiten konfigurieren

Nachdem Sie den Arbeitsspeicher-Manager mit der Richtlinie Static aktiviert haben, können Sie hugepages hinzufügen, um die Leistung der Containerarbeitslast auf Ihren NUMA-Knoten weiter zu verbessern. Mit Giantpages können Sie Speicherseiten angeben, die größer als die standardmäßigen 4 Kibibyte (KiB) sind. Die VM-Laufzeit auf GDC unterstützt 2 Mebibyte (MiB) und 1 Gibibyte (GiB) Seiten. Sie können VAST-Pages für einen Knoten zur Laufzeit oder für das Booten der Knotenmaschine festlegen. Wir empfehlen, hugepages auf jedem Knoten zu konfigurieren, auf dem Sie NUMA-fähige VMs ausführen möchten.

Verwenden Sie den folgenden Befehl, um die Anzahl der großen Seiten einer bestimmten Größe auf Ihrem NUMA-Knoten zur Laufzeit zu konfigurieren:
```
echo HUGEPAGE_QTY > \
    /sys/devices/system/node/NUMA_NODE/hugepages/hugepages-HUGEPAGE_SIZEkB/nr_hugepages
```
Ersetzen Sie Folgendes:
- HUGEPAGE_QTY: die Anzahl von riesigen Seiten, die der angegebenen Größe zugewiesen werden sollen.
- NUMA_NODE: der NUMA-Knoten, z. B. node0, dem Sie riesigen Seiten zuordnen.
- HUGEPAGE_SIZE: die Größe der großen Seiten in Kibibyte, 2048 (2 MiB) oder 1048576 (1 GiB).

VM für die Verwendung des NUMA-Knotens konfigurieren

Sobald Ihre Clusterknoten auf NUMA abgestimmt sind, können Sie NUMA-fähige VMs erstellen. NUMA-berechtigte VMs werden auf NUMA Knoten geplant.

So erstellen Sie eine NUMA-sensitive VM:

Folgen Sie der Anleitung zum Erstellen einer VM aus einem Manifest.

Konfigurieren Sie Ihre VM mit den folgenden compute-Einstellungen so, dass sie NUMA-fähig ist:
- spec.compute.guaranteed: Setzen Sie guaranteed auf true. Mit dieser Einstellung wird der Pod virt-launcher so konfiguriert, dass er in die Dienstqualitätsklasse von Kubernetes garantiert wird.
- spec.compute.advancedCompute:
  - dedicatedCPUPlacement: Setzen Sie dedicatedCPUPlacement auf true. Mit dieser Einstellung werden virtuelle CPUs an die physischen CPUs des Knotens angepinnt.
  - hugePageSize: Legen Sie für hugePageSize entweder 2Mi oder 1Gi fest, um die zu verwendende enorme Seitengröße für Ihre VM anzugeben, also 2 Mebibyte oder 1 Gibibyte.
  - numaGuestMappingPassthrough: Fügen Sie für diese Einstellung eine leere Struktur ({}) ein. Mit dieser Einstellung wird die NUMA-Affinität eingerichtet, sodass Ihre VM nur auf NUMA-Knoten geplant wird.
Das folgende VirtualMachine-Manifestbeispiel zeigt, wie eine NUMA-sensitive VM-Konfiguration aussehen könnte:
```
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
```