Jobwarteschlangensystem mit Kontingentfreigabe zwischen Namespaces in GKE implementieren

In dieser Anleitung wird Kueue verwendet, um Ihnen zu zeigen, wie Sie ein Job-Warteschlangensystem implementieren, die Arbeitslastressource und die Kontingentfreigabe zwischen verschiedenen Namespaces in Google Kubernetes Engine (GKE) konfigurieren und die Nutzung Ihres Clusters maximieren können.

Hintergrund

Als Infrastrukturentwickler oder Clusteradministrator ist es sehr wichtig, die Auslastung zwischen Namespaces zu maximieren. Ein Batch von Jobs in einem Namespace nutzt möglicherweise nicht vollständig das dem Namespace zugewiesene vollständige Kontingent, während ein anderer Namespace mehrere ausstehende Jobs haben kann. Sie können Kohorten in Kueue konfigurieren, um die Clusterressourcen zwischen Jobs in verschiedenen Namespaces effizient zu nutzen und die Flexibilität der Kontingentverwaltung zu erhöhen. Eine Kohorte ist eine Gruppe von ClusterQueues, die nicht genutztes Kontingent mieten können. Eine ClusterQueue steuert einen Pool von Ressourcen wie CPU, Arbeitsspeicher und Hardwarebeschleunigern.

Eine ausführlichere Definition aller dieser Konzepte finden Sie in der Kueue-Dokumentation.

Ziele

Diese Anleitung richtet sich an Infrastrukturentwickler oder Clusteradministratoren, die ein Jobwarteschlangensystem in Kubernetes mithilfe von Kueue mit Kontingentfreigabe implementieren möchten.

In dieser Anleitung werden zwei Teams in zwei verschiedenen Namespaces nachahmt, wobei jedes Team seine eigenen Ressourcen hat, aber sich gegenseitig nutzen kann. Ein dritter Satz von Ressourcen kann als Spillover verwendet werden, wenn sich Jobs ansammeln.

Verwenden Sie den Prometheus-Operator, um Jobs und Ressourcenzuweisung in verschiedenen Namespaces zu überwachen.

Diese Anleitung umfasst die folgenden Schritte:

  1. GKE-Cluster erstellen
  2. ResourceFlavors erstellen
  3. Erstellen Sie für jedes Team eine ClusterQueue und eine LocalQueue.
  4. (Optional) kube-prometheus bereitstellen und Arbeitslasten mit Prometheus überwachen
  5. Jobs erstellen und zugelassene Arbeitslasten beobachten
  6. Nicht verwendetes Kontingent mit Kohorten nutzen
  7. Eine Spillover-ClusterQueue zur Steuerung von Spot-VMs hinzufügen

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

Mit unserem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung erstellen.

Nach Abschluss dieser Anleitung können Sie weitere Kosten durch Löschen von erstellten Ressourcen vermeiden. Weitere Informationen finden Sie unter Bereinigen.

Vorbereitung

Projekt einrichten

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Enable the GKE API.

    Enable the API

    5.

  5. In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

    Go to project selector

  6. Make sure that billing is enabled for your Google Cloud project.

  7. Enable the GKE API.

    Enable the API

    8.

Standardeinstellungen für die Google Cloud CLI festlegen

  1. Starten Sie in der Google Cloud Console eine Cloud Shell-Instanz:
    Cloud Shell öffnen

  2. Laden Sie den Quellcode für diese Beispielanwendung herunter:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

  3. Legen Sie die Standardumgebungsvariablen fest:

    gcloud config set project PROJECT_ID
gcloud config set compute/region COMPUTE_REGION

    Ersetzen Sie die folgenden Werte:

