[Kubernetes] 쿠버네티스에서의 모니터링(feat. Prometheus)

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.
 

Kubernetes

---

이번 포스팅에서는 쿠버네티스에서의 모니터링에 대해서 다루어보려고 한다. 직전 포스팅까지는 쿠버네티스에서 어떠한 리소스 오브젝트를 생성하고 적용하는 방법에 대해 주로 배워왔다면 이제는 지금까지 생성해온 리소스들의 상태가 현재 어떤지, 장애가 난 건 아닌지를 모니터링 하는 시스템을 쿠버네티스에서 어떻게 구축할 수 있는지에 대해 배워본다.

 

사실 쿠버네티스에서 자체적으로 제공하는 모니터링 기능은 없다. 보통은 프로메테우스와 같은 오픈소스 도구들을 조합하거나 Datadog과 같은 유료 솔루션을 도입해서 쿠버네티스에서의 모니터링 시스템을 구축하게 된다. 방금 언급한 프로메테우스는 오픈소스 모니터링 시스템으로 쿠버네티스와 매우 좋은 호환성을 지닌 소프트웨어 제품이다. 이 프로메테우스는 특별한 것은 아니고 데이터를 저장하는 일종의 시계열 데이터베이스이다. 이 프로메테우스의 개념이 구체적으로 무엇이고 어떻게 동작하는지는 후술할 예정이다.

 

우린 앞으로 쿠버네티스에서의 모니터링 기본 구조와 동작 원리를 살펴본다. 그 이후에는 프로메테우스로 쿠버네티스 모니터링 시스템을 어떻게 구축할 수 있는지도 살펴보자.

1. 모니터링의 기본적인 구조

인트로에서 프로메테우스가 시계열 데이터베이스라고 했다. 우리가 주목할 부분은 '데이터베이스'라는 것이다. 모니터링을 구축할 때도 데이터베이스가 사용된다. 그러면 이 데이터베이스에 저장되는 데이터는 무엇일까? 여러 가지가 있겠지만, 대표적으로 CPU 사용률, 메모리 사용률, 네트워크 I/O, 초당 요청 횟수 등과 같은 일종의 '메트릭' 데이터가 저장된다.

 

예전 도커 관련 포스팅에서 CAdvisor라는 것에 대해 소개한 적이 있다. CAdvisor는 컨테이너에 관련된 모니터링 데이터를 확인할 수 있는 모니터링 도구이다. 하지만 이 CAdvisor가 GUI 화면으로 보여주는 메트릭 데이터들은 지난 포스팅을 보면 알겠지만 사실 정갈하지 못하다. 쿠버네티스는 이 CAdvisor를 가져다 쓰되 데이터베이스와 결합해서 모니터링 시스템을 구축한다.

 

우선 이 CAdvisor는 쿠버네티스 클러스터를 구성하는 모든 노드에 kubelet 에이전트와 함께 내장되어 있다. 그리고 프로메테우스와 같은 데이터베이스를 하나 두어서 CAdvisor와 통신하며 노드의 메트릭들을 전달받게 된다. 구조는 다음과 같다.

 

 

먼저 모든 노드는 /metrics 라는 경로로 엔드포인트 경로를 노출(Listen)하고 있는데, 바로 이 엔드포인트로 클라이언트가 요청하면 각 노드에 붙어있는 CAdvisor는 해당 노드로부터 수집한 메트릭을 클라이언트에게 전달해준다. 위 그림에서는 프로메테우스가 클라이언트가 된다. 프로메테우스가 /metrics 엔드포인트로 요청을 수행하면 각 노드들로부터 메트릭 데이터들을 응답받고, 프로메테우스는 이 데이터들을 데이터베이스에 저장한다.(참고로 이 때 CAdvisor가 전달해주는 데이터의 형태는 키-값 쌍으로 구성되어 있다)

 

