Jobwarteschlangensystem mit Kontingentfreigabe zwischen Namespaces in GKE implementieren

Standard

---

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.

Hinweis: Kueue bezieht sich auf Jobs, die mit einer beliebigen API als Arbeitslasten definiert sind, um die Verwechslung mit der spezifischen Kubernetes-Job-API zu vermeiden.

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.

In dieser Anleitung werden die folgenden erforderlichen Schritte behandelt:

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

Kosten

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

• GKE

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. 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

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:

   • PROJECT_ID: Ihre Google Cloud-Projekt-ID.
   • COMPUTE_REGION: Die Compute Engine-Region.

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
   

   Hinweis: Dieser Schritt kann bis zu fünf Minuten dauern.

   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.

   Hinweis: Für die Beispiele im Repository ist v0.3.0 oder höher erforderlich.

   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.

Hinweis: Für diese Labels ist GKE 1.26 oder höher erforderlich.

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) Arbeitslasten mit kube-prometheus überwachen

Mit Prometheus können Sie aktive und ausstehende Arbeitslasten in Kueue überwachen. Wenn Sie die einzelnen überwachten Arbeitslasten überwachen und die Last auf jeder ClusterQueue beobachten möchten, stellen Sie kube-prometheus im Cluster unter dem Namespace monitoring bereit:

1. Laden Sie den Quellcode für den Prometheus-Operator 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. Richten Sie eine Portweiterleitung an den Prometheus-Dienst ein, der in Ihrem GKE-Cluster ausgeführt wird:

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

7. Öffnen Sie die Prometheus-Weboberfläche unter localhost:9090 im Browser.

   In Cloud Shell:

   1. Klicken Sie auf Webvorschau.

   2. Klicken Sie auf Port ändern und legen Sie die Portnummer auf 9090 fest.

   3. Klicken Sie auf Ändern und Vorschau.

   Die folgende Prometheus-Web-UI wird angezeigt.

   

8. Geben Sie in das Abfragefeld Expression die folgende Abfrage ein, um den ersten Bereich zu erstellen, in dem die aktiven Arbeitslasten für cq-team-a ClusterQueue überwacht werden:

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

9. Klicken Sie auf Steuerfeld hinzufügen.

10. Geben Sie in das Abfragefeld Expression (Ausdruck) die folgende Abfrage ein, um einen weiteren Bereich zu erstellen, in dem die aktiven Arbeitslasten für die ClusterQueue cq-team-b überwacht werden:

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

11. Klicken Sie auf Steuerfeld hinzufügen.

12. Geben Sie in das Abfragefeld Expression (Ausdruck) die folgende Abfrage ein, um einen Bereich zu erstellen, in dem die Anzahl der Knoten im Cluster überwacht wird:

    count(kube_node_info)
    

(Optional) Arbeitslasten mit Google Cloud Managed Service for Prometheus überwachen

Mit Google Cloud Managed Service for Prometheus können Sie Ihre aktiven und ausstehenden Arbeitslasten in Kueue überwachen. Eine vollständige Liste der Messwerte finden Sie in der Kueue-Dokumentation.