GKE-Cluster erstellen

  1. Erstellen Sie einen GKE-Cluster mit dem Namen kueue-cohort:

    Sie erstellen einen Cluster mit 6 Knoten (2 pro Zone) im Standardpool und ohne Autoscaling. Das sind anfangs alle Ressourcen, die den Teams zur Verfügung stehen. Daher müssen sie um sie konkurrieren.

    Sie werden später sehen, wie Kueue die Arbeitslasten verwaltet, die beide Teams an die entsprechenden Warteschlangen senden.

      gcloud container clusters create kueue-cohort --region COMPUTE_REGION \
  --release-channel rapid --machine-type e2-standard-4 --num-nodes 2

    Das Ergebnis sieht nach der Erstellung des Clusters in etwa so aus:

      kubeconfig entry generated for kueue-cohort.
  NAME: kueue-cohort
  LOCATION: us-central1
  MASTER_VERSION: 1.26.2-gke.1000
  MASTER_IP: 35.224.108.58
  MACHINE_TYPE: e2-medium
  NODE_VERSION: 1.26.2-gke.1000
  NUM_NODES: 6
  STATUS: RUNNING

    Dabei ist STATUS gleich RUNNING für den kueue-cluster.

  2. Erstellen Sie einen Knotenpool mit dem Namen spot.

    Dieser Knotenpool verwendet Spot-VM und aktiviertes Autoscaling. Er beginnt mit 0 Knoten, aber später stellen Sie ihn den Teams zur Nutzung als Überlaufkapazität zur Verfügung.

    gcloud container node-pools create spot --cluster=kueue-cohort --region COMPUTE_REGION  \
--spot --enable-autoscaling --max-nodes 20 --num-nodes 0 \
--machine-type e2-standard-4

  3. Installieren Sie die Releaseversion von Kueue im Cluster:

    VERSION=VERSION
kubectl apply -f \
  https://github.com/kubernetes-sigs/kueue/releases/download/$VERSION/manifests.yaml

    Ersetzen Sie VERSION durch den Buchstaben v nach der neuesten Version von Kueue, z. B. v0.4.0. Weitere Informationen zu Kueue-Versionen finden Sie unter Kueue-Releases.

    Warten Sie, bis der Kueue-Controller bereit ist:

    watch kubectl -n kueue-system get pods

    Die Ausgabe sollte in etwa so aussehen, bevor Sie fortfahren können:

    NAME                                        READY   STATUS    RESTARTS   AGE
kueue-controller-manager-6cfcbb5dc5-rsf8k   2/2     Running   0          3m

  4. Erstellen Sie zwei neue Namespaces mit den Namen team-a und team-b:

    kubectl create namespace team-a
kubectl create namespace team-b

    Jobs werden in jedem Namespace generiert.

ResourceFlavors erstellen

Ein ResourceFlavor stellt Ressourcenvarianten in Ihren Clusterknoten dar, z. B. verschiedene VMs (z. B. Spot im Vergleich zu On-Demand), Architekturen (z. B. x86 im Vergleich zu ARM-CPUs), Marken und Modelle (z.B. Nvidia A100 im Vergleich zu T4 GPUs).

ResourceFlavors verwenden Knotenlabels und Markierungen, um sie mit einer Reihe von Knoten im Cluster abzugleichen.

apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: on-demand # This ResourceFlavor will be used for the CPU resource
spec:
  nodeLabels:
    cloud.google.com/gke-provisioning: standard # This label was applied automatically by GKE
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: spot # This ResourceFlavor will be used as added resource for the CPU resource
spec:
  nodeLabels:  
    cloud.google.com/gke-provisioning: spot # This label was applied automatically by GKE

In diesem Manifest:

  • Das ResourceFlavor on-demand hat das Label cloud.google.com/gke-provisioning: standard.
  • Das ResourceFlavor spot hat das Label cloud.google.com/gke-provisioning: spot.

Wenn einer Arbeitslast ein ResourceFlavor zugewiesen wird, weist Kueue den Pods der Arbeitslast Knoten zu, die den für das ResourceFlavor definierten Knotenlabels entsprechen.

Stellen Sie das ResourceFlavor bereit:

kubectl apply -f flavors.yaml

ClusterQueue und LocalQueue erstellen

Erstellen Sie die zwei ClusterQueues cq-team-a und cq-team-b sowie die zugehörigen LocalQueues lq-team-a und lq-team-b mit dem Namespace team-a und team-b.