물론 프로메테우스가 자동으로 엔드포인트를 탐지하는 것은 아니고, 반드시 프로메테우스에 CAdvisor 엔드포인트 정보를 등록해주어야 한다. 이렇게 프로메테우스가 메트릭을 수집할 엔드포인트를 등록해주는 것을 '서비스 디스커버리(Service Discovery)'라고도 한다. 

 

그리고 CAdvisor 처럼 /metrics 라는 경로를 외부에 노출시켜서 어딘가에서 데이터를 수집할 수 있도록 공통화된 인터페이스를 제공하는 서버를 Exporter 라고 부른다. Exporter의 종류로는 매우 다양한데, 만약 애플리케이션 내부의 데이터를 프로메테우스로 수집하고 싶다면 Python이나 Go 언어와 같은 프로그래밍 언어에서 제공하는 Exporter 라이브러리를 통해 커스텀 Exporter를 만들 수도 있다. 

2. 모니터링 메트릭의 종류

직전에 소개한 CAdvisor는 주로 컨테이너 레벨의 메트릭을 제공해준다. 여기서 '컨테이너 레벨의 메트릭'이란 무엇을 의미할까? 그리고 컨테이너 레벨 말고 다른 레벨의 메트릭도 있는 건가? 이번 목차에서는 주로 모니터링 시스템에서 수집하는 메트릭의 대표적인 종류에 대해 알아보도록 하자. 절대적인 분류법은 아니지만 대략적인 분류 체계로만 이해하기만 하면 될 듯 하다.

 

• 인프라 수준의 메트릭: 호스트 머신 레벨에서의 메트릭을 의미. 예를 들어, 파일 디스크립터 개수, 디스크 사용량, NIC의 패킷 사용량 등 
• 컨테이너 수준의 메트릭: 컨테이너 레벨에서의 메트릭을 의미. 예를 들어, 컨테이너별 CPU 및 메모리 사용률, 컨테이너의 프로세스 상태, 컨에티너에 할당된 리소스 할당량, 컨테이너 및 파드의 상태 등
• 애플리케이션 수준의 메트릭: 애플리케이션 레벨에서 발생하는 메트릭을 의미. 트레이싱 데이터, 애플리케이션에서 사용하는 특정 프레임워크에서 발생하는 메트릭 데이터 등

3. k8s에서의 모니터링 구조

이번 목차에서는 본격적으로 쿠버네티스에서의 모니터링 시스템 구조에 대해 살펴본다. 해당 목차의 내용을 읽어나갈 때, [목차 1]에서 소개한 구조를 머릿속에 숙지한 채 읽어내려가보도록 하자.

3-1. 컨테이너와 인프라 레벨의 메트릭을 제공하는 서버: metrics-server

metrics-server 라는 서버는 쿠버네티스 자체가 제공하지는 않지만 쿠버네티스에 손쉽게 설치할 수 있는 에드온(add-on)이다. 이 metrics-server를 설치하면 kubectl top 명령어를 입력했을 때 출력되는 내용 또는 HPA가 동작하는 기준이 되는 파드의 CPU 및 메모리 사용률을 얻을 수 있게 된다. 이 metrics-server는 보통 kube-system 이라는 네임스페이스에 파드 형태로 생성된다.

 

좀 더 나아가서 metrics-server가 동작하는 원리에 대해서 살펴보자. metrics-server는 APIService 라는 쿠버네티스 리소스 오브젝트를 활용해서 쿠버네티스 API 확장 기능을 사용한다. 일반적으로 kubectl 키워드로 시작하는 명령어를 사용하게 되면 kube-apiserver로 요청을 전송한다고 했다. APIService 라는 쿠버네티스 리소스 오브젝트는 API 서버의 스펙을 준수하는 별도의 서버를 구축한 뒤, 해당 서버를 쿠버네티스에 등록하게 되면 kube-apiserver 처럼 나만의 확장된 API 서버처럼 새로 만들어서 사용할 수 있도록 해주는 것이다. 

 

