[서비스 모니터링] 02. 쿠버네티스 클러스터 모니터링

# 학습 목표

• 쿠버네티스 모니터링 시스템이 Prometheus와 Grafana를 통해 구현됨을 이해할 수 있다.

---

# 학습 내용

1.  쿠버네티스 클러스터 모니터링

- 쿠버네티스의 경우 클러스터 안에 다수의 노드, 그리고 그 안에 파드를 비롯한 다양한 워크로드가 많게는 수백 개가 실행되는 형태로 구성되어 있음

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

 

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

kubectl top 명령어

- 단일 노드와 비슷하게, 클러스터 모니터링에서도 노드가 사용하는 리소스를 확인 가능

- 명령어를 통해 노드와 파드가 각각 얼마만큼의 CPU/메모리 리소스를 사용하고 있는지 확인 가능

- but, 쿠버네티스 환경에서는, 여러 개의 마이크로서비스가 워크로드로서 실행되고, 또한 클러스터 안에서 서로 연결되어 있는 경우가 대부분이므로 문제의 원인을 찾아내는 것이 조금 더 복잡

예를 들어 백엔드 영역의 파드 하나에서 문제가 발생한 경우, 파드를 연결한 서비스 역시 제대로 작동하지 않을 것잉나 사용자는 UI에서 그저 뭔가 문제가 있다는 정도만 확인할 뿐, 실제로 어떤 곳에서 무슨 원인에 의해 발생한 지는 알기 어려움

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

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

 

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

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