클러스터 내부 DNS 완벽 가이드

쿠버네티스 클러스터 내부에서 서비스들이 서로를 어떻게 찾는지, CoreDNS의 동작 원리부터 실무에서 자주 사용하는 DNS 디버깅 방법까지 초급 개발자도 쉽게 이해할 수 있도록 설명합니다.

---

목차

1. CoreDNS 이해하기
2. 서비스 DNS 이름 규칙
3. Pod DNS 정책
4. Headless Service DNS
5. DNS 디버깅 방법
6. 커스텀 DNS 설정

---

1. CoreDNS 이해하기

김개발 씨는 쿠버네티스 클러스터에 처음으로 마이크로서비스를 배포했습니다. 그런데 이상한 일이 벌어졌습니다.

분명히 서비스 이름으로 API를 호출했는데, 어떻게 IP 주소도 모르면서 통신이 되는 걸까요? 선배에게 물어보니 "CoreDNS 덕분이지"라는 답이 돌아왔습니다.

CoreDNS는 쿠버네티스 클러스터의 기본 DNS 서버입니다. 마치 거대한 회사 건물의 안내 데스크처럼, 클러스터 내의 모든 서비스 위치를 알고 있습니다.

Pod가 서비스 이름으로 요청을 보내면, CoreDNS가 해당 서비스의 IP 주소를 찾아서 알려줍니다.

다음 코드를 살펴봅시다.

# CoreDNS 구성 확인하기
kubectl get configmap coredns -n kube-system -o yaml

# CoreDNS Pod 상태 확인
kubectl get pods -n kube-system -l k8s-app=kube-dns

# CoreDNS 서비스 확인
kubectl get svc -n kube-system kube-dns

# Corefile 핵심 설정 예시
# .:53 {
#     kubernetes cluster.local in-addr.arpa ip6.arpa {
#         pods insecure
#         fallthrough in-addr.arpa ip6.arpa
#     }
#     forward . /etc/resolv.conf
#     cache 30
# }

김개발 씨는 입사 2개월 차 주니어 개발자입니다. 오늘 처음으로 쿠버네티스 클러스터에 자신이 만든 백엔드 서비스를 배포했습니다.

그런데 신기한 일이 벌어졌습니다. 프론트엔드 Pod에서 백엔드 API를 호출할 때, IP 주소가 아닌 서비스 이름만으로 통신이 되는 것입니다.

분명히 IP 주소는 배포할 때마다 바뀔 텐데, 어떻게 항상 정확하게 찾아가는 걸까요? 선배 개발자 박시니어 씨가 다가와 설명해주었습니다.

"그건 CoreDNS 덕분이야. 클러스터 내부의 전화번호부라고 생각하면 돼." 그렇다면 CoreDNS란 정확히 무엇일까요?

쉽게 비유하자면, CoreDNS는 마치 대형 쇼핑몰의 안내 데스크와 같습니다. 손님이 "OO 매장이 어디에요?"라고 물으면, 안내 데스크 직원이 "3층 동쪽 끝에 있습니다"라고 알려주죠.

CoreDNS도 마찬가지입니다. Pod가 "user-service가 어디에 있어?"라고 물으면, CoreDNS가 "10.96.45.123이야"라고 IP 주소를 알려줍니다.

CoreDNS가 없던 시절에는 어땠을까요? 개발자들은 서비스의 IP 주소를 직접 관리해야 했습니다.

환경 변수에 IP를 하드코딩하거나, 설정 파일에 일일이 적어놓았죠. 문제는 서비스가 재시작되거나 스케일링되면 IP가 바뀔 수 있다는 것입니다.

그때마다 모든 연관 서비스의 설정을 바꿔야 했습니다. 바로 이런 문제를 해결하기 위해 쿠버네티스는 CoreDNS를 기본 DNS 서버로 채택했습니다.

CoreDNS는 kube-system 네임스페이스에서 실행됩니다. 클러스터가 생성될 때 자동으로 배포되며, 보통 2개의 복제본으로 고가용성을 보장합니다.

모든 Pod는 자동으로 CoreDNS를 DNS 서버로 사용하도록 설정됩니다. 위의 명령어를 살펴보겠습니다.

