Kubernetes Allocation Dynamique des Ressources : Erreurs de configuration pratiques et comment les éviter

Introduction

L’allocation dynamique des ressources (Dynamic Resource Allocation ou DRA) de Kubernetes est une fonctionnalité puissante qui permet une allocation fine de ressources matérielles spécialisées, comme les GPU, les FPGA ou les adaptateurs réseau, aux charges de travail. Contrairement aux demandes et limites traditionnelles de ressources pour le CPU et la mémoire, la DRA permet d’allouer dynamiquement et de partager des ressources entre les pods selon la disponibilité et des exigences précises. Cependant, une mauvaise configuration de la DRA peut entraîner des échecs de planification, des fuites de ressources ou une instabilité du cluster.

Cet article présente des erreurs de configuration pratiques à éviter lors de l’utilisation de la DRA de Kubernetes. Il inclut des exemples concrets, des commandes et des sorties attendues pour vous aider à valider, à revenir en arrière et à dépanner les configurations DRA de manière efficace. Le public visé comprend les développeurs, les consultants DevOps et les équipes techniques de startups qui ont besoin d’une sécurité opérationnelle : observer avant de modifier, limiter le rayon d’impact, utiliser des espaces réservés au lieu de secrets, vérifier les résultats et documenter les chemins de récupération.

Nous couvrirons l’inventaire des versions et de l’environnement, les chemins de configuration sûrs, la vérification et les diagnostics, les modes de défaillance et la récupération, et une liste de contrôle opérationnelle. Chaque section comprend des scénarios réels et des bonnes pratiques pour garder votre cluster stable et votre allocation de ressources prévisible.

Inventaire des versions et de l’environnement

Avant de configurer la DRA, vous devez connaître votre version de Kubernetes, les pilotes de ressources installés et la topologie du cluster. La DRA nécessite Kubernetes v1.26 ou ultérieure avec la porte de fonctionnalité DynamicResourceAllocation activée (elle est devenue bêta en v1.31 et est activée par défaut à partir de v1.32 pour certaines API). De plus, un pilote de ressources (par exemple, un contrôleur spécifique au fournisseur) doit être déployé dans le cluster pour gérer les ressources.

Commencez par un inventaire en lecture seule :

kubectl version
kubectl get nodes -o wide
kubectl get pods -n kube-system | grep -E 'dra|resource'

Exemple de sortie :

Client Version: v1.31.0
Server Version: v1.31.0
NAME                 STATUS   ROLES           AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
control-plane        Ready    control-plane   10d   v1.31.0   10.0.0.2      <none>        Ubuntu 22.04.3 LTS   5.15.0-91-generic   containerd://1.7.11
worker-1             Ready    <none>          10d   v1.31.0   10.0.0.3      <none>        Ubuntu 22.04.3 LTS   5.15.0-91-generic   containerd://1.7.11
worker-2             Ready    <none>          10d   v1.31.0   10.0.0.4      <none>        Ubuntu 22.04.3 LTS   5.15.0-91-generic   containerd://1.7.11
...

Vérifiez si la porte de fonctionnalité DRA est activée :

kubectl get --raw /metrics | grep -i dynamic_resource_allocation

Si aucune sortie n’apparaît, la porte de fonctionnalité est peut-être désactivée.

Vérifiez également que le pilote de ressources est en cours d’exécution et que ses CRD sont installées :

kubectl get crd | grep -E 'resources|allocation'

Par exemple, si vous utilisez le pilote DRA GPU d’exemple, vous pourriez voir :

NAME                                             CREATED AT
resources.gpu.example.com                        2024-01-15T10:00:00Z
resourceclaims.resource.k8s.io                   2024-01-15T10:00:00Z

Conservez cet inventaire dans un runbook. Ne procédez à des modifications qu’après avoir enregistré l’état actuel et confirmé les prérequis.

Chemin de configuration sûr

Lors de la configuration de la DRA, appliquez les modifications progressivement et observez chaque étape. Commencez par un petit pod de test qui demande une seule revendication de ressource, puis vérifiez l’allocation avant de passer à l’échelle.

