IT/Kubernets

CoreDNS autopath + NodeLocal DNSCache, 같이 써야 진짜 빨라진다

gfrog 2026. 5. 5. 21:14
반응형

 

쿠버네티스 클러스터가 어느 정도 커지면 DNS가 가장 먼저 비명을 지른다. 우리 팀도 노드 80대 규모 EKS에서 CoreDNS QPS가 2만을 넘기면서 P99 레이턴시가 200ms 가까이 튀는 걸 보고 나서야 손을 댔다. NodeLocal DNSCache는 들어봤는데, autopath는 의외로 안 쓰는 팀이 많더라. 이 둘을 같이 써야 진짜 효과가 난다.

이 글은 두 컴포넌트를 같이 도입하는 가이드다. 각각의 역할, 설정 순서, 그리고 같이 쓸 때 주의할 점까지 정리했다.

ndots:5가 만드는 N+1 쿼리 문제

쿠버네티스 파드에 들어가서 cat /etc/resolv.conf를 찍어보면 이런 게 나온다.

search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5

ndots:5는 도메인 이름의 점이 5개 미만이면 search 도메인을 다 붙여서 시도해보라는 뜻이다. 그래서 api.example.com을 부르면 다음 순서로 쿼리가 나간다.

  1. api.example.com.default.svc.cluster.local
  2. api.example.com.svc.cluster.local
  3. api.example.com.cluster.local
  4. api.example.com

외부 도메인 한 번 부르려고 NXDOMAIN 응답을 세 번 받는다. 클라이언트 입장에선 RTT 곱하기 4. 클러스터 입장에선 쓸데없는 트래픽 4배. 작은 클러스터에선 그냥 무시할 수 있는데, 노드가 늘고 마이크로서비스가 외부 API를 자주 호출하기 시작하면 이게 진짜 무섭다.

NodeLocal DNSCache: 일단 트래픽부터 줄인다

NodeLocal DNSCache는 모든 노드에 DaemonSet으로 경량 CoreDNS 인스턴스를 띄운다. 파드의 DNS 쿼리는 kube-proxy iptables 룰에 의해 노드 로컬(169.254.20.10)로 가로채지고, 캐시 히트면 거기서 바로 응답한다. 미스만 진짜 CoreDNS로 간다.

효과는 즉각적이다. 우리 팀 측정값으로:

  • CoreDNS 들어가는 QPS: 22k → 3.5k (84% 감소)
  • 파드 측 P99 lookup latency: 180ms → 12ms
  • 노드 간 DNS UDP 트래픽: 사실상 0

설치는 공식 매니페스트로 한 방이다. kubectl apply -f 하기 전에 __PILLAR__DNS__SERVER__, __PILLAR__LOCAL__DNS__, __PILLAR__DNS__DOMAIN__ 세 개 변수만 sed로 바꿔준다.

kubedns=$(kubectl get svc kube-dns -n kube-system -o jsonpath='{.spec.clusterIP}')
domain="cluster.local"
localdns="169.254.20.10"

curl -L https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml \
  | sed "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" \
  | kubectl apply -f -

근데 이걸로 끝이 아니다. NodeLocal DNSCache는 캐시일 뿐이라서, 캐시에 없는 쿼리는 여전히 search 도메인 4개를 다 시도한다. 외부 도메인일수록 캐시 히트율이 낮아서 효과가 떨어진다.

autopath: 쿼리 자체를 줄인다

autopath 플러그인은 접근 방식이 다르다. 파드의 namespace를 보고, 첫 번째 쿼리 응답에 CNAME으로 "이 도메인은 외부야, search 도메인 더 붙이지 마"라는 힌트를 박아준다. 클라이언트는 그걸 받고 두 번째, 세 번째 쿼리를 안 날린다.

CoreDNS Corefile에 이렇게 추가한다.

.:53 {
    errors
    health
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods verified
        fallthrough in-addr.arpa ip6.arpa
    }
    autopath @kubernetes
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

중요한 포인트 몇 개:

pods verified가 필수다. autopath는 파드 IP로 namespace를 알아내야 하는데, pods insecure나 디폴트 pods disabled로는 동작 안 한다. verified로 바꿔야 kubernetes 플러그인이 파드 정보를 watch하고 캐시한다.

autopath는 kubernetes 플러그인 뒤에 와도 되지만, 같은 zone에 있어야 한다. Corefile 작성 순서는 위 예시처럼 두면 된다.

