Eu tenho uma instância gerenciada do Kubernetes no Azure. Tenho certeza de que o DNS principal está funcionando e os pods do DNS estão saudáveis.
Eu tenho alguns serviços
frontend-service com um pod - Imagem [nginx-alpine] que contém os arquivos estáticos do frontend.
backend-service , com um pod - Imagem [ubuntu:20.04] que contém o código nodejs.
Não consigo resolver os nomes de serviço DNS internos, como frontend-service OR frontend-service.default.svc.cluster.local dos pods do back-end, mas nslookup , Host , dig dos nomes DNS internos resolvem para o endereço correto. Os pods de back-end também são capazes de resolver nomes 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
Tudo funciona bem ao tentar resolver o nome DNS interno do serviço de back-end dos pods do serviço de front-end.
Depois de alguma depuração e observação dos logs de coredns e strace , vejo que nenhuma chamada está acontecendo para os pods coredns ao fazer um curl , mas posso ver a entrada ao fazer um nslook up.
Eu também. verifiquei se o /etc/resolv.conf está com a configuração correta.
nameserver 10.3.0.10
search default.svc.cluster.local svc.cluster.local cluster.local tdghymxumodutbxfnz5m2elcog.bx.internal.cloudapp.net
options ndots:5
strace não mostra nenhuma entrada para procurar /etc/resolv.conf , então curl não está verificando /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
Eu queria testar a implantação passo a passo com a mesma imagem ubuntu:20.04, então fiz o seguinte.
Abordagem 1
Criei um pod efêmero no cluster conforme abaixo.
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.
Isso me intrigou, então removi todas as etapas de construção do Dockerfile e usei apenas os comandos abaixo.
Abordagem 2
Dockerfile
FROM ubuntu:20.04
EXPOSE 3688
CMD [ "sleep", "infinity" ]
Empurrou a imagem para acr e implantou os pods de back-end novamente.
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.
Isso é surpreendente, a mesma imagem com o mesmo conteúdo – executada por kubectl run e implantada por meio de Dockerfile, tem comportamento diferente ao executar curl da mesma versão (7.68).
Eu queria ver o fluxo em ambas as abordagens. Por favor, encontre os links strace de RUN e EXEC
strace de executar curl do pod efêmero. https://pastebin.com/NthHQacW
strace executando curl no pod implantado por meio do Dockerfile https://pastebin.com/6LCE5NXu
Depois de analisar os caminhos de sondagem executando
cat strace-log | grep open
Descobri que faltam as linhas abaixo no log de strace da abordagem 2.
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
Portanto, o comando curl dentro do pod não está olhando para /etc/resolv.conf OU /etc/nsswitch.conf.
Estou intrigado por que o comportamento do curl em dois pods com a mesma imagem e a mesma versão do curl no mesmo cluster é diferente.
Responder1
Depois de tentar várias opções, tentei depurar meu arquivo de configuração de implantação que estava usando para implantar o pod no cluster AKS. Eu tinha um volume baseado em montagem de host que apontava para o caminho "/var/run".
Depois de remover o host mount , curl e wget funcionaram conforme o esperado.
Depois de discutir esse comportamento com o suporte da MS, eles confirmaram que curl e wget não estão retornando ao arquivo /etc/resolv.conf para resolução de DNS se você tiver uma montagem de host apontada para o caminho "/var/run" pode ser devido ao caminho A investigação de DNS é implementada em curl e wget.