Comment Miro a optimisé la mise à l’échelle de Kubernetes

Comment mêler plusieurs types d’instances ? En exploiter des préemptives ? Faire du multi-AZ ? Autant d’aspects sur lesquels les nodepools de Kubernetes sont susceptibles d’entraîner des complications.

L’équipe Compute de Miro (plate-forme de collaboration numérique) s’est retrouvée confrontée à ces questions avec son déploiement EKS.

L’implémentation initiale, réalisée début 2021, exploitait les groupes de nœuds gérés EKS et l’outil Cluster Autoscaler. Les premiers automatisent l’approvisionnement et la gestion du cycle de vie des nœuds (pas besoin de provisionner les instances EC2 sous-jacentes). Le second s’appuie sur les groupes d’autoscaling EC2 pour ajuster automatiquement la taille des clusters lorsque des pods manquent de ressources ou qu’un nœud est sous-utilisé.

Miro face aux limites de l’autoscaling EKS

Ce couple a bien fonctionné tant que le volume de workloads était restreint et prédictible, explique Miro. Avec la montée en charge, l’autoscaling natif d’EKS a fini par montrer ses limites. En particulier sur les points suivants :

– Gérer l’hétérogénéité des workloads alors qu’il est conseillé de ne pas mixer des instances de tailles diverses
Opter pour de grosses instances apporte une tranquillité d’esprit, mais a un coût. Créer de multiples groupes est une autre option, mais elle accroît la complexité.

– Maintenir la disponibilité sur instances Spot
Miro cherche à exécuter l’essentiel de ses clusters hors prod sur de telles machines. Mais un bon usage de ce modèle implique d’accepter une diversité de types et des tailles de VM. Ce qui tend à entrer en conflit avec les groupes d’autoscaling.

– Assurer l’exploitation et la maintenance
Les groupes d’autoscaling prennent du temps pour récupérer lorsqu’un type d’instance est indisponible. Idem pour la maintenance sur les groupes de nœuds gérés (rotation des nœuds, mise à jour des images système…).

– Utiliser des volumes persistants avec Cluster Autoscaler
Cela nécessite d’aligner les tags AWS entre les instances et les groupes d’autoscaling. Par ailleurs, les volumes EBS étant liés à une zone de disponibilité spécifique, il est nécessaire de créer un groupe différent sur chaque zone.

L’option Karpenter

Lorsqu’il ne lui a plus été possible d’exécuter de façon fiable ses clusters hors prod sur des instances Spot, Miro s’est orienté vers Karpenter, un autoscaler open source qu’on doit… à AWS. Ses fonctions, dans les grandes lignes :

> Surveiller les pods non planifiables
> Évaluer les contraintes des pods planifiés
> Provisionner les nœuds les plus adaptés
> Éliminer les nœuds qui ne sont plus nécessaires

Les provisioners sont un concept central à Karpenter. Chacune de ces CRD gère un ensemble de nœuds. Elles permettent de spécifier des configurations de provisionnement.

Karpenter peut notamment activer, au niveau de ces provisioners, un mécanisme dit de consolidation. L’objectif : réduire les ressources inutilisées. Il consiste, dans un premier temps, à éliminer les nœuds vides. Puis à envisager les possibilités de supprimer plusieurs nœuds à la fois (évaluation heuristique). Enfin, à étudier la suppression de nœuds individuels (évaluation au cas par cas) pour éventuellement les remplacer par des nœuds plus efficaces.

Pour se prémunir des aléas potentiels de  consolidation, on aura appliqué quelques bonnes pratiques Kubernetes. Dont :

– Déployer de multiples instances des workloads
– Les répartir équitablement entre nœuds et zones de défaillance
– Définir un PodDisruptionBudget précis pour chaque workload (cela permet d’éviter la suppression simultanée de tous les réplicas d’un service)
– S’assurer que les applications gèrent « en douceur » l’arrêt des nœuds

SQS et EventBridge mis à contribution

Miro a dédié un groupe de nœuds gérés à Karpenter, installé et configuré via Terraform. L’outil accède aux API EC2 par l’intermédiaire d’un compte de service, avec les rôles IAM adaptés. Il lance les instances appropriées dans les AZ et les sous-réseaux souhaités.

Les provisioners lancent une nouvelle machine dès lors qu’ils reçoivent un avertissement d’extinction d’instance Spot. Karpenter surveille pour cela une file d’attente SQS configurée au préalable avec les règles EventBridge nécessaires.

Miro affirme avoir atteint, grâce à cette approche, un taux d’efficacité de 95 % sur ses clusters. En paramétrant un durée de vie maximale de 30 jours pour les nœuds, ils s’assure en outre que ceux-ci utilisent les dernières AMI.

Illustration principale © LuckyStep – Adobe Stock