Les choix d'e-TF1 pour optimiser son infra conteneurisée

Garder en interne ou mettre en open source ?

Les équipes d'e-TF1 en sont arrivées à cette question avec l'un des outils qu'elles ont développés. Son rôle : éteindre automatiquement les environnements hors production lors des périodes creuses.

Cette extinction est gérée au niveau des clusters, chacun étant autonome dans son cycle de vie. Deux solutions open source ont été envisagées. D'une part, Kube-green, qui agit principalement sur les replicas de déploiements et les tâches cron, en stockant leur état précédent dans un secret. De l'autre, Kubecost Cluster Turndown, qui agit sur le scaling des noeuds via des CRD.

En plus d'un conflit potentiel avec les outils GitOps, Kube-green est limité aux ressources gérées par l'opérateur (les statefulsets ne sont ainsi pas couverts, par exemple). Quant à Kubecost Cluster Turndown, il n'est pas compatible avec Karpenter, qu'e-TF1 utilise pour la mise à l'échelle de ses clusters.

C'est dans ce contexte qu'un outil interne a été développé. Il gère la sauvegarde et la destruction des nodepools Karpenter. Tout en désactivant les alertes dans Altermanager et en créant des silences temporaires avant chaque extinction pour éviter les notifications superflues pendant les périodes de fermeture. À la destruction d'un nodepool, les instances EC2 sous-jacentes s'éteignent.

Outre le décalage temporaire qu'elle crée vis-à-vis de Terraform*, cette approche implique des investissements en maintenance. D'où la perspective d'une éventuelle intégration de ses fonctionnalités dans un outil open source.

Karpenter + KEDA pour l'autoscaling

e-TF1 a déployé Karpenter en remplacement de cluster-autoscaler. Pour la mise à l'échelle des applications, KEDA (Kubernetes Event-Driven Autoscaling) a remplacé l'Horizontal Pod Autoscaler. À la clé, la possibilité d'utiliser divers déclencheurs (métriques Prometheus, files SQS, topics Kafka...) pour scaler en fonction des besoins métiers. L'outil utilise une CRD ScaledObject.

Pour couvrir les pics de charge imprévus, il a été décidé d'un surprovisionnement de 5 %. Il est mis en oeuvre par l'intermédiaire du chart Cluster Overprovisioner. Ce dernier, qu'on doit à l'entreprise allemande codecentric, combine deux fonctionnalités :

• Le CPA (Cluster Proportional Autoscaler) de Kubernetes
  Ce composant effectue la mise à l'échelle en fonction de la taille du cluster, en tenant compte du nombre de noeuds planifiables et de coeurs disponibles.
  
  
• Le déploiement de pods basse priorité
  Ces pods sollicitent des ressources, mais ne les consomment pas. Ils sont ensuite évincés, permettant de créer d'autres pods "normaux" tout en déclenchant une mise à l'échelle avec cluster-autoscaler.

Un groupe de noeuds géré est dédié à Karpenter, avec des taints spécifiques. Un nodepool sert un usage généraliste ; un autre, les workloads à utilisation de disque intensive.

Comment éteindre les ressources situées hors de Kubernetes ?

En complément à l'extinction automatique des ressources, e-TF1 privilégie les configurations mono-AZ sur les services data associés (clusters RDS et Elasticache managés) lorsque la haute disponibilité n'est pas nécessaire. Sur S3, il désactive les buckets non critiques pour économiser du stockage. Et lorgne, côté compute, les instances Graviton ("environ 10 % de coût en moins pour 10 % de performance en plus").

Certaines ressources comme les load balancers créés automatiquement et les éléments provisionnés avec des outils comme Crossplane requièrent des stratégies d'extinction spécifiques.
Au-delà d'adapter l'outil d'extinction de nodepools en laissant les outils GitOps assurer la reconstruction, e-TF1 envisage de recourir à la doublette Terraform destroy-apply. Un moyen d'atteindre un niveau d'extinction plus avancé. Mais qui suppose un allongement du temps de reconstruction (plus de 20 minutes pour un cluster EKS ou une instance RDS ; jusqu'à 45 pour un cluster OpenSearch).

* Le déploiement utilise Terraform associé à Terragrunt pour la factorisation de code et Atlantis pour le CI/CD. Les applicatifs sont conteneurisés sur EKS. Une petite partie de l'infra est sur site, notamment un CDN interne pour la diffusion vidéo.

Illustration générée par IA