ResourceQuota et LimitRange : contrôler les ressources par namespace

ResourceQuota limite la consommation totale d'un namespace (CPU, mémoire, nombre de pods...), tandis que LimitRange définit des valeurs par défaut et des bornes min/max pour chaque conteneur. Ensemble, ils empêchent qu'une équipe ou une application ne monopolise les ressources du cluster. Ce guide vous montre comment les configurer et les combiner efficacement.

Ce que vous allez apprendre

Comprendre la différence entre ResourceQuota et LimitRange
Créer des quotas pour limiter CPU, mémoire et objets Kubernetes
Configurer des valeurs par défaut avec LimitRange
Combiner les deux mécanismes pour un namespace multi-tenant
Déboguer les erreurs liées aux quotas dépassés

Prérequis : connaître les namespaces Kubernetes et comprendre requests et limits.

Pourquoi limiter les ressources par namespace ?

Sans quota, un développeur peut déployer un pod qui réclame 100 Go de mémoire. Le scheduler le place sur le nœud qui a le plus de place, le conteneur grossit jusqu'à épuiser la mémoire disponible, et le noyau déclenche alors un OOM kill qui frappe aussi les pods voisins, y compris ceux d'autres équipes. Dans un cluster multi-tenant (plusieurs équipes, plusieurs projets sur la même infrastructure), rien n'isole par défaut la consommation d'un namespace de celle des autres.

Scénario	Sans quota	Avec ResourceQuota
Un pod demande 100 Go RAM	Schedulé, crash du nœud	Rejeté immédiatement
Une équipe crée 500 pods	Cluster saturé	Limité à 50 pods max
Création massive de ConfigMaps	Surcharge etcd	Plafonné à 100 ConfigMaps

Les quotas sont préventifs : ils bloquent le déploiement avant que le problème ne survienne.

ResourceQuota : limiter la consommation totale

Un ResourceQuota définit des limites agrégées pour tout un namespace. Il répond à la question : "Combien de ressources ce namespace peut-il consommer au total ?"

Types de quotas disponibles

Ces quatre catégories ne servent pas le même objectif. Les quotas Compute protègent les nœuds d'une saturation CPU ou mémoire ; les quotas Objets protègent surtout etcd, qui est la base de données du cluster et son point de contention le plus fragile. Un namespace qui crée dix mille ConfigMaps ne fait crasher aucun nœud, mais il ralentit l'API server pour tout le monde. La catégorie Étendu est le filet universel : sa syntaxe count/<ressource>.<groupe> couvre y compris les ressources personnalisées installées par vos opérateurs.

Catégorie	Exemples de ressources	Description
Compute	`requests.cpu`, `limits.memory`	CPU et mémoire totaux
Objets	`pods`, `services`, `configmaps`	Nombre d'objets Kubernetes
Stockage	`requests.storage`, `persistentvolumeclaims`	Espace disque et PVC
Étendu	`count/deployments.apps`, `count/jobs.batch`	Tout type de ressource

Créer votre premier ResourceQuota

Un ResourceQuota se pose sur un namespace existant et prend effet immédiatement, y compris sur les pods déjà en place : ceux-ci continuent de tourner, mais toute nouvelle création est désormais soumise au plafond. Commencez donc par un namespace de test. La troisième étape est la plus instructive : describe affiche la consommation constatée en face de chaque plafond, et c'est le seul moyen de vérifier que le quota compte bien ce que vous croyiez.

Créer le fichier de quota

Ce quota limite le namespace à 4 CPU en requests, 8 Go de mémoire en limits, et 30 pods maximum.

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

Appliquer le quota

kubectl apply -f quota-team-backend.yaml

Vérifier l'état du quota

kubectl describe resourcequota compute-quota -n team-backend

Sortie attendue :

Name:            compute-quota
Namespace:       team-backend
Resource         Used  Hard
--------         ----  ----
limits.cpu       0     8
limits.memory    0     16Gi
pods             0     30
requests.cpu     0     4
requests.memory  0     8Gi

Quota sur le nombre d'objets

Vous pouvez limiter le nombre de n'importe quel type d'objet Kubernetes :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-quota
  namespace: team-backend
spec:
  hard:
    configmaps: "30"
    secrets: "30"
    services: "10"
    services.loadbalancers: "2"
    services.nodeports: "5"
    persistentvolumeclaims: "10"
    count/deployments.apps: "20"
    count/jobs.batch: "50"

Quota par classe de priorité

Vous pouvez segmenter les quotas selon la PriorityClass des pods :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: high-priority-quota
  namespace: team-backend
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values: ["high-priority"]

Ce quota ne s'applique qu'aux pods avec priorityClassName: high-priority.

LimitRange : valeurs par défaut et bornes

Un LimitRange définit des contraintes au niveau de chaque conteneur ou pod individuel. Il répond à : "Quelles sont les valeurs min, max et par défaut pour un conteneur ?"

Le problème des pods sans requests/limits

