Mise à l’échelle automatique verticale de pod dans Azure Kubernetes Service (AKS)
Cet article donne une vue d’ensemble de l’outil de mise à l’échelle automatique verticale de pod (VPA, Vertical Pod Autoscaler) dans Azure Kubernetes Service (AKS), qui est basé sur la version open source de Kubernetes. Une fois configuré, il définit automatiquement des demandes et limites de ressources sur des conteneurs par charge de travail en fonction de l’utilisation passée. Le VPA libère le processeur et la mémoire pour les autres pods, facilitant une utilisation efficace de votre cluster AKS.
La mise à l’échelle automatique verticale de pod fournit des recommandations pour l’utilisation des ressources au fil du temps. Pour gérer les pics d’utilisation des ressources soudains, utilisez la mise à l’échelle automatique horizontale de pod, qui met à l’échelle le nombre de réplicas de pod selon les besoins.
Avantages
Un Vertical Pod Autoscaler offre les avantages suivants :
Il analyse et ajuste les ressources de processeur et de mémoire pour dimensionner correctement vos applications. Le VPA est responsable de l’augmentation et de la réduction d’échelle en fonction de leur utilisation des ressources au fil du temps.
Un pod est supprimé s’il doit changer ses demandes de ressources quand son mode de mise à l’échelle est défini sur Auto ou Recreate.
Définit des contraintes de processeur et de mémoire pour des conteneurs individuels en spécifiant une stratégie de ressource.
Veille à ce que les nœuds disposent de ressources correctes pour la planification des pods.
Assure une journalisation configurable des ajustements des ressources de processeur ou de mémoire effectués.
Améliore l’utilisation des ressources de cluster et libère des ressources de processeur et de mémoire pour d’autres pods.
Limites
La mise à l’échelle automatique verticale de pod prend en charge jusqu’à 1 000 pods associés à des objets
VerticalPodAutoscaler
par cluster.VPA peut recommander plus de ressources que celles qui sont disponibles dans le cluster. Ceci empêche donc le pod d’être affecté à un nœud et de s’exécuter, car le nœud ne dispose pas de ressources suffisantes. Vous pouvez surmonter cette limitation en définissant la LimitRange sur le nombre maximal de ressources disponibles par espace de noms, ce qui garantit que les pods ne demandent pas plus de ressources que ce qui est spécifié. En outre, vous pouvez définir le nombre maximal de recommandations de ressources autorisées par pod dans un objet
VerticalPodAutoscaler
. Notez bien que VPA ne peut pas résoudre entièrement un problème de ressources de nœud insuffisantes. La plage de limites est fixe, mais l’utilisation des ressources d’un nœud change de façon dynamique.Nous vous déconseillons d’utiliser l’outil de mise à l’échelle automatique verticale de pod avec l’outil de mise à l’échelle automatique horizontale de pod, qui effectue ses mises à l’échelle en fonction des mêmes métriques d’utilisation du processeur et de la mémoire.
Le générateur de recommandations du VPA conserve un historique des données seulement pour un maximum de huit jours.
Le VPA ne prend pas en charge les charges de travail basées sur JVM en raison d’une visibilité limitée sur l’utilisation réelle de la mémoire par la charge de travail.
Exécuter votre propre implémentation de VPA en même temps que cette implémentation managée de VPA n’est ni recommandé ni pris en charge. Le fait d’avoir un générateur de recommandations supplémentaire ou personnalisé est pris en charge.
Les conteneurs Windows AKS ne sont pas pris en charge.
Avant de commencer
Le cluster AKS exécute Kubernetes version 1.24 ou ultérieure.
Azure CLI version 2.52.0 ou ultérieure installé et configuré. Exécutez
az --version
pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.kubectl
doit être connecté au cluster dans lequel vous souhaitez installer le VPA.
Vue d’ensemble de VPA
Objet d’API
Le Vertical Pod Autoscaler est une ressource d’API dans le groupe d’API de mise à l’échelle automatique Kubernetes. La version prise en charge est 0.11 et ultérieure, et se trouve dans le dépôt de l’outil de mise à l’échelle automatique de Kubernetes.
L’objet VPA est constitué de trois composants :
Générateur de recommandations : il surveille la consommation de ressources actuelle et passée et, en fonction de celle-ci, fournit des valeurs recommandées pour les demandes/limites de processeur et de mémoire des conteneurs. Le générateur de recommandations surveille l’historique des métriques, les événements OOM (Mémoire insuffisante) et les spécifications de déploiement de VPA, et suggère des demandes équitables. Grâce à une configuration appropriée des demandes et de limites de ressources, les limites sont augmentées ou abaissées.
Outil de mise à jour : il vérifie si les pods managés disposent des ressources correctes et, si ce n’est pas le cas, il les supprime pour permettre leur recréation par leurs contrôleurs avec les demandes mises à jour.
Contrôleur d’admission VPA : il définit les demandes de ressources correctes sur les nouveaux pods (créés ou recréés par leur contrôleur en raison de l’activité de l’outil de mise à jour).
Contrôleur d’admission VPA
Le contrôleur d’admission VPA est un fichier binaire qui s’inscrit lui-même en tant que webhook d’admission mutant. Pour chaque pod créé, il obtient une requête du serveur d’API et évalue s’il existe une configuration VPA correspondante, ou bien il trouve une configuration correspondante et utilise la recommandation actuelle pour définir les demandes de ressources dans le pod.
Un travail autonome s’exécute en dehors du contrôleur d’admission VPA, appelé overlay-vpa-cert-webhook-check
. overlay-vpa-cert-webhook-check
est utilisé pour créer et renouveler les certificats, et pour inscrire le contrôleur d’admission VPA en tant que MutatingWebhookConfiguration
.
Pour la haute disponibilité, AKS prend en charge deux réplicas de contrôleur d’admission.
Modes de fonctionnement de l’objet VPA
Une ressource Outil de mise à l’échelle automatique verticale de pod est insérée pour chaque contrôleur dont vous voulez calculer automatiquement les besoins en ressources. Il s’agit le plus souvent d’un déploiement. Les VPA fonctionnent selon quatre modes :
Auto
: VPA affecte des demandes de ressources lors de la création du pod et met à jour les pods existants en utilisant le mécanisme de mise à jour par défaut. Actuellement,Auto
est équivalent àRecreate
, et est également le mode par défaut. Une fois que la mise à jour sans redémarrage (« sur place ») des demandes de pod est disponible, elle peut être utilisée comme mécanisme de mise à jour par défaut par le modeAuto
. Lors de l’utilisation du modeRecreate
, VPA supprime un pod s’il doit changer ses demandes de ressources. Ceci peut provoquer le redémarrage de tous les pods en même temps, ce qui entraîne des incohérences des applications. Vous pouvez limiter les redémarrages et assurer la cohérence dans cette situation en utilisant un PodDisruptionBudget.Recreate
: VPA affecte les demandes de ressources lors de la création du pod et met à jour les pods existants en les supprimant quand les ressources demandées diffèrent sensiblement de la nouvelle recommandation (en respectant le budget d’interruption de pod, s’il a été défini). Ce mode doit être utilisé rarement, seulement si vous devez faire en sorte que les pods soient redémarrés chaque fois que la demande de ressources change. Sinon, le modeAuto
est préférable, car il peut tirer parti des mises à jour sans redémarrage dès qu’elles sont disponibles.Initial
: VPA affecte seulement les demandes de ressources lors de la création du pod et ne change jamais par la suite.Off
: VPA ne change pas automatiquement les besoins en ressources des pods. Les recommandations sont calculées et peuvent être inspectées dans l’objet VPA.
Modèle de déploiement pendant le développement d’une application
Un modèle de déploiement courant recommandé si vous n’êtes familiarisé avec VPA consiste à effectuer les étapes suivantes pendant le développement d’une application afin d’identifier ses caractéristiques uniques d’utilisation des ressources, de tester le bon fonctionnement de VPA et de tester en parallèle d’autres composants Kubernetes pour optimiser l’utilisation des ressources du cluster.
Définissez UpdateMode = "Off" dans votre cluster de production et exécutez VPA en mode de recommandation afin de tester et vous familiariser avec VPA. UpdateMode = "Off" peut éviter d’introduire une configuration incorrecte qui risque de provoquer une interruption.
Commencez par établir l’observabilité en collectant la télémétrie de l’utilisation réelle des ressources sur une période donnée. Ceci vous aide à comprendre le comportement et les indicateurs des symptômes ou des problèmes liés aux ressources de conteneur et de pod influencées par les charges de travail qui s’y exécutent.
Familiarisez-vous avec les données de supervision pour comprendre les caractéristiques des performances. En fonction de cet insight, définissez les demandes/limites souhaitées en conséquence, puis dans le déploiement ou la mise à niveau qui suit.
Définissez la valeur de
updateMode
surAuto
,Recreate
ou surInitial
, en fonction de vos exigences.
Déployer, mettre à niveau ou désactiver un VPA sur un cluster
Cette section explique comment déployer, mettre à niveau ou désactivez le Vertical Pod Autoscaler sur votre cluster.
Pour activer un VPA sur un nouveau cluster, utilisez le paramètre
--enable-vpa
avec la commande az aks create.az aks create \ --name myAKSCluster \ --resource-group myResourceGroup \ --enable-vpa \ --generate-ssh-keys
Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster.
Si vous le souhaitez, pour activer VPA sur un cluster existant, utilisez la
--enable-vpa
commande [https://learn.microsoft.com/en-us/cli/azure/aks?view=azure-cli-latest#az-aks-update] .az aks update --name myAKSCluster --resource-group myResourceGroup --enable-vpa
Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster.
Si vous le souhaitez, pour désactiver VPA sur un cluster existant, utilisez la
--disable-vpa
commande [https://learn.microsoft.com/en-us/cli/azure/aks?view=azure-cli-latest#az-aks-update] .az aks update --name myAKSCluster --resource-group myResourceGroup --disable-vpa
Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster.
Pour vérifier que les pods Vertical Pod Autoscaler ont été créés avec succès, utilisez la commande kubectl get.
kubectl get pods --name kube-system
La sortie de la commande inclut les résultats suivants spécifiques des pods VPA. Les pods devraient afficher un état exécution.
NAME READY STATUS RESTARTS AGE
vpa-admission-controller-7867874bc5-vjfxk 1/1 Running 0 41m
vpa-recommender-5fd94767fb-ggjr2 1/1 Running 0 41m
vpa-updater-56f9bfc96f-jgq2g 1/1 Running 0 41m
Tester l’installation de votre Vertical Pod Autoscaler
Les étapes suivantes créent un déploiement avec deux pods, chacun exécutant un conteneur unique qui demande 100 millicœurs et essaie d’en utiliser un peu plus de 500. Une configuration VPA pointant vers le déploiement est également créée. Le VPA observe le comportement des pods et, après environ cinq minutes, ceux-ci sont mis à jour avec une demande de processeur plus élevée.
Créez un fichier nommé
hamster.yaml
et copiez-le dans le manifeste suivant de l’exemple de Vertical Pod Autoscaler à partir du référentiel GitHub kubernetes/autoscaler.Déployez l’exemple de Vertical Pod Autoscaler
hamster.yaml
à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML :kubectl apply -f hamster.yaml
Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster.
Exécutez la commande kubectl get suivante pour obtenir les pods à partir de l’exemple d’application hamster :
kubectl get pods -l app=hamster
La sortie de l’exemple ressemble à ceci :
hamster-78f9dcdd4c-hf7gk 1/1 Running 0 24s hamster-78f9dcdd4c-j9mc7 1/1 Running 0 24s
Utilisez la commande kubectl describe sur l’un des pods pour afficher sa réservation de processeur et de mémoire. Remplacez « exampleID » par l’un des ID de pod retournés dans la sortie de l’étape précédente.
kubectl describe pod hamster-exampleID
La sortie de l’exemple est un extrait de code des informations sur le cluster :
hamster: Container ID: containerd:// Image: k8s.gcr.io/ubuntu-slim:0.1 Image ID: sha256: Port: <none> Host Port: <none> Command: /bin/sh Args: -c while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done State: Running Started: Wed, 28 Sep 2022 15:06:14 -0400 Ready: True Restart Count: 0 Requests: cpu: 100m memory: 50Mi Environment: <none>
Le pod comprend 100 millicpus et 50 mébioctets (Mio) de mémoire réservés dans cet exemple. Pour cet exemple d’application, le pod ayant besoin de moins de 100 millicpus pour s’exécuter, il n’existe aucune capacité de processeur disponible. Les pods réservent également beaucoup moins de mémoire que nécessaire. Le déploiement vpa-recommender de Vertical Pod Autoscaler analyse les pods hébergeant l’application hamster pour voir si les besoins en processeur et en mémoire sont appropriés. Si des ajustements sont nécessaires, le vpa-updater relance les pods avec des valeurs mises à jour.
Attendez que vpa-updater lance un nouveau pod hamster, ce qui devrait prendre quelques minutes. Vous pouvez surveiller les pods à l’aide de la commande kubectl get.
kubectl get --watch pods -l app=hamster
Quand un nouveau pod hamster est démarré, décrivez le pod exécutant la commande kubectl describe et affichez les réservations de processeur et de mémoire mises à jour.
kubectl describe pod hamster-<exampleID>
La sortie de l’exemple est un extrait de code des informations décrivant le pod :
State: Running Started: Wed, 28 Sep 2022 15:09:51 -0400 Ready: True Restart Count: 0 Requests: cpu: 587m memory: 262144k Environment: <none>
Dans la sortie précédente, vous pouvez voir que la réservation de processeur a augmenté à 587 millicpus, soit plus de cinq fois la valeur d’origine. La mémoire est passée à 262 144 kilo-octets, soit environ 250 mébioctets ou cinq fois la valeur d’origine. Ce pod était sous-doté et le Vertical Pod Autoscaler a corrigé l’estimation avec une valeur beaucoup plus appropriée.
Pour afficher les recommandations mises à jour du VPA, exécutez la commande kubectl describe pour décrire les informations de ressource hamster-vpa.
kubectl describe vpa/hamster-vpa
La sortie de l’exemple est un extrait de code des informations sur l’utilisation des ressources :
State: Running Started: Wed, 28 Sep 2022 15:09:51 -0400 Ready: True Restart Count: 0 Requests: cpu: 587m memory: 262144k Environment: <none>
Définir les demandes de l’outil de mise à l’échelle automatique de pod
La mise à l’échelle automatique verticale de pod utilise l’objet VerticalPodAutoscaler
pour définir automatiquement les demandes de ressources sur les pods quand le mode de mise à jour (updateMode) est défini sur Auto. Vous pouvez définir une valeur différente en fonction de vos besoins et des tests réalisés. Dans cet exemple, updateMode est défini sur Recreate
.
Activez le VPA pour votre cluster en exécutant la commande suivante. Remplacez le nom de cluster
myAKSCluster
par le nom de votre cluster AKS, et remplacezmyResourceGroup
par le nom du groupe de ressources dans lequel le cluster est hébergé.az aks update --name myAKSCluster --resource-group myResourceGroup --enable-vpa
Créez un fichier nommé
azure-autodeploy.yaml
et copiez-y le manifeste suivant.apiVersion: apps/v1 kind: Deployment metadata: name: vpa-auto-deployment spec: replicas: 2 selector: matchLabels: app: vpa-auto-deployment template: metadata: labels: app: vpa-auto-deployment spec: containers: - name: mycontainer image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine resources: requests: cpu: 100m memory: 50Mi command: ["/bin/sh"] args: ["-c", "while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done"]
Ce manifeste décrit un déploiement avec deux pods. Chaque pod a un conteneur qui demande 100 milliCPU et 50 Mio de mémoire.
Créez le pod avec la commande kubectl create, comme indiqué dans l’exemple suivant :
kubectl create -f azure-autodeploy.yaml
Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster.
Exécutez la commande kubectl get suivante pour obtenir les pods :
kubectl get pods
La sortie ressemble à l’exemple suivant montrant le nom et l’état des pods :
NAME READY STATUS RESTARTS AGE vpa-auto-deployment-54465fb978-kchc5 1/1 Running 0 52s vpa-auto-deployment-54465fb978--namehtmj 1/1 Running 0 52s
Créez un fichier nommé
azure-vpa-auto.yaml
et copiez-y le manifeste suivant qui décrit unVerticalPodAutoscaler
:apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: vpa-auto spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: vpa-auto-deployment updatePolicy: updateMode: "Recreate"
La valeur
targetRef.name
spécifie que tout pod contrôlé par un déploiement nommévpa-auto-deployment
appartient àVerticalPodAutoscaler
. La valeurRecreate
pourupdateMode
signifie que le contrôleur de l’outil de mise à l’échelle automatique de pod peut supprimer un pod, ajuster les demandes de processeur et de mémoire, puis créer un pod.Appliquez le manifeste au cluster à l’aide de la commande kubectl apply :
kubectl create -f azure-vpa-auto.yaml
Attendez quelques minutes, puis réaffichez les pods en cours d’exécution en exécutant la commande kubectl get suivante :
kubectl get pods
La sortie ressemble à l’exemple suivant montrant les noms de pods qui ont changé et l’état des pods :
NAME READY STATUS RESTARTS AGE vpa-auto-deployment-54465fb978-qbhc4 1/1 Running 0 2m49s vpa-auto-deployment-54465fb978-vbj68 1/1 Running 0 109s
Obtenez des informations détaillées sur un de vos pods en cours d’exécution en utilisant la commande Kubectl get. Remplacez
podName
par le nom d’un de vos pods que vous avez récupéré à l’étape précédente.kubectl get pod podName --output yaml
La sortie ressemble à l’exemple suivant, montrant que le contrôleur de Vertical Pod Autoscaler a augmenté la demande de mémoire à 262 144 k et la demande de processeur à 25 millicpu.
apiVersion: v1 kind: Pod metadata: annotations: vpaObservedContainers: mycontainer vpaUpdates: 'Pod resources updated by vpa-auto: container 0: cpu request, memory request' creationTimestamp: "2022-09-29T16:44:37Z" generateName: vpa-auto-deployment-54465fb978- labels: app: vpa-auto-deployment spec: containers: - args: - -c - while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done command: - /bin/sh image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine imagePullPolicy: IfNotPresent name: mycontainer resources: requests: cpu: 25m memory: 262144k
Pour obtenir des informations détaillées sur le Vertical Pod Autoscaler et ses recommandations pour le processeur et la mémoire, utilisez la commande kubectl get :
kubectl get vpa vpa-auto --output yaml
La sortie ressemble à l’exemple suivant :
recommendation: containerRecommendations: - containerName: mycontainer lowerBound: cpu: 25m memory: 262144k target: cpu: 25m memory: 262144k uncappedTarget: cpu: 25m memory: 262144k upperBound: cpu: 230m memory: 262144k
Les résultats indiquent l’attribut
target
qui spécifie que, pour que le conteneur s’exécute de manière optimale, il n’a pas besoin de modifier le processeur ou la mémoire cibles. Vos résultats peuvent varier quand les recommandations de processeur et de mémoire cibles sont supérieures.L’outil de mise à l’échelle automatique de pod utilise les attributs
lowerBound
etupperBound
pour décider s’il faut supprimer un pod et le remplacer par un nouveau. Si un pod a des demandes inférieures à la limite inférieure ou supérieures à la limite supérieure, l’outil de mise à l’échelle automatique de pod supprime le pod et le remplace par un pod répondant à l’attribut cible.
Générateur de recommandations supplémentaire pour l’outil de mise à l’échelle automatique de pod
Le générateur de recommandations est un des principaux composants du VPA. Il fournit des recommandations pour l’utilisation des ressources en fonction de la consommation des ressources en temps réel. AKS déploie un générateur de recommandations quand un cluster active le VPA. Vous pouvez déployer un générateur de recommandations personnalisé ou un générateur de recommandations supplémentaire avec la même image que l’image par défaut. L’avantage d’un générateur de recommandations personnalisé est que vous pouvez personnaliser votre logique de recommandation. Avec un générateur de recommandations supplémentaire, vous pouvez partitionner des VPA sur plusieurs générateurs de recommandations s’il existe de nombreux objets VPA.
L’exemple suivant est un générateur de recommandations supplémentaire que vous appliquez à votre cluster AKS existant. Vous configurez ensuite l’objet VPA pour utiliser le générateur de recommandations supplémentaire.
Créez un fichier nommé
extra_recommender.yaml
et copiez-y le manifeste suivant :apiVersion: apps/v1 kind: Deployment metadata: name: extra-recommender namespace: kube-system spec: replicas: 1 selector: matchLabels: app: extra-recommender template: metadata: labels: app: extra-recommender spec: serviceAccountName: vpa-recommender securityContext: runAsNonRoot: true runAsUser: 65534 # nobody containers: - name: recommender image: registry.k8s.io/autoscaling/vpa-recommender:0.13.0 imagePullPolicy: Always args: - --recommender--nameame=extra-recommender resources: limits: cpu: 200m memory: 1000Mi requests: cpu: 50m memory: 500Mi ports: - name: prometheus containerPort: 8942
Déployez l’exemple de VPA
extra-recomender.yaml
en utilisant la commande kubectl apply et spécifiez le nom de votre manifeste YAML.kubectl apply -f extra-recommender.yaml
Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster.
Créez un fichier nommé
hamnster_extra_recommender.yaml
et copiez-y le manifeste suivant :apiVersion: "autoscaling.k8s.io/v1" kind: VerticalPodAutoscaler metadata: name: hamster-vpa spec: recommenders: - name: 'extra-recommender' targetRef: apiVersion: "apps/v1" kind: Deployment name: hamster updatePolicy: updateMode: "Auto" resourcePolicy: containerPolicies: - containerName: '*' minAllowed: cpu: 100m memory: 50Mi maxAllowed: cpu: 1 memory: 500Mi controlledResources: ["cpu", "memory"] --- apiVersion: apps/v1 kind: Deployment metadata: name: hamster spec: selector: matchLabels: app: hamster replicas: 2 template: metadata: labels: app: hamster spec: securityContext: runAsNonRoot: true runAsUser: 65534 # nobody containers: - name: hamster image: k8s.gcr.io/ubuntu-slim:0.1 resources: requests: cpu: 100m memory: 50Mi command: ["/bin/sh"] args: - "-c" - "while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done"
Si
memory
n’est pas spécifié danscontrolledResources
, le générateur de recommandations ne répond pas aux événements OOM. Dans ce cas, vous définissez seulement le processeur danscontrolledValues
.controlledValues
vous permet de choisir de mettre à jour les demandes de ressources du conteneur avec l’optionRequestsOnly
, ou bien à la fois les demandes de ressources et les limites en utilisant l’optionRequestsAndLimits
. La valeur par défaut estRequestsAndLimits
. Si vous utilisez l’optionRequestsAndLimits
, les demandes sont calculées en fonction de l’utilisation réelle, et les limites sont calculées en fonction du ratio des demandes et des limites du pod actuel.Par exemple, si vous commencez avec un pod qui demande 2 processeurs et limite à 4 processeurs, VPA définit toujours la limite pour que sa valeur soit de deux fois les demandes. Le même principe s’applique à la mémoire. Quand vous utilisez le mode
RequestsAndLimits
, il peut servir de blueprint pour vos demandes et vos limites de ressources d’application initiales.
Vous pouvez simplifier l’objet VPA en utilisant le mode Auto et en calculant des recommandations à la fois pour le processeur et pour la mémoire.
Déployez l’exemple
hamster_extra-recomender.yaml
en utilisant la commande kubectl apply et spécifiez le nom de votre manifeste YAML.kubectl apply -f hamster_customized_recommender.yaml
Attendez que vpa-updater lance un nouveau pod hamster, ce qui devrait prendre quelques minutes. Vous pouvez surveiller les pods à l’aide de la commande kubectl get.
kubectl get --watch pods -l app=hamster
Quand un nouveau pod hamster est démarré, décrivez le pod exécutant la commande kubectl describe et affichez les réservations de processeur et de mémoire mises à jour.
kubectl describe pod hamster-<exampleID>
La sortie de l’exemple est un extrait de code des informations décrivant le pod :
State: Running Started: Wed, 28 Sep 2022 15:09:51 -0400 Ready: True Restart Count: 0 Requests: cpu: 587m memory: 262144k Environment: <none>
Pour afficher les recommandations mises à jour du VPA, exécutez la commande kubectl describe pour décrire les informations de ressource hamster-vpa.
kubectl describe vpa/hamster-vpa
La sortie de l’exemple est un extrait de code des informations sur l’utilisation des ressources :
State: Running Started: Wed, 28 Sep 2022 15:09:51 -0400 Ready: True Restart Count: 0 Requests: cpu: 587m memory: 262144k Environment: <none> Spec: recommenders: Name: customized-recommender
Dépannage
Pour diagnostiquer les problèmes liés à une installation VPA, effectuez les étapes suivantes.
Vérifiez si tous les composants système sont en cours d’exécution en utilisant la commande suivante :
kubectl --namespace=kube-system get pods|grep vpa
La sortie doit lister trois pods : générateur de recommandation, outil de mise à jour et contrôleur d’admission, tous avec l’état Running
.
Vérifiez si les composants système consignent des erreurs. Pour chacun des pods retournés par la commande précédente, exécutez la commande suivante :
kubectl --namespace=kube-system logs [pod name] | grep -e '^E[0-9]\{4\}'
Vérifiez que la définition de ressources personnalisée a été créée en exécutant la commande suivante :
kubectl get customresourcedefinition | grep verticalpodautoscalers
Étapes suivantes
Cet article vous a montré comment mettre automatiquement à l’échelle l’utilisation par des nœuds de cluster de ressources telles que le processeur et la mémoire pour répondre aux exigences d’une application.
Vous pouvez également utiliser le programme de mise à l’échelle automatique de pods élastique pour ajuster automatiquement le nombre de pods qui exécutent votre application. Pour obtenir des instructions sur l’utilisation du programme de mise à l’échelle automatique de pods élastique, consultez l’article Mettre à l’échelle des applications dans Azure Kubernetes Service (AKS).
Consultez les [informations de référence sur l’API] sur VPA pour en savoir plus sur les définitions des objets VPA associés.
Azure Kubernetes Service
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour