## Introduction LimitRange est un objet de politique Kubernetes qui contraint la consommation de ressources par Pod ou par conteneur au sein d'un espace de noms. Bien qu'il soit souvent traité comme un simple garde-fou, des LimitRanges mal configurés peuvent introduire des problèmes de performance subtils : latence d'admission, retards de planification et fragmentation des ressources. Ce guide fournit des étapes pratiques pour diagnostiquer et régler les performances de LimitRange. Vous apprendrez à inspecter les paramètres actuels, à mesurer leur impact, à mettre en œuvre des changements ciblés en toute sécurité et à vérifier les améliorations. L'objectif est de vous aider à éviter les pièges courants et à maintenir un cluster sain. Pourquoi régler les performances de LimitRange ? Des valeurs par défaut trop restrictives peuvent obliger les Pods à demander plus de ressources que nécessaire, gaspillant ainsi la capacité. Un nombre trop élevé ou trop complexe d'objets LimitRange peut ralentir le webhook d'admission du serveur API. Et des limites incohérentes entre les espaces de noms peuvent entraîner un comportement imprévisible. En suivant un processus de réglage structuré, vous pouvez améliorer l'utilisation des ressources, réduire la latence et simplifier les opérations. ## Inventaire des versions et de l'environnement Avant d'apporter des modifications, vous devez avoir une vision claire de votre environnement. Cette section couvre la version de Kubernetes, la topologie du cluster et les prérequis pour le réglage de LimitRange. ### Version de Kubernetes Le comportement de LimitRange est stable depuis Kubernetes 1.10, mais des améliorations liées aux performances et des changements de contrôle d'admission apparaissent dans les versions ultérieures. Utilisez kubectl version --short pour vérifier à la fois les versions client et serveur : kubectl version --short Sortie attendue : Client Version: v1.24.0 Server Version: v1.24.0 Si votre cluster est antérieur à la version 1.21, envisagez une mise à niveau avant le réglage, car les versions plus récentes offrent de meilleures performances du serveur API et de meilleures métriques. ### Topologie du cluster Identifiez le nombre de nœuds, leur capacité et les espaces de noms utilisant des LimitRanges : kubectl get nodes kubectl get limitrange --all-namespaces La première commande affiche l'état et la capacité des nœuds. La seconde liste tous les LimitRanges, ce qui vous aide à comprendre l'ampleur de votre effort de réglage. ### Prérequis Assurez-vous d'avoir : - Un accès administrateur au cluster pour modifier les objets LimitRange. - Le serveur de métriques installé pour les métriques d'utilisation des ressources (ou un système de surveillance équivalent). - Le point de terminaison des métriques du serveur API Kubernetes activé (disponible par défaut dans la plupart des distributions). - Une base de référence des métriques de performance actuelles, telles que la durée des requêtes d'admission et la latence de planification. Exécutez la commande suivante pour vérifier le serveur de métriques : kubectl top nodes Si elle échoue, installez metrics-server. C'est crucial pour mesurer l'impact de votre réglage.

Question rapide 1 sur 2 Que se passe-t-il si une LimitRange définit une limite par défaut inférieure à la valeur de requête spécifiée par un client pour un conteneur ? - Le Pod est créé avec à la fois la requête et la limite. - Le Pod ne sera pas planifiable et échouera avec une erreur. - La LimitRange est automatiquement ajustée pour correspondre à la requête. - Le Pod est créé mais la limite est ignorée.

Une LimitRange ne vérifie pas la cohérence des valeurs par défaut qu'elle applique. Si une limite par défaut est inférieure à la valeur de requête, le Pod final ne sera pas planifiable et échouera avec une erreur du type « must be less than or equal to cpu limit ».

