Kubernetes Monitoring Lab 정리: Datadog, Prometheus, Grafana 실습

Kubernetes Monitoring Lab Summary

Datadog, Prometheus, Grafana를 이용한 Kubernetes 모니터링 실습 정리입니다. Datadog 설치 흐름, Prometheus/Grafana 구성, Dashboard 6417 N/A 해결 과정을 포함합니다.

2026-05-13 Kubernetes Monitoring Lab Summary

0. 실습 환경

오늘 실습은 Windows PowerShell에서 minikube 프로필 argocd-lab을 대상으로 진행했다.

처음 확인한 기본 상태는 다음과 같았다.

minikube start -p argocd-lab
kubectl get nodes

결과적으로 argocd-lab 노드는 Ready 상태였고, Kubernetes는 v1.31.0, 컨테이너 런타임은 Docker였다. 중간에 registry.k8s.io 접속 경고가 있었지만, 기존 컨테이너와 필요한 이미지가 동작하는 데에는 바로 치명적인 문제로 이어지지는 않았다.

이번 실습의 큰 흐름은 다음과 같다.

Datadog 웹 UI
  |
  +-- Free Trial
  +-- Agent Setup
  +-- New Installation 명령 복사
        |
        +-- 워커 노드 또는 minikube 노드에서 Agent 설치/시작
        |
        +-- 추가 확인 과정: Datadog Operator + DatadogAgent CR
              +-- Datadog Agent / Cluster Agent
  |
  +-- Prometheus
  |     +-- Kubernetes API / cAdvisor / Pod annotations
  |     +-- kube-state-metrics
  |     +-- node-exporter
  |
  +-- Grafana
        +-- Prometheus Data Source
        +-- Dashboard 6417

핵심은 Datadog은 노드와 컨테이너에서 수집된 정보를 외부 Datadog SaaS로 보내는 방식이고, Prometheus와 Grafana는 클러스터 안에서 메트릭을 수집하고 시각화하는 방식이라는 점이다.

0.1 Datadog과 Prometheus/Grafana를 둘 다 설정한 이유

이번 실습에서 Datadog도 설치하고 Prometheus/Grafana도 따로 구성한 이유는 같은 Kubernetes 모니터링을 두 가지 방식으로 비교하기 위해서다.

Datadog은 관리형 SaaS 모니터링 방식이다. Datadog Agent가 노드와 컨테이너, Kubernetes 상태 정보를 수집하고, 그 결과를 외부 Datadog 서비스로 전송한다. 사용자는 Datadog 웹 UI에서 인프라 상태, 컨테이너 상태, 이벤트, 대시보드, 알림을 통합해서 본다. 실무에서는 빠르게 붙이고 운영 화면을 바로 얻을 수 있다는 장점이 있다.

Prometheus와 Grafana는 직접 구축하는 오픈소스 모니터링 방식이다. Prometheus가 Kubernetes 내부에서 메트릭을 직접 수집하고 저장하며, Grafana는 Prometheus를 Data Source로 연결해서 대시보드로 시각화한다. 이 방식은 어떤 메트릭을 어디서 가져오는지, 왜 어떤 패널이 N/A가 되는지, PromQL을 어떻게 고쳐야 하는지를 직접 확인할 수 있다.

Datadog
  = 관리형 SaaS 모니터링
  = Agent 설치 후 Datadog 웹 UI에서 통합 관제
  = 빠르게 결과를 확인하기 좋음

Prometheus + Grafana
  = 직접 구축형 오픈소스 모니터링
  = Prometheus가 수집하고 Grafana가 시각화
  = exporter, scrape, PromQL 구조를 이해하기 좋음

따라서 두 도구를 모두 다룬 것은 단순 중복이 아니다. Datadog으로는 상용 모니터링 도구의 운영 흐름을 보고, Prometheus/Grafana로는 Kubernetes 메트릭 수집 구조와 대시보드 쿼리 문제를 직접 분석한 것이다. 특히 Dashboard 6417의 N/A 문제는 Prometheus 수집 대상과 PromQL이 맞아야 데이터가 나온다는 점을 확인하는 핵심 실습이었다.

0.2 Kubernetes 모니터링 구조 전체 흐름

Kubernetes 클러스터에는 여러 노드가 있고, 그 노드 안에서 여러 Pod가 실행된다. 운영자가 궁금한 것은 단순히 "Pod가 떠 있다"가 아니라, 실제로 CPU와 메모리를 얼마나 쓰는지, 디스크가 부족하지 않은지, Pod와 Node가 정상인지, 장애가 나면 알림을 받을 수 있는지, 부하가 커지면 Pod 수를 자동으로 늘릴 수 있는지다.

Kubernetes Cluster
  |
  +-- Control Plane
  |     +-- API Server
  |
  +-- Worker Node 1
  |     +-- Application Pod
  |     +-- Node Exporter
  |     +-- Datadog Agent
  |
  +-- Worker Node 2
        +-- Application Pod
        +-- Node Exporter
        +-- Datadog Agent

이 문제를 해결하기 위해 Datadog, Prometheus, Grafana, Alertmanager, Node Exporter, HPA, LimitRange 같은 구성 요소가 등장한다. 각 도구의 역할은 겹쳐 보이지만 실제 책임은 다르다.

Datadog
  = Agent 기반 SaaS 모니터링
  = 각 노드의 상태를 수집해 Datadog 서버로 전송

Node Exporter
  = 노드 CPU, 메모리, 디스크, 네트워크 정보를 /metrics로 공개

Prometheus
  = /metrics 엔드포인트를 주기적으로 scrape
  = 메트릭 저장
  = 알림 조건 평가

Grafana
  = Prometheus에 쿼리
  = 대시보드와 그래프로 시각화

Alertmanager
  = Prometheus가 발생시킨 알림을 Slack, Email, Webhook으로 전달

HPA
  = 메트릭 기준으로 Deployment replica 수 조정

LimitRange
  = Namespace 안의 CPU/Memory request, limit 정책 강제

Datadog 구조는 각 노드에 Datadog Agent를 배치하고, Agent가 수집한 정보를 Datadog SaaS로 전송하는 방식이다. Kubernetes에서는 보통 DaemonSet으로 배포한다. DaemonSet은 모든 워커 노드마다 Pod를 하나씩 배치하는 방식이므로, 노드가 3개면 Datadog Agent Pod도 3개가 실행된다.

Worker Node 1 -> Datadog Agent
Worker Node 2 -> Datadog Agent
Worker Node 3 -> Datadog Agent

