Automatisation CI/CD de l’allocation dynamique des ressources Kubernetes avec exemples pratiques

Introduction

L’allocation dynamique des ressources (Dynamic Resource Allocation, DRA) de Kubernetes est une fonctionnalité relativement nouvelle, introduite en alpha dans la version 1.26 et évoluant vers la version bêta, qui généralise la manière dont les pods demandent et accèdent à du matériel spécialisé comme les GPU, les FPGA et les adaptateurs réseau. Contrairement aux plugins de périphériques traditionnels, la DRA permet aux administrateurs de clusters de définir des classes de ressources et aux utilisateurs de demander des ressources par nom, le planificateur et un pilote de ressources gérant le cycle de vie de l’allocation. Cette flexibilité est puissante, mais elle rend également l’automatisation CI/CD plus complexe : la disponibilité des ressources peut varier selon les nœuds, l’allocation est asynchrone et les pilotes peuvent nécessiter une installation et une configuration.

Cet article fournit un guide pratique pour construire des pipelines CI/CD pour les charges de travail qui utilisent l’allocation dynamique des ressources Kubernetes. Nous aborderons la découverte de la version et de l’environnement, les approches de configuration sûres, la vérification et le diagnostic, les modes de défaillance et la récupération, ainsi qu’une liste de contrôle opérationnelle. Chaque section comprend des commandes concrètes, des sorties attendues et des points de décision. À la fin, vous serez en mesure de créer des pipelines automatisés qui déploient des applications dépendantes de la DRA en toute sécurité, avec des chemins de retour en arrière clairs lorsque les allocations échouent.

Le public cible comprend les ingénieurs DevOps, les équipes de plateforme et les responsables techniques qui doivent gérer des charges de travail avec état et accélérées par le matériel dans Kubernetes. Nous supposons une familiarité avec les concepts de base de Kubernetes, kubectl et les outils CI/CD comme GitHub Actions ou GitLab CI.

Inventaire de la version et de l’environnement

Avant d’automatiser toute interaction avec la DRA, confirmez que votre cluster prend en charge la fonctionnalité et que les composants requis sont installés. La DRA repose sur deux parties principales :

• Le plan de contrôle Kubernetes avec la porte de fonctionnalité DynamicResourceAllocation activée (pour l’alpha dans la version 1.26, la bêta dans la version 1.27+ et la version stable dans les versions ultérieures).
• Un pilote de ressources qui implémente l’API DRA. Des exemples incluent le pilote DRA GPU NVIDIA, le pilote DRA Intel Device Plugins ou des pilotes personnalisés pour votre matériel.

Exécutez les vérifications en lecture seule suivantes pour inventorier votre environnement :

kubectl version --short
kubectl get nodes -o wide
kubectl get pods -n kube-system | grep -E 'dra|resource-driver'
kubectl get resourceclasses.resource.k8s.io
kubectl get resourceslices.resource.k8s.io

Sorties attendues :

• kubectl version doit afficher la version du serveur 1.26 ou ultérieure.
• kubectl get nodes doit lister tous les nœuds worker avec leur statut.
• La commande kubectl get pods -n kube-system listera les pods du pilote DRA ; si aucun n’apparaît, le pilote n’est pas installé.
• resourceclasses et resourceslices sont des ressources personnalisées ; si les API ne sont pas disponibles, la porte de fonctionnalité est désactivée ou les CRD sont manquantes.

Exemple d’un cluster sain :

$ kubectl get resourceclasses.resource.k8s.io
NAME              AGE
gpu.nvidia.com    5d

Si vous voyez error: the server doesn't have a resource type "resourceclasses", activez la porte de fonctionnalité sur le serveur d’API et le gestionnaire de contrôleurs, ou mettez à niveau vers une version où la DRA est bêta et activée par défaut.

Notes de compatibilité :