## Chemin de configuration sécurisé Le réglage de LimitRange doit être effectué de manière incrémentale et avec un plan de retour en arrière clair. Commencez par un seul espace de noms, de préférence non productif, puis étendez. ### Identifier les limites actuelles Tout d'abord, inspectez le LimitRange existant dans votre espace de noms cible : kubectl get limitrange -n my-app -o yaml Exemple de sortie : apiVersion: v1 kind: LimitRange metadata: name: my-app-limits namespace: my-app spec: limits: - max: cpu: "2" memory: 2Gi min: cpu: "100m" memory: 100Mi default: cpu: "500m" memory: 500Mi defaultRequest: cpu: "200m" memory: 200Mi type: Container Cela définit des limites pour les conteneurs individuels. Si vos charges de travail demandent souvent beaucoup moins que la valeur par défaut, vous êtes peut-être en surallocation. ### Choisir un changement ciblé Les goulots d'étranglement de performance proviennent souvent de : - Des valeurs par défaut de CPU/mémoire excessivement élevées, obligeant les Pods à demander plus que nécessaire et gaspillant la capacité allouable. - Un trop grand nombre d'objets LimitRange dans un espace de noms (chaque objet ajoute un coût de recherche lors de l'admission). - L'utilisation de LimitRange en combinaison avec ResourceQuota, ce qui peut créer de la confusion et des retards s'ils ne sont pas alignés. Pour ce guide, nous nous concentrerons sur la réduction des valeurs de ressources par défaut pour mieux correspondre à l'utilisation réelle. C'est une optimisation courante et sûre. ### Appliquer les modifications progressivement Modifiez le LimitRange en utilisant une approche déclarative. Tout d'abord, créez un nouveau fichier YAML avec des valeurs par défaut ajustées. Par exemple, réduisez le CPU par défaut de 500m à 250m et la mémoire par défaut de 500Mi à 256Mi. Nouveau LimitRange ( limitrange-adjusted.yaml ) : apiVersion: v1 kind: LimitRange metadata: name: my-app-limits namespace: my-app spec: limits: - max: cpu: "2" memory: 2Gi min: cpu: "100m" memory: 100Mi default: cpu: "250m" memory: 256Mi defaultRequest: cpu: "100m" memory: 128Mi type: Container Appliquez le changement : kubectl apply -f limitrange-adjusted.yaml Sortie attendue : limitrange/my-app-limits configured ### Impact sur les Pods existants Les changements de LimitRange ne mettent pas automatiquement à jour les Pods existants. Seuls les nouveaux Pods créés après le changement utiliseront les nouvelles valeurs par défaut. Les Pods existants conservent leurs demandes et limites de ressources. Pour voir l'effet, vous devez créer un nouveau Pod ou Déploiement. ## Vérification et diagnostic Après avoir appliqué les modifications, vérifiez que le nouveau LimitRange fonctionne comme prévu et mesurez son impact sur les performances. ### Vérifier que les nouvelles valeurs par défaut sont appliquées Créez un simple Pod sans spécifier de ressources pour voir si les valeurs par défaut sont appliquées. Créez un fichier test-pod.yaml : apiVersion: v1 kind: Pod metadata: name: test-pod namespace: my-app spec: containers: - name: app image: nginx Appliquez le Pod : kubectl apply -f test-pod.yaml Vérifiez les ressources du Pod : kubectl get pod test-pod -n my-app -o jsonpath='{.spec.containers[0].resources}' Sortie attendue : {"limits":{"cpu":"250m","memory":"256Mi"},"requests":{"cpu":"100m","memory":"128Mi"}} Cela confirme que les nouvelles valeurs par défaut sont appliquées. ### Mesurer la latence d'admission Le serveur API traite l'admission LimitRange pour chaque création de Pod. Pour vérifier le temps pris, inspectez les métriques du serveur API. Utilisez la commande suivante contre le serveur API (nécessite un accès au serveur API ou à son point de terminaison de métriques, souvent accessible via kubectl get --raw /metrics ) : kubectl get --raw /metrics | grep apiserver_admission_controller_admission_duration_seconds_sum{name="limitrange"} Cela renvoie une somme cumulative. Pour obtenir la moyenne récente, vous pouvez utiliser un outil de surveillance comme Prometheus. Si vous avez Prometheus, interrogez : rate(apiserver_admission_controller_admission_duration_seconds_sum{name="limitrange"}[5m]) / rate(apiserver_admission_controller_admission_duration_seconds_count{name="limitrange"}[5m]) Résultat attendu : avant le réglage, la moyenne peut être d'environ 1 à 5 millisecondes. Après réduction de la complexité (par exemple, moins d'objets LimitRange ou des règles plus simples), elle devrait diminuer. Comparez avant et après. ### Vérifier le débit de planification Si vous réduisez les demandes de ressources, plus de Pods peuvent tenir sur les nœuds, améliorant la planification. Créez un petit Déploiement pour simuler la charge et observer le temps de planification des pods. Créez deployment-test.yaml : apiVersion: apps/v1 kind: Deployment metadata: name: load-test namespace: my-app spec: replicas: 10 selector: matchLabels: app: test template: metadata: labels: app: test spec: containers: - name: app image: nginx Appliquez puis surveillez les temps de création des pods : kubectl apply -f deployment-test.yaml kubectl get pods -n my-app -w Observez à quelle vitesse les Pods passent à l'état Running. Vous pouvez également vérifier les métriques de latence de planification depuis kube-scheduler si disponibles.