ClusterQueues sind clusterbezogene Objekte, die einen Pool von Ressourcen wie CPU, Arbeitsspeicher und Hardwarebeschleuniger steuern. Batch-Administratoren können die Sichtbarkeit dieser Objekte auf Batch-Nutzer beschränken.

LocalQueues sind Namespace-Objekte, die Batch-Nutzer auflisten können. Sie verweisen auf ClusterQueues, aus denen Ressourcen zum Ausführen der LocalQueue-Arbeitslasten zugewiesen werden.

apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: cq-team-a
spec:
  cohort: all-teams # cq-team-a and cq-team-b share the same cohort
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: team-a #Only team-a can submit jobs direclty to this queue, but will be able to share it through the cohort
  resourceGroups:
  - coveredResources: ["cpu", "memory"]
    flavors:
    - name: on-demand
      resources:
      - name: "cpu"
        nominalQuota: 10
        borrowingLimit: 5
      - name: "memory"
        nominalQuota: 10Gi
        borrowingLimit: 15Gi
    - name: spot # This ClusterQueue doesn't have nominalQuota for spot, but it can borrow from others
      resources:
      - name: "cpu"
        nominalQuota: 0
      - name: "memory"
        nominalQuota: 0
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  namespace: team-a # LocalQueue under team-a namespace
  name: lq-team-a
spec:
  clusterQueue: cq-team-a # Point to the ClusterQueue team-a-cq

ClusterQueues ermöglichen es Ressourcen, mehrere Flavors zu erhalten. In diesem Fall haben beide ClusterQueues zwei Flavors, on-demand und spot, die jeweils cpu-Ressourcen bereitstellen. Das Kontingent von ResourceFlavor spot ist auf 0 festgelegt und wird vorerst nicht verwendet.

Beide ClusterQueues haben die gleiche Kohorte namens all-teams, definiert in .spec.cohort. Wenn zwei oder mehr ClusterQueues dieselbe Kohorte teilen, können sie sich ungenutzte Kontingente gegenseitig ausgleichen.

Weitere Informationen zur Funktionsweise von Kohorten und zur Semantik der Kreditaufnahme finden Sie in der Kueue-Dokumentation.

Stellen Sie die ClusterQueues und LocalQueues bereit:

kubectl apply -f cq-team-a.yaml
kubectl apply -f cq-team-b.yaml

(Optional) kube-prometheus bereitstellen und Arbeitslasten mit Prometheus überwachen

Mit Prometheus können Sie ausstehende Arbeitslasten und aktive Arbeitslasten in Kueue überwachen. Richten Sie Prometheus für den Cluster unter dem Namespace-Monitoring ein, um die einzelnen überwachten Arbeitslasten zu überwachen und die Last auf jeder ClusterQueue zu beobachten.

  1. Laden Sie den Quellcode für den Prometheus-Operator zum Monitoring herunter:

    cd
git clone https://github.com/prometheus-operator/kube-prometheus.git

  2. Erstellen Sie die CustomResourceDefinitions(CRDs):

    kubectl create -f kube-prometheus/manifests/setup

  3. Erstellen Sie die Monitoring-Komponenten:

    kubectl create -f kube-prometheus/manifests

  4. Erlauben Sie dem Prometheus-Operator, Messwerte aus Kueue-Komponenten zu extrahieren:

    kubectl apply -f https://github.com/kubernetes-sigs/kueue/releases/download/$VERSION/prometheus.yaml

  5. Wechseln Sie in das Arbeitsverzeichnis:

    cd kubernetes-engine-samples/batch/kueue-cohort

  6. Starten Sie ein neues Terminal, um durch Portweiterleitung des Dienstes auf Prometheus zuzugreifen:

    kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090

  7. Öffnen Sie Prometheus unter localhost:9090 im Browser.

  8. Wenn Sie Cloud Shell verwenden, klicken Sie auf Webvorschau, wählen Sie den Port ändern, setzen Sie die Portnummer auf 9090 und wählen Sie Change and Preview aus.

  9. Geben Sie die Abfrage für den ersten Bereich ein, der die aktive ClusterQueue cq-team-a überwacht:

    kueue_pending_workloads{cluster_queue="cq-team-a", status="active"} or kueue_admitted_active_workloads{cluster_queue="cq-team-a"}

  10. Fügen Sie einen weiteren Bereich hinzu und geben Sie die Abfrage ein, die die aktive ClusterQueue cq-team-b überwacht:

    kueue_pending_workloads{cluster_queue="cq-team-b", status="active"} or kueue_admitted_active_workloads{cluster_queue="cq-team-b"}

  11. Fügen Sie einen weiteren Bereich hinzu und geben Sie die Abfrage ein, die die Anzahl der Knoten im Cluster überwacht:

    count(kube_node_info)

