DNS 서비스 사용자 정의하기
DNS 서비스 사용자 정의하기 (Customizing DNS Service)
이 페이지는 클러스터에서 DNS Pod를 구성하고 DNS 해석 과정을 사용자 정의하는 방법을 설명해요.
출처: 문서
본문
시작하기 전에 (Before you begin)
쿠버네티스 클러스터가 필요하고, kubectl 명령줄 도구가 클러스터와 통신하도록 구성돼 있어야 해요. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 두 개 이상 있는 클러스터에서 실행하는 것을 권장해요. 아직 클러스터가 없다면 minikube로 만들거나 다음 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있어요.
- iximiuz Labs
- Killercoda
- KodeKloud
클러스터가 CoreDNS 애드온을 실행 중이어야 해요. 쿠버네티스 서버가 최소 v1.12 버전이어야 해요. 버전을 확인하려면 kubectl version을 입력하세요.
소개 (Introduction)
DNS는 addon manager 클러스터 애드온을 사용해 자동으로 시작되는 내장 쿠버네티스 서비스예요.
참고: CoreDNS Service는
metadata.name필드에kube-dns라는 이름을 가져요. 이는 레거시kube-dnsService 이름에 의존하던 워크로드와의 더 큰 상호운용성을 보장하기 위한 의도예요.kube-dns라는 Service를 사용하면 그 공통 이름 뒤에서 실행되는 DNS 제공자가 무엇인지라는 구현 세부 사항을 추상화해요.
CoreDNS를 Deployment로 실행한다면, 보통 정적 IP 주소를 가진 쿠버네티스 Service로 노출돼요. kubelet은 --cluster-dns=<dns-service-ip> 플래그로 각 컨테이너에 DNS 해석기 정보를 전달해요.
DNS 이름에는 도메인도 필요해요. kubelet에 --cluster-domain=<default-local-domain> 플래그로 로컬 도메인을 구성해요.
DNS 서버는 정방향 조회(A와 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원해요. 자세한 내용은 Service와 Pod용 DNS를 참고하세요.
파드의 dnsPolicy가 default로 설정되면, 파드가 실행되는 노드의 이름 해석 구성을 상속해요. 파드의 DNS 해석은 노드와 동일하게 동작해야 해요. 알려진 문제(Known issues)를 참고하세요.
이런 동작을 원하지 않거나 파드에 다른 DNS 구성을 원한다면 kubelet의 --resolv-conf 플래그를 사용할 수 있어요. 이 플래그를 ""로 설정하면 파드가 DNS를 상속하지 않도록 방지돼요. 유효한 파일 경로로 설정하면 DNS 상속을 위해 /etc/resolv.conf 외의 파일을 지정할 수 있어요.
CoreDNS
CoreDNS는 클러스터 DNS로 사용될 수 있는 범용 권위 있는(authoritative) DNS 서버로, DNS 사양을 준수해요.
CoreDNS ConfigMap 옵션 (CoreDNS ConfigMap options)
CoreDNS는 모듈식이고 플러그 가능한 DNS 서버로, 플러그인이 새 기능을 추가해요. CoreDNS 서버는 CoreDNS 구성 파일인 Corefile을 유지 관리하여 구성할 수 있어요. 클러스터 관리자는 CoreDNS Corefile의 ConfigMap을 수정해 그 클러스터의 DNS 서비스 발견이 동작하는 방식을 변경할 수 있어요.
쿠버네티스에서 CoreDNS는 다음 기본 Corefile 구성으로 설치돼요.
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
Corefile 구성은 다음 CoreDNS 플러그인을 포함해요.
- errors: 오류가 stdout에 기록돼요.
- health: CoreDNS의 상태가
http://localhost:8080/health에 보고돼요. 이 확장 구문에서lameduck은 프로세스를 unhealthy하게 만든 뒤 프로세스가 종료되기 전에 5초를 기다려요. - ready: 준비 상태를 알릴 수 있는 모든 플러그인이 이를 끝냈을 때 포트 8181의 HTTP 엔드포인트가 200 OK를 반환해요.
- kubernetes: CoreDNS가 Services와 Pods의 IP를 기반으로 DNS 쿼리에 응답해요. 이 플러그인에 대한 자세한 내용은 CoreDNS 웹사이트에서 확인할 수 있어요.
ttl은 응답에 대한 커스텀 TTL을 설정할 수 있게 해 줘요. 기본값은 5초예요. 허용되는 최소 TTL은 0초이고 최대는 3600초로 제한돼요. TTL을 0으로 설정하면 레코드가 캐시되지 않도록 방지해요.pods insecure옵션은kube-dns와의 하위 호환성을 위해 제공돼요.pods verified옵션을 사용할 수 있는데, 같은 네임스페이스에 일치하는 IP의 파드가 존재할 때만 A 레코드를 반환해요.- 파드 레코드를 사용하지 않는다면
pods disabled옵션을 사용할 수 있어요.
- prometheus: CoreDNS의 메트릭이 Prometheus 형식(OpenMetrics라고도 함)으로
http://localhost:9153/metrics에서 사용 가능해요. - forward: 쿠버네티스 클러스터 도메인 내에 있지 않은 쿼리는 미리 정의된 해석기(/etc/resolv.conf)로 전달돼요.
- cache: 프론트엔드 캐시를 활성화해요.
- loop: 단순 전달 루프를 감지하고, 루프가 발견되면 CoreDNS 프로세스를 중지해요.
- reload: 변경된 Corefile의 자동 재로드를 허용해요. ConfigMap 구성을 편집한 뒤 변경 사항이 적용되도록 2분을 허용하세요.
- loadbalance: 응답에서 A, AAAA, MX 레코드의 순서를 무작위화하는 라운드 로빈 DNS 로드밸런서예요.
ConfigMap을 수정해 기본 CoreDNS 동작을 변경할 수 있어요.
CoreDNS로 스텁 도메인과 업스트림 네임서버 구성하기 (Configuration of Stub-domain and upstream nameserver using CoreDNS)
CoreDNS는 forward 플러그인을 사용해 스텁 도메인(stub-domain)과 업스트림 네임서버를 구성할 수 있는 능력이 있어요.
예시 (Example)
클러스터 운영자가 "10.150.0.1"에 있는 Consul 도메인 서버를 가지고 있고, 모든 Consul 이름의 접미사가 ".consul.local"이라고 해 보죠. CoreDNS에서 이를 구성하려면 클러스터 관리자가 CoreDNS ConfigMap에 다음 스탠자를 만듭니다.
consul.local:53 {
errors
cache 30
forward . 10.150.0.1
}
모든 비클러스터 DNS 조회가 172.16.0.1의 특정 네임서버를 통해 가도록 명시적으로 강제하려면 forward를 /etc/resolv.conf 대신 그 네임서버를 가리키게 하세요.
forward . 172.16.0.1
기본 Corefile 구성과 함께 최종 ConfigMap은 다음과 같아요.
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . 172.16.0.1
cache 30
loop
reload
loadbalance
}
consul.local:53 {
errors
cache 30
forward . 10.150.0.1
}
참고: CoreDNS는 스텁 도메인과 네임서버에 대한 FQDN(예: "ns.foo.com")을 지원하지 않아요. 번역 중에 모든 FQDN 네임서버는 CoreDNS 구성에서 생략돼요.
다음 단계 (What's next)
- DNS 해석 디버깅 읽기