작업자 노드가 아닌 Pod 내부에서 DNS 확인 실패 문제 해결

아티클
11/20/2024

이 문서에서는 AKS(Microsoft Azure Kubernetes Service) 클러스터에서 아웃바운드 연결을 설정하려고 할 때 작업자 노드가 아닌 Pod 내부에서 발생하는 DNS(Domain Name System) 확인 실패 문제를 해결하는 방법을 설명합니다.

필수 조건

Kubernetes kubectl 도구 또는 클러스터에 연결할 유사한 도구입니다. Azure CLI를 사용하여 kubectl을 설치하려면 az aks install-cli 명령을 실행합니다.
패키지를 처리하기 위한 apt-get 명령줄 도구입니다.
DNS 조회를 위한 호스트 명령줄 도구입니다.
systemctl 명령줄 도구입니다.

배경

DNS 확인을 위해 Pod는 네임스페이스의 CoreDNS Pod에 kube-system 요청을 보냅니다.

DNS 쿼리가 서비스 이름과 같은 내부 구성 요소에 대한 경우 CoreDNS Pod는 자체적으로 응답합니다. 그러나 외부 도메인에 대한 요청인 경우 CoreDNS Pod는 요청을 업스트림 DNS 서버로 보냅니다.

업스트림 DNS 서버는 Pod가 실행 중인 작업자 노드의 resolv.conf 파일을 기반으로 가져옵니다. resolv.conf 파일( /run/systemd/resolve/resolv.conf)은 작업자 노드가 실행 중인 가상 네트워크의 DNS 설정을 기반으로 업데이트됩니다.

문제 해결 검사 목록

Pod 내에서 DNS 문제를 해결하려면 다음 섹션의 지침을 사용합니다.

1단계: Pod 내에서 DNS 문제 해결

다음 단계에 표시된 것처럼 kubectl 명령을 사용하여 Pod 내에서 DNS 문제를 해결할 수 있습니다.

CoreDNS Pod가 실행 중인지 확인합니다.

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

CoreDNS Pod가 과용되었는지 확인합니다.

$ kubectl top pods -n kube-system -l k8s-app=kube-dns
NAME                      CPU(cores)   MEMORY(bytes)
coredns-dc97c5f55-424f7   3m           23Mi
coredns-dc97c5f55-wbh4q   3m           25Mi

CoreDNS Pod를 호스트하는 노드가 과도하게 사용되지 않는지 확인합니다. 또한 CoreDNS Pod를 호스팅하는 노드를 가져옵니다.
```
kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].spec.nodeName}'
```
다음 노드의 사용량을 확인합니다.
```
kubectl top nodes
```

CoreDNS Pod에 대한 로그를 확인합니다.

kubectl logs -l k8s-app=kube-dns -n kube-system

참고 항목

더 많은 디버깅 정보를 보려면 CoreDNS에서 자세한 정보 표시 로그를 사용하도록 설정합니다. CoreDNS에서 자세한 로깅을 사용하도록 설정하려면 AKS에서 CoreDNS 사용자 지정 문제 해결을 참조하세요.

2단계: 명령을 실행하는 테스트 Pod 만들기

DNS 확인이 실패하는 경우 다음 단계를 수행합니다.

문제가 있는 Pod와 동일한 네임스페이스에서 테스트 Pod를 실행합니다.
클러스터에서 테스트 Pod를 시작합니다.
```
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
```
테스트 Pod가 실행되면 Pod에 액세스할 수 있습니다.
다음 명령을 실행하여 필요한 패키지를 설치합니다.
```
apt-get update -y
apt-get install dnsutils -y
```

resolv.conf 파일에 올바른 항목이 있는지 확인합니다.

cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local 00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net
nameserver 10.0.0.10
options ndots:5

명령을 host 사용하여 DNS 요청이 업스트림 서버로 라우팅되는지 여부를 확인합니다.

$ host -a microsoft.com
Trying "microsoft.com.default.svc.cluster.local"
Trying "microsoft.com.svc.cluster.local"
Trying "microsoft.com.cluster.local"
Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
Trying "microsoft.com"
Trying "microsoft.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      ANY