Datadog Agent
  -> Node / Pod / Container 상태 수집
  -> Kubernetes API Server를 통해 Namespace, Pod, Node 메타데이터 확인
  -> Datadog SaaS로 전송
  -> Datadog 웹 UI에서 확인

여기서 Kubernetes API Server가 필요한 이유는 메트릭 값에 의미를 붙이기 위해서다. 단순히 CPU 80%만 있으면 운영자는 어느 Pod에서 발생한 값인지 알 수 없다. API Server에서 메타데이터를 함께 확인하면 다음처럼 해석 가능한 정보가 된다.

namespace: monitoring
pod: grafana-55fb79fcf6-cn6k6
node: argocd-lab
container: grafana
cpu: 80%

Prometheus 구조는 Datadog과 다르다. Datadog은 Agent가 수집 결과를 외부 Datadog 서버로 보내는 흐름이 중심이고, Prometheus는 중앙의 Prometheus 서버가 수집 대상에 직접 접근해 메트릭을 가져오는 흐름이 중심이다. 이 방식을 Pull 방식이라고 하고, Prometheus에서는 이를 scrape라고 부른다.

Prometheus -> "메트릭 있나요?"
Target     -> "네, /metrics에 있습니다."
Prometheus -> 가져와서 저장

Node Exporter는 Prometheus가 노드 상태를 가져갈 수 있도록 /metrics 엔드포인트를 제공하는 프로그램이다. Node Exporter가 판단을 하거나 알림을 보내는 것은 아니다. Node Exporter는 CPU, 메모리, 디스크, 네트워크 같은 노드 상태를 Prometheus 형식으로 공개하고, Prometheus가 주기적으로 가져간다.

Node Exporter
  -> Node CPU / Memory / Disk / Network 정보 읽기
  -> http://node-exporter:9100/metrics 로 공개

Prometheus
  -> node-exporter:9100/metrics 를 주기적으로 scrape
  -> 메트릭 저장
  -> 조건 평가

정확히 나누면 다음과 같다.

데이터를 준비하고 공개하는 주체 = Node Exporter
데이터를 실제로 가져가는 주체 = Prometheus
데이터를 저장하고 조건을 판단하는 주체 = Prometheus
알림을 묶고 전송하는 주체 = Alertmanager
그래프와 대시보드로 보여주는 주체 = Grafana

Prometheus에서 ConfigMap은 핵심 설정 파일 역할을 한다. Deployment는 Prometheus Pod를 실행하고, ConfigMap은 Prometheus가 어떻게 동작할지 알려준다.

Prometheus Deployment
  -> prom/prometheus 이미지로 Pod 실행
  -> --config.file=/etc/prometheus/prometheus.yml 사용

Prometheus ConfigMap
  -> prometheus.yml 제공
  -> scrape 대상 정의
  -> scrape 주기 정의
  -> alert rule 정의
  -> Alertmanager 주소 정의

즉 "ConfigMap에 조건이 있어서 Prometheus가 모니터링을 시작한다"는 이해는 방향이 맞다. 더 정확히는 ConfigMap에 어디를 수집할지, 얼마나 자주 수집할지, 어떤 조건을 알림으로 볼지, 알림을 어디로 보낼지가 들어 있고, Prometheus Pod가 그 설정 파일을 읽어서 동작한다.

예를 들어 수집 대상 설정은 이런 의미다.

scrape_configs:
  - job_name: node-exporter
    static_configs:
      - targets:
          - node-exporter:9100

이 설정은 Prometheus에게 node-exporter:9100으로 가서 메트릭을 가져오라고 알려준다.

알림 조건은 이런 의미다.

groups:
  - name: node-alerts
    rules:
      - alert: HighCpuUsage
        expr: cpu_usage > 80
        for: 5m

이 설정은 CPU 사용률이 80%를 넘는 상태가 5분 이상 유지되면 알림을 발생시키라는 뜻이다. 실제 알림 전송은 보통 Alertmanager가 맡는다.

Grafana는 수집기가 아니다. Grafana는 Prometheus에 저장된 데이터를 보기 좋게 보여주는 UI다. 따라서 일반적인 흐름은 Grafana -> Node Exporter가 아니라 Grafana -> Prometheus -> Node Exporter에서 수집한 데이터다.

Grafana
  -> Prometheus Data Source로 쿼리
  -> Prometheus가 저장한 메트릭 반환
  -> Grafana가 차트와 대시보드로 표시

Alertmanager는 Prometheus가 발생시킨 알림을 실제 사용자에게 전달하는 역할이다. 단순 전달만 하는 것이 아니라 중복 알림을 줄이고, 알림을 묶고, 심각도나 라벨에 따라 Slack, Email, Webhook 같은 서로 다른 채널로 라우팅할 수 있다.

PV는 PersistentVolume이다. Prometheus는 시간별 메트릭 데이터를 계속 저장한다. Pod 내부 저장소만 사용하면 Prometheus Pod가 재시작될 때 과거 데이터가 사라질 수 있다. PV를 붙이면 Prometheus Pod가 다시 떠도 기존 메트릭 데이터를 유지할 수 있다.

Prometheus Pod 재시작
  -> PV가 있으면 기존 메트릭 데이터 유지
  -> 과거 그래프 확인 가능

monitoring Namespace를 만든 이유는 Prometheus, Grafana, Alertmanager, Node Exporter, kube-state-metrics 같은 모니터링 리소스를 일반 애플리케이션과 분리해서 관리하기 위해서다.

monitoring Namespace
  +-- Prometheus
  +-- Grafana
  +-- Alertmanager
  +-- Node Exporter
  +-- kube-state-metrics

LimitRange와 HPA는 모니터링 도구라기보다는 리소스 정책과 자동 조정 도구다. Prometheus, Grafana, Node Exporter는 관측과 시각화에 가깝고, LimitRange와 HPA는 Kubernetes 리소스 사용 방식을 제한하거나 조정한다.

Prometheus / Grafana / Node Exporter
  = 감시, 수집, 저장, 시각화

LimitRange / HPA / VPA / Cluster Autoscaler
  = 제한, 조정, 자동 확장

LimitRange는 Namespace 안의 컨테이너가 사용할 수 있는 CPU/Memory request와 limit의 기본값, 최소값, 최대값을 강제한다. HPA는 CPU 사용률이나 메트릭 값을 보고 Deployment의 replica 수를 늘리거나 줄인다.

