## 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.
Question rapide 1 sur 2 Quel est l'objectif principal des Resource Quotas Kubernetes ? - Limiter le nombre de nœuds dans un cluster - Limiter la consommation totale de ressources d'un namespace - Restreindre l'accès à l'API Kubernetes - Appliquer des politiques réseau
Les Resource Quotas sont utilisés pour gérer l'utilisation des ressources des workloads des locataires, en limitant la quantité totale de ressources qu'un namespace peut consommer.
## 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é.
Question rapide 2 sur 2 Que décrit le champ `.status.allocatable` d'un Node ? - La capacité totale du Node - La quantité de ressources disponibles pour les Pods sur ce Node - Les demandes de ressources de tous les Pods sur le Node - Les limites de ressources de tous les Pods sur le Node
Le champ `.status.allocatable` décrit la quantité de ressources disponibles pour les Pods sur ce Node, en tenant compte des démons système.
## 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 : - Identifiez la ressource épuisée à partir des événements ou de la description du quota. - 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. - Sinon, augmentez la limite stricte du quota pour cette ressource, mais seulement après avoir confirmé la capacité du cluster. - 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 | 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.
ÉtapeActionCommande / VérificationRésultat attendu
1Identifier la version du clusterkubectl version --shortVersions client et serveur compatibles
2Lister les quotas dans l'espace de nomskubectl get resourcequota -n my-namespaceL'objet quota existe avec des limites strictes
3Vérifier l'utilisation actuellekubectl describe resourcequota compute-quota -n my-namespaceValeurs utilisées inférieures ou égales aux limites strictes
4Inspecter les événements récentskubectl get events -n my-namespace --sort-by=.lastTimestampAucun avertissement récent exceeded quota
5Examiner les demandes de ressources des podskubectl get pods -n my-namespace -o custom-columns=...Somme des demandes inférieure à la limite stricte du quota
6Si quota épuisé, identifier quelle ressourceÀ partir de la description ou des événementsRessource spécifique (cpu, mémoire, stockage) identifiée
7Décider : réduire les demandes ou augmenter le quotaAnalyser les besoins de la charge de travailChangement minimal qui résout le problème
8Appliquer le changement via contrôle de version ou patchkubectl apply -f manifest.yaml ou kubectl patch ...Changement accepté sans erreurs
9Vérifier la mise à jour du quotakubectl get resourcequota -n my-namespaceNouvelle limite stricte reflétée
10Surveiller le déploiementkubectl rollout status deployment/web -n my-namespaceDéploiement réussi
11Confirmer l'absence de nouveaux événements de quotakubectl get events -n my-namespace --sort-by=.lastTimestampAucun événement exceeded quota dans les 5 dernières minutes
12Documenter le changement et le plan de retour en arrièreMettre à jour le runbook ou les notes d'incidentÉtapes de récupération enregistrées
## 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.