Diese Seite wurde von der Cloud Translation API übersetzt.

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.

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

Mit Prometheus können Sie Ihre aktiven und ausstehenden Kueue-Arbeitslasten überwachen. Stellen Sie kube-prometheus für den Cluster unter dem Namespace monitoring bereit, um die einzelnen überwachten Arbeitslasten zu überwachen und die Last auf jeder ClusterQueue zu beobachten:

Laden Sie den Quellcode für den Prometheus-Operator herunter:

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

Erstellen Sie die CustomResourceDefinitions(CRDs):

kubectl create -f kube-prometheus/manifests/setup

Erstellen Sie die Monitoring-Komponenten:

kubectl create -f kube-prometheus/manifests

Erlauben Sie prometheus-operator, Messwerte aus Kueue-Komponenten zu extrahieren:

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

Wechseln Sie in das Arbeitsverzeichnis:

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

Richten Sie die Portweiterleitung zum Prometheus-Dienst ein, der in Ihrem GKE-Cluster ausgeführt wird:
```
kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090
```
Öffnen Sie die Prometheus-Web-UI 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.
Geben Sie im Abfragefeld Ausdruck die folgende Abfrage ein, um den ersten Bereich zu erstellen, der die aktiven Arbeitslasten für die 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"}
```
Klicken Sie auf Bereich hinzufügen.
Geben Sie im Abfragefeld 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"}
```
Klicken Sie auf Bereich hinzufügen.
Geben Sie im Abfragefeld 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 Kueue-Arbeitslasten überwachen. Eine vollständige Liste der Messwerte finden Sie in der Kueue-Dokumentation.

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

Mit der folgenden Konfiguration werden vier Kubernetes-Ressourcen erstellt, die den Zugriff auf Messwerte für die Google Cloud Managed Service for Prometheus-Collector ermöglichen.

Ein ServiceAccount namens kueue-metrics-reader im Namespace kueue-system wird für die Authentifizierung beim Zugriff auf die Kueue-Messwerte verwendet.
Ein Secret, das dem Dienstkonto kueue-metrics-reader zugeordnet ist, speichert ein Authentifizierungstoken, das vom Collector verwendet wird, um sich am Messwertendpunkt zu authentifizieren, der von der Kueue-Bereitstellung bereitgestellt wird.
Eine Rolle mit dem Namen kueue-secret-reader im Namespace kueue-system, die das Lesen des Secrets mit dem Dienstkontotoken ermöglicht.
Ein ClusterRoleBinding-Objekt, das 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

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

Je nachdem, ob Sie einen Autopilot- oder Standardcluster verwenden, müssen Sie das RoleBinding im Namespace gke-gmp-system oder gmp-system erstellen. Mit dieser Ressource kann das Dienstkonto des Collectors auf das kueue-metrics-reader-token-Secret zugreifen, um die Kueue-Messwerte zu authentifizieren und 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

PodMonitoring-Ressource konfigurieren:

Mit der folgenden Ressource wird die Überwachung für die Kueue-Bereitstellung konfiguriert. Sie gibt an, dass Messwerte über HTTPS auf dem Pfad „/metrics“ bereitgestellt werden. Das Secret kueue-metrics-reader-token wird für die Authentifizierung beim Scrapen der Messwerte verwendet.

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

Exportierte Messwerte abfragen

Beispiel für PromQL-Abfragen zum Überwachen von Kueue-basierten Systemen

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

Jobdurchsatz

So wird die Rate der zugelassenen Arbeitslasten pro Sekunde über 5 Minuten für jede cluster_queue berechnet. Wenn Sie diesen Messwert nach Warteschlange aufschlüsseln, können Sie Engpässe ermitteln. Wenn Sie ihn summieren, erhalten Sie den Gesamtdurchsatz des Systems.

Suchanfrage:

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

Bessere Ressourcennutzung

Dabei wird davon ausgegangen, dass metrics.enableClusterQueueResources aktiviert ist. Das Verhältnis der aktuellen CPU-Nutzung zum nominalen CPU-Kontingent für jede Warteschlange wird berechnet. Ein Wert nahe 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 benutzerdefinierte 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 gibt die Wartezeit im 90. Perzentil für Arbeitslasten in einer bestimmten Warteschlange an. Sie können den Quantilwert ändern (z. B. 0,5 für den Median, 0,99 für das 99. Perzentil), 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

In diesem Abschnitt erstellen Sie Kubernetes-Jobs unter den Namespaces team-a und team-b. Ein Jobcontroller in Kubernetes erstellt einen oder mehrere Pods und sorgt dafür, dass sie eine bestimmte Aufgabe erfolgreich ausführen.

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.

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
```
Starten Sie ein anderes Terminal und erstellen Sie Jobs für den Namespace team-b:
```
./create_jobs.sh job-team-b.yaml 1
```
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.

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

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:

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

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
```
Beobachten Sie in Prometheus die Anzahl der Knoten im Cluster. Oder mit diesem Befehl:
```
watch -n 2 kubectl get nodes -o wide
```
Beenden Sie beide Skripts, indem Sie CTRL+c für die Namespaces team-a und team-b drücken.

Jobwarteschlangensystem mit Kontingentfreigabe zwischen Namespaces in GKE implementieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hintergrund

ResourceFlavors erstellen

ClusterQueue und LocalQueue erstellen

(Optional) Arbeitslasten mit kube-prometheus überwachen

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

Autopilot

Standard

Exportierte Messwerte abfragen

Beispiel für PromQL-Abfragen zum Überwachen von Kueue-basierten Systemen

Jobdurchsatz

Bessere Ressourcennutzung

Wartezeiten in der Warteschlange

Jobs erstellen und zugelassene Arbeitslasten beobachten

Nicht verwendetes Kontingent mit Kohorten nutzen

Kontingent mit Spot-VMs erhöhen

Jobwarteschlangensystem mit Kontingentfreigabe zwischen Namespaces in GKE implementieren