Implémenter un système de mise en file d'attente de jobs avec un partage de quota entre espaces de noms dans GKE

Créer les ressources ResourceFlavors

Une ressource ResourceFlavor représente les variations de ressources dans vos nœuds de cluster, telles que différentes VM (par exemple, Spot ou à la demande), les architectures (par exemple, processeurs x86 et ARM), les marques et les modèles (par exemple, Nvidia A100 par rapport aux GPU T4).

Les ressources ResourceFlavors utilisent des libellés et des rejets de nœuds pour correspondre à un ensemble de nœuds du 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

Dans le fichier manifeste :

• Le libellé de la ressource ResourceFlavor on-demand est défini sur cloud.google.com/gke-provisioning: standard.
• Le libellé de la ressource ResourceFlavor spot est défini sur cloud.google.com/gke-provisioning: spot.

Lorsqu'une charge de travail est attribuée à une ressource ResourceFlavor, Kueue en attribue les pods aux nœuds correspondant aux libellés de nœud définis pour la ressource ResourceFlavor.

Déployez la ressource ResourceFlavor :

kubectl apply -f flavors.yaml

Créer les ressources ClusterQueue et LocalQueue

Créez deux ressources ClusterQueue cq-team-a et cq-team-b, ainsi que les ressources LocalQueues lq-team-a et lq-team-b correspondantes, respectivement liées à team-a et team-b.

Les ressources QueueQueue sont des objets à l'échelle d'un cluster qui régissent un pool de ressources telles que le processeur, la mémoire et les accélérateurs matériels. Les administrateurs Batch peuvent limiter la visibilité de ces objets aux utilisateurs Batch.

Les ressources LocalQueue sont des objets d'espace de noms que les utilisateurs peuvent répertorier. Elles pointent vers des ressources CluterQueues à partir desquelles les ressources sont allouées pour exécuter les charges de travail 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 permet aux ressources d'avoir plusieurs types. Dans ce cas, les deux ClusterQueues ont deux saveurs, on-demand et spot, chacune fournissant cpu ressources. Le quota de la ressource ResourceFlavor spot est défini sur 0 et ne sera pas utilisé pour le moment.

Les deux ressources ClusterQueue partagent la même cohorte appelée all-teams, définie dans .spec.cohort. Lorsque deux ou plusieurs ressources ClusterQueue partagent la même cohorte, elles peuvent s'emprunter leur quota inutilisé.

Pour en savoir plus sur le fonctionnement des cohortes et la sémantique de l'emprunt, consultez la documentation de Kueue.

Déployez les ressources ClusterQueue et LocalQueues :

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

(Facultatif) Surveiller les charges de travail à l'aide de kube-prometheus

Vous pouvez utiliser Prometheus pour surveiller vos charges de travail Kueue actives et en attente. Pour surveiller les charges de travail en cours et observer la charge sur chaque ClusterQueue, déployez kube-prometheus dans le cluster sous l'espace de noms monitoring :

1. Téléchargez le code source de l'opérateur Prometheus :

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

2. Créez les ressources CustomResourceDefinition(CRD) :

   kubectl create -f kube-prometheus/manifests/setup
   

3. Créez les composants de surveillance :

   kubectl create -f kube-prometheus/manifests
   

4. Autorisez prometheus-operator à récupérer les métriques des composants Kueue :

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

5. Accédez au répertoire de travail :

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

6. Configurez la redirection de port vers le service Prometheus s'exécutant dans votre cluster GKE :

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

7. Ouvrez l'interface utilisateur Web de Prometheus sur localhost:9090 dans le navigateur.

   Dans Cloud Shell :

   1. Cliquez sur Aperçu sur le Web.

   2. Cliquez sur Modifier le port et définissez le numéro de port sur 9090.

   3. Cliquez sur Change and Preview (Modifier et prévisualiser).

   L'interface utilisateur Web de Prometheus suivante s'affiche.

   

8. Dans la zone de requête Expression, saisissez la requête suivante pour créer le premier panneau qui surveille les charges de travail actives pour la ressource ClusterQueue cq-team-a :

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

9. Cliquez sur Ajouter un panneau.

