Arbeitslasttrennung in GKE konfigurieren

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie Google Kubernetes Engine (GKE) anweisen, Ihre Pods zusammen, separat oder an bestimmten Standorten zu planen.

Die Arbeitslasttrennung ermöglicht die Verwendung von Markierungen und Toleranzen, um GKE anzuweisen, Pods auf verschiedenen Knoten zu trennen, Pods auf Knoten zu platzieren, die bestimmte Kriterien erfüllen, oder um bestimmte Arbeitslasten gemeinsam zu planen. Was Sie zum Konfigurieren der Arbeitslasttrennung tun müssen, hängt von der GKE-Clusterkonfiguration ab. In der folgenden Tabelle werden die Unterschiede beschrieben:

Konfiguration der Arbeitslasttrennung
Autopilot Standard mit automatischer Knotenbereitstellung	Fügen Sie Ihrer Pod-Spezifikation eine Toleranz für ein bestimmtes Schlüssel/Wert-Paar hinzu und wählen Sie dieses Schlüssel/Wert-Paar mit einem nodeSelector aus. GKE erstellt Knoten, wendet die entsprechende Knotenmarkierung an und plant den Pod auf dem Knoten. Eine Anleitung finden Sie unter Arbeitslasten in Autopilot-Clustern trennen auf dieser Seite.
Standard ohne automatische Bereitstellung von Knoten	Knotenpool mit Knotenmarkierung und Knotenlabel erstellen Toleranz für diese Markierung der Pod-Spezifikation hinzufügen Eine Anleitung finden Sie unter Arbeitslasten in dedizierten Knotenpools isolieren. Achtung: Wenn bei dieser Methode vorhandene Markierungen Knoten nicht genügend Ressourcen haben, um einen Pod mit einer Toleranz zu unterstützen, verbleibt der Pod im Status "Ausstehend".

Konfiguration der Arbeitslasttrennung

Autopilot
Standard mit automatischer Knotenbereitstellung

Fügen Sie Ihrer Pod-Spezifikation eine Toleranz für ein bestimmtes Schlüssel/Wert-Paar hinzu und wählen Sie dieses Schlüssel/Wert-Paar mit einem nodeSelector aus. GKE erstellt Knoten, wendet die entsprechende Knotenmarkierung an und plant den Pod auf dem Knoten.

Eine Anleitung finden Sie unter Arbeitslasten in Autopilot-Clustern trennen auf dieser Seite.

Standard ohne automatische Bereitstellung von Knoten

Knotenpool mit Knotenmarkierung und Knotenlabel erstellen
Toleranz für diese Markierung der Pod-Spezifikation hinzufügen

Eine Anleitung finden Sie unter Arbeitslasten in dedizierten Knotenpools isolieren.

In dieser Anleitung wird ein Beispielszenario verwendet, in dem Sie zwei Arbeitslasten, einen Batchjob und einen Webserver haben, die Sie voneinander trennen möchten.

Wann sollte die Arbeitslasttrennung in GKE verwendet werden?

Die Arbeitslasttrennung ist nützlich, wenn Sie Arbeitslasten haben, die unterschiedliche Rollen ausführen und nicht auf denselben zugrunde liegenden Maschinen ausgeführt werden sollen. Im Folgenden sind einige Beispielszenarien aufgeführt:

Sie haben eine Batch-Koordinatorarbeitslast, mit der Jobs erstellt werden, die Sie getrennt halten möchten.
Sie führen einen Gameserver mit einer Arbeitslast für die Partnerzuordnung aus, die Sie von Sitzungs-Pods trennen möchten.
Sie möchten Teile Ihres Stacks voneinander trennen, z. B. um einen Server von einer Datenbank zu trennen.
Sie möchten einige Arbeitslasten aus Compliance- oder Richtliniengründen trennen.

Preise

In Autopilot-Clustern werden Ihnen die Ressourcen in Rechnung gestellt, die von Ihren Pods während der Ausführung angefordert werden. Weitere Informationen finden Sie unter Autopilot-Preise. Für Pods mit Arbeitslasttrennung werden höhere Mindestressourcenanfragen als für reguläre Pods erzwungen.

In Standardclustern erfolgt die Abrechnung auf der Hardwarekonfiguration und -größe der einzelnen Knoten, unabhängig davon, ob Pods auf den Knoten ausgeführt werden. Weitere Informationen finden Sie unter Standardpreise.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Prüfen Sie, ob ein GKE-Cluster ausgeführt wird. Verwenden Sie eine der folgenden Optionen, um zu erfahren, wie Sie einen Cluster erstellen:

Arbeitslasten in Autopilot-Clustern trennen

Wenn Sie Arbeitslasten voneinander trennen möchten, fügen Sie jeder Arbeitslastspezifikation eine Toleranz und einen Knotenselektor hinzu, der den Knoten definiert, auf dem die Arbeitslast ausgeführt werden soll. Diese Methode funktioniert auch auf Standardclustern, für die die automatische Knotenbereitstellung aktiviert ist.

