Version 1.14. This version is no longer supported. For information about how to upgrade to version 1.15, see Upgrading Anthos on bare metal in the 1.15 documentation. For more information about supported and unsupported versions, see the Version history page in the latest documentation.

NUMA-fähige VM-Planung konfigurieren

In diesem Dokument wird beschrieben, wie Cluster und VMs konfiguriert werden, um Arbeitslasten mit hoher Leistung und niedriger Latenz mit der Recheneffizienz des ungleichmäßigen Arbeitsspeicherzugriffs (NUMA) zu unterstützen. Dort finden Sie auch 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 zum NUMA-Knoten. Die NUMA-fähige VM vermeidet Datentransaktionen zu und von Remoteressourcen, 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 kritischen 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 optimiert, um die CPU- und Arbeitsspeicherleistung zu optimieren. Folgen Sie der Anleitung für jeden Knoten, auf dem NUMA-fähige VMs ausgeführt werden sollen.

Kubelet-Konfiguration aktualisieren

Nehmen Sie im Rahmen der Knotenkonfiguration zur Unterstützung der NUMA-Knotenaffinität die folgenden Änderungen in 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 KUBELET_EXTRA_ARGS=""-Abschnitt erstellt.
Zum Aktivieren des CPU-Managers mit einer 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 dem 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 den aktuell von GKE on Bare Metal reservierten Arbeitsspeicher:

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 Bereinigungsgrenzwert 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 riesige Seiten hinzufügen, um die Leistung von Containerarbeitslasten 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 in Google Distributed Cloud unterstützt 2 Mebibyte (MiB) und 1 Gibibyte (GiB) große Seiten. Sie können enormpages für einen Knoten zur Laufzeit oder für den Start der Knotenmaschine festlegen. Wir empfehlen, dass Sie hugepages auf jedem Knoten konfigurieren, auf dem NUMA-fähige VMs ausgeführt werden sollen.

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 der riesigen Seiten, die der angegebenen Größe zugewiesen werden sollen.
- NUMA_NODE: der NUMA-Knoten, z. B. node0, dem Sie enorme Seiten zuweisen.
- 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-fähige VMs werden auf NUMA-Knoten geplant.

So erstellen Sie eine NUMA-fähige 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: Setze guaranteed auf true. Mit dieser Einstellung ist der virt-launcher-Pod so konfiguriert, dass er in die Dienstqualitätsklasse (Quality of Service, QoS) von Kubernetes garantiert wird.
- spec.compute.advancedCompute:
  - dedicatedCPUPlacement: Setzen Sie dedicatedCPUPlacement auf true. Durch diese Einstellung werden virtuelle CPUs den physischen CPUs des Knotens zugewiesen.
  - hugePageSize: Legen Sie für hugePageSize entweder 2Mi oder 1Gi fest, um die zu verwendende Größe von Seiten wie 2 Mebibyte oder 1 Gibibyte anzugeben.
  - numaGuestMappingPassthrough: Fügen Sie für diese Einstellung eine leere Struktur ({}) ein. Diese Einstellung richtet die NUMA-Affinität ein, sodass Ihre VM nur auf NUMA-Knoten geplant wird.
Das folgende Beispiel für ein VirtualMachine-Manifest 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
```