먼저 APIService 리소스 오브젝트를 생성하는 예시 매니페스트를 살펴보자.

 

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.custom.metrics.k8s.io
spec:
  group: custom.metrics.k8s.io
  service:
    name: prometheus-adapter
    namespace: prometheus
    port: 443
  version: v1beta1

 

매니페스트를 보면 새로운 API를 확장해서 어떠한 서비스에 접근할지를 명시하고 있다. 생성될 API Service의 이름은 v1beta1.custom.metrics.k8s.io 이며, 이 API는 prometheus-adapter 에 접근함으로써 사용할 수 있다. 그래서 클라이언트는 v1beta1.custom.metrics.k8s.io 라는 이름의 API를 호출하게 되면 이 요청은 kube-apiserver로 가지 않고 해당 APIService로 가서 처리된다.

 

참고로 이러한 API 확장 방식을 API Aggregation이라고도 하니 용어를 알아두도록 하자.

3-2. 리소스 상태에 대한 메트릭을 제공하는 서버: kube-state-metrics

이번에 알아볼 또 다른 에드온 서버는 쿠버네티스 클러스터 내의 리소스 상태에 대한 메트릭을 제공하는 서버인 kube-state-metrics 이다. '리소스 상태에 대한 메트릭'이라 함은 예를 들어, 파드의 상태가 Running인지 또는 디플로이먼트의 레플리카 개수가 몇 개인지 등이 해당한다. kube-state-metrics 설치하는 YAML 파일은 쿠버네티스의 공식 github에서 쉽게 확인이 가능하다.

3-3. 인프라 수준의 메트릭을 제공하는 서버: node-exporter

다음으로 알아볼 에드온은 인프라 수준의 메트릭을 제공하는 서버인 node-exporter 이다. node-exporter는 이전에 소개한 에드온과는 달리 파일 시스템, 네트워크 패킷 등과 같은 호스트 측면에서의 다양하고 자세한 메트릭을 제공한다. 그래서 호스트 측면에서의 메트릭을 위한 서버이기 때문에 node-exporter는 모든 노드에 설치되어야 해서 데몬셋 형태로 배포된다. 그래서 특정 노드에 스케쥴링된 node-exporter 데몬셋 파드 하나를 출력해서 IP 항목을 보면 해당 파드가 스케쥴링된 노드의 IP랑 동일한 것을 볼 수 있다. 이는 node-exporter 데몬셋 파드가 호스트 네트워크 모드(hostNetwork)로 실행되기 때문입니다. 마치 docker run 명령어의 --net host 와 같은 옵션과 동일한 효과인 셈이다.

 

node-exporter는 기본적으로 상당히 많은 양의 메트릭을 수집하게 된다. 만약 수집할 필요가 없는 메트릭들이 있다면 node-exporter 데몬셋 매니페스트의 실행 인자 중에 --no-collector를 적절히 추가하는 방식으로 적용해볼 수 있다.

 

참고로 node-exporter를 설치하는 YAML 파일은 쿠버네티스에서 공식적으로 제공하지는 않지만 kube-prometheus 와 같은 깃헙 레포지토리에서 매니페스트를 찾아볼 수 있다. 

4. 프로메테우스를 활용해서 메트릭을 수집하자

직전 목차까지 배운 메트릭을 모니터링하기 위한 에드온인 kube-state-metrics, node-exporter, 그리고 kubelet에 내장되어있는 CAdvisor도 모두 설치되어 있는 상태라면 이제 이 에드온들이 수집하는 메트릭을 수집(이를 스크래핑(Scraping)이라고도 함)하는 프로메테우스를 설치해야 한다. 왜냐하면 문두에서 언급한 것처럼 프로메테우스는 일종의 시계열 데이터베이스고, 이 데이터베이스에 에드온들이 수집하는 메트릭을 저장해야 하기 때문이다. 그리고 이 프로메테우스에 저장된 메트릭을 가지고 그라파나와 같은 시각화 도구를 가지고 모니터링 대시보드를 제작할 수 있다. 구조를 그려보면 다음과 같다.

 

