CoreDNS

CoreDNS는 DNS 질의를 처리하는 서버이며, 기능을 플러그인으로 조합하는 구조를 갖는다. 파일 기반 응답, 외부 DNS 전달, 캐시, 지표 노출과 Kubernetes 서비스 발견 등을 필요한 조합으로 구성한다. DNS를 사용한다고 항상 CoreDNS가 필요한 것은 아니지만 Kubernetes에서는 흔히 클러스터 DNS 역할을 맡는다. CoreDNS 매뉴얼이 기본 구조를 설명한다.

플러그인과 서비스 발견

Corefile의 서버 블록은 어떤 DNS 영역을 어느 포트에서 처리할지 정하고 플러그인 설정을 담는다. 응답을 직접 만드는 플러그인도 있고 캐시나 로깅처럼 처리에 기능을 더하는 플러그인도 있다. 적어 둔 줄의 순서만으로 모든 플러그인의 실제 실행 순서가 결정된다고 가정해서는 안 된다.

kubernetes 플러그인은 Kubernetes API의 서비스·엔드포인트 정보를 이용해 DNS 응답을 만든다. 일반 ClusterIP Service 이름은 안정적인 서비스 주소로 해석되고, headless Service의 응답 방식은 다르다. kubernetes 플러그인 참조는 영역·네임스페이스·TTL 등의 설정과 API 연결을 설명한다.

장점과 한계

작은 DNS 서버부터 클러스터 서비스 발견까지 같은 구성 체계로 다룰 수 있고, 필요 기능을 플러그인으로 선택할 수 있다. 애플리케이션은 교체되는 Pod 주소를 직접 저장하는 대신 서비스 이름으로 통신할 수 있다. 다만 DNS 응답이 올바르더라도 실제 TCP 연결이나 애플리케이션 상태까지 정상이라는 뜻은 아니다.

잘못된 전달 경로는 반복 질의나 장애를 만들 수 있고, 과도한 캐시는 변경 반영을 늦출 수 있다. API 접근 권한과 네트워크, 상위 DNS의 상태를 함께 확인해야 한다. 외부 도메인만 실패하는지 클러스터 내부 이름도 실패하는지에 따라 조사 경로가 달라진다.

도서 검색 서비스 이름 확인

library-lab 네임스페이스에 catalog라는 Service가 있고 클러스터 도메인이 cluster.local인 연습 환경을 가정한다. 아래 명령은 DNS 도구가 설치된 기존 실습 Pod 안에서 실행하는 조회 예시다. 새 Pod를 만들거나 DNS 설정을 바꾸지 않는다.

nslookup catalog.library-lab.svc.cluster.local
nslookup kubernetes.default.svc.cluster.local
cat /etc/resolv.conf

첫 조회는 업무 서비스, 두 번째는 클러스터 기본 서비스 이름을 비교한다. 하나만 실패하면 해당 Service의 존재와 네임스페이스부터 확인할 수 있다. resolv.conf의 nameserver와 search는 이 Pod가 실제로 어느 DNS와 검색 접미사를 사용하는지 보여 준다. 주소를 일반 브라우저에서 해석할 수 있는지는 별개의 문제다.

자주 생기는 오해

짧은 이름 catalog는 호출 Pod의 네임스페이스 검색 규칙에 영향을 받는다. 다른 네임스페이스로 이동하면 같은 짧은 이름이 달라질 수 있으므로 필요한 범위를 명시한다. DNS 오류를 해결하려고 애플리케이션에 Pod IP를 고정하면 Pod 교체 시 다시 장애가 생길 수 있다. 이름·Service·엔드포인트·연결을 순서대로 확인한다.

참고 자료