Problème de résolution DNS intempestive sur K8S

Problème de résolution DNS intempestive sur K8S
Photo by Prateek Katyal / Unsplash

Petite note vite fait pour ne pas oublier ce problème un peu chiant. Vous avez un cluster K8S qui fonctionne et vous vous apercevez que lorsqu'il essaie de sortir et résoudre un host tel que blog.claneys.net, le pod vous retourne une erreur de certificat SSL self-signed.

Mon serveur utilisant Traefik en tant que reverse proxy L7, L4 et LoadBalancer, même si je n'utilise pour l'instant pas cette fonctionnalité, et ce certificat retourné était le sien. Stupéfaction, Incompréhension, comment se retrouve t'il à résoudre sur lui-même une requête externe ? Je me lance donc dans le debug de ce problème en utilisant un pod à cet usage, confer la doc. Je définis le petit manifest de mon pod de debug puis lance un petit shell pour inspecter ce problème :

$ cat > dnsutils.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: dnsutils
spec:
  containers:
  - name: dnsutils
    image: k8s.gcr.io/e2e-test-images/jessie-dnsutils:1.3
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
  restartPolicy: Always
EOF
$ kubectl apply -f dnsutils.yaml
$ kubectl exec -it dnsutils -- bash
ping blog.claneys.net
PING blog.claneys.net.uruk.home (192.168.1.11) 56(84) bytes of data.
64 bytes from traefik.traefik.svc.cluster.local (192.168.1.11): icmp_seq=1 ttl=63 time=0.142 ms

Voilà, on voit un truc étrange, c'est qu'il me rajouter mon domaine perso à la fin du FQDN. Et cela résout avec l'adresse interne à mon réseau, sur laquelle j'avais mis une wildcard dernièrement. Ok, pour l'explication, c'est bon, je supprime la wildcard et tout rentre dans l'ordre.

Conclusion: De ce que j'ai compris donc, mon domaine perso est dans ma config resolv.conf de mes noeuds K8S ainsi que mon serveur DNS. Ce domaine est ajouté aux domaines internes au cluster. Le problème étant qu'à cause de la wildcard sur ce domaine et bien la résolution fonctionne tout le temps. Si cela n'avait pas fonctionné, il aurait itéré sur les autres et finalement tenté sans ajouter de domaine en suffixe. S'il ajoute ce domaine en suffixe, c'est à cause la configuration des ndots par défaut DNS pour les Pods pour la Policy par défaut et ClusterFirst. Les ndots, nouvelle découverte, spécifie au bout de combien de "point", il considère l'hôte à résoudre dans une requête comme complet. Confer man resolv.conf. Exemple! si ndots vaut 2 alors blog.claneys.net est résolu tel quel avant de tenter avec les domaines de recherche spécifiés dans les search domaines. Et par défaut, ce ndots est fixé à 5 dans K8S. Et cela car il utilise des noms internes plutôt long du type <pod_name>.<namespace>.<pod>.<domain> (ie. dnsutils.default.pod.cluster.local). Confer la doc.

Donc à moins de terminer toutes mes requêtes par un point final, qui selon la norme DNS, nouvelle découverte, spécifie explicitement que c'est un FQDN et qu'il n'y a pas besoin de chercher ailleurs. Ou de régler ce ndots au niveau du cluster ou de chaque pod, ce que je n'ai pas trouvé et que pas mal de monde cherche par ailleurs, à tort ou à raison. Il suffit de supprimer cette wildcard dns sur ce domaine, ou alors de l'enlever des search domaines.