kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

kubectl get pod -n kube-system
kubectl describe pod -n kube-system [metrics pod이름] # 500에러

kubectl get -n kube-system deploy metrics-server -o yaml | k neat > metrics-insecure-deploy.yaml
# args에 --kubelet-insecure-tls추가
# 지금부터 top 명령어 사용가능
Bash
복사

k top pod
k top pod -A --sort-by memory
Bash
복사

모니터링 도구 k9s

NOTE

sudo wget -qO- https://github.com/derailed/k9s/releases/download/v0.25.18/k9s_Linux_x86_64.tar.gz | sudo tar xvzf - -C /tmp
mv /tmp/k9s /usr/local/bin/k9s
k9s info # k9s 접속
Bash
복사
k9s 설치

•

쿠버네티스 Addon 종류중 하나로 공싱적으로 쿠버네티스에서 개발,관리되는 Addon이다.

◦

Addon ⇒ 프로그램의 기능을 보강하기 위한 보조프로그램

쿠버네티스 모니터링 시스템

NOTE

쿠버네티스 환경은 모니터링 측면에서 기존의 가상 머신이나 베어메탈 환경과 다른점이 존재한다!

서비스 디스커버리

서비스 디스커버리는 쿠버네티스 클러스터 내에서 실행 중인 서비스들을 자동으로 식별하고, 이 정보를 모니터링 시스템에 제공하는 과정입니다.

•

쿠버네티스 환경에서는 Pod, Service와 같은 여러 리소스가 지속적으로 생성/삭제됩니다.

•

이러한 동적 환경에서 서비스 디스커버리는 새로운 서비스를 자동으로 인식하고, 제거하는 역할을 합니다.

•

구현 방법) 프로메테우스 - 쿠버네티스 API

애플리케이션 중심 모니터링

애플리케이션 중심 모니터링은 클러스터 내 리소스뿐 아니라, 애플리케이션의 성능, 트랜잭션, 에러 등을 집중적으로 모니터링하는 방식입니다.

•

개발자와 운영팀이 애플리케이션의 실시간 성능을 파악하고, 사용자 경험에 직접적인 영향을 주는 문제를 해결합니다.

•

구현 방법) 분산 추적(Jaeger, Zipkin), 로그 분석(ELK), 메트릭(Prometheus, Grafana)

이러한 차이점들 때문에, 쿠버네티스 환경에서의 모니터링 대상은 일반적으로 다음 세 가지로 나뉩니다.

•

노드와 컨테이너 자원 사용량

◦

일반 가상머신 환경과 유사하게, 쿠버네티스에서도 노드와 컨테이너의 리소스 모니터링이 필요합니다.

•

클러스터

◦

사용 중인 쿠버네티스 오브젝트 수량 및 이벤트 메시지

•

애플리케이션

◦

파드 뿐 아니라 웹, DB에 관련된 모니터링

◦

응답 속도, 세션 수, 쿼리 속도 등

프로메테우스

NOTE

프로메테우스는 2018년 CNCF 졸업 프로젝트로서 쿠버네티스 환경의 모니터링 표준입니다!

기존 모니터링 솔루션과 비교했을때 프로메테우스의 특징은 다음과 같습니다.

•

서비스 디스커버리

◦

동적으로 확장되고 축소되는 쿠버네티스 환경에서 프로메테우스는 개별 모니터링 대상을 서비스 엔드포인트로 등록해서 감지한다.

•

pull 방식

◦

변경이 잦은 개별 모니터링 대상에 대해서는 에이전트를 설치하고 에이전트가 중앙서버로 모니터링 정보를 전달하는 push방식이 아니다.

◦

중앙의 프로메테우스 서버가 직접 가져오는 pull 방식을 사용

•

다양한 익스포터, 레이블 지원

◦

HAProxy, MySQL와 같은 거의 모든 애플리케이션이 프로메테우스에서 사용할 수 있는 메트릭 정보를 제공한다.

◦

애플리케이션 추가시, 별도의 리소스를 들이지 않고 기존에 사용중인 exporter를 가져와서 사용할 수 있다.

◦

메트릭에 다양한 레이블을 추가해서 여러 메트릭중 원하는 메트릭만 필터링할 수 있다.

•

자체 언어인 PromQL지원

◦

프로메테우스는 자체 검색 언어를 제공한다.

◦

시각화 솔루션인 그라파나에서도 동일한 PromQL로 다양하게 자료를 조회해 그래프로 나타낼 수 있다.

•

시계열 DB(TSDB)사용

◦

프로메테우스는 모니터링 대상이 되는 메트릭 데이터를 시간과 값이 한 쌍을 이루는 데이터 형태로서 시간에 따라 순차적으로 저장하는 시계열 DB를 사용합니다.

프로메테우스 - Helm 설치