Question rapide 2 sur 2 Lors de la création ou de la mise à jour d'un objet qui enfreint une contrainte LimitRange, quel est le code de statut HTTP renvoyé par le serveur d'API ? - 200 OK - 403 Forbidden - 404 Not Found - 500 Internal Server Error

Si vous tentez de créer ou de mettre à jour un objet qui enfreint une contrainte LimitRange, la requête adressée au serveur d'API échouera avec un code de statut HTTP 403 Forbidden et un message expliquant la contrainte qui a été enfreinte.

## Modes de défaillance et récupération Les changements de LimitRange peuvent mal tourner. Les modes de défaillance courants incluent : - Définir des valeurs par défaut trop basses, provoquant le rejet des Pods en raison de ressources insuffisantes ou du dépassement des quotas de l'espace de noms. - Définir des valeurs minimales trop élevées, empêchant la création de petits Pods. - Suppression accidentelle du LimitRange, permettant la création de Pods sans limites. ### Procédure de retour en arrière Si le nouveau LimitRange cause des problèmes, revenez à la version précédente. Si vous avez conservé le YAML d'origine, réappliquez-le : kubectl apply -f original-limitrange.yaml Si vous l'avez perdu, extrayez la configuration précédente des journaux d'audit du cluster ou d'une sauvegarde. En dernier recours, vous pouvez modifier manuellement le LimitRange pour annuler les changements. ### Contrôles de récupération Après le retour en arrière, vérifiez que : - Les Pods existants ne sont pas affectés. - Les nouveaux Pods obtiennent les valeurs par défaut précédentes en créant un Pod de test et en vérifiant les ressources. - La latence d'admission revient à la ligne de base. De plus, envisagez d'utiliser les journaux d'audit du serveur API Kubernetes pour identifier quelles requêtes ont été refusées en raison du mauvais LimitRange. Par exemple, recherchez "limitrange" et "denied" dans les journaux d'audit. ## Liste de contrôle des opérations Utilisez cette liste de contrôle pour le réglage continu des performances de LimitRange :

Étape	Action	Commande / Vérification
1	Inventorier les LimitRanges	`kubectl get limitrange --all-namespaces`
2	Examiner les valeurs par défaut par rapport à l'utilisation réelle	Comparez `kubectl top pods` avec les valeurs par défaut
3	Tester les changements dans un espace de noms non productif	Appliquez le LimitRange ajusté et testez avec de nouveaux Pods
4	Mesurer la latence d'admission avant et après	Utilisez la métrique `apiserver_admission_controller_admission_duration_seconds`
5	Surveiller le débit de planification	Créez un Déploiement de test et vérifiez les temps de démarrage des pods
6	Valider que les nouveaux Pods obtiennent les valeurs par défaut attendues	`kubectl get pod <name> -o jsonpath='{.spec.containers[0].resources}'`
7	Avoir un plan de retour en arrière	Conservez le YAML d'origine et sauvegardez via un contrôle de version

Répétez cette liste de contrôle périodiquement ou chaque fois que vous modifiez les politiques de LimitRange. ## Conclusion Le réglage des performances de LimitRange est souvent négligé mais peut apporter des améliorations significatives en matière d'utilisation des ressources et d'efficacité du cluster. En suivant une approche structurée : inventorier votre environnement, apporter des changements ciblés en toute sécurité, vérifier avec des métriques et avoir un plan de retour en arrière, vous pouvez éviter les pièges courants. Commencez par un projet pilote étroit pour mesurer l'impact, puis étendez à d'autres espaces de noms. N'oubliez pas de documenter les changements et de surveiller en continu. Avec un réglage minutieux, vous pouvez vous assurer que vos clusters Kubernetes fonctionnent de manière fluide et rentable.