Speichern Sie das folgende Manifest als web-server.yaml:
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 6
  selector:
    matchLabels:
      pod: nginx-pod
  template:
    metadata:
      labels:
        pod: nginx-pod
    spec:
      tolerations:
      - key: group
        operator: Equal
        value: "servers"
        effect: NoSchedule
      nodeSelector:
        group: "servers"
      containers:
      - name: web-server
        image: nginx
```
Dieses Manifest enthält die folgenden Felder:
- spec.tolerations: GKE kann die Pods auf Knoten mit der Markierung group=servers:NoSchedule platzieren. GKE kann keine Pods planen, die diese Toleranz für diese Knoten nicht haben.
- spec.nodeSelector: GKE muss die Pods auf Knoten mit dem Knotenlabel group: servers platzieren.
GKE fügt den Knoten die entsprechenden Labels und Markierungen hinzu, die GKE automatisch zum Ausführen dieser Pods bereitstellt.

Speichern Sie das folgende Manifest als batch-job.yaml:

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  completions: 5
  backoffLimit: 3
  ttlSecondsAfterFinished: 120
  template:
    metadata:
      labels:
        pod: pi-pod
    spec:
      restartPolicy: Never
      tolerations:
      - key: group
        operator: Equal
        value: "jobs"
        effect: NoSchedule
      nodeSelector:
        group: "jobs"
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]

Dieses Manifest enthält die folgenden Felder:

spec.tolerations: GKE kann die Pods auf Knoten mit der Markierung group=jobs:NoSchedule platzieren. GKE kann keine Pods planen, die diese Toleranz für diese Knoten nicht haben.
spec.nodeSelector: GKE muss die Pods auf Knoten mit dem Knotenlabel group: jobs platzieren.

GKE fügt den Knoten die entsprechenden Labels und Markierungen hinzu, die GKE automatisch zum Ausführen dieser Pods bereitstellt.

Stellen Sie die Arbeitslasten bereit:

kubectl apply -f batch-job.yaml web-server.yaml

Wenn Sie die Arbeitslasten bereitstellen, führt GKE für jede Arbeitslast Folgendes aus:

GKE sucht nach vorhandenen Knoten, für die die entsprechende Knotenmarkierung und das entsprechende Knotenlabel im Manifest angegeben sind. Wenn Knoten vorhanden sind und verfügbare Ressourcen haben, plant GKE die Arbeitslast auf dem Knoten.
Wenn GKE keinen geeigneten vorhandenen Knoten zum Planen der Arbeitslast findet, erstellt GKE einen neuen Knoten und wendet die entsprechende Knotenmarkierung und das Knotenlabel basierend auf dem Manifest an. GKE platziert den Pod auf dem neuen Knoten.

Das Vorhandensein des Effekts NoSchedule in der Knotenmarkierung sorgt dafür, dass Arbeitslasten ohne Toleranz nicht auf dem Knoten platziert werden.

Arbeitslasttrennung prüfen

Listen Sie Ihre Pods auf, um die Namen der Knoten zu ermitteln:

kubectl get pods --output=wide

Die Ausgabe sieht in etwa so aus:

NAME                          READY   ...   NODE
batch-job-28j9h               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-78rcn               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-gg4x2               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-qgsxh               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-v4ksf               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
web-server-6bb8cd79b5-dw4ds   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm
web-server-6bb8cd79b5-g5ld6   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-jcdx5   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-pxdzw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-s66rw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-zq8hh   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm

Diese Ausgabe zeigt, dass die batch-job-Pods und die web-server-Pods immer auf verschiedenen Knoten ausgeführt werden.

Einschränkungen der Arbeitslasttrennung mit Markierungen und Toleranzen

Sie können die folgenden Schlüsselpräfixe nicht für die Trennung von Arbeitslasten verwenden:

GKE- und Kubernetes-spezifische Schlüssel
*cloud.google.com/
*kubelet.kubernetes.io/
*node.kubernetes.io/

Sie sollten Ihre eigenen, eindeutigen Schlüssel für die Trennung von Arbeitslasten verwenden.

Arbeitslasten in Standardclustern ohne automatische Knotenbereitstellung trennen

Wenn Sie Arbeitslasten in Standardclustern ohne automatische Knotenbereitstellung trennen möchten, müssen Sie Knotenpools mit den entsprechenden Knotenmarkierungen und Knotenlabels manuell erstellen, um Ihre Arbeitslasten zu berücksichtigen. Eine Anleitung finden Sie unter Arbeitslasten in dedizierten Knotenpools isolieren. Verwenden Sie diesen Ansatz nur, wenn Sie bestimmte Anforderungen haben, die eine manuelle Verwaltung Ihrer Knotenpools erfordern.