Dépannage des quotas de ressources Kubernetes : guide pratique de terrain

Introduction

Les quotas de ressources Kubernetes (Resource Quotas) sont un contrôle essentiel pour les clusters mutualisés et partagés. Ils limitent la consommation totale de ressources d'un espace de noms (namespace), empêchant une seule équipe ou charge de travail d'affamer les autres. Lorsqu'un quota est dépassé, les pods ne peuvent pas être planifiés, les services peuvent se dégrader et le dépannage peut devenir déroutant si vous ne savez pas où chercher.

Ce guide propose une approche pratique, étape par étape, pour diagnostiquer et résoudre les problèmes de quotas de ressources Kubernetes. Il s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui doivent passer rapidement et en toute sécurité d'un problème observé à un résultat vérifié.

Nous couvrons l'inventaire de la version et de l'environnement, les chemins de configuration sûrs, la vérification et le diagnostic, les modes de défaillance, les procédures de récupération et une liste de contrôle opérationnelle. Chaque section comprend des commandes concrètes, les sorties attendues et des conseils de décision. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint.

Inventaire de la version et de l'environnement

Avant de dépanner tout problème de quota de ressources, vous devez savoir exactement avec quoi vous travaillez. Commencez par identifier la version de Kubernetes, la configuration du quota et l'utilisation actuelle dans l'espace de noms concerné. Cela établit une base de référence et évite des modifications accidentelles sur le mauvais objet.

Déterminer la version du cluster et du client

Exécutez :

kubectl version --short

Sortie attendue (exemple) :

Client Version: v1.27.3
Kustomize Version: v5.0.1
Server Version: v1.27.2

Si votre client est nettement plus ancien que le serveur, certains champs de ResourceQuota peuvent ne pas être pris en charge. Mettez à jour kubectl pour correspondre à la version mineure du serveur lorsque cela est possible.

Inspecter les quotas de ressources existants

Listez tous les objets ResourceQuota dans l'espace de noms :

kubectl get resourcequota -n my-namespace

Exemple de sortie :

NAME           AGE   REQUEST    LIMIT
compute-quota  5d    requests.cpu: 2/4, requests.memory: 2Gi/8Gi, limits.cpu: 4/8, limits.memory: 4Gi/16Gi

Les colonnes REQUEST et LIMIT montrent l'utilisation actuelle et les limites strictes. Si l'utilisation est proche ou égale à la limite, vous avez probablement un problème de quota.

Pour une vue détaillée :

kubectl describe resourcequota compute-quota -n my-namespace

Extrait d'exemple :

Name:            compute-quota
Namespace:       my-namespace
Resource         Used    Hard
--------         ----    ----
requests.cpu     2       4
requests.memory  2Gi     8Gi
limits.cpu       4       8
limits.memory    4Gi     16Gi

Vérifier les libellés et annotations de l'espace de noms

Les quotas de ressources peuvent être limités à des classes de priorité spécifiques ou à des sélecteurs. Vérifiez les libellés de l'espace de noms :

kubectl get namespace my-namespace --show-labels

Exemple :

NAME           STATUS   AGE   LABELS
my-namespace   Active   12d   team=backend, environment=production

Identifier les pods et leurs demandes/limites de ressources

Une cause fréquente d'épuisement de quota est un pod qui demande plus de ressources que prévu. Listez les pods avec leurs demandes et limites de ressources à l'aide d'une colonne personnalisée :

kubectl get pods -n my-namespace -o custom-columns='NAME:.metadata.name,CPU_REQ:.spec.containers[*].resources.requests.cpu,MEM_REQ:.spec.containers[*].resources.requests.memory,CPU_LIM:.spec.containers[*].resources.limits.cpu,MEM_LIM:.spec.containers[*].resources.limits.memory'

Exemple de sortie :

NAME                    CPU_REQ   MEM_REQ   CPU_LIM   MEM_LIM
web-6c9d8f7b5d-abcde    250m      256Mi     500m      512Mi
worker-7f8b9c6d5e-fghij 500m      512Mi     1         1Gi

Comparez ces valeurs avec l'utilisation du quota. Si un pod a été récemment créé ou mis à jour, il a pu pousser l'utilisation au-delà de la limite.

