Commandes de quotas de ressources Kubernetes : guide opérationnel pratique

Introduction

Les quotas de ressources dans Kubernetes sont essentiels pour empêcher un seul espace de noms de consommer plus que sa juste part des ressources du cluster. Ils offrent aux équipes plateforme un point d'application strict pour le CPU, la mémoire, le stockage et le nombre d'objets. Sans eux, un déploiement incontrôlé ou un autoscaler mal configuré peut affamer d'autres charges de travail et déstabiliser tout le cluster.

Ce guide se concentre sur les commandes opérationnelles nécessaires pour créer, inspecter, modifier et dépanner les quotas de ressources Kubernetes. Il s'adresse aux développeurs, consultants DevOps et jeunes entreprises techniques qui gèrent des clusters multi-locataires ou des environnements partagés. Chaque section inclut des commandes kubectl concrètes, des manifestes YAML d'exemple, les sorties attendues et les étapes de récupération pour les modes de défaillance courants.

L'objectif est la sécurité opérationnelle : observer avant de changer, limiter le rayon d'impact, utiliser des paramètres génériques plutôt que des secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint. À la fin, vous serez capable d'appliquer des contraintes de ressources en toute confiance et de diagnostiquer les problèmes liés aux quotas en production.

Inventaire des versions et de l'environnement

Avant d'exécuter toute commande de quota, confirmez la version de l'environnement Kubernetes et les objets que vous inspectez. Le comportement des quotas de ressources a évolué au fil des versions, notamment avec l'introduction des portées (scopes) et des classes de priorité. Capturez toujours l'état actuel avant d'apporter des modifications.

Vérifier la version de Kubernetes

Exécutez la commande suivante pour identifier la version du cluster et garantir la compatibilité avec vos définitions de quota :

kubectl version --short

La sortie attendue ressemble à :

Client Version: v1.29.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.5

Si les versions majeures du client et du serveur diffèrent de plus d'une version mineure, mettez à niveau votre kubectl pour éviter les problèmes de compatibilité API. Les quotas de ressources sont disponibles dans toutes les versions modernes de Kubernetes, mais certains champs comme scopeSelector et matchScopes nécessitent la version 1.24 ou ultérieure.

Lister tous les quotas de ressources d'un espace de noms

Pour voir les quotas existants dans un espace de noms, utilisez :

kubectl get resourcequota -n <namespace>

Par exemple, dans un espace de noms nommé team-a, la sortie pourrait être :

NAME            AGE   REQUEST   LIMIT
compute-quota   3d    cpu: 2/10, memory: 1Gi/4Gi   cpu: 4/10, memory: 2Gi/4Gi
storage-quota   1d    requests.storage: 100Gi/500Gi

La colonne REQUEST montre l'utilisation actuelle et la limite stricte pour les ressources de type requête, tandis que LIMIT montre la même chose pour les ressources de type limite. Cette commande unique vous donne un contrôle rapide de l'état.

Inspecter les détails d'un quota

Utilisez kubectl describe pour obtenir la spécification complète et l'état actuel d'un quota :

kubectl describe resourcequota compute-quota -n team-a

Extrait de sortie attendu :

Name:         compute-quota
Namespace:    team-a
Resource      Used   Hard
--------      ----   ----
cpu           2      10
memory        1Gi    4Gi
pods          5      20
services      3      10

Si le quota n'apparaît pas, vérifiez que vous êtes dans le bon espace de noms et que vous disposez des autorisations RBAC appropriées. La commande kubectl auth can-i list resourcequotas -n team-a doit renvoyer yes.

Comparer l'utilisation des quotas entre les espaces de noms

Pour une vue d'ensemble multi-locataires, exécutez :

kubectl get resourcequota --all-namespaces

Cela liste tous les quotas du cluster, ce qui est utile pour identifier quelles équipes approchent de leurs limites. Vous pouvez filtrer avec grep ou awk par type de ressource ou pourcentage d'utilisation.

Chemin de configuration sécurisé

Modifier un quota de ressources peut avoir des effets immédiats sur les charges de travail en cours. Par exemple, abaisser une limite stricte en dessous de l'utilisation actuelle ne terminera pas les pods existants, mais bloquera la création de nouvelles ressources. Suivez ce chemin sécurisé pour minimiser les risques.

