Kubernetes Observability: 모니터링 대상과 이유

Source: Dev.to

관측성 레이어

Kubernetes 관측성은 각각 다른 전략이 필요한 세 가지 뚜렷한 레이어로 구성됩니다:

1. 클러스터 상태 (인프라)
2. 워크로드 상태 (애플리케이션)
3. 애플리케이션 성능 (사용자 경험)

클러스터‑레벨 메트릭

이것은 “플랫폼이 정상 작동하고 있는가?” 를 판단하는 메트릭입니다.

critical_cluster_metrics:
  nodes:
    - node_ready_status        # 모든 노드가 정상인가?
    - node_cpu_utilization     # 85% 초과 시 알림
    - node_memory_utilization  # 90% 초과 시 알림
    - node_disk_pressure       # 불리언 알림
    - node_pid_pressure        # 거의 발생하지 않지만 항상 중요

  control_plane:
    - apiserver_request_latency_p99  # 1초 초과 시 알림
    - etcd_disk_wal_fsync_duration   # 100ms 초과 시 알림
    - scheduler_pending_pods         # 5분 동안 0보다 크면 알림
    - controller_manager_queue_depth # 증가 추세이면 알림

프로 팁: 개별 노드 CPU에 알림을 설정하지 마세요. 대신 클러스터‑레벨 용량에 알림을 설정합니다:

# 클러스터 사용률이 80 %를 초과하면 알림
(
  sum(node_cpu_seconds_total{mode!="idle"})
  /
  sum(node_cpu_seconds_total)
) > 0.80

워크로드‑레벨 메트릭

대부분의 팀은 워크로드가 아닌 파드만 모니터링해서 실수를 합니다.

critical_workload_metrics:
  deployments:
    - available_replicas  5 min
    - deployment_generation != observed_generation  # 롤아웃이 멈춤

  pods:
    - restart_count increasing               # CrashLoopBackOff 감지
    - container_oom_killed                   # 메모리 제한이 너무 낮음
    - pod_pending_duration > 2 min           # 스케줄링 문제

  hpa:
    - current_replicas == max_replicas       # 스케일 상한에 도달
    - cpu_utilization_vs_target              # 목표치를 지속적으로 초과

예시 알림: CrashLoopBackOff에 걸린 파드 감지

# CrashLoopBackOff에 걸린 파드 감지
alert: PodCrashLooping
expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
for: 15m
labels:
  severity: warning
annotations:
  summary: "Pod {{ $labels.pod }} is crash-looping"
  description: "{{ $labels.pod }} in {{ $labels.namespace }} has restarted {{ $value }} times in 15 minutes"

애플리케이션‑레벨 메트릭

이 메트릭은 실제 사용자들이 신경 쓰는 부분을 반영합니다.

application_metrics:
  red_method:  # Rate, Errors, Duration
    - request_rate_per_second
    - error_rate_percentage        # 1 % 초과 시 알림
    - request_duration_p99         # 500 ms 초과 시 알림

  use_method:  # Utilization, Saturation, Errors
    - cpu_request_vs_limit_ratio
    - memory_request_vs_limit_ratio
    - network_receive_bytes_rate

단일 “K8s Health” 대시보드

우리는 네 개의 패널로 구성된 대시보드를 만들었으며, 이는 “뭔가 문제가 있나요?” 라는 질문의 약 90 %에 답합니다:

1. 클러스터 용량 – 노드 풀별 CPU/메모리/디스크 사용률
2. 워크로드 상태 – 모든 디플로이먼트를 건강 상태와 함께 표기
3. 오류율 – 서비스 전체를 오류율 순으로 정렬
4. 최근 이벤트 – 경고와 오류만 필터링한 K8s 이벤트

흔히 저지르는 실수

• 파드 대신 서비스 모니터링 – 파드는 일시적이며, 중요한 것은 서비스입니다.
• 리소스 요청을 설정하지 않음 – 요청이 없으면 메트릭이 의미가 없습니다.
• SLO 대신 리소스 사용량에 알림 – CPU가 높아도 지연 시간이 괜찮다면 문제되지 않습니다.
• 컨트롤 플레인 무시 – API 서버가 비정상이면 모든 것이 영향을 받습니다.

통합 Kubernetes 관측성을 원하나요?

우리가 구축하고 있는 Nova AI Ops 를 확인해 보세요.