• La DRA est en alpha dans la version 1.26, elle nécessite donc la porte de fonctionnalité DynamicResourceAllocation=true sur kube-apiserver, kube-controller-manager et kube-scheduler.
• Dans les versions 1.27 et 1.28, la DRA est bêta et activée par défaut, mais l’API peut toujours être sous le groupe resource.k8s.io/v1alpha2.
• Consultez la documentation de votre pilote pour la compatibilité ; certains pilotes peuvent ne fonctionner qu’avec des versions spécifiques de Kubernetes.

Considération de sécurité : Utilisez un compte de service avec des autorisations en lecture seule pour ces vérifications dans le CI. Par exemple, créez un ClusterRole dra-reader avec get, list et watch sur les resourceclasses, resourceslices, pods et nœuds.

Une fois l’environnement vérifié, capturez-le dans une étape du pipeline. Pour GitHub Actions, un job d’inventaire simple pourrait être :

name: Environment Inventory
on: [workflow_dispatch]
jobs:
  inventory:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up kubectl
        uses: azure/setup-kubectl@v3
        with:
          version: 'v1.28.0'
      - name: Check DRA resources
        run: |
          kubectl version --short
          kubectl get resourceclasses.resource.k8s.io
          kubectl get resourceslices.resource.k8s.io

Cette étape s’exécute avant tout déploiement et échoue si les ressources DRA sont manquantes, ce qui évite des échecs ultérieurs.

Chemin de configuration sécurisé

Avec la DRA, la configuration doit être versionnée et appliquée de manière incrémentale. Les objets clés sont :

• ResourceClass : définit une classe de ressource (par exemple, gpu.nvidia.com) et référence un pilote.
• ResourceSlice : publié par le pilote pour annoncer les ressources disponibles sur les nœuds.
• ResourceClaim : une demande de ressource d’une classe spécifique, créée par un utilisateur ou un pod.
• Spécification de pod utilisant la demande : le pod référence la ResourceClaim pour obtenir la ressource allouée.

Une approche de configuration sûre consiste à utiliser un modèle GitOps où tous les manifestes DRA sont dans un dépôt et appliqués via un pipeline avec des étapes de révision. Voici un exemple de configuration DRA minimale :

ResourceClass :

apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClass
metadata:
  name: gpu.nvidia.com
driverName: dra.nvidia.com

ResourceClaim (modèle) :

apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClaimTemplate
metadata:
  name: gpu-claim-template
spec:
  metadata:
    labels:
      app: myapp
  spec:
    resourceClassName: gpu.nvidia.com

Pod utilisant le modèle de demande :

apiVersion: v1
kind: Pod
metadata:
  name: myapp-with-gpu
spec:
  containers:
  - name: app
    image: myapp:latest
    resources:
      claims:
      - name: gpu
  resourceClaims:
  - name: gpu
    source:
      resourceClaimTemplateName: gpu-claim-template

Lorsque vous appliquez ces manifestes, le contrôleur crée une ResourceClaim et le pilote alloue une ressource appropriée sur un nœud. Le pod ne sera planifié qu’après le succès de l’allocation.

Plus petit changement justifié : Appliquez toujours la ResourceClass et le pilote d’abord, testez avec une ResourceClaim statique, puis passez aux modèles. Évitez de modifier les configurations du pilote sans un déploiement canari complet.

Exemple de pipeline avec étape d’approbation : Dans GitHub Actions, vous pouvez utiliser des environnements avec des réviseurs requis pour contrôler l’étape d’application :

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - name: Apply DRA configuration
        run: |
          kubectl apply -f dra/ --dry-run=client
          kubectl apply -f dra/
          kubectl get resourceclaims

Le dry-run=client valide la syntaxe avant l’application. Après l’application, vérifiez le statut de la demande :

kubectl get resourceclaims
NAME                STATE
myapp-gpu-claim     allocated

Si le statut reste pending, vérifiez les journaux du pilote et la capacité des nœuds.

Vérification et diagnostic

La vérification va au-delà de la vérification du statut du pod. Comme la DRA implique une allocation asynchrone, vous devez vérifier toute la chaîne : demande créée, ressource allouée, pilote lié et conteneur démarré avec la ressource visible.

