Monitoring - Metric Server

Kubernetes 클러스터 모니터링: 무엇을, 어떻게, 어디까지 볼 것인가 (Metrics Server 중심)

쿠버네티스를 운영(혹은 학습)하다 보면 “클러스터가 지금 정상인가?”를 넘어 “어디가 얼마나 쓰이고 있고, 언제부터 나빠졌는가?”까지 확인하고 싶어집니다. 모니터링은 결국 리소스 소비(usage)와 상태(state)를 지속적으로 수집·저장·분석해서 장애 예방/용량 계획/오토스케일링 의사결정을 가능하게 하는 체계입니다.

이 글에서는 강의 스크립트의 흐름을 기반으로, 쿠버네티스 모니터링에서 가장 먼저 만나게 되는 Metrics Server를 중심으로 전체 그림을 깔끔하게 정리합니다. (필요한 부분은 용어/명령/구성을 정확한 형태로 다듬었습니다.)

---

1) Kubernetes에서 “무엇을 모니터링”해야 하나?

보통 아래 3개 축으로 나누면 빠르게 정리가 됩니다.

(1) 노드(Node) 수준 메트릭

• 전체 노드 수 / Ready(정상) 노드 수
• 노드별 CPU / 메모리 사용량
• (확장) 네트워크, 디스크 I/O, 파일시스템 사용량 등

(2) 성능(Performance) 메트릭

• CPU 사용률(코어 기준 사용량)
• 메모리 사용량(working set 등)
• (확장) 네트워크 트래픽, 디스크 I/O, 파일시스템 용량

(3) 파드(Pod) 수준 메트릭

• 파드 수, 네임스페이스별 파드 분포
• 파드/컨테이너별 CPU·메모리 사용량
• (확장) 요청/제한(Requests/Limits) 대비 사용량, OOMKilled/재시작 등

이걸 “보는 것”에서 끝내면 안 되고, 저장하고(장기 보관), 분석하고(대시보드/알람), 자동화(HPA 등)까지 가야 운영에 의미가 생깁니다.

---

2) Kubernetes에 “기본 제공 모니터링”이 없는 이유와 현실적인 선택지

강의 스크립트의 요지는 정확합니다:

• 쿠버네티스는 “완전한 풀스택 모니터링”을 기본으로 제공하지 않습니다.
• 대신 생태계에서 다음 솔루션들이 많이 쓰입니다:
  • Metrics Server: 쿠버네티스 리소스 메트릭(CPU/메모리)의 표준 파이프라인(가볍고 필수에 가깝다)
  • Prometheus(+ Grafana): 시계열 저장 + 강력한 쿼리/알람
  • Elastic Stack: 로그/이벤트 중심 분석(메트릭도 가능)
  • Datadog / Dynatrace: 상용 올인원(에이전트 + 대시보드 + APM 등)

특히 Metrics Server는 “대시보드/장기 저장”이 아니라, K8s가 CPU/메모리 usage를 표준 API로 노출하도록 만드는 구성 요소라는 관점이 중요합니다. Kubernetes 공식 문서도 Metrics Server가 Metrics API를 구현하고 오토스케일러에 리소스 사용량을 공급하는 역할임을 명확히 설명합니다. (Kubernetes)

---

3) Heapster → Metrics Server: 역사 정리 

• Heapster는 예전에 쿠버네티스 모니터링/분석 참조 아키텍처에서 많이 언급되던 프로젝트였습니다.
• 하지만 현재는 deprecated(더 이상 권장되지 않음) 되었고,
• Metrics Server가 “리소스 메트릭 파이프라인”의 슬림한 표준 구현체로 자리 잡았습니다. (GitHub)

---

4) Metrics Server 아키텍처: 메트릭은 어디서 생성되고 어떻게 수집되나?

핵심 흐름은 아래와 같습니다.

1. 각 노드에는 kubelet이 떠 있습니다.
2. kubelet은 노드에서 파드를 실행/관리하고, 노드/컨테이너의 리소스 메트릭을 제공하는 엔드포인트를 갖습니다.
3. Metrics Server는 각 노드의 kubelet로부터 메트릭을 주기적으로 가져와(스크레이프/폴링) 집계(aggregation) 합니다.
4. 그 결과를 쿠버네티스 표준 API인 metrics.k8s.io (Metrics API) 로 노출합니다. (Kubernetes)
5. kubectl top, HPA 같은 컴포넌트가 이 Metrics API를 조회합니다. (Kubernetes)

간단 다이어그램(개념):

[Pod/Container] -> (node) kubelet ----\
                                       \  scrape
                                        -> [metrics-server] -> metrics.k8s.io API
                                       /                        |
(other nodes kubelet) ----------------/                         +--> kubectl top
                                                                +--> HPA/VPA (resource 기반)

중요한 제한: “인메모리” 저장 (장기 보관 불가)

