Le pod Kubernetes /etc/resolv.conf a le mauvais serveur de noms

J'ai mis en place un cluster de 4 nœuds à la maison avec lequel je joue, et j'ai rencontré un problème lorsque j'ai commencé à essayer de faire des communications pod-à-pod. J'ai utilisé Kubespray pour installer les nœuds (1 "serveur/contrôleur" et 3 "nœuds").

Le problème est que je ne peux pas résoudre les services par leur nom, seulement par IP. Par exemple, j'ai utilisé Helm pour lancer Jenkins dans l'espace de noms par défaut avec le nom de service "jenkins", mais si j'essaie de faire un ping sur "jenkins" ou "jenkins.default", cela ne résout pas. L'exécution de dig jenkins ou dig jenkins.default dans un pod dnsutils produit :

/ # dig jenkins.default

; <<>> DiG 9.11.6-P1 <<>> jenkins.default
;; options globales: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 8927
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; ATTENTION: récursion demandée mais non disponible

;; SECTION QUESTION:
;jenkins.default.       IN  A

;; Temps de requête: 0 msec
;; SERVEUR: 169.254.25.10#53(169.254.25.10)
;; QUAND: Sam 28 Mar 14:51:26 UTC 2020
;; TAILLE DU MESSAGE rcvd: 72

En vérifiant le fichier /etc/resolv.conf dans le pod dnsutils, j'ai remarqué qu'une adresse IP étrange était définie pour le nameserver : 169.254.25.10. Après avoir regardé tous les pods, il semble qu'ils aient tous la même configuration, mais le service coredns est défini sur 10.233.0.3. En fait, toutes les adresses IP commencent par 10. quelque chose. Changer manuellement le /etc/resolv.conf du pod dnsutils pour utiliser le 10.233.0.3 en tant que nameserver semblait corriger le problème pour ce pod, mais comment puis-je le corriger pour TOUS les pods ? Et d'où vient cette adresse IP 169.254.25.10 de toute façon ? Mon serveur DNS réseau réel est 10.0.0.5, et je n'ai pas d'adresses IP 169.254 dans mon réseau interne, autant que je sache.