Argo CD : Économiser ses deniers sans impacter la performance

Adrien Paysant , Yoan SIMIAND-COSSIN 04 avr. 2025

Introduction

On ne présente plus Argo CD. Pour celles et ceux qui auraient vécu dans une caverne ces dernières années, c’est un outil open-source de déploiement continu (CD) natif pour Kubernetes, conçu selon les principes du GitOps. Argo surveille en continu l'état des applications déployées, compare cet état à la configuration déclarative stockée dans Git et synchronise automatiquement les différences détectées. Il offre une interface utilisateur web, une interface en ligne de commande (CLI), un contrôle d'accès basé sur les rôles (RBAC) et prend en charge l'authentification unique (SSO) avec divers fournisseurs. Ainsi, après avoir expliqué pourquoi il est important d’optimiser les coûts, nous verrons comment les réduire efficacement sans compromettre les performances d’Argo CD à l’échelle.

Cet article est basé sur une conférence donnée par Alexander Matyushentsev, cofondateur du projet Argo et cofondateur et architecte en chef chez Akuity, lors de la KubeCon Europe le 2 avril 2025.

Pourquoi cela peut coûter cher ?

Argo CD : version simple ($)

Dans sa version la plus simple, Argo CD déploie les 7 pods suivants :

application-controller : le contrôleur responsable de la gestion des applications Argo (Custom Resource Definition - CRD)
applicationset-controller : le contrôleur responsable de la gestion des applicationsets Argo (CRD)
dex-server : le composant gérant l’authentification avec des fournisseurs d’identité externes
notifications-controller : le contrôleur responsable de l’envoi des notifications
redis : la base de données en cache utilisée par Argo CD
repo-server : le composant responsable de la synchronisation des repositories
server : l’API et l’application web d’Argo CD

Dans cette configuration, la consommation est limitée, chaque pod ne consommant que très peu de ressources, ce qui ne pèse pas sur la facture.

Cependant, dans un environnement résilient ou possédant de nombreuses applications Argo, ce mode de déploiement simple ne suffit pas. Il existe pour cela un mode de déploiement “haute disponibilité”.

Argo CD : version haute disponibilité ($$)

Ce mode est très ressemblant au mode “simple”, déployant les mêmes composants. La principale différence est sur le nombre de réplicas de chacun de ces composants.

Voici un schéma résumant ce type de déploiement :

Bien que ce mode soit adapté à la haute disponibilité et la gestion de nombreuses applications, les équipes d’Argo CD recommandent de déployer les charges de travail dans des clusters différents, et d’avoir un cluster d'administration spécifique pour les composants d’Argo CD.

Argo CD : version très haute disponibilité et centralisée ($$$)

Ce mode de déploiement permet d’isoler Argo CD dans un cluster différent des charges de travail. Cela permet d’éviter de surcharger l’API server du control plane lors des synchronisations. En effet, à chaque synchronisation d’application, ayant lieu toutes les 3 minutes par défaut, Argo CD requête l’API server afin de récupérer des informations concernant l’application Argo (CRD), ainsi que toutes les ressources déployées par cette dernière. En déployant Argo CD dans un cluster à part, cela permet de répartir la charge sur au moins deux API servers différents, un pour les applications Argo et l’autre pour les charges de travail.

Cette architecture permet également d’améliorer la résilience et la haute disponibilité au niveau cluster.

Les équipes d’Argo CD recommandent ce mode pour des écosystèmes ayant un grand nombre d’applications gérées par Argo, d’une centaine à plusieurs milliers.

Sur le plan financier, ce mode de fonctionnement se paie : pour 800 applications Argo, compter environ $100k mensuels. Il est donc important de pondérer les enjeux de coûts réseaux en fonction de l’architecture du SI.

Les axes d’amélioration identifiés afin d’économiser

Les coûts réseau

Trafic entre zones de disponibilité (AZ) du control plane Kubernetes

Il arrive que des utilisateurs définissent des CRDs d’application Argo très lourds, atteignant la taille maximale de 1 Mo, souvent en intégrant directement des valeurs Helm dans le manifest de l'application. Chaque mise à jour génère des requêtes PATCH fréquentes et un trafic constant lié aux opérations WATCH.

Pour réduire cette charge, il est recommandé de limiter l’historique des révisions à l’aide du paramètre spec.revisionHistoryLimit ainsi que d’externaliser les valeurs Helm dans un fichier values.yaml. Cela vient d’un constat fait par Akuity qu’une part non négligeable de leurs utilisateurs hardcode les valeurs directement dans l'application Argo.

Voici un exemple d'externalisation des valeurs Helm dans une application Argo :

spec:
  source:
    repoURL: https://github.com/argo-is-wonderful/repo
    path: charts/some-awesome-app
    targetRevision: main
    helm:
      valueFiles:
        - values/prd.yaml

De plus, Argo CD stocke l’état détaillé des ressources dans les CRD d’Application, entraînant des mises à jour incessantes. Pour éviter ce trafic inutile, il suffit d’ajouter l’option controller.resource.health.persist: "false" dans le ConfigMap argocd-cmd-params-cm.