Commandes de vérification étape par étape :

1. Vérifiez les événements du pod :

kubectl describe pod myapp-with-gpu

Recherchez des événements comme :

Events:
  Type     Reason          Age   From               Message
  ----     ------          ----  ----               -------
  Normal   Scheduled       10s   default-scheduler  Successfully assigned default/myapp-with-gpu to node1
  Normal   Pulled          9s    kubelet            Container image "myapp:latest" already present on machine
  Normal   Created         9s    kubelet            Created container app
  Normal   Started         9s    kubelet            Started container app

1. Inspectez la ResourceClaim :

kubectl describe resourceclaim myapp-gpu-claim

La sortie doit montrer Allocation: allocated et le nom de la ResourceSlice.

1. Vérifiez la ressource à l’intérieur du conteneur :

kubectl exec myapp-with-gpu -- nvidia-smi

La sortie attendue comprend des informations sur le GPU, par exemple NVIDIA GeForce RTX 3090.

1. Vérifiez les journaux du pilote si l’allocation a échoué :

kubectl logs -n kube-system -l app=nvidia-dra-driver --tail=50

Signaux d’échec courants :

• Le pod reste en Pending avec l’événement FailedScheduling: no nodes available for resource claim.
• Le statut de la demande est pending sans allocation après plusieurs minutes.
• Les journaux du pilote affichent des erreurs comme insufficient resources ou driver not ready.

Script de diagnostic pour le CI : Ajoutez un job de vérification qui s’exécute après le déploiement et échoue si une vérification échoue :

- name: Verify DRA allocation
  run: |
    # Wait for Pod to be Running
    kubectl wait --for=condition=Ready pod/myapp-with-gpu --timeout=300s
    # Check claim status
    CLAIM_STATE=$(kubectl get resourceclaim myapp-gpu-claim -o jsonpath='{.status.allocation.result}')
    if [ "$CLAIM_STATE" != "allocated" ]; then
      echo "Claim not allocated"
      exit 1
    fi
    # Verify resource in container
    kubectl exec myapp-with-gpu -- nvidia-smi | grep -q 'NVIDIA'

Ce script utilise kubectl wait pour éviter les conditions de course, puis confirme l’allocation et la visibilité du périphérique.

Modes de défaillance et récupération

La DRA introduit de nouveaux modes de défaillance au-delà des problèmes de planification typiques. Comprendre ces modes aide à concevoir des stratégies de retour en arrière efficaces.

Modes de défaillance courants :

1. Pilote non installé ou mal configuré : Les ResourceClasses existent mais aucune ResourceSlice n’est publiée.

• Symptôme : kubectl get resourceslices.resource.k8s.io ne renvoie aucune ressource.
• Récupération : Installez/mettez à niveau le pilote, assurez-vous qu’il s’exécute sur tous les nœuds et vérifiez son RBAC.

1. Épuisement des ressources : Toutes les ressources d’une classe sont allouées à d’autres demandes.

• Symptôme : Les nouvelles demandes restent pending ; les ResourceSlices montrent allocated égal à capacity.
• Récupération : Libérez les demandes inutilisées manuellement :

     kubectl delete resourceclaim myapp-gpu-claim

Puis redéployez. Ou réduisez d’autres charges de travail qui détiennent des demandes.

1. Défaillance du nœud : Le nœud qui détient la ressource allouée tombe en panne.

• Symptôme : Le pod est expulsé ou bloqué en Terminating ; la demande peut être dans l’état reserved.
• Récupération : Supprimez le pod et la demande ; le planificateur allouera une nouvelle ressource sur un nœud sain si disponible.

1. Incompatibilité de version du pilote : Le pilote ne prend pas en charge la version actuelle de l’API DRA de Kubernetes.

• Symptôme : Les journaux du contrôleur affichent des erreurs d’API ; les demandes ne sont jamais allouées.
• Récupération : Mettez à niveau le pilote vers une version compatible ; consultez les notes de version du pilote pour la prise en charge des versions de Kubernetes.

