Dieses Dokument richtet sich an Inhaber von Anwendungen und Plattformadministratoren, die GKE on Bare Metal ausführen. In diesem Dokument erfahren Sie, wie Sie Zeitplankonfigurationen wie Affinität und Anti-Affinität für VMs verwenden, die die VM-Laufzeit in Google Distributed Cloud verwenden.
Hinweise
Um dieses Dokument abzuschließen, benötigen Sie Zugriff auf die folgenden Ressourcen:
- Zugriff auf Cluster von GKE on Bare Metal ab Version 1.12.0 (
anthosBareMetalVersion: 1.12.0
). Sie können einen beliebigen Clustertyp verwenden, der Arbeitslasten ausführen kann. Testen Sie bei Bedarf GKE on Bare Metal in Compute Engine oder lesen Sie die Übersicht über die Clustererstellung. - Das
virtctl
-Clienttool, das als Plug-in fürkubectl
installiert wurde. Installieren Sie bei Bedarf das virtctl-Clienttool.
Planungskonfigurationen – Übersicht
Zeitplankonfigurationen sind optionale Werte in der VM-Laufzeit in Google Distributed Cloud. 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. Die VM-Laufzeit in Google Distributed Cloud plant die VM nur auf den Knoten, die ein angegebenes Label haben.- 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.
Die VM-Laufzeit in Google Distributed Cloud verwendet dieselbe VM-Planungslogik und Manifeststruktur wie Kubernetes, um Pods zu Knoten zuzuweisen. Weitere Informationen zu diesen Planungskonfigurationen finden Sie unter den folgenden Links:
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 Frontend-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