Kubernetes 모니터링

블랙박스 모니터링 : 애플리케이션 외부에 초점, (CPU, Mem, Disk 등)인프라 수준의 모니터링

모니터링 패턴

블랙박스 모니터링 - 리소스 파악
- USE패턴(모든 리소스에 대해 사용률, 포화도, 오류율 확인) - 인프라 컴포넌트에 초점 --> 시스템의 리소스 제약과 오류율 빠르게 파악 가능 ex) 클러스터 노드의 네트워크 상태를 점검하기 위해 사용률, 포화도, 오류율을 모니터링해 네트워크 병목이나 네트워크 스택의 오류를 쉽게 알 수 있음
화이트박스 모니터링 - App의 최종 UX 모니터링
- RED(요청, 오류율, 소요시간) - 사용자의 서비스 경험에 초점
- *구글의 네가지 황금 신호에서 가져옴. 레이턴시(요청을 처리하는 데 걸리는 시간)/트래픽(시스템에 존재하는 요청의 양)/오류율(요청 실패율)/포화도(서비스의 사용률)
- k8s에서 실행중인 프론트엔드 서비스를 모니터링할 때,
  - 프론트엔드 서비스는 얼마나 많은 요청을 처리하고 있는지?
  - 사용자는 500오류를 얼마나 받고 있는지?
  - 요청에 대한 서비스의 사용률이 과도하게 높지는 않은지

💡 어떤 Component를 모니터링?
Control Plane : API 서버, etcd, scheduler, controller manager
Worker Node : kublet, Container Runtime, kube-proxy, kube-dns, pod

1. Host

Kubernetes Cluster를 구성하는 모든 Node의 Host에 대한 CPU, 메모리, 디스크, 네트워크, 사용량과Node의 OS와 커널에 대한 모니터링을 함.

2. Container

Node에서 실행 중인 Container의 CPU,메모리, 디스크, 네트워크 사용량 모니터링 함.

3. Application

Container에서 구동되는 개별 어플리케이션에 대한 모니터링.

ex) 컨테이너에서 기동되는 node.js기반의 애플리케이션의 http 에러 빈도 등

4. Kubernetes

Container를 컨트롤 하는 Kubernetes 자체에 대한 모니터링 (Kubernetes의 자원인 Service, POD, 계정 정보등이 이에 해당)

*이러한 4계층으로 분류된 Matrics는 분류방법에 따라 2개의 Matrics로 분류됨.

1 . System Metrics

Metrics 4계층 중 Host와 Container에 해당하며, Node나 컨테이너의 CPU, 메모리 사용량 같은 일반적인 시스템 관련 Metrics.

System Metrics는 더 세분화해서 Core Metrics와 Non-core Metrics로 분류됨.

[Core Metrics] : kubernetes의 내부 컴포넌트들이 사용하는 Metrics. ex) kubectl top에서 사용하는 Metrics 값

[Non-core Metrics] : kubernetes가 직접 사용하지 않는 다른 시스템 Metrics

2 . Service Metrics

Metrics 4계층 중 Application과 Kubernetes에 해당하며, Application을 모니터링 하는데 필요한 Metrics ex) 웹서버의 응답속도, 500error의 빈도 등

*Metric은 최대한 많이 모니터링하는 편이 좋으나, 너무 많으면 이상신호를 발견하기 어렵다. 즉, 계층적 방식을 취하는게 좋다.

계층

물리 혹은 가상의 Node
1. CPU Usage
2. Mem Usage
3. Network Usage
4. Disk Usage
Clusert Component
1. etcd Latency
Cluster 추가 기능
1. Cluster AutoScaler
2. Ingress Controller
사용자(개발자)의 App
1. Container Mem Usage & Saturation
2. Container CPU Usage
3. Container Network Usage & Error
4. App Framework의 특수 Metric - 이렇게 계층으로 구분을 하고 pod에 이상이 생기면, 1. -> 4. 순으로 상태를 살펴보면 빠르게 문제점을 파악 할 수 있다.