Étape 1 : Exporter le YAML du quota actuel

Avant de modifier un quota, sauvegardez une copie :

kubectl get resourcequota compute-quota -n team-a -o yaml > compute-quota-backup.yaml

Inspectez le fichier de sauvegarde pour comprendre la spécification actuelle. Cette sauvegarde est votre point de récupération si la nouvelle configuration cause des problèmes.

Étape 2 : Appliquer un petit changement bien testé

Au lieu de réécrire tout le quota, appliquez un correctif minimal. Par exemple, pour augmenter la limite stricte des requêtes CPU de 10 à 12, créez un fichier de correctif ou utilisez un correctif de fusion stratégique :

kubectl patch resourcequota compute-quota -n team-a --type merge -p '{"spec":{"hard":{"cpu":"12"}}}'

Sortie attendue :

resourcequota/compute-quota patched

Vérifiez toujours le correctif avec :

kubectl describe resourcequota compute-quota -n team-a

Confirmez que la colonne Hard affiche maintenant cpu: 12.

Étape 3 : Utiliser un chemin GitOps dédié en production

Pour les clusters de production, n'appliquez pas de modifications YAML brutes avec kubectl patch. Utilisez un dépôt Git avec un flux de demande de tirage (pull request). L'extrait suivant montre un manifeste de quota de ressources minimal dans Git :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "12"
    requests.memory: 4Gi
    limits.cpu: "20"
    limits.memory: 8Gi
    pods: "30"
    services: "10"

Après avoir fusionné la PR, un outil comme Argo CD ou Flux peut synchroniser le changement. Cette approche fournit une piste d'audit et un retour en arrière facile.

Étape 4 : Vérifier que le quota est appliqué

Après un changement de quota, testez que les nouvelles ressources sont évaluées par rapport aux limites mises à jour. Par exemple, créez un pod simple dans l'espace de noms :

kubectl create deployment test-pod --image=nginx -n team-a

Si le quota est dépassé, le pod ne sera pas créé et vous verrez une erreur comme :

Error from server (Forbidden): pods "test-pod" is forbidden: exceeded quota: compute-quota, requested: cpu=1, used: cpu=12, limited: cpu=12

Si vous devez supprimer le pod de test, utilisez kubectl delete pod test-pod -n team-a.

Étape 5 : Surveiller l'utilisation du quota dans le temps

Mettez en place une surveillance pour observer les changements de quota à mesure que les charges de travail évoluent :

kubectl get resourcequota compute-quota -n team-a --watch

Cela met à jour l'utilisation des ressources en temps réel. Vous pouvez également intégrer des métriques Prometheus comme kube_resourcequota pour créer des tableaux de bord et des alertes.

Vérification et diagnostics

La vérification va au-delà de la vérification de la spécification du quota ; elle garantit que le quota est correctement appliqué aux nouvelles charges de travail et que votre espace de noms est sain. Utilisez les commandes et techniques suivantes.

Vérifier qu'un quota est actif

Interrogez l'état du quota avec kubectl get et regardez les colonnes REQUEST et LIMIT. Un quota est actif s'il apparaît dans la liste et a des valeurs strictes non nulles.

kubectl get resourcequota compute-quota -n team-a

Sortie :

NAME            AGE   REQUEST                        LIMIT
compute-quota   5d    cpu: 3/12, memory: 1Gi/4Gi    cpu: 5/20, memory: 2Gi/8Gi

Si la colonne REQUEST ou LIMIT est vide, le quota peut ne pas suivre ces types de ressources. Vérifiez la spécification pour confirmer quelles ressources sont définies.

Vérifier quelle ressource bloque un pod

Lorsqu'un pod ne parvient pas à se planifier ou à se créer en raison d'un quota, le message d'erreur inclut souvent le nom du quota et la ressource dépassée. Pour plus de détails, décrivez le ReplicaSet ou le Deployment qui tente de créer le pod :

kubectl describe deployment my-app -n team-a

Recherchez des événements comme :

Warning  FailedCreate  5m    replicaset-controller  Error creating: pods "my-app-7b9f8b6c5-" is forbidden: exceeded quota: compute-quota, requested: memory=2Gi, used: memory=3.5Gi, limited: memory=4Gi

