VMs planen, die VM-Laufzeit in GDC verwenden

Dieses Dokument richtet sich an Anwendungsinhaber 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 auf GDC verwenden.

Hinweise

Um dieses Dokument abzuschließen, benötigen Sie Zugriff auf die folgenden Ressourcen:

Zugriff auf den Cluster GKE 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. Versuchen Sie es bei Bedarf mit GDCV für Bare Metal in Compute Engine oder sehen Sie sich die Übersicht über die Clustererstellung an.
Das virtctl-Clienttool, das als Plug-in für kubectl installiert wurde. Installieren Sie bei Bedarf das virtctl-Clienttool.

Planungskonfigurationen – Übersicht

Zeitplankonfigurationen sind optionale Werte in der VM-Laufzeit auf GDC. 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. Von der VM-Laufzeit auf GDC wird die VM nur für Knoten mit einem angegebenen Label geplant.
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 auf GDC 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 Label key: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.

Hinweis: Legen Sie für eine harte Planungsanforderung requiredDuringSchedulingIgnoredDuringExecution anstelle von preferredDuringSchedulingIgnoredDuringExecution fest.
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 Labelpaar key: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.

Hinweis: Legen Sie für eine harte Planungsanforderung requiredDuringSchedulingIgnoredDuringExecution anstelle von preferredDuringSchedulingIgnoredDuringExecution fest.
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
```

Nächste Schritte

VM in GDCV für Bare Metal bearbeiten