Introduction
Le planificateur a besoin des demandes de ressources pour placer les Pods, le kubelet applique les limites, et le HorizontalPodAutoscaler a besoin de métriques ainsi que d’une base d’utilisation pertinente. Ces mécanismes constituent un même processus de gestion de la capacité.
Vous allez configurer les demandes et les limites, examiner l’utilisation en temps réel, créer un HPA, générer de la charge et observer l’évolution du nombre de répliques.
Ces paramètres forment une chaîne de dépendances. La demande de processeur établit une base de référence, metrics-server fournit l’utilisation récente, puis le HPA compare les deux pour décider si le nombre de répliques doit changer. Sans demande, le calcul de l’utilisation du processeur en pourcentage n’aurait pas de sens.
Définir les demandes et les limites
Dans cette étape, déployez l’exemple Kubernetes de HPA avec des ressources explicites.
Une demande correspond à la quantité de ressources utilisée pour la planification et comme dénominateur de la mise à l’échelle automatique. Une limite représente le maximum imposé au conteneur. Le processeur est exprimé en cœurs ou en millicœurs (100m correspond à 0,1 cœur) ; la mémoire utilise des unités d’octets telles que Mi.
cd /home/labex/project/resource-autoscaling
kubectl create namespace practice-capacity
kubectl create deployment cpu-demo -n practice-capacity --image=registry.k8s.io/hpa-example:latest --replicas=1
Ajoutez le contrat de ressources au Deployment généré. kubectl set resources met à jour le modèle de Pod et déclenche donc un nouveau déploiement :
kubectl set resources deployment/cpu-demo -n practice-capacity --requests=cpu=100m,memory=32Mi --limits=cpu=200m,memory=64Mi
kubectl expose deployment cpu-demo -n practice-capacity --port=80 --target-port=80
kubectl rollout status deployment/cpu-demo -n practice-capacity --timeout=60s
kubectl get deployment cpu-demo -n practice-capacity -o jsonpath='{.spec.template.spec.containers[0].resources}{"\n"}'
100m correspond à un dixième de cœur processeur. Les demandes influencent la planification et les calculs d’utilisation ; les limites plafonnent la consommation du conteneur.
La sortie JSON doit contenir à la fois requests et limits. Déclarer uniquement une limite ne fournirait pas le dénominateur nécessaire au calcul de l’utilisation par le HPA.
deployment "cpu-demo" successfully rolled out
{"limits":{"cpu":"200m","memory":"64Mi"},"requests":{"cpu":"100m","memory":"32Mi"}}
Les clés JSON peuvent apparaître dans un ordre différent. Vérifiez les quatre valeurs plutôt que leur position sur la ligne.
Examiner les métriques de ressources
Dans cette étape, vérifiez le pipeline de métriques préparé et examinez l’utilisation.
kubectl top fournit un instantané de l’utilisation récente, comparable dans son principe à la commande système top. Il n’affiche pas les demandes ni les limites configurées ; celles-ci restent définies dans la spécification de la charge de travail.
cd /home/labex/project/resource-autoscaling
kubectl get deployment metrics-server -n kube-system
for attempt in $(seq 1 18); do
if kubectl top nodes >/dev/null 2>&1 && kubectl top pods -n practice-capacity --containers >/dev/null 2>&1; then
break
fi
echo "Waiting for the first metrics sample (${attempt}/18)..."
sleep 5
done
kubectl top nodes
kubectl top pods -n practice-capacity --containers
kubectl top lit les métriques récentes, et non les demandes de ressources. Les métriques peuvent mettre un peu de temps à apparaître ; si un nouveau Pod ne possède pas encore d’échantillon, réessayez après quelques secondes.
La boucle effectue automatiquement ces nouvelles tentatives. Elle vérifie discrètement la disponibilité des métriques au maximum 18 fois, attend cinq secondes entre chaque tentative, puis exécute les deux commandes top visibles dès qu’un échantillon est disponible. Dans les vérifications, >/dev/null ignore la sortie standard et 2>&1 redirige la sortie d’erreur au même endroit ; cela évite d’afficher dans le terminal les messages attendus indiquant que les métriques ne sont pas encore prêtes. Ce délai est normal dans un pipeline de collecte d’utilisation récente ; il ne signifie pas que le Pod a échoué.
Les valeurs du nœud et des Pods varieront. Concentrez-vous donc sur la présence des colonnes du processeur et de la mémoire plutôt que sur les chiffres exacts. --containers distingue l’utilisation lorsque plusieurs conteneurs se trouvent dans un même Pod.
Par exemple, l’environnement testé a produit un tableau pour le nœud et un tableau par conteneur semblables à ceux-ci :
NAME CPU(cores) CPU(%) MEMORY(bytes) MEMORY(%)
labex-v135 182m 9% 1602Mi 44%
POD NAME CPU(cores) MEMORY(bytes)
cpu-demo-... hpa-example 1m 9Mi
Il est normal que vos valeurs diffèrent, car il s’agit de mesures et non de valeurs de configuration.
Créer un HorizontalPodAutoscaler
Dans cette étape, définissez une utilisation moyenne cible du processeur de 30 %, avec un à quatre réplicas.
Avec une demande de 100m, une cible de 30 % correspond à environ 30m d’utilisation moyenne du processeur par Pod. Le HPA ajuste le nombre souhaité de répliques du Deployment, sans jamais descendre sous min=1 ni dépasser max=4.
cd /home/labex/project/resource-autoscaling
kubectl autoscale deployment cpu-demo -n practice-capacity --cpu=30% --min=1 --max=4
kubectl get hpa cpu-demo -n practice-capacity
kubectl describe hpa cpu-demo -n practice-capacity
L’utilisation est mesurée par rapport à la demande de processeur de 100m. Sans cette demande, une cible exprimée en pourcentage ne disposerait pas de dénominateur.
La syntaxe actuelle de kubectl autoscale écrit explicitement le pourcentage avec --cpu=30%. Elle remplace l’ancien indicateur --cpu-percent, que Kubernetes 1.35 signale comme obsolète.
Durant les premières secondes, la colonne TARGETS peut afficher <unknown> le temps qu’un nouvel échantillon de métrique soit collecté. describe hpa fournit les conditions et les événements permettant de déterminer si le contrôleur dispose de métriques exploitables.
Le tableau initial peut donc ressembler à ceci sans signaler d’erreur :
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: <unknown>/30% 1 4 0
Après la synchronisation suivante du contrôleur, <unknown> est remplacé par un pourcentage mesuré et REPLICAS reflète l’état du Deployment.
Générer de la charge et observer la mise à l’échelle
Dans cette étape, exécutez un client temporaire qui envoie des requêtes répétées au Service pendant 60 secondes maximum.
La commande timeout de BusyBox exécute une boucle de requêtes imbriquée pendant 60 secondes. La boucle while appelle de manière répétée le point de terminaison de démonstration, très consommateur de processeur, tandis que >/dev/null ignore les corps des réponses afin de garder le terminal lisible. Lorsque la durée limite est atteinte, la commande renvoie normalement un code différent de zéro ; || true considère donc cet arrêt prévu comme une fin normale.
cd /home/labex/project/resource-autoscaling
kubectl run load-generator -n practice-capacity --image=busybox:1.36 --image-pull-policy=IfNotPresent --restart=Never --rm -i -- sh -c 'timeout 60 sh -c "while true; do wget -qO- http://cpu-demo >/dev/null; done" || true'
kubectl get hpa cpu-demo -n practice-capacity
kubectl get deployment cpu-demo -n practice-capacity
Le HPA réagit de manière asynchrone : les changements de nombre de répliques peuvent donc se poursuivre après l’arrêt du client. Examinez les conditions et les événements du HPA au lieu de supposer qu’une mise à l’échelle est immédiate.
Si la mise à l’échelle n’apparaît pas dans le premier tableau, exécutez brièvement kubectl get hpa cpu-demo -n practice-capacity -w, puis appuyez sur Ctrl+C après avoir observé un changement. -w surveille les mises à jour ; il ne modifie pas le HPA. Le délai exact ne fait volontairement pas partie de la vérification, car les boucles de contrôle des métriques sont asynchrones.
Lors de l’exécution testée, le HPA a constaté une utilisation supérieure à la cible et a augmenté le Deployment à deux répliques prêtes :
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: 55%/30% 1 4 2
NAME READY UP-TO-DATE AVAILABLE
cpu-demo 2/2 2 2
L’utilisation exacte et le nombre de répliques peuvent différer. L’interprétation importante est la suivante : l’utilisation actuelle de 55% dépassait la cible de 30%, de sorte que la capacité souhaitée a augmenté tout en restant dans les limites de 1 à 4 répliques.
Résumé
Vous avez relié les demandes, les limites, les métriques en temps réel, les cibles d’utilisation et les décisions du HPA. La gestion de la capacité fonctionne comme une boucle de rétroaction : déclarer une base de référence, observer l’utilisation, définir des limites et examiner les conditions du contrôleur.