CPU 사용률 증가
  -> Metrics Server 또는 Custom Metrics에서 값 확인
  -> HPA가 판단
  -> Deployment replica 수 증가
  -> Pod 개수 증가
  -> 트래픽 분산

이 실습 전체를 한 장의 흐름으로 정리하면 다음과 같다.

[Worker Node]
  +-- Application Pod
  +-- Node Exporter
        +-- /metrics 공개

        ↑ scrape

[Prometheus]
  +-- ConfigMap 설정 읽음
  +-- Node Exporter / App / kube-state-metrics에서 메트릭 수집
  +-- 메트릭 저장
  +-- PV에 데이터 보존
  +-- 알림 조건 평가

        ↓ 알림 발생

[Alertmanager]
  +-- Slack / Email / Webhook 전송

        ↑ 데이터 조회

[Grafana]
  +-- Prometheus를 Data Source로 등록
  +-- 대시보드 UI 제공

[HPA / LimitRange]
  +-- HPA: 메트릭 기준으로 Pod 수 자동 조정
  +-- LimitRange: Namespace 리소스 사용 규칙 제한

결론적으로 전체 구조는 Node Exporter가 노드 상태를 Prometheus가 가져갈 수 있게 공개하고, Prometheus는 ConfigMap 설정에 따라 메트릭을 수집, 저장, 알림 판단을 한다. Grafana는 Prometheus 데이터를 UI로 보여주고, Alertmanager는 문제 발생 시 알림을 보낸다. HPA와 LimitRange는 관측 결과나 정책을 바탕으로 리소스를 조정하거나 제한하는 쪽에 가깝다.

1. Datadog 설치 및 확인

이 실습의 첫 번째 큰 작업은 Datadog 웹페이지에서 Free Trial 환경을 만들고, Datadog 화면이 안내하는 Agent 설치 명령을 복사해서 Kubernetes 노드 쪽에 실행한 것이다.

1.0 설치 전에 이해해야 할 Datadog 구조

Datadog 설치 전에 먼저 봐야 하는 개념은 Datadog Agent의 배치 위치, 수집 대상, 전송 대상이다.

책 그림의 핵심은 다음이다.

워커 노드마다 Datadog Agent Pod가 배치된다.
노드의 CPU, 메모리, 디스크, 네트워크, 컨테이너 상태가 수집 대상이다.
Pod, Namespace, Node 같은 Kubernetes 메타데이터는 API Server를 통해 확인된다.
수집된 메트릭과 메타데이터는 Datadog SaaS로 전송된다.
사용자는 Datadog 웹 UI에서 그 결과를 본다.

아래 구조도는 같은 개념을 실습 환경 기준으로 정리한 것이다.

Datadog Kubernetes 메트릭 수집 구조

Datadog SaaS / Dashboard

↑

메트릭 + 태그 전송

Control Plane
Kubernetes API Server

Kubernetes Cluster

DaemonSet 방식이면 워커 노드마다 Datadog Agent Pod가 하나씩 배치된다.

Worker Node 1

Datadog Agent

Worker Node 2

Datadog Agent

Worker Node N

Datadog Agent

각 노드의 CPU, Memory, Disk, Network, Container 정보 수집
API Server를 통해 Pod / Namespace / Node 메타데이터 확인

이 그림에서 각 요소의 의미는 다음과 같다.

Datadog SaaS / Dashboard
  수집된 메트릭이 최종적으로 올라가는 외부 Datadog 서버다.
  사용자는 브라우저에서 이 화면을 보고 모니터링한다.

Kubernetes API Server
  클러스터 상태 정보를 제공하는 중앙 API다.
  Pod가 어느 Namespace에 있는지, 어느 Node에 떠 있는지, 상태가 어떤지 같은 정보를 제공한다.

Worker Node
  실제 애플리케이션 Pod와 컨테이너가 실행되는 서버다.

Datadog Agent
  각 Worker Node에 배치되어 노드와 컨테이너 메트릭 수집을 담당하는 프로그램이다.

여기서 DaemonSet이라는 말이 중요하다.

DaemonSet은 Kubernetes에서 모든 워커 노드마다 Pod를 하나씩 자동으로 배치하는 방식이다. Datadog Agent의 DaemonSet 배포에서는 노드가 3개일 때 Agent Pod도 3개, 노드가 10개일 때 Agent Pod도 10개가 실행된다.

이렇게 구성하는 이유는 각 노드의 CPU, 메모리, 디스크, 네트워크, 컨테이너 상태가 노드 단위로 발생하기 때문이다. 따라서 노드마다 수집용 Pod를 배치해야 각 노드의 상태를 빠짐없이 모을 수 있다.

또 API Server가 필요한 이유도 있다. 단순히 CPU 80%라는 값만 있으면 이 값이 어떤 Pod, 어떤 Namespace, 어떤 Deployment에서 나온 것인지 알기 어렵다. API Server에서 Kubernetes 메타데이터를 함께 확인하면 Datadog에는 다음처럼 의미 있는 정보로 저장된다.

namespace: monitoring
pod: grafana-55fb79fcf6-cn6k6
node: argocd-lab
container: grafana
metric: cpu / memory / network

즉 Datadog 구조에서 노드 단위 수집은 Agent Pod가 담당하고, Kubernetes API Server는 수집값에 Namespace, Pod, Node 같은 의미를 붙이는 기준 정보를 제공한다.

실제 실습 흐름은 다음 순서로 보는 것이 맞다.

Datadog 웹사이트 접속
  -> Free Trial 계정/환경 생성
  -> Agent Setup 화면 진입
  -> New Installation 선택
  -> Datadog이 만들어준 설치 명령 복사
  -> Kubernetes 워커 노드 또는 minikube 노드 셸에서 명령 실행
  -> Datadog UI에서 Kubernetes/Container 데이터 유입 확인

Helm repo -> Datadog Operator -> DatadogAgent YAML 내용은 터미널 로그와 남아 있는 YAML 파일 기준의 추가 확인 과정이다. 실제 실습 시작점은 Datadog UI의 Agent Setup이므로, 이 문서에서는 그 흐름을 기본 흐름으로 정리한다.

참고로 Datadog 공식 Kubernetes 설치 문서도 Datadog의 Installing on Kubernetes 화면을 따라 설치 방식을 선택하라고 안내한다. 그 설치 방식은 Operator, Helm, Manual installation 중 하나로 갈린다.

1.1 minikube 클러스터 시작

먼저 Datadog을 설치할 Kubernetes 클러스터를 시작했다.

