Implementare un sistema di coda dei job con condivisione della quota tra gli spazi dei nomi su GKE

Standard

---

Questo tutorial utilizza Kueue per mostrarti come implementare un sistema di accodamento dei job, configurare la condivisione di risorse e quote dei carichi di lavoro tra diversi spazi dei nomi su Google Kubernetes Engine (GKE) e massimizzare l'utilizzo del cluster.

Sfondo

In qualità di ingegnere dell'infrastruttura o amministratore del cluster, massimizzare l'utilizzo tra gli spazi dei nomi è molto importante. Un batch di job in uno spazio dei nomi potrebbe non utilizzare completamente la quota assegnata allo spazio dei nomi, mentre un altro spazio dei nomi potrebbe avere più job in attesa. Per utilizzare in modo efficiente le risorse del cluster tra i job in spazi dei nomi diversi e per aumentare la flessibilità della gestione delle quote, puoi configurare i cohort in Kueue. Una coorte è un gruppo di ClusterQueue che possono prendere in prestito la quota inutilizzata l'una dall'altra. Una ClusterQueue gestisce un pool di risorse come CPU, memoria e acceleratori hardware.

Puoi trovare una definizione più dettagliata di tutti questi concetti nella documentazione di Kueue.

Nota: Kueue si riferisce ai job definiti con un'API arbitraria come carichi di lavoro, per evitare confusione con l'API Kubernetes Job specifica.

Obiettivi

Questo tutorial è rivolto agli ingegneri dell'infrastruttura o agli amministratori dei cluster che vogliono implementare un sistema di accodamento dei job su Kubernetes utilizzando Kueue con la condivisione delle quote.

Questo tutorial simulerà due team in due spazi dei nomi diversi, in cui ogni team ha le proprie risorse dedicate, ma può prendere in prestito risorse dall'altro. Un terzo insieme di risorse può essere utilizzato come spillover quando i job si accumulano.

Utilizza l'operatore Prometheus per monitorare i job e l'allocazione delle risorse in spazi dei nomi diversi.

Questo tutorial illustra i seguenti passaggi necessari:

1. Crea un cluster GKE
2. Crea ResourceFlavors
3. Per ogni team, crea una ClusterQueue e una LocalQueue
4. Crea job e osserva i workload ammessi
5. Prendere in prestito la quota inutilizzata con le coorti
6. Aggiungi una coda ClusterQueue di overflow che gestisce le VM spot

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

• GKE

Utilizza il Calcolatore prezzi per generare una stima dei costi in base all'utilizzo previsto.

Al termine di questo tutorial, puoi evitare l'addebito di ulteriori costi eliminando le risorse create. Per ulteriori informazioni, vedi Pulizia.

Prima di iniziare

Configura il progetto

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.

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

Verify that billing is enabled for your Google Cloud project.

Enable the GKE API.

Enable the API

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

Verify that billing is enabled for your Google Cloud project.

Enable the GKE API.

Enable the API

Impostare i valori predefiniti per Google Cloud CLI

1. Nella console Google Cloud , avvia un'istanza Cloud Shell:
   Apri Cloud Shell

2. Scarica il codice sorgente di questa app di esempio:

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

3. Imposta le variabili di ambiente predefinite:

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

   Sostituisci i seguenti valori:

   • PROJECT_ID: il tuo Google Cloud ID progetto.
   • COMPUTE_REGION: la regione Compute Engine.

Crea un cluster GKE

1. Crea un cluster GKE denominato kueue-cohort:

   Creerai un cluster con 6 nodi (2 per zona) nel pool predefinito e senza scalabilità automatica. Queste saranno tutte le risorse disponibili per le squadre all'inizio, quindi dovranno competere per ottenerle.

   Vedremo più avanti come Kueue gestisce i workload che entrambi i team invieranno alle rispettive code.

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

   Nota: il completamento di questo passaggio può richiedere fino a cinque minuti.

   Una volta creato il cluster, il risultato è simile al seguente:

     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
   

   Dove STATUS è RUNNING per kueue-cluster.

2. Crea un pool di nodi denominato spot.

   Questo pool di nodi utilizza la VM spot e la scalabilità automatica è abilitata. Inizialmente non ha nodi, ma in un secondo momento lo renderai disponibile ai team per l'utilizzo come capacità di overflow.

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