Cela vous indique exactement quel quota et quelle ressource bloquent.

Utiliser kubectl describe quota pour l'état complet

La sortie de description inclut l'utilisation pour toutes les ressources et, si des portées sont utilisées, le sélecteur de portée. Exemple :

Name:         compute-quota
Namespace:    team-a
Scopes:       NotTerminating
Resource      Used   Hard
--------      ----   ----
cpu           3      12
memory        1Gi    4Gi
pods          7      30

Si Scopes est listé, votre quota ne s'applique qu'aux pods ayant cette portée. Des portées mal configurées sont une raison courante pour laquelle un quota semble ne pas être appliqué.

Simuler un déploiement dépassant le quota

Pour tester vos limites de quota, déployez une charge de travail qui les dépasserait. Créez un fichier stress-pod.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: stress-pod
  namespace: team-a
spec:
  containers:
  - name: stress
    image: polinux/stress
    resources:
      requests:
        memory: "10Gi"
        cpu: "5"
      limits:
        memory: "12Gi"
        cpu: "6"

Appliquez-le et observez le rejet :

kubectl apply -f stress-pod.yaml

Erreur attendue :

Error from server (Forbidden): error when creating "stress-pod.yaml": pods "stress-pod" is forbidden: exceeded quota: compute-quota, requested: memory=10Gi, used: memory=1Gi, limited: memory=4Gi

Cela confirme que le quota est appliqué.

Auditer les changements de quota

Si vous avez besoin de savoir quand un quota a été modifié pour la dernière fois, vérifiez les métadonnées de la ressource :

kubectl get resourcequota compute-quota -n team-a -o jsonpath='{.metadata.managedFields[0].time}{"\n"}'

Pour une piste d'audit complète, activez la journalisation d'audit Kubernetes et filtrez pour resourcequotas.

Modes de défaillance et récupération

Les problèmes de quotas de ressources se manifestent souvent par des échecs de création de pods, des déploiements bloqués ou l'impossibilité de créer des services. Cette section couvre les modes de défaillance courants et les étapes de récupération.

Défaillance : La création de pod échoue avec « Exceeded Quota »

C'est la défaillance la plus courante. Le message d'erreur indiquera le nom du quota et la ressource qui dépasse la limite. Pour récupérer, augmentez le quota (si justifié) ou réduisez les requêtes de ressources du pod.

Option 1 : Augmenter le quota

kubectl patch resourcequota compute-quota -n team-a --type merge -p '{"spec":{"hard":{"memory":"6Gi"}}}'

Option 2 : Réduire la requête mémoire du pod

Modifiez le déploiement et changez resources.requests.memory pour une valeur qui tient dans le quota actuel. Appliquez ensuite le changement et le pod devrait se créer.

Défaillance : Le quota ne semble pas être appliqué

Si des pods sont créés malgré le dépassement du quota, vérifiez les points suivants :

• Portées : Un quota avec scopes: ["Terminating"] ne s'applique qu'aux pods ayant activeDeadlineSeconds défini. Une incohérence peut faire que le quota soit ignoré pour les pods réguliers.
• Espace de noms : Assurez-vous que le quota est dans le même espace de noms que les pods.
• Noms de ressources : Le quota doit spécifier le même type de ressource que le champ de ressource du pod. Par exemple, requests.cpu vs cpu.

Utilisez kubectl describe resourcequota <name> -n <ns> pour examiner la spécification.

Défaillance : Impossible de supprimer un espace de noms à cause d'un quota

Parfois, un espace de noms reste bloqué en état Terminating parce qu'un quota bloque le nettoyage du finaliseur. Pour résoudre, vérifiez d'abord s'il reste des ressources :

kubectl get all -n stuck-ns

Supprimez tous les pods ou services restants. Si le quota a des finaliseurs, supprimez-les après sauvegarde :

kubectl patch resourcequota <quota-name> -n stuck-ns -p '{"metadata":{"finalizers":[]}}' --type=merge

Forcez ensuite la suppression de l'espace de noms :

kubectl delete namespace stuck-ns --grace-period=0 --force

Soyez extrêmement prudent avec la suppression forcée ; ne le faites qu'après avoir confirmé qu'aucune donnée critique ne reste.

