Kubernetes Best Practices : 쿠버네티스 모범 사례 : Chapter 3

[%] 의 표시 : 필자의 의견

Chapter 3. 모니터링 & 로깅

모니터링 기술

• 블랙박스 모니터링
  • CPU, Mem, Disk 등 infra 수준의 모니터링
• 화이트박스 모니터링
  • App 상태에 초점 : Http 요청수, 500 오류 수, latency 등
  • 시스템의 상태가 왜 이런지 파악

모니터링 패턴

USE 블랙박스 모니터링에 초점 - 리소스 파악

• Utilzation : 사용률
• Saturation : 포화도
• Error : 오류율

  RED 화이트박스 모니터링 : App의 최종 UX를 모니터링

• Request : 요청
• Error : 오류율
• Duration : 소요시간

  Google의 Four Golden Siganls (RED의 부모)

• Latency : 요청을 처리하는데 걸리는 시간
• Traffic : 시스템에 존재하는 요청의 양
• Error : 요청 실패율
• Saturation : 서비스의 사용률

k8s Metric 개요

어떤 Component를 모니터링?

Control Plane ; API 서버, etcd, scheduler, controller manager

Worker Node ; kublet, Container Runtime, kube-proxy, kube-dns, pod

cAdvisor

• 리눅스 cgroups (cpu, disk io, net io 를 고립시킬 수 있는 리눅스 커널 기능)로 mem, cpu 수집
• kubelet에 내장되어 있다.

Metric Server

• CPU, Mem 과 같은 resource metric을 수집. : kubelet API 에서 수집
• Metric Server에서 수집한 정보들은 Scheduler, HPA, VPA 등에서 사용

kube-state-metircs

• k8s에 저장된 Object를 Monitoring
• cAdvisor, Metric Server은 리소스 사용량에 중점
• kube-state-metircs 은 Cluster 에 배포된 k8s Object의 상태를 파악하는데 중점

모니터링할 Metric

Metric은 최대한 많이 모니터링하는 편이 좋으나, 너무 많으면 이상신호를 발견하기 어렵다.

즉, 계층적 방식을 취하는게 좋다.

계층

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

모니터링 Tools

Prometheus

InfluxDB

• 높은 write, query 부하를 처리하기 위한 timeseries DB

Datadog

Sysdig

Logging 개요

cluster & cluster 내 app 의 로그를 수집하여 중앙집중화 해야한다.

• Trade Off
  • 너무 많은 Metric 을 관찰하면 문제를 빠르게 발견하기 어렵다.
  • 리소스 사용량이 올라간다.
• 로그 디버그는 필요악 이다.
  • 최종 UX를 통해 살펴보면 30~45일 정도의 로그를 보관하는 것이 좋다.

k8s cluster 의 component log

• Node log
• k8s Control Plane log
  • API server
  • Controller Manager
  • Scheduler
• k8s audit log
• container app log

EFK 스택을 활용한 logging

EFK : Elastic Search, Fluentd, Kibana 의 약자

• Elastic Search : 검색 엔진
• Fluentd : k8s 환경에서 Elastic Search 로 로그 전송
• Kibana : Elastic Search 에 저장된 로그를 보기 위한 시각화 도구

EFK 로 처음 구현을 해보는 것이 처음에는 좋지만, 로깅 플랫폼을 관리하는 것이 정말 가치가 있는지? 를 봤을때 일반적으로는 가치가 없다. -> 굉장히 관리하기가 복잡하다.

알림

알림은 양날의 검이다. : 너무 많은 알림을 날리면 중요한 이벤트를 놓칠 수도 있다. ex) 파드가 실패할 때마다 알림을 해야하나? : k8s 의 묘미는 자동으로 컨테이너의 상태를 체크해서 재시작을 하는데 있다. -> 일반적인 상식과는 다르게 이런 상황은 모니터링 할 필요가 없다.

• 알림을 하는 대상(정책)을 고민해서 선택할 필요가 있다.
• 사람이 즉각 대응해야 하며, app 의 UX에 영향을 주는 문제라면 대기중인 엔지니어에게 즉각 알림을 줘야 한다.

즉각 대응할 필요가 없는 알림을 처리하는 방법은 문제를 자동으로 해결하는 것

• App Deployment 에서 k8s liveness probe 를 활용하면 응답이 없는 프로세스를 자동으로 복원하는데 도움을 얻을 수 있다.

ALert Threshold

• 알림을 구축할 떄 ALert Threshold를 고려하는게 중요하다.
• Threshold가 너무 짧으면 많은 거짓 알람을 받을 수 있다. (일반적으로 5분 이하)
• 수신하는 대상을 문제에 책임이 있는 사람에게만 알려야 한다.

Monitoring, Logging, Alert Best Practice

Monitoring

• Node & k8s의 모든 Component에 대한 Usage, Saturation, Error 모니터링
• 블랙박스 : 시스템의 예측하기 힘든 상태 & 징후를 모니터링
• 화이트박스 : 시스템과 내부를 조사
• 정확도가 높은 메트릭을 얻으려면 시계열 기반 메트릭으로 구현 -> app의 동작에 대한 통찰력을 얻을수 있다.

Logging

• 메트릭 모니터링과 함께 로깅
• 30~45일만 로그 저장 -> 그 후에도 필요하다면 저비용 리소스의 disk로 이전
• Sidecar Pattern 을 사용한다면 로그 전달자를 제한해서 배치하자 -> 그렇지 않으면 너무 많은 리소스를 사용하게 될거다

Alert

• 알림 피로에 조심 -> 너무 많은 알람은 사람과 프로세스에 악영향을 미친다.
• 즉각적인 대응이 필요 없는 일시적인 문제는 알림하지 않고 자동으로 재정의 되게 수립한다. (혹은 threshold 를 높이는것도 방법이다.)

---

• Previous
  Docker Image Build & Optimization

---