NOTE

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm pull prometheus-community/kube-prometheus-stack --untar
Bash
복사
helm repo & pull

# 임계값 도달시 경고
defaultRules:
	rules:
		alertmanager: true
		ectd: true

# alertManager 설치
alertmanager:
	## Service type
	type: NodePort
	
	
# 필요에 따라 다양한 모니터링 대상 추가
kubeApiServer:
	enabled: true
	
kubelet:
	enabled: true
	

# 타노스(멀티클라우드 환경) 생략
prometheus:
	thanosService:
		enabled: false

# 프로메테우스 ServiceMonitor 설정
# helm 설치 시 사용한 네임스페이스 이 외 다른 네임스페이스에서도 
# 서비스모니터를 등록 가능하도록 설정
	serviceMonitorSelectorNilUsesHelmValues: false


# 프로메테우스 서비스 설정
	type: NodePort
	
	retention: 5d
	
	retentionsSize: "10GiB"
	
	storageSpec:
		volumeClaimTemplate:
			spec:
				storageClassName: openebs-hostpath
				accessModes: ["ReadWriteOnce"]
				resources:
					requests:
						storage: 15Gi
YAML
복사
my-values.yaml

service:
	type: LoadBalancer
	
persistence:
	type: pvc
	enabled: true
	storageClassName: openebs-hostpath
YAML
복사
values.yaml (그라파나)

kubectl create ns monitoring
kubectl ns monitoring
helm install prometheus . --namespace monitoring -f my-values.yaml
Bash
복사
helm 설치

프로메테우스 - 아키텍쳐

NOTE

프로메테우스 아키텍쳐

•

얼럿 매니저

◦

프로메테우스는 사전에 정의한 정책에 기반해 경고 메시지를 생성한다.

◦

해당 메시지는 얼럿 매니저로 전달되고 얼럿 매니저는 중복제거, 메시지 그룹화, 일시 중지 등의 사후처리 작업을 거쳐서 경보 전달 채널로 전송한다.

•

그라파나

◦

메트릭 정보를 저장하는 용도, 그래프 형태로 시각화가 가능하다.

◦

PromQL 검색언어 조회가능

•

프로메테우스 파드

◦

스테이트풀셋으로 배포된다.

◦

모니터링 대상이되는 파드는 exporter라는 별도의 사이드카 형식의 컨테이너로 메트릭을 노출시킨다.

◦

해당 메트릭을 프로메테우스는 pull 방식으로 가져와 내부의 사계열 DB(TSDB)에 저장한다.

•

노드-익스포터

◦

데몬셋으로 설치되어 모니터링 대상이 되는 전체 노드에 자동설치

◦

노드-익스포터는 물리 노드에 대한 자원 사용량 정보를 메트릭 형태로 변경해 노출

필수 구성요소 외의 프로메테우스 헬름차트는 아래의 파드를 추가로 설치합니다.

•

프로메테우스 오퍼레이터

◦

시스템 경고 메시지 정책, 애플리케이션 모니터링 대상 추가 등의 작업을 하도록 Custom Resources 지원

•

kube-state-metrics

◦

쿠버네티스 상태를 메트릭으로 변환

◦

쿠버네티스 API 서버와 통신해서 각 오브젝트 상태를 메트릭으로 수집해서 모니터링

프로메테우스 서버가 메트릭 정보 수집하는 방법

노드 익스포터는 노드의 자원 사용량 정보를 수집하며, 파드의 ClusterIP 서비스를 사용하고 있습니다.

프로메테우스를 포함한 대부분의 모니터링 시스템은 모니터링 대상이 기본적으로 메트릭 정보를 웹 서버의 /metrics 엔드포인트 경로에 노출합니다.

이 정보는 프로메테우스 서버가 HTTP GET 방식으로 가져오고, 프로메테우스는 노드 익스포터의 서비스 이름(prometheus-prometheus-node-exporter)과 9100번 포트를 통해 접속합니다.

프로메테우스 파드는 노드 익스포터 서비스를 통해 해당 메트릭을 확인합니다. 로컬호스트의 포트 포워드 기능을 사용하여 원격의 노드 익스포터 파드에 접속하고 해당 메트릭을 확인해 보세요.

k get svc
k port-forward svc/prometheus-prometheus-node-exporter 8080:9100
Bash
복사
실행이후 다른 터미널에서 확인해야함

port-forward

•

해당 명령어를 이용해서 NodePort, LoadBalancer, Ingress로 지정하지 않은 ClusterIP 타입의 서비스를 임시로 외부에서 접속하는 경우 사용할 수 있다.

•

k port-forward 명령어에 원하는 서비스 대상을 지정하고 8080:9100으로 매핑한다.

•

설정이 완료되면 8080 → 9100 포트로 접속이 가능해진다.

•

localhost:8080/metrics에서 메트릭 값을 확인할 수 있다.

