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

Crea le ResourceFlavors

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

ResourceFlavors utilizza le etichette e gli elementi 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:

• L'etichetta di ResourceFlavor on-demand è impostata su cloud.google.com/gke-provisioning: standard.
• L'etichetta di ResourceFlavor spot è impostata su cloud.google.com/gke-provisioning: spot.

Quando a un carico di lavoro viene assegnato un ResourceFlavor, Kueue assegna i pod del carico di lavoro ai nodi corrispondenti alle etichette dei nodi definite per il ResourceFlavor.

Esegui il deployment di ResourceFlavor:

kubectl apply -f flavors.yaml

Crea ClusterQueue e LocalQueue

Crea due code cluster cq-team-a e cq-team-b e le relative code locali lq-team-a e lq-team-b con spazi dei nomi rispettivamente team-a e team-b.

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

Le code locali sono oggetti con spazio dei nomi che gli utenti possono elencare in batch. Questi puntano a CluterQueues, da cui vengono allocate le risorse per l'esecuzione dei 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ù versioni. In questo caso, entrambi i flussi di lavoro hanno due versioni, on-demand e spot, che forniscono ciascuna cpu risorse. La quota di ResourceFlavor spot è impostata su 0 e non verrà utilizzata per ora.

Entrambi i 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'uno dall'altro.

Per scoprire di più sul funzionamento delle coorti e sulla semantica del 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) Monitorare i carichi di lavoro utilizzando kube-prometheus

Puoi utilizzare Prometheus per monitorare i carichi di lavoro di Kueue attivi e in attesa. Per monitorare i carichi di lavoro 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 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 estrarre le metriche dai componenti 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 l'inoltro delle porte al servizio Prometheus in esecuzione nel tuo cluster GKE:

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

7. Apri l'interfaccia utente 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 Modifica e anteprima.

   Viene visualizzata la seguente interfaccia utente web di Prometheus.

   

8. Nella casella di query Espressione, inserisci la seguente query per creare il primo riquadro 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 di 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 riquadro 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 di Kueue attivi e in attesa. Un elenco completo delle metriche è disponibile nella documentazione di Kueue.

1. Configura l'identità e il RBAC per l'accesso alle metriche:

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

   • Un account di servizio denominato kueue-metrics-reader nello spazio dei nomi kueue-system verrà utilizzato per l'autenticazione quando si accede alle metriche di Kueue.

   • Un secret associato all'account di servizio kueue-metrics-reader memorizza un token di autenticazione utilizzato dal collector per autenticarsi 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 segreto contenente il token dell'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, dovrai creare il ruolo di appartenenza nello spazio dei nomi gke-gmp-system o gmp-system. Questa risorsa consente all'account di servizio del collector di accedere al segreto kueue-metrics-reader-token per autenticare e 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 di monitoraggio dei pod:

   La seguente risorsa configura il monitoraggio per il deployment di Kueue e 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: https
    interval: 30s
    path: /metrics
    scheme: https
    tls:
      insecureSkipVerify: true
    authorization:
      type: Bearer
      credentials:
        secret:
          name: kueue-metrics-reader-token
          key: token
   

Esegui query sulle metriche esportate

• 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 il throughput dei job, l'utilizzo delle risorse per coda e i tempi di attesa del carico di lavoro, per comprendere le prestazioni del sistema e identificare potenziali colli di bottiglia.

Throughput dei job

Viene calcolata la frequenza al secondo dei workload ammessi in 5 minuti per ogni cluster_queue. Questa metrica può essere utile per suddividere i dati in base alla coda e individuare i colli di bottiglia. La somma di queste metriche fornisce la produttività complessiva del sistema.

Query:

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

Utilizzo delle risorse

Si presume che metrics.enableClusterQueueResources sia attivato. Calcola il rapporto tra l'utilizzo corrente della CPU e la quota nominale della CPU per ogni coda. Un valore prossimo a 1 indica un utilizzo elevato. Puoi adattarlo per la memoria o altre risorse modificando l'etichetta della risorsa.

Per installare una versione rilasciata di Kueue configurata in modo personalizzato 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 tempo di attesa del 90° percentile per i carichi di lavoro 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

Genera job per entrambi i ClusterQueue che rimarranno inattivi per 10 secondi, con tre job in parallelo e verranno completati con tre completamenti. Verrà poi cleanup 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 alla coda locale lq-team-a e alla coda del cluster cq-team-a.

Analogamente, job-team-b.yaml crea job nello spazio dei nomi team-b e punta alla coda locale lq-team-b e alla coda del cluster 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 gruppi di coorte

ClusterQueues potrebbe non essere sempre a piena capacità. L'utilizzo delle quote non viene massimizzato quando i carichi di lavoro non sono distribuiti uniformemente tra i ClusterQueue. Se i cluster condividono la stessa coorte tra loro, possono prendere in prestito quote da altri cluster per massimizzare l'utilizzo delle quote.

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

2. Una volta elaborati tutti i job in attesa nello 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, questi ClusterQueue sono in grado di condividere 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 carichi di lavoro:

   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 la quota deve essere aumentata temporaneamente, ad esempio per soddisfare una domanda elevata nei carichi di lavoro in attesa, puoi configurare Kueue per soddisfare la domanda aggiungendo altri ClusterQueue alla coorte. I ClusterQueue con risorse inutilizzate possono condividerle con altri ClusterQueue che appartengono alla stessa coorte.

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

1. Crea un nuovo ClusterQueue denominato 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é questo ClusterQueue condivide la stessa coorte con cq-team-a e cq-team-b, sia ClusterQueue cq-team-a che 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 carichi di lavoro ammessi aumentano sia per cq-team-a che per cq-team-b grazie alla quota aggiunta da 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.