← Blog
트러블슈팅

K3s 노드 확장 후 발생한 외부 도메인 연결 오류 (ndots 이슈)

목차

개요

K3s 클러스터를 4노드에서 9노드로 확장하고 etcd 기반 HA 구조로 전환한 직후, 예상치 못한 네트워크 장애가 발생했습니다. ArgoCD의 GitHub 리포지토리 연결 실패(Connection Timeout)와 사이드카 컨테이너의 SSL 핸드쉐이크 오류(SSL alert 80)가 간헐적으로 관찰되었습니다. 단순한 설정 문제로 보였던 이번 장애를 추적한 결과, 쿠버네티스 DNS 메커니즘인 ndots 설정과 외부 검색 도메인 간의 간섭이 근본 원인임을 확인했습니다.

1. 문제 상황

  • 증상 1: ArgoCD에서 GitHub 리포지토리 연결 시 Connection Timeout 및 인증 실패 발생.
  • 증상 2: 컨테이너 내부에서 외부 API(MaxMind 등) 호출 시 SSL 핸드쉐이크 에러(SSL alert number 80) 발생
  • 특이점: 모든 Pod가 아닌 일부에서만 발생하며, HA 전환 및 노드 확장 직후부터 현상이 관찰됨.

2. 첫 번째 가설: MTU 병목

초기에는 패킷 유실 문제로 판단하여 MTU(Maximum Transmission Unit) 설정을 의심했습니다.

  • 이유: 클러스터 확장으로 인해 네트워크 홉(Hop)이나 오버헤드가 증가하면서 특정 크기 이상의 패킷이 드랍된다고 생각했습니다.
  • 조치: 컨테이너 인터페이스의 MTU를 1500에서 1300으로 낮춰보았습니다.
  • 결과: 잠시 정상 동작하는 듯했으나, 재설치 후 동일 증상이 반복되어 근본 원인이 아님을 확인했습니다.

3. 원인 파악: 엉뚱한 IP로의 연결

문제 노드에서 ssh -vvv를 통해 GitHub 연결 과정을 상세히 확인해 보니, github.com이 실제 IP가 아닌 엉뚱한 IP(74.207.241.245)로 분석(Resolve)되고 있는 것을 발견했습니다.

4. 근본 원인: CoreDNS의 ndots 설정과 검색 도메인 간섭

쿠버네티스의 기본 DNS 설정인 ndots:5와 시스템의 검색 도메인이 결합하며 발생한 문제였습니다.

  • 동작 매커니즘: 쿠버네티스는 도메인의 점(.) 개수가 5개 미만이면, 이를 내부 서비스 주소로 가정하고
    /etc/resolv.conf에 등록된 search 리스트 주소들을 뒤에 붙여서 순차적으로 질의합니다.

질의 순서: 사용자가 github.com 호출 시:

  1. github.com.default.svc.cluster.local (실패)
  2. github.com.svc.cluster.local (실패)
  3. github.com.cluster.local (실패)
  4. github.com.tail2c8b06.ts.net (질의 중 응답 수신)
  5. github.com. (진짜 주소까지 도달 못 함)

문제의 핵심: 4번 과정에서 외부 DNS(혹은 특정 네트워크 장비)가 "해당 주소 없음(NXDOMAIN)" 응답을 주는 대신, 엉뚱한 IP를 담은 NOERROR 응답을 보냈습니다. 쿠버네티스는 이를 정상 응답으로 간주하여 실제 GitHub 주소까지 질의를 이어가지 않고 엉뚱한 서버로 접속을 시도했던 것입니다.

유사하게 포착된 사례

간혈적으로 연결이 되는 이유

  • 만약 어떤 시점에 네트워크 지연이나 외부 DNS의 일시적 오류로 인해 4번 질의(...ts.net, .com)가 응답을 못 받고 건너뛰게 되어 5번(github.com.)이 먼저 성공한 적이 있다면, CoreDNS는 이 진짜 IP를 한동안 캐시에 들고 있습니다.
  • 이 캐시가 유지되는 동안에는 즉시 진짜 IP로 연결되지만, 캐시가 만료(TTL 종료)되어 다시 질의를 시작하면 다시 4, 5번의 "엉뚱한 응답"에 낚이게 되는 것입니다.

마치며: 3일간의 추적이 남긴 교훈

이번 장애를 해결하며 단순한 리소스 생성을 넘어 인프라 하부 구조의 중요성을 다시 확인했습니다.

처음엔 MTUndots 같은 개념이 생소하다 보니, AI의 가이드에 의존하며 갈팡질팡하기도 했습니다. 그 과정에서 3일이라는 시간을 쏟으며 갖은 시도를 했지만, 오히려 그 덕분에 CoreDNS 로그를 분석하는 법, search 도메인의 역할, ndots의 매커니즘을 뇌리에 강렬하게 새길 수 있었습니다.

아직도 "처음부터 어떤 방식으로 접근했어야 좋았을까?"라는 고민은 남습니다.

이번 경험을 통해 쿠버네티스 공부가 단순히 리소스를 생성하는 법을 익히는 게 전부가 아니라는 걸 느꼈습니다. 그 안에 내재된 기술들이 각각 어떻게 유기적으로 맞물려 돌아가는지, 앞으로 어떤 방향으로 깊게 파고들어야 할지 감을 잡을 수 있었던 소중한 시간이었습니다.