Dieses Dokument richtet sich an Anwendungsinhaber und Plattformadministratoren, die Anthos-Cluster auf Bare-Metal ausführen. In diesem Dokument erfahren Sie, wie Sie Planungskonfigurationen wie Affinität und Anti-Affinität für VMs verwenden, die Anthos VM Runtime verwenden.
Hinweis
Um dieses Dokument abzuschließen, benötigen Sie Zugriff auf die folgenden Ressourcen:
- Zugriff auf Anthos-Cluster on Bare Metal Version 1.12.0 (
anthosBareMetalVersion: 1.12.0
) oder höher. Sie können einen beliebigen Clustertyp verwenden, der Arbeitslasten ausführen kann. Bei Bedarf können Sie Anthos-Cluster auf Bare Metal in Compute Engine ausprobieren oder die Übersicht über die Clustererstellung aufrufen. - Das
virtctl
-Clienttool, das als Plug-in fürkubectl
installiert wurde. Installieren Sie bei Bedarf das virtctl-Clienttool.
Planungskonfigurationen – Übersicht
Planungskonfigurationen sind optionale Werte in Anthos VM Runtime. Wenn keine Planungskonfiguration angegeben ist, verwendet die VM standardmäßig das Standard-Planungsverhalten von Kubernetes.
Beim Standard-Planungsverhalten werden VMs auf den Cluster verteilt. Der Planer prüft die aktuelle Verfügbarkeit der Knotenressourcen, wie CPU und Arbeitsspeicher, und plant VMs auf Knoten, um die Rechenanforderungen zu verteilen. Wenn Sie keine spezifischen Anforderungen haben, müssen Sie keine Planungskonfigurationen definieren.
Die folgenden drei Felder sind für die Planung von VMs verfügbar:
nodeSelector
: Gibt Knotenlabels an, die der Hostknoten einer VM haben muss. Anthos VM Runtime plant die VM nur auf den Knoten mit einem bestimmten Label.- Affinität: Gibt die Affinitätsregeln der VM an. Sie umfasst Knotenaffinität und VM-Affinität oder Anti-Affinität. Sie definieren eine weiche oder harte Anforderung für den Planer:
preferredDuringSchedulingIgnoredDuringExecution
: ist eine weiche Anforderung. Der Planer versucht, Ihre Anfrage zu berücksichtigen. Wenn der Planer die Anforderung nicht berücksichtigen kann, wird die VM möglicherweise auf einem nicht bevorzugten Knoten geplant.requiredDuringSchedulingIgnoredDuringExecution
: Ist eine harte Anforderung. Der Planer versucht, Ihre Anfrage zu berücksichtigen. Wenn keine Knoten verfügbar sind, die Ihren Anforderungen entsprechen, wird die VM nicht geplant.
Tolerations
: Ermöglicht, dass die VM auf Knoten mit übereinstimmenden Markierungen geplant wird.
Sie können eine dieser Planungskonfigurationen definieren, um Ihre Rechenarbeitslasten und Planungsanforderungen zu unterstützen. Neben Planungskonfigurationen hängt die VM-Planung von verfügbaren Ressourcen ab.
Anthos VM Runtime verwendet dieselbe VM-Planungslogik und Manifeststruktur wie Kubernetes, um Pods Knoten zuzuweisen. Weitere Informationen zu diesen Planungskonfigurationen finden Sie unter den folgenden Links:
- nodeSelector
- Zielgruppen mit gemeinsamen Interessen und mit gemeinsamen Interessen
- Markierungen und Toleranzen
VMs auf einem bestimmten Knoten platzieren
Wenn Sie Knoten mit bestimmten Hardwarekonfigurationen haben, können Sie VMs so planen, dass sie nur auf diesen Knoten ausgeführt werden. Beispiel: Ihre VM möchte einen bestimmten CPU-Chipsatz oder benötigt GPU-Unterstützung. Mit einem einfachen nodeSelector
oder flexibleren Affinitätsregeln können Sie VMs planen, die auf diesen Knoten ausgeführt werden.
nodeSelector
Das folgende VirtualMachine
-Manifest verwendet einen nodeSelector
für eine harte Planungsanforderung. Wenn kein Knoten verfügbar ist, der die Planungskonfiguration erfüllt, kann die VM nicht geplant werden.
Erstellen Sie im Editor Ihrer Wahl ein
VirtualMachine
-Manifest wie z. B. my-scheduled-vm.yaml.nano my-scheduled-vm.yaml
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachine metadata: name: VM_NAME spec: interfaces: - name: eth0 networkName: pod-network default: true disks: - virtualMachineDiskName: VM_NAME-boot-dv boot: true scheduling: nodeSelector: kubernetes.io/hostname: NODE_NAME
Ersetzen Sie die folgenden Werte:
VM_NAME
ist der Name Ihrer VM.NODE_NAME
: der oder die Knoten, auf denen Sie die VM planen möchten.
Das Bootlaufwerk mit dem Namen
VM_NAME-boot-dv
muss bereits vorhanden sein. Weitere Informationen finden Sie unter VM-Bootlaufwerk erstellen.Speichern und schließen Sie das VM-Manifest in Ihrem Editor.
Erstellen Sie die VM und die Planungskonfiguration mit
kubectl
:kubectl apply -f my-scheduled-vm.yaml
Affinität
Das folgende VirtualMachine
-Manifest verwendet Affinität für eine weiche Planungsanforderung. Der Planer versucht, Ihre Anfrage zu berücksichtigen. Wenn der Planer die Anfrage nicht befolgen kann, wird die VM auf einem nicht bevorzugten Knoten geplant.
Erstellen Sie im Editor Ihrer Wahl ein
VirtualMachine
-Manifest wie z. B. my-scheduled-vm.yaml.nano my-scheduled-vm.yaml
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachine metadata: name: VM_NAME spec: interfaces: - name: eth0 networkName: pod-network default: true disks: - virtualMachineDiskName: VM_NAME-boot-dv boot: true scheduling: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: kubernetes.io/hostname operator: In values: - NODE_NAME
Ersetzen Sie die folgenden Werte:
VM_NAME
ist der Name Ihrer VM.NODE_NAME
: der oder die Knoten, auf denen Sie die VM planen möchten.
Das Bootlaufwerk mit dem Namen
VM_NAME-boot-dv
muss bereits vorhanden sein. Weitere Informationen finden Sie unter VM-Bootlaufwerk erstellen.Speichern und schließen Sie das VM-Manifest in Ihrem Editor.
Erstellen Sie die VM und die Planungskonfiguration mit
kubectl
:kubectl apply -f my-scheduled-vm.yaml
VMs nicht auf einem bestimmten Knoten platzieren
Manche VMs haben möglicherweise Arbeitslasten, die nicht auf einem bestimmten Knoten ausgeführt werden. Sie können Anti-Affinitätsregeln verwenden, um zu vermeiden, dass VMs auf diesen Knoten geplant werden.
Das folgende VirtualMachine
-Manifest verwendet Affinität für eine weiche Planungsanforderung. Der Planer versucht, Ihre Anfrage zu berücksichtigen. Wenn der Planer die Anforderung nicht berücksichtigen kann, wird die VM möglicherweise auf einem unangemessenen Knoten geplant.
Erstellen Sie im Editor Ihrer Wahl ein
VirtualMachine
-Manifest wie z. B. my-scheduled-vm.yaml.nano my-scheduled-vm.yaml
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachine metadata: name: VVM_NAME spec: interfaces: - name: eth0 networkName: pod-network default: true disks: - virtualMachineDiskName: VM_NAME-boot-dv boot: true scheduling: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: kubernetes.io/hostname operator: NotIn values: - NODE_NAME
Ersetzen Sie die folgenden Werte:
VM_NAME
ist der Name Ihrer VM.NODE_NAME
: der Knoten, auf dem Sie die VM planen möchten.
Das Bootlaufwerk mit dem Namen
VM_NAME-boot-dv
muss bereits vorhanden sein. Weitere Informationen finden Sie unter VM-Bootlaufwerk erstellen.Speichern und schließen Sie das VM-Manifest in Ihrem Editor.
Erstellen Sie die VM und die Planungskonfiguration mit
kubectl
:kubectl apply -f my-scheduled-vm.yaml
VMs voneinander getrennt halten
Ihre Computing-Arbeitslasten haben möglicherweise VMs, die für Hochverfügbarkeit auf Knoten verteilt sein sollten, z. B. ein Pool von Front-End-VMs. Sie können Anti-Affinitätsregeln zwischen VMs verwenden, um zu vermeiden, dass VMs gemeinsam auf Knoten geplant werden.
Das folgende VirtualMachine
-Manifest verwendet Affinität für eine weiche Planungsanforderung. Der Planer versucht, Ihre Anfrage zu berücksichtigen. Wenn der Planer die Anforderung nicht berücksichtigen kann, wird die VM möglicherweise auf einem unangemessenen Knoten geplant.
Erstellen Sie im Editor Ihrer Wahl ein
VirtualMachine
-Manifest wie z. B. my-scheduled-vm.yaml.nano my-scheduled-vm.yaml
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachine metadata: name: VM_NAME labels: KEY:VALUE spec: interfaces: - name: eth0 networkName: pod-network default: true disks: - virtualMachineDiskName: VM_NAME-boot-dv boot: true scheduling: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: topologyKey: kubernetes.io/hostname labelSelector: matchLabels: KEY:VALUE
Ersetzen Sie die folgenden Werte:
VM_NAME
ist der Name Ihrer VM.KEY:VALUE
: das Labelkey:value
, das auf Ihre VMs angewendet werden soll, die Sie auf verschiedenen Knoten planen möchten. Weitere Informationen finden Sie unter Labels und Selektoren.
Das Bootlaufwerk mit dem Namen
VM_NAME-boot-dv
muss bereits vorhanden sein. Weitere Informationen finden Sie unter VM-Bootlaufwerk erstellen.Speichern und schließen Sie das VM-Manifest in Ihrem Editor.
Erstellen Sie die VM und die Planungskonfiguration mit
kubectl
:kubectl apply -f my-scheduled-vm.yaml
VMs zusammenhalten
Ihre Rechenarbeitslasten können VMs haben, die auf Knoten zusammen gehalten werden sollten, um die Latenz zu verringern, z. B. eine Middleware- und Datenbankstufe. Sie können Affinitätsregeln zwischen VMs verwenden, um VMs auf Knoten zusammen zu planen.
Das folgende VirtualMachine
-Manifest verwendet Affinität für eine weiche Planungsanforderung. Der Planer versucht, Ihre Anfrage zu berücksichtigen. Wenn der Planer die Anforderung nicht berücksichtigen kann, wird die VM möglicherweise auf einem unangemessenen Knoten geplant.
Erstellen Sie im Editor Ihrer Wahl ein
VirtualMachine
-Manifest wie z. B. my-scheduled-vm.yaml.nano my-scheduled-vm.yaml
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachine metadata: name: VM_NAME labels: KEY:VALUE spec: interfaces: - name: eth0 networkName: pod-network default: true disks: - virtualMachineDiskName: VM_NAME-boot-dv boot: true scheduling: affinity: podAffinity: preferredDuringSchedulingIgnoredDuringExecution - podAffinityTerm: topologyKey: kubernetes.io/hostname labelSelector: matchLabels: KEY:VALUE weight: 100
Ersetzen Sie die folgenden Werte:
VM_NAME
ist der Name Ihrer VM.KEY:VALUE
: das Labelpaarkey:value
, das auf Ihre VMs angewendet werden soll, die Sie auf verschiedenen Knoten planen möchten. Weitere Informationen finden Sie unter Labels und Selektoren.
Das Bootlaufwerk mit dem Namen
VM_NAME-boot-dv
muss bereits vorhanden sein. Weitere Informationen finden Sie unter VM-Bootlaufwerk erstellen.Speichern und schließen Sie das VM-Manifest in Ihrem Editor.
Erstellen Sie die VM und die Planungskonfiguration mit
kubectl
:kubectl apply -f my-scheduled-vm.yaml
VMs auf Knoten mit Markierungen planen
Markierungen sind ein Planungsattribut, mit dem Knoten nur VMs mit bestimmten Toleranzen für die Ausführung zulassen können. Sie können eine Markierung auf einen Knoten anwenden und dann im Manifest VirtualMachine
eine Toleranz definieren, damit die VM auf dem Knoten ausgeführt werden kann. Weitere Informationen finden Sie unter Markierungen und Toleranzen.
Erstellen Sie im Editor Ihrer Wahl ein
VirtualMachine
-Manifest wie z. B. my-scheduled-vm.yaml.nano my-scheduled-vm.yaml
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachine metadata: name: VM_NAME spec: interfaces: - name: eth0 networkName: pod-network default: true disks: - virtualMachineDiskName: VM_NAME-boot-dv boot: true scheduling: tolerations: - key: KEY_NAME operator: "Equal" value: KEY_VALUE effect: "NoSchedule"
Ersetzen Sie die folgenden Werte:
VM_NAME
ist der Name Ihrer VM.KEY_NAME
: der Schlüsselname Ihrer Toleranz, der mit der Markierung auf dem Knoten übereinstimmt.KEY_VALUE
: der Wert des Schlüssels für Ihre Toleranz, der mit der Markierung auf dem Knoten übereinstimmt.
Das Bootlaufwerk mit dem Namen
VM_NAME-boot-dv
muss bereits vorhanden sein. Weitere Informationen finden Sie unter VM-Bootlaufwerk erstellen.Speichern und schließen Sie das VM-Manifest in Ihrem Editor.
Erstellen Sie die VM und die Planungskonfiguration mit
kubectl
:kubectl apply -f my-scheduled-vm.yaml