Kubernetes Monitoring - Concept, Architecture
Overview
Kubernetes의 Monitoring 개념과 아키텍처에 대해서 기술하겠습니다.
참고 링크들
Monitoring Concept
우선 쿠버네티스 클러스터에서 데이터를 수집할 수 있는 오브젝트는 크게 4가지 계층으로 볼 수 있습니다.
-
Host : 노드의 cpu, 메모리, 디스크, 네트워크, 사용량과 노드 os와 커널에 대한 모니터링
-
Container : 노드에 기동되는 각각의 컨테이너에 대한 정보. 컨테이너의 CPU,메모리, 디스크, 네트워크 사용량을 모두 모니터링
-
Application : 컨테이너에서 구동되는 개별 어플리케이션에 대한 모니터링. ex) 컨테이너에서 기동되는 node.js기반의 애플리케이션의 http 에러 빈도등
-
Kubernetes : 컨테이너를 컨트롤 하는 쿠버네티스 자체에 대한 모니터링 (쿠버네티스의 자원인 서비스나 POD, 계정 정보등이 이에 해당)
개념적으로는 이렇게 나눌 수 있고 쿠버네티스 공식문서에서는 이를 수집지표, 즉 Metric이라고 부릅니다.
Metrics
쿠버네티스에서는 수집지표를 두가지로 나눠서 설명하고 있습니다.
- System metrics : 노드나 컨테이너의 cpu, 메모리 사용량 같은 일반적인 시스템 관련 메트릭.
core metric: 쿠버네티스의 내부 컴포넌트들이 사용하는 메트릭. (kubectl top에서 사용하는 메트릭 값.)non-core metric은 쿠버네티스가 직접 사용하지 않는 다른 시스템 메트릭을 의미
- Service metrics : application을 모니터링 하는데 필요한 메트릭.
- 쿠버네티스 인프라컨테이너에서 나오는 메트릭은 클러스터를 관리할 때 참고해서 사용
- 사용자 application에서 나오는 메트릭은 서비스 관련 정보를 파악할 수 있음 (ex, 웹서버의 응답속도, 500error의 빈도 등)
Pipeline
그리고 이러한 수집지표들을 수집하는 pipeline을 두 종류로 나눠서 설명하고 있습니다.
- Resource metric pipeline : 핵심 요소들에 대한 모니터링 (kubelet, metrics-server, metricAPI등으로 구성).
- 스케줄러나 HPA등의 기초자료로 활용
- Full metric pipeline : 클러스터의 사용자들이 필요한 모니터링을 하는데 활용.
- 쿠버네티스가 관리하지 않고, 외부 모니터링 시스템을 연계해서 이용하는 것을 권장
- 시스템, 서비스 메트릭 둘 다 수집 가능
Background++
HPA(Horizontal Pod Autoscaler) : 시스템의 부하 여부에 따라 pod을 자동으로 scale out 시켜주는 컨트롤러
Monitoring Architecture
지금부터는 위에서 언급한 두개의 파이프라인 아키텍처에대해서 알아보겠습니다.
1. Resource Metric Pipeline Architecture
아래 그림은 Resource metric pipeline을 통해 HPA를 하는 도식도입니다.
HPA는 시스템의 부하여부에 따라 pod을 scale-out시켜주는 모듈 이고, HPA를 하려면 시스템의 부하여부를 파악해야 합니다.
시스템의 부하여부는 여러 메트릭들을 참고할 수 있겠지만 기본적으로는 시스템메트릭(cpu나 메모리사용량)을 모니터링하게됩니다.
쿠버네티스에서는 이러한 시스템메트릭을 기본적으로 제공하고 있습니다.
Kubernetes node의 kubelet에는 cAdvisor라는 모니터링 에이전트가 탑재되어있어 노드에 대한 정보와 컨테이너(pod)에 대한 지표를 수집하고 있습니다.
그럼 해당 메트릭들을 가져오기만 하면 뚝딱 해치울수있습니다.
이 때 메트릭들을 가져오는 역할을 하는게 쿠버네티스 애드온 컴포넌트인 Metrics-Server입니다.
cAdvisor에서 지표수집 ->kubelet으로 전송Metrics-Server에서는 해당 metric들을 사용하기 위한 커스텀 api를k8s Aggregator를 통해 API server에 등록- 등록된 metrics api를 통해 수집된
system metric들이HPA로 전송 - 설정한 값에 따라 HPA에서는 controller에 명령을 내림
- 명령을 받은 컨트롤러에서 pod을 scale-out 시킴
이 다음 포스팅에서 진행할 HPA실습을 해보시면 이해가 더 잘될거라 생각합니다.
2. Full Metric Pipeline Architecture
두번째는 Full Metric Pipeline의 Architecture입니다.
이 파이프라인의 가장 큰 특징은 사용자들이 필요한 리소스의 모니터링을 할 수 있다는 것입니다.
즉, system과 service metric모두 수집이 가능하고 사용자가 원하는대로 모니터링을 할 수 있다는 것입니다.
Kubernetes Community에 올라온 Full metric pipeline Architecture는 다음과 같습니다.
얼핏보면 복잡한데 파랑색에만 집중하시면 됩니다.
- 일단 system metric처럼 service metric은 기본제공 metric이 아니니 metric을 수집하는 에이전트를 둬야함
- 수집한 metric을 모니터링시스템으로 전송
- 전송된 metric(system+service)은 Dashboard로 확인 또는 HPA로 보내 커스텀부하측정을 가능하게 함
예전에는 cAdvisor + Heapster + InfluxDB의 조합이 대세였지만 Heapster가 Kubernetes에서 deprecated되면서 Prometheus를 많이 사용하는 추세입니다.
해당 포스팅에서는 Prometheus를 기준으로 설명을 드리겠습니다.
Prometheus
프로메테우스는 시계열 데이터를 저장할 수 있는 다차원 데이터모델 구조를 지니고 있으며 CNCF의 두번째 졸업프로젝트입니다.
타 모니터링 프로그램과 다른 점은 데이터를 pull 방식으로 수집한다는 것입니다.
이 말은 모니터링 대상이 되는 자원이 지표 정보를 프로메테우스로 보내는 것이 아니라 프로메테우스가 주기적으로 모니터링 대상에서 지표를 읽어온다는 뜻입니다.
push 방식으로 지표를 수집하는 모니터링 툴은 ELK Stack, Telegraf, InfluxDB 등이 있습니다.
아래 그림은 프로메테우스의 아키텍처를 그린 그림입니다.
- 데이터 수집 : 크게 두가지 방식으로 나뉩니다.(pull, push)
- pull : 수집하고자 하는 객체에 설치된
exporter를 통해 수집합니다. - push : 배치성 작업은 필요한 경우에만 떠있다가 사라지기 때문에 pull방식으로 데이터수집이 어렵습니다. 이 경우
pushgateway에 지표정보를 push하고 나중에 프로메테우스에서 pushgateway의 데이터를 pull받는 방식으로 수집할 수 있습니다.
- pull : 수집하고자 하는 객체에 설치된
- 수집 타겟 : 서버의 개수가 정적으로 정해져있다면 모니터링 대상을 관리하는데 문제가 없지만, 클라우드환경에서는 ip가 동적으로 변하거나 대상이 늘어나거나 할 수 있기 때문에, 일일히 설정파일에 기재하는건 한계가 있습니다.
때문에 쿠버네티스의 etcd나 dns와 같은Service Discovery서비스와 연동하여 타겟 리스트를 설정 가능할 수 있습니다. - 데이터 저장 : 단순히 로컬 디스크에 저장해도되지만 외부 스토리지에 저장하는 것도 가능합니다.
쿠버네티스의storage class와 연결해서 쿠버네티스의Persistent Volume서비스를 이용할 수 있습니다. - 알람 : 프로메테우스에 정의된 특정 규칙에 따라 알람발생조건이 되면
Slack,Email등으로 알람내용을 전달할 수 있습니다. - 데이터 시각화 : 프로메테우스에 내장된 웹 UI 또는
Grafana와 같은 서드파티 툴을 이용할 수 있습니다.
다음 포스팅에서 쿠버네티스클러스터를 프로메테우스와 연동해 모니터링할 수 있는 실습을 해보겠습니다.
-> Kubernetes Monitoring - HPA 실습
-> Kubernetes Monitoring - Prometheus 실습
댓글남기기