L’autoscaling est une fonctionnalité de Kubernetes qui permet d'ajuster automatiquement la taille de son instance en fonction de la charge de travail. L'idée est d'optimiser l'utilisation des ressources et de garantir que l’environnement dispose toujours de la capacité nécessaire pour exécuter les applications sans sur ou sous-utilisation des ressources tout en simplifiant la gestion opérationnelle.

Autoscaling, que propose les géants du Cloud ?

Sur base du composant Cluster Autoscaler qui date de la v1.8 de Kubernetes, les 3 géants US du cloud fournissent des services d’autoscaling pour ajuster dynamiquement la capacité du cluster Kubernetes en fonction des métriques de performance. Cela permet aux utilisateurs de maintenir un usage efficient des ressources tout en garantissant des performances optimisées pour leurs applications déployées. Tour d’horizon.

Le Cluster Autoscaler pour Kubernetes ajuste automatiquement la taille du cluster en fonction de la demande. Il peut mettre à l’échelle horizontalement en ajoutant ou en supprimant des nodes en fonction de la charge. Il utilise des métriques telles que l'utilisation des ressources du cluster pour prendre des décisions d'échelle.

Quand Azure se contente d’intégrer le composant, Google Cloud propose une offre spécifique, GKE Autopilot, et AWS un outil dédié, Karpenter

Cluster autoscaling, véritable eldorado ?

Le cluster autoscaling offre ainsi une grande flexibilité pour ajuster dynamiquement la taille de ses clusters en fonction de la charge de travail et d’avoir à moins se concentrer sur son infrastructure sous-jacente et plus sur ses applications et services. Mais, tel que proposé par les Big 3, il présente également certaines limites.

· Temps de réponse : Le cluster autoscaling peut nécessiter un certain temps pour détecter la charge croissante et provisionner de nouveaux nodes ou supprimer des nodes existants. Ce délai peut entraîner des retards dans la mise à l'échelle, impactant potentiellement les performances pendant cette période de transition.

· Coûts : Le cluster autoscaling peut être coûteux à cause de l’effet de palier induit par la mécanique d’ajout de nodes. Un scaling excessif peut également entraîner un gaspillage de ressources si la charge de travail diminue rapidement après le scaling.

· Downscale manuel : Si l’autoscaling est efficient pour ajouter des nodes au regard de la croissance de la charge (upscale), l’inverse (downscale) est rarement automatisé est nécessite chez les providers cloud une action manuelle et/ou une configuration supplémentaire.

· Impact sur les applications : Lorsque de nouveaux nodes sont ajoutés ou supprimés, cela peut affecter les applications en cours d'exécution. Si les applications ne sont pas conçues pour être tolérantes aux pannes ou pour gérer les changements de configuration, cela peut perturber leur fonctionnement.

Du cluster autoscaling au pod autoscaling

Il existe trois principaux types de mécanismes d'autoscaling dans Kubernetes : l'autoscaling des clusters que l’on vient d’aborder, mais aussi l'autoscaling horizontal de pods (HPA) et l'autoscaling vertical de pods (VPA). Chacun de ces mécanismes fonctionne différemment et correspond à un ensemble différent de scénarios, les 2 derniers agissant au niveau du pod permettent néanmoins des réglages plus fins.

Le Vertical Pod Autoscaling (VPA) est un add-on de Kubernetes qui vise à ajuster automatiquement les demandes de ressources (CPU et mémoire) des conteneurs d’un pod en fonction de leurs besoins réels en ressources. Contrairement au Cluster Autoscaling qui agit sur la taille du cluster, le Vertical Pod Autoscaling se concentre sur l'optimisation des ressources allouées à chaque pod.

Avantages

• Utilisation efficace des ressources : Le VPA garantit que les pods ont la quantité exacte de ressources dont ils ont besoin, évitant ainsi le sous et le sur-approvisionnement des ressources.

• Performances applicatives améliorées : en fournissant aux pods les ressources nécessaires, le VPA peut optimiser les performances et la réactivité des applications.

