George Sims explique, dans un article publié sur le blog de la CNCF le 3 septembre 2026, l’expérience de migration d’un service d’authentification essentiel au sein d’un cluster Kubernetes, depuis le namespace default vers un espace de noms dédié, sans interrompre le service. Le service, que l’auteur a nommé auth-svc, était utilisé en permanence par des dizaines de services et était responsable de l’authentification des utilisateurs dans toute une zone du cluster ; son interruption aurait donc empêché les connexions dans cette zone.
Le problème ne consistait pas simplement à déplacer un objet Deployment vers un autre espace de noms. Les consommateurs à l’intérieur du cluster accédaient au service via le nom auth-svc.default.svc.cluster.local, tandis que les utilisateurs externes au cluster y accédaient via un Ingress distinct. En outre, les services consommateurs appartenaient à des équipes différentes et fonctionnaient selon des calendriers de publication disparates, ce qui rendait impraticable la modification simultanée de toutes les références.
Pourquoi le simple déplacement du service et la mise à jour des références ne suffisent-ils pas ?
L’auteur indique que le pipeline de déploiement ne prenait en charge le déploiement du service que dans un seul espace de noms et n’était pas conçu pour exécuter deux versions simultanément. Modifier la logique du pipeline partagé aurait affecté d’autres équipes, ce que l’équipe souhaitait éviter. De plus, une politique fondée sur OPA interdisait la présence simultanée de règles Ingress identiques dans deux espaces de noms, afin d’empêcher un routage ambigu résultant d’une migration incomplète.
C’est pourquoi la solution ne reposait pas sur l’obligation faite à chaque consommateur de connaître la nouvelle adresse, mais sur le maintien temporaire de l’ancienne adresse et sa redirection vers le service déplacé.
ExternalName comme adresse de redirection
Après le déploiement de la version réelle du service dans le nouvel espace de noms authentication, l’objet Service existant dans default a été transformé en service de type ExternalName. Son nom pointait désormais vers auth-svc.authentication.svc.cluster.local, de sorte que les services utilisant l’ancienne adresse continuent d’accéder à la nouvelle version sans modification immédiate de leur code ni nouveau déploiement.
L’auteur compare ce mécanisme à un service de réexpédition du courrier : il n’est pas nécessaire de contacter chaque personne qui possède l’ancienne adresse ; les demandes sont redirigées vers le nouvel emplacement jusqu’à ce que les entités consommatrices mettent progressivement leurs adresses à jour. Toutefois, cette méthode dépend du fait que les consommateurs utilisent un nom DNS ; si certains systèmes se connectent à une adresse IP fixe ou contournent le DNS, la situation sera différente et la migration nécessitera un autre traitement.
Avant d’arrêter l’ancienne version, l’équipe a surveillé les métriques afin de vérifier que les requêtes arrivant à l’ancienne adresse atteignaient effectivement le nouveau Deployment, sans échec ni boucle de redirection. Après cette vérification, le nombre d’anciennes répliques a été réduit à zéro au lieu de les supprimer directement. Cela a permis de disposer d’une voie de retour rapide en redémarrant les anciennes répliques en cas de problème, tout en reportant leur suppression définitive à une date ultérieure.
Gestion du conflit Ingress
Le chemin d’accès externe nécessitait un Ingress dans le nouvel espace de noms avant la suppression de l’ancien Ingress. Cependant, la politique OPA empêchait la création simultanée des deux règles identiques. L’équipe a donc utilisé une exception temporaire et ciblée au lieu de désactiver complètement la politique : une étiquette a été ajoutée à l’espace de noms authentication afin d’autoriser le contournement de la vérification des doublons Ingress pendant la migration, à l’aide de la clé policy.example.com/allow-duplicate-ingress: "true".
Pendant la courte fenêtre de chevauchement, le nouvel Ingress a été exécuté parallèlement à l’ancien, puis l’équipe a vérifié que le trafic atteignait le nouveau Deployment. L’ancien Ingress a ensuite été supprimé, et l’exception temporaire a été laissée expirer au lieu d’être considérée comme un paramètre permanent.
Qu’est-ce qui change en pratique ?
Cette expérience montre que la migration d’un service sensible ne nécessite pas forcément une coordination simultanée avec tous les consommateurs, lorsqu’il existe une frontière claire reposant sur le DNS. Cela ne supprime toutefois pas la nécessité d’effectuer des tests par étapes, d’assurer une surveillance précise et de disposer d’un plan de retour en arrière. L’équipe a d’abord exécuté l’opération dans l’environnement de développement, puis dans l’environnement de test, et a attendu deux semaines après la réussite de l’étape de test avant de l’effectuer en production.
La leçon plus générale est que l’accumulation de services dans le namespace default peut rester sans conséquence jusqu’à ce que le service ait besoin de politiques ou de ressources limitées à un espace de noms dédié. À ce moment-là, la dette opérationnelle devient un problème concret. ExternalName offre une voie pratique aux services qui dépendent du DNS, mais ce n’est pas une solution universelle pour les systèmes qui utilisent des adresses fixes ; de même, la fenêtre de chevauchement et l’exception de sécurité doivent être intentionnelles et temporaires, et s’accompagner de mesures clairement définies.