Pod design pattern - prometheus exporter (질문에 대한 의문)

글 쓰는 계기

오늘은 AWS의 모든 것 단톡방을 보다가 한 분이 남긴 질문에 대한 답을 찾다가 내가 공부하게 되어 기록을 남기려고 끄적이고 있다.

ECS도 쿠버네티스처럼 클러스터가 있고 클러스터 내에서 컨테이너가 돌아가기 때문에 쿠버네티스 책에서 배운 내용이 문득 떠올랐다. 파드 디자인 패턴의 하나로 exporter가 들어오는 것이 기억이 났고 그 때문에 책의 내용을 인용하여 질문에 대해 답을 남겨줬다.

![]

쿠버네티스에서 파드 디자인 패턴은 총 3가지로 exporter는 어댑터패턴으로 리소스가 생성 된다.

이전 시간에 연습삼아 prometheus와 grafana 세팅을 한 경험에서 리소스가 생성된 것을 하나하나 유심히 봤는데 그 중에
blackbox 옵저빙 형태로 클러스터 내 CPU 성능, 디스크 공간, 메모리 사용량 등을 체크하는 방식이다.

https://devops.com/black-box-vs-white-box-monitoring-what-you-need-to-know/

다음 질문이 연달아 들어왔다. 나 아직 잘 모르는데... ㅠㅠ 근데 생각해보니 부트캠프 마지막 프로젝트 때 eks상의 aws ingress controller 설치하고 설치확인하는 과정에서 CLI 친 것이 문득 떠올랐다. 그리고 쿠버네티스 개념공부를 하기위해 산 책에서 Namespace간 차이를 설명한 내용이 적힌 부분이 떠올랐고 엄연히 ingress는 파드가 아닌 것을 생각했을 때 파드 디자인패턴으로는 설명할 수 없다고 생각했고 이 부분에 대해 자세히 알아봤다.

쿠버네티스 완벽 가이드 책 100page에 보면 네임스페이스로 가상적인 클러스터 분리 챕터의 내용을 간략하게 보고가자.

• kube-system: 쿠버네티스 클러스터 구성 요소와 애드온이 배포될 네임스페이스
• kube-public: 모든 사용자가 사용할 수 있는 컨피그맵 등을 배치하는 네임스페이스
• kube-node-lease 노드 하트비트 정보가 저장된 네임스페이스
• default: 기본 네임스페이스

kubectl get deployment -n kube-system aws-load-balancer-controller

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-controller   2/2     2            2           84s

위 cli는 aws ingress controller 설치확인하는 명령어이다.
참고 https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/aws-load-balancer-controller.html

앰버서더 패턴에 대한 설명으로 들 수 있는 예시가 뭐가 있을까라는 생각과 함께 efk구성이 떠올랐다. 이 때 Fluentd가 앰버서더 역할로 로그를 깔끔하게 정리하는 느낌인가 ? 라는 내 자신에게 의문을 남겼다. 하지만 Fluentd는 sidecar 형태로 붙는다. 지금 생각해보니 Argo CD 도 sidecar로 붙겠구나 ㅎㅎ...
https://argo-cd.readthedocs.io/en/stable/core_concepts/

결론

aws-ingress-controller는 kube-system으로 클러스터 구성요소다.
마지막 프로젝트에서 Argo CD 사용할 때 생긴 의문을 개념적으로 이해하는 시간을 가졌다.
blackbox vs whitebox 옵저버에 대한 내용도 다시금 복기할 수 있었다.
질문남겨준 분들에게 감사하게 생각하고 글을 마무리합니다.