Jobs erstellen und zugelassene Arbeitslasten beobachten

Erstellen Sie Jobs in beiden ClusterQueues, die zehn Sekunden lang in den Ruhemodus versetzt werden, mit drei parallelen Jobs, die mit drei Vervollständigungen abgeschlossen werden. Sie wird nach 60 Sekunden bereinigt.

apiVersion: batch/v1
kind: Job
metadata:
  namespace: team-a # Job under team-a namespace
  generateName: sample-job-team-a-
  labels:
    kueue.x-k8s.io/queue-name: lq-team-a # Point to the LocalQueue
spec:
  ttlSecondsAfterFinished: 60 # Job will be deleted after 60 seconds
  parallelism: 3 # This Job will have 3 replicas running at the same time
  completions: 3 # This Job requires 3 completions
  suspend: true # Set to true to allow Kueue to control the Job when it starts
  template:
    spec:
      containers:
      - name: dummy-job
        image: gcr.io/k8s-staging-perf-tests/sleep:latest
        args: ["10s"] # Sleep for 10 seconds
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
      restartPolicy: Never

job-team-a.yaml erstellt Jobs unter dem Namespace team-a und verweist auf die LocalQueue lq-team-a und die ClusterQueue cq-team-a.

In ähnlicher Weise erstellt job-team-b.yaml Jobs unter dem Namespace team-b und verweist auf die LocalQueue lq-team-b und die ClusterQueue cq-team-b.

  1. Starten Sie ein neues Terminal und führen Sie dieses Skript aus, um jede Sekunde einen Job zu generieren:

    ./create_jobs.sh job-team-a.yaml 1

  2. Starten Sie ein anderes Terminal und erstellen Sie Jobs für den Namespace team-b:

    ./create_jobs.sh job-team-b.yaml 1

  3. Beobachten Sie, welche Jobs in Prometheus in der Warteschlange stehen. Oder mit diesem Befehl:

    watch -n 2 kubectl get clusterqueues -o wide

Die Ausgabe sollte in etwa so aussehen:

    NAME        COHORT      STRATEGY         PENDING WORKLOADS   ADMITTED WORKLOADS
    cq-team-a   all-teams   BestEffortFIFO   0                   5
    cq-team-b   all-teams   BestEffortFIFO   0                   4

Nicht verwendetes Kontingent mit Kohorten nutzen

ClusterQueues sind möglicherweise nicht immer voll ausgelastet. Die Kontingentnutzung wird nicht maximiert, wenn Arbeitslasten nicht gleichmäßig auf ClusterQueues verteilt sind. Wenn ClusterQueues dieselbe Kohorte untereinander teilen, können ClusterQueues Kontingente aus anderen ClusterQueues mieten, um die Kontingentnutzung zu maximieren.

  1. Sobald Jobs für die ClusterQueues cq-team-a und cq-team-b in die Warteschlange gestellt wurden, beenden Sie das Skript für den Namespace team-b. Dazu drücken Sie CTRL+c auf dem entsprechenden Terminal.

  2. Sobald alle ausstehenden Jobs aus dem Namespace team-b verarbeitet wurden, können die Jobs aus dem Namespace team-a die verfügbaren Ressourcen in cq-team-b übernehmen:

    kubectl describe clusterqueue cq-team-a

    Da cq-team-a und cq-team-b dieselbe Kohorte namens all-teams verwenden, können diese ClusterQueues Ressourcen verwenden, die nicht verwendet werden.

      Flavors Usage:
    Name:  on-demand
    Resources:
      Borrowed:  5
      Name:      cpu
      Total:     15
      Borrowed:  5Gi
      Name:      memory
      Total:     15Gi

  3. Setzen Sie das Skript für den Namespace team-b fort.

    ./create_jobs.sh job-team-b.yaml 3

    Sehen Sie sich an, wie die übernommenen Ressourcen von cq-team-a zurück zu 0 wechseln, während die Ressourcen von cq-team-b für ihre eigenen Arbeitslasten verwendet werden:

    kubectl describe clusterqueue cq-team-a

      Flavors Usage:
    Name:  on-demand
    Resources:
      Borrowed:  0
      Name:      cpu
      Total:     9
      Borrowed:  0
      Name:      memory
      Total:     9Gi

