Kubernetes 모니터링

쿠버네티스의 경우 클러스터 안에 다수의 노드와 그 안에 파드를 비롯한 다양한 워크로드가 많게는 수백개가 실행되는 형태이다.

단일 노드의 경우 리눅스 명령어를 이용하여 하드웨어의 상황을 파악하고, 각 프로세스 모니터링을 했다면, 쿠버네티스의 경우 각 노드는 전적으로 컨트롤 플레인에 의해 관리되므로 우리는 모니터링에 대한 다른 접근 방법을 가져야 한다. 즉 우리는 쿠버네티스 API 를 적극 이용해야 한다.

클러스터 환경에서의 문제 해결의 어려움

단일 노드와 비슷하게, 클러스터 모니터링에서도 노드가 사용하는 리소스를 확인할 수 있다. 대표적으로 kubectl top 명령어가 있다. 이 명령어는 노드와 파드가 각각 얼마만큼의 CPU/메모리 리소스를 사용하는지 확인 할 수 있다.

한편 Kubernetes 환경에서는, 여러 개의 마이크로서비스가 워크로드로서 실행되고 또한 클러스터 안에 서로 연결되어 있는 경우가 대부분일 것이다. 이 경우 문제의 원인을 찾아내기 조금 더 복잡하다.

❗️백엔드 영역의 파드 하나에서 문제가 발생한 경우

-> 파드를 연결한 서비스 역시 제대로 작동하지 않을 것이다.
사용자는 UI 에서 그저 뭔가 문제가 있다는 정도만 확인할 뿐, 실제로 어떤 곳에서 무슨 원인에 의해 발생하는지 알기 어렵다.

위의 경우에 각 파드에서 사용하는 리소스에 문제가 발생할 경우 미리 경고를 주거나, Liveness Probe 를 통해 애플리케이션에서 발생하는 응답이 오류로 전달되는 경우 이를 즉시 모니터링할 수 있다면 좋을 것이다.

추가적으로 노드가 물리적으로 멀리 떨어진 상황일 경우 네트워크에 대한 문제가 발생할 있다. 따라서 응답 대기 시간(Response Latency)에 대한 점검도 중요하다.

클러스터 환경에서의 주요 이슈

• 쿠버네티스 환경 그 자체
  • 제어판(컨트롤 플레인)의 주요 컴포넌트 상태가 비정상적인 경우
• 노드의 리소스 가용량 (CPU, 메모리 요청에 대한 비율)
  • 노드의 가용한 리소스보다, 리소스 요청량이 커서 파드가 배포되지 않은 경우
• 노드의 리소스 사용량
  • 노드 리소스가 부족하여 컨테이너에 크래시가 발생한 경우
• 워크로드 이슈
  • 마운트한 파일 시스템의 용량이 부족한 경우
  • 특정 컨테이너가 반복적으로 재시작하는 경우

Prometheus 모니터링

Prometheus 는 오픈소스 모니터링/알림 시스템이다. Kubernetes, Node 는 Prometheus 자체를 모니터링 할 수 있다. Kubernetes 를 지원하고 관리하는 재단인 CNCF에서 프로메테우스 역시 관리하고 있으며, 이 두 도구를 비롯해 시각화를 담당하는 Grafana와 함께 세 도구 조합은 정석적으로 널리 사용되고 있다.

Action Items

❓ 모니터링 시스템에는 메트릭 수집을 위한 두가지 방식의 메커니즘이 존재한다. 바로 Pull 방식과 Push 방식 그렇다면 프로메테우스는 어떤 방식의 메커니즘을 사용하는가?

프로메테우스는 Pull 방식을 사용합니다.

프로메테우스 서버가 주기적으로 메트릭 데이터를 수집하기 위해 클라이언트에게 요청을 보내고 클라이언트는 이 요청에 대해 응답으로 현재의 메트릭 데이터를 반환한다.

이 방식의 장점은 클라이언트에서 수집 및 전송되는 데이터가 프로메테우스 서버에서 제어될 수 있으므로, 서버 부하를 조절할 수 있다는 점이다.

❓ Pull 방식과 Push 방식은 어떻게 다르며, 장단점은 무엇인지, 또한 해당 방식을 사용하는 모니터링 도구는 어떤 것들이 있는지 연구해보세요.

Pull 방식

(프로메테우스: Go 언어로 작성된 오픈소스 모니터링 시스템)
(Zabbix: C 언어로 작성된 네트워크 및 서버 모니터링 솔루션)

• 프로메테우스와 같은 Pull 방식의 모니터링 도구에서 사용
• 메트릭 데이터를 수집하기 위해 클라이언트에게 주기적인 요청을 보내는 방식
• 클라이언트에서는 요청에 대한 응답으로 현재의 메트릭 데이터를 반환
• 서버에서 클라이언트로 데이터를 가져오므로, 서버 부하를 조절할 수 있다.
• 데이터를 적극적으로 모으는 것이 어려울 수 있지만, 데이터를 효과적으로 분석할 수 있다.

Push 방식

(InfluxDB: 시계열 데이터를 저장하고 분석하는 데이터베이스)
(Graphite: 시계열 데이터를 수집하고 저장하는 오픈소스 솔루션)
(시계열 데이터: 일정 시간 간격으로 한 줄로 배열된 데이터)

• InfluxDB와 같은 Push 방식의 모니터링 도구에서 사용
• 클라이언트에서 주기적으로 서버로 메트릭 데이터를 전송하는 방식
• 클라이언트에서는 데이터를 전송하기 때문에, 서버에서 데이터를 수집하기 위해 추가적인 네트워크 요청을 보낼 필요가 없다.
• 클라이언트에서 데이터를 전송할 때 서버 부하가 발생할 수 있지만, 데이터 수집에 대한 전체적인 컨트롤이 가능
• 데이터를 수집하고 저장하는 것이 간단하지만, 데이터 분석이 힘들 수 있다.