Créez une ResourceClaim et un ResourceClaimTemplate. Dans Kubernetes v1.31+, ResourceClaim est un objet à portée de cluster. Voici un exemple de revendication pour une ressource GPU fournie par un pilote nommé gpu.example.com :

apiVersion: resource.k8s.io/v1alpha3
kind: ResourceClaim
metadata:
  name: my-gpu-claim
spec:
  devices:
    requests:
    - name: gpu
      count: 1
      deviceClassName: gpu.example.com

Appliquez-la et vérifiez son état :

kubectl apply -f claim.yaml
kubectl get resourceclaim my-gpu-claim -o yaml

La sortie attendue peut montrer :

status:
  allocation:
    devices:
      results:
      - device: gpu-0
        driver: gpu.example.com
        pool: default
        request: gpu
  reservedFor:
  - resource: pods
    name: null

Ensuite, créez un pod qui utilise cette revendication :

apiVersion: v1
kind: Pod
metadata:
  name: test-gpu-pod
spec:
  containers:
  - name: cuda-app
    image: nvidia/cuda:12.2.0-base-ubuntu22.04
    command: ["nvidia-smi"]
    resources:
      claims:
      - name: gpu
        resourceClaimName: my-gpu-claim

Avant de l’appliquer, assurez-vous que l’espace de noms existe et que vous avez les autorisations nécessaires. Appliquez ensuite et surveillez les événements :

kubectl apply --server-side -f pod.yaml
kubectl get events --field-selector involvedObject.name=test-gpu-pod --watch

Si le pod est planifié et exécute nvidia-smi, vous devriez voir une sortie indiquant le GPU alloué. Sinon, passez aux diagnostics.

Conservez toujours les versions de configuration sous contrôle de version et utilisez la simulation (dry-run) avant d’appliquer les changements aux clusters en production :

kubectl apply --server-side -f pod.yaml --dry-run=client

Vérification et diagnostics

Après avoir appliqué une configuration DRA, vérifiez que la ressource a bien été allouée et que le pod l’utilise. Utilisez kubectl describe sur le pod et la revendication de ressource :

kubectl describe pod test-gpu-pod
kubectl describe resourceclaim my-gpu-claim

Recherchez des événements comme ResourceClaim created, Pod scheduled et l’état d’allocation du pilote.

Pour voir les journaux du pod :

kubectl logs test-gpu-pod

Si le pod échoue, vérifiez les journaux du conteneur précédent :

kubectl logs test-gpu-pod --previous

Par exemple, si le pilote GPU n’est pas installé, vous pourriez voir :

Error: NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.

Cela indique que le nœud ne possède pas le pilote, et non une mauvaise configuration de la DRA.

Pour vérifier l’état du contrôleur du pilote DRA :

kubectl get pods -n kube-system -l app=gpu-dra-driver
kubectl logs -n kube-system <driver-pod-name>

Erreur courante : ResourceClass not found signifie que le deviceClassName dans votre revendication ne correspond à aucune ResourceClass déployée. Vérifiez avec :

kubectl get resourceclasses

Si votre revendication reste à l’état Pending, inspectez ses événements :

kubectl describe resourceclaim my-gpu-claim

Événement attendu en cas d’indisponibilité :

Events:
  Type     Reason              Age   From               Message
  ----     ------              ----  ----               -------
  Warning  ResourceUnavailable 2m    gpu-dra-driver     no devices available for request 'gpu'

Modes de défaillance et récupération

Les échecs courants de configuration DRA comprennent :

