kubernetes monitoring
Monitoring
CAdvisor(:exporter의 한 종류) 와 같은 컨테이너 모니터링 에이전트들은 /metrics 라고 하는 경로를 외부에 노출시켜 메트릭 데이터를 오픈하고, 해당 경로로 요청을 보내면 CAdvisor는 key-value 쌍으로 구성된 메트릭 데이터의 목록을 반환한다. 이 경로를 프로메테우스(:prometheus, 오픈소스 모니터링 데이터베이스)에게 미리 알려주면 자동으로 수집해가는 형식이다.
Monitoring Metric
1
2
3
4
5
6
7
8
9
10
11
step 1) 인프라 수준의 메트릭 : 호스트 레벨에서의 메트릭. 파일 디스크립터 개수, 디스크 사용량, 호스트 NIC의 패킷
전송량 등등
step 2) 컨테이너 수준의 메트릭 : 컨테이서 레벨에서의 메트릭. 컨테이너별 CPU와 메모리 사용량, 컨테이너 프로세스 상
태, 컨테이너에 할당된 리소스 할당량, 포트 상태 등
step 3) 어플리케이션 수준의 메트릭 : 어플리케이션 레벨에서의 메트릭. 마이크로서비스에서 발생하는 트레이싱(tracing)
데이터, 어플리케이션 로직에 종속적인 데이터, 서버 프레임워크에서 제공하는 모니
터링 데이터 등
Monitoring basic
kubernetes는 자체적으로 모니터링 기능을 제공하지는 않지만 몇가지 add-on 기능을 제공한다.
- metrics-server
예를 들어, kubectl top 과 같은 명령어를 사용하려면, 클러스터 내부의 메트릭을 모아서 제공하는 별도의 무엇인가가 필요하다. metrics-server가 바로 그 역할을 담당한다. (참고: 설치를 위한 yaml 파일을 깃헙에서 제공함.)
metrics-server의 동작원리 : APIService 리소스
metric-server는 어떤 방식으로 metric을 모아서 사용자에게 보여줄 수 있을까?
k8s의 노드 에이전트인 kubelet은 CAdvisor를 자체적으로 내장하고 있으며, Pod와 노드 메트릭을 반환하는 /stats/ summary 라는 엔드포인트를 제공한다. 이 메트릭을 가지고 오기 위한 권한을 ClusterRole로 정의해서, 서비스어카운트에 연결하고, 이 토큰을 기반으로 메트릭을 수집하게 된다. 이 과정에서 metrics-server는 API 서버의 역할을 일부 담당하고 있으며, 이는 쿠버네티스에 APIService 로 등록되어 있다.
이때 APIService 리소스는 새로운 API를 확장해 사용하기 위해서는 어떤 서비스에 접근해야 하는가 를 정의하고 있다. 이런 API 확장방식을 쿠버네티스에서는 API Aggregation 이라고 한다.
1
2
3
4
5
1) APIService 리소스를 통해 metrics-server를 확장한 API 서버로 등록
2) 쿠버네티스 API서버에 metrics.k8s.io API 요청을 전송함
3) API Aggregation Layer 에 의해 metrics-server로부터 제공되므로 k8s API 서버는 해당 요청을 metrics-server
로 전달
4) 응답 반환
- kube-state-metrics
쿠버네티스 리소스 상태에 관련된 메트릭을 제공하는 Add-On 이다. Pod 의 상태, 디플로이먼트 레플리카 개수 등
- node-exporter
인프라 수준에서의 메트릭을 제공. 파일 시스템, 네트워크 패킷 등과 같은 호스트 측면에서의 메트릭
Prometheus & Grafana
모니터링을 위한 메트릭을 제공하는 Add-On 을 설치하고 나면, 이를 수집하는 프로메테우스(혹은 데이터독과 같은 유료서비스)를 설치할 차례이다. 설치하는 방법은 1) 프로메테우스 도커이미지를 사용 , 2) 프로메테우스 Operator와 커스텀 리소스를 사용 , 3) 바이너리를 직접 실행 등 다양하게 존재한다.
- Prometheus
프로메테우스 오퍼레이터는 깃헙 저장소에서 yaml 파일을 제공한다. CRD 역시 함께 생성된다. 이후에 아래와 같이 prometheus 라는 이름의 커스텀 리소스를 생성해서 프로메테우스를 배포하면 된다. 이때, 권한문제를 위해 서비스 어카운트를 생성, 권한 부여, 해당 서비스 어카운트를 프로메테우스 포드가 사용할 수 있도록 설정해야 한다.
1
2
3
4
5
6
7
8
9
10
11
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus
namespace: default
spec:
replicas: 1
serviceMonitorNamespaceSelector: {}
serviceMonitorSelector: {}
serviceAccountName: {생성해준 prometheus 서비스 어카운트 이름}
-> kubeclt port-forward 와 같은 명령어를 사용하면 외부로 노출되지 않는 서비스에 임시로 접근할 수 있는 포트 포워딩을 생성할 수 있다. -> 로컬에서 프로메테우스 web-ui 확인 가능
프로메테우스로 메트릭을 수집하기 위해서는 메트릭을 가져올 수 있는 엔드포인트를 프로메테우스에게 알려주어야 한다. 이를 위해, ServiceMonitor 라는 커스텀 리소스를 사용하면 굳이 프로메테우스 프로세스를 리로드 하지 않아도 자동으로 적용할 수 있다.
1
2
3
4
5
1. serviceMonitor 라는 커스텀 리소스 생성 (이때 matchLabels 에 node-exporter가 설정되어 있는 yaml 파일
을 적용)
2. 프로메테우스 web-ui 에서 상단 status > Configuration > prometheus.yml 파일에서 scrape_configs
확인
- Grafana
별도의 설정 없이 도커 허브의 그라파나 이미지만 사용하면 손쉽게 설치할 수 있다.
1
2
3
4
5
6
7
8
9
# 예시
1) 프로메테우스를 데이터 소스로 등록
configuration > datasource > add datasource > prometheus
2) 데이터소스에서 그라파나 대쉬보드를 생성
그라파나 사이트에서 대쉬보드 선책 > 그라파나 화면 왼쪽에서 Dashboards > manage > 아까 대쉬보드 ID import
> Datasource는 1번 프로메테우스 데이터소스 선택