Partager via

Mise à l’échelle automatique verticale des pods dans AKS (Azure Kubernetes Service)

  • Article

Cet article donne une vue d’ensemble de l’utilisation de l’outil de mise à l’échelle automatique verticale des pods (VPA, Vertical Pod Autoscaler) dans AKS (Azure Kubernetes Service), qui est basé sur la version open source de Kubernetes.

Une fois configuré, VPA définit automatiquement des demandes et limites de ressources sur des conteneurs par charge de travail en fonction de l’utilisation passée. VPA libère le processeur et la mémoire pour les autres pods, facilitant une utilisation efficace de vos clusters AKS. Vertical Pod Autoscaler 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

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 dont le mode de mise à l’échelle est défini sur Auto ou Recréer est supprimé s’il doit changer ses demandes de ressources.
  • Vous pouvez définir des contraintes de processeur et de mémoire pour des conteneurs individuels en spécifiant une stratégie de ressource.
  • Il veille à ce que les nœuds disposent de ressources correctes pour la planification des pods.
  • Il offre une journalisation configurable des ajustements des ressources de processeur ou de mémoire effectués.
  • Il améliore l’utilisation des ressources de cluster et libère des ressources de processeur et de mémoire pour d’autres pods.

Limitations et considérations

Tenez compte des limitations et considérations suivantes lors de l’utilisation de Vertical Pod Autoscaler :

  • VPA prend en charge jusqu’à 1000 pods associés à des objets VerticalPodAutoscaler par cluster.
  • VPA est susceptible de recommander une quantité de ressources supérieure à celle disponible dans le cluster, ce qui empêche le pod d’être affecté à un nœud et de s’exécuter en raison de ressources insuffisantes. 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é. Vous pouvez également définir le nombre maximal de recommandations de ressources autorisées par pod dans un objet VerticalPodAutoscaler. 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 VPA avec l’outil de mise à l’échelle automatique horizontale de pod (HPA), qui effectue des mises à l’échelle basées sur les mêmes métriques d’utilisation du processeur et de la mémoire.
  • Le générateur de recommandations de VPA conserve un historique des données seulement pour un maximum de huit jours.
  • 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.
  • VPA ne prend pas en charge l’exécution de votre propre implémentation de VPA en même temps que l’implémentation par défaut. 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.

Vue d’ensemble de VPA

L’objet VPA est constitué de trois composants :

  • Générateur de recommandations : le générateur de recommandations surveille la consommation actuelle et passée des ressources, y compris l’historique des métriques, les événements OOM (Out of Memory) et les spécifications de déploiement VPA, et il utilise les informations qu’il collecte pour fournir des valeurs recommandées pour les demandes/limites de processeur et de mémoire du conteneur.
  • Outil de mise à jour: L’outil de mise à jour surveille les pods managés pour s’assurer que leurs demandes de ressources sont correctement définies. Si ce n’est pas le cas, il supprime ces pods afin que leurs contrôleurs puissent les recréer avec les demandes mises à jour.
  • Contrôleur d’admission VPA : le Contrôleur d’admission VPA définit les demandes de ressources correctes sur les nouveaux pods, créés ou recréés par leur contrôleur en fonction 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. Lorsqu’un pod est créé, le Contrôleur d’admission VPA 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, overlay-vpa-cert-webhook-check, s’exécute en dehors du Contrôleur d’admission VPA. Le travail overlay-vpa-cert-webhook-check crée et renouvelle les certificats, et inscrit le Contrôleur d’admission VPA en tant que MutatingWebhookConfiguration.

Modes de fonctionnement de l’objet VPA

Une ressource Vertical Pod Autoscaler, le plus souvent un déploiement, est insérée pour chaque contrôleur dont vous voulez calculer automatiquement les besoins en ressources.

VPA fonctionne 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. Auto, qui est équivalent à Recreate, est le mode par défaut. Une fois que les mises à jour sans redémarrage (ou sur place) des demandes de pod sont disponibles, elles peuvent être utilisées comme mécanisme de mise à jour par défaut par le mode Auto. Avec le mode Auto, VPA supprime un pod s’il doit changer ses demandes de ressources. Ceci peut provoquer le redémarrage simultané de tous les pods, ce qui risque d’entraîner 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 des nouvelles recommandations (en respectant PodDisruptionBudget, s’il a été défini). Vous ne devez utiliser ce mode que si vous devez faire en sorte que les pods soient redémarrés chaque fois que la demande de ressources change. Autrement, nous vous recommandons d’utiliser le mode Auto, qui tire parti des mises à jour sans redémarrage une fois disponibles.
  • Initial : VPA affecte uniquement les demandes de ressources lors de la création du pod. Il ne met pas à jour les pods existants. Ce mode est utile pour tester et comprendre le comportement de VPA sans affecter les pods en cours d’exécution.
  • 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 pour le développement d’application

Si vous n’êtes familiarisé avec VPA, nous recommandons le modèle de déploiement suivant 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 :

  1. Définissez UpdateMode = "Off" dans votre cluster de production, et exécutez VPA en mode recommandation afin de tester VPA et de vous familiariser avec lui. UpdateMode = "Off" peut éviter d’introduire une configuration incorrecte susceptible de provoquer une panne.
  2. Établissez d’abord l’observabilité en collectant la télémétrie d’utilisation des ressources réelle sur une période donnée, ce qui vous permettra de comprendre le comportement et d’identifier tout signe de problème lié aux ressources de conteneur et de pod influencé par les charges de travail en cours d’exécution.
  3. 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.
  4. Définissez la valeur de updateMode sur Auto, Recreate ou sur Initial, en fonction de vos exigences.

Étapes suivantes

Pour découvrir comment configurer Vertical Pod Autoscaler sur votre cluster AKS, consultez Utiliser Vertical Pod Autoscaler dans AKS.