Introduction
Le laboratoire précédent a montré comment un Service fournit aux Pods un point d'entrée stable au sein du cluster. Kubernetes attribue également un nom DNS à chaque Service. Un Pod situé dans le même namespace peut généralement utiliser le nom court du Service, mais un Pod situé dans un namespace différent nécessite souvent un nom plus long incluant le namespace du Service.
Dans ce laboratoire, vous allez créer un service web, tester l'accès DNS au sein d'un même namespace, reproduire un échec de résolution de nom court entre deux namespaces, corriger la requête en utilisant le FQDN (nom de domaine complet) du Service, et inspecter les objets qui vous aideront à diagnostiquer si un problème DNS provient réellement du Service, des endpoints ou de CoreDNS.
Préparer un service web
Dans cette étape, vous allez créer le Service cible que les tests DNS ultérieurs devront résoudre. La charge de travail est volontairement simple, car le sujet principal est le nommage DNS et non le déploiement d'applications.
Commencez dans /home/labex/project :
mkdir -p /home/labex/project
cd /home/labex/project
Vérifiez que le serveur API Kubernetes est accessible. Si la machine virtuelle vient de démarrer et que le nœud n'est pas encore prêt, attendez quelques secondes et relancez la commande.
kubectl get nodes --request-timeout=5s
La sortie attendue inclut :
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Attendez que le réseau du cluster soit prêt. Ce laboratoire envoie du trafic entre les Pods, le réseau des Pods doit donc être opérationnel avant que les tests d'accès DNS ne soient pertinents.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Sortie attendue :
pod/calico-node-... condition met
Créez un namespace nommé ckad-prep-dns et définissez-le comme namespace par défaut :
kubectl create namespace ckad-prep-dns
kubectl config set-context --current --namespace=ckad-prep-dns
Créez un déploiement et exposez-le avec un Service nommé dns-web :
kubectl create deployment dns-web --image=nginx:1.25 --port=80
kubectl expose deployment dns-web --port=80 --target-port=80
Attendez que le Pod web soit disponible :
kubectl rollout status deployment/dns-web --timeout=120s
Inspectez le Service et son EndpointSlice. Le Service est la cible DNS stable ; l'EndpointSlice affiche les adresses IP actuelles des Pods backend sélectionnés par le Service.
kubectl get service dns-web
kubectl get endpointslice -l kubernetes.io/service-name=dns-web
La sortie attendue inclut :
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dns-web ClusterIP ... <none> 80/TCP ...
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
dns-web-... IPv4 80 ... ...
Résoudre le Service depuis le même namespace
Dans cette étape, vous allez créer un Pod client dans le même namespace que le Service et utiliser le nom court du Service. Il s'agit du cas le plus simple pour le DNS de Service.
Créez un Pod client qui reste actif :
kubectl run same-ns-client --image=busybox:1.36 --restart=Never --command -- sleep 3600
Attendez que le Pod client soit prêt :
kubectl wait --for=condition=Ready pod/same-ns-client --timeout=120s
Sortie attendue :
pod/same-ns-client condition met
Utilisez nslookup à l'intérieur du Pod client pour résoudre le nom court du Service dns-web. Le nom court fonctionne ici car le Pod client et le Service se trouvent dans le même namespace. La commande nslookup de BusyBox peut afficher des lignes NXDOMAIN supplémentaires pour d'autres suffixes de recherche et renvoyer un code de sortie non nul après avoir affiché l'adresse correcte ; c'est pourquoi la commande utilise || true et vous devez vous concentrer sur les lignes Name et Address.
kubectl exec same-ns-client -- sh -c 'nslookup dns-web || true'
La sortie attendue inclut :
Name: dns-web.ckad-prep-dns.svc.cluster.local
Address: ...
Envoyez maintenant une requête HTTP vers le nom court du Service :
kubectl exec same-ns-client -- wget -qO- http://dns-web | grep '<title>Welcome to nginx'
Sortie attendue :
<title>Welcome to nginx!</title>
Diagnostiquer un échec de nom court entre namespaces
Dans cette étape, vous allez créer un Pod client dans un namespace différent et reproduire une erreur DNS courante. Un nom de Service court est résolu par rapport au namespace du Pod client en priorité ; par conséquent, dns-web ne trouvera pas le Service dans ckad-prep-dns lorsque le client s'exécute dans un autre namespace.
Créez un second namespace et un Pod client à l'intérieur :
kubectl create namespace ckad-prep-dns-client
kubectl run remote-client --namespace ckad-prep-dns-client --image=busybox:1.36 --restart=Never --command -- sleep 3600
kubectl wait --namespace ckad-prep-dns-client --for=condition=Ready pod/remote-client --timeout=120s
La sortie attendue inclut :
namespace/ckad-prep-dns-client created
pod/remote-client created
pod/remote-client condition met
Essayez de résoudre le nom court depuis le namespace distant. Le || true permet de poursuivre le laboratoire car cet échec est attendu.
kubectl exec --namespace ckad-prep-dns-client remote-client -- nslookup dns-web || true
La sortie attendue inclut une erreur telle que :
** server can't find dns-web...
Résolvez maintenant le nom de Service complet (FQDN). Le format complet est <service>.<namespace>.svc.cluster.local.
kubectl exec --namespace ckad-prep-dns-client remote-client -- nslookup dns-web.ckad-prep-dns.svc.cluster.local
La sortie attendue inclut :
Name: dns-web.ckad-prep-dns.svc.cluster.local
Address 1: ...
Utilisez le même nom complet pour l'accès HTTP :
kubectl exec --namespace ckad-prep-dns-client remote-client -- wget -qO- http://dns-web.ckad-prep-dns.svc.cluster.local | grep '<title>Welcome to nginx'
Sortie attendue :
<title>Welcome to nginx!</title>
Vérifier le chemin de dépannage DNS
Dans cette étape, vous allez inspecter les objets qui aident à distinguer un problème de nommage DNS d'un problème de Service ou de backend. Un ordre de dépannage pratique est le suivant : confirmer le nom et le namespace du Service, confirmer qu'il possède des endpoints, puis confirmer que CoreDNS est disponible.
Tout d'abord, inspectez le Service dans son namespace réel :
kubectl get service dns-web --namespace ckad-prep-dns
La sortie attendue inclut :
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dns-web ClusterIP ... <none> 80/TCP ...
Ensuite, inspectez l'EndpointSlice. Si le DNS se résout mais que le trafic HTTP échoue, l'absence d'endpoints est une cause fréquente.
kubectl get endpointslice --namespace ckad-prep-dns -l kubernetes.io/service-name=dns-web
La sortie attendue inclut au moins un endpoint :
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
dns-web-... IPv4 80 ... ...
Vérifiez les Pods CoreDNS. CoreDNS est le service DNS du cluster qui répond aux requêtes DNS des Pods.
kubectl get pods --namespace kube-system -l k8s-app=kube-dns
La sortie attendue inclut les Pods CoreDNS en état Running :
NAME READY STATUS RESTARTS AGE
coredns-... 1/1 Running ... ...
Enfin, inspectez la configuration de recherche DNS du client distant. La ligne search explique pourquoi le nom court dns-web a été recherché dans le namespace du client avant que vous n'utilisiez le nom complet.
kubectl exec --namespace ckad-prep-dns-client remote-client -- cat /etc/resolv.conf
La sortie attendue inclut un chemin de recherche similaire à :
search ckad-prep-dns-client.svc.cluster.local svc.cluster.local cluster.local
nameserver ...
Résumé
Vous vous êtes exercé à diagnostiquer l'accès DNS aux services Kubernetes à travers une séquence adaptée aux débutants. Vous avez créé un Service, confirmé qu'un client situé dans le même namespace peut utiliser le nom court du Service, reproduit un échec de nom court entre namespaces, corrigé ce problème avec le nom DNS complet du Service, et inspecté le Service, l'EndpointSlice, les Pods CoreDNS ainsi que le chemin de recherche DNS du client pour comprendre l'origine des problèmes d'accès DNS.