Chemin de configuration sûr

Lorsque vous devez ajuster des quotas ou des demandes de ressources, suivez un chemin de configuration sûr. Cela minimise les perturbations et permet un retour en arrière rapide si nécessaire.

Ne modifiez jamais directement les manifestes en direct

Utilisez des manifestes contrôlés par version. Par exemple, une définition de ResourceQuota pourrait être :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: my-namespace
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi

Stockez ceci dans Git et appliquez les changements via un pipeline de déploiement ou kubectl apply.

Faites des changements incrémentaux

Si vous devez augmenter un quota, augmentez-le d'une petite quantité et observez. Par exemple, pour augmenter les demandes de CPU de 4 à 5 cœurs, modifiez le manifeste :

requests.cpu: "5"

Appliquez le changement :

kubectl apply -f resourcequota.yaml

Vérifiez :

kubectl get resourcequota compute-quota -n my-namespace

La colonne REQUEST devrait maintenant montrer la nouvelle limite stricte.

Utilisez kubectl patch pour des ajustements rapides

Pour un changement temporaire, vous pouvez appliquer un patch directement :

kubectl patch resourcequota compute-quota -n my-namespace --type='json' -p='[{"op": "replace", "path": "/spec/hard/requests.cpu", "value": "5"}]'

Vérifiez avec :

kubectl get resourcequota compute-quota -n my-namespace -o jsonpath='{.spec.hard.requests.cpu}'

Sortie attendue :

5

Ajuster les demandes de ressources des pods

Si le problème vient d'un pod qui demande trop, réduisez ses demandes plutôt que d'augmenter le quota. Modifiez le déploiement :

kubectl edit deployment web -n my-namespace

Trouvez la spécification du conteneur et changez :

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"

Enregistrez et quittez. Le déploiement va dérouler un nouveau pod avec des demandes plus faibles, libérant du quota pour d'autres charges de travail.

Vérification et diagnostic

Après avoir effectué des modifications, vérifiez que le problème est résolu et comprenez pourquoi il s'est produit. Cette section couvre les commandes de diagnostic et l'interprétation des résultats.

Vérifier les événements récents

Les événements Kubernetes contiennent souvent des messages liés aux quotas. Listez les événements triés par heure :

kubectl get events -n my-namespace --sort-by=.lastTimestamp

Exemple d'événement de quota dépassé :

LAST SEEN   TYPE      REASON             OBJECT                MESSAGE
2m          Warning   FailedCreate       replicaset/web-...    (combined from similar events): Error creating: pods "web-..." is forbidden: exceeded quota: compute-quota, requested: requests.cpu=250m,requests.memory=256Mi, used: requests.cpu=4000m,requests.memory=8192Mi, limited: requests.cpu=4,requests.memory=8Gi

Cela montre clairement le nom du quota, la ressource demandée, l'utilisation actuelle et la limite stricte.

Vérifier le statut et les descriptions des pods

Lorsqu'un pod ne peut pas être créé en raison d'un quota, il n'apparaîtra pas dans get pods car il n'a jamais été admis. À la place, vérifiez le statut du replicaset ou du déploiement :

kubectl get deployment web -n my-namespace

La sortie peut montrer :

NAME   READY   UP-TO-DATE   AVAILABLE   AGE
web    2/3     3            2           1h

Décrivez le déploiement pour voir les conditions :

kubectl describe deployment web -n my-namespace

Cherchez une condition comme :

ReplicaFailure   True    FailedCreate

Inspectez ensuite les événements du replicaset comme ci-dessus.

Utiliser kubectl describe sur ResourceQuota

Cela donne un instantané de l'utilisation par rapport aux limites strictes :

kubectl describe resourcequota compute-quota -n my-namespace

Si l'utilisation est égale à la limite stricte pour une ressource, cette ressource est saturée. Vous devez soit réduire les demandes, soit augmenter le quota.

Vérifier les journaux du serveur API pour les refus d'admission

Si vous avez accès aux journaux du serveur API Kubernetes, recherchez l'espace de noms et le nom du quota :

grep "exceeded quota" /var/log/kubernetes/kube-apiserver.log | tail -20