첫 번째 명령어는 CoreDNS의 설정 파일인 Corefile을 확인합니다. 여기서 어떤 도메인을 어떻게 처리할지 정의되어 있습니다.

두 번째 명령어는 CoreDNS Pod가 정상적으로 실행 중인지 확인합니다. 실제 현업에서는 CoreDNS 설정을 거의 건드리지 않습니다.

하지만 문제가 발생했을 때 어디를 봐야 하는지 알아두면 큰 도움이 됩니다. DNS 관련 이슈의 90%는 CoreDNS 상태를 확인하는 것으로 시작합니다.

주의할 점도 있습니다. CoreDNS Pod가 죽으면 클러스터 전체의 서비스 디스커버리가 마비됩니다.

따라서 CoreDNS의 상태를 모니터링하는 것이 중요합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 IP 주소를 몰라도 서비스 이름만으로 통신이 되는 거군요!"

실전 팁

💡 - CoreDNS는 kube-system 네임스페이스에서 실행되므로, 문제 발생 시 해당 네임스페이스부터 확인하세요

• CoreDNS Pod는 기본적으로 2개가 실행되어 고가용성을 보장합니다

---

2. 서비스 DNS 이름 규칙

김개발 씨가 다른 팀의 서비스를 호출하려고 합니다. 그런데 서비스 이름이 뭔지 몰라 막막했습니다.

박시니어 씨가 웃으며 말했습니다. "쿠버네티스 DNS 이름 규칙을 알면, 서비스 이름을 바로 유추할 수 있어."

쿠버네티스의 서비스 DNS 이름은 일정한 규칙을 따릅니다. 서비스명.네임스페이스.svc.cluster.local 형식입니다.

마치 우편 주소처럼 계층 구조로 되어 있어, 같은 네임스페이스면 서비스명만으로, 다른 네임스페이스면 전체 주소로 접근할 수 있습니다.

다음 코드를 살펴봅시다.

# 같은 네임스페이스 내에서 호출
curl http://user-service

# 다른 네임스페이스의 서비스 호출
curl http://user-service.production

# 완전한 FQDN으로 호출
curl http://user-service.production.svc.cluster.local

# 특정 포트를 명시한 호출
curl http://user-service.production.svc.cluster.local:8080

# DNS 레코드 조회 예시
nslookup user-service.default.svc.cluster.local

# SRV 레코드로 포트 정보 조회
nslookup -type=SRV _http._tcp.user-service.default.svc.cluster.local

김개발 씨는 자신의 주문 서비스에서 사용자 서비스의 API를 호출해야 했습니다. 그런데 사용자 서비스가 다른 네임스페이스에 있다고 합니다.

어떻게 호출해야 할까요? 박시니어 씨가 화이트보드에 그림을 그리며 설명했습니다.

"쿠버네티스 DNS 이름은 우편 주소와 비슷해. 계층 구조로 되어 있거든." 쿠버네티스의 서비스 DNS 이름은 마치 회사 내선 전화번호 체계와 같습니다.

같은 부서 내에서는 내선번호 네 자리만 누르면 됩니다. 하지만 다른 부서로 전화하려면 부서 코드까지 함께 눌러야 하죠.

DNS 이름의 전체 형식은 서비스명.네임스페이스.svc.cluster.local입니다. 가장 앞의 서비스명은 쿠버네티스 Service 리소스의 이름입니다.

그 다음 네임스페이스는 서비스가 속한 네임스페이스입니다. svc는 이것이 서비스임을 나타내고, cluster.local은 클러스터의 기본 도메인입니다.

재미있는 점은 같은 네임스페이스 내에서는 서비스명만으로 접근할 수 있다는 것입니다. DNS 검색 도메인이 자동으로 설정되어 있기 때문입니다.

Pod의 /etc/resolv.conf 파일을 열어보면 search 항목에 네임스페이스가 포함되어 있습니다. 예를 들어 default 네임스페이스의 Pod에서 user-service를 호출하면, DNS는 순차적으로 user-service.default.svc.cluster.local을 찾습니다.

만약 없으면 user-service.svc.cluster.local, 그 다음 user-service.cluster.local 순으로 검색합니다. 다른 네임스페이스의 서비스를 호출할 때는 최소한 서비스명과 네임스페이스를 함께 적어야 합니다.

