쿠버네티스 모니터링

쿠버네티스 창시자에게 배우는 모범 사례

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 제공 받아 작성된 서평입니다."

메트릭 vs 로그

메트릭: 정해진 기간에 측정한 수치

로그: 에러, 경고, 중요 이벤트 등 프로그램 실행 중 일어난 사건을 추적

메트릭과 로그를 모두 수집해야 하는 대표적 사례는 애플리케이션의 성능이 나빠지는 경우

가령, 애플리케이션을 호시팅한 파드에서 레이턴시(지연시간)가 높게 나타난 경우, 메트릭만으로는 문제를 제대로 파악하기 어렵기 때문에

애플리케이션이 기록한 로그를 살펴보며 에러를 조사한다.

모니터링 기법

폐쇠형 모니터링 (closed-box monitoring)

주로 애플리케이션 외부에서 모니터링, 기존 CPU, 메모리, 스토리지 등을 모니터링하는 시스템에서 많이 써온 방식

인프라 수준의 컴포넌트를 모니터링할 때는 유용하지만, 애플리케이션이 어떻게 동작하는지 전후 맥락과 인사이트를 얻기는 어렵다.

개방형 모니터링 (open-box monitoring)

총 HTTP 요청수, 500 에러 횟수, 요청 레이턴시 같은 애플리케이션 상태에 주목

그래서 '왜' 시스템 상태가 이렇게 되었는지 단서를 얻을 수 있다.

모니터링 패턴

쿠버네티스와 같은 다이나믹하고 일시적인(transient: 쿠버네티스 오프젝트의 잦은 생성/소멸을 거치는 특성을 말함) 플랫폼 환경에서는 모니터링 방법에 대한 재고가 필요, 쿠버네티스는 수명이 짧고 다이나믹한 파드의 특성을 잘 나타낼 수 있는 모니터링 체계를 수립해야 한다.

분산 시스템을 모니터링 하는 패턴은 크게 두가지

USE 방법론

• U: 사용률 Utilization
• S: 포화도 Saturation
• E: 에러 수 Errors

이 방법론은 애플리케이션 수준의 모니터링으로는 한계가 뚜렷하여 주로 인프라 수준의 모니터링에 쓰인다. 

'모든 리소스에 대해 사용률, 포화도, 에러 수를 확인'하는 것으로 시스템의 리소스 제약과 에러를 신속하게 파악할 수 있다.

RED 방법론

• R: 처리율 Rate
• E: 에러 수 Errors
• D: 처리 시간 Duration

이 방법론의 기본 사상은 구글의 4대 골든 시그널이다.

레이턴시: 요청을 처리하는데 걸린 시간

트레픽: 시스템에 가해진 수요량

에러: 실패한 요청의 비율

포화도: 서비스 사용률

 

이 두 방법론은 서로 상호 보완적인 관계.

USE는 인프라 컴포넌트에 집중하는 반면, RED는 애플리케이션의 엔드 유저 경험 위주로 모니터링한다.

쿠버네티스 메트릭 개요

위에서 언급한 모니터링 기법과 패턴을 활용해 쿠버네티스 클러스터에서 어떤 컴포넌트를 모니터링할지 알아보자.

쿠버네티스 클러스터는 컨트롤 플레인(control plane)과 여러 노드 컴포넌트(node component)로 구성된다.

컨트롤 플레인: API 서버, etcd, 스케줄러, 컨트롤러 메니저로 구성

노드: kubelet, 컨테이너 런타임, kube-proxy, kube-dns, 파드로 구성

클러스터와 애플리케이션을 정상 가동하려면 이 모든 컴포넌트를 빠짐 없이 모니터링 해야 한다.

 

쿠버네티스는 다양한 방식으로 메트릭을 표출하는데, 클러스터 내부의 메트릭을 수집하는 다양한 컴포넌트를 하나씩 알아보면..

cAdvisor (컨테이너 어드바이저)

노드에서 실행 중인 컨테이너의 리소스와 메트릭을 수집하는 오픈 소스 구현체