4-1. 프로메테우스 설치하기

가장 먼저 프로메테우스를 설치해야 한다. 프로메테우스를 설치하는 방법은 여러가지가 있다. Helm 차트로 설치하는 방법, 커스텀 리소스를 활용해서 설치하는 오퍼레이터 방법 등이 있다. 해당 책에서는 오퍼레이터를 활용해서 설치하는 방법을 소개한다. 오퍼레이터는 지난 포스팅에서 배운 커스텀 리소스를 활용해서 설치하는 방식이다. 커스텀 리소스에 대한 설명은 지난 포스팅을 참조하도록 하고, 여기서는 별도 설명은 생략하겠다.

 

프로메테우스를 오퍼레이터로 설치하고 동작하는 단계와 구조는 각각 다음과 같다.

 

 

그림의 왼쪽은 CRD와 CR, 그리고 컨트롤러라는 것들 간의 관계이다. 지난 커스텀 리소스 포스팅에서도 소개했던 내용이다. 이를 프로메테우스로 적용하면, 가장 먼저 프로메테우스를 설치하기 위해서 프로메테우스라는 커스텀 리소스가 정의된 CRD 매니페스트를 다운로드받든 깃헙에서 clone하던 가져온다. 그리고 CRD 매니페스트를 apply 하면 프로메테우스라는 커스텀 리소스가 생성된다. 여기까지가 설치하는 과정이라고 생각하면 된다.

 

다음은 이제 프로메테우스가 동작하기 위해서는 일종의 컨트롤러인 프로메테우스 오퍼레이터가 프로메테우스라는 커스텀 리소스가 생성되었다는 것을 감지한 뒤, 프로메테우스라는 커스텀 리소스에 정의되어 있는 여러가지 쿠버네티스 리소스들(ex. 파드, 디플로이먼트, 서비스, 시크릿, 컨피그맵, PV 등..)을 실질적으로 생성한다. 이것이 바로 프로메테우스가 동작하는 과정이다.(만약 오퍼레이터 방식으로 설치했다면)

 

프로메테우스가 GUI로 제공하는 것이 있는데, 프로메테우스 오퍼레이터가 설치한 쿠버네티스 리소스 오브젝트 중에 서비스 리소스 오브젝트에 9090 포트로 접근하면 아래의 GUI 화면에 접근할 수 있다.

 

프로메테우스 GUI 화면

 

위 GUI에서는 프로메테우스가 스크래핑하는 엔드포인트랑 연결이 잘 되었는지 확인할 수 있을 뿐만 아니라, 프로메테우스라는 시계열 데이터베이스에 저장되어 있는 메트릭 데이터에 대해 쿼리해서 데이터를 볼 수도 있다. 이 때 사용하는 쿼리를 PromQL이라고도 부른다.

4-2. 프로메테우스가 메트릭 수집하도록 하기

다음은 이제 프로메테우스가 어떤 곳(어떤 exporter)에서 메트릭을 수집하도록 할지 설정해주어야 한다. 이 때, 프로메테우스를 어떻게 설치했는지에 따라 약간 달라질 수 있는데, 만약 오퍼레이터를 활용해서 설치하지 않았다면 프로메테우스 파드 내부에 있는 config 설정 파일에 엔드포인트를 직접 기입한 후, 파드를 재시작하거나 파드 내부에서 실행되고 있는 프로메테우스 프로세스를 재실행해야 한다. 하지만 오퍼레이터 즉, 커스텀 리소스를 활용해서 설치했다면 ServiceMonitor라는 커스텀 리소스를 활용해서 어떠한 엔드포인트로부터 메트릭을 가져올지 쿠버네티스 리소스로서 정의하고, 이를 프로메테우스에 자동으로 적용할 수 있게 된다.

 