user-service.production 형식으로 말이죠. 실무에서 가장 많이 하는 실수는 네임스페이스를 빠뜨리는 것입니다.

개발 환경에서는 모든 서비스가 같은 네임스페이스에 있다가, 운영 환경에서 네임스페이스가 분리되면서 문제가 발생합니다. 코드에서 서비스 URL을 설정할 때는 환경 변수를 활용하는 것이 좋습니다.

네임스페이스가 바뀔 수 있기 때문입니다. 다시 김개발 씨의 이야기입니다.

이제 다른 팀의 서비스도 자신 있게 호출할 수 있게 되었습니다. "user-service.production이군요.

생각보다 간단하네요!"

실전 팁

💡 - 같은 네임스페이스면 서비스명만, 다른 네임스페이스면 서비스명.네임스페이스 형식을 사용하세요

• FQDN을 사용하면 DNS 검색 시간을 줄일 수 있어 미세한 성능 향상이 있습니다

---

3. Pod DNS 정책

김개발 씨가 외부 API를 호출하려는데 DNS 해석이 안 됩니다. 분명히 인터넷 연결은 되는데 말이죠.

박시니어 씨가 Pod 설정을 살펴보더니 "DNS 정책 문제네"라고 말했습니다.

Pod DNS 정책은 Pod가 DNS 쿼리를 어디로 보낼지 결정합니다. 기본값인 ClusterFirst는 클러스터 DNS를 먼저 확인하고, 없으면 외부로 전달합니다.

상황에 따라 Default, None 등 다른 정책을 선택할 수 있습니다.

다음 코드를 살펴봅시다.

# ClusterFirst 정책 (기본값)
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  dnsPolicy: ClusterFirst
  containers:
  - name: app
    image: nginx

# Default 정책 - 노드의 DNS 설정 사용
apiVersion: v1
kind: Pod
metadata:
  name: host-dns-pod
spec:
  dnsPolicy: Default
  containers:
  - name: app
    image: nginx

# None 정책 - 완전한 커스텀 DNS
apiVersion: v1
kind: Pod
metadata:
  name: custom-dns-pod
spec:
  dnsPolicy: None
  dnsConfig:
    nameservers:
    - 8.8.8.8
    - 8.8.4.4
    searches:
    - my-company.com

김개발 씨는 새로운 기능을 개발하다가 외부 결제 API를 호출해야 했습니다. 그런데 이상하게도 payment.example.com 도메인을 찾을 수 없다는 에러가 발생했습니다.

박시니어 씨가 Pod 설정을 확인했습니다. "hostNetwork를 쓰고 있네.

그러면 DNS 정책도 같이 봐야 해." dnsPolicy는 Pod가 DNS 질의를 어떻게 처리할지 결정하는 설정입니다. 마치 네비게이션의 경로 설정과 같습니다.

고속도로를 우선할지, 일반 도로를 우선할지 선택하는 것처럼요. 쿠버네티스에는 네 가지 DNS 정책이 있습니다.

첫 번째는 ClusterFirst입니다. 가장 많이 사용되는 기본값입니다.

모든 DNS 쿼리를 먼저 클러스터 DNS(CoreDNS)로 보냅니다. 클러스터 내부 서비스를 찾을 수 있고, 외부 도메인은 CoreDNS가 상위 DNS로 전달합니다.

두 번째는 Default입니다. 노드의 DNS 설정을 그대로 사용합니다.

hostNetwork를 사용하는 Pod에서 주로 쓰입니다. 클러스터 내부 서비스는 찾을 수 없지만, 외부 DNS는 바로 접근할 수 있습니다.

세 번째는 ClusterFirstWithHostNet입니다. hostNetwork를 사용하면서도 클러스터 DNS를 쓰고 싶을 때 사용합니다.

이름이 길지만, hostNetwork와 ClusterFirst를 결합한 것입니다. 네 번째는 None입니다.

DNS 설정을 완전히 직접 지정합니다. dnsConfig와 함께 사용하여 원하는 DNS 서버를 명시합니다.

김개발 씨의 문제로 돌아가봅시다. hostNetwork를 사용하면서 dnsPolicy를 지정하지 않으면, 자동으로 Default가 적용됩니다.

이 경우 클러스터 DNS를 거치지 않고 노드의 DNS 설정을 직접 사용합니다. 해결책은 간단합니다.

