관측성

관측성 (Observability)

쿠버네티스에서 관측성(observability)은 종종 관측성의 세 기둥(three pillars)으로 불리는 메트릭, 로그, 트레이스를 수집하고 분석해 클러스터의 내부 상태, 성능, 상태에 대한 더 나은 이해를 얻는 과정이에요.

쿠버네티스 제어 플레인 구성 요소와 많은 애드온은 이러한 신호를 생성하고 방출해요. 그것들을 집계하고 연관지으면 제어 플레인, 애드온, 클러스터 전반의 애플리케이션에 대한 통일된 그림을 얻을 수 있어요.

그림 1은 클러스터 구성 요소가 세 가지 주요 신호 유형을 어떻게 방출하는지 개요로 보여 줘요.

flowchart LR
    A[Cluster components] --> M[Metrics pipeline]
    A --> L[Log pipeline]
    A --> T[Trace pipeline]
    M --> S[(Storage and analysis)]
    L --> S
    T --> S
    S --> O[Operators and automation]

그림 1. 클러스터 구성 요소가 방출하는 상위 수준 신호와 그 소비자.

출처: 문서

본문

메트릭 (Metrics)

쿠버네티스 구성 요소는 프로메테우스 형식의 메트릭을 자신의 /metrics 엔드포인트에서 방출해요. 다음을 포함합니다.

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

kubelet은 또한 /metrics/cadvisor, /metrics/resource, /metrics/probes에서 메트릭을 노출하며, kube-state-metrics 같은 애드온은 쿠버네티스 객체 상태로 이러한 제어 플레인 신호를 풍부하게 해요.

일반적인 쿠버네티스 메트릭 파이프라인은 주기적으로 이러한 엔드포인트를 스크랩(scrape)하고 샘플을 시계열 데이터베이스(예: Prometheus)에 저장해요.

세부 사항과 구성 옵션은 시스템 메트릭 가이드를 참고하세요.

그림 2는 일반적인 쿠버네티스 메트릭 파이프라인을 개요로 보여 줘요.

flowchart LR
    C[Cluster components] --> P[Prometheus scraper]
    P --> TS[(Time series storage)]
    TS --> D[Dashboards and alerts]
    TS --> A[Automated actions]

그림 2. 일반적인 쿠버네티스 메트릭 파이프라인의 구성 요소.

다중 클러스터 또는 다중 클라우드 가시성을 위해 분산 시계열 데이터베이스(예: Thanos 또는 Cortex)가 Prometheus를 보완할 수 있어요.

메트릭 스크래퍼와 시계열 데이터베이스에 대해서는 '공통 관측성 도구 - 메트릭 도구'를 참고하세요.

메트릭 API (Metrics API)

쿠버네티스 메트릭 API는 노드와 파드의 CPU 및 메모리 리소스 사용량을 제공해요. kubectl top 명령과 HorizontalPodAutoscaler, VerticalPodAutoscaler 같은 구성 요소가 이 API를 사용해요.

kubectl top은 metrics.k8s.io/v1과 metrics.k8s.io/v1beta1을 모두 지원해요. 해당 버전을 사용할 수 있을 때 v1을 선호하고, v1beta1로 폴백해요. 쿠버네티스 v1.37에서 HorizontalPodAutoscaler 컨트롤러는 metrics.k8s.io/v1beta1만 지원하며, metrics.k8s.io/v1 지원은 계획되어 있지만 아직 사용할 수 없어요.

앞서 설명한 구성 요소 메트릭 엔드포인트와 달리 메트릭 API는 쿠버네티스 API 집계 계층(API aggregation layer)을 통해 서비스돼요. 클러스터는 Metrics Server 또는 그 API를 제공하는 다른 구현을 실행해야 해요. 메트릭 API는 의도적으로 오토스케일링과 기본 검사에 필요한 리소스 메트릭만 제공하며, 완전한 모니터링 파이프라인의 대체물이 아니에요.

API, 그 구현, kubelet에서 클라이언트까지의 데이터 흐름에 대해 배우려면 리소스 메트릭 파이프라인 문서를 참고하세요.

See Also

• 쿠버네티스 구성 요소용 시스템 메트릭
• metrics-server로 리소스 사용량 모니터링
• kube-state-metrics 개념

로그 (Logs)

로그는 애플리케이션, 쿠버네티스 시스템 구성 요소 내부의 사건, 그리고 감사 로깅(audit logging) 같은 보안 관련 활동에 대한 시간순 기록을 제공해요.

컨테이너 런타임은 컨테이너화된 애플리케이션의 출력을 표준 출력(stdout)과 표준 오류(stderr) 스트림에서 포착해요. 런타임은 이것을 다르게 구현하지만, kubelet과의 통합은 CRI 로깅 형식을 통해 표준화되며, kubelet은 kubectl logs를 통해 이 로그를 사용 가능하게 해요.

그림 3a. 노드 수준 로깅 아키텍처.

시스템 구성 요소 로그는 클러스터의 사건을 포착하며 디버깅과 문제 해결에 종종 유용해요. 이러한 구성 요소는 컨테이너에서 실행되는 것과 그렇지 않은 것의 두 가지 방식으로 분류돼요. 예를 들어 kube-scheduler와 kube-proxy는 보통 컨테이너에서 실행되고, kubelet과 컨테이너 런타임은 호스트에서 직접 실행돼요.

• systemd가 있는 머신에서 kubelet과 컨테이너 런타임은 journald에 기록해요. 그렇지 않으면 /var/log 디렉터리의 .log 파일에 기록해요.
• 컨테이너 안에서 실행되는 시스템 구성 요소는 항상 기본 컨테이너 로깅 메커니즘을 우회해 /var/log의 .log 파일에 기록해요.

