목 차
0. CoreDNS란?
CoreDNS는 Kubernetes 클러스터 내에서 서비스 디스커버리(DNS 기반) 기능을 제공하는 핵심 컴포넌트입니다. Kubernetes에서 각 Pod는 고정된 IP가 없고, 동적으로 할당되기 때문에 서비스 간 통신을 위해서는 이름 기반의 접근 방식이 필요합니다. 이때 CoreDNS는 클러스터 내부에서 DNS 요청을 처리하여, 서비스명으로 Pod나 ClusterIP를 조회할 수 있도록 돕습니다.
CoreDNS는 기본적으로 kube-system 네임스페이스에 Deployment
리소스로 배포되며, 서비스명은 kube-dns
또는 coredns
입니다. 일반적으로 Kubernetes 클러스터를 설치할 때 자동으로 포함되며, ConfigMap
을 통해 동작 방식을 설정할 수 있습니다. 이 설정 파일은 Corefile
이라는 이름으로 불리며, 플러그인 기반 구조로 동작을 구성합니다.
예를 들어, 클러스터 내부 DNS 요청을 처리하고 외부 DNS 요청은 Google DNS로 포워딩하는 기본적인 Corefile 설정은 다음과 같습니다:
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
fallthrough in-addr.arpa ip6.arpa
}
forward . 8.8.8.8 1.1.1.1
cache 30
loop
reload
}
CoreDNS는 다음과 같은 아키텍처로 작동합니다:
- 클러스터 내부의 모든 Pod는 /etc/resolv.conf 파일을 통해 CoreDNS로 DNS 요청을 보냅니다.
- CoreDNS는 서비스명, 네임스페이스 등을 기반으로 클러스터 내부 자원을 해석합니다.
- 해당 도메인이 클러스터 외부일 경우, forward 플러그인을 이용해 외부 DNS 서버로 요청을 전달합니다.
이처럼 CoreDNS는 Kubernetes 네트워크 구조의 중심에서 중요한 역할을 하며, 설정 파일만으로 유연하게 동작 방식을 정의할 수 있다는 점에서 운영의 핵심 요소로 자리 잡고 있습니다. 다음 절에서는 coreDNS의 BP사례 8가지를 소개합니다.
1. 외부 DNS 서버를 다중으로 설정하세요
CoreDNS는 외부 도메인 질의를 처리할 때 forward
플러그인을 통해 지정된 외부 DNS 서버로 요청을 전달합니다. 이때 단일 DNS 서버만 지정하면, 해당 서버가 일시적으로 응답하지 않거나 네트워크 장애가 발생했을 때 전체 DNS 쿼리가 실패할 수 있습니다. 장애 허용성을 높이기 위해 다중 DNS 서버를 설정하는 것이 필수입니다. Google의 8.8.8.8, Cloudflare의 1.1.1.1 같은 공용 DNS 서버를 함께 사용하는 것이 일반적입니다.
예를 들어 CoreDNS의 ConfigMap을 다음과 같이 설정합니다:
.:
53 {
forward . 8.8.8.8 1.1.1.1 9.9.9.9
cache 30
loop
reload
loadbalance
}
이 설정을 통해 CoreDNS는 첫 번째 DNS 서버가 응답하지 않으면 다음 DNS 서버로 자동으로 요청을 전달하며, 서비스 연속성을 보장할 수 있습니다. 특히 DNS 응답 지연이 발생하는 환경에서는 반드시 이 설정을 고려해야 합니다.
2. cache 플러그인으로 응답 지연을 줄이세요
CoreDNS는 기본적으로 외부 DNS 응답을 처리할 때마다 새롭게 요청을 수행합니다. 그러나 동일한 도메인에 대해 반복적인 요청이 많다면 이는 응답 지연의 원인이 됩니다. 이를 해결하는 방법이 바로 cache
플러그인을 사용하는 것입니다. 이 플러그인은 응답 결과를 메모리에 일정 시간 저장해 두었다가 동일 요청이 들어오면 즉시 반환합니다.
아래는 cache 플러그인을 활성화한 예시입니다:
cache 300
위 설정은 300초 동안 DNS 응답을 저장합니다. 이 설정은 응답 속도를 크게 향상시키고 외부 DNS 요청 횟수를 줄여 네트워크 부하를 감소시킵니다. 하지만 TTL을 너무 길게 설정하면 변경 사항이 반영되지 않을 수 있으므로 적절한 균형이 필요합니다.
3. CoreDNS 리소스 요청과 제한을 명확히 지정하세요
CoreDNS는 경량 DNS 서버이지만, 클러스터 크기와 질의량이 증가하면 메모리 부족이나 CPU 과부하로 인해 장애가 발생할 수 있습니다. 이러한 상황을 방지하려면 Pod의 리소스를 명확하게 정의하는 것이 중요합니다. Kubernetes에서는 resources.requests
와 resources.limits
를 사용하여 이를 설정할 수 있습니다.
예시:
resources:
requests:
memory: "70Mi"
cpu: "100m"
limits:
memory: "170Mi"
cpu: "250m"
위 설정은 CoreDNS에 최소 메모리 70Mi, 최대 170Mi를 할당합니다. 과도한 리소스 할당은 다른 워크로드에 영향을 줄 수 있으므로, 모니터링 기반으로 점진적으로 튜닝하는 것이 좋습니다.
4. 클러스터 노드 수에 따라 CoreDNS 레플리카 수를 조정하세요
CoreDNS는 Deployment 형태로 배포되기 때문에 기본적으로 2개의 레플리카로 구성되어 있습니다. 하지만 노드 수가 많거나 DNS 요청이 빈번한 대형 클러스터에서는 이 수치가 부족할 수 있습니다. Replica 수를 늘려 병렬 처리를 늘리는 것이 안정적인 운영의 핵심입니다.
예를 들어 다음 명령어로 레플리카 수를 3개로 조정할 수 있습니다:
kubectl scale deployment coredns --replicas=3 -n kube-system
또한 Horizontal Pod Autoscaler(HPA)를 적용해 자동 확장 기능을 도입하면 트래픽 변화에 유연하게 대응할 수 있습니다.
5. loop 플러그인으로 DNS 루프를 감지하세요
CoreDNS가 자체 IP나 잘못된 내부 DNS를 참조하는 구조에서는 무한 DNS 요청 루프가 발생할 수 있습니다. 이런 루프는 CPU 사용률 급증, Pod 재시작 등을 유발하므로 반드시 방지해야 합니다. loop
플러그인은 이러한 상황을 자동으로 감지하고 로그로 경고를 출력합니다.
ConfigMap 내에 다음과 같이 loop 플러그인을 포함시키세요:
loop
DNS 루프가 감지되면 CoreDNS 로그에 아래와 같은 메시지가 출력됩니다:
plugin/loop: Loop detected for zone "."
이 메시지를 통해 원인을 추적하고, 외부 DNS 설정이나 resolv.conf 설정을 수정해야 합니다.
6. 운영 환경에서는 log 대신 errors 플러그인을 사용하세요
모든 DNS 요청을 기록하는 log
플러그인은 개발 환경에서 유용하지만, 운영 환경에서는 부하를 증가시키고 디스크를 빠르게 채울 수 있습니다. 대신 errors
플러그인을 사용하면 실제 장애 상황만 로그로 남겨 운영 리소스를 효율적으로 사용할 수 있습니다.
추천 설정:
errors
# log (운영 환경에서는 주석 처리 또는 삭제)
이렇게 설정하면 CoreDNS는 5xx 오류 등 문제 상황에 대한 정보만 기록하여, 문제 발생 시에만 로그를 조회하면 됩니다.
7. ready 플러그인으로 안정적인 Liveness Probe를 구성하세요
Kubernetes의 kubelet은 CoreDNS가 서비스 준비 상태인지 확인하기 위해 Liveness/Readiness Probe를 사용합니다. ready
플러그인을 활성화하면 CoreDNS가 요청을 처리할 준비가 되었을 때만 프로브에 응답하도록 설정할 수 있습니다.
ConfigMap 내에 다음과 같이 설정합니다:
ready
이 플러그인을 사용하면 CoreDNS Pod가 준비되지 않았을 때도 트래픽을 받는 상황을 방지할 수 있습니다. 특히 클러스터 부팅 시 안정성 확보에 중요한 역할을 합니다.
8. Prometheus를 통한 CoreDNS 모니터링을 구성하세요
CoreDNS는 기본적으로 /metrics
엔드포인트를 통해 Prometheus 형식의 메트릭 데이터를 제공합니다. 이를 통해 DNS 질의 수, 실패율, 캐시 히트율 등의 운영 지표를 수집할 수 있으며, 문제 발생 전 징후를 사전에 파악할 수 있습니다.
Prometheus 설정 예시:
- job_name: 'coredns'
static_configs:
- targets: [':9153']
또한 Grafana와 연동해 시각화 대시보드를 구성하면 DNS 운영 상태를 실시간으로 모니터링할 수 있어, 장애 대응 시간을 단축할 수 있습니다.
'쿠버네티스' 카테고리의 다른 글
Kubernetes에서 노드 삭제 시 발생하는 서비스 지연 현상 (0) | 2025.04.14 |
---|---|
Kubernetes에서 L7 Load Balancer와 Ingress Controller로 SSL Offloading 설정하는 방법 (0) | 2025.04.04 |
pause image 총 정리 - failed to pull image "registry.k8s.io/pause:3.9" (0) | 2025.04.02 |
Kubernetes에서 Object Storage 사용하는 법: S3 연동부터 코드 예시까지 (0) | 2025.03.25 |
Kubernetes Multi Cluster (0) | 2025.03.24 |