메모리가 좀 더 든다. 파드 IP → namespace 매핑을 다 들고 있어야 해서. 파드 1만 개 기준 100MB 정도 추가됐다. CoreDNS 리밋이 170Mi였는데 256Mi로 올렸다.

둘이 같이 쓸 때 진짜 주의할 점

여기서부터가 본론이다. NodeLocal DNSCache + autopath를 같이 쓰면 한 가지 함정이 있다.

NodeLocal DNSCache 자체도 안에서 작은 CoreDNS가 도는데, 이 캐시가 autopath의 응답을 캐시해버린다는 거다. autopath는 파드의 namespace에 따라 다른 응답을 만들어야 하는데, A 파드 응답이 캐시되면 B 파드(다른 namespace)가 같은 답을 받게 된다. 그러면 B 파드 입장에선 CNAME 힌트가 잘못된 거고, search 도메인 검색이 깨진다.

해결책은 NodeLocal DNSCache의 cluster.local zone에서 caching을 끄는 것이다. NodeLocalDNS의 ConfigMap에서:

cluster.local:53 {
    errors
    cache {
        success 9984 30
        denial 9984 5
    }
    reload
    loop
    bind 169.254.20.10 10.96.0.10
    forward . __PILLAR__CLUSTER__DNS__ {
        force_tcp
    }
    prometheus :9253
    health 169.254.20.10:8080
}

여기서 cache 블록을 빼거나, 최소한 disable success cluster.local을 추가한다. 우리 팀은 그냥 cluster.local zone에서는 캐시 자체를 빼버렸다. 어차피 파드 IP 변동이 잦아서 캐시 효과보다 stale 위험이 더 컸다.

cluster.local:53 {
    errors
    reload
    loop
    bind 169.254.20.10 10.96.0.10
    forward . __PILLAR__CLUSTER__DNS__ {
        force_tcp
    }
    prometheus :9253
    health 169.254.20.10:8080
}

외부 도메인 zone(.:53)에서는 캐시 그대로 두면 된다. autopath 응답은 어차피 cluster.local zone에서만 나온다.

검증: 진짜로 줄었나?

Prometheus 메트릭으로 검증한다.

# CoreDNS가 받는 총 쿼리 (NodeLocal 도입 전후 비교)
sum(rate(coredns_dns_requests_total[5m]))

# autopath가 처리한 쿼리 비율
sum(rate(coredns_autopath_success_total[5m])) 
  / sum(rate(coredns_dns_requests_total{server="dns://:53"}[5m]))

# NXDOMAIN 응답 비율 - autopath 잘 동작하면 떨어진다
sum(rate(coredns_dns_responses_total{rcode="NXDOMAIN"}[5m]))
  / sum(rate(coredns_dns_responses_total[5m]))

도입 전후 비교 (실측):

메트릭 Before After
CoreDNS QPS 22,000 1,800
파드 P99 lookup 180ms 4ms
NXDOMAIN 비율 73% 11%
CoreDNS 메모리 170Mi 240Mi

NXDOMAIN 비율이 73%에서 11%로 떨어진 게 핵심이다. 이게 줄었다는 건 search 도메인 무한 시도가 사라졌다는 뜻이고, 클라이언트가 체감하는 속도 차이가 크다.

한 가지 안 풀린 문제

autopath는 Windows 노드 파드에선 동작하지 않는다. Windows 컨테이너는 ndots 동작이 리눅스랑 달라서 그렇다. 우리는 Windows 노드가 없어서 신경 안 썼는데, 멀티 OS 클러스터 굴리는 분들은 NodeSelector로 Windows 파드만 별도 처리하거나, 그냥 autopath 안 쓰는 게 안전하다.

또 하나 — CoreDNS 1.12.2(2025년 6월 릴리즈)에서 autopath 슬라이스 할당 최적화가 들어갔다. 1.11 버전 이하 쓰는 분들은 가능하면 1.12.2 이상으로 올리는 게 좋다. 메모리 사용량이 눈에 띄게 줄었다.

정리

NodeLocal DNSCache 단독으로도 효과는 크다. autopath만 단독으로 써도 좋다. 근데 둘 중 하나만 쓰면 절반의 효과만 본다는 게 이번 도입에서 배운 점이다. 캐시 충돌 함정만 피하면 같이 쓰는 게 정답이다.

다음에는 같은 맥락에서 ExternalDNS와 Route53 동기화 지연으로 삽질한 얘기도 풀어볼까 한다.

반응형
저작자표시 비영리 동일조건 (새창열림)