10. Dans la zone de requête Expression, saisissez la requête suivante pour créer un autre panneau qui surveille les charges de travail actives pour la ressource ClusterQueue cq-team-b :

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

11. Cliquez sur Ajouter un panneau.

12. Dans la zone de requête Expression, saisissez la requête suivante pour créer un panneau qui surveille le nombre de nœuds dans le cluster :

    count(kube_node_info)
    

(Facultatif) Surveiller les charges de travail à l'aide de Google Cloud Managed Service pour Prometheus

Vous pouvez utiliser Google Cloud Managed Service pour Prometheus afin de surveiller vos charges de travail Kueue actives et en attente. Vous trouverez la liste complète des métriques dans la documentation de Kueue.

1. Configurez l'identité et le RBAC pour accéder aux métriques :

   La configuration suivante crée quatre ressources Kubernetes qui fournissent un accès aux métriques pour les collecteurs Google Cloud Managed Service pour Prometheus.

   • Un compte de service nommé kueue-metrics-reader dans l'espace de noms kueue-system sera utilisé pour l'authentification lors de l'accès aux métriques Kueue.

   • Un secret associé au compte de service kueue-metrics-reader stocke un jeton d'authentification utilisé par le collecteur pour s'authentifier auprès du point de terminaison des métriques exposé par le déploiement Kueue.

   • Un rôle nommé kueue-secret-reader dans l'espace de noms kueue-system, qui permet de lire le secret contenant le jeton du compte de service.

   • Un objet ClusterRoleBinding qui accorde au compte de service kueue-metrics-reader le 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. Configurez RoleBinding pour Google Cloud Managed Service pour Prometheus :

   Selon que vous utilisez un cluster Autopilot ou Standard, vous devrez créer RoleBinding dans l'espace de noms gke-gmp-system ou gmp-system. Cette ressource permet au compte de service du collecteur d'accéder au secret kueue-metrics-reader-token pour authentifier et extraire les métriques 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. Configurez la ressource PodMonitoring :

   La ressource suivante configure la surveillance du déploiement Kueue. Elle spécifie que les métriques sont exposées sur le chemin d'accès /metrics via HTTPS. Il utilise le secret kueue-metrics-reader-token pour l'authentification lors du scraping des métriques.

   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
   

Interroger les métriques exportées

• Interroger les métriques exportées avec Cloud Monitoring
• Interroger les métriques exportées avec Grafana

Exemples de requêtes PromQL pour surveiller les systèmes basés sur Kueue

Ces requêtes PromQL vous permettent de surveiller les métriques Kueue clés telles que le débit des jobs, l'utilisation des ressources par file d'attente et les temps d'attente des charges de travail pour comprendre les performances du système et identifier les goulots d'étranglement potentiels.

Débit des jobs

Cela permet de calculer le taux par seconde des charges de travail admises sur cinq minutes pour chaque cluster_queue. Cette métrique peut vous aider à identifier les goulots d'étranglement en la ventilant par file d'attente. En l'additionnant, vous obtenez le débit global du système.

Requête :

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

Utilisation des ressources

Cela suppose que metrics.enableClusterQueueResources est activé. Il calcule le ratio entre l'utilisation actuelle du processeur et le quota nominal de processeurs pour chaque file d'attente. Une valeur proche de 1 indique une utilisation élevée. Vous pouvez l'adapter à la mémoire ou à d'autres ressources en modifiant le libellé de la ressource.

Pour installer une version disponible de Kueue avec une configuration personnalisée dans votre cluster, suivez la documentation de Kueue.

Requête :

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

Temps d'attente dans la file d'attente

Cela fournit le temps d'attente au 90e centile pour les charges de travail dans une file d'attente spécifique. Vous pouvez modifier la valeur du quantile (par exemple, 0,5 pour la médiane ou 0,99 pour le 99e centile) afin de comprendre la distribution du temps d'attente.

Requête :

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

Créer des jobs et observer les charges de travail acceptées

Dans cette section, vous allez créer des jobs Kubernetes dans les espaces de noms team-a et team-b. Dans Kubernetes, un contrôleur Job crée un ou plusieurs pods et s'assure qu'ils exécutent correctement une tâche spécifique.

