Skip to main content
Sur Kaeyros Analytics, le nom complet d’une ressource Kubernetes est dérivé du couple Application + chart. Par conséquent, renommer une Application ArgoCD ne modifie pas simplement une étiquette : cela recrée l’intégralité des ressources Kubernetes associées (Rollout, Service, Ingress, ServiceAccount). Cette page détaille les effets concrets de cette opération et vous guide dans sa préparation.

​
Ce qui se passe

Lorsque vous modifiez le nom d’une Application dans ArgoCD, la chaîne de déploiement déclenche une séquence irréversible de création et de suppression.
1

Création des nouvelles ressources

ArgoCD détecte le nouveau nom d’Application et provisionne un nouveau Rollout, un nouveau Service, un nouvel Ingress et un nouveau ServiceAccount sous le préfixe fullname mis à jour.
2

Suppression des anciennes ressources

ArgoCD applique la politique de pruning : les anciennes ressources portant l’ancien fullname sont supprimées du cluster. Cette étape est automatique et non configurable depuis l’interface ArgoCD.
3

Changement du nom DNS interne

Le Service ClusterIP porte le nom <application>-<chart>. Son renommage entraîne un changement immédiat du nom DNS interne résolvable dans le cluster : http://<service>.<namespace>.svc.cluster.local.

​
Les deux effets à anticiper

Deux conséquences directes affectent la disponibilité et la connectivité de vos services. Anticipez-les impérativement avant de valider un renommage.
Coupure de service pendant la basculeEntre la suppression de l’ancien Rollout et la mise en route du nouveau, les pods actifs disparaissent momentanément. Le Ingress n’a plus de cible backend valide. Les utilisateurs externes et les jobs internes subissent une interruption de quelques secondes à quelques minutes, selon la vitesse de démarrage des conteneurs et la propagation DNS.
Rupture des appels service-à-service hardcodésSi d’autres applications ou des traitements data-precompute appellent votre service via une URL interne écrite en dur, du type http://<ancien-nom>.<namespace>.svc.cluster.local, ces requêtes échouent immédiatement après le pruning. Le nouveau Service répond désormais sous http://<nouveau-nom>.<namespace>.svc.cluster.local.

​
Migration rollout vers rollout-v2

Le même mécanisme s’applique lorsque vous migrez un déploiement du chart rollout vers rollout-v2. Le suffixe du fullname passe de …-rollout à …-rollout-v2, ce qui déclenche la recréation complète de la stack.
Traitez une migration rollout → rollout-v2 comme un renommage à part entière. Toutes les ressources sont recréées, le nom DNS interne change et une coupure est inévitable. Planifiez cette opération en dehors des heures de pointe de vos utilisateurs finaux (Tenants).

​
Procédure recommandée

Suivez cette séquence pour minimiser l’impact d’un renommage ou d’une migration de chart.
1

Inventorier les appelants

Parcourez les dépôts de code, les fichiers values des autres Applications et les configurations de jobs data-precompute pour identifier toutes les occurrences de l’ancien nom DNS interne. Recherchez aussi les références dans les variables d’environnement et les secrets Kubernetes.
2

Choisir une fenêtre de maintenance

Sélectionnez un créneau hors heures de pointe, de préférence en coordination avec les équipes produit concernées (Distribution, Santé, RH, etc.). Informez les stakeholders via le canal habituel avant de commencer.
3

Préparer un PR unique

Créez une pull request regroupant :
  • le nouveau fichier d’Application dans apps/
  • la mise à jour de tous les appelants (code source et fichiers de valeurs Helm)
  • la suppression programmée de l’ancien fichier d’Application
Évitez de scinder ces modifications en plusieurs PR. Une synchronisation partielle laisse le cluster dans un état incohérent.
4

Merger et surveiller ArgoCD

Après fusion, surveillez la synchronisation dans l’interface ArgoCD (serveur argo-production). Vérifiez que le nouveau Rollout atteint l’état Healthy et que les pods sont prêts (Ready) avant de considérer l’opération comme terminée.
5

Vérifier le nettoyage

Confirmez dans ArgoCD que l’ancien Ingress, l’ancien Service et l’ancien Rollout ont bien été supprimés (prune effectuée). Un résidu manuel peut provoquer des conflits de routage Traefik ou des erreurs de certificat TLS.

​
Ce qu’il faut ne PAS faire

Évitez ces erreurs courantes :
  • Renommer sans prévenir : ne modifiez jamais le nom d’une Application sans communication préalable aux équipes et sans fenêtre de maintenance définie.
  • Ignorer les appels internes hardcodés : une URL en dur du type http://<service>.<namespace>.svc.cluster.local dans un autre microservice ou un traitement planifié provoque une panne en cascade invisible depuis ArgoCD.
  • Merger le renommage avant la mise à jour des appelants : si le nouveau Service existe mais que les consommateurs pointent encore vers l’ancien nom, vous créez une partition réseau partielle.
  • Oublier de vérifier les certificats TLS : le nouvel Ingress génère une nouvelle demande cert-manager. Surveillez l’apparition éventuelle de pods cm-acme-http-solver-* en attente.
Si vous avez un doute sur la portée d’un renommage ou si vous souhaitez une revue de votre PR, contactez l’équipe DevOps à devops@kaeyros-analytics.com.