Défaillance : L'utilisation du quota ne se met pas à jour

Si les chiffres d'utilisation dans kubectl get resourcequota ne changent pas après la suppression de ressources, cela peut être un délai du contrôleur ou un bogue. D'abord, attendez quelques minutes. Ensuite, vérifiez les journaux du gestionnaire de contrôleurs :

kubectl logs -n kube-system kube-controller-manager-<node> | grep -i quota

Si le contrôleur est sain mais que l'utilisation est périmée, vous pouvez forcer une mise à jour en redémarrant le contrôleur (uniquement si vous avez les droits d'administrateur du cluster).

Récupération : Revenir sur un changement de quota

Si vous avez appliqué un changement de quota qui a causé une panne, revenez en arrière avec votre YAML de sauvegarde :

kubectl apply -f compute-quota-backup.yaml

Si vous utilisez GitOps, annulez le commit dans Git et laissez le contrôleur se synchroniser. Gardez toujours des sauvegardes pendant au moins 30 jours.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant et après avoir apporté des modifications de quotas de ressources en production.

Liste de contrôle avant changement

• Identifiez l'espace de noms et le nom du quota.
• Enregistrez l'utilisation actuelle avec kubectl describe resourcequota <name> -n <ns> et sauvegardez la sortie dans un fichier.
• Sauvegardez le YAML du quota avec kubectl get resourcequota <name> -n <ns> -o yaml > backup.yaml.
• Déterminez les nouvelles limites souhaitées en fonction de la croissance projetée de la charge de travail.
• Vérifiez les autorisations RBAC de l'utilisateur effectuant le changement avec kubectl auth can-i update resourcequotas -n <ns>.
• Avertissez les équipes concernées si le changement pourrait bloquer leurs déploiements.

Liste de contrôle d'exécution du changement

• Appliquez le changement via GitOps ou kubectl apply/kubectl patch.
• Vérifiez immédiatement avec kubectl describe resourcequota <name> -n <ns> et confirmez la colonne Hard.
• Testez en créant un petit pod (si approprié) pour vous assurer que le quota se comporte comme prévu.
• Surveillez kubectl get resourcequota <name> -n <ns> --watch pendant quelques minutes.

Liste de contrôle de validation après changement

• Vérifiez que les charges de travail existantes fonctionnent toujours : kubectl get pods -n <ns>
• Recherchez de nouveaux événements de violation de quota : kubectl get events -n <ns> | grep quota
• Confirmez que l'utilisation du quota est dans des limites acceptables.
• Mettez à jour la documentation et les tableaux de bord avec les nouvelles limites.
• Assurez-vous que la sauvegarde est stockée dans un emplacement sécurisé.

Liste de contrôle d'audit mensuel

• Listez tous les quotas dans tous les espaces de noms : kubectl get resourcequota --all-namespaces
• Identifiez les quotas trop serrés (utilisation > 80 % de la limite stricte) ou trop lâches (utilisation < 20 % sans croissance).
• Vérifiez si les requêtes de ressources dans les déploiements sont correctement définies.
• Vérifiez si des quotas sont orphelins ou non utilisés.
• Planifiez des ajustements en fonction des prévisions de capacité.

Conclusion

Les quotas de ressources Kubernetes sont un outil puissant pour maintenir l'équité et la stabilité dans les clusters partagés. En maîtrisant les commandes de ce guide, vous pouvez appliquer des limites de ressources de manière proactive, diagnostiquer rapidement les défaillances liées aux quotas et récupérer en toute sécurité.

Comme prochaine étape, choisissez une vérification à faible risque de cet article, comme lister les quotas dans un espace de noms de test ou simuler un pod dépassant le quota. Enregistrez l'état actuel, exécutez les commandes documentées, comparez les résultats avec la sortie attendue et pratiquez le processus de récupération. Portez attention aux domaines connexes comme les plages de limites (Limit Ranges), les frontières des espaces de noms et les spécifications des pods, car ils affectent directement l'application des quotas.

Un flux de travail opérationnel fiable rend la défaillance visible, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision. Avec ces pratiques, vous pouvez garder vos clusters Kubernetes sains et vos équipes de développement productives.