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.
In diesem Manifest:
- Das ResourceFlavor
on-demand
hat das Labelcloud.google.com/gke-provisioning: standard
. - Das ResourceFlavor
spot
hat das Labelcloud.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.
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:
Klicken Sie auf Webvorschau.
Klicken Sie auf Port ändern und legen Sie die Portnummer auf
9090
fest.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 Namespacekueue-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 Namespacekueue-system
, die das Lesen des Secrets mit dem Dienstkontotoken ermöglicht.Ein ClusterRoleBinding-Objekt, das dem Dienstkonto
kueue-metrics-reader
die ClusterRolekueue-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
odergmp-system
erstellen. Mit dieser Ressource kann das Dienstkonto des Collectors auf daskueue-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.
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
undcq-team-b
in die Warteschlange gestellt wurden, beenden Sie das Skript für den Namespaceteam-b
. Dazu drücken SieCTRL+c
auf dem entsprechenden Terminal.Sobald alle ausstehenden Jobs aus dem Namespace
team-b
verarbeitet wurden, können die Jobs aus dem Namespaceteam-a
die verfügbaren Ressourcen incq-team-b
übernehmen:kubectl describe clusterqueue cq-team-a
Da
cq-team-a
undcq-team-b
dieselbe Kohorte namensall-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 zu0
wechseln, während die Ressourcen voncq-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 vonall-teams
:Da diese ClusterQueue dieselbe Kohorte mit
cq-team-a
undcq-team-b
nutzt, können sowohl ClusterQueuecq-team-a
als auchcq-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ürcq-team-b
aufgrund des zusätzlichen Kontingents voncq-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 Namespacesteam-a
undteam-b
drücken.