쿠버네티스에 프로메테우스(Prometheus) 오퍼레이터 설치하기

프로메테우스(Prometheus)는 모니터링 시스템을 말한다. 프로메테우스는 파일 기반의 타임시리즈(Time-Series) 데이터베이스다. 시스템의 메트릭스들을 수집하기 위해서는 익스포터(Exportor) 를 설치해야 한다. 이외에도 알람을 전달해주는 AlertManager 도 있는데, 전체적인 아키텍쳐는 다음과 같다.

프로메테우스 아키텍쳐

프로메테우스는 쿠버네티스에서도 설치가 가능한데, 이글은 쿠버네티스에 프로메테우스 설치에 대한 글이다.

환경

환경은 다음과 같다.

  • Kubernetes 버전: 1.20
  • Kubernetes Nodes: Master 3개, Worker 3개
  • Prometheus 설치 방법: Helm Operator

설치

프로메테우스(Prometheus) 설치는 매우 다양한데, 검색을 해보면 Helm 을 이용한 방법 그중에서도 오퍼레이터(Operator) 를 이용한 방법이 많이 소개 되어 있다. 여기서도 이 오퍼레이터를 이용한 방법을 사용하고자 한다.

Prometheus Operator 로 검색을 해보면 github 저장소를 찾을 수 있다.

중간에 보면 Prometheus Operator vs kube-prometheus vs community helm chart 가 보인다. 자세히 읽어보면 쿠버네티스에 설치할 수 있는 방법이 세 가지로 나뉜다는 것을 알수 있다.

이중에서 나는 Helm chart 를 이용한 방법을 이용할 생각이다.

노드 레이블 설정

노드에 레이블을 설정하게 되면 쿠버네티스에 앱을 배포할때에 레이블을 지정함으로써 특정 노드에 생성되도록 강제할 수 있다. 프로메테우스 오퍼레이터 설치를 특정 노드에 하기 위해서 레이블을 부여할 생각이다. 대상 노드는 kworker3.systemv.local 노드이며 다음과 같이 레이블을 할당해 줬다.

kworker3.systemv.local 노드에 system.rule=monitoring 레이블이 새겨졌다.

Helm Chart 가지고 오기

Helm 를 이용하면 명령어 한줄로 설치가 되지만 설정을 변경하기 위해서는 챠트(Chart) 를 수정해줘야 한다. 이를 위해서 챠트를 다운받아야만 한다. Helm 챠트는 프로메테우스 커뮤니티에서 관리하고 있다.

많은 챠트가 존재하는데, 여기서 설치 대상은 kube-prometheus-stack 이다.

설정을 하기위해서 프로메테우스 오퍼레이터의 구성을 살펴볼 필요가 있다.

  • Prometheus – 프로메테우스 리소스 정의가 되어 있다. 프로메테우스를 위한 파드(Pod) 의 리플리카(Replica) 갯수, 퍼시스턴스 볼륨 구성등이다. 프로메테이스 오퍼레이터는 파드를 StatefulSet 으로 배포 한다. 그리고 어떤 애플리케이션, 혹은 리소스를 모니터링할 것이지를 지정하는 것인데, 이것은 ServiceMonitor 로 설정이 이루어 진다.
  • ServiceMonitor – 프로메테우스 오퍼레이터는 어노테이션 기반의 서비스 디스커버리를 지원하지 않으며 대신 PodMonitor, ServiceMonitor 를 이용한다. ServiceMonitor는 애플리케이션이나 서비스의 리소스를 모니터링할 것인지를 지정한다. 쿠버네티스의 NodeSelector 처럼 LableSelector 로 서비스의 리소스를 선택할 수 있고, 엔드포인트(EndPoint) 를 통해서 애플리케이션의 메트릭을 수집할 수 있다. ServiceMonitor 는 rule 을 기반으로 Prometheus의 모니터링 대상이 되는 ServiceMonitor를 scan하여 해당 정보를 Secret으로 배포한다. 그리고 이 Secret을 Prometheus StatefulSet에 마운트한다. 이런 방식으로 Prometheus 팟은 자신이 모니터링할 Service가 무엇인지 알 수 있다.
  • Altermanager – 알람 매니저 이다. 프로메테우스 컴포넌트중에 하나다.
  • PodMonitor – 파드에 대한 모니터다. 역시나 LabelSelector 를 통해서 모니터링하고자 하는 파드를 지정할 수 있다.

위 내용을 잘 알야하는 이유는 kube-prometheus-stack 디렉토리에 values.yaml 파일에 구조와 연관이 있다.

values.yaml 파일 편집

프로메테우스 오퍼레이터를 Helm 으로 설치할 때에는 values.yaml 파일의 설정을 참고하도록 되어 있다. values.yaml 에는 altermanager, Grafana, Prometheus 등에 대한 설정 값들이 들어가 있다. 앞에서 특정 노드에 배포하도록 하기 위해서 worker3.systemv.local 노드에 레이블링을 해줬기 때문에 이들 컴포넌트의 NodeSeletor 를 지정해 줘야 한다.

Grafana, Altermanager, Prometheus 의 파드들은 system.rule=monitoring 레이블링 된 노드에만 설치되도록 해뒀다.

