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

S’applique à : ✔️ AKS Automatic ✔️ AKS Standard

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.

Pour la plupart des charges de travail de production, AKS Automatic est l’expérience AKS par défaut recommandée. AKS Automatic est prêt pour la production par défaut et inclut VPA comme fonctionnalité de cluster préconfigurée. Dans AKS Standard, vous configurez et gérez explicitement VPA.

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 augmentations soudaines de l’utilisation des ressources, utilisez le Horizontal Pod Autoscaler, qui ajuste le nombre de réplicas de pods selon les besoins.

Pour en savoir plus sur AKS Automatic, consultez Qu’est-ce que Azure Kubernetes Service (AKS) Automatique ?

VPA dans AKS Automatic et AKS Standard

VPA est disponible dans les deux modes de cluster AKS, mais la configuration diffère :

• AKS Automatic : VPA est préconfiguré.
• AKS Standard : VPA est facultatif et configuré explicitement.

Pour la plupart des scénarios de production, commencez par AKS Automatic pour utiliser les valeurs par défaut prêtes pour la production et réduire la surcharge opérationnelle.

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. VPA est responsable non seulement de l'augmentation mais aussi de la réduction de ses ressources en fonction de leur utilisation dans le 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.
• Garantit que les nœuds disposent des 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 garantit une prise en charge optimale pour un maximum de 1 000 pods par cluster associé à des objets VerticalPodAutoscaler. À mesure que le nombre de pods suivis augmente, la consommation de mémoire augmente sur tous les composants VPA, en particulier pour le générateur de recommandations, ce qui peut affecter l’extensibilité.
• 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 le Horizontal Pod Autoscaler (HPA), qui effectue des mises à l’échelle basées sur les mêmes métriques d’utilisation du CPU 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 parallèle. 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.
• VPA Admission Controller: Le VPA Admission Controller définit les demandes de ressources correctes sur les nouveaux pods, qu’ils soient créés ou recréés par leur contrôleur, en fonction de l’activité de l’Updater.

Contrôleur d’admission VPA

Le VPA Admission Controller est un binaire qui s’enregistre en tant que Mutating Admission Webhook. 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 VPA Admission Controller. Le travail overlay-vpa-cert-webhook-check crée et renouvelle les certificats et enregistre le VPA Admission Controller 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 :

• 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. Sinon, nous vous recommandons d’utiliser InPlaceOrRecreate le mode, qui tire parti des mises à jour sans redémarrage si possible.
• InPlaceOrRecreate: en mode InPlaceOrRecreate, VPA tente de mettre à jour les demandes et limites des ressources pod sans redémarrer le pod si possible. Cependant, lorsque les mises à jour sur place ne peuvent pas être appliquées pour une modification de ressource donnée, le VPA recourt à l’expulsion du pod (à l’image du mode « Recreate ») et permet au contrôleur de charge de travail de créer un pod de substitution avec des ressources actualisées. Ce mode est disponible sur AKS 1.34+.
  • Pour essayer InPlaceOrRecreate le mode, suivez les instructions pas à pas.
  • Dans ce mode, le programme de mise à jour applique des recommandations sur place à l’aide de la fonctionnalité Redimensionner les ressources de conteneur sur place.
  • Pour plus d’informations, consultez la documentation des mises à jour in situ en amont.
• Initial : VPA alloue uniquement les demandes de ressources lors de la création d'un pod. Il ne met pas à jour les pods existants. Ce mode est utile pour tester et comprendre le comportement de la VPA sans affecter les pods actuellement 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 pas familiarisé avec VPA, utilisez le modèle de déploiement suivant pendant le développement d’applications pour identifier les caractéristiques uniques d’utilisation des ressources de chaque application, tester VPA pour vérifier qu’il fonctionne correctement et tester en même temps que 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 les données de télémétrie réelles de l’utilisation des ressources sur une période donnée. Cette télémétrie vous aide à comprendre le comportement et les signes de problèmes liés aux ressources conteneur et pod influencées par les charges de travail exécutées sur ces conteneurs et pods.
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 lors du prochain déploiement ou de la prochaine mise à niveau.
4. Définissez la valeur de updateMode sur Recreate, InPlaceOrRecreate ou sur Initial, en fonction de vos exigences.

Dans AKS Automatic, VPA est déjà disponible en tant que fonctionnalité préconfigurée. Par conséquent, concentrez-vous sur le réglage de la stratégie et du mode. Dans AKS Standard, effectuez la configuration VPA avant d’appliquer le modèle de déploiement.

Contenu connexe

• Créer un cluster automatique Azure Kubernetes Service (AKS)
• Utiliser le Vertical Pod Autoscaler sur AKS