Automatiser les demandes et limites de ressources Kubernetes avec CI/CD : guide pratique

Introduction

La définition des demandes (requests) et des limites (limits) de ressources est une pratique essentielle pour exécuter des charges de travail fiables sur Kubernetes. Sans elles, un seul pod défaillant peut affamer les autres services sur le même nœud, provoquer des évictions inattendues ou gonfler votre facture cloud. Cependant, faire respecter ces paramètres de manière cohérente entre les équipes est difficile : les développeurs les oublient dans les fichiers YAML, les réviseurs les manquent dans les revues de code, et les incidents de production révèlent les lacunes.

Cet article fournit un guide pratique pour automatiser les demandes et limites de ressources Kubernetes à l'aide de pipelines CI/CD (intégration continue/déploiement continu). Vous apprendrez à valider les manifests avant qu'ils n'atteignent le cluster, à appliquer des politiques avec des contrôleurs d'admission et à mettre en place des mécanismes de retour en arrière sécurisés lorsque les choses tournent mal. Nous nous concentrons sur la sécurité opérationnelle : observer l'état actuel, apporter de petits changements réversibles et vérifier les résultats avec des commandes concrètes. Chaque section inclut de vraies commandes kubectl, des extraits de pipeline et les sorties attendues.

À la fin, vous disposerez d'un flux de travail reproductible pour la gestion des ressources qui convient aux développeurs, aux consultants DevOps et aux équipes techniques de startups.

Prérequis et inventaire de l'environnement

Avant d'automatiser quoi que ce soit, documentez votre environnement. Cette section couvre les versions et les outils nécessaires, et comment inspecter la configuration actuelle des ressources de votre cluster.

Outils requis