쿠버네티스 kubelet과 한몸으로 클러스터의 모든 노드에서 실행

cAdvisor를 cgroup(CPU, 디스크 I/O, 네트워크 I/O 리소스를 격리하는 리눅스 커널의 기능)트리를 통해 메모리, CPU 메트릭을 수집하며, 리눅스 커널에 내장된 statfs로 디스크 메트릭을 수집

메트릭 서버

메트릭 서버는 리소스 메트릭 API의 표준 구현체로, CPU, 메모리 등 리소스 메트릭을 kubelet API에서 수집해 메모리에 저장

이렇게 수집된 메트릭은 스케줄러, HPA(Horizontal Pod Autoscaler: 수평 파드 오토스케일러), VPA(Vertical Pod Autoscaler: 수직 파드 오토스케일러)에서 사용

커스텀 메트릭 API를 사용하면 모니터링 시스템에서 임의의 메트릭을 수집할 수 있다.

kube-state-metrics

kube-state-metrics는 쿠버네티스에 저장된 오브젝트를 모니터링하는 쿠버네티스 애드온

cAdvisor와 메트릭 서버가 리소스 사용량에 관한 구체적 메트릭을 제공하는 반면, kube-state-metrics는 클러스터에 배포된 쿠버네티스 오브젝트의 상태 파악이 주된 관심사

 

kube-state-metrics로 확인 가능한 항목

 

파드

• 클러스터에 파드가 몇 개 배포되었나?
• 대기 상태인 파드는 몇 개인가?
• 파드 요청을 처리할 만큼 리소스가 충분한 상태인가?

 

디플로이먼트

• 실행 중인 파드 대비 몇 개의 파드가 의도한 상태인가?
• 레플리카는 몇 개 사용할 수 있나?
• 어떤 디플로이먼트가 업데이트 되었나?

 

노드

• 내 노드의 상태는 어떠한가?
• 클러스터에 할당 가능한 CPU 코어 수는 몇 개인가?
• 스케줄링 불가능한 노드가 있는가?

 

잡

• 잡이 언제 시작되었나?
• 잡이 언제 완료되었나?
• 실패한 잡은 몇 개인가?

 

어떤 메트릭을 모니터링 하나?

모든 메트릭을 모니터링 하면 좋겠지만 너무 많은 메트릭을 보다간 중요한 신호를 보지 못할 수 있기 때문에 다음의 요소를 계층적으로 접근할 필요가 있다.

• 물리, 가상 노드 
• 클러스터 컴포넌트
• 클러스터 애드온
• 엔드 유저 어플리케이션

모니터링을 계층적으로 접근하면 대상 시스템에서 올바른 신호를 보다 쉽게 찾아내고 당면한 문제를 더 집중적으로 파고들 수 있다.

예를 들어, 어떤 파드가 자꾸 대기 상태에 빠질 경우, 일단 노드의 리소스 사용률을 체크하고 문제가 없으면 클러스터 수준의 컴포넌트를 타깃팅하는 식으로 살펴보는 것

시스템에서 타깃팅할 만한 메트릭

 

노드

• CPU, 메모리, 네트워크, 디스크 사용률

 

클러스터 컴포넌트

• etcd 레이턴시

 

클러스터 애드온

• 클러스터 오토스케일러
• 인그레스 컨트롤러

 

애플리케이션

• 컨테이너 메모리 사용룰 및 포화도
• 컨테이너 CPU 사용률
• 컨테이너 네트워크 사용률 및 에러율
• 애플리케이션 프레임워크에 특정한 메트릭

 

프로메테우스를 이용한 쿠버네티스 모니터링

프로메테우스는 쿠버네티스의 레이블, 서비스 디스커버리, 메타데이터와 궁합이 좋은 메트릭 모니터링 툴

처음엔 구글 내부 모니터링 시스템인 보그몬(Borgmon)에서 많은 아이디어를 가져왔다.

메트릭을 풀(pull) 방식으로 수집할 대상 엔드포인트에서 직접 긁어오는 식으로 계속 수집하여 프로메테우스 서버에 넣는다.

프로메테우스 아키텍처