Container Service for Kubernetes:DNS FAQ

Pourquoi ne puis-je pas exécuter de commande dans un Pod CoreDNS ?

L'image du conteneur CoreDNS est construite sur scratch, qui ne contient aucun shell. L'exécution de kubectl -n kube-system exec -it {coredns-pod-name} bash échoue car l'image ne dispose d'aucun shell.

Pour inspecter l'environnement réseau d'un Pod CoreDNS, utilisez nsenter à la place. Consultez la section Vérifier la connectivité réseau d'un Pod CoreDNS pour obtenir des instructions. Pour afficher les journaux CoreDNS, activez la fonctionnalité d'analyse et de surveillance des journaux CoreDNS. Consultez la section Analyser et surveiller les journaux CoreDNS.

Pourquoi CoreDNS utilise-t-il une API obsolète ?

Lors d'une vérification préalable à la mise à niveau d'un cluster, un client dont l'agent utilisateur est coredns accède à l'API obsolète discovery.k8s.io/v1beta1 via /apis/discovery.k8s.io/v1beta1.

Cela se produit pour l'une des deux raisons suivantes :

• Version CoreDNS obsolète : La version installée ne prend pas en charge discovery.k8s.io/v1 et revient donc à v1beta1.

• Sélection d'API périmée : CoreDNS a été démarré sur une ancienne version de Kubernetes (par exemple, v1.20) et a verrouillé l'utilisation de v1beta1 au démarrage. Après une mise à niveau du cluster ayant rendu cette API obsolète, CoreDNS a continué à l'utiliser.

Dans les deux cas, commencez par mettre à niveau CoreDNS. Si aucune mise à niveau n'est disponible, redémarrez-le pour forcer une nouvelle sélection d'API.

Pour mettre à niveau ou redémarrer CoreDNS :

1. Connectez-vous à la console ACK et cliquez sur Clusters dans le volet de navigation de gauche.

2. Cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Add-ons.

3. Sur la page Add-ons, mettez à niveau le composant CoreDNS. Si la page indique qu'une mise à niveau n'est pas possible, passez à l'étape 4. Pour plus d'informations, consultez la section Gérer les composants.

4. Redémarrez CoreDNS :

   kubectl -n kube-system rollout restart deployment coredns

   Important

   Des erreurs de résolution DNS peuvent occasionnellement se produire pendant le redémarrage. Consultez la section Atténuer les délais d'attente DNS intermittents causés par des défauts IPVS pour réduire l'impact.

5. Vérifiez que les Pods CoreDNS sont en cours d'exécution :

   kubectl -n kube-system get pod -l k8s-app=kube-dns

   La sortie attendue affiche les Pods nouvellement recréés avec l'état Running :

   NAME                       READY   STATUS    RESTARTS   AGE
   coredns-xxxxxxxxxx-xxxxx   1/1     Running   0          30s
   coredns-xxxxxxxxxx-yyyyy   1/1     Running   0          28s

   Une fois que les deux Pods sont à l'état Running, vous pouvez ignorer en toute sécurité les enregistrements d'appels d'API obsolètes sur la page de vérification préalable et procéder à la mise à niveau du cluster.

Erreur dans les journaux CoreDNS : dns: buffer size too small

CoreDNS définit la taille par défaut du tampon UDP (bufsize) à 1232 octets. Lorsqu'une réponse DNS dépasse cette limite, la résolution échoue et l'erreur dns: buffer size too small apparaît dans les journaux. Cela affecte généralement les requêtes DNS qui renvoient des réponses volumineuses. Pour plus de contexte, consultez cette issue GitHub.

Mettez à niveau CoreDNS vers la version v1.7.1 ou ultérieure, ce qui résout automatiquement le problème. Pour les versions antérieures à la v1.7.1, définissez manuellement bufsize dans la ConfigMap CoreDNS :

kubectl edit cm -n kube-system coredns

Ajoutez bufsize avec une valeur comprise dans la plage \[512, 4096\] (bornes incluses) :

. {
    bufsize 1220
    log
}

Pour plus d'informations, consultez la documentation du plugin bufsize de CoreDNS.

Pourquoi les requêtes renvoient-elles de manière incohérente NXDOMAIN et NOERROR après la création d'un Service ?

CoreDNS s'exécute sous forme de plusieurs réplicas de Pod. Immédiatement après la création d'un nouveau Service, un Pod peut ne pas avoir encore récupéré les dernières informations du Service depuis le serveur API, tandis qu'un autre Pod les possède déjà. Les requêtes acheminées vers le Pod non synchronisé renvoient NXDOMAIN ; les requêtes acheminées vers le Pod mis à jour renvoient NOERROR. L'incohérence se résout d'elle-même une fois que tous les Pods CoreDNS sont synchronisés avec le serveur API. Aucune action manuelle n'est nécessaire.

Résolution DNS sur les nœuds Windows

Les Pods sur les nœuds Windows présentent plusieurs comportements DNS différents de ceux de Linux :

• **ClusterFirstWithHostNet n'est pas pris en charge.** Windows ne prend pas en charge cette politique DNS pour les Pods.

• **Tous les noms contenant un point (.) sont traités comme des noms de domaine complets (FQDN).** Windows n'ajoute pas de suffixes de recherche DNS pour les noms contenant un point, contrairement à Linux qui parcourt une liste de suffixes de recherche.

• Un seul suffixe DNS est utilisé par Pod. Le suffixe est dérivé du namespace du Pod. Par exemple, un Pod dans le namespace default reçoit le suffixe default.svc.cluster.local. Cela signifie que kubernetes.default.svc.cluster.local et kubernetes se résolvent correctement, mais les noms partiellement qualifiés tels que kubernetes.default ou kubernetes.default.svc ne se résolvent pas.

• **Utilisez Resolve-DnsName pour les requêtes DNS.** Windows prend en charge plusieurs résolveurs DNS avec de légères différences de comportement. L'applet de commande PowerShell Resolve-DnsName donne les résultats les plus cohérents.

Pour plus d'informations, consultez la section DNS for Services and Pods.