## 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 -n 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 Question rapide 1 sur 2 Quel est le but des demandes de ressources dans Kubernetes ? - Pour définir une limite stricte sur l'utilisation des ressources - Pour informer le kube-scheduler sur quel nœud placer le Pod - Pour appliquer une limitation du CPU - Pour mettre à l'échelle automatiquement les pods

Les demandes de ressources sont utilisées par le kube-scheduler pour décider sur quel nœud placer le Pod, tandis que les limites sont appliquées par le kubelet.

## 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 -n 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 | 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. - 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 . - 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. - 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. - 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. - 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. - 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. - 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. - 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.