1. Porte de fonctionnalité désactivée : Si la porte de fonctionnalité DynamicResourceAllocation n’est pas activée, la création d’une ResourceClaim échouera avec une erreur du type the server could not find the requested resource. Activez-la dans les configurations du kube-apiserver et du kube-controller-manager.
2. Pilote non exécuté : Si le pod du pilote de ressources n’est pas en cours d’exécution, les revendications resteront non allouées. Assurez-vous que le déploiement du pilote est sain et que son compte de service dispose des autorisations RBAC nécessaires.
3. Ressources insuffisantes sur les nœuds : Si aucun nœud ne possède le périphérique demandé, le pod ne sera pas planifié. Utilisez kubectl describe node pour vérifier les ressources allouables et la capacité signalée par le pilote.
4. Versions d’API incompatibles : La DRA a évolué à travers v1alpha2, v1alpha3 et v1beta1. Assurez-vous que vos manifestes correspondent à la version servie par votre cluster. Vérifiez avec kubectl api-versions | grep resource.k8s.io.

Étapes de récupération :

• Pour revenir en arrière sur une configuration problématique, supprimez le pod et la revendication, puis réappliquez une version connue comme bonne :

kubectl delete pod test-gpu-pod --grace-period=0 --force
kubectl delete resourceclaim my-gpu-claim
kubectl apply -f known-good-pod.yaml

• Si une mise à niveau du pilote a causé des problèmes, revenez au déploiement du pilote précédent :

kubectl rollout undo deployment/gpu-dra-driver -n kube-system
kubectl rollout status deployment/gpu-dra-driver -n kube-system

• Si un nœud devient défectueux, isolez-le pour empêcher de nouvelles planifications :

kubectl cordon worker-2

Puis videz-le après vous être assuré qu’aucun pod critique ne reste :

kubectl drain worker-2 --ignore-daemonsets --delete-emptydir-data

Documentez toujours les procédures de récupération et testez-les dans un environnement de préproduction.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après toute modification de configuration DRA :

• [ ] Confirmez la version de Kubernetes et l’état de la porte de fonctionnalité (kubectl version, vérifiez les ressources API).
• [ ] Vérifiez que le pilote de ressources est en cours d’exécution et sain (kubectl get pods -n kube-system).
• [ ] Examinez les ResourceClaims actuelles et leurs états (kubectl get resourceclaims -A).
• [ ] Appliquez les modifications en utilisant d’abord --dry-run=client.
• [ ] Limitez la portée : modifiez une seule revendication ou un seul pod à la fois.
• [ ] Surveillez les événements pendant le déploiement (kubectl get events --watch).
• [ ] Vérifiez l’allocation avec kubectl describe sur la revendication et le pod.
• [ ] Consultez les journaux de l’application et du pilote.
• [ ] En cas d’échec, suivez les étapes de retour en arrière et documentez l’incident.
• [ ] Après une vérification réussie, stockez les manifestes fonctionnels dans le contrôle de version.

Exemple de workflow de vérification de déploiement :

# Simulation
kubectl apply -f claim.yaml --dry-run=client
# Application de la revendication
kubectl apply -f claim.yaml
# Vérification de l’état de la revendication
kubectl get resourceclaim my-gpu-claim -o wide
# Si l’état montre alloué, appliquez le pod
kubectl apply --server-side -f pod.yaml
# Surveillance du pod
kubectl get pods test-gpu-pod --watch
# Vérification des journaux
kubectl logs test-gpu-pod

Conclusion

L’allocation dynamique des ressources de Kubernetes offre des capacités puissantes pour la gestion de matériel spécialisé, mais elle exige une configuration et une exploitation soignées. En suivant les pratiques décrites dans cet article — commencer par un inventaire des versions et de l’environnement, appliquer les modifications en toute sécurité, vérifier les allocations, connaître les modes de défaillance et la récupération, et utiliser une liste de contrôle opérationnelle — vous pouvez éviter les erreurs courantes et maintenir un cluster stable.

Comme prochaine étape, choisissez une vérification DRA à faible risque dans votre environnement : enregistrez l’état actuel, appliquez une revendication et un pod minimaux, observez l’allocation et comparez avec les sorties attendues. Passez en revue les dépendances telles que les plugins de périphériques, les limites de ressources des nœuds et le RBAC pour le pilote. Un workflow fiable rend les défaillances visibles, protège les valeurs sensibles et garantit que la récupération est définie avant qu’un incident ne force une décision.