ServiceMonitor라는 커스텀 리소스는 "어떠한 쿠버네티스 서비스에 연결되어 있는 파드들로부터 메트릭을 가져올 것인가"를 프로메테우스에게 알려주는 역할을 한다. 그래서 실제 ServiceMonitor 커스텀 리소스를 정의하는 매니페스트를 보면 라벨 셀렉터(selector.matchLabels) 항목이 존재하는 것을 볼 수 있다. 해당 부분에 특정 쿠버네티스 서비스가 갖고 있는 라벨 key: value를 설정해주면 된다. 아래는 ServiceMonitor 매니페스트의 간단한 예제이다. spec.selector.matchLabels 항목을 유심히 보자.

 

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-app
  labels:
    team: frontend
spec:
  selector:
    matchLabels:
      app: example-app
  endpoints:
  - port: web

 

이렇게 해서 프로메테우스를 활용해서 메트릭을 수집하는 방법을 알아보았다.

 

참고로 프로메테우스는 수집되는 메트릭 양에 따라 메모리를 많이 소모하는 시계열 데이터베이스이다. 그래서 보통 프로메테우스의 데이터 리텐션은 짧게 설정하는 것이 흔하고, 일반적으로 최근 24시간 동안의 데이터만을 조회할 수 있다. 이 값은 프로메테우스 실행 옵션 중 --stroage.tsdv.retention.time 를 이용할 수 있다. 만약 장기간의 데이터를 프로메테우스에 보관해서 시각화하고 싶다면 타노스라는 추가 솔루션을 찾아볼 수 있다.

5. 시계열 데이터베이스의 메트릭을 수집하는 방식: Push, Pull

메트릭을 수집하는 시계열 데이터베이스로 프로메테우스 말고도 influxDB 라는 것도 존재한다. 그런데 이 influxDB는 프로메테우스와 어떤 차이점이 있는 걸까? 

 

시계열 데이터베이스가 메트릭을 수집하는 방식에는 크게 Push, Pull 방식 2가지가 존재한다. 이 2가지의 차이점은 "메트릭을 가져오는 주체가 누구냐"이다. 먼저 프로메테우스는 Pull 방식을 사용한다. Pull 방식은 데이터베이스가 메트릭을 노출하는 exporter에 접근해서 메트릭을 당겨(Pull)오는 방식이다. 반면에 influxDB는 Push 방식을 사용하는데, 이는 exporter가 데이터베이스로 메트릭을 전송(Push)하는 방식이다. 

 

메트릭을 수집하는 2가지 방식

---

이렇게 해서 시작하세요! 도커/쿠버네티스 서적을 공부한 모든 챕터의 내용의 기록이 끝이 났다. 해당 책은 크게 도커와 쿠버네티스 두 가지 파트로 구성되어 있는데, 해당 서적의 첫 파트를 공부하고 블로깅하던 시점이 2023년 2월이었다. 그 때부터 쿠버네티스 기초인 2023년 8월까지 진행하다가, 실무에 고급 내용을 활용할 일이 없어 잠깐 다른 쪽을 공부했었다. 그러다가 작년 9월에 이직을 하면서 쿠버네티스를 제대로 실무에 활용하는 상황에 다가오다 보니, 2024년 9월부터 계속해서 서적을 읽어나가기 시작했다. 그리고 드디어 2025년 2월에 해당 서적 공부를 마지막 챕터까지 완료했다.

 

대략 책 700쪽 분량의 내용을 정말 찐(?)으로 공부하고 기록하는 데 실질적으로 약 11개월 정도가 걸린 것 같다. 책을 11개월 간 읽다니.. 오래걸렸던 것 같기도 하다. 하지만 천천히 진행하면서 공부한 내용에 대해 치밀하게 고민해보고 곱씹어보며, 실무에 적용하는 시간도 같이 가져가다 보니, 효과는 배로 가져간 듯 하다. 아무튼 이번 기회에 책을 완독하게 되어 뿌듯하다!