minikube start -p argocd-lab

출력에서 확인한 내용:

[argocd-lab] Microsoft Windows 11 Pro 환경
docker 드라이버 사용
Kubernetes v1.31.0
Docker 27.2.0 runtime
storage-provisioner, default-storageclass 활성화

중간에 다음 경고가 있었다.

Failing to connect to https://registry.k8s.io/ from inside the minikube container

이건 minikube 컨테이너 안에서 외부 이미지 레지스트리에 바로 연결하지 못했다는 경고다. 다만 기존 클러스터가 다시 시작되었고 필요한 구성요소가 동작했기 때문에, 그 시점에서는 실습을 계속 진행할 수 있었다.

노드 상태 확인:

kubectl get nodes

결과:

NAME         STATUS   ROLES           VERSION
argocd-lab   Ready    control-plane   v1.31.0

즉 Datadog을 설치할 Kubernetes 클러스터는 정상적으로 Ready 상태였다.

1.2 Datadog 웹페이지에서 Free Trial 환경 생성

그다음 Datadog 웹사이트에 들어가서 Free Trial을 시작했다.

실습 화면 캡처 위치
Datadog Free Trial / Agent Setup 화면은 티스토리 업로드 시 이미지로 별도 첨부하면 된다. 본문에는 설치 흐름과 명령 의미를 빠짐없이 정리했다.

이 단계의 목적은 Datadog SaaS 쪽에 데이터를 받을 계정과 조직 환경을 만드는 것이다. Datadog Agent 실행 위치는 로컬 Kubernetes나 워커 노드 쪽이고, 수집된 메트릭과 컨테이너 정보는 Datadog SaaS로 전송된다.

따라서 설치 전에 Datadog 웹 UI에서 다음이 준비되어야 한다.

Datadog 계정
Datadog organization
Datadog site
API key
Agent 설치 안내 화면

오늘 실습에서는 Datadog site가 us3.datadoghq.com 기준으로 잡혀 있었다.

실습 화면 캡처 위치
Datadog Free Trial / Agent Setup 화면은 티스토리 업로드 시 이미지로 별도 첨부하면 된다. 본문에는 설치 흐름과 명령 의미를 빠짐없이 정리했다.

1.3 Agent Setup에서 New Installation 선택

Datadog UI에서 Agent 설치 화면으로 이동했다.

실습 흐름:

Datadog UI
  -> Agent Setup
  -> New Installation
  -> 설치 대상 환경 선택
  -> Datadog이 제공하는 설치 명령 복사

여기서 중요한 점은 설치 명령 안에 Datadog API key와 site 정보가 포함된다는 것이다. 그래서 명령을 그대로 공개 문서나 채팅에 남기면 안 된다.

예시 형태는 다음과 비슷하다. 실제 키 값은 문서에 적지 않는다.

DD_API_KEY=<DATADOG_API_KEY> DD_SITE="us3.datadoghq.com" ...

또는 Kubernetes 설치 방식에서는 Datadog UI가 Helm/Operator/kubectl 기반 명령을 단계별로 보여줄 수 있다. 어떤 형태든 공통점은 Datadog이 화면에서 현재 계정의 API key와 site에 맞춘 설치 명령을 만들어준다는 것이다.

1.4 복사한 설치 명령을 워커 노드에서 실행

네가 실습한 방식은 Datadog 화면에서 복사한 New Installation 명령을 워커 노드 쪽에서 실행하는 형태였다.

minikube 환경에서는 실제 워커 노드가 별도 물리 서버가 아니라 minikube 컨테이너/VM 안의 노드다. 그래서 노드 내부에서 실행해야 하는 명령이라면 다음처럼 들어가서 실행하는 흐름이 된다.

minikube ssh -p argocd-lab

그 안에서 Datadog UI가 제공한 설치 명령을 실행한다.

# Datadog UI에서 복사한 New Installation 명령 실행

Datadog의 Linux Agent 설치 명령 흐름에는 보통 Agent 서비스를 시작하는 단계가 포함된다.

systemctl start datadog-agent

이 명령은 Linux 워커 노드 안에서 Datadog Agent 서비스를 시작하는 명령이다. 즉 Datadog UI에서 복사한 New Installation 명령을 워커 노드에서 실행할 때 등장하는 것이 자연스럽다.

다만 이 명령은 Windows PowerShell에서 실행하는 명령이 아니다. Windows PowerShell에서 직접 실행하면 systemctl 자체가 없기 때문에 실패한다.

이 방식의 인과관계는 다음과 같다.

Datadog UI에서 명령 생성
  -> 명령 안에 API key/site/install script 정보 포함
  -> 워커 노드에서 실행
  -> 노드/컨테이너/Kubernetes 정보 수집
  -> Datadog SaaS로 전송
  -> Datadog UI에서 클러스터와 컨테이너 데이터 확인

1.5 터미널에 남아 있던 Operator/YAML 기반 추가 확인 과정

실제 시작점은 Datadog UI였지만, 터미널 로그와 파일에는 Operator/YAML 기반 설정도 남아 있었다. 이 부분은 Datadog Kubernetes 리소스가 어떤 방식으로 구성되었는지 확인한 과정으로 정리한다.

1.5.1 Datadog Helm repository 등록

Datadog Operator를 Helm으로 설치하기 위해 Datadog Helm repository를 등록했다.

helm repo add datadog https://helm.datadoghq.com

이미 추가되어 있어서 다음 메시지가 나왔다.

"datadog" already exists with the same configuration, skipping

이 메시지는 에러가 아니다. 이미 같은 Datadog Helm repository가 등록되어 있으므로 다시 추가하지 않았다는 뜻이다.

1.5.2 Datadog Operator 설치 시도와 기존 설치 확인

그다음 Datadog Operator를 설치하려고 했다.

helm install datadog-operator datadog/datadog-operator --namespace datadog --create-namespace

하지만 다음 에러가 나왔다.

cannot reuse a name that is still in use

이건 같은 Helm release 이름인 datadog-operator가 이미 클러스터에 존재한다는 뜻이다. 즉 새로 설치할 필요가 없고, 기존 Operator를 그대로 사용하면 되는 상황이었다.

Datadog Operator는 DatadogAgent라는 Custom Resource를 감시하다가, 그 설정에 맞춰 실제 Datadog Agent Pod를 만들어주는 역할을 한다.

즉 여기서 중요한 판단은 다음이다.

helm install 실패
  -> 설치 자체가 망한 것이 아님
  -> 같은 이름의 Datadog Operator release가 이미 있음
  -> 기존 Operator를 사용하면 됨

