Skip to content

KR_K8s_Monitoring

somaz edited this page Mar 30, 2026 · 1 revision

쿠버네티스 모니터링 & 옵저버빌리티 (Q41-Q45)

모니터링 & 옵저버빌리티 (41~45번)


Q41. Prometheus의 Service Discovery와 relabel_configs 활용은?

Prometheus는 Kubernetes Service Discovery를 통해 동적으로 타겟을 발견한다.

주요 SD 메커니즘:

  • kubernetes_sd_configs: Pod, Service, Endpoint, Node, Ingress 자동 발견.
  • relabel_configs: 메트릭 수집 전 레이블 변환/필터링.

실무 패턴:

- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
  action: keep
  regex: true
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
  action: replace
  target_label: __metrics_path__
  regex: (.+)

불필요한 메트릭 drop으로 카디널리티 감소, Pod annotation 기반 자동 스크래핑, 네임스페이스별 필터링으로 멀티 테넌시 지원.


Q42. Distributed Tracing에서 OpenTelemetry Collector의 역할과 구성은?

OpenTelemetry Collector는 traces, metrics, logs를 수집/처리/전송하는 벤더 중립 에이전트다.

주요 구성:

  • Receivers: OTLP, Jaeger, Zipkin 프로토콜 수신
  • Processors: Batch(배치 처리), Attributes(메타데이터 추가), Sampling(샘플링)
  • Exporters: Jaeger, Tempo, DataDog, Elastic APM 전송

배포 패턴:

  • Agent: DaemonSet으로 각 노드에 배포, 애플리케이션 → Agent → Collector
  • Gateway: Deployment로 중앙 집중, 여러 Agent → Gateway → Backend

Tail-based sampling으로 에러/느린 트레이스만 수집, Head-based sampling으로 전체 트래픽 감소.

Context Propagation(W3C Trace Context)으로 서비스 간 추적 연결.


Q43. Kubernetes Events를 장기 보관하고 분석하는 방법은?

Kubernetes Events는 기본적으로 1시간만 보관되므로 장기 보관 전략이 필요하다.

옵션 비교:

Event Exporter + Elasticsearch/Loki:

  • Event Exporter(Bitnami)가 Events를 감시하여 로그 시스템으로 전송, Elasticsearch로 인덱싱 후 Kibana로 시각화, 또는 Grafana Loki + LogQL로 쿼리.

Kubernetes Event Exporter → S3:

  • Fluentd/Fluent Bit로 Events를 JSON 형태로 S3에 저장, Athena로 쿼리, 비용 효율적.

Prometheus Metrics로 변환:

  • kube-state-metrics가 Event를 메트릭으로 노출, AlertManager로 중요 이벤트 알림.

실무에서는 경고용 Event(Warning, Error)만 별도 수집하고, Pod OOMKilled, ImagePullBackOff, NodeNotReady 등 패턴 분석에 활용.


Q44. Metrics Server vs Prometheus vs Custom Metrics API 차이는?

Kubernetes는 3가지 메트릭 시스템을 가진다.

Metrics Server:

  • 경량 메트릭 수집, kubelet에서 CPU/메모리만 수집, kubectl top 명령어 지원, HPA의 Resource Metrics 소스, 15초 간격 수집, 히스토리 없음.

Prometheus:

  • 풀스택 모니터링, 모든 메트릭 수집 가능, PromQL로 복잡한 쿼리, 장기 보관, HPA의 Custom Metrics 소스(Prometheus Adapter 필요), Alert 기능.

Custom Metrics API:

  • HPA가 커스텀 메트릭 사용하도록 표준 인터페이스 제공, Prometheus Adapter, DataDog Cluster Agent가 구현, 애플리케이션 메트릭(RPS, Queue Length) 기반 스케일링.

선택: 기본 모니터링은 Metrics Server, 프로덕션은 Prometheus, 비즈니스 메트릭 기반 스케일링은 Custom Metrics API.


Q45. Grafana의 Dashboard as Code와 Jsonnet 활용 전략은?

Grafana Dashboard를 코드로 관리하여 버전 관리와 자동화를 구현한다.

방법:

JSON Export/Import:

  • 기존 대시보드를 JSON으로 export, Git 저장, ConfigMap으로 자동 프로비저닝, 간단하지만 중복 많음.

Jsonnet + Grafonnet:

  • Jsonnet 템플릿 언어로 대시보드 정의, 변수/함수/라이브러리 재사용, Grafonnet 라이브러리로 타입 안전성, 100개 대시보드도 관리 용이.

Terraform Grafana Provider:

  • Terraform으로 대시보드, DataSource, Alert 관리, 인프라와 통합 관리.

실무 패턴: 템플릿 대시보드(Node, Pod, Ingress)를 Jsonnet으로 작성, 환경별 변수(dev/staging/prod) 주입, CI/CD로 자동 배포, 팀별 폴더 분리.

💡 용어 설명:

  • 모니터링 관련 용어들(Liveness Probe, Readiness Probe, Startup Probe, Prometheus, Metrics Server, Custom Metrics API, OpenTelemetry, Distributed Tracing 등)에 대한
  • 상세한 설명은 문서 상단의 주요 용어 통합 정리 > 모니터링 및 로깅 섹션을 참고하세요.

Clone this wiki locally