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 consomme 100 Go de mémoire — et faire crasher tous les autres workloads du cluster. Dans un environnement multi-tenant (plusieurs équipes, plusieurs projets), c’est le problème du “noisy neighbor” : un voisin bruyant qui monopolise les ressources.

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

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

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

Quand un ResourceQuota existe sur un namespace, tout pod doit déclarer ses requests et limits. Les pods sans ces valeurs sont rejetés avec l’erreur :

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

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

Créer un LimitRange

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

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

# 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”

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”

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

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”

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

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, 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

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