1.5.3 Datadog API Key Secret 생성

Datadog SaaS로 데이터를 전송하려면 API key가 필요하다. 그래서 Kubernetes Secret을 만들었다.

kubectl create secret generic datadog-secret --from-literal api-key=<DATADOG_API_KEY> -n datadog

이 Secret은 DatadogAgent 리소스에서 참조된다.

주의할 점은 오늘 채팅과 터미널 기록에 실제 Datadog API key가 노출되었다는 것이다. 실습이 끝난 뒤 Datadog에서 해당 키는 rotate 또는 삭제하는 것이 안전하다.

1.5.4 DatadogAgent YAML 적용

적용한 파일은 다음이다.

[실습 작업 디렉터리]\llm-saas-sass\datadog-agent.yaml

핵심 설정은 다음과 같다.

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
  namespace: datadog
spec:
  global:
    clusterName: argocd-lab
    site: us3.datadoghq.com
    kubelet:
      tlsVerify: false
    credentials:
      apiSecret:
        secretName: datadog-secret
        keyName: api-key
  features:
    clusterChecks:
      enabled: true
    orchestratorExplorer:
      enabled: true

적용 명령:

kubectl apply -f "[실습 작업 디렉터리]\llm-saas-sass\datadog-agent.yaml"

결과:

datadogagent.datadoghq.com/datadog created

여기서 중요한 인과관계는 다음과 같다.

DatadogAgent는 직접 Agent Pod가 아니다. Datadog Operator가 이 CR을 보고 실제 datadog-agent와 datadog-cluster-agent Pod를 생성한다.

kubelet.tlsVerify: false는 로컬 minikube 환경에서 kubelet 인증서 검증 문제를 피하기 위한 설정이다. 운영 환경에서는 더 신중하게 다뤄야 하지만, 로컬 실습에서는 자주 필요한 옵션이다.

1.5.5 Datadog Pod 생성 과정 확인

적용 직후에는 Pod가 바로 Running이 아니라 생성 과정을 거친다.

확인 명령:

kubectl get pods -n datadog -w

중간 상태:

datadog-agent-kznfl                      0/2   Init:0/2
datadog-cluster-agent-688d66646f-rzjfj   0/1   ContainerCreating
datadog-operator-66c678ff76-g2fzs        1/1   Running

이후 상태가 바뀌었다.

datadog-agent-kznfl                      2/2   Running
datadog-cluster-agent-688d66646f-rzjfj   1/1   Running
datadog-operator-66c678ff76-g2fzs        1/1   Running

여기서 datadog-agent는 노드에 붙어서 메트릭과 로그, kubelet 관련 정보를 수집하고, datadog-cluster-agent는 클러스터 단위의 상태와 orchestrator 정보를 처리한다.

1.6 Datadog 최종 상태 확인

확인 명령:

kubectl get datadogagent -n datadog
kubectl get pods -n datadog

최종 상태:

datadog   Running (1/1/1)   Running (1/1/1)

datadog-agent-ct22c                      2/2   Running
datadog-cluster-agent-688d66646f-rzjfj   1/1   Running
datadog-operator-66c678ff76-g2fzs        1/1   Running

즉 Datadog Operator, Agent, Cluster Agent가 모두 동작하는 상태까지 확인했다.

1.7 systemctl 명령의 위치와 실패한 이유

중간에 다음 명령도 실행했다.

systemctl start datadog-agent

결과:

systemctl : The term 'systemctl' is not recognized

이 명령 자체는 Datadog Linux Agent 설치 흐름에서는 의미가 있다. Datadog UI의 New Installation 명령을 Linux 워커 노드에서 실행하면 datadog-agent 서비스를 설치하고 시작하는 단계로 볼 수 있다.

하지만 위 에러가 난 이유는 명령을 Windows PowerShell에서 실행했기 때문이다. 현재 작업 위치는 Windows PowerShell이고, systemctl은 Linux systemd 서비스 관리 명령이다.

따라서 구분은 다음처럼 해야 한다.

Linux 워커 노드 안에서 Datadog Linux Agent를 설치/시작할 때:
  systemctl start datadog-agent

Windows PowerShell에서 Kubernetes에 올라간 Datadog 리소스를 확인할 때:
  kubectl get pods -n datadog
  kubectl get datadogagent -n datadog

오늘 터미널에 남아 있던 Operator/YAML 기반 확인 흐름에서는 시작/중지/상태 확인을 systemctl이 아니라 다음처럼 kubectl로 확인했다.

kubectl get pods -n datadog
kubectl get datadogagent -n datadog

2. Prometheus 실습

Prometheus는 Kubernetes 내부의 메트릭을 수집하는 역할이다. 오늘 실습에서는 YAML 파일을 직접 만들어서 RBAC, ConfigMap, Deployment, Service, node-exporter를 구성했다.

2.0 설치 전에 이해해야 할 Prometheus 구조

Prometheus 구조 그림은 Kubernetes 클러스터에서 Prometheus가 메트릭을 수집하고, 저장하고, 조건에 따라 알림까지 전달하는 흐름을 설명한다. Datadog 구조와 비교하면 차이가 더 분명하다.

Datadog 구조
  각 노드의 Datadog Agent가 메트릭을 수집해서 Datadog SaaS로 전송한다.

Prometheus 구조
  Prometheus가 직접 여러 수집 대상에 접근해서 메트릭을 가져온다.

Prometheus의 기본 방식은 Pull 방식이다. 대상이 Prometheus에게 먼저 보내는 것이 아니라, Prometheus가 정해진 주기마다 수집 대상에 접속해서 메트릭을 가져온다. 이 작업을 scraping이라고 부른다.

Prometheus -> "메트릭 있나요?"
Node / Pod / Exporter -> "네, 여기 있습니다."
Prometheus -> 수집한 값을 저장

Prometheus 모니터링 흐름

Kubernetes Cluster
  ├─ Node / Pod / Service
  ├─ node-exporter
  ├─ kube-state-metrics
  └─ cAdvisor / kubelet metrics
          ↑
          | scrape
          |
Prometheus Server
  ├─ ConfigMap의 prometheus.yml을 읽고 수집 대상을 결정
  ├─ 수집한 메트릭을 시계열 데이터로 저장
  ├─ 알림 규칙을 평가
  └─ 조건 만족 시 Alertmanager로 알림 전달
          |
          v
Alertmanager
  └─ Slack / Email 같은 채널로 사용자에게 알림 전송

