Echo m'a eu, et a cassé ma production

Une drôle d’histoire qui m’est arrivée en ce 3 juillet 2025, une application récalcitrante à démarrer.

Depuis plusieurs jours, je travaillais sur le déploiement d’une application dans un cluster Kubernetes, sans succès. Pour un peu de contexte, j’essayais de déployer une application et sa base PostgreSQL, en créant moi-même les secrets via un manifest kind: Secret.

Habituellement, je récupère une charte Helm, j’étudie et récupère les images, puis je crée un modèle pour les valeurs que je personnalise ensuite. Les valeurs dans les chartes Helm sont souvent en clair et via ArgoCD c’est encore plus simple. L’application elle-même n’a pas d’importance particulière ni d’impact sur le problème rencontré. Cette application utilise une base de données PostgreSQL, instanciée par l’opérateur CNPG. L’opération est rodée puisque ce n’est pas la première fois que nous utilisons cet opérateur, sans parler de tous les déploiements divers et variés déjà effectués (et fonctionnels).

Pour créer une base PostgreSQL avec l’opérateur CNPG, il faut créer un secret, comportant les identifiants de connexion à la base. Je saisis généralement une commande de ce type dans un terminal : echo 'monUtilisateur' | base64 -w0⁣, et ce, pour toutes les variables du même genre. Suite à cette commande, en sortie exit 0, un résultat est obtenu (bW9uVXRpbGlzYXRldXIK), que je saisis au bon endroit avant de continuer les modifications. Quand tout est prêt, j’applique les manifests via ArgoCD ou manuellement avec kubectl. Aucune erreur n’apparaît, le déploiement fonctionne, et les pods, secrets, configmaps et autres ressources sont créés sans problème apparent. Tout est vert, ça marche.

Cependant, par acquit de conscience, je consulte les logs du pod du serveur PostgreSQL. Bien que le pod soit “running” et “healthy” ✅, impossible de me connecter à la base. Les logs sont clairs : “[…] unable to connect to the database with username ‘username: monUtilisateur\n’, waiting for username to be ‘username: monUtilisateur’ […]”.

Perplexe, je décode le secret, le recrée, et redéploie, mais toujours la même erreur. Naturellement, je m’impatiente et en parle à mes collègues, leur demandant si je deviens fou (devinez la réponse). Nous commençons à suspecter l’opérateur CNPG (qui a été mis à jour récemment) et fouillons le web à la recherche d’une issue ou d’un problème connu, sans résultat.

Soudain, un espoir surgit : notre doyen au bureau pose la question suivante : “Avez-vous ajouté l’argument -ne à echo, pour empêcher l’ajout d’un retour-chariot ?”

La lumière se fait. En saisissant la même commande echo avec l’argument -ne (echo -ne 'monUtilisateur' |base64 -w0), le résultat obtenu (bW9uVXRpbGlzYXRldXI=) est différent de celui que nous avions auparavant, et cette fois pas de retour-charriot (toujours invisible quand on décode). Le secret et le pod sont recréés, tout démarre et cette fois, dans les logs, tout est enfin fonctionnel pour de vrai.

Ce qui est trompeur, c’est que le décodage des secrets avec la commande kubectl, via k9s ou encore dans Rancher, nous affichait toujours le bon secret, sans montrer le retour-chariot. La seule fois où nous l’avons vu était dans les logs du pod du serveur PostgreSQL.

Comme quoi, même en étant loin des technologies d’aujourd’hui, il est toujours bon d’apprendre des plus expérimentés avec des outils d’une autre époque… 🤗

Morale :

• L’importance de bien maîtriser les outils Unix de base, même dans des contextes technologiques avancés comme Kubernetes.
• Que les erreurs les plus subtiles viennent parfois de détails “hors radar”, comme un simple caractère caché.
• Que la collaboration et l’écoute des membres expérimentés restent des atouts majeurs pour résoudre des incidents qui peuvent devenir complexes et interrompre une production.