Un cluster est un pool partagé de CPU et de mémoire. Sans garde-fous, une charge de travail gourmande peut affamer ses voisines, et une application bloquée peut continuer à recevoir du trafic. Ce guide couvre les outils pour les deux cas : namespaces et quotas pour répartir le pool, requests et limits pour décrire ce dont chaque conteneur a besoin, et probes pour que Kubernetes puisse savoir quand un conteneur est défaillant.

Diviser un cluster avec les namespaces

Les namespaces découpent un cluster en espaces distincts pour des équipes, des applications ou des environnements :

kubectl create namespace demo
kubectl get pods -n demo
kubectl config set-context --current --namespace=demo
kubectl get pods -A

Vos objets vont dans default sauf indication contraire, via -n NAME dans une commande ou metadata.namespace dans un manifeste. Les composants propres au cluster vivent dans kube-system. La plupart des objets sont rattachés à un namespace (Pods, Services, ConfigMaps, Secrets), tandis que certains, comme les nœuds et les PersistentVolumes, sont globaux au cluster. Les namespaces sont l’unité à laquelle s’attachent les quotas et les règles d’accès, mais, à eux seuls, ils constituent une frontière organisationnelle et non une forte barrière de sécurité. Une surprise fréquente est un Pod qui semble avoir disparu, alors qu’en réalité vous l’avez créé dans un autre namespace. Vérifiez avec kubectl get pods -A.

Définir des requests et des limits

Chaque conteneur peut déclarer ce dont il a besoin et le maximum qu’il peut utiliser :

spec:
  containers:
    - name: web
      image: nginx:1.25
      resources:
        requests:
          cpu: 250m
          memory: 64Mi
        limits:
          cpu: 500m
          memory: 128Mi

• Les requests sont ce que le scheduler réserve. Un Pod n’est placé que sur un nœud disposant de cette capacité non réclamée, et le conteneur reçoit au moins cette quantité.
• Les limits sont un plafond strict. Un conteneur qui tente d’utiliser plus de CPU est ralenti (throttled). Un conteneur qui dépasse sa limite de mémoire est tué (OOMKilled) puis redémarré.

Le CPU se mesure en cœurs, où 1000m (millicores) représente un cœur entier : 250m est donc un quart de cœur. Une limit ne peut pas être inférieure à sa request. Les deux se définissent par conteneur, pas par Pod.

Surveiller l’utilisation avec le metrics server

kubectl top indique l’utilisation en direct, mais il nécessite le metrics server, qui manque à de nombreux clusters neufs. Sans lui, vous verrez « Metrics API not available ». Sur minikube :

minikube addons enable metrics-server
kubectl top nodes
kubectl top pods -A

Sur les autres clusters, installez metrics-server depuis sa page de projet. C’est un moyen rapide de repérer quels Pods consomment le plus de ressources.

Imposer un budget avec ResourceQuota et LimitRange

Un ResourceQuota plafonne le total qu’un namespace peut demander ou utiliser :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: demo-quota
  namespace: demo
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
    pods: "10"

kubectl describe resourcequota -n demo montre ce qui est consommé par rapport à chaque limite. Dès que le total serait dépassé, les nouveaux Pods sont rejetés à la création avec une erreur « exceeded quota ». Quand un quota porte sur le CPU ou la mémoire, chaque Pod de ce namespace doit aussi déclarer ces requests et limits, faute de quoi il est rejeté. Un LimitRange évite cela en fournissant des valeurs par défaut aux conteneurs qui ne définissent pas les leurs :

apiVersion: v1
kind: LimitRange
metadata:
  name: container-defaults
  namespace: demo
spec:
  limits:
    - type: Container
      defaultRequest:
        cpu: 100m
        memory: 64Mi
      default:
        cpu: 250m
        memory: 128Mi

Ajouter des readiness et liveness probes

Un conteneur en cours d’exécution n’est pas forcément un conteneur qui fonctionne. Les probes permettent à Kubernetes de vérifier :

• Une readiness probe décide si le conteneur doit recevoir du trafic. Quand elle échoue, le Pod est retiré des endpoints de ses Services mais n’est pas redémarré. Utilisez-la pour les démarrages lents ou les surcharges temporaires.
• Une liveness probe décide si le conteneur est toujours vivant. Après suffisamment d’échecs consécutifs, le kubelet redémarre le conteneur.
• Une startup probe retarde les deux autres pendant qu’une application lente démarre.

spec:
  containers:
    - name: web
      image: nginx:1.25
      readinessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 2
        periodSeconds: 5
        timeoutSeconds: 1
        failureThreshold: 3
      livenessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 10
        periodSeconds: 10
        failureThreshold: 3

Les champs de temporisation fonctionnent de la même façon pour toutes les probes. initialDelaySeconds est le délai d’attente après le démarrage du conteneur avant la première vérification, periodSeconds la fréquence des vérifications, timeoutSeconds le temps d’attente d’une réponse, et failureThreshold le nombre d’échecs consécutifs qui comptent comme un échec définitif. Outre les requêtes HTTP, les probes peuvent ouvrir une connexion TCP (tcpSocket), exécuter une commande dans le conteneur (exec) ou utiliser gRPC.

Gardez des liveness checks simples et centrés sur le processus lui-même. Si une liveness probe échoue parce qu’une base de données est en panne, Kubernetes redémarre inutilement des conteneurs applicatifs sains et peut aggraver une panne. Une readiness probe est l’endroit approprié pour refléter les dépendances. La readiness pilote aussi les mises à jour progressives : les nouveaux Pods ne comptent comme disponibles qu’une fois prêts.

Vous pouvez voir les résultats des probes dans kubectl describe pod, où les échecs apparaissent dans les événements, et dans kubectl get pods, où une readiness probe en échec s’affiche 0/1 dans la colonne READY.