;; ANSWER SECTION:
microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
...
...
ns4-39.azure-dns.info.  30      IN      A       13.107.206.39

Received 2121 bytes from 10.0.0.10#53 in 232 ms

Pod에서 업스트림 DNS 서버를 확인하여 DNS 확인이 제대로 작동하는지 확인합니다. 예를 들어 Azure DNS의 경우 다음 nslookup 명령을 실행합니다.
```
$ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85
```

3단계: 업스트림 DNS 서버가 명시적으로 지정될 때 DNS 요청이 작동하는지 확인

업스트림 DNS 서버를 명시적으로 지정할 때 Pod의 DNS 요청이 작동하는 경우 다음 조건을 확인합니다.

CoreDNS에 대한 사용자 지정 ConfigMap을 확인합니다.
```
kubectl describe cm coredns-custom -n kube-system
```
사용자 지정 ConfigMap이 있는 경우 구성이 올바른지 확인합니다. 자세한 내용은 Azure Kubernetes Service를 사용하여 CoreDNS 사용자 지정을 참조 하세요.
네트워크 정책이 UDP(사용자 데이터그램 프로토콜) 포트 53에서 네임스페이스의 CoreDNS Pod에 대한 트래픽을 차단하고 있는지 확인합니다 kube-system .
CoreDNS Pod가 다른 노드 풀(시스템 노드 풀)에 있는지 확인합니다. 이 경우 NSG(네트워크 보안 그룹)가 UDP 포트 53에서 트래픽을 차단하는 시스템 노드 풀과 연결되어 있는지 확인합니다.
새 DNS 서버를 추가하기 위해 가상 네트워크가 최근에 업데이트되었는지 확인합니다.

가상 네트워크 업데이트가 발생한 경우 다음 이벤트 중 하나도 발생했는지 확인합니다.
- 노드가 다시 시작되었습니다.
- 노드의 네트워크 서비스가 다시 시작되었습니다.
DNS 설정의 업데이트가 적용되려면 노드의 네트워크 서비스 및 CoreDNS Pod를 다시 시작해야 합니다. 네트워크 서비스 또는 Pod를 다시 시작하려면 다음 방법 중 하나를 사용합니다.
- 노드를 다시 시작합니다.
- 새 노드의 크기를 조정합니다. (새 노드에는 업데이트된 구성이 포함됩니다.)
- 노드에서 네트워크 서비스를 다시 시작한 다음 CoreDNS Pod를 다시 시작합니다. 다음 단계를 수행합니다.
  1. 노드에 대한 SSH(Secure Shell) 연결을 만듭니다. 자세한 내용은 유지 관리 또는 문제 해결을 위해 AKS(Azure Kubernetes Service) 클러스터 노드에 연결을 참조하세요.
  2. 노드 내에서 네트워크 서비스를 다시 시작합니다.
```
systemctl restart systemd-networkd
```
  3. 설정이 업데이트되었는지 확인합니다.
```
cat /run/systemd/resolve/resolv.conf
```
  4. 네트워크 서비스를 다시 시작한 후 kubectl을 사용하여 CoreDNS Pod를 다시 시작합니다.
```
kubectl delete pods -l k8s-app=kube-dns -n kube-system
```

가상 네트워크 DNS 설정에 둘 이상의 DNS 서버가 지정되어 있는지 확인합니다.

AKS 가상 네트워크에 여러 DNS 서버를 지정하는 경우 다음 시퀀스 중 하나가 발생합니다.

AKS 노드는 시리즈의 일부로 업스트림 DNS 서버에 요청을 보냅니다. 이 순서에서 요청은 가상 네트워크에 구성된 첫 번째 DNS 서버로 전송됩니다(DNS 서버에 연결할 수 있고 실행 중인 경우). 첫 번째 DNS 서버에 연결할 수 없고 응답하지 않으면 요청이 다음 DNS 서버로 전송됩니다.