Poser un ResourceQuota sur les ressources de calcul a un effet de bord que beaucoup découvrent en production : le namespace devient plus strict pour tous les pods, y compris ceux qui fonctionnaient très bien avant. Kubernetes ne peut en effet pas décompter d'un quota un pod qui ne déclare pas ce qu'il consomme, alors il refuse de le créer. Le manifeste ci-dessous n'a pas changé, c'est le namespace autour de lui qui est devenu exigeant.

Dès qu'un ResourceQuota porte sur des ressources de calcul (requests.cpu, limits.memory...), tout conteneur du namespace doit déclarer les valeurs correspondantes. Les pods qui ne le font pas sont rejetés à la création :

Error from server (Forbidden): error when creating "pod.yaml": pods "mon-pod" is forbidden:
failed quota: compute-quota: must specify limits.cpu for: nginx; limits.memory for: nginx;
requests.cpu for: nginx; requests.memory for: nginx

Le message nomme chaque conteneur en défaut, ce qui est précieux sur un pod multi-conteneurs.

Le LimitRange résout ce problème en définissant des valeurs par défaut automatiques.

Créer un LimitRange

L'objet ci-dessous mélange deux rôles qu'il faut distinguer avant de le lire. default et defaultRequest sont permissifs : ils complètent un manifeste incomplet et laissent passer le pod. max et min sont bloquants : ils rejettent le pod si les valeurs déclarées sortent des bornes. La troisième étape le vérifie concrètement, en créant un pod dépourvu de section resources et en relisant ce que l'API server a réellement enregistré.

Créer le fichier LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: container-limits
  namespace: team-backend
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "50m"
      memory: "64Mi"

Appliquer le LimitRange

kubectl apply -f limitrange-team-backend.yaml

Tester avec un pod sans limits

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: team-backend
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    # Pas de resources déclarées

kubectl apply -f pod-sans-limits.yaml
kubectl get pod test-pod -n team-backend -o yaml | grep -A 10 resources

Résultat : Les valeurs par défaut sont automatiquement injectées.

Les quatre champs du LimitRange

La colonne Appliqué quand est la clé de lecture de ce tableau : les deux premiers champs n'entrent en jeu que si le manifeste est silencieux, les deux derniers s'appliquent dans tous les cas. Une erreur classique consiste à définir default sans defaultRequest : Kubernetes recopie alors la valeur de limits dans requests, et vous réservez bien plus de ressources que prévu sur chaque nœud.

Champ	Description	Appliqué quand
default	Valeur limits par défaut	Si `limits` non spécifié
defaultRequest	Valeur requests par défaut	Si `requests` non spécifié
max	Valeur maximale autorisée	Toujours (rejet si dépassé)
min	Valeur minimale autorisée	Toujours (rejet si inférieur)

LimitRange pour les pods

Vous pouvez aussi définir des limites au niveau du pod entier (somme de tous les conteneurs) :

apiVersion: v1
kind: LimitRange
metadata:
  name: pod-limits
  namespace: team-backend
spec:
  limits:
  - type: Pod
    max:
      cpu: "4"
      memory: "8Gi"

LimitRange pour le stockage

Le LimitRange peut aussi contraindre la taille des PVC :

apiVersion: v1
kind: LimitRange
metadata:
  name: storage-limits
  namespace: team-backend
spec:
  limits:
  - type: PersistentVolumeClaim
    max:
      storage: 50Gi
    min:
      storage: 1Gi

Combiner ResourceQuota et LimitRange

En production, vous utilisez toujours les deux ensemble. Voici l'ordre d'application recommandé :

Créer le namespace avec des labels

apiVersion: v1
kind: Namespace
metadata:
  name: team-backend
  labels:
    team: backend
    environment: production

Appliquer le LimitRange en premier

Le LimitRange garantit que tous les pods auront des requests/limits, même non déclarés.

apiVersion: v1
kind: LimitRange
metadata:
  name: container-limits
  namespace: team-backend
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "50m"
      memory: "64Mi"

Appliquer le ResourceQuota ensuite

Le ResourceQuota limite la consommation totale du namespace.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: team-backend
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    pods: "50"
    configmaps: "50"
    secrets: "50"
    services: "20"
    persistentvolumeclaims: "20"

Flux de validation

Quand vous créez un pod, voici ce qui se passe :

1. Le pod arrive à l'API server
2. LimitRange injecte les defaults si manquants
3. LimitRange vérifie min/max par conteneur
4. ResourceQuota vérifie si le total du namespace permet ce pod
5. Si tout est OK → pod créé
6. Sinon → erreur avec message explicite

Surveiller l'utilisation des quotas

Via kubectl

get répond à la question « y a-t-il un quota ici », describe à la question « où en est-on ». Seule la seconde affiche les colonnes Used et Hard côte à côte, qui sont l'information utile au quotidien : c'est en voyant Used s'approcher de Hard qu'on anticipe le blocage, plutôt que de le découvrir sur un déploiement refusé un vendredi soir.

# Voir tous les quotas d'un namespace
kubectl get resourcequota -n team-backend

# Détails avec utilisation actuelle
kubectl describe resourcequota compute-quota -n team-backend

# Voir les LimitRange
kubectl describe limitrange -n team-backend

Via l'API ou métriques