1. Identität und RBAC für den Zugriff auf Messwerte einrichten:

   Mit der folgenden Konfiguration werden vier Kubernetes-Ressourcen erstellt, die den Google Cloud Managed Service for Prometheus-Sammlern Messwertzugriff gewähren.

   • Ein Dienstkonto mit dem Namen kueue-metrics-reader im Namespace kueue-system wird für die Authentifizierung beim Zugriff auf die Queue-Messwerte verwendet.

   • In einem Secret, das mit dem Dienstkonto kueue-metrics-reader verknüpft ist, wird ein Authentifizierungstoken gespeichert, das vom Collector verwendet wird, um sich beim Messwertendpunkt zu authentifizieren, der von der Kueue-Bereitstellung freigegeben wird.

   • Eine Rolle mit dem Namen kueue-secret-reader im Namespace kueue-system, die das Lesen des Secrets mit dem Dienstkontotoken ermöglicht.

   • Eine ClusterRoleBinding, die dem Dienstkonto kueue-metrics-reader die ClusterRole kueue-metrics-reader zuweist.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
    name: kueue-metrics-reader
    namespace: kueue-system
   ---
   apiVersion: v1
   kind: Secret
   metadata:
    name: kueue-metrics-reader-token
    namespace: kueue-system
    annotations:
      kubernetes.io/service-account.name: kueue-metrics-reader
   type: kubernetes.io/service-account-token
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
    name: kueue-secret-reader
    namespace: kueue-system
   rules:
   -   resources:
    -   secrets
    apiGroups: [""]
    verbs: ["get", "list", "watch"]
    resourceNames: ["kueue-metrics-reader-token"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
    name: kueue-metrics-reader
   subjects:
   -   kind: ServiceAccount
    name: kueue-metrics-reader
    namespace: kueue-system
   roleRef:
    kind: ClusterRole
    name: kueue-metrics-reader
    apiGroup: rbac.authorization.k8s.io
   

2. RoleBinding für Google Cloud Managed Service for Prometheus konfigurieren:

   Je nachdem, ob Sie einen Autopilot- oder Standardcluster verwenden, müssen Sie die RoleBinding entweder im Namespace gke-gmp-system oder gmp-system erstellen. Über diese Ressource kann das Dienstkonto des Collectors auf das kueue-metrics-reader-token-Secret zugreifen, um sich zu authentifizieren und die Kueue-Messwerte zu erfassen.

   Autopilot

     apiVersion: rbac.authorization.k8s.io/v1
     kind: RoleBinding
     metadata:
       name: gmp-system:collector:kueue-secret-reader
       namespace: kueue-system
     roleRef:
       name: kueue-secret-reader
       kind: Role
       apiGroup: rbac.authorization.k8s.io
     subjects:
     -   name: collector
       namespace: gke-gmp-system
       kind: ServiceAccount
   

   Standard

     apiVersion: rbac.authorization.k8s.io/v1
     kind: RoleBinding
     metadata:
       name: gmp-system:collector:kueue-secret-reader
       namespace: kueue-system
     roleRef:
       name: kueue-secret-reader
       kind: Role
       apiGroup: rbac.authorization.k8s.io
     subjects:
     -   name: collector
       namespace: gmp-system
       kind: ServiceAccount
   

3. Pod Monitoring-Ressource konfigurieren:

   Mit der folgenden Ressource wird die Überwachung für die Kueue-Bereitstellung konfiguriert. Dabei wird angegeben, dass Messwerte über HTTPS unter dem Pfad „/metrics“ verfügbar gemacht werden. Beim Scrapen der Messwerte wird das Secret kueue-metrics-reader-token für die Authentifizierung verwendet.

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
   name: kueue
   namespace: kueue-system
   spec:
   selector:
    matchLabels:
      control-plane: controller-manager
   endpoints:
   -   port: https
    interval: 30s
    path: /metrics
    scheme: https
    tls:
      insecureSkipVerify: true
    authorization:
      type: Bearer
      credentials:
        secret:
          name: kueue-metrics-reader-token
          key: token
   

Exportierte Messwerte abfragen

• Exportierte Messwerte mit Cloud Monitoring abfragen
• Exportierte Messwerte mit Grafana abfragen

Beispiel-PromQL-Abfragen zum Überwachen von systemen mit Warteschlangen

Mit diesen PromQL-Abfragen können Sie wichtige Messwerte für die Warteschlange überwachen, z. B. Jobdurchsatz, Ressourcenauslastung nach Warteschlange und Wartezeiten für Arbeitslasten, um die Systemleistung zu verstehen und potenzielle Engpässe zu identifizieren.

Jobdurchsatz

Hier wird die Rate der zugelassenen Arbeitslasten pro Sekunde über einen Zeitraum von 5 Minuten für jede cluster_queue berechnet. Dieser Messwert kann bei der Aufschlüsselung nach Warteschlange helfen, Engpässe zu ermitteln. Die Summe gibt den Gesamtdurchsatz des Systems an.

Suchanfrage:

sum(rate(kueue_admitted_workloads_total[5m])) by (cluster_queue)

Bessere Ressourcennutzung

Dabei wird davon ausgegangen, dass metrics.enableClusterQueueResources aktiviert ist. Es wird das Verhältnis der aktuellen CPU-Nutzung zum nominellen CPU-Kontingent für jede Warteschlange berechnet. Ein Wert nahe bei 1 weist auf eine hohe Auslastung hin. Sie können dies für Arbeitsspeicher oder andere Ressourcen anpassen, indem Sie das Ressourcenlabel ändern.

Wenn Sie eine benutzerdefiniert konfigurierte Releaseversion von Kueue in Ihrem Cluster installieren möchten, folgen Sie der Kueue-Dokumentation.

Suchanfrage:

sum(kueue_cluster_queue_resource_usage{resource="cpu"}) by (cluster_queue) / sum(kueue_cluster_queue_nominal_quota{resource="cpu"}) by (cluster_queue)

Wartezeiten in der Warteschlange

Dies ist die Wartezeit des 90. Perzentil für Arbeitslasten in einer bestimmten Warteschlange. Sie können den Quantilwert ändern (z. B. 0,5 für den Median oder 0,99 für den 99. Perzentilwert), um die Verteilung der Wartezeit zu analysieren.

Suchanfrage:

histogram_quantile(0.9, kueue_admission_wait_time_seconds_bucket{cluster_queue="QUEUE_NAME"})

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

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:
• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.
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

• Weitere Informationen zum Bereitstellen eines Batchsystems mit Kueue

• Mehr über Jobs in GKE erfahren

• Weitere Informationen zu Kueue