AKS 노드는 확인자 명령을 사용하여 DNS 서버에 요청을 보냅니다. 이 확인자의 구성 파일은 AKS 노드의 /run/systemd/resolve/resolv.conf 에서 찾을 수 있습니다.

서버가 여러 대 있나요? 이 경우 확인자 라이브러리는 나열된 순서대로 쿼리합니다. (사용되는 전략은 이름 서버를 먼저 시도하는 것입니다. 쿼리 시간이 초과되면 다음 이름 서버를 시도하고 이름 서버 목록이 소진될 때까지 계속합니다. 그런 다음 쿼리는 최대 재시도 횟수가 만들어 질 때까지 이름 서버에 계속 연결하려고 합니다.)

CoreDNS는 앞으로 플러그 인을 사용하여 업스트림 DNS 서버에 요청을 보냅니다. 이 플러그 인은 임의 알고리즘을 사용하여 업스트림 DNS 서버를 선택합니다. 이 시퀀스에서 요청은 가상 네트워크에 언급된 DNS 서버로 이동될 수 있습니다. 예를 들어 다음 출력을 받을 수 있습니다.

$ kubectl describe cm coredns -n kube-system
Name:         coredns
Namespace:    kube-system
Labels:       addonmanager.kubernetes.io/mode=Reconcile
              k8s-app=kube-dns
              kubernetes.io/cluster-service=true
Annotations:  <none>

Data
====
Corefile:
----
.:53 {
    errors
    ready
    health
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
    prometheus :9153
    forward . /etc/resolv.conf                            # Here!
    cache 30
    loop
    reload
    loadbalance
    import custom/*.override
}
import custom/*.server


BinaryData
====

Events:  <none>

CoreDNS forward 플러그 인에서 policy는 업스트림 서버 선택에 사용할 정책을 지정합니다. 정책은 다음 표에 정의되어 있습니다.

정책 이름	Description
`random`	임의의 업스트림 선택을 구현하는 정책입니다. 이 정책은 기본 정책입니다.
`round_robin`	라운드 로빈 순서를 기반으로 호스트를 선택하는 정책입니다.
`sequential`	순차적 순서에 따라 호스트를 선택하는 정책입니다.

AKS 가상 네트워크에 여러 DNS 서버가 포함된 경우 AKS 노드의 요청이 첫 번째 DNS 서버로 이동될 수 있습니다. 그러나 Pod의 요청은 두 번째 DNS 서버로 이동될 수 있습니다.

원인: DNS 요청에 대한 여러 대상

두 개의 사용자 지정 DNS 서버가 지정되고 세 번째 DNS 서버가 Azure DNS(168.63.129.16)로 지정된 경우 노드는 실행 중이고 연결할 수 있는 경우 첫 번째 사용자 지정 DNS 서버로 요청을 보냅니다. 이 설정에서 노드는 사용자 지정 도메인을 확인할 수 있습니다. 그러나 Pod의 일부 DNS 요청은 Azure DNS로 전송될 수 있습니다. CoreDNS가 임의로 업스트림 서버를 선택할 수 있기 때문입니다. 이 시나리오에서는 사용자 지정 도메인을 확인할 수 없습니다. 따라서 DNS 요청이 실패합니다.

해결 방법: 가상 네트워크 설정에서 Azure DNS 제거

가상 네트워크 설정에서 사용자 지정 DNS 서버와 Azure DNS를 결합하지 않는 것이 좋습니다. 사용자 지정 DNS 서버를 사용하려면 가상 네트워크 설정에 사용자 지정 DNS 서버만 추가합니다. 그런 다음 사용자 지정 DNS 서버의 전달자 설정에서 Azure DNS를 구성합니다.

자세한 내용은 자체 DNS 서버를 사용하는 이름 확인을 참조하세요.

타사 연락처 고지

이 문서에 포함된 타사의 연락처 정보는 이 항목에 대한 추가 정보를 찾는 데 도움을 주기 위한 것입니다. 이 연락처 정보는 공지 없이 변경될 수 있습니다. Microsoft는 타사 연락처 정보의 정확성을 보증하지 않습니다.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나 Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.

다음을 통해 공유