ConfigMap은 Prometheus의 설정 파일 역할을 한다. 어디에서 메트릭을 수집할지, 몇 초마다 수집할지, 어떤 라벨을 붙일지, 어떤 alert rule을 사용할지 같은 내용이 들어간다. 오늘 실습에서는 prometheus-config-map.yaml에 prometheus.yml을 넣고, Prometheus Deployment가 이 ConfigMap을 mount해서 사용하도록 구성했다.

PV는 PersistentVolume의 약자이며, Prometheus가 수집한 시계열 데이터를 오래 보관하기 위한 저장소다. 예를 들어 10:00 CPU 30%, 10:01 CPU 45%, 10:02 CPU 80% 같은 시간별 값이 Prometheus 저장소에 쌓인다. Prometheus Pod가 재시작되어도 데이터를 유지하려면 PV를 붙여야 한다. 오늘 실습에서는 간단한 로컬 실습이라 emptyDir을 사용했기 때문에 Pod가 다시 만들어지면 과거 데이터는 사라질 수 있다.

Alertmanager는 Prometheus가 만든 알림을 실제 사용자에게 전달하는 역할이다. Prometheus가 메트릭을 수집하고 alert rule을 평가한 뒤, CPU 사용률이 높거나 Pod 상태가 비정상인 조건이 만족되면 Alertmanager로 알림을 넘긴다. Alertmanager는 이 알림을 Slack, 이메일 같은 채널로 보낼 수 있다. 이번 실습의 핵심은 수집과 시각화였기 때문에 Alertmanager까지 깊게 구성하지는 않았지만, Prometheus 운영 구조에서는 함께 쓰이는 구성요소다.

아래 명령으로 monitoring 네임스페이스를 만든 이유도 이 구조와 연결된다.

kubectl create ns monitoring

Prometheus, Grafana, node-exporter 같은 모니터링 리소스를 default 네임스페이스에 섞어 두지 않고 monitoring이라는 별도 공간에 모아 관리하기 위한 것이다. Namespace는 Kubernetes 리소스를 구분하는 논리적 폴더처럼 보면 된다.

2.1 monitoring 네임스페이스 생성

처음에는 k alias가 없어서 다음 명령이 실패했다.

k create ns monitoring

에러:

k : The term 'k' is not recognized

그래서 PowerShell에서 alias를 만들었다.

Set-Alias k kubectl
k create ns monitoring

결과:

namespace/monitoring created

2.2 Prometheus RBAC

파일:

[Windows 사용자 홈]\prometheus-cluster-role.yaml

적용:

k apply -f prometheus-cluster-role.yaml

생성된 리소스:

clusterrole.rbac.authorization.k8s.io/prometheus created
clusterrolebinding.rbac.authorization.k8s.io/prometheus created

이 설정의 목적은 Prometheus가 Kubernetes API를 통해 노드, Pod, Service, Endpoint 정보를 조회할 수 있게 하는 것이다.

특히 Prometheus 설정에서 다음과 같은 경로를 긁기 때문에 RBAC에 nodes/proxy 권한이 필요하다.

/api/v1/nodes/${node}/proxy/metrics
/api/v1/nodes/${node}/proxy/metrics/cadvisor

즉 RBAC 없이는 Prometheus가 클러스터 내부 메트릭을 발견하거나 읽을 수 없다.

2.3 Prometheus ConfigMap

파일:

[Windows 사용자 홈]\prometheus-config-map.yaml

적용:

k apply -f prometheus-config-map.yaml

생성:

configmap/prometheus-server-conf created

이 ConfigMap 안에는 Prometheus 설정 파일인 prometheus.yml과 alert rule이 들어 있다.

주요 scrape job은 다음과 같다.

kubernetes-apiservers
kubernetes-nodes
kubernetes-pods
kube-state-metrics
kubernetes-cadvisor
kubernetes-service-endpoints

여기서 중요한 흐름은 다음이다.

Prometheus는 무작정 모든 Pod를 긁는 것이 아니라, Kubernetes service discovery와 annotation을 보고 대상을 찾는다.

예를 들어 Pod나 Service에 다음 annotation이 있어야 scrape 대상으로 잡힌다.

prometheus.io/scrape: "true"
prometheus.io/port: "9100"

2.4 Prometheus Deployment

파일:

[Windows 사용자 홈]\prometheus-deployment.yaml

적용:

k apply -f prometheus-deployment.yaml

생성:

deployment.apps/prometheus-deployment created

핵심 설정:

image: prom/prometheus:latest
args:
  - --config.file=/etc/prometheus/prometheus.yml
  - --storage.tsdb.path=/prometheus/

ConfigMap은 /etc/prometheus/에 mount했고, 메트릭 저장 경로는 /prometheus/로 잡았다. 이 실습에서는 emptyDir을 사용했기 때문에 Pod가 새로 만들어지면 Prometheus 데이터는 사라질 수 있다. 실습용으로는 괜찮지만 운영용이라면 PersistentVolume을 써야 한다.

2.5 Prometheus Service

파일:

[Windows 사용자 홈]\prometheus-svc.yaml

적용:

k apply -f prometheus-svc.yaml

생성:

service/prometheus-service created

중요한 포트 구조:

type: NodePort
ports:
  - port: 8080
    targetPort: 9090
    nodePort: 30001

이 뜻은 다음과 같다.

Kubernetes 내부 접근: prometheus-service:8080
Prometheus Pod 실제 포트: 9090
NodePort 외부 접근: <node-ip>:30001

하지만 Windows + Docker 기반 minikube에서는 NodePort 접속이 애매할 수 있어서, 오늘은 kubectl port-forward를 더 안정적인 접근 방식으로 사용했다.

kubectl port-forward -n monitoring svc/prometheus-service 9090:8080

이 명령의 의미:

Windows localhost:9090
  -> Kubernetes service/prometheus-service:8080
  -> Prometheus Pod:9090

브라우저에서 Prometheus를 볼 때는 다음 주소를 사용한다.

http://localhost:9090

3. Grafana 실습

Grafana는 Prometheus가 수집한 메트릭을 대시보드로 보여주는 역할이다.

3.1 Grafana YAML 적용

파일:

[Windows 사용자 홈]\grafana.yaml

적용:

k apply -f grafana.yaml

생성:

deployment.apps/grafana created
service/grafana created

핵심 설정:

