Réglage des performances de Kubernetes LimitRange : guide pratique de mise en œuvre

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.

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.

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 :

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.