3. Installa la versione di rilascio di Kueue nel cluster:

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

   Sostituisci VERSION con la lettera v dopo l'ultima versione di Kueue, ad esempio v0.4.0. Per ulteriori informazioni sulle versioni di Kueue, consulta Versioni di Kueue.

   Nota: gli esempi nel repository richiedono la versione 0.3.0 o successive.

   Attendi che il controller Kueue sia pronto:

   watch kubectl -n kueue-system get pods
   

   Prima di poter continuare, l'output dovrebbe essere simile al seguente:

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

4. Crea due nuovi spazi dei nomi denominati team-a e team-b:

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

   I job verranno generati in ogni spazio dei nomi.

Crea ResourceFlavors

Un ResourceFlavor rappresenta le variazioni delle risorse nei nodi del cluster, ad esempio VM diverse (ad esempio spot rispetto a on demand), architetture (ad esempio CPU x86 e ARM), marche e modelli (ad esempio GPU Nvidia A100 e T4).

ResourceFlavors utilizza le etichette e i taint dei nodi per trovare una corrispondenza con un insieme di nodi nel cluster.

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 questo manifest:

• ResourceFlavor on-demand ha l'etichetta impostata su cloud.google.com/gke-provisioning: standard.
• ResourceFlavor spot ha l'etichetta impostata su cloud.google.com/gke-provisioning: spot.

Nota: queste etichette richiedono GKE 1.26 o versioni successive

Quando a un workload viene assegnato un ResourceFlavor, Kueue assegna i pod del workload ai nodi che corrispondono alle etichette dei nodi definite per ResourceFlavor.

Esegui il deployment di ResourceFlavor:

kubectl apply -f flavors.yaml

Crea ClusterQueue e LocalQueue

Crea due ClusterQueue cq-team-a e cq-team-b e le relative LocalQueue lq-team-a e lq-team-b con spazi dei nomi team-a e team-b rispettivamente.

ClusterQueue sono oggetti con ambito a livello di cluster che regolano un pool di risorse come CPU, memoria e acceleratori hardware. Gli amministratori batch possono limitare la visibilità di questi oggetti agli utenti batch.

LocalQueues sono oggetti con spazi dei nomi che gli utenti batch possono elencare. Puntano a ClusterQueues, da cui vengono allocate le risorse per eseguire i workload LocalQueue.

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 consente alle risorse di avere più varianti. In questo caso, entrambe le ClusterQueue hanno due varianti, on-demand e spot, ognuna delle quali fornisce cpu risorse. La quota di ResourceFlavor spot è impostata su 0 e non verrà utilizzata per ora.

Entrambe le ClusterQueue condividono la stessa coorte denominata all-teams, definita in .spec.cohort. Quando due o più ClusterQueue condividono la stessa coorte, possono prendere in prestito la quota inutilizzata l'una dall'altra.

Per saperne di più sul funzionamento dei cohort e sulla semantica di prestito, consulta la documentazione di Kueue.

Esegui il deployment di ClusterQueues e LocalQueues:

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

(Facoltativo) Monitora i workload utilizzando kube-prometheus

Puoi utilizzare Prometheus per monitorare i carichi di lavoro Kueue attivi e in attesa. Per monitorare i workload in fase di avvio e osservare il carico su ogni ClusterQueue, esegui il deployment di kube-prometheus nel cluster nello spazio dei nomi monitoring:

1. Scarica il codice sorgente dell'operatore Prometheus:

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

2. Crea le CustomResourceDefinitions(CRD):

   kubectl create -f kube-prometheus/manifests/setup
   

3. Crea i componenti di monitoraggio:

   kubectl create -f kube-prometheus/manifests
   

4. Consenti a prometheus-operator di eseguire lo scraping delle metriche dai componenti di Kueue:

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

5. Passa alla directory di lavoro:

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

6. Configura il port forwarding al servizio Prometheus in esecuzione nel cluster GKE:

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

7. Apri la UI web di Prometheus su localhost:9090 nel browser.

   In Cloud Shell:

   1. Fai clic su Anteprima web.

   2. Fai clic su Cambia porta e imposta il numero di porta su 9090.

   3. Fai clic su Cambia e visualizza anteprima.

   Viene visualizzata la seguente UI web di Prometheus.

   