Node Exportor 는 system.rule=monitoring 레이블링을 할당하지 않는다. 이들은 노드마다 작동되어야 하기 때문이다.

Helm 설치

이제 설치를 해야 하는데, 설치하기 앞서 의존성 챠트를 업데이트 해야 한다.

이제 다음과 같이 설치를 실행해 준다.

확인

이제 확인을 해보자.

이렇게 설치가 된것으로 보이지만, 사실 프로메테우스의 오퍼레이터는 CRD 를 이용해 리소스를 생성하였기 때문에 이를 알아야 한다. CRD 를 포함한 monitoring 네임스페이스에 모든 리소스를 보기 위해서 다음과 같이 할 수 있다.

이를 통해 확인할 수 있는 CRD 예로 ServiceMonitor, Prometheus 등을 확인해 볼 수 있다.

필자는 Metallb 를 이용해서 LoadBalancer 를 사용할 수 있기 때문에 grafana, prometheus 서비스에 대해서 타입을 ClusterIP 를 LoadBalancer 로 변경해 외부접속이 가능하도록 할 수 있다.

Metallb 에 의해서 EXTERNAL-IP 에 외부접속 IP 가 할당 되었다.

7 comments

  1. 1

    안녕하세요. 궁금한 부분이 생겨 여쭙니다. metallb로 external ip를 할당하셨는데
    kubectl expose deployment prometheus-grafana –type=LoadBalancer –name=my-service 이런식으로 클라우드 환경에서 로드밸런서를 할당하려고 했더니 existing 으로 나와서 할당이 되지 않습니다.
    어떤식으로 할당하시는 줄 아시나요?

    • 123

      확실하진 않지만 서비스를 lb타입으로 쓰려면 lb를 사용할 수 있는 컨트롤러를 사용해야하는걸로 본거같아요(ex: aws-alb controller)

  2. odark

    ServiceMonitor 는 rule 을 기반으로 Prometheus의 모니터링 대상이 되는 ServiceMonitor를 scan하여 해당 정보를 Secret으로 배포한다. 그리고 이 Secret을 Prometheus StatefulSet에 마운트한다. 이런 방식으로 Prometheus 팟은 자신이 모니터링할 Service가 무엇인지 알 수 있다.

    이말을 좀더 쉽게 설명이 가능할까요? 샘플 코드를 보여줄수있나요? 그리고 내용중에 serviceMonitor가 ServiceMonitor를 scan한다는 말도 이상하네요.

    • admin

      원래는 Prometheus 를 서버에 설치해보면 prometheus.yml 파일에서 설정을 다 합니다. 그 설정이란 것이 어떤 자원을 스크랩을 할지가 가장 큰 비중을 차지하게 됩니다.
      그런데, K8S 에 Prometheus 를 설치할때에 Operator 로 설치하게 되면 ‘어떤 자원을 스크랩 할것인가?’ 하는걸 ServiceMonitor 로 쪼개놨습니다.
      만일 Prometheus-Operator 로 설치를 성공적으로 해서 운영하고 있는데, 별도의 다른 자원에 대해서 모니털을 하고 싶다면 ServiceMonitor 를 만들어서 배포하면 되는 겁니다.
      그러면, 이런 생각을 하게 됩니다. ServiceMonitor 별로 스크랩 정보를 가지고 있다면 Prometheus 는 결국 prometheus.yml 설정파일 하나를 읽어서 작동되는데
      저렇게 쪼개진 스크랩정보를 어떻게 가지고 오는가?
      그것이 ServiceMonitor 들이 Secret 자원에 해당 내용을 올리게 되고, 이것을 마운트해서 prometheus.yml 파일에 읽을수 있도록 한다는 겁니다.
      실제로 Prometheus-Operator 로 설치하고 난후에 prometheus.yml 파일을 직접 수정해도 적용되지 않습니다.
      Prometheus 는 K8S 의 자원을 모니터링하기 위해서 Prometheus-K8S-Exportor 를 가동하고 그걸 가지고 k8s 에 대한 자원 모니터링을 하게되는데,
      이것은 결국에는 k8s 에 자원 모니터링 정보를 긁어오는 겁니다. k8s 의 자원모니터링은 cAdvisor 도 있지만 metric-server 를 설치하면 그걸 가지고 오게도 되어 있는걸로 알아요.
      https://sysdig.com/wp-content/uploads/2018/09/prometheus_operator_servicemonitor.png 이 그림을 참고하시면 되겠습니다.

  3. odark

    내용이어서 질문입니다.
    PodMonitor 역시나 LabelSelector 를 통해서 모니터링하고자 하는 파드를 지정해서 파드를 모니터링한다고하셨데 기존 operator패턴이 아닌 그냥 prometheus만 설치했을경우 pod에 exporter 붙어서 모니터링하는것과
    podmonitor가 모니터링하는게 무슨차이가 있나요? podmonitor가 똑같이 metric정보를 추출하나요?그럼 기존에 prometheus 에서 exporter가 하는걸 serviceMonitor, podMonitor 이런 crd로 선언된 cr이 그역할을 하는건지……개념이 헷갈립니다.

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">