EKS Fargate CoreDNS 와 Logging Architecture

 

CoreDNS

CoreDNS는 Kubernetes 클러스터에서 핵심적인 역할을 수행한다.

이는 클러스터 내의 서비스와 파드 간의 통신을 관리하며, DNS 쿼리를 처리하여 서비스 디스커버리를 제공한다.

또한, 클러스터의 크기에 관계없이 확장 가능하며, 대규모 클러스터에서도 안정적으로 동작한다.

이는 애플리케이션의 확장성과 안정성을 보장하고 더불어 CoreDNS는 다양한 플러그인을 지원하여 사용자가 필요에 따라 DNS 기능을 확장할 수 있다.

이는 클러스터의 특정 요구 사항에 맞춰 DNS 구성을 조정할 수 있게 하며, 더욱 유연한 운영을 가능케 한다.

CoreDNS의 이러한 역할과 기능을 이해하는 것은 Kubernetes 클러스터의 네트워크 관리와 애플리케이션 배포에 있어서 중요한 역할을 할 수 있도록 도와준다.

EKS Logging 

 

로그를 CloudWatch나 Datadog과 같은 로깅 솔루션으로 따로 보내는 것에는 여러 가지 장점이 있다.

먼저, 이러한 로깅 솔루션은 로그 데이터를 중앙 집중식으로 수집하여 관리하므로, 다양한 서비스나 클러스터에서 발생하는 로그를 한 곳에서 통합적으로 관리할 수 있다. 

또한, 로깅 솔루션은 고급 검색 및 필터링 기능을 제공하여 로그 데이터를 신속하게 검색하고 분석할 수 있다. 

뿐만 아니라, 로깅 솔루션은 대용량의 로그 데이터를 안정적으로 처리하고 저장할 수 있어 대규모 환경에서도 안정적으로 로그를 관리할 수 있다.

마지막으로, 로깅 솔루션은 보안 및 규정 준수를 위한 다양한 기능을 제공하여 로그의 기밀성과 무결성을 보호하여 데이터의 안전한 보관과 접근 제어를 보장하여 보안 요구 사항을 충족시킬 수 있다.

따라서 로깅 솔루션으로 로그를 따로 관리하는 것은 로그 관리 및 분석을 효율적으로 수행하고, 시스템의 안정성과 보안을 강화하는 데 큰 장점을 제공한다.

kubectl logs <POD_NAME>으로 나오던 Application Log 들을 AWS CloudWatch로 추출한다.

logging을 구성하기 전 EKS Fargate로 구성하기 때문에 추가 세팅이 필요하다.

기본적으로 EKS 클러스터를 구성하면 kube-system namespace에 CoreDNS의 구성 요소들이 있다.

Docs 에는 CoreDNS는  “ k8s 클러스터 DNS로 사용할 수 있는 유연하고 확장 가능한 DNS 서버 ”라고 나와있다.

kubectl 명령은 기본적으로 Control Plane의 Cloud Provider API를 거쳐 kube-apiserver와 REST Call 형태로 요청을 받아 node와 pod로 명령을 던져준다.

kube-apiserver , kube-scheduler 등 내부 통신 자체를 Private DNS로 하는 듯한 느낌이 있어

새로운 service, pod들이 등록될 시 해당 내용을 CoreDNS에 업데이트하는 형식이다.

 

pod는 기본적으로 DNS 질의 시 kube-dnskube-dns를 찾고 pod 내부의 /etc/resolv.conf를 보면 kube-dnskube-dns의 Cluster-IP 가 있다.

 

kube-system namespace의 kube-dns Cluster-IP와 동일하다.

Kubernetes 구성 요소들을 봤을 때 플로우는 kube-apiserver에서 바로 node, pod 들에 접근하는 것처럼 표현했지만 중간에 kube-system namespace의 kube-dns와 CoreDNS를 거쳐 통신하게 된다.

 

자세히 살펴보면 kube-dns의 selector는 k8s-app=kube-dns로 명시되어 있고 service Cluster IP로 요청을 한다.

 

 

kube-dns는 CoreDNS 2개 pod를 endpoint로 잡고 있다.

 

결론적으로, 내/외부 요청 시 아래 플로우로 흐르게 된다.

 

💡 Application Pod ↔ kube-dns service ↔ CoreDNS Pod ↔ kube-apiserver

---

Kubernetes 로깅 아키텍처

 

Kubernetes 로깅 아키텍처는 크게 노드 수준 로깅, 클러스터 수준 로깅으로 나뉜다.

SaaS 서비스를 멋지게 구축하기 위해 이런 멋진 선언문 하나는 읽어줘야 제 맛이다.

이 멋진 선언문에 의하면 컨테이너화된 애플리케이션의 로그는 stdout 및 stderr로 출력해야 한다고 나와있다.

The Twelve-Factor App

The Twelve-Factor App

 

노드 수준 로깅

k logs <Pod_Name>

• kubectl을 사용해서 Pod의 로그를 가져오는 수준
• logrotate 기능은 k8s 자체적으로 지원하지 않지만 Fluent Bit에 해당 기능이 있다.

 

클러스터 수준 로깅

노드 로깅 에이전트

• 로깅 에이전트는 모든 노드에서 실행해야 하기 때문에 에이전트는 DaemonSet으로 실행
• Fargate 에선 사용할 수 없음
• EC2 Node를 통해 CloudWatch Agent를 설치하는 등의 방식으로 볼 수 있음

 

스트리밍 사이드카 컨테이너

• Application의 여러 부분에서 여러 로그 스트림을 분리할 수 있다.
• Pod는 단일 컨테이너를 실행하고 컨테이너는 서로 다른 2 가지 형식을 사용하여 2 개의 서로 다른 로그 파일에 쓴다.
• 로그 파일을 읽는다는 거 자체가 구버전 같음

 

로깅 에이전트가 있는 사이드카 컨테이너

노드 수준의 로깅 에이전트가 유연하지 못할 경우 각 애플리케이션과 함께 사용

 

애플리케이션에서 직접 로그 노출

• 모든 애플리케이션에서 직접 로그를 노출하거나 푸시하는 로깅은 k8s의 범위를 벗어난다.

동일하게 3번으로 가져갈 것 같고 다만 아직까지 찾아본 바로는 EKS Fluent Bit에서 바로 Datadog으로 전송할 수 없어 Forwarder를 사용해야 한다.

하지만 Cloudwatch 비용이 중복되어 사용하기 까다롭고 위 FB output.conf 에 나온 것처럼 AWS FireHose로 보낸 후 Datadog으로 보내는 것이 효율적인 방법일 것 같다.