dnsPolicy를 ClusterFirstWithHostNet으로 변경하면 됩니다. 이렇게 하면 hostNetwork를 사용하면서도 클러스터 DNS의 혜택을 받을 수 있습니다.

실무에서 None 정책은 특수한 상황에서만 사용합니다. 예를 들어 회사 내부 DNS 서버를 직접 지정해야 하거나, 특정 도메인을 우회해야 할 때입니다.

김개발 씨는 설정을 수정하고 다시 배포했습니다. 이제 외부 API 호출도, 내부 서비스 호출도 모두 정상적으로 동작합니다.

실전 팁

💡 - hostNetwork를 사용할 때는 반드시 dnsPolicy를 ClusterFirstWithHostNet으로 설정하세요

• DNS 정책 변경 후에는 Pod를 재시작해야 적용됩니다

---

4. Headless Service DNS

김개발 씨가 StatefulSet으로 데이터베이스 클러스터를 구성했습니다. 그런데 각 Pod에 직접 접근해야 하는 상황이 생겼습니다.

일반 서비스로는 특정 Pod를 지정할 수 없는데, 어떻게 해야 할까요?

Headless Service는 clusterIP가 None인 특별한 서비스입니다. 로드밸런서 없이 각 Pod의 IP를 직접 DNS로 노출합니다.

StatefulSet과 함께 사용하면 pod-0.서비스명 형식으로 특정 Pod에 접근할 수 있습니다.

다음 코드를 살펴봅시다.

# Headless Service 정의
apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  clusterIP: None  # Headless Service의 핵심
  selector:
    app: mysql
  ports:
  - port: 3306
    name: mysql

---
# StatefulSet과 함께 사용
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql  # Headless Service 이름
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0

# 각 Pod에 직접 접근
# mysql-0.mysql.default.svc.cluster.local
# mysql-1.mysql.default.svc.cluster.local
# mysql-2.mysql.default.svc.cluster.local

김개발 씨는 MySQL 클러스터를 쿠버네티스에 구성하고 있었습니다. Primary-Replica 구조로, 쓰기는 Primary로, 읽기는 Replica로 분산하려고 합니다.

문제가 생겼습니다. 일반 서비스는 로드밸런서처럼 동작해서, 어떤 Pod로 연결될지 알 수 없습니다.

쓰기 요청이 Replica로 가면 큰일입니다. 박시니어 씨가 해결책을 알려주었습니다.

"Headless Service를 써봐. 각 Pod에 직접 접근할 수 있어." Headless Service는 마치 회사의 직통 전화번호와 같습니다.

일반 서비스가 대표번호라면, Headless Service는 각 직원의 직통번호를 알려주는 것입니다. 일반 서비스는 clusterIP를 할당받습니다.

이 IP로 요청하면 서비스가 뒤에 있는 Pod들 중 하나로 분배합니다. 하지만 Headless Service는 clusterIP를 None으로 설정합니다.

clusterIP가 없으면 어떻게 될까요? DNS 쿼리 결과가 달라집니다.

일반 서비스의 DNS 쿼리는 서비스의 clusterIP 하나만 반환합니다. 하지만 Headless Service는 모든 Pod의 IP 목록을 반환합니다.

클라이언트가 직접 원하는 Pod를 선택할 수 있습니다. 더 강력한 기능은 StatefulSet과의 조합입니다.

StatefulSet의 Pod는 mysql-0, mysql-1, mysql-2처럼 순차적인 이름을 가집니다. Headless Service와 결합하면 각 Pod에 고유한 DNS 이름이 부여됩니다.

mysql-0.mysql.default.svc.cluster.local 형식으로 특정 Pod에 직접 접근할 수 있습니다. 이것이 데이터베이스 클러스터, 카프카, 엘라스틱서치 같은 스테이트풀 애플리케이션에서 Headless Service를 사용하는 이유입니다.

주의할 점이 있습니다. Headless Service는 로드밸런싱을 하지 않습니다.

클라이언트가 직접 어떤 Pod로 연결할지 결정해야 합니다. 단순히 부하 분산이 목적이라면 일반 서비스를 사용해야 합니다.

김개발 씨는 Headless Service를 적용했습니다. 이제 쓰기는 mysql-0으로, 읽기는 mysql-1과 mysql-2로 명확하게 분리할 수 있게 되었습니다.