• Cluster Kubernetes version 1.25 ou ultérieure (pour un support stable des fonctionnalités de kubectl et des webhooks d'admission).
• Client kubectl dont la version correspond à celle du cluster à une version mineure près. Vérifiez avec :

  kubectl version --short

Sortie attendue :

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

• Une plateforme CI/CD (GitHub Actions, GitLab CI, Jenkins, etc.) avec accès à un registre d'images de conteneurs et au kubeconfig du cluster (stocké en tant que secret).
• Optionnel mais recommandé : un moteur de politiques tel qu'OPA Gatekeeper, Kyverno ou la politique d'admission de validation native de Kubernetes.

Commandes d'observation en lecture seule

Exécutez ces commandes pour évaluer l'état actuel des demandes et limites de ressources dans votre cluster :

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

Cela montre les valeurs manquantes. Pour un examen plus approfondi d'un pod spécifique :

kubectl describe pod <nom-du-pod> -n <namespace>

Recherchez des événements comme FailedScheduling avec des messages tels que 0/3 nodes are available: 3 Insufficient cpu.

Pour voir les quotas de ressources et les plages de limites qui peuvent déjà être en place :

kubectl get resourcequota -A
kubectl get limitrange -A

Exemple de sortie :

NAMESPACE   NAME           AGE
prod        prod-quota     10d

Si des quotas existent, inspectez leurs contraintes :

kubectl describe resourcequota prod-quota -n prod

Les champs attendus comprennent :

Resource       Used  Hard
--------       ----  ----
requests.cpu   500m  10
limits.memory  1Gi   20Gi

Délimitation de l'automatisation

Avant de modifier quoi que ce soit, demandez-vous :

• Quels namespaces voulez-vous contrôler ? (par exemple, prod, staging)
• Avez-vous besoin de politiques différentes par namespace ou par type de charge de travail ?
• Quelle est la politique minimale viable ? Commencez par : chaque conteneur doit avoir des demandes et des limites non nulles pour le CPU et la mémoire.

Enregistrez votre état actuel et les horodatages. Par exemple :

date && kubectl get pods -o wide > pod_state_$(date +%Y%m%d).txt

Chemin de configuration sécurisé

Cette section explique comment construire un pipeline d'automatisation sécurisé qui valide les demandes et limites de ressources avant le déploiement. Nous couvrirons à la fois la validation CI/CD et l'application à l'exécution.

Étape 1 : Définir la politique en tant que code

Créez un document de politique qui spécifie les règles. Pour un pipeline CI/CD, vous pouvez utiliser un script simple. Voici un exemple en Bash utilisant kubectl dry-run et jq pour vérifier les ressources manquantes :

#!/bin/bash
# validate_resources.sh
set -euo pipefail

for file in ./manifests/*.yaml; do
  echo "Validating $file"
  kubectl apply --dry-run=client -f "$file" -o json | jq -e '
    .items[]?.spec.template.spec.containers[]? |
    (.resources.requests.cpu != null) and (.resources.requests.memory != null) and
    (.resources.limits.cpu != null) and (.resources.limits.memory != null)
  ' >/dev/null || {
    echo "ERROR: $file is missing resource requests or limits"
    exit 1
  }
done

Ce script échoue si un conteneur dans un déploiement n'a pas de demandes ou de limites.

Étape 2 : Intégration au pipeline CI/CD

Exemple d'extrait de workflow GitHub Actions :

name: Validate Kubernetes Manifests
on: [pull_request, push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup kubectl
        uses: azure/setup-kubectl@v4
        with:
          version: 'v1.27.3'
      - name: Run resource validation
        run: ./validate_resources.sh

Lors d'une demande d'extraction (pull request), cette vérification s'exécute automatiquement et bloque la fusion si des ressources sont manquantes.

Étape 3 : Ajouter une application à l'exécution avec un moteur de politiques

Le CI/CD ne détecte que les manifests qui passent par le pipeline. Pour une application à l'échelle du cluster, utilisez un contrôleur d'admission. Kubernetes 1.26+ prend en charge nativement ValidatingAdmissionPolicy. Voici un exemple de politique (en supposant que la fonctionnalité ValidatingAdmissionPolicy est activée) :

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-resource-limits
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: ["apps"]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["deployments", "statefulsets", "daemonsets"]
  validations:
    - expression: "object.spec.template.spec.containers.all(c, has(c.resources) && has(c.resources.requests) && has(c.resources.limits))"
      message: "All containers must have resource requests and limits"

Appliquez-la :

kubectl apply -f require-resource-limits.yaml

Testez avec un déploiement invalide :

kubectl apply -f test-without-limits.yaml

Erreur attendue :

Error from server (Forbidden): error when creating "test-without-limits.yaml": admission webhook "validating.admission.policy/require-resource-limits" denied the request: All containers must have resource requests and limits

Étape 4 : Utiliser les quotas de ressources et les plages de limites

ResourceQuota limite la consommation agrégée de ressources par namespace, tandis que LimitRange définit des valeurs par défaut pour les pods qui omettent les demandes/limites.

Exemple de LimitRange pour définir des valeurs par défaut en cas d'omission :

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: prod
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi
    type: Container

Appliquez et vérifiez :

kubectl apply -f limitrange.yaml
kubectl get limitrange -n prod

Désormais, si un pod est créé sans demandes/limites dans le namespace prod, il recevra les valeurs par défaut.

Étape 5 : Déploiement progressif

Commencez par un seul namespace ou un déploiement canari. Par exemple, n'appliquez la politique qu'aux nouveaux déploiements dans staging, surveillez pendant une semaine, puis étendez à prod. N'appliquez jamais un changement de politique à tout le cluster en une seule fois.

Vérification et diagnostics

Après avoir appliqué vos politiques, vérifiez que l'automatisation fonctionne correctement. Cette section couvre les commandes pour confirmer les paramètres de ressources et diagnostiquer les problèmes.

Vérification des demandes et limites de ressources

Vérifiez les valeurs réelles d'un pod en cours d'exécution :

kubectl get pod my-app-7d8f9b6c-abcde -n prod -o jsonpath='{.spec.containers[0].resources}'

Exemple de sortie :

{"limits":{"cpu":"500m","memory":"512Mi"},"requests":{"cpu":"200m","memory":"256Mi"}}

Pour voir tous les pods d'un namespace avec leurs ressources :

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

Diagnostic des échecs de planification

Si un pod ne peut pas être planifié en raison de contraintes de ressources, utilisez :

kubectl describe pod <nom-du-pod> -n <namespace>

Recherchez des événements comme :

Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  2m    default-scheduler  0/3 nodes are available: 3 Insufficient cpu.

Pour voir la capacité des nœuds et les ressources allouables :

kubectl describe node <nom-du-nœud> | grep -A 5 "Allocated resources"

Exemple de sortie :

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests      Limits
  --------           --------      ------
  cpu                1500m (75%)   5000m (250%)
  memory             2Gi (50%)     4Gi (100%)

Vérification des politiques et des quotas

Vérifiez que la politique d'admission est active :

kubectl get validatingadmissionpolicies

Testez la politique avec un manifest en échec et confirmez le message de refus.

Vérifiez l'utilisation des quotas de ressources :

kubectl describe resourcequota prod-quota -n prod

Surveillez que Used approche les limites Hard.

Journaux du pipeline CI/CD

Dans votre système CI, inspectez les journaux du travail de validation. Pour GitHub Actions, allez dans l'onglet Actions, sélectionnez l'exécution et examinez l'étape Run resource validation. Elle devrait se terminer avec le code 0 en cas de succès ; sinon, un message d'erreur apparaît.

Modes de défaillance et récupération

Même avec l'automatisation, des échecs surviennent. Cette section couvre les scénarios de défaillance courants et comment récupérer en toute sécurité.

Défaillance : la validation du pipeline échoue sur des manifests existants

Si votre vérification CI/CD commence à échouer parce que les développeurs ont oublié d'ajouter des ressources aux nouveaux manifests, c'est attendu. Pour gérer les manifests hérités, vous pouvez :

• Les mettre à jour manuellement pour ajouter des ressources, ou
• Autoriser temporairement des exceptions via une annotation (si votre moteur de politiques le prend en charge).

Pour une ValidatingAdmissionPolicy, vous pouvez ajouter un matchExclusions pour ignorer certains namespaces ou libellés. Exemple pour exclure un namespace :

matchExclusions:
- objectSelector:
    matchLabels:
      exempt: "true"

Puis étiquetez le namespace :

kubectl label namespace legacy-apps exempt=true

Mais assurez-vous d'avoir un plan pour mettre ces charges de travail en conformité.

Défaillance : la politique d'admission bloque un déploiement critique

Si une politique est trop stricte et bloque un déploiement légitime, vous pouvez temporairement désactiver la politique. Pour ValidatingAdmissionPolicy, définissez failurePolicy à Ignore, ou supprimez la politique :

kubectl delete validatingadmissionpolicy require-resource-limits

Déployez ensuite la charge de travail, corrigez le manifest et réappliquez la politique.

Ayez toujours un plan de retour en arrière. En CI/CD, utilisez le contrôle de version pour annuler un changement de politique et relancer le pipeline.

Défaillance : pod OOMKilled malgré les limites

Si un pod est tué pour avoir dépassé les limites de mémoire (OOMKilled), vérifiez l'état du pod :

kubectl get pod my-app -n prod

L'état affichera OOMKilled dans la colonne RESTARTS ou dans kubectl describe.

Augmentez ensuite la limite de mémoire de manière appropriée :

resources:
  limits:
    memory: "1Gi"
  requests:
    memory: "512Mi"

Appliquez avec :

kubectl apply -f deployment.yaml

Surveillez :

kubectl top pod my-app -n prod

Défaillance : le cluster manque de ressources

Si les nœuds sont surchargés, vous pouvez voir des pods Evicted. Vérifiez les événements :

kubectl get events --all-namespaces | grep Evicted

Étapes de récupération :

• Réduire ou supprimer les charges de travail gourmandes en ressources.
• Ajouter plus de nœuds.
• Ajuster les quotas de ressources pour éviter le surengagement.

Meilleures pratiques de retour en arrière

Gardez toujours la version de travail précédente de vos manifests dans un dépôt Git. Utilisez kubectl rollout undo pour les déploiements :

kubectl rollout undo deployment/my-app -n prod

Et vérifiez :

kubectl rollout status deployment/my-app -n prod

Pour les changements de politique, annulez le commit et relancez le CI/CD. Documentez la procédure de récupération dans vos runbooks.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour vous assurer que votre automatisation de la gestion des ressources est opérationnellement saine.

1. Inventaire de l'environnement

• [ ] Exécutez kubectl version --short et enregistrez les versions client/serveur.
• [ ] Listez les quotas de ressources existants : kubectl get resourcequota -A.
• [ ] Listez les plages de limites : kubectl get limitrange -A.
• [ ] Capturez l'utilisation actuelle des ressources des pods : kubectl get pods -o wide --all-namespaces > pod_state_$(date +%Y%m%d).txt.

1. Définition de la politique

• [ ] Définissez les exigences minimales : chaque conteneur doit avoir des demandes et limites de CPU et de mémoire.
• [ ] Créez un script de validation ou utilisez un moteur de politiques.
• [ ] Testez la politique localement avec un exemple de manifest invalide.

1. Intégration CI/CD

• [ ] Ajoutez l'étape de validation au pipeline (sur les demandes d'extraction et les poussées).
• [ ] Assurez-vous que le pipeline échoue sur les manifests invalides.
• [ ] Protégez la branche principale afin que seuls les contrôles réussis puissent être fusionnés.

1. Application à l'exécution

• [ ] Appliquez la politique d'admission ou LimitRange au namespace cible.
• [ ] Testez avec un pod sans ressources et confirmez le refus ou la définition par défaut.
• [ ] Configurez des quotas de ressources pour plafonner la consommation totale.

1. Vérification

• [ ] Déployez une charge de travail de test et vérifiez les ressources avec kubectl get pod -o jsonpath.
• [ ] Vérifiez la planification : kubectl describe pod montre une planification réussie.
• [ ] Surveillez les journaux CI/CD pour les exécutions réussies.

1. Surveillance et alertes

• [ ] Configurez des alertes pour l'utilisation des quotas de ressources > 80 %.
• [ ] Alertez sur les évictions de pods ou les événements OOMKilled.
• [ ] Examinez les tableaux de bord pour les demandes vs limites de CPU/mémoire.

1. Plan de retour en arrière

• [ ] Documentez comment annuler les changements de politique.
• [ ] Utilisez kubectl rollout undo pour les régressions de déploiement.
• [ ] Gardez tous les manifests dans Git avec l'historique.

1. Revue périodique

• [ ] Mensuellement, examinez l'utilisation des ressources et ajustez les demandes/limites pour l'efficacité.
• [ ] Trimestriellement, examinez l'efficacité de la politique et mettez à jour si nécessaire.
• [ ] Après les incidents, mettez à jour les runbooks en fonction des leçons apprises.

Conclusion

Automatiser les demandes et limites de ressources Kubernetes avec le CI/CD est un moyen puissant de prévenir l'épuisement des ressources, de réduire les coûts et d'améliorer la stabilité du cluster. En combinant la validation par pipeline, les politiques d'admission et les quotas de ressources, vous créez plusieurs couches de défense qui détectent les problèmes tôt et appliquent les normes de manière cohérente.

La clé est de procéder avec sécurité opérationnelle : observer l'état actuel, mettre en œuvre de petits changements réversibles, vérifier avec des commandes concrètes et avoir un plan de retour en arrière. Utilisez les exemples de ce guide comme point de départ, mais adaptez-les à votre environnement et à vos politiques spécifiques.

Commencez petit : choisissez un namespace, définissez vos exigences minimales, ajoutez un script de validation à votre pipeline CI, et surveillez les résultats. À mesure que la confiance grandit, étendez à d'autres namespaces et ajoutez l'application à l'exécution. Rappelez-vous que la gestion des ressources n'est pas une configuration unique ; elle nécessite une revue et un ajustement continus à mesure que les charges de travail évoluent.

Avec ces pratiques, vous pouvez vous assurer que chaque conteneur exécuté dans votre cluster Kubernetes a des demandes et des limites de ressources appropriées, ce qui conduit à des performances prévisibles et à une plateforme plus résiliente.