Ces optimisations permettent de réduire le trafic inter-AZ et d’améliorer l’efficacité d’Argo CD dans un environnement Kubernetes distribué.

Trafic Redis entre zones de disponibilité

Les contrôleurs Argo CD génèrent un trafic Redis inter-AZ massif en envoyant des milliers de requêtes SET par jour. Ce trafic provient de la mise à jour systématique de l’arbre des ressources des applications stocké dans Redis. Chaque modification d’une ressource entraîne une réécriture complète de l’arbre. Plus le nombre de ressources Kubernetes est élevé, plus ces mises à jour deviennent fréquentes et volumineuses.

Pour limiter cette surcharge, il est recommandé de désactiver la surveillance des ressources orphelines, d’activer le partage de l’arbre des ressources et de configurer la variable d’environnement ARGOCD_APPLICATION_TREE_SHARD_SIZE=50 dans le contrôleur (cette valeur ayant été déterminée de manière empirique, d’après l’ensemble des applications Argo gérées par Akuity). Ces optimisations permettent de réduire jusqu’à 10 fois le trafic réseau lié à Redis.

Trafic du contrôleur via Internet

Les contrôleurs Argo CD génèrent un trafic réseau important en recevant plusieurs gigaoctets de données depuis les clusters Kubernetes managés où se situent les charges de travail. Ce trafic, souvent externe, est jusqu’à dix fois plus coûteux que le trafic inter-AZ, et peut représenter des milliers de dollars par mois.

Ce volume s’explique par le comportement du contrôleur, qui surveille par défaut toutes les ressources déployées dans les clusters Kubernetes. En utilisant l’API de découverte, il identifie l’ensemble des ressources disponibles et exécute des requêtes LIST et WATCH sur chacune d’entre elles, amplifiant ainsi le trafic réseau.

Afin de limiter ces coûts, il est essentiel d’exclure les ressources que vous ne souhaitez pas gérer en configurant le champ “resource.exclusions” dans le ConfigMap “argocd-cm”. Exclure des objets comme les Endpoints ou EndpointSlices permet de réduire considérablement le volume de données échangées et d’optimiser l’utilisation du réseau. Une autre solution, pour les utilisateurs des services AWS, peut être d’utiliser des VPC endpoints entre les différents VPC dans lesquels se trouvent les clusters Kubernetes, afin de profiter de AWS Private Link plutôt que de passer par Internet.

Les coûts liés à la consommation de ressources

Surconsommation au niveau de Redis

Le mode haute disponibilité de Redis dans Argo déploie 5 pods, et l’utilisation de la mémoire augmente avec le temps pour atteindre environ 2 GB de RAM.

Cela est dû au fait que Argo configure Redis avec de la haute réplication de cache qui n’est pas forcément nécessaire : 512 MB par réplica.

Heureusement, ce paramètre est personnalisable via le champ “repl-backlog-size” dans la configuration de Redis. Les équipes d’Argo CD recommandent une valeur de 64 MB ainsi qu’une requête de RAM de 128 MB au niveau du conteneur Redis.

Surconsommation au niveau du repo-server

Le repo-server est très lent pour générer des manifests. Cela s’explique par la configuration par défaut qui permet de traiter une seule requête à la fois par repository Git.

Vous l’aurez deviné, il est possible d’agir sur ce comportement en permettant la génération de manifests en parallèle. Cela peut se faire, pour les charts Helm, au travers de la variable d’environnement ARGOCD_HELM_ALLOW_CONCURRENCY. Il est également possible d’utiliser le paramètre –parallelismlimit.

Les coûts du Control Plane Kubernetes dédié à Argo CD

Serveur Kubernetes dédié

Gérer un cluster Kubernetes spécifique à Argo CD augmente forcément les coûts, que ce soit au niveau ressources ou au niveau maintenance opérationnelle.

Malheureusement, il n’est actuellement pas possible de déployer Argo CD en dehors d’un cluster Kubernetes.

Il peut donc être intéressant de partager un même cluster pour tous les outils plateforme (Argo CD, Crossplane, …) afin de mutualiser les coûts. Une autre solution serait d’utiliser k3s, un outil plus léger, afin de stocker les applications Argo, et Kubernetes (EKS, OpenShift, GKE, …) pour les charges de travail. Cependant, cette deuxième solution présente d’autres problèmes, comme la haute disponibilité et la résilience du cluster de gestion Argo, et n'est donc pas spécialement recommandée.

Conclusion

La conférence donnée par Alexander MATYUSHENTSEV permet d'ouvrir le débat et de raisonner sur des manières cohérentes de rationaliser les coûts d'Argo CD sans en dégrader les performances.

Les cas d'usages présentés par l'architecte d'Akuity sont à l'échelle et soulignent donc les écueils qu'un usage simple et peu intensif d'Argo CD permet d'éviter. Il est important d'en avoir conscience afin d'anticiper et d'éviter les mauvaises surprises.

En appliquant des optimisations telles que la gestion du trafic Redis, la réduction du bruit réseau des contrôleurs et la rationalisation du cluster d'administration, il est possible de réduire considérablement les coûts tout en conservant une plateforme GitOps fiable, performante et évolutive.