☰

컬 및 wget은 aks 클러스터 내의 내부 DNS 이름을 확인할 수 없지만 nslookup, host, dig는 정상적으로 작동합니다.

tag-icon • tag-icon domain-name-system kubernetes curl aks
컬 및 wget은 aks 클러스터 내의 내부 DNS 이름을 확인할 수 없지만 nslookup, host, dig는 정상적으로 작동합니다.

Azure에 관리형 kubernetes 인스턴스가 있습니다. 핵심 DNS가 작동하고 있고 DNS 포드가 정상이라고 확신합니다.

몇 가지 서비스가 있어요

  1. 하나의 포드가 있는 frontend-service - 정적 프런트엔드 파일이 있는 이미지 [nginx-alpine].

  2. backend-service, 하나의 포드 포함 - nodejs 코드가 있는 이미지 [ubuntu:20.04].

백엔드 포드에서 frontend-service 또는 frontend-service.default.svc.cluster.local과 같은 내부 DNS 서비스 이름을 확인할 수 없지만 내부 DNS 이름의 nslookup,host, dig가 올바른 주소로 확인됩니다. 백엔드 포드는 google.com과 같은 외부 DNS 이름을 확인할 수도 있습니다.

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

프런트엔드 서비스 포드에서 백엔드 서비스 내부 DNS 이름을 확인하는 동안 모든 것이 잘 작동합니다.

디버깅을 하고 coredns 및 strace의 로그를 살펴본 후, 컬을 수행하는 동안 coredns 포드에 대한 호출이 발생하지 않는 것을 볼 수 있지만 nslook up을 수행하는 동안 항목을 볼 수 있습니다.

나도. /etc/resolv.conf의 구성이 올바른지 확인했습니다.

nameserver 10.3.0.10
search default.svc.cluster.local svc.cluster.local cluster.local tdghymxumodutbxfnz5m2elcog.bx.internal.cloudapp.net
options ndots:5

strace는 /etc/resolv.conf를 검색할 항목을 표시하지 않으므로 컬은 /etc/resolv.conf를 확인하지 않습니다.

편집 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

편집 2

동일한 ubuntu:20.04 이미지를 사용하여 단계별로 배포를 테스트하고 싶어서 다음을 수행했습니다.

접근법 1

아래와 같이 클러스터에 임시 포드를 생성했습니다.

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.

이것이 저를 당황하게 하여 Dockerfile에서 모든 빌드 단계를 제거하고 아래 명령만 사용했습니다.

접근법 2

도커파일

FROM ubuntu:20.04
 
EXPOSE 3688
CMD [ "sleep", "infinity" ]

이미지를 acr에 푸시하고 백엔드 포드를 다시 배포했습니다.

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.

이는 놀랍게도 동일한 콘텐츠를 가진 동일한 이미지입니다. kubectl run을 통해 실행하고 Dockerfile을 통해 배포하면 동일한 버전(7.68)의 컬을 실행하는 동안 동작이 다릅니다.

나는 두 접근법 모두에서 strace의 흐름을 보고 싶었습니다. RUN 및 EXEC에서 strace 링크를 찾으십시오.

임시 포드에서 컬을 실행하는 중입니다. https://pastebin.com/NthHQacW

Dockerfile을 통해 배포된 포드에서 컬을 실행하여 strace를 수행합니다. https://pastebin.com/6LCE5NXu

다음을 실행하여 프로빙 경로를 분석한 후

cat strace-log | grep open

접근 방식 2의 strace 로그에 아래 줄이 누락되어 있음을 발견했습니다.


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

따라서 포드 내의 컬 명령은 /etc/resolv.conf 또는 /etc/nsswitch.conf를 확인하지 않습니다.

동일한 클러스터에서 동일한 이미지와 동일한 컬 버전을 가진 두 개의 포드 내에서 컬의 동작이 다른 이유가 무엇인지 궁금합니다.

답변1

많은 옵션을 시도한 후 Pod를 AKS 클러스터에 배포하는 데 사용했던 배포 구성 파일을 디버깅하려고 했습니다. "/var/run" 경로를 가리키는 호스트 마운트 기반 볼륨이 있었습니다.

호스트 마운트를 제거하면 컬과 wget이 예상대로 작동했습니다.

MS 지원팀과 이 동작을 논의한 후, "/var/run" 경로를 가리키는 호스트 마운트가 있는 경우 컬 및 wget이 DNS 확인을 위해 /etc/resolv.conf 파일로 대체되지 않음을 확인했습니다. DNS 검색은 컬 및 wget에서 구현됩니다.

관련 정보