Générez des tâches sur les deux ressources ClusterQueue, qui resteront en veille pendant 10 secondes, avec trois tâches parallèles et seront effectuées avec trois tâches terminées. Cela sera ensuite nettoyé au bout de 60 secondes.

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 crée des tâches sous l'espace de noms team-a et pointe vers la ressource LocalQueue lq-team-a et la ressource ClusterQueue cq-team-a.

De même, job-team-b.yaml crée des tâches sous l'espace de noms team-b, et pointe vers la ressource LocalQueue lq-team-b et la ressource ClusterQueue cq-team-b.

1. Démarrez un nouveau terminal et exécutez ce script pour générer une tâche toutes les secondes :

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

2. Démarrez un autre terminal et créez des tâches pour l'espace de noms team-b :

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

3. Observez les tâches en train d'être mises en file d'attente dans Prometheus. Ou à l'aide de la commande suivante :

   watch -n 2 kubectl get clusterqueues -o wide
   

La sortie devrait ressembler à ce qui suit :

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

Emprunter un quota inutilisé avec des cohortes

Les ressources ClusterQueue ne sont pas toujours saturées. L'utilisation des quotas n'est pas maximisée lorsque les charges de travail ne sont pas réparties uniformément entre les ressources ClusterQueue. Si les ressources ClusterQueue partagent la même cohorte entre elles, elles peuvent emprunter des quotas d'autres ressources ClusterQueue pour maximiser l'utilisation du quota.

1. Une fois que des tâches sont mises en file d'attente pour les ressources ClusterQueue cq-team-a et cq-team-b, arrêtez le script destiné à l'espace de noms team-b en appuyant sur CTRL+c dans le terminal correspondant.

2. Une fois que toutes les tâches en attente de l'espace de noms team-b sont traitées, les tâches de l'espace de noms team-a peuvent emprunter les ressources disponibles dans cq-team-b :

   kubectl describe clusterqueue cq-team-a
   

   Comme cq-team-a et cq-team-b partagent la même cohorte appelée all-teams, ces ressources ClusterQueue peuvent partager des ressources qui ne sont pas utilisées.

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

3. Reprenez le script pour l'espace de noms team-b.

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

   Observez comment les ressources empruntées de cq-team-a reviennent à 0, tandis que les ressources de cq-team-b sont utilisées pour leurs propres charges de travail :

   kubectl describe clusterqueue cq-team-a
   

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

Augmenter le quota avec des VM Spot

Lorsque le quota doit être temporairement augmenté, par exemple pour répondre à une demande élevée dans les charges de travail en attente, vous pouvez configurer Kueue pour répondre à la demande en ajoutant d'autres ressources ClusterQueue à la cohorte. Les ressources ClusterQueue avec des ressources inutilisées peuvent partager ces ressources avec d'autres ressources ClusterQueue appartenant à la même cohorte.

Au début du tutoriel, vous avez créé un pool de nœuds nommé spot à l'aide de VM Spot et une ressource ResourceFlavor nommée spot avec le libellé défini sur cloud.google.com/gke-provisioning: spot. Créez une ressource ClusterQueue pour utiliser ce pool de nœuds et la ressource ResourceFlavor qui le représente :

1. Créez une nouvelle ressource ClusterQueue appelée cq-spot avec la cohorte définie sur 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

   Étant donné que cette ressource ClusterQueue partage la même cohorte avec cq-team-a et cq-team-b, les ressources ClusterQueue cq-team-a et cq-team-b peuvent emprunter des ressources jusqu'à 15 requêtes de processeur et 15 Gio de mémoire.

   kubectl apply -f cq-spot.yaml
   

2. Dans Prometheus, observez comment les charges de travail admises augmentent pour cq-team-a et cq-team-b grâce au quota ajouté par cq-spot, qui partage la même cohorte. Ou à l'aide de la commande suivante :

   watch -n 2 kubectl get clusterqueues -o wide
   

3. Dans Prometheus, observez le nombre de nœuds du cluster. Ou à l'aide de la commande suivante :

   watch -n 2 kubectl get nodes -o wide
   

4. Arrêtez les deux scripts en appuyant sur CTRL+c pour les espaces de noms team-a et team-b.