image: grafana/grafana:latest
containerPort: 3000
env:
  - name: GF_AUTH_ANONYMOUS_ENABLED
    value: "true"
  - name: GF_AUTH_ANONYMOUS_ORG_ROLE
    value: Admin

실습 편의를 위해 anonymous 접근을 켜고 Admin 권한을 부여했다. 운영 환경에서는 위험한 설정이므로 그대로 쓰면 안 된다.

Grafana Service는 다음처럼 열었다.

type: NodePort
ports:
  - port: 3000
    targetPort: 3000
    nodePort: 30004

마찬가지로 오늘은 NodePort보다 port-forward를 사용했다.

kubectl port-forward -n monitoring svc/grafana 3000:3000

이 명령의 의미:

Windows localhost:3000
  -> Kubernetes service/grafana:3000
  -> Grafana Pod:3000

브라우저에서 Grafana 접속:

http://localhost:3000

3.2 현재 Grafana / Prometheus 상태

현재 확인한 monitoring 네임스페이스 상태:

grafana-55fb79fcf6-cn6k6                 1/1   Running
node-exporter-bsg9c                      1/1   Running
prometheus-deployment-577c8f5b69-l2x9c   1/1   Running

service/grafana              NodePort    3000:30004/TCP
service/node-exporter        ClusterIP   9100/TCP
service/prometheus-service   NodePort    8080:30001/TCP

즉 Grafana, Prometheus, node-exporter가 모두 정상 실행 중이다.

4. Grafana와 Prometheus 연동

4.1 처음 난 에러

Grafana에서 Prometheus Data Source를 설정할 때 다음 에러가 났다.

Post "http://localhost:9090/query/api/v1/query":
dial tcp [::1]:9090: connect: connection refused

이 에러의 원인은 Grafana Data Source URL에 localhost와 /query를 잘못 넣었기 때문이다.

4.2 왜 localhost가 틀렸는가

브라우저에서 localhost:9090은 Windows PC 자신을 뜻한다.

하지만 Grafana 설정 화면에서 Data Source URL에 쓰는 localhost는 Windows PC가 아니다. Grafana Pod 내부에서 봤을 때의 localhost다.

즉 Grafana Pod 안에서:

localhost = Grafana Pod 자기 자신

Grafana Pod 안에는 Prometheus가 떠 있지 않다. 그래서 localhost:9090으로 요청하면 connection refused가 난다.

4.3 Grafana Data Source에 넣어야 하는 주소

Grafana Data Source URL은 Kubernetes 내부 DNS 주소를 써야 한다.

http://prometheus-service.monitoring.svc.cluster.local:8080

또는 같은 네임스페이스라면 다음도 가능하다.

http://prometheus-service:8080

여기서 /query는 붙이면 안 된다. Grafana가 Prometheus API를 호출할 때 뒤에 /api/v1/query를 자동으로 붙인다. 사용자가 URL에 /query를 붙이면 최종 요청 경로가 이상해진다.

정리하면 주소는 목적에 따라 다르다.

브라우저에서 Prometheus 보기:
http://localhost:9090

Grafana Data Source URL:
http://prometheus-service.monitoring.svc.cluster.local:8080

4.4 Dashboard 6417 Import

책에서는 예전 Grafana UI 기준으로 다음 경로를 안내했다.

Dashboards -> Manage -> Import

하지만 현재 Grafana UI에서는 보통 다음 경로를 사용한다.

Dashboards -> New -> Import

여기에 Grafana dashboard ID 6417을 넣어 가져왔다.

5. Dashboard 6417에서 N/A가 난 이유와 해결

Dashboard 6417을 가져온 뒤 여러 패널에서 N/A가 나왔다.

처음에는 단순히 Grafana 문제처럼 보였지만, 실제 원인은 Prometheus가 수집하는 메트릭 환경과 대시보드의 PromQL이 맞지 않았기 때문이다.

원인은 크게 세 가지였다.

5.1 원인 1: kube-state-metrics 부족

Dashboard 6417은 kube_pod_info, kube_node_status_allocatable, kube_deployment_* 같은 kube_* 메트릭을 많이 사용한다.

이 메트릭들은 Kubernetes 기본 구성에서 자동으로 나오는 것이 아니라 kube-state-metrics가 만들어준다.

그래서 다음 파일을 추가했다.

[실습 작업 디렉터리]\llm-saas-sass\kube-state-metrics.yaml

이 파일에는 다음 리소스가 들어 있다.

ServiceAccount
ClusterRole
ClusterRoleBinding
Deployment
Service

이미지는 다음 버전을 사용했다.

image: registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.15.0

Prometheus ConfigMap에는 이미 다음 scrape job이 있었다.

- job_name: 'kube-state-metrics'
  static_configs:
    - targets: ['kube-state-metrics.kube-system.svc.cluster.local:8080']

즉 kube-state-metrics Service가 정상 생성되어야 Prometheus가 kube_* 메트릭을 긁을 수 있다.

최종 확인:

kube-state-metrics-8699bdc54c-cw5bx   1/1   Running

5.2 원인 2: node-exporter Service 문제

node-exporter Pod는 있었지만, Prometheus가 안정적으로 발견할 수 있는 Service가 부족했다.

처음 prometheus-node-exporter.yaml에는 DaemonSet은 monitoring 네임스페이스에 만들면서, Service는 kube-system 네임스페이스에 만드는 형태가 섞여 있었다.

이러면 selector가 맞아도 네임스페이스가 달라 Prometheus service discovery 흐름이 꼬일 수 있다.

그래서 다음 파일을 추가했다.

[실습 작업 디렉터리]\llm-saas-sass\node-exporter-service.yaml

핵심 설정:

apiVersion: v1
kind: Service
metadata:
  name: node-exporter
  namespace: monitoring
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "9100"
spec:
  selector:
    k8s-app: node-exporter
  ports:
    - name: metrics
      port: 9100
      targetPort: http

이렇게 해서 Prometheus가 node-exporter를 scrape 대상으로 잡고 node_cpu_seconds_total 같은 node 메트릭을 수집할 수 있게 했다.

최종 확인:

node-exporter-bsg9c        1/1   Running
service/node-exporter      ClusterIP   9100/TCP

5.3 원인 3: Dashboard 6417의 PromQL이 예전 메트릭 이름을 사용

Dashboard 6417은 오래된 Kubernetes / kube-state-metrics 기준의 PromQL을 포함하고 있었다.

예전 쿼리 예시:

kube_node_status_allocatable_cpu_cores

현재 kube-state-metrics v2에서는 이런 이름이 다음처럼 바뀌었다.