8. Nella casella di query Espressione, inserisci la seguente query per creare il primo pannello che monitora i carichi di lavoro attivi per cq-team-a ClusterQueue:

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

9. Fai clic su Aggiungi riquadro.

10. Nella casella della query Espressione, inserisci la seguente query per creare un altro riquadro che monitora i carichi di lavoro attivi per cq-team-b ClusterQueue:

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

11. Fai clic su Aggiungi riquadro.

12. Nella casella di query Espressione, inserisci la seguente query per creare un pannello che monitora il numero di nodi nel cluster:

    count(kube_node_info)
    

(Facoltativo) Monitora i carichi di lavoro utilizzando Google Cloud Managed Service per Prometheus

Puoi utilizzare Google Cloud Managed Service per Prometheus per monitorare i carichi di lavoro Kueue attivi e in attesa. Un elenco completo delle metriche è disponibile nella documentazione di Kueue.

1. Configura l'identità e il controllo dell'accesso basato sui ruoli per l'accesso alle metriche:

   La seguente configurazione crea quattro risorse Kubernetes che forniscono l'accesso alle metriche per i raccoglitori di Google Cloud Managed Service per Prometheus.

   • Un service account denominato kueue-metrics-reader all'interno dello spazio dei nomi kueue-system verrà utilizzato per l'autenticazione durante l'accesso alle metriche di Kueue.

   • Un secret associato al account di servizio kueue-metrics-reader memorizza un token di autenticazione utilizzato dal raccoglitore per l'autenticazione con l'endpoint delle metriche esposto dal deployment di Kueue.

   • Un ruolo denominato kueue-secret-reader nello spazio dei nomi kueue-system, che consente di leggere il secret contenente il token del account di servizio.

   • Un ClusterRoleBinding che concede all'account di servizio kueue-metrics-reader il ClusterRole kueue-metrics-reader.

   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. Configura RoleBinding per Google Cloud Managed Service per Prometheus:

   A seconda che tu stia utilizzando un cluster Autopilot o Standard, devi creare RoleBinding nello spazio dei nomi gke-gmp-system o gmp-system. Questa risorsa consente al account di servizio del collettore di accedere al secret kueue-metrics-reader-token per autenticare ed estrarre le metriche di Kueue.

   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. Configura la risorsa Pod Monitoring:

   La seguente risorsa configura il monitoraggio per il deployment di Kueue, specifica che le metriche sono esposte sul percorso /metrics tramite HTTPS. Utilizza il secret kueue-metrics-reader-token per l'autenticazione durante lo scraping delle metriche.

   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
   

Metriche esportate delle query

• Eseguire query sulle metriche esportate con Cloud Monitoring
• Eseguire query sulle metriche esportate con Grafana

Query PromQL di esempio per il monitoraggio di sistemi basati su Kueue

Queste query PromQL ti consentono di monitorare le metriche chiave di Kueue, come la velocità effettiva dei job, l'utilizzo delle risorse per coda e i tempi di attesa dei workload, per comprendere le prestazioni del sistema e identificare potenziali colli di bottiglia.

Throughput del job

Questo valore calcola la tariffa al secondo dei workload ammessi in 5 minuti per ogni cluster_queue. Questa metrica può essere utile per suddividerla per coda, in modo da individuare i colli di bottiglia e la somma fornisce la velocità effettiva complessiva del sistema.

Query:

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

Utilizzo delle risorse

Ciò presuppone che metrics.enableClusterQueueResources sia attivato. Calcola il rapporto tra l'utilizzo attuale della CPU e la quota nominale di CPU per ogni coda. Un valore vicino a 1 indica un utilizzo elevato. Puoi adattare questo valore per la memoria o altre risorse modificando l'etichetta della risorsa.

Per installare una versione rilasciata di Kueue configurata personalizzata nel tuo cluster, segui la documentazione di Kueue.

Query:

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

Tempi di attesa in coda

Fornisce il 90° percentile del tempo di attesa per i workload in una coda specifica. Puoi modificare il valore del quantile (ad es. 0,5 per la mediana, 0,99 per il 99° percentile) per comprendere la distribuzione del tempo di attesa.

Query:

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

Crea job e osserva i workload ammessi

In questa sezione, creerai i job Kubernetes negli spazi dei nomi team-a e team-b. Un controller Job in Kubernetes crea uno o più pod e assicura che eseguano correttamente un'attività specifica.

