Kubernetes 옵저버빌리티 확보하기
Kubernetes 환경은 컨테이너가 수시로 뜨고 사라지는 동적 토폴로지이기 때문에 "CPU가 몇 %인가" 같은 상태 확인(모니터링)만으론 문제 대응이 어렵습니다. "왜 이 Pod가 재시작되는가", "왜 이 서비스가 느려졌는가"를 추적할 수 있는 옵저버빌리티가 필요합니다.
이 가이드는 WhaTap Kubernetes Monitoring으로 Cluster·Pod·Service 계층을 어떻게 묶어 보는지, 어떤 메뉴를 언제 쓰는지 정리합니다.
옵저버빌리티의 4가지 신호
Kubernetes 환경을 이해하려면 다음 네 가지 데이터를 교차해서 봐야 합니다.
| 신호 | 역할 | 와탭에서 보는 곳 |
|---|---|---|
| Metric | 자원 사용률·수량 변화 추세 | Cluster·Node·Pod 대시보드 |
| Trace | 서비스 간 호출 흐름·지연 구간 | 트랜잭션 트레이스 |
| Log | 시간 단위의 사건 원본 | 컨테이너 로그 |
| Event | K8s 자체 이벤트(Pod 재시작 등) | K8s 이벤트 스트림 |
단편 데이터 하나로는 원인을 찾기 어렵습니다. 예를 들어 Pod CPU 스파이 크(Metric)를 봤다면, 같은 시점 Trace로 어느 요청이 CPU를 썼는지, Log로 무슨 작업이었는지, Event로 스케줄링 변화가 있었는지를 함께 봐야 합니다.
WhaTap Kubernetes Monitoring의 통합 관점
와탭은 인프라 (Cluster/Node) → 컨테이너 (Pod) → 애플리케이션 (Service) 세 계층을 한 프로젝트 안에서 일원화된 시각으로 제공합니다.
- Cluster: 클러스터 전체 자원·상태 요약
- Node: 워커 노드별 CPU·메모리·네트워크·디스크
- Pod / Container: 컨테이너 단위 자원 사용 + 재시작 이력
- Service (애플리케이션): WAS/앱 APM 연동으로 Trace·에러 분석
덕분에 인프라 관리자와 애플리케이션 개발자가 같은 실시간 데이터를 보며 커뮤니케이션할 수 있습니다.
상세 기능: Kubernetes 모니터링 소개
과거 시점 분석도 가능
문제가 발생한 과거 시점(배포 전후, 특정 장애 시간)의 Trace·Metric·Log·Event를 자동 수집·저장하므로, 재현 없이 과거 상황을 그대로 돌려볼 수 있습니다. "어제 새벽 3시에 발생한 Pod Evict이 왜 일어났는지"를 지금 앉아서 분석할 수 있습니다.
관찰 시나리오 예시
특정 서비스가 느려졌을 때
- 서비스 대시보드에서 응답 시간·에러율 이상 확인
- 트랜잭션 트레이스로 느린 요청의 호출 스택 확인 → DB/외부 호출 중 어느 곳이 병목인지
- 해당 Pod의 컨테이너 리소스 확인 → CPU/메모리 고갈 여부
- 동시간대 K8s 이벤트에서 Pod 재시작/스케줄링 변화 확인
- 필요시 컨테이너 로그에서 에러 메시지 조회
Pod가 반복 재시작될 때
- K8s 이벤트에서 재시작 횟수·사유(OOMKilled, CrashLoopBackOff 등) 확인
- 재시작 전 시점의 Pod 메모리 사용률·애플리케이션 로그를 타임라인에 맞춰 비교
- 트래픽 급증 여부는 상위 Service 대시보드에서 교차 확인
다음 단계
- 설치·초기 설정 → Kubernetes 모니터링 설치
- 컨테이너 맵으로 네트워크 관계 파악 → 컨테이너 맵
- 애플리케이션 연동 → Kubernetes + APM 통합 관찰 (APM 자동 설치)
- GPU 워크로드 모니터링 → GPU 대시보드
- 장애 대응 루틴 → 장애 대응 시나리오