kube_node_status_allocatable{resource="cpu", unit="core"}

즉 Prometheus에는 데이터가 있어도, Grafana 패널이 없는 메트릭 이름을 조회하면 결과가 비게 된다. 그 결과 Grafana에는 N/A가 보인다.

그래서 Dashboard 6417의 PromQL을 현재 메트릭 이름에 맞게 수정했다.

추가로, 정상적으로 값이 없을 수 있는 패널에는 다음 패턴을 넣었다.

... or vector(0)

이렇게 하면 시계열이 아예 비어 있을 때 N/A 대신 0을 보여줄 수 있다.

5.4 최종 검증

수정 후 만든 검증 리포트:

[실습 작업 디렉터리]\llm-saas-sass\monitoring-fix-report.html

캡처:

[실습 작업 디렉터리]\llm-saas-sass\screenshots\monitoring-fix-report.png
[실습 작업 디렉터리]\llm-saas-sass\screenshots\grafana-6417-fixed-dashboard.png
[실습 작업 디렉터리]\llm-saas-sass\screenshots\prometheus-targets-after-fix.png

검증 결과:

up{job="kube-state-metrics"} = 1
up{k8s_app="node-exporter"} = 1
count(kube_pod_info) = 24
count(node_cpu_seconds_total) = 128
Grafana Dashboard 6417 PromQL = 36 / 36 queries returned data
Visible DOM = N/A 0, error 0

즉 N/A의 원인은 Grafana 화면 자체가 아니라 Prometheus 수집 대상과 Dashboard PromQL의 불일치였고, 수집 대상 보강과 PromQL 수정으로 해결했다.

6. Port-forward 정리

오늘 실습에서 브라우저 접속은 NodePort보다 port-forward를 주로 사용했다.

Prometheus:

kubectl port-forward -n monitoring svc/prometheus-service 9090:8080

브라우저:

http://localhost:9090

Grafana:

kubectl port-forward -n monitoring svc/grafana 3000:3000

브라우저:

http://localhost:3000

로그에 다음 메시지가 많이 나왔다.

Handling connection for 3000
Handling connection for 9090

이건 브라우저가 HTML, JS, CSS, API 요청을 여러 번 보내기 때문에 자연스럽게 많이 찍힌다.

또 다음 에러도 보였다.

wsarecv: An existing connection was forcibly closed by the remote host
wsasend: An established connection was aborted by the software in your host machine

이건 브라우저 새로고침, 탭 닫기, 연결 중단, long polling 또는 websocket 종료 때도 나올 수 있다. 페이지가 계속 열리고 요청이 된다면 항상 치명적인 에러는 아니다.

하지만 다음 메시지는 port-forward 자체가 끊긴 것이다.

error: lost connection to pod

이 경우에는 port-forward 명령을 다시 실행해야 한다.

7. kube-apiserver / metrics-server 관련 보조 실습

오늘 중간에 metrics-server와 Kubernetes aggregated API 관련 실습도 같이 진행했다.

Windows에서 다음 파일을 바로 열려고 했다.

notepad /etc/kubernetes/manifests/kube-apiserver.yaml

하지만 이 경로는 Windows 파일시스템이 아니라 minikube control-plane 노드 내부 경로다.

그래서 다음으로 들어가야 했다.

minikube ssh -p argocd-lab

또는 Docker 컨테이너에서 파일을 복사해서 Windows Notepad로 수정하는 방식을 사용했다.

수정한 파일:

[실습 작업 디렉터리]\ps-c-users-admin-notepad-etc\kube-apiserver.yaml

추가한 옵션:

- --enable-aggregator-routing=true

이 옵션은 metrics.k8s.io 같은 aggregated API가 kube-apiserver를 통해 metrics-server로 라우팅될 때 필요한 설정이다.

현재 확인:

kube-apiserver-argocd-lab             1/1   Running
metrics-server-775995795d-6sx7p       1/1   Running
kube-state-metrics-8699bdc54c-cw5bx   1/1   Running

즉 metrics-server와 kube-state-metrics 모두 실행 상태다.

8. 같이 했던 LimitRange / HPA 흐름

모니터링 실습과 별도로 Kubernetes 리소스 제한과 HPA 실습도 진행했다.

LimitRange:

[Windows 사용자 홈]\set-limit-range.yaml

내용:

min:
  cpu: "200m"
max:
  cpu: "800m"

Pod:

[Windows 사용자 홈]\pod-with-cpu-range.yaml

이 Pod는 CPU request 500m, limit 800m으로 생성했다.

HPA용 Deployment:

[Windows 사용자 홈]\php-apache.yaml

핵심:

requests:
  cpu: 200m
limits:
  cpu: 500m

HPA 생성:

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

부하 생성:

kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

여기서 HPA의 50%는 CPU limit 기준이 아니라 CPU request 기준이다. php-apache의 request가 200m이므로, 평균 CPU가 약 100m을 넘으면 scale out 판단이 시작된다.

9. 오늘 실습의 핵심 정리

오늘 실습의 핵심은 세 줄로 요약할 수 있다.

첫째, Datadog은 웹 UI에서 Free Trial 환경을 만든 뒤 Agent Setup의 New Installation 명령을 이용해 Agent 설치 흐름을 진행했고, 터미널에서는 Operator와 DatadogAgent CR 기반 리소스가 Running 되는 것까지 확인했다.

둘째, Prometheus는 YAML로 RBAC, ConfigMap, Deployment, Service를 만들고 Kubernetes API, cAdvisor, Pod/Service annotation, kube-state-metrics, node-exporter를 scrape하도록 구성했다.

셋째, Grafana는 Prometheus를 Data Source로 붙이고 Dashboard 6417을 가져왔지만, 예전 PromQL과 현재 kube-state-metrics v2 메트릭 이름이 맞지 않아 N/A가 났고, 수집 대상 보강과 PromQL 수정으로 데이터가 나오게 했다.

가장 중요한 개념 구분은 이것이다.

브라우저에서 여는 주소:
  Prometheus -> http://localhost:9090
  Grafana    -> http://localhost:3000

Grafana Pod가 Prometheus에 접근하는 주소:
  http://prometheus-service.monitoring.svc.cluster.local:8080

즉 localhost는 상황에 따라 의미가 달라진다. Windows 브라우저의 localhost와 Grafana Pod 내부의 localhost는 같은 대상이 아니다. 이 차이를 이해한 것이 Grafana-Prometheus 연동 문제를 푸는 핵심이었다.