L'API expose l'utilisation des quotas :

kubectl get resourcequota compute-quota -n team-backend -o jsonpath='{.status}'

Pour le monitoring, kube-state-metrics expose les métriques :

kube_resourcequota : limites et utilisation
kube_limitrange : valeurs configurées

Dépannage

Erreur "exceeded quota"

C'est le message le plus lisible de la série : il donne les trois nombres nécessaires au diagnostic dans la même ligne. requested est ce que le nouveau pod demande, used ce que le namespace consomme déjà, limited le plafond. Si la somme des deux premiers dépasse le troisième, le pod est refusé.

Error from server (Forbidden): pods "my-pod" is forbidden:
exceeded quota: compute-quota, requested: requests.memory=2Gi,
used: requests.memory=7Gi, limited: requests.memory=8Gi

Cause : Le namespace a déjà utilisé 7 Gi sur 8 Gi autorisés.

Solutions :

Réduire les requests du nouveau pod
Supprimer des pods existants
Augmenter le quota (si justifié)

# Voir l'utilisation actuelle
kubectl describe resourcequota -n team-backend

# Identifier les gros consommateurs
kubectl top pods -n team-backend --sort-by=memory

Erreur "must specify limits"

Ne confondez pas ce message avec le précédent : failed quota signale un manifeste incomplet, pas un plafond atteint. Le namespace peut être totalement vide et produire quand même cette erreur. Le message énumère les ressources manquantes et le conteneur concerné, ce qui vous indique directement quoi ajouter.

Error from server (Forbidden): pods "my-pod" is forbidden:
failed quota: compute-quota: must specify limits.cpu for: nginx; limits.memory for: nginx

Cause : Un ResourceQuota existe mais pas de LimitRange, et le pod ne déclare pas ses limits.

Solution : Ajouter un LimitRange avec des valeurs par défaut.

Erreur "exceeds maximum"

Celle-ci vient du LimitRange, pas du ResourceQuota : elle se déclenche même si le namespace est presque vide, parce qu'elle borne chaque conteneur pris isolément. Le mot per Container dans le message est le repère qui permet de distinguer immédiatement les deux mécanismes.

Error from server (Forbidden): pods "my-pod" is forbidden:
maximum cpu usage per Container is 2, but limit is 4

Cause : Le pod demande plus que le max autorisé par le LimitRange.

Solution : Réduire les limits du conteneur ou ajuster le LimitRange.

Pod non schedulé (Pending)

Un pod peut être créé (quota OK) mais rester Pending si le cluster n'a pas assez de ressources disponibles. Le quota ne garantit pas la disponibilité, il garantit seulement les limites.

kubectl describe pod my-pod -n team-backend
# Regarder la section Events pour "Insufficient cpu" ou "Insufficient memory"

Bonnes pratiques

Dimensionnement des quotas

Un quota trop serré transforme chaque déploiement en ticket d'exploitation ; un quota trop large ne protège de rien. La règle qui fonctionne est de partir de la consommation mesurée (kubectl top pods sur quelques jours) et non des chiffres annoncés par l'équipe, puis d'ajouter la marge indiquée ci-dessous. Prévoyez de revoir ces valeurs après le premier trimestre : un quota posé une fois et jamais relu finit toujours par bloquer quelqu'un.

Métrique	Recommandation
requests.cpu	Somme des requests de tous les pods attendus
limits.cpu	1.5x à 2x les requests (marge pour burst)
pods	Nombre max réaliste + 20% marge
PVC	Basé sur les besoins réels de stockage

Cohérence requests/limits

Assurez-vous que le LimitRange est cohérent avec le ResourceQuota :

# Si LimitRange.default.cpu = 500m et ResourceQuota.limits.cpu = 8
# Alors max 16 conteneurs avec defaults (16 × 500m = 8 CPU)

Quotas par environnement

Adaptez les quotas selon l'environnement :

Environnement	Quota CPU requests	Quota mémoire	Pods max
dev	2	4Gi	20
staging	4	8Gi	30
production	16	32Gi	100

À retenir

ResourceQuota limite la consommation totale d'un namespace (CPU, mémoire, objets)
LimitRange définit des valeurs par défaut et des bornes min/max par conteneur
Avec un ResourceQuota portant sur le calcul, les pods doivent déclarer leurs requests/limits → utilisez LimitRange pour les defaults
Appliquez LimitRange avant ResourceQuota pour éviter les rejets de pods
Les quotas sont préventifs : ils bloquent avant que le problème ne survienne
Surveillez l'utilisation avec kubectl describe resourcequota

Testez vos Connaissances

Ce quiz porte sur les points où les deux objets se confondent le plus souvent : quel mécanisme rejette quoi, et dans quel ordre les appliquer. Répondez sans revenir en arrière, les questions manquées vous indiqueront la section à relire.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

8 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

Prochaines étapes

Requests et Limits Comprendre requests et limits au niveau conteneur

Namespaces Organiser votre cluster avec les namespaces

Autoscaling Ajuster automatiquement les ressources avec HPA et VPA

Network Policies Isoler le réseau entre namespaces