실전 팁

💡 - Headless Service는 StatefulSet과 함께 사용할 때 가장 유용합니다

• clusterIP: None을 설정하는 것만으로 Headless Service가 됩니다

---

5. DNS 디버깅 방법

김개발 씨의 서비스가 갑자기 다른 서비스에 연결되지 않습니다. 에러 메시지는 "could not resolve host"입니다.

DNS 문제인 것 같은데, 어디서부터 어떻게 확인해야 할까요?

DNS 문제를 디버깅할 때는 체계적인 접근이 필요합니다. dnsutils Pod를 배포하여 nslookup, dig 명령어로 DNS 해석을 테스트하고, CoreDNS 로그를 확인하며, Pod의 /etc/resolv.conf 설정을 검사합니다.

다음 코드를 살펴봅시다.

# DNS 디버깅용 Pod 생성
kubectl run dnsutils --image=tutum/dnsutils --restart=Never -- sleep infinity

# Pod 안에서 DNS 테스트
kubectl exec -it dnsutils -- nslookup user-service
kubectl exec -it dnsutils -- nslookup user-service.default.svc.cluster.local
kubectl exec -it dnsutils -- nslookup kubernetes.default

# dig 명령어로 상세 정보 확인
kubectl exec -it dnsutils -- dig user-service.default.svc.cluster.local

# Pod의 DNS 설정 확인
kubectl exec -it dnsutils -- cat /etc/resolv.conf

# CoreDNS 로그 확인
kubectl logs -n kube-system -l k8s-app=kube-dns

# CoreDNS Pod 상태 확인
kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide

# 서비스 엔드포인트 확인
kubectl get endpoints user-service

김개발 씨는 월요일 아침부터 장애 알림을 받았습니다. 주문 서비스가 사용자 서비스에 연결되지 않는다는 것입니다.

에러 로그를 보니 "could not resolve host: user-service"라고 적혀 있습니다. DNS 문제는 마치 미로 찾기와 같습니다.

어디서 막혔는지 찾으려면 체계적으로 접근해야 합니다. 박시니어 씨가 첫 번째 단계를 알려주었습니다.

"일단 DNS 테스트용 Pod를 띄워봐." dnsutils 이미지에는 nslookup, dig 같은 DNS 진단 도구가 포함되어 있습니다. 이 Pod를 띄우고 그 안에서 DNS 쿼리를 직접 실행해봅니다.

먼저 nslookup user-service를 실행합니다. 응답이 오지 않거나 에러가 발생하면 DNS 문제가 확실합니다.

정상적으로 IP가 반환되면 다른 곳에 문제가 있는 것입니다. 두 번째 단계는 CoreDNS 상태 확인입니다.

CoreDNS Pod가 정상적으로 실행 중인지 확인합니다. Running 상태가 아니라면 CoreDNS 자체에 문제가 있는 것입니다.

세 번째 단계는 CoreDNS 로그 확인입니다. 로그에서 에러 메시지를 찾습니다.

메모리 부족, 설정 오류 등 다양한 원인이 나타날 수 있습니다. 네 번째 단계는 Pod의 /etc/resolv.conf 확인입니다.

이 파일에는 Pod가 사용하는 DNS 서버 주소가 적혀 있습니다. nameserver 항목이 CoreDNS 서비스 IP를 가리키고 있어야 합니다.

다섯 번째 단계는 서비스와 엔드포인트 확인입니다. 서비스가 존재하는지, 엔드포인트가 제대로 연결되어 있는지 확인합니다.

서비스는 있지만 엔드포인트가 비어있다면 Pod가 제대로 선택되지 않은 것입니다. 김개발 씨는 단계별로 확인해나갔습니다.

CoreDNS Pod가 OOMKilled 상태였습니다. 메모리가 부족해서 죽어있던 것입니다.

메모리 리밋을 늘려주고 CoreDNS를 재시작하자, 모든 것이 정상으로 돌아왔습니다. 체계적인 디버깅 덕분에 빠르게 원인을 찾을 수 있었습니다.

실전 팁

💡 - dnsutils Pod는 DNS 문제 해결의 필수 도구입니다. 항상 클러스터에 하나 띄워두세요

