관측 가능성

관측 가능성 (Observability)

쿠버네티스 클러스터가 실제로 제대로 돌아가는지, 어디서 병목이 나는지 알려면 클러스터 "내부"를 들여다볼 수 있어야 해요. 이걸 가능하게 하는 게 바로 관측 가능성(Observability) 입니다. 이 페이지에서는 메트릭(metric), 로그(log), 트레이스(trace)를 수집해서 클러스터를 종단 간(end-to-end)으로 들여다보는 방법을 설명해요.

출처: 쿠버네티스 공식 문서 — Observability

쿠버네티스에서 관측 가능성이란 메트릭·로그·트레이스를 수집하고 분석해 클러스터의 내부 상태, 성능, 건강 상태를 더 잘 이해하는 과정이에요. 이 세 가지를 흔히 관측 가능성의 세 기둥(three pillars of observability) 이라고 부릅니다.

쿠버네티스 컨트롤 플레인 컴포넌트와 많은 애드온은 이런 신호를 생성하고 내보냅니다. 이들을 집계하고 서로 연결하면 컨트롤 플레인, 애드온, 애플리케이션 전체의 통합된 그림을 얻을 수 있어요.

메트릭 (Metrics)

쿠버네티스 컴포넌트는 /metrics 엔드포인트에서 Prometheus 형식으로 메트릭을 내보냅니다. 여기에는 다음이 포함돼요:

  • kube-controller-manager
  • kube-proxy
  • kube-apiserver
  • kube-scheduler
  • kubelet

kubelet은 /metrics/cadvisor, /metrics/resource, /metrics/probes에서도 메트릭을 노출하고, kube-state-metrics 같은 애드온은 컨트롤 플레인 신호에 쿠버네티스 객체 상태 정보를 더해줍니다.

일반적인 쿠버네티스 메트릭 파이프라인은 이 엔드포인트를 주기적으로 스크래핑해 샘플을 시계열 데이터베이스(예: Prometheus)에 저장합니다.

설정 옵션과 세부 내용은 시스템 메트릭 가이드를 참고하세요.

멀티 클러스터나 멀티 클라우드 환경을 위한 가시성이 필요하다면, 분산 시계열 데이터베이스(예: Thanos나 Cortex)로 Prometheus를 보완할 수 있어요.

로그 (Logs)

로그는 애플리케이션, 쿠버네티스 시스템 컴포넌트, 그리고 감사(audit) 로깅 같은 보안 관련 활동 안의 이벤트를 시간 순으로 기록합니다.

컨테이너 런타임은 컨테이너화된 애플리케이션의 표준 출력(stdout)과 표준 에러(stderr) 출력을 캡처합니다. 런타임은 방식이 다르지만, kubelet과의 통합은 CRI 로깅 형식으로 표준화되어 있고, kubelet은 kubectl logs를 통해 이 로그를 제공해요.

시스템 컴포넌트 로그는 클러스터에서 발생한 이벤트를 캡처하며 디버깅·트러블슈팅에 자주 유용합니다. 이 컴포넌트는 두 가지로 분류돼요: 컨테이너 안에서 실행되는 것과 그렇지 않은 것. 예를 들어 kube-scheduler와 kube-proxy는 보통 컨테이너에서 실행되고, kubelet과 컨테이너 런타임은 호스트에서 직접 실행됩니다.

  • systemd가 있는 머신에서는 kubelet과 컨테이너 런타임이 journald에 기록합니다. 그렇지 않으면 /var/log 디렉터리의 .log 파일에 기록해요.
  • 컨테이너 안에서 실행되는 시스템 컴포넌트는 기본 컨테이너 로깅 메커니즘을 거치지 않고 항상 /var/log의 .log 파일에 기록합니다.

/var/log 아래 저장되는 시스템·컨테이너 로그는 무한정 커지지 않도록 로그 회전(log rotation)이 필요해요. 일부 클러스터 프로비저닝 스크립트는 기본으로 로그 회전을 설치하지만, 환경을 확인하고 필요에 따라 조정하세요. 자세한 내용은 시스템 로그 레퍼런스를 참고합니다.

대부분의 클러스터는 파일을 트레일링해서 중앙 로그 저장소로 전달하는 노드 레벨 로깅 에이전트(예: Fluent Bit, Fluentd)를 실행합니다. 파이프라인 설계, 보존, 백엔드로의 로그 흐름은 로깅 아키텍처 가이드에서 설명해요.

트레이스 (Traces)

트레이스는 요청이 쿠버네티스 컴포넌트와 애플리케이션 사이를 어떻게 이동하는지 캡처해서, 운영 간의 지연·타이밍·관계를 연결해 줍니다. 트레이스를 수집하면 종단 간 요청 흐름을 시각화하고, 성능 문제를 진단하고, 컨트롤 플레인·애드온·애플리케이션의 병목이나 예상치 못한 상호작용을 식별할 수 있어요.

쿠버네티스 1.36은 OpenTelemetry Protocol(OTLP)로 스팬(span)을 내보낼 수 있어요. 기본 제공되는 gRPC 익스포터로 직접 하거나, OpenTelemetry Collector를 통해 전달하는 방식입니다.

OpenTelemetry Collector는 컴포넌트와 애플리케이션에서 스팬을 받아 처리(예: 샘플링·리덕션 적용)한 뒤, 저장·분석을 위해 트레이싱 백엔드로 전달해요.

공통 관측 가능성 도구 (Common observability tools)

이 섹션은 쿠버네티스에 필요한 기능을 제공하는 서드파티 프로젝트를 링크합니다. 쿠버네티스 프로젝트 저자는 이 프로젝트에 책임지지 않으며, 알파벳 순서로 나열되어 있어요.

더 알아보기 (Learn more)