본 콘텐츠는 coredns와 coredns 모니터링에 대한 내용을 다룹니다.
- coredns에 대한 이해
기본적으로 kubedns는 Kubernetes용 SkyDNS 구현체로, coredns는 kubedns의 보완할 리소스로 처음 등장하게 되었습니다. CoreDNS는 인터넷 도메인 이름에 대한 요청을 해결하고 Kubernetes 클러스터 내에서 서비스 검색을 제공할 수 있는 오픈 소스 DNS 서버입니다. Kubernetes 클러스터에서 플러그인은 기본적으로 활성화되어 있으므로 클러스터를 시작하자마자 많은 주요 메트릭을 모니터링할 수 있습니다 .
기본적으로 각 coredns 파드는 prometheus 플러그인을 사용하여 자체 엔드포인트를 오픈하고 있습니다. 포트는 9153번을 사용하고 있습니다. 해당 내용은 다음과 같이 coredns 파드에 질의하여 해당 로그를 확인할 수 있습니다.
curl -X GET $(kubectl get pods -l k8s-app=kube-dns -n kube-system -o jsonpath='{.items[0].status.podIP}'):9153/metrics
2. coredns의 동작
클러스터 내부 요청
파드는 도메인 이름을 사용해 lookup.ecommerce.svc.cluster.local의 서비스 주소를 확인하고, CoreDNS는 IP주소를 제공합니다.
이 경우 클러스터 내 서비스 주소를 알고 있기 때문에 권한 있는 주소를 반환할 수 있습니다.
인터넷 도메인 요청
하지만, www.shopist.io에 대한 요청에 대해서 CoreDNS가 직접 처리가 불가능합니다.
왜냐하면 해당 도메인을 다른 DNS 서버가 관리하고 있기 때문입니다.
그래서 요청이 오더라도 CoreDNS는 해당 최종 IP 주소를 캐싱하고 있지 않기 때문에 CoreDNS는 upstream DNS 서버(예제와 같은 8.8.8.8)로 요청을 전달합니다. 그리고 nameserver.shopist.io에서 권한 있는 응답을 받아 다운스트림으로 요청을 처리합니다. 이후, 마찬가지로 CoreDNS 자체에서는 도메인에 대한 권한이 없으므로 클라이언트에 198.51.100.0을 전달하며, 이 응답은 권한 없는 응답이 됩니다.
서비스에 대한 생성 / 수정 / 삭제시 Kubernetes API를 통해서 해당 내용을 감지합니다.
이때 파드는 DNS 클라이언트의 역할을 하며, 통신할 DNS 서버에 대한 내용은 resolve.conf 파일에 지정되어 있습니다.
웹 애플리케이션이 DNS를 찾는 방법의 경우, Pod 컨테이너의 /etc/resolv.conf 파일의 DNS 서버 주소는 10.100.0.10으로 등록되어 있습니다.
nameserver 10.100.0.10
search ecommerce.svc.cluster.local svc.cluster.local cluster.local ec2.internal
options ndots:5
search 구문은 Cluster IP 위치에 대한 키워드로, 도메인 검색 실패시 ecommerce.svc.cluster.local → svc.cluster.local → cluster.local → ec2.internal 순서대로 질의를 진행합니다.
ndots 구문의 경우, 도메인 이름에 점이 5개 미만일 경우 search 구문을 붙여서 조회를 시도합니다.
(ndots: 5, 해당 설정 설정은 DNS 조회 시 도메인 이름에 점(.)이 5개 이상 있어야만 FQDN(정규화된 도메인 이름)으로 간주하게 함.)
다만, ndots가 높은 수로 설정되어 있을 경우, 위의 resolv.conf에 기술된 내용대로
shopist.io.ecommerce.svc.cluster.local <= NXDomain
shopist.io.svc.cluster.local <= NXDomain
shopist.io.cluster.local <= NXDomain
shopist.io.us-west-2.compute.internal <= NXDomain
shopist.io <= NoERROR
에서 a,b,c,d는 NXDomain (도메인 없음) 출력 후 e에서 NOError를 출력하면서 성공했다는 내용을 출력하게 됩니다. 보통은 ndots를 1,2를 권장하며, 정확한 FQDN 제공이 가능하다면 해당 내용을 설정 후 가비지 도메인에 대한 쿼리 수집을 중단하여 요청량 자체를 다음 이미지와 같이 줄일 수 있습니다.
- 주요하게 확인할 메트릭
먼저, 데이터독을 활용한 Error / Latency 설정의 경우는 다음과 같습니다.
(찾다보니 coredns 관련은 grafana 혹은 newrelic에서 조금 더 자세한 내용을 다루고 있는 것으로 확인됩니다.)
a. Error
- 전체 트래픽은 높은데 cache hit 낮은 경우, ttl을 늘려 캐시를 오래 들고 있을 수 있도록 수정해야 합니다.
- response_code_count의 경우 에러 발생시 생김,
NxDomain, FormErr, ServFail, Refused 등과 같은 여러 가지 오류들이 있는데 ServFail의 경우 서비스 / 클러스터에 치명적일 수 있으므로 확인이 필요합니다.
b. Latency (Request Latency)
- sum:coredns.request_duration.seconds.sum{kube_cluster_name:xpert-dev-cluster} / sum:coredns.request_duration.seconds.count{kube_cluster_name:xpert-dev-cluster}
대기 시간이 길거나 시간이 지남에 따라 증가하는 경우 부하 문제를 나타낼 수 있습니다. CoreDNS 인스턴스가 오버로드되면 DNS 이름 확인에 문제가 발생할 수 있으며 애플리케이션 및 Kubernetes 내부 서비스에서 지연 또는 중단이 발생할 수 있습니다.
- 문제시 해결 / 로그 확인 :
- coredns 포드 동작 확인
kubectl get service kube-dns -n kube-system
kubectl -n kube-system get endpoints kube-dns
- 엔드포인트 목록이 비어 있으면 CoreDNS 포드에서 포드 상태 확인
- 보안 그룹이나 네트워크 액세스 제어 목록(네트워크 ACL)이 포드를 차단하는지 확인
kube-proxy 포드 동작 확인
kubectl logs -n kube-system --selector 'k8s-app=kube-proxy'
CoreDNS 포드의 CPU 사용률 확인
$ kubectl exec -it your-pod-name -- sh
클러스터 ip (10.100.0.10)가 resolv.conf에 있는지 확인
cat /etc/resolv.conf
nameserver 10.100.0.10
search default.svc.cluster.local svc.cluster.local cluster.local ec2.internal
options ndots:5
내부 도메인 질의 가능 여부 확인
nslookup kubernetes.default 10.100.0.10
외부 도메인 질의 가능 여부 확인
nslookup amazon.com 10.100.0.10
coredns 파드의 상세 동작 확인
kubectl -n kube-system edit configmap coredns
로그 문자열 추가 - 하기 스니펫에서 log 추가
kind: ConfigMap
apiVersion: v1
data:
Corefile: |
.:53 {
log # Enabling CoreDNS Logging
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
}
...
...
로그 실패 혹은 히트 확인은 다음 명령어를 수행하여 확인할 수 있습니다.
kubectl logs --follow -n kube-system --selector 'k8s-app=kube-dns'
'DevOps > Observability' 카테고리의 다른 글
[Datadog] RabbitMQ Integration (3) | 2024.11.10 |
---|---|
[Datadog] RabbitMQ의 주요 메트릭 (10) | 2024.11.09 |
Rabbit MQ on Datadog (2) | 2024.11.08 |