[Observability] 쿠버네티스 클러스터 속의 Prometheus Operator

 

앞서 Prometheus와 Exporter 아키텍처를 구축해보면서 node-exporter를 통해 메트릭을 가져오는 것을 알 수 있었다.

prometheus 설정파일에 exporter의 정보를 추가하면서, Prometheus가 Scraping할 대상을 등록했었다.

[Observability] Prometheus & Grafana 연동

 

그렇다면 쿠버네티스 환경에서는 어떨까?

쿠버네티스 환경에서도 마찬가지로 Prometheus를 직접 배포해서 메트릭을 수집하려면, 보통 Configmap으로 관리되는 prometheus.yml 파일에 수집(Scraping) 대상을 직접 추가해주어야할 것이다. 

 

하지만 이러한 포인트가 쿠버네티스 클러스터 환경에서는 그리 좋지못한 단점으로 작용된다.

• 확장성의 한계
  • 서비스가 증가하거나 확장될때마다 설정파일을 직접 수정해줘야한다.
    서비스의 구성 변경이 잦은 쿠버네티스 환경에서는 관리에 대한 오버헤드가 증가하게 될 것이다.
    (수정 과정 속에서 휴먼 에러가 발생할 가능성도 다분하다)
• 무중단 적용의 어려움
  • 설정을 바꿀 때마다 변경분을 적용하기 위해 Prometheus 서버를 재시작해줘야한다.
    이러한 과정 속에서 모니터링에 공백 타임이 발생할 수 밖에 없다.

 

이렇게 전통적인 방식으로 클러스터 내에서 Prometheus를 운영하면, 전체 서비스 모니터링 부분에 큰 영향을 주게 된다.

 

 

Prometheus Operator

쿠버네티스 클러스터 환경에서 Custom Resource를 활용해 Prometheus를 자동으로 간편하게 관리하고 구성을 돕는 도구

'자동'과 '선언적'에 초점을 맞춘 쿠버네티스 환경에 적합하게 매번 설정파일을 변경하는 대신, 쿠버네티스의 커스텀 리소스(CR/CRD)를 통해 설정을 선언한다.

그리고 이 설정을 자동으로 해석하며 Prometheus 서버를 구축하는 매커니즘으로 동작한다.

구성 컴포넌트

Prometheus Operator를 통해 Prometheus 코어 서버뿐만 아니라 AlertManager, Grafana와 같은 관련된 컴포넌트들도 함께 설치하고 관리할 수 있다.

 

Operator는 아래와 같은 대표적인 CRD를 중점으로 Prometheus 서버를 구동시킨다.

 

1. Prometheus
   • Prometheus 서버를 deployment로 선언한 CRD [Prometheus 코어 서버]
2. Alertmanager
   • AlertManager 서버를 deployment를 선언한 CRD
3. Probe
   • 정적인 타겟(외부URL 등)을 대상으로 한 스크래핑 설정, 타겟에 요청을 보내고 그 결과를 메트릭으로 변환
4. ServiceMonitor / PodMonitor
   • 서비스와 파드를 대상으로 한 스크래핑 설정, Prometheus가 스크래핑 작업을 수행할 타깃

 

GitHub - prometheus-operator/prometheus-operator: Prometheus Operator creates/configures/manages Prometheus clusters atop Kubern

 

Operator의 특징

자동/선언적인 설정 관리

본래 Prometheus에서는 Scraping할 대상을 새로 추가하려면, 설정파일에 타깃 정보를 추가함으로써 이루어진다.

Prometheus Operator에서는 ServiceMonitor와 PodMonitor같은 CRD를 통해 Scraping 대상의 선언을 함으로써 Prometheus 설정을 자동으로 생성하고 갱신하게 된다.

 

무중단 설정 적용

그리고 설정파일을 변경하게되면 Prometheus 서버를 재시작해야 변경분이 반영되는데, Operator의 CRD를 통해서 기존 Scraping 작업을 방해하지 않고 롤링 업데이트하는 방식으로 변경분을 반영하게된다.

 

 

실습

Prometheus Operator를 통해 쿠버네티스 클러스터에서 Prometheus 모니터링 아키텍처를 구축해 본다.

`prometheus-community/kube-prometheus-stack` Helm 차트를 이용해서 Prometheus Operator를 구축하고자 한다.

GitHub - prometheus-operator/kube-prometheus: Use Prometheus to monitor Kubernetes and applications running on Kubernetes

 

# Repo 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# 전용 namespace 지정
kubectl create ns monitoring

# chart 설치
helm install prometheus-stack prometheus-community/kube-prometheus-stack -n monitoring

 

 

차트를 설치하면 아래와 같이 Operator의 컴포넌트들이 구동되는 것과 Operator의 CRD들의 목록을 확인할 수 있다.

 

 

먼저 `Prometheus` 커스텀 리소스를 확인해본다.

`Prometheus` 커스텀 리소스는 Prometheus 코어 서버에 대한 정의로, ServiceMonitor/PodMonitor/Probe/PrometheusRules 객체를 선택할 namespace와 label Selector를 각각 가지고 있다.

 

즉 위와 같은 객체를 생성할때, 객체의 `release` 라벨을 Prometheus 커스텀 리소스의 Selector에 정의된 내용대로 지정해야 Selector가 객체를 올바르게 가져올 수 있다는 것이다.

Prometheus가 "이름표(release 라벨)가 'prometheus-stack'인 사람들(ServiceMonitor)만 인터뷰하겠다"고 선언한 상태인 것이고, 이외 인물들은 무시되는 개념이다.

 

spec.replicas의 수를 조절해서 Prometheus를 간단하게 HA 모드로 전환시킬 수 있다.

kubectl edit prometheus prometheus-stack-kube-prom-prometheus -n monitoring

 

 

이렇게 Prometheus-Operator의 기본적인 컴포넌트와 CR 개념을 알아보았다.

이어서 Exporter와 ServiceMonitor/PodMonitor 객체를 통해 실제 스크래핑 작업을 동적으로 추가해보도록 한다.