Mise à l’échelle automatique verticale de pod dans Azure Kubernetes Service (AKS)

Article
12/23/2023

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 mode Auto. Lors de l’utilisation du mode Recreate, 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 mode Auto 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 sur Auto, Recreate ou sur Initial, 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
```
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 remplacez myResourceGroup 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 un VerticalPodAutoscaler :
```
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 valeur Recreate pour updateMode 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 et upperBound 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é dans controlledResources, le générateur de recommandations ne répond pas aux événements OOM. Dans ce cas, vous définissez seulement le processeur dans controlledValues. controlledValues vous permet de choisir de mettre à jour les demandes de ressources du conteneur avec l’option RequestsOnly, ou bien à la fois les demandes de ressources et les limites en utilisant l’option RequestsAndLimits. La valeur par défaut est RequestsAndLimits. Si vous utilisez l’option RequestsAndLimits, 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.

Share via