Genera job per entrambe le ClusterQueue che rimarranno inattive per 10 secondi, con tre job paralleli e tre completamenti. Verrà poi ripulito dopo 60 secondi.

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 crea job nello spazio dei nomi team-a e punta a LocalQueue lq-team-a e ClusterQueue cq-team-a.

Analogamente, job-team-b.yaml crea job nello spazio dei nomi team-b e punta a LocalQueue lq-team-b e a ClusterQueue cq-team-b.

1. Avvia un nuovo terminale ed esegui questo script per generare un job ogni secondo:

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

2. Avvia un altro terminale e crea job per lo spazio dei nomi team-b:

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

3. Osserva i job in coda in Prometheus. In alternativa, con questo comando:

   watch -n 2 kubectl get clusterqueues -o wide
   

L'output dovrebbe essere simile al seguente:

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

Prendere in prestito la quota inutilizzata con i cohort

ClusterQueues potrebbe non essere sempre alla massima capacità. L'utilizzo delle quote non viene ottimizzato quando i workload non sono distribuiti uniformemente tra le ClusterQueue. Se ClusterQueue condividono la stessa coorte, possono prendere in prestito quote da altre ClusterQueue per massimizzare l'utilizzo delle quote.

1. Una volta che sono presenti job in coda per ClusterQueue cq-team-a e cq-team-b, interrompi lo script per lo spazio dei nomi team-b premendo CTRL+c nel terminale corrispondente.

2. Una volta elaborati tutti i job in attesa dello spazio dei nomi team-b, i job dello spazio dei nomi team-a possono prendere in prestito le risorse disponibili in cq-team-b:

   kubectl describe clusterqueue cq-team-a
   

   Poiché cq-team-a e cq-team-b condividono la stessa coorte denominata all-teams, queste ClusterQueue possono condividere le risorse non utilizzate.

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

3. Riprendi lo script per lo spazio dei nomi team-b.

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

   Osserva come le risorse prese in prestito da cq-team-a tornano a 0, mentre le risorse di cq-team-b vengono utilizzate per i propri workload:

   kubectl describe clusterqueue cq-team-a
   

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

Aumentare la quota con le VM spot

Quando è necessario aumentare temporaneamente la quota, ad esempio per soddisfare la domanda elevata nei workload in attesa, puoi configurare Kueue in modo che soddisfi la domanda aggiungendo altre ClusterQueue al coorte. ClusterQueue con risorse inutilizzate può condividere queste risorse con altre ClusterQueue che appartengono alla stessa coorte.

All'inizio del tutorial, hai creato un pool di nodi denominato spot utilizzando le VM spot e un ResourceFlavor denominato spot con l'etichetta impostata su cloud.google.com/gke-provisioning: spot. Crea una ClusterQueue per utilizzare questo pool di nodi e ResourceFlavor che lo rappresenta:

1. Crea una nuova ClusterQueue denominata cq-spot con la coorte impostata su 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

   Poiché questa ClusterQueue condivide lo stesso gruppo con cq-team-a e cq-team-b, entrambe le ClusterQueue cq-team-a e cq-team-b possono prendere in prestito risorse fino a 15 richieste di CPU e 15 Gi di memoria.

   kubectl apply -f cq-spot.yaml
   

2. In Prometheus, osserva come i picchi dei carichi di lavoro ammessi per cq-team-a e cq-team-b grazie alla quota aggiuntiva di cq-spot che condivide la stessa coorte. In alternativa, con questo comando:

   watch -n 2 kubectl get clusterqueues -o wide
   

3. In Prometheus, osserva il numero di nodi nel cluster. In alternativa, con questo comando:

   watch -n 2 kubectl get nodes -o wide
   

4. Interrompi entrambi gli script premendo CTRL+c per lo spazio dei nomi team-a e team-b.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina il progetto

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:
• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini, elimini anche tutto il lavoro che hai svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.
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.

Elimina la singola risorsa

1. Elimina il sistema di quote Kueue:

   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. Elimina il manifest di Kueue:

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

3. Elimina il cluster:

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

Passaggi successivi

• Scopri di più su come implementare un sistema batch utilizzando Kueue.

• Scopri di più sui job su GKE.

• Scopri di più su Kueue