Cela peut fournir un contexte supplémentaire, surtout si les événements ont expiré.

Modes de défaillance et récupération

Comprendre les modes de défaillance courants vous aide à récupérer plus rapidement. Voici des scénarios et des étapes de récupération recommandées.

Mode de défaillance 1 : Les nouveaux pods ne peuvent pas être planifiés

Symptôme : Le déploiement montre moins de répliques que souhaité, et les événements montrent exceeded quota (quota dépassé).

Diagnostic : Le quota pour une ou plusieurs ressources est épuisé.

Récupération :

1. Identifiez la ressource épuisée à partir des événements ou de la description du quota.
2. Si possible, réduisez les demandes de ressources du nouveau pod ou d'autres pods dans l'espace de noms pour libérer du quota.
3. Sinon, augmentez la limite stricte du quota pour cette ressource, mais seulement après avoir confirmé la capacité du cluster.
4. Vérifiez que le déploiement monte en charge : kubectl rollout status deployment/web -n my-namespace

Mode de défaillance 2 : Pods existants évincés ou terminés

Symptôme : Les pods sont tués, et le nœud montre de la pression.

Diagnostic : Ce n'est généralement pas un problème de ResourceQuota mais une pression de ressources au niveau du nœud. Cependant, si un quota est défini pour requests.storage et qu'une demande de volume persistant le dépasse, les nouvelles PVC seront rejetées.

Récupération :

• Vérifiez les conditions du nœud : kubectl describe node <node-name> | grep -A5 Conditions
• Si le quota de stockage est dépassé, supprimez les PVC inutilisées ou augmentez le quota.
• Si pression du nœud, cordonnez et drainez le nœud, ou ajoutez de la capacité.

Mode de défaillance 3 : Quota non appliqué

Symptôme : L'utilisation des ressources dépasse les limites du quota sans rejet.

Diagnostic : L'objet ResourceQuota pourrait être mal configuré ou non appliqué à l'espace de noms. Vérifiez que l'espace de noms a les bons libellés si vous utilisez des sélecteurs de quota.

Récupération :

• Vérifiez que le quota existe : kubectl get resourcequota -n my-namespace
• Vérifiez si le quota a spec.scopeSelector ou spec.scopes qui excluent certains pods.
• Assurez-vous que le quota n'est pas dans un autre espace de noms.
• Réappliquez le manifeste du quota s'il est manquant.

Mode de défaillance 4 : Pods avec classes de priorité

Symptôme : Les pods de haute priorité sont évincés ou ne peuvent pas être créés.

Diagnostic : Les quotas peuvent être limités à des classes de priorité. Si un quota a scopeSelector correspondant à une classe de haute priorité, il peut être limité.

Récupération :

• Examinez le quota : kubectl get resourcequota compute-quota -n my-namespace -o yaml
• Si nécessaire, ajustez le quota ou la priorité du pod.

Vérification de la récupération

Après toute action de récupération, vérifiez toujours :

kubectl get resourcequota -n my-namespace
kubectl get pods -n my-namespace
kubectl get events -n my-namespace --sort-by=.lastTimestamp | tail -10

Assurez-vous que l'utilisation est dans les limites et qu'aucune nouvelle erreur de quota n'apparaît.

Liste de contrôle opérationnelle

Utilisez cette liste pour assurer une approche systématique du dépannage et de la récupération des quotas de ressources.

Conclusion

Le dépannage des quotas de ressources Kubernetes exige une approche méthodique : comprendre votre environnement, faire des changements minimaux, vérifier soigneusement et être prêt à récupérer. En suivant les étapes de ce guide, vous pouvez rapidement diagnostiquer les problèmes liés aux quotas et rétablir le service sans causer de perturbations supplémentaires.

Rappelez-vous toujours d'observer avant de modifier, de protéger les valeurs sensibles et de documenter vos actions. Avec les bonnes commandes et une liste de contrôle systématique, les problèmes de ResourceQuota deviennent gérables plutôt que mystérieux. Comme prochaine étape, exécutez les trois premières commandes de diagnostic dans votre propre cluster pour établir une base de référence, et entraînez-vous à ajuster un quota dans un espace de noms hors production.