Prometheus Operator

Operator Framework

Prometheus Operator를 이야기하기 전에 먼저 Operator Framework가 뭔지 알아보자.

보통 k8s에서 configmap을 수정하면, workload(deployment, statefulset 등)를 재기동해야하는 문제가 있다. 단순히 하나의 설정만 바꾸었음에도 운영중인 환경의 파드를 재배포해야하는 문제가 발생하는데, 상황에 따라서 굉장히 위험한 작업이 될 수 있다. 

 

 CoreOS에서는 이러한 부분을 해소하기 위해 Operator Framework라는 개념을 고안하였고, 이를 통해 설정변경에 민감하지 않은 k8s 환경을 구성할 수 있게하였다. 한 마디로 말하면, 운영중인 application의 설정을 변경하더라도 application을 지속사용 가능하게 만들어준달까..?

 

 여튼 프로메테우스에서는 위의 방법을 사용하여 Prometheus Operator를 만들었다.

 

Prometheus Operator

 기본적으로 Prometheus Operator는 CRD(Custom Resource Definition)에 있는 설정값을 참고하여 운영 중인 프로메테우스에 설정내용을 반영한다. 여기서 CRD란, 쿠버네티스 API에서 특정 종류의 API 오브젝트 모음을 저장하는 엔드포인트이다. 예를 들어 빌트인 파드 리소스에는 파드 오브젝트 모음이 포함되어 있다.

 커스텀 리소스는 쿠버네티스 API의 익스텐션으로, 기본 쿠버네티스 설치에서 반드시 사용할 수 있는 것은 아니다. 이는 특정 쿠버네티스 설치에 수정이 가해졌음을 나타낸다. 간단히 말하자면, yaml의 kind가 ServiceMonitor인 것, configmap인 것 등을 하나의 오브젝트로 묶은 리소스를 의미한다고 보면된다.

 

Prometheus Operator Architecture. Source:  www.nicktriller.com

Prometheus CRD를 설명하기 위한 자료. ref: https://sysdig.com/blog/kubernetes-monitoring-prometheus-operator-part3/

Prometheus Operator는 아래의 리소스들을 참조하여 하나의 리소스(CRD)로 만든다.

• Prometheus: prometheus desired 스케일에 대한 값
• ServiceMonitor: label selector를 통해 scraping 대상에 적용할 설정값을 지정. operator는 이 값을 참조하여 scrape configuration을 가져온다. (사실상 CRD의 핵심은 ServiceMonitor라고 생각해도 될 것 같다)
• PrometheusRule: 프로메테우스 alert이나 record rule에 관련된 값
• Alertmanager: alertmanager의 desired scale에 대한 값

 

 위의 두 그림을 보면 알 수 있듯이, 첫 번째 그림을 통해 Prometheus Operator는 Prometheus Resource, Alertmanager Resource, ServiceMonitor Resource, PrometheusRule Resource를 참고하여 CRD를 만들고 해당 CRD를 프로메테우스에 반영하는 것을 알 수 있고, 두 번째 그림을 통해 해당 CRD는 Dynamic하게 설정이 적용될 수 있다는 것을 알 수 있다.

 

Prometheus Operator를 실제 사용해보면...

Prometheus Operator를 사용해서 좋은 점은, 확장을 위해 Prometheus를 분할하여 관리할 수 있다는 점에 있다. 예를 들어 한 Prometheus는 node-exporter 메트릭과 같은 인프라 메트릭을 수집하고 다른 Prometheus는 사용자 지정 애플리케이션의 메트릭을 담당 할 수 있다. 

 이 외에도 Prometheus Operator를 사용하면 팀당 하나의 Prometheus를 사용할 수 있게 할 수 있고, Prometheus configuration을 여러 인스턴스에 커스텀하여 적용하기 위해 드는 시간도 줄일 수 있다.