• CoreDNS 로그는 -f 옵션으로 실시간으로 볼 수 있습니다

---

6. 커스텀 DNS 설정

김개발 씨의 회사에서 내부 도메인 서버를 운영하고 있습니다. internal.company.com 같은 회사 내부 도메인은 회사 DNS 서버에서만 해석됩니다.

쿠버네티스 Pod에서 이 도메인에 접근하려면 어떻게 해야 할까요?

dnsConfig를 사용하면 Pod별로 DNS 설정을 커스터마이징할 수 있습니다. 추가 네임서버, 검색 도메인, DNS 옵션을 지정할 수 있습니다.

클러스터 전체 설정이 필요하면 CoreDNS ConfigMap을 수정합니다.

다음 코드를 살펴봅시다.

# Pod별 커스텀 DNS 설정
apiVersion: v1
kind: Pod
metadata:
  name: custom-dns-pod
spec:
  dnsPolicy: ClusterFirst
  dnsConfig:
    nameservers:
    - 10.0.0.10  # 회사 내부 DNS
    searches:
    - internal.company.com
    - company.com
    options:
    - name: ndots
      value: "2"
    - name: timeout
      value: "3"
  containers:
  - name: app
    image: nginx

---
# CoreDNS ConfigMap으로 전체 클러스터 설정
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
        }
        forward . /etc/resolv.conf
        cache 30
    }
    internal.company.com:53 {
        forward . 10.0.0.10
    }

김개발 씨의 회사는 내부 시스템을 많이 운영하고 있습니다. 인사 시스템은 hr.internal.company.com, 재무 시스템은 finance.internal.company.com으로 접근합니다.

이 도메인들은 회사 내부 DNS 서버에서만 해석됩니다. 문제는 쿠버네티스 클러스터의 Pod에서 이 시스템들에 접근해야 한다는 것입니다.

기본 설정으로는 internal.company.com을 찾을 수 없습니다. 박시니어 씨가 두 가지 방법을 알려주었습니다.

"Pod별로 설정할 수도 있고, 클러스터 전체에 적용할 수도 있어." 첫 번째 방법은 dnsConfig를 사용하는 것입니다. Pod 스펙에 dnsConfig를 추가하면 해당 Pod의 DNS 설정을 커스터마이징할 수 있습니다.

nameservers에 추가 DNS 서버를 지정합니다. 회사 내부 DNS 서버 IP를 넣으면 됩니다.

searches에는 검색 도메인을 추가합니다. internal.company.com을 넣으면 hr만 입력해도 hr.internal.company.com을 찾습니다.

options에서는 DNS 동작을 세밀하게 조정할 수 있습니다. ndots는 도메인에 점이 몇 개 있어야 절대 도메인으로 인식할지 결정합니다.

timeout은 DNS 쿼리 타임아웃 시간입니다. 두 번째 방법은 CoreDNS ConfigMap을 수정하는 것입니다.

클러스터의 모든 Pod에 적용되어야 할 때 사용합니다. CoreDNS의 Corefile에 새로운 서버 블록을 추가합니다.

internal.company.com으로 끝나는 도메인은 회사 DNS 서버로 전달하도록 설정합니다. 이렇게 하면 모든 Pod에서 별도 설정 없이 내부 도메인에 접근할 수 있습니다.

주의할 점이 있습니다. CoreDNS ConfigMap을 수정하면 CoreDNS가 자동으로 리로드됩니다.

하지만 잘못된 설정을 넣으면 클러스터 전체의 DNS가 마비될 수 있습니다. 반드시 테스트 환경에서 먼저 확인하세요.

또한 dnsConfig의 nameservers는 최대 3개까지만 지정할 수 있습니다. 쿠버네티스가 이미 클러스터 DNS를 하나 사용하고 있으므로, 실제로 추가할 수 있는 것은 2개입니다.

김개발 씨는 CoreDNS ConfigMap에 회사 DNS 설정을 추가했습니다. 이제 모든 서비스에서 회사 내부 시스템에 자유롭게 접근할 수 있게 되었습니다.

실전 팁

💡 - CoreDNS ConfigMap 수정 전에 반드시 백업을 해두세요

• Pod별 설정은 dnsConfig, 클러스터 전체 설정은 CoreDNS ConfigMap을 사용하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!