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

Diese Seite wurde von der Cloud Translation API übersetzt.

NUMA-fähige VMs konfigurieren

In diesem Dokument wird beschrieben, wie Sie Cluster und VMs so konfigurieren, dass sie hohe Leistungs- und niedrige Latenzarbeitslasten mit der Recheneffizienz des Non-Uniform Memory Access (NUMA) unterstützen. Hier finden Sie eine Anleitung zur Abstimmung der Kubernetes-Einstellungen für Clusterknoten. Dieses Dokument enthält auch eine Anleitung zum Konfigurieren von virtuellen Maschinen (VMs) mit NUMA-Affinität, damit diese geplant werden und die NUMA-Knoten nutzen können.

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 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 optimiert, um die CPU- und Arbeitsspeicherleistung zu optimieren. Folgen Sie der Anleitung für jeden Knoten, auf dem Sie NUMA-fähige VMs ausführen möchten.

Kubelet-Konfiguration aktualisieren

Im Rahmen der Knotenkonfiguration zur Unterstützung der NUMA-Knotenaffinität müssen Sie die folgenden Änderungen an der Kubelet-Konfiguration vornehmen:

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

So konfigurieren Sie kubelet auf Ihrem Worker-Knoten:

Suchen Sie die Datei kubelet auf Ihrem Worker-Knoten und öffnen Sie sie zur Bearbeitung:
```
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.
Fügen Sie das Flag --cpu-manager-policy=static in den Abschnitt KUBELET_EXTRA_ARGS="" der Datei ein, um den CPU-Manager mit einer static-Richtlinie zu aktivieren:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static"
```
Wenn Sie Memory Manager mit einer Static-Richtlinie aktivieren möchten, fügen Sie im Abschnitt KUBELET_EXTRA_ARGS="" der Datei das Flag --memory-manager-policy=Static hinzu:
```
KUBELET_EXTRA_ARGS="--cpu-manager-policy=static --memory-manager-policy=Static"
```
Zum Aktivieren von Topology Manager mit einer restricted-Richtlinie 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 die aktuelle Größe des von Google Distributed Cloud reservierten Arbeitsspeichers:

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 Google Distributed Cloud 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 über dem aktuell reservierten Arbeitsspeicher fest, um den Schwellenwert für die Bereinigung 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 riesigen Seiten konfigurieren

Nachdem Sie den Arbeitsspeicher-Manager mit der Richtlinie Static aktiviert haben, können Sie Hugepages hinzufügen, um die Leistung von Containerarbeitslasten auf Ihren NUMA-Knoten weiter zu verbessern. Mit LargePages kannst du, wie der Name schon sagt, 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) riesigen Seiten. Sie können große Seiten für einen Knoten während der Laufzeit oder für den Start der Knotenmaschine festlegen. Es empfiehlt sich, auf jedem Knoten, auf dem NUMA-fähige VMs ausgeführt werden sollen, sehr viele Seiten zu konfigurieren.

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 großen Seiten zuordnen.
- HUGEPAGE_SIZE: die Größe der riesigen 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.

Verwenden Sie die folgenden compute-Einstellungen, um Ihre VM NUMA-fähig zu konfigurieren:
- spec.compute.guaranteed: Legen Sie für guaranteed den Wert true fest. Mit dieser Einstellung wird der Pod virt-launcher so konfiguriert, dass er in die Kubernetes-Klasse „Dienstqualität“ aufgenommen 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 riesigen Seitengröße anzugeben (2 Mebibyte oder 1 Gibibyte).
  - numaGuestMappingPassthrough: Fügen Sie für diese Einstellung eine leere Struktur ({}) hinzu. Diese Einstellung richtet die NUMA-Affinität ein, sodass Ihre VM nur auf NUMA-Knoten geplant wird.
Das folgende VirtualMachine-Beispielmanifest zeigt, wie eine NUMA-fähige 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
```