Emmanuel Smith
← Blog

2 min de lecture

Quand le DNS se coupe l’herbe sous le pied

Une modification anodine — changer la source d’une image — a coupé toute la résolution DNS du homelab. Autopsie d’une dépendance circulaire.

#kubernetes#dns#gitops#incident

Le contexte

Pour ne plus dépendre de Docker Hub (limites de téléchargement, disponibilité), j’ai mis en place un miroir d’images dans le registre de ma forge Forgejo, et j’ai commencé à faire pointer les déploiements du cluster vers ce miroir.

Parmi eux : AdGuard Home, qui fait office de serveur DNS pour tout le réseau… y compris pour le nœud Kubernetes lui-même.

Dans le même commit, j’ai passé sa stratégie de déploiement à Recreate : l’ancien pod est arrêté avant que le nouveau démarre.

Ce qui s’est passé

  1. ArgoCD applique le changement. L’ancien pod AdGuard est supprimé.
  2. Plus de DNS sur le réseau.
  3. Le nouveau pod doit télécharger son image depuis forgejo.<mon-domaine>…
  4. … qu’il faut résoudre en DNS, donc via AdGuard, qui n’existe plus.
  5. Même docker.io ne se résout plus : le nœud lui-même utilise AdGuard comme résolveur.

Le serpent se mord la queue. Tout est bloqué.

La réparation

Il a fallu intervenir directement sur le nœud pour ajouter un résolveur public de secours dans /etc/resolv.conf, le temps que containerd puisse de nouveau télécharger des images. Ensuite : retour à l’image d’origine pour AdGuard.

Les leçons

1. Certains composants ne doivent jamais dépendre d’eux-mêmes. Le DNS, la forge qui héberge le registre, l’outil de déploiement et le coffre à secrets sont exclus du miroir : leurs images viennent toujours directement de l’amont.

2. Vérifier comment un chart construit le nom d’image. Le même chantier a produit un deuxième piège, plus sournois : un chart Helm préfixait automatiquement un registre par défaut au dépôt que je lui donnais. Résultat : un nom d’image inexistant, resté invisible pendant des heures parce que le StatefulSet était en mise à jour OnDelete. C’est une alerte de supervision qui l’a révélé.

3. Un DNS unique est un point de défaillance unique. Prochaine étape : un DNS secondaire hors du cluster, sur un Raspberry Pi qui traînait dans un tiroir.

Avant de pointer un composant critique vers une ressource, se demander : qui a besoin de qui pour démarrer ?