/var/log 아래에 저장된 시스템 구성 요소 및 컨테이너 로그는 통제되지 않은 증가를 방지하기 위해 로그 로테이션이 필요해요. 일부 클러스터 프로비저닝 스크립트는 기본적으로 로그 로테이션을 설치해요. 환경을 확인하고 필요에 따라 조정하세요. 위치, 형식, 구성 옵션의 세부 사항은 시스템 로그 참조를 참고하세요.

대부분의 클러스터는 이러한 파일을 추적(tail)해 중앙 로그 저장소로 항목을 전달하는 노드 수준 로깅 에이전트(예: Fluent Bit 또는 Fluentd)를 실행해요. 로깅 아키텍처 안내는 그러한 파이프라인을 설계하고, 보존을 적용하며, 백엔드로 로그 흐름을 보내는 방법을 설명해요.

그림 3은 일반적인 로그 집계 파이프라인을 개요로 보여 줘요.

flowchart LR
    subgraph Sources
        A[Application stdout / stderr]
        B[Control plane logs]
        C[Audit records]
    end
    A --> N[Node log agent]
    B --> N
    C --> N
    N --> L[Central log store]
    L --> Q[Dashboards, alerting, SIEM]

그림 3. 일반적인 쿠버네티스 로그 파이프라인의 구성 요소.

로깅 에이전트와 중앙 로그 저장소에 대해서는 '공통 관측성 도구 - 로깅 도구'를 참고하세요.

See Also

• 로깅 아키텍처
• 시스템 로그
• 로깅 작업과 튜토리얼
• 감사 로깅 구성

트레이스 (Traces)

트레이스는 요청이 쿠버네티스 구성 요소와 애플리케이션을 어떻게 이동하는지 포착해, 작업 간의 지연, 타이밍, 관계를 연결해요. 트레이스를 수집하면 엔드 투 엔드 요청 흐름을 시각화하고, 성능 문제를 진단하며, 제어 플레인, 애드온, 또는 애플리케이션의 병목이나 예상치 못한 상호작용을 식별할 수 있어요.

쿠버네티스 1.37은 OpenTelemetry Protocol(OTLP)을 통해 스팬(span)을 내보낼 수 있어요. 내장된 gRPC 익스포터를 통해 직접 하거나, OpenTelemetry Collector를 통해 전달해서요.

OpenTelemetry Collector는 구성 요소와 애플리케이션에서 스팬을 받아 처리하고(예: 샘플링 또는 편집 적용), 저장과 분석을 위해 트레이싱 백엔드로 전달해요.

그림 4는 일반적인 분산 트레이싱 파이프라인을 개요로 보여 줘요.

flowchart LR
    subgraph Sources
        A[Control plane spans]
        B[Application spans]
    end
    A --> X[OTLP exporter]
    B --> X
    X --> COL[OpenTelemetry Collector]
    COL --> TS[(Tracing backend)]
    TS --> V[Visualization and analysis]

그림 4. 일반적인 쿠버네티스 트레이스 파이프라인의 구성 요소.

트레이싱 수집기와 백엔드에 대해서는 '공통 관측성 도구 - 트레이싱 도구'를 참고하세요.

See Also

• 쿠버네티스 구성 요소용 시스템 트레이스
• OpenTelemetry Collector 시작하기 가이드
• 모니터링 및 트레이싱 작업

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

참고: 이 섹션은 쿠버네티스가 요구하는 관측성 기능을 제공하는 서드파티 프로젝트에 연결돼요. 쿠버네티스 프로젝트 작성자는 가나다순으로 나열된 이러한 프로젝트에 대해 책임지지 않아요. 이 목록에 프로젝트를 추가하려면 변경을 제출하기 전에 콘텐츠 가이드를 읽으세요.

메트릭 도구

• Cortex: 수평 확장 가능한 장기 Prometheus 저장소 제공.
• Grafana Mimir: 멀티 테넌트, 수평 확장 가능한 Prometheus 호환 저장소를 제공하는 Grafana Labs 프로젝트.
• Prometheus: 쿠버네티스 구성 요소의 메트릭을 스크랩하고 저장하는 모니터링 시스템.
• Thanos: 전역 쿼리, 다운샘플링, 객체 저장소 지원으로 Prometheus를 확장.

로깅 도구

• Elasticsearch: 분산 로그 인덱싱과 검색 제공.
• Fluent Bit: 낮은 리소스 사용량으로 컨테이너 및 노드 로그 수집·전달.
• Fluentd: 로그를 여러 대상으로 라우팅하고 변환.
• Grafana Loki: Prometheus에서 영감을 받은 라벨 기반 형식으로 로그 저장.
• OpenSearch: Elasticsearch API와 호환되는 오픈소스 로그 인덱싱·검색 제공.

트레이싱 도구

• Grafana Tempo: 확장 가능하고 저비용인 분산 트레이싱 저장소 제공.
• Jaeger: 마이크로서비스용 분산 트레이스 포착·시각화.
• OpenTelemetry Collector: 트레이스를 포함한 텔레메트리 데이터 수신·처리·내보내기.
• Zipkin: 분산 트레이싱 수집과 시각화 제공.

더 알아보기 (Learn more)

• metrics-server로 리소스 사용량 메트릭 수집 방법을 배워 보세요.
• 로깅 작업과 튜토리얼 살펴보기
• 모니터링 및 트레이싱 작업 가이드 따라가기
• 구성 요소 엔드포인트와 안정성에 대한 시스템 메트릭 가이드 검토
• 검증된 서드파티 옵션에 대한 공통 관측성 도구 섹션 검토