Stratégie de retour en arrière : Dans le CI/CD, testez toujours le retour en arrière avant la production. Une procédure de retour en arrière simple pour un déploiement dépendant de la DRA :

# Rollback Deployment
kubectl rollout undo deployment/myapp
# If that fails, delete the Pod and claim
kubectl delete pod myapp-with-gpu
kubectl delete resourceclaim myapp-gpu-claim
# Redeploy previous version
kubectl apply -f previous-manifests/

Pour un retour en arrière automatisé dans GitHub Actions, utilisez un job qui s’exécute en cas d’échec :

on:
  workflow_run:
    workflows: ["Deploy"]
    types:
      - completed
jobs:
  rollback-on-failure:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          kubectl rollout undo deployment/myapp
          kubectl delete resourceclaim myapp-gpu-claim

Vérification de la récupération : Après le retour en arrière, assurez-vous que la version précédente s’exécute correctement :

kubectl rollout status deployment/myapp
kubectl get pods -l app=myapp

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après toute exécution de pipeline CI/CD impliquant la DRA. Elle est conçue pour être collée dans un ticket ou un runbook.

Liste de contrôle pré-déploiement :

1. La version de Kubernetes est 1.26+ (pour l’alpha) ou 1.27+ (pour la bêta) ; la porte de fonctionnalité est activée si nécessaire.

• Commande : kubectl version --short

1. Le pilote DRA est déployé et sain.

• Commande : kubectl get pods -n kube-system | grep dra (tous Running)

1. Les objets ResourceClass et ResourceSlice existent.

• Commande : kubectl get resourceclasses.resource.k8s.io, kubectl get resourceslices.resource.k8s.io

1. La capacité disponible est suffisante pour la nouvelle charge de travail.

• Commande : kubectl describe resourceslice <slice-name> | grep -A5 'Allocated resources'

1. Les manifestes ResourceClaim sont validés.

• Commande : kubectl apply --dry-run=client -f manifests/

1. Le plan de retour en arrière est documenté et testé en staging.

• Exemple : kubectl rollout undo deployment/myapp

Pendant le déploiement :

• Surveillez le statut de la demande : watch kubectl get resourceclaims -l app=myapp
• Observez les événements du pod : kubectl describe pod myapp-with-gpu
• Si la demande reste en attente plus de 5 minutes, vérifiez les journaux du pilote.

Vérification post-déploiement :

• Le pod est en cours d’exécution et prêt.
• Le statut de la ResourceClaim est allocated.
• Le périphérique est visible à l’intérieur du conteneur (par exemple, sortie nvidia-smi).
• Les performances de l’application sont acceptables (pas d’attente excessive sur la ressource).

Exemple de liste de contrôle remplie pour un déploiement spécifique :

Conclusion

L’allocation dynamique des ressources Kubernetes permet un partage flexible du matériel, mais elle exige une automatisation minutieuse. En inventoriant votre environnement, en appliquant les changements de manière incrémentale, en vérifiant les allocations avec des commandes concrètes et en vous préparant aux modes de défaillance, vous pouvez construire des pipelines CI/CD fiables pour les charges de travail accélérées par GPU et autres charges spécialisées.

Les points clés à retenir sont les suivants :

• Vérifiez toujours la compatibilité des versions et la santé du pilote avant de déployer quoi que ce soit qui utilise la DRA.
• Utilisez d’abord des vérifications en lecture seule et des dry-runs ; n’appliquez jamais sans validation.
• Surveillez toute la chaîne d’allocation : ResourceClaim, ResourceSlice, planification des pods.
• Ayez un chemin de retour en arrière clair et testez-le en staging.
• Automatisez les étapes de vérification pour détecter les échecs tôt.

Commencez par implémenter l’étape d’inventaire de l’environnement dans votre pipeline. Ajoutez ensuite l’application sécurisée avec dry-run et approbation. Enfin, intégrez les jobs de vérification et de retour en arrière. Avec ces éléments en place, vous pouvez gérer la DRA en production en toute confiance.