프로메테우스 - 웹 ui활용

NOTE

노드 익스포터의 메트릭 정보에 대한 설정 확인 Status → Configuration

•

관련 설정에 대해 설명하는데 핵심 요소만 보면된다.

모니터링 대상확인 Status → Target

avg(rate(node_cpu_seconds_total{mode="idle"}[1m]))
Bash
복사
PromQL 예시

그라파나 - NGINX 애플리케이션 + 모니터링 대시보드

NOTE

헬름 프로메테우스-스택으로 프로메테우스를 설치하면 이미 자동으로 대시보드가 포함되어 있습니다.

Dashboards | Grafana Labs

Browse a library of official and community-built dashboards.

https://grafana.com/grafana/dashboards/

Grafana 디자인 랩

k get secrets prometheus-grafana -o yaml # grafana 패스워드 확인
echo -n "~~" | base64 --decode
Bash
복사
패스워드 확인 (그라파나 패스워드 확인)

기본적인 그라파나 사용과 로그인에 대한 설명은 생략하고 바로 다음 단계로 넘어갑니다.

프로메테우스 익스포터 옵션을 추가하여 Nginx를 설치하면, 자동으로 NGINX가 프로메테우스 모니터링에 등록되는 실습을 진행합니다.

Nginx 모니터링용 대시보드 추가

helm repo add bitnami https://charts.bitnami.com/bitnami
helm pull bitnami/nginx --untar
Bash
복사
helm repo & pull

metrics:
	## @param metrics.
	enabled: true
	
	service:
		## @param metrics.service.port NGINX..
		port: 9113
	
	# 서비스모니터 사용
	serviceMonitor:
		## @param metrics.serviceMonitor.enabled Creates
		enabled: true
		## @param metrics.serviceMonitor.namespace Namespace
		namespace: "monitoring"
YAML
복사
values.yaml (Nginx)

서비스 모니터는 프로메테우스가 사용하는 CRD입니다.

프로메테우스 서비스모니터 구조

•

사용자는 이 서비스 모니터라는 별도의 리소스를 추가함으로써 기존 프로메테우스 설정을 변경하지 않고 새로운 모니터링 대상을 등록할 수 있습니다. 

•

새로운 모니터링 대상을 등록할 때 파드 리스타트 등 기존 서비스의 안전성에 영향을 미치는 추가 작업이 필요하지 않도록 리소스를 분리하였습니다.

•

이렇게 기존 서비스 설정을 변경하지 않는것을 불변 인프라 방식이라 합니다.

•

이렇게 기존 서비스 설정을 변경하지 않는것을 불변 인프라 방식이라 한다.

위의 nginx helm을 설치한 이후 다음 명령어로 serviceMonitor객체를 확인할 수 있습니다.

k get servicemonitors.monitoring.coreos.com -n monitoring
Bash
복사

얼럿 매니저 - 경보시스템

NOTE

얼럿 매니저의 구조

프로메테우스는 장애 등의 메시지 전달 기능을 얼럿매니저로 분리해서 관리합니다.

프로메테우스는 임계값 설정에 의해 경고 메시지가 발생하면 이를 얼럿매니저에 푸시 이벤트로 전달하고 얼럿 매니저는 이를 그룹과, 일시 중지(silence) 등의 가공 과정을 거쳐 이메일, 슬랙으로 전달합니다.

프로메테우스의 Alerts정보

경고 - Alerts

•

시스템 경고 메시지 관련을 확인하는 메뉴

•

프로메테우스는 시스템 경고 설정에 관한 정책을 별도의 리소스인 prometheusrules CRD로 관리한다.

비활성화 - Inactive

•

경고가 활성화 되지 않은 상태

지연 - Pending

•

경고가 발생했으나, 아직 경고 메시지 전달까지의 시간이 경과되지 않음

경보 - Fring

•

임계값과 시간을 초과해서 경보가 발생한 메시지

시스템 경고 상황이 발생했을 때 얼럿매니저에서 메시지를 전달하는데 필요한 슬랙채널 생성

슬랙채널 & 웹훅등록

alertmanager:
	## AlertManager configuration directives
	## ..
	config:
		global:
			resolve_timeout: 5m
			slack_api_url: 'https://hooks.slack.com/services/~~' # URL
			
		# ..	
		route:
			group_by: [job']
			group_wati: 30s
			group_interval: 5m
			repeat_interval: 12h
			receiver: "slack-notifications"
			routes:
			- receiver: 'slack-notifications' # 슬랙 등록
				matchers:
				- alertname = "InfoInhibitor|Watchdog"
		
		receivers:
			- name: 'slack-notifications'
				slack_configs:
				- channel: 'test' # 슬랙채널 이름
					send_resolved: true
YAML
복사
values.yaml (그라파나)

경고메시지 출력