Metrics Server는 메트릭을 디스크에 장기 저장하지 않고 인메모리로만 유지합니다. 즉,

• “지금” 또는 “최근” 사용량 스냅샷에는 강하지만
• “어제/지난주/지난달 대비 추세” 같은 과거 성능 분석은 불가능

그래서 운영에서는 Prometheus 같은 TSDB(시계열 DB) 또는 상용 솔루션과 함께 쓰는 경우가 대부분입니다. (강의 흐름도 이 지점에서 “고급 모니터링 솔루션”으로 확장하죠.)

---

5) 설치: Minikube vs 일반 클러스터

(A) Minikube

Minikube는 애드온으로 Metrics Server를 켤 수 있습니다.

minikube addons enable metrics-server

(B) 그 외(일반 Kubernetes / 관리형 포함)

공식 repo의 최신 릴리스 매니페스트를 적용하는 방식이 가장 흔합니다.

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

위 설치 방식은 Metrics Server 공식 설치 가이드에 명시되어 있습니다. (GitHub)

참고: 운영 환경에서 고가용성이 필요하면 HA 매니페스트(예: high-availability-1.21+.yaml)도 공식적으로 제공됩니다. (GitHub)

---

6) 설치 확인과 사용: kubectl top node/pod

Metrics Server는 설치 직후 바로 수치가 안 나올 수 있습니다. (수집/집계 파이프라인에 약간의 지연이 있음) Kubernetes 문서도 kubectl top pod에 대해 “파드 생성 후 몇 분간 메트릭이 없을 수 있다”고 언급합니다. (Kubernetes)

노드 리소스 사용량 보기

kubectl top node
# 또는 특정 노드만
kubectl top node <node-name>

공식 kubectl 문서: kubectl top node는 노드의 CPU/메모리 사용량을 보여줍니다. (Kubernetes)

파드 리소스 사용량 보기

kubectl top pod
# 네임스페이스 지정
kubectl top pod -n <namespace>
# 특정 파드만
kubectl top pod <pod-name> -n <namespace>

공식 kubectl 문서: kubectl top pod는 파드의 CPU/메모리 사용량을 보여줍니다. (Kubernetes)

“kubectl top이 어디서 가져오는데?”

kubectl top 자체 문서에 “Metrics Server가 kubelet에서 데이터를 집계해 제공하며, 이게 설치되어 있어야 동작한다”가 명시되어 있습니다. (Kubernetes)

---

7) Metrics API를 직접 조회해보기 (문제 진단에 매우 유용)

kubectl top이 애매하게 실패할 때, Metrics API를 직접 치면 원인을 더 빨리 파악할 수 있습니다.

# 노드 메트릭 조회 (예: minikube)
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes/minikube"

# 파드 메트릭 조회 (네임스페이스/파드명 조합)
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/default/pods"

Kubernetes 공식 문서의 “Resource metrics pipeline” 섹션에 동일한 방식의 예시가 있습니다. (Kubernetes)

---

8) 운영에서 자주 부딪히는 포인트(필수 체크리스트)

(1) “메트릭은 보이는데, 과거 데이터를 보고 싶다”

• Metrics Server는 장기 저장을 하지 않습니다 → Prometheus/Grafana 또는 상용 솔루션이 필요합니다. (Kubernetes)

(2) “kubectl top이 NotFound / metrics not available”

• Metrics Server가 설치되어 있는지 확인
• metrics.k8s.io APIService 상태 확인(개념적으로는 API aggregation 체계에서 연결됨)
• 설치 직후라면 몇 분 기다린 뒤 재시도 (Kubernetes)

(3) “노드가 많아지면?”

• Metrics Server는 클러스터당 1개가 보통이지만, HA 모드(레플리카 증가) 구성도 공식 가이드가 있습니다. (GitHub)

---

9) 어디까지가 Metrics Server의 역할인가?

정리하면:

• Metrics Server = 쿠버네티스 표준 리소스 메트릭(CPU/메모리) 파이프라인의 구현체
  • kubectl top, HPA 같은 기능을 위해 “거의 필수”
  • 가볍고 빠르게 “현재 사용량”을 보기 좋음
  • 하지만 장기 저장/대시보드/정교한 알람은 범위 밖 (Kubernetes)
• Prometheus/Elastic/Datadog/Dynatrace = “운영 모니터링 플랫폼”
  • 저장(장기) + 쿼리 + 대시보드 + 알람 + (상용이면) APM/트레이싱까지

---

10) 실습 루틴(추천)

1. Metrics Server 설치

• Minikube: minikube addons enable metrics-server
• 일반: kubectl apply -f .../components.yaml (GitHub)

2. 메트릭 생성/수집 대기 (수 분)
3. 확인

kubectl top node
kubectl top pod -A

4. 문제 시 Metrics API 직접 조회

kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes"

 

 

Practice Test - https://uklabs.kodekloud.com/topic/practice-test-monitor-cluster-components-2/