Prometheus 구성 요소

• 프로메테우스는 시계열(time series) 데이터를 저장
  (시계열 데이터: 일정 시간 간격으로 한 줄로 배열된 데이터)
• 프로메테우스 서버는 다양한 exporter 로부터 각 대상의 메트릭을 pull 하여 주기적으로 가져오는 모니터링 시스템
  • 예를 들어, 쿠버네티스 관련 메트릭을 가져오고 싶다면 쿠버네티스 exporter를, mongoDB 관련 메트릭을 가져오고 싶다면, mongodb exporter를 사용하면 된다.
• Alert manager는 경고 및 알람을 담당
• 사용자가 데이터를 질의할 수 있는 Web UI가 존재
  • 이 때 질의 언어로는 PromQL(Prometheus Query Language)을 사용

프로메테우스의 구성 요소는 위 외에도 더 있지만 먼저 알아야 하는 것을 소개했다.
추가로 Grafana는 프로메테우스의 구성요소는 아니지만, 프로메테우스에서 권장하는 시각화 도구이다.

Kubernetes exporter

프로메테우스에서 쿠버네티스 관련 메트릭을 가져올 수 있는 쿠버네티스 exporter가 존재한다. 이 때 프로메테우스 exporter는 Kube API를 사용하고 대부분의 필요한 정보는 가져올 수 있다.

쿠버네티스에서 프로메테우스와 그라파나, 그리고 슬랙과 같은 메신저와의 연동은 보통 다음 그림과 같이 구성한다.

Prometheus, Grafana 설치

Prometheus Operator를 이용하여 설치 해보자.

우선 minikube 를 이용해 클러스터를 생성한다. --nodes 옵션을 이용하여 여러 개의 노드를 만들 수 있다.

위의 사진에 명령어를 입력 노드가 3개를 만들자. 이때 첫번째 노드는 master 나머지 두개의 노드는 worker 노드로 구성된다. 여러 개의 노드를 구성할 경우, 워커 노드에는 실제로 실행되는 애플리케이션을 배치하며, 마스터 노드는 클러스터 관리 그 자체에 집중하게 된다.

❓ 모니터링의 관점에서 워커 노드에 애플리케이션을 별도로 배치하는 것이 왜 유리할까?

1. 분산 환경에서의 모니터링
   워커 노드에 애플리케이션을 배치하면, 모든 서버에서 동일한 방식으로 모니터링할 수 있습니다. 또한, 모든 서버에서 동일한 방식으로 애플리케이션을 실행하므로, 문제가 발생했을 때 원인을 빠르게 파악할 수 있다.
   
   
2. 모니터링 리소스의 최소화
   예를 들어, 각 서버에 별도의 모니터링 애플리케이션을 배치하면, 메모리, CPU 등의 리소스를 낭비할 수 있다. 그러나, 워커 노드에 애플리케이션을 배치하면, 서버에서 필요한 메트릭 데이터만 수집하면 되므로, 리소스를 최소한으로 사용할 수 있다.
   
   
3. 로그 및 메트릭 데이터의 중앙 집중화
   워커 노드에 애플리케이션을 배치하면, 로그 및 메트릭 데이터를 중앙 집중화할 수 있다. 중앙 집중화된 데이터를 사용하면, 여러 서버에서 발생한 이슈를 빠르게 파악하고 대처할 수 있다. 또한, 중앙 집중화된 데이터를 사용하여 애플리케이션의 성능과 안정성을 개선할 수 있습니다.

모니터링 관점에서 워커 노드에 애플리케이션을 별도로 배치하는 것은 분산 환경에서의 모니터링, 모니터링 리소스의 최소화, 로그 및 메트릭 데이터의 중앙 집중화 등의 이점이 있다.

minikube 를 이용해 클러스터를 생성했다면 잘 설치됬는지 minikube status 명령어로 확인해보자.
정상적으로 설치된 모습.

그런 다음 원하는 이름으로 디렉토리를 하나 생성하고 그 디렉토리 안에 kube-prometheus 를 클론해주자. 공식 문서에 깃 클론 주소가 있으니 복사해서 진행하자.

복제 끝.

해당 디렉토리에서 kube-prometheus 를 배포해보자.

STEP 1

kubectl create -f manifests/setup

manifests/setup 안의 워크로드를 전부 실행한다.

STEP 2

until kubectl get servicemonitors --all-namespaces ; do date; sleep 1; echo ""; done

"서비스 모니터" CRD가 생성될 때까지 기다립니다. "No resources found" 메시지는 이 컨텍스트에서 성공을 의미한다. (이거의 뜻은... 잘 모르겠다. 공식문서에 나와있는데로 하는거라... 알려주실분..?)

STEP 3

kubectl create -f manifests/

manifest/ 안의 워크로드를 전부 실행합니다.

그러고 나서 STEP2 의 명령어를 입력해보니...
프로메테우스 관련 프로세스에 대한 동작되는 서비스들과 동작시간을 보는 명령어 인걸로 이해했다.

두 폴더의 리소스를 단일 명령으로 적용할 수 kubectl create -f manifests/setup -f manifests 있지만 모든 구성 요소를 성공적으로 생성하려면 명령을 여러 번 실행해야 할 수 있다.

kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090

1. 브라우저에서 localhost:9090 의 Prometheus 연다.

접속 성공

kubectl --namespace monitoring port-forward svc/grafana 3000

2. 브라우저에서 localhost:3000 의 Grafana (사용자 이름과 비밀번호는 공식문서에 있다.)
   
   성공