Tengo una instancia de Kubernetes administrada en Azure. Estoy muy seguro de que el DNS central está funcionando y los pods de DNS están en buen estado.
tengo un par de servicios
Servicio de interfaz de usuario con un pod: imagen [nginx-alpine] que tiene los archivos de interfaz de usuario estáticos.
backend-service, con un pod: Imagen [ubuntu:20.04] que tiene el código nodejs.
No puedo resolver los nombres de los servicios DNS internos como frontend-service O frontend-service.default.svc.cluster.local desde los pods del backend, pero nslookup, host, dig de los nombres DNS internos se resuelven en la dirección correcta. Los pods de backend también pueden resolver los nombres de DNS externos como google.com.
curl http://frontend-service
curl: (6) Could not resolve host: frontend-service
curl http://frontend-service.default.svc.cluster.local
curl: (6) Could not resolve host: frontend-service.default.svc.cluster.local
wget frontend-service
--2020-08-31 23:36:43-- http://frontend-service
Resolving frontend-service (frontend-service)... failed: Name or service not known.
wget: unable to resolve host address 'frontend-service'
/etc/nsswitch.conf shows the below :
passwd: files
group: files
shadow: files
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
Todo funciona bien al intentar resolver el nombre DNS interno del servicio backend desde los pods del servicio frontend.
Después de depurar un poco y mirar los registros de coredns y strace, veo que no se realiza ninguna llamada a los pods de coredns mientras hago un curl, pero puedo ver la entrada mientras hago una búsqueda.
Yo también. Verificó que /etc/resolv.conf tenga la configuración correcta.
nameserver 10.3.0.10
search default.svc.cluster.local svc.cluster.local cluster.local tdghymxumodutbxfnz5m2elcog.bx.internal.cloudapp.net
options ndots:5
strace no muestra ninguna entrada para buscar /etc/resolv.conf, por lo que curl no busca /etc/resolv.conf.
Editar 1
From the backend service pod :
dig frontend-service [It is able to resolve to the correct name server.]
; <<>> DiG 9.16.1-Ubuntu <<>> frontend-service
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13441
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; OPT=65436: 87 a1 ee 81 04 d8 5a 49 be 0e c4 ed 1d d8 27 41 ("......ZI......'A")
;; QUESTION SECTION:
;frontend-service. IN A
;; AUTHORITY SECTION:
. 30 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020083101 1800 900 604800 86400
;; Query time: 20 msec
;; SERVER: 10.3.0.10#53(10.3.0.10)
;; WHEN: Tue Sep 01 10:48:00 IST 2020
;; MSG SIZE rcvd: 142
nslookup frontend-service
Server: 10.3.0.10
Address: 10.3.0.10#53
Name: frontend-service.default.svc.cluster.local
Address: 10.3.0.30
host frontend-service
frontend-service.default.svc.cluster.local has address 10.3.0.30
Editar 2
Quería probar la implementación paso a paso con la misma imagen de ubuntu:20.04, así que hice lo siguiente.
Enfoque 1
Creé un pod efímero en el clúster como se muestra a continuación.
kubectl run -it --rm test-ubuntu --image=ubuntu:20.04 --restart=Never
Installed curl (7.68) and ran the curl http://frontend-service – This is successful.
Esto me desconcertó, así que eliminé todos mis pasos de compilación de Dockerfile y usé solo los siguientes comandos.
Enfoque 2
archivo acoplable
FROM ubuntu:20.04
EXPOSE 3688
CMD [ "sleep", "infinity" ]
Empujó la imagen a acr y volvió a implementar los pods de backend.
kubectl exec -it <pod-name> /bin/bash
I installed curl (7.68) and ran the curl http://frontend-service – Same error – unable to resolve host.
Esto es sorprendente, la misma imagen con el mismo contenido: al ejecutar kubectl run y al implementar a través de Dockerfile, tiene un comportamiento diferente al ejecutar curl de la misma versión (7.68).
Quería ver el flujo en strace en ambos accesos. Encuentre los enlaces de strace de RUN y EXEC
strace de correr rizo de la vaina efímera. https://pastebin.com/NthHQacW
strace de ejecutar curl desde el pod implementado a través de Dockerfile https://pastebin.com/6LCE5NXu
Después de analizar las rutas de sondeo ejecutando
cat strace-log | grep open
Descubrí que al registro de seguimiento del método 2 le faltan las líneas siguientes.
2844 openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 7
2844 openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC <unfinished...>
2844 <... openat resumed>) = 7
2844 openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 7
2844 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 7
2844 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 7
2844 openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 7
2844 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC <unfinished ...>
2844 <... openat resumed>) = 7
2844 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 7
Entonces, el comando curl dentro del pod no mira ni /etc/resolv.conf NI /etc/nsswitch.conf.
Me sorprende por qué el comportamiento del rizo dentro de dos grupos con la misma imagen y la misma versión de rizo en el mismo grupo es diferente.
Respuesta1
Después de probar muchas opciones, intenté depurar el archivo de configuración de implementación que estaba usando para implementar el pod en el clúster de AKS. Tenía un volumen basado en montaje de host que apuntaba a la ruta "/var/run".
Una vez que eliminé el montaje del host, curl y wget funcionaron como se esperaba.
Después de discutir este comportamiento con el soporte de MS, confirmaron que curl y wget no recurren al archivo /etc/resolv.conf para la resolución DNS si tiene un montaje de host apuntado a la ruta "/var/run" puede deberse a la forma El sondeo de DNS se implementa en curl y wget.