현대 오토에버 클라우드 스쿨
K8S 프로젝트 중) Infra level metrics 수집
Gom3rye
2025. 9. 26. 10:41
728x90
반응형
👉 node-exporter / cAdvisor / kube-state-metrics는 **셋 다 “인프라 레벨 메트릭”**이에요.
하지만 수집하는 대상과 범위가 완전히 다르기 때문에 3개 모두를 쓰는 게 일반적입니다.
아래에서 하나씩 비교해볼게요 👇
🧠 1️⃣ node-exporter — “노드(호스트) 레벨 메트릭”
항목설명
| 📍 수집 대상 | Kubernetes 노드(OS 수준) |
| 📊 주요 지표 | - CPU 사용량 (전체/idle/steal 등) - 메모리 총량·사용량 - 디스크 I/O 속도 및 사용량 - 네트워크 패킷 수/에러율 - 파일시스템 사용률 |
| 📌 포지션 | VM / 물리 서버 / 호스트 OS 수준의 인프라 관찰 |
| 📊 예시 메트릭 | node_cpu_seconds_total, node_memory_MemAvailable_bytes, node_network_receive_bytes_total |
📊 쉽게 말해:
👉 “노드 자체가 과부하인지?”, “메모리가 모자란지?”, “디스크가 꽉 찼는지?” 같은 시스템 레벨 상태를 알려주는 역할이에요.
🔎 예시:
- 어떤 Pod가 CPU를 100% 먹는지 알 수는 없지만, 노드 전체가 CPU 90%를 먹고 있다는 건 알 수 있어요.
🐳 2️⃣ cAdvisor — “컨테이너 / Pod 레벨 메트릭”
항목설명
| 📍 수집 대상 | 각 노드의 Kubelet → 컨테이너(cgroup) |
| 📊 주요 지표 | - Pod별 CPU 사용량 / 메모리 사용량 - Container별 네트워크 I/O, 디스크 I/O - 컨테이너 재시작 횟수 등 |
| 📌 포지션 | Pod/Container 리소스 소비량 관찰 |
| 📊 예시 메트릭 | container_cpu_usage_seconds_total, container_memory_usage_bytes, container_fs_usage_bytes |
📊 쉽게 말해:
👉 “노드 안에서 어떤 파드가 리소스를 얼마나 쓰는지”를 알려주는 역할이에요.
🔎 예시:
- node-exporter로는 “CPU 90% 사용”까지만 알 수 있다면,
- cAdvisor로는 “그 중 70%를 api-server-pod가 쓰고 있다”까지 알 수 있어요.
✅ 즉, node-exporter가 ‘전체 호스트 리소스’를 보여준다면, cAdvisor는 ‘파드별 리소스 상세’를 보여줍니다.
📦 3️⃣ kube-state-metrics — “쿠버네티스 리소스 상태 메트릭”
항목설명
| 📍 수집 대상 | Kubernetes API Server → 리소스 오브젝트 상태 |
| 📊 주요 지표 | - Deployment / StatefulSet replica 수 (desired vs available) - Pod 상태 (Running / CrashLoopBackOff 등) - PVC 용량, PersistentVolume 상태 - DaemonSet, CronJob 등 오브젝트 상태 |
| 📌 포지션 | 쿠버네티스 오브젝트 상태 / Desired vs Actual 차이 관찰 |
| 📊 예시 메트릭 | kube_deployment_status_replicas_available, kube_pod_status_phase, kube_persistentvolume_status_phase |
📊 쉽게 말해:
👉 이건 리소스 사용량이 아니라 쿠버네티스 “객체 상태”를 논리적으로 모니터링하는 역할이에요.
🔎 예시:
- “ReplicaSet이 5개여야 하는데 2개만 떠 있다”
- “Pod가 CrashLoopBackOff 상태다”
- “PVC가 Pending 상태다”
이런 건 node-exporter나 cAdvisor는 절대 못 잡아요.
📊 총정리: 3개의 역할 비교
비교 항목node-exportercAdvisorkube-state-metrics
| 📍 수집 대상 | 노드(호스트) | Pod/컨테이너 (cgroup) | 쿠버네티스 리소스 (API) |
| 📊 주요 관점 | 하드웨어/OS 리소스 상태 | 워크로드별 리소스 소비 | 리소스 상태/헬스 |
| 📈 메트릭 범위 | 전체 CPU/메모리/디스크/네트워크 | Pod·Container별 CPU/메모리/IO | Deployment, Pod, PVC 상태 |
| 🧭 질문 예시 | “이 노드 CPU가 90%야?” | “어떤 파드가 CPU 제일 많이 써?” | “Replica가 원하는 만큼 떴어?” |
| 🔥 없으면 알 수 없는 것 | 노드 부하 여부 | Pod별 리소스 상세 | 리소스 상태 이상 여부 |
✅ 핵심 정리
- node-exporter → "서버(노드)가 괜찮은지"
- cAdvisor → "어떤 Pod가 리소스를 먹고 있는지"
- kube-state-metrics → "쿠버네티스 리소스 상태가 정상인지"
이 3개는 서로 대체 관계가 아니라 보완 관계예요.
📌 왜 실무에서 3개를 다 쓰는가?
실제 운영 환경에서는 문제를 이렇게 “탐지 → 추적 → 원인 분석” 순서로 진행합니다:
- node-exporter
- CPU 95% 사용! → “노드가 과부하 상태임” 감지
- cAdvisor
- recommendation-api-pod가 CPU 85% 사용 중 → “가해자 파드” 추적
- kube-state-metrics
- 해당 Deployment의 replicas 2/5 상태 → “스케일링 실패” 또는 “CrashLoopBackOff” 원인 파악
즉, 세 단계를 연결해서 보면 문제를 “탐지-원인-조치”까지 완전히 연결할 수 있습니다.
✅ 최종 결론:
- cAdvisor, kube-state-metrics도 인프라 레벨입니다. (서비스 메트릭이 아니에요)
- 하지만 node-exporter와 “레벨이 다르기” 때문에 서로 보완하는 관계입니다.
- 이 세 가지를 모두 써야 실제 운영 환경에서 “문제가 생겼을 때 어디서부터 어디까지 추적할 수 있는지”가 확보됩니다.
💡 참고로 “서비스 레벨 메트릭”이라고 부르는 건 이런 것들이에요:
- HTTP 요청 수 (http_requests_total)
- 에러율 (http_requests_total{status=~"5.."})
- 처리 시간 (request_duration_seconds_bucket)
- DB 쿼리 시간, 캐시 히트율, 비즈니스 로직 성능
➡️ 이런 건 Pod 자동탐색 + 애플리케이션이 /metrics를 직접 노출해야만 수집됩니다.
(즉, “서비스 레벨” = 앱 코드에서 내보내는 지표예요.)
📊 전체 관측 계층 구조 (Infra → Pod → K8s → Service)
┌──────────────────────────────────────────┐
│ 📈 서비스 레벨 │
│──────────────────────────────────────────│
│ 예: API 요청 수, 에러율, 응답시간, DB 쿼리 속도 │
│ → 앱 코드가 /metrics로 직접 노출해야 수집 가능 │
│ → Pod 자동탐색(prometheus.io/scrape: "true") 필요 │
└──────────────────────────────────────────┘
▲
│
┌──────────────────────────────────────────┐
│ 📦 쿠버네티스 리소스 상태 │
│ (kube-state-metrics) │
│──────────────────────────────────────────│
│ 예: Deployment replica 상태, Pod phase, PVC 상태 │
│ → Kubernetes API를 통해 논리적 리소스 상태 수집 │
│ → 앱 상태가 CrashLoopBackOff인지, Replica가 맞는지 │
└──────────────────────────────────────────┘
▲
│
┌──────────────────────────────────────────┐
│ 🐳 Pod/컨테이너 리소스 메트릭 │
│ (cAdvisor / Kubelet) │
│──────────────────────────────────────────│
│ 예: Pod별 CPU/메모리 사용량, I/O, 네트워크 │
│ → 어떤 Pod가 리소스를 얼마나 쓰는지 분석 │
│ → “누가” 과부하를 유발하는지 추적 가능 │
└──────────────────────────────────────────┘
▲
│
┌──────────────────────────────────────────┐
│ 🖥️ 노드(호스트) 메트릭 │
│ (node-exporter) │
│──────────────────────────────────────────│
│ 예: 전체 CPU, 메모리, 디스크, 네트워크 상태 │
│ → 노드 단위에서 과부하 감지 및 리소스 용량 확인 │
└──────────────────────────────────────────┘✅ 이 구조를 기억하면 아래처럼 단계별로 “문제 원인을 추적”할 수 있어요:
단계예시 상황모니터링 지표 예
| 1️⃣ node-exporter | CPU가 95%다 | node_cpu_seconds_total |
| 2️⃣ cAdvisor | 어떤 Pod가 먹고 있는지 | container_cpu_usage_seconds_total |
| 3️⃣ kube-state-metrics | Pod 상태 이상 여부 | kube_pod_status_phase |
| 4️⃣ 서비스 레벨 | 요청 처리량 급증 여부 | http_requests_total / http_request_duration_seconds |
📊 Grafana에서 보통 이렇게 대시보드가 나뉩니다
🖥️ [대시보드 1: Node Infra Dashboard]
📌 데이터 소스: node-exporter
메트릭설명
| CPU Usage (%) | 노드 CPU 전체 사용량 |
| Memory Usage (%) | 사용 가능 메모리 vs 전체 메모리 |
| Disk I/O | 초당 읽기/쓰기 속도 |
| Network Traffic | 초당 패킷 송수신량 |
✅ 목적: 노드 레벨에서 전체 클러스터 자원이 안정적인지 감지
🐳 [대시보드 2: Pod/Container Resource Dashboard]
📌 데이터 소스: cAdvisor
메트릭설명
| Top 5 Pods by CPU | CPU를 가장 많이 쓰는 파드 목록 |
| Top 5 Pods by Memory | 메모리를 가장 많이 쓰는 파드 목록 |
| Container Restart Count | 재시작 횟수 모니터링 |
| Container Network I/O | 컨테이너별 네트워크 사용량 |
✅ 목적: “누가 자원을 많이 쓰고 있는지” 한눈에 파악
📦 [대시보드 3: Kubernetes Object Health]
📌 데이터 소스: kube-state-metrics
메트릭설명
| Deployment Replicas (desired vs available) | 원하는 파드 수와 실제 파드 수 비교 |
| Pod Status by Namespace | Running / Pending / CrashLoopBackOff 상태 |
| PVC Capacity / Usage | 스토리지 용량 확인 |
| Job / CronJob Success Rate | 배치 작업 성공률 |
✅ 목적: 리소스 상태 이상 조기 감지 (스케일링 실패, PVC 부족, Pod 충돌 등)
📈 [대시보드 4: Application & Business Metrics]
📌 데이터 소스: Pod 자동탐색 (서비스가 /metrics 노출)
메트릭설명
| HTTP Request Rate (RPS) | 초당 요청 수 |
| Error Rate (5xx/4xx) | 에러 발생률 |
| Request Latency (p95, p99) | 응답 지연 시간 |
| Custom Business Metric | 예: 주문 성공 수, 로그인 시도 횟수 등 |
✅ 목적: 실제 서비스 수준(SLO, SLA) 관점에서 사용자 경험 모니터링
🧠 최종 요약
구성요소관측 대상수집 계층수집 목적필수 여부
| node-exporter | 노드(호스트) | 인프라 레벨 | 자원 과부하 감지 | ✅ |
| cAdvisor | Pod/컨테이너 | 인프라 레벨 (세부) | 어떤 워크로드가 문제인지 분석 | ✅ |
| kube-state-metrics | 쿠버네티스 리소스 상태 | 인프라 레벨 (논리) | 파드/디플로이 상태, PVC 문제 확인 | ✅ |
| Pod 자동탐색 | 서비스 메트릭 | 서비스 레벨 | 요청 수, 에러율, 지연시간 분석 | ❌ (서비스별 필요 시만) |
👉 실무에서는 이 3개(Infra Layer)는 거의 필수 셋이고,
“서비스 모니터링”이 필요해지면 마지막 Pod 자동탐색을 추가해서 풀옵션으로 씁니다.
✅ 정리하자면:
- 지금처럼 node-exporter + cAdvisor + kube-state-metrics 조합만으로도 클러스터 전체 상태를 굉장히 깊이 있게 관찰할 수 있어요.
- 하지만 “서비스 성능 지표(요청 수, 에러율, 레이턴시)”를 보려면 반드시 애플리케이션이 /metrics를 노출하고 Pod 자동탐색을 활성화해야 합니다.
728x90
반응형