쿠버네티스(K8s) 모니터링 시작하기 — 4계층 지표와 알람 설정
쿠버네티스 모니터링, 무엇부터 봐야 할지 막막하다면. 컨트롤 플레인·노드·워크로드·앱 4계층으로 나눠 지표를 정리하고, metrics-server와 Prometheus의 역할, 최소 알람 5가지까지.
쿠버네티스 모니터링이 막막한 이유는 "무엇을 봐야 하는지"가 한 덩어리로 보이기 때문입니다. 결론부터 말하면, 컨트롤 플레인·노드·워크로드(Pod)·애플리케이션 4계층으로 나눠서, 각 계층마다 보는 지표와 도구를 정하면 됩니다. 이 글은 계층별 지표부터 metrics-server 와 Prometheus 의 역할 차이, 최소한으로 걸어야 할 알람까지 순서대로 정리합니다(쿠버네티스 자체가 낯설면 쿠버네티스란?부터 읽어 주세요).
왜 기존 서버 모니터링으로는 안 되나
가장 큰 차이는 대상이 움직인다는 점입니다. Pod 은 재생성될 때마다 이름과 IP 가 바뀌고, 오토스케일링으로 개수도 바뀝니다. "3번 서버 CPU 가 높다"는 식의 모니터링은 성립하지 않습니다. 대신 "어떤 워크로드가, 왜, 얼마나 자원을 쓰는가"를 레이블(태그)로 추적하는 설계가 필요합니다.
무엇을 봐야 하나 — 4계층 지표
| 계층 | 보는 것 | 주요 지표 |
|---|---|---|
| 컨트롤 플레인 | 클러스터의 두뇌 | API 지연/에러율, etcd 커밋 지연 |
| 노드 | 실제 머신의 건강 | CPU/메모리/디스크 압력, kubelet 상태 |
| 워크로드 | Pod·Deployment | 재시작 횟수, OOMKilled, Pending Pod, CPU 스로틀링 |
| 애플리케이션 | 서비스의 응답 | RED(Rate/Errors/Duration), 분산 추적 |
계층별 핵심만 짚으면:
관련 가이드Kubernetes Architecture: 구성 요소·제어 흐름·장애 지점→
- 컨트롤 플레인: 매니지드(EKS, NKS 등)를 쓰면 운영은 클라우드가 하지만, API 지연과 에러율은 직접 봐야 합니다. "배포가 느리다", "kubectl 이 무겁다"의 원인을 가르는 출발점입니다. 구조가 궁금하면 쿠버네티스 아키텍처를 참고하세요.
- 노드: 메모리 압력(MemoryPressure)과 디스크 압력(DiskPressure)이 Pod 축출(eviction)의 방아쇠입니다.
- 워크로드: 장애의 입구는 거의 여기입니다. 재시작 루프, OOMKilled, Pending 세 가지는 최우선으로 알람화합니다.
- 애플리케이션: 인프라가 정상이어도 앱이 느리면 사용자 영향이 납니다. RED 지표와 트레이스는 APM 영역으로, APM 뜻과 분산 추적이 자세합니다.
도구 역할 정리 — metrics-server, Prometheus, KSM
처음 헷갈리는 세 가지를 정리합니다.
- metrics-server: CPU/메모리 사용량을 가볍게 모읍니다. HPA(오토스케일)의 데이터 소스이자
kubectl top의 내용물입니다. 모니터링 도구가 아니라 현재값만 가집니다. - Prometheus: 시계열을 쌓아서 조회하고 알람을 겁니다. "과거와 비교", "몇 분간 이 상태면 알림"은 이쪽입니다.
- kube-state-metrics(KSM): Deployment 의 기대 개수와 현재 개수, Pod 의 단계 같은 "K8s 객체의 상태"를 Prometheus 지표로 바꿔 줍니다. 재시작 횟수나 Pending 감시는 KSM 경유입니다.
실무 표준은 "metrics-server(오토스케일용)+ Prometheus + KSM(감시·알람용)"의 병용입니다.
최소 알람 5가지
- Pod 재시작이 짧은 시간에 늘 때(CrashLoopBackOff 전조)
- OOMKilled 발생(메모리 제한과 실사용량의 불일치)
- Pending Pod 이 일정 시간 해소되지 않을 때(자원 부족 또는 스케줄 불가)
- 노드의 MemoryPressure / DiskPressure
- API 서버 에러율과 p99 지연의 악화
도구 선택 — 자체 운영이냐 SaaS 냐
Prometheus 스택을 직접 굴리는 길과 SaaS 에 맡기는 길이 있습니다.
관련 가이드Kubernetes란? 개념·작동 원리·도입 판단 기준→
| 선택 | 특징 | 맞는 팀 |
|---|---|---|
| Prometheus + Grafana(자체) | 무료, 자유도 최고 | 운영할 엔지니어가 있는 팀 |
| Datadog | 통합이 넓고 도입이 빠름 | 예산보다 속도 중시(과금 구조는 여기) |
| New Relic | 데이터량 과금으로 작게 시작 | 규모가 작거나 변동이 큰 팀 |
| Guance(观测云) | 사용량 과금·일 단위 정산, DataKit 을 DaemonSet 으로 배포 | 쓴 만큼만 내고 싶은 팀 |
어느 길이든 보는 지표와 알람은 이 글의 4계층으로 같습니다. 도구 차이는 수집과 운영 부담에서 납니다.
자주 묻는 질문
Q. 쿠버네티스 모니터링은 무료로 시작할 수 있나요?
네. metrics-server 와 Prometheus + Grafana 는 무료로 시작할 수 있습니다. 비용이 드는 것은 데이터 보관·가용성·운영 인건비이고, SaaS 는 그 부담을 요금으로 바꾼 것입니다.
Q. 처음엔 무엇부터 봐야 하나요?
워크로드 계층의 "재시작·OOMKilled·Pending" 세 가지부터입니다. 사용자 영향이 있는 장애 대부분을 이 세 가지로 조기에 잡을 수 있고 설정도 단순합니다. 다음으로 노드 압력 지표, 마지막으로 컨트롤 플레인과 앱의 RED 를 더합니다.
Q. Prometheus 와 metrics-server 는 둘 다 필요한가요?
역할이 달라서 병용이 표준입니다. metrics-server 는 오토스케일과 kubectl top 의 현재값용, Prometheus 는 적재·조회·알람용입니다. Prometheus 가 있어도 HPA 는 metrics-server 를 봅니다.
Q. 매니지드(EKS 등)를 써도 모니터링이 필요한가요?
필요합니다. 컨트롤 플레인 운영은 클라우드가 하지만, 노드·워크로드·애플리케이션 감시는 사용자 책임입니다. 매니지드여도 "API 지연"은 직접 보지 않으면 원인을 가를 수 없습니다.
Q. 비용은 어느 정도 드나요?
자체 운영이면 소프트웨어는 무료이고 운영 비용만, SaaS 면 구성에 따라 다릅니다. 100 호스트 규모의 예시는 Datadog 가격 완전 정리에 다른 도구와의 비교와 함께 있습니다. 도구 선택보다, 먼저 4계층 지표 설계를 정하는 것을 권합니다.