• Coûts cloud réduits : une allocation efficace des ressources, peut minimiser les coûts d'infrastructure cloud. Encore plus vrai associé à une granularité plus fine (au CPU, au Go) dans le paramétrage des ressources.

Inconvénients

• Évolutivité limitée : le VPA est moins adapté aux applications avec des demandes de ressources imprévisibles ou des charges de travail fluctuantes.

• Configuration manuelle : nécessite une configuration manuelle des demandes de ressources et des limites pour chaque pod.

Cas d'utilisation de l’autoscaling vertical

• Applications gourmandes en mémoire : ces applications peuvent bénéficier de la capacité de l’autoscaling vertical à ajuster les ressources mémoire de manière dynamique.

• Applications stateful : Les applications avec des besoins de ressources constants peuvent tirer parti du redimensionnement piloté des ressources.

• Traitements par lots : Les travaux de traitement par lots intensifs en ressources peuvent bénéficier de la capacité du VPA à fournir les ressources nécessaires pour une exécution efficace et limitée dans le temps.

L’Horizontal Pod Autoscaling (HPA) ajuste le nombre de pods dans un déploiement en fonction de métriques telles que l'utilisation du CPU ou de la mémoire. Cette approche convient aux applications présentant des besoins en ressources variables et des charges de travail fluctuantes.

Avantages

· Scalabilité élastique : Le HPA peut automatiquement ajuster le nombre de pods pour gérer les pics de trafic ou les besoins en ressources.

· Adaptation à la charge de travail : Le HPA peut s'adapter aux schémas de charge de travail fluctuant, garantissant une disponibilité adéquate des ressources.

· Réduction des charges opérationnelles : Le HPA automatise le processus de redimensionnement, réduisant au minimum l'intervention manuelle.

Inconvénients

• Coûts d'infrastructure accrus : Ajouter davantage de pods ayant un prérequis de ressources minimum, peut entraîner des coûts d'infrastructure cloud plus élevés.

• Temps de réponse plus longs : L'ajout de nouveaux pods peut prendre du temps, entraînant des retards potentiels dans la gestion des pics soudains de trafic.

Cas d'utilisation de l’autoscaling horizontal

• Applications web : Les applications web avec des schémas de trafic fluctuants peuvent bénéficier des capacités de redimensionnement dynamique du HPA.

• Architectures de microservices : Le HPA est bien adapté aux applications basées sur des microservices présentant des besoins en ressources diversifiés.

• Charges de travail imprévisibles : Les applications ayant des besoins en ressources imprévisibles peuvent tirer parti de la capacité du HPA à redimensionner en temps réel.

Le Pod Autoscaling, qu’il soit horizontal ou vertical, complète ainsi le Cluster Autoscaling en s'attaquant à un niveau plus granulaire, optimisant les ressources allouées aux conteneurs individuels pour améliorer l'efficacité globale de l'environnement Kubernetes.

Cette approche, couplée à une infrastructure serverless autorisant de facto une granularité fine, semble être l’idéal pour profiter pleinement de la puissance permise par l’autoscaling de Kubernetes.

Une scalabilité déléguée ET maitrisée

L’autoscaling tel que proposé par les géants du cloud, semble clairement plus à leur l’avantage qu’à celui de leurs utilisateurs. Si la simplification de la gestion d’une infra cloud pour les développeurs est indéniable, l’effet de palier dû à l’unité retenue dans leurs offres, le node, ajouté au fait que l’auto-mode ne fonctionne nativement que pour l’upscale, n’est pas sans impact sur le volet financier pour les utilisateurs.

Pas de surprise néanmoins, le métier de ces acteurs reste de vendre de l’infrastructure, ils ne dérogent pas à cette logique dans le cadre de leurs offres « Cluster Autoscaling ».

Le mode Autopilot de la solution h8lio, qui combine autoscaling du pod vertical (VPA) ET horizontal (HPA), change ce paradigme et permet de rendre plus intéressant le fait de déléguer et d’automatiser la gestion de ses ressources. Le mode Autopilot traitant sans distinguo l’upscale et le downscale, c’est encore plus prégnant.