Kontingent mit Spot-VMs erhöhen

Wenn das Kontingent vorübergehend erhöht werden muss, um beispielsweise die hohe Nachfrage ausstehender Arbeitslasten zu erfüllen, können Sie Kueue so konfigurieren, dass der Bedarf gedeckt wird. Dazu müssen Sie der Kohorte weitere ClusterQueues hinzufügen. ClusterQueues mit nicht verwendeten Ressourcen können diese Ressourcen mit anderen ClusterQueues teilen, die zur selben Kohorte gehören.

Zu Beginn der Anleitung haben Sie einen Knotenpool mit dem Namen spot mithilfe von Spot-VMs und einem ResourceFlavor mit dem Namen spot erstellt, wobei das Label auf cloud.google.com/gke-provisioning: spot gesetzt ist. Erstellen Sie eine ClusterQueue zur Verwendung dieses Knotenpools und des ResourceFlavor, der ihn darstellt:

  1. Erstellen Sie eine neue ClusterQueue namens cq-spot mit der Kohorte von all-teams:

    apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: spot-cq
spec:
  cohort: all-teams # Same cohort as cq-team-a and cq-team-b
  resourceGroups:
  - coveredResources: ["cpu", "memory"]
    flavors:
    - name: spot
      resources:
      - name: "cpu"
        nominalQuota: 40
      - name: "memory"
        nominalQuota: 144Gi

    Da diese ClusterQueue dieselbe Kohorte mit cq-team-a und cq-team-b nutzt, können sowohl ClusterQueue cq-team-a als auch cq-team-b Ressourcen bis zu 15 CPU-Anfragen und 15 GB Arbeitsspeicher mieten.

    kubectl apply -f cq-spot.yaml

  2. Achten Sie in Prometheus darauf, dass die zugelassenen Arbeitslasten sowohl für cq-team-a als auch für cq-team-b aufgrund des zusätzlichen Kontingents von cq-spot, das dieselbe Kohorte nutzt, einen Anstieg der Anzahl von Arbeitslasten erreichen. Oder mit diesem Befehl:

    watch -n 2 kubectl get clusterqueues -o wide

  3. Beobachten Sie in Prometheus die Anzahl der Knoten im Cluster. Oder mit diesem Befehl:

    watch -n 2 kubectl get nodes -o wide

  4. Beenden Sie beide Skripts, indem Sie CTRL+c für die Namespaces team-a und team-b drücken.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Projekt löschen

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Einzelne Ressource löschen

  1. Das Kueue-Kontingentsystem löschen:

    kubectl delete -n team-a localqueue lq-team-a
kubectl delete -n team-b localqueue lq-team-b
kubectl delete clusterqueue cq-team-a
kubectl delete clusterqueue cq-team-b
kubectl delete clusterqueue cq-spot
kubectl delete resourceflavor default
kubectl delete resourceflavor on-demand
kubectl delete resourceflavor spot

  2. Das Kueue-Manifest löschen:

    VERSION=VERSION
kubectl delete -f \
  https://github.com/kubernetes-sigs/kueue/releases/download/$VERSION/manifests.yaml

  3. Löschen Sie den Cluster:

    gcloud container clusters delete kueue-cohort --region=COMPUTE_REGION

Nächste Schritte