Kubernetes 환경에서 Monitoring이 현재 상태를 확인하는 역할이라면 Logging은 문제가 발생한 원인을 분석하는 역할을 담당합니다.
실제 운영 환경에서는 다음과 같은 상황이 자주 발생합니다.
Application 오류 발생
↓
Pod 재시작
↓
서비스 장애 발생
이때 운영자는 다음 질문에 답해야 합니다.
- 어떤 Container에서 오류가 발생했는가?
- 언제 문제가 시작되었는가?
- 어떤 Error Message가 발생했는가?
- 여러 Pod 중 어떤 Pod가 원인인가?
이러한 문제를 해결하기 위해 Kubernetes에서는 Container Log를 수집하고 중앙에서 관리하는 Logging Architecture가 필요합니다.
| 구성 요소 | 역할 |
|---|---|
| Container Log | Application 실행 기록 |
| Node Logging | Node 단위 Log 관리 |
| Log Agent | Log 수집 |
| Log Storage | Log 저장 |
| Visualization | Log 검색 및 분석 |
Kubernetes Logging Architecture를 이해하면 장애 원인을 빠르게 분석하고 안정적인 Production 환경을 운영할 수 있습니다.
Kubernetes Logging이 필요한 이유
Container 환경에서는 Pod가 계속 생성되고 삭제됩니다.
일반 Server:
하나의 Server
↓
하나의 Log File 관리
Kubernetes:
Node 여러 개
↓
Pod 수십~수백 개
↓
Container 생성·삭제 반복
기존 방식으로는 Log 관리가 어렵습니다.
특히 Kubernetes 환경에서는 다음 문제가 발생합니다.
- Pod 삭제 후 Log 손실
- 여러 Node Log 관리 어려움
- 장애 Container 찾기 어려움
- 장기간 Log 보관 필요
따라서 중앙 집중 Logging 시스템이 필요합니다.
Kubernetes Container Log 기본 구조
Kubernetes Container Log는 기본적으로 Container Runtime이 관리합니다.
구조:
Application
↓
stdout / stderr 출력
↓
Container Runtime
↓
Node Log 저장
↓
kubectl logs 확인
Application은 별도 Log File을 관리하지 않고 표준 출력 방식으로 Log를 기록하는 것이 일반적입니다.
Kubernetes kubectl logs 동작 방식
가장 기본적인 Log 확인 방법입니다.
Pod 확인:
kubectl get podsLog 확인:
kubectl logs pod-name결과:
Application Error
↓
Stack Trace
↓
실패 원인 확인
개발 환경에서는 유용하지만 Production 환경에서는 한계가 있습니다.
kubectl logs 방식의 한계
직접 Log 확인 방식은 규모가 커지면 문제가 발생합니다.
예:
Cluster:
Node 10개
↓
Pod 500개
↓
운영자가 직접 확인
문제:
- 검색 어려움
- 보관 어려움
- 장애 추적 어려움
따라서 중앙 Logging 시스템이 필요합니다.
Kubernetes Logging Architecture 구조
일반적인 Production Logging 구조:
Application Container
↓
stdout / stderr
↓
Node Log
↓
Log Agent
↓
Central Logging System
↓
Dashboard
대표적인 구성:
- Fluent Bit
- Fluentd
- Elasticsearch
- Loki
- Grafana
운영 환경에서는 이러한 구조를 사용합니다.
Kubernetes Log Agent 역할
Log Agent는 각 Node에서 발생하는 Container Log를 수집합니다.
구조:
Worker Node
↓
Log Agent
↓
Log Storage
대표적인 방식:
DaemonSet 배포
이유:
모든 Node에서 하나씩 실행되어야 하기 때문입니다.
이전에 배운 DaemonSet 구조와 연결됩니다.
Kubernetes Logging과 DaemonSet 관계
Logging Agent는 대부분 DaemonSet으로 배포됩니다.
구조:
Node 1
↓
Fluent Bit Pod
Node 2
↓
Fluent Bit Pod
Node 3
↓
Fluent Bit Pod
새로운 Node 추가:
Node 생성
↓
DaemonSet 감지
↓
Log Agent 자동 생성
자동으로 Logging 환경이 확장됩니다.
Kubernetes 주요 Logging 방식
Kubernetes Logging은 크게 세 가지 방식으로 나눌 수 있습니다.
Node-Level Logging
가장 기본 방식입니다.
구조:
Container
↓
Node Log
↓
Agent 수집
장점:
간단한 구성
단점:
Node 장애 시 Log 손실 가능
Sidecar Logging
Container 옆에 Log Container를 함께 실행합니다.
구조:
Application Container
Log Sidecar Container
↓
Log Storage
장점:
Application별 관리 가능
단점:
Resource 증가
Agent 방식
가장 일반적인 Production 방식입니다.
구조:
모든 Node
↓
Logging Agent
↓
중앙 저장소
대규모 Cluster에 적합합니다.
Kubernetes Logging Storage 구성
수집한 Log는 별도 Storage에 저장합니다.
대표 구성:
Elasticsearch
대규모 검색 중심 Logging
Loki
Grafana 기반 Lightweight Logging
Cloud Logging
AWS CloudWatch
Google Cloud Logging
환경에 맞게 선택합니다.
Kubernetes Logging과 Monitoring 차이
두 시스템은 함께 사용됩니다.
| 구분 | Monitoring | Logging |
|---|---|---|
| 목적 | 상태 확인 | 원인 분석 |
| 데이터 | Metric | Text |
| 예시 | CPU 90% | Error Message |
| 도구 | Prometheus | Loki/ELK |
장애 분석에서는 두 데이터를 함께 확인해야 합니다.
Kubernetes Logging 장애 분석 과정
실제 운영 흐름:
서비스 오류 발생
↓
Monitoring Alert 확인
↓
관련 Pod 확인
↓
Container Log 확인
↓
Error 분석
↓
원인 해결
Logging은 장애 원인 분석의 핵심 데이터입니다.
Kubernetes Log 보관 정책
Production 환경에서는 Log 보관 기간을 관리해야 합니다.
예:
개발 환경:
7일 보관
운영 환경:
30~90일 보관
보안 환경:
장기간 보관
고려 항목:
- Storage 비용
- Compliance
- 장애 분석 필요성
Kubernetes Logging 운영 시 주의사항
Log가 많다고 항상 좋은 것은 아닙니다.
주의:
| 항목 | 설명 |
|---|---|
| Log Level 관리 | 불필요한 Log 감소 |
| Storage 관리 | 용량 확보 |
| 개인정보 보호 | 민감 정보 제거 |
| 검색 성능 | Index 관리 |
운영 Logging은 관리 전략이 필요합니다.
Kubernetes Logging과 DevOps 관계
CI/CD와 Runtime Logging은 연결됩니다.
구조:
배포
↓
Application 실행
↓
Log 생성
↓
Monitoring
↓
장애 분석
DevOps 운영에서는 배포 이후 관찰 가능한 환경이 중요합니다.
Kubernetes Logging Architecture 장점
| 장점 | 설명 |
|---|---|
| 장애 분석 | 원인 확인 가능 |
| 중앙 관리 | 여러 Node 통합 |
| 검색 가능 | 빠른 분석 |
| 자동 수집 | 운영 효율 증가 |
Logging Architecture는 Production Kubernetes 운영의 필수 요소입니다.
자주 묻는 질문
kubectl logs만 사용하면 안 되나요?
가능하지만 대규모 Production 환경에서는 중앙 Logging 시스템이 필요합니다.
Logging Agent는 왜 DaemonSet으로 실행하나요?
모든 Node의 Log를 수집해야 하기 때문입니다.
Monitoring과 Logging 중 무엇이 더 중요한가요?
둘 다 필요합니다.
Monitoring은 문제 발견, Logging은 원인 분석 역할을 합니다.
마무리
Kubernetes Logging Architecture는 Container Log를 수집하고 중앙에서 분석하기 위한 운영 구조입니다.
| 구성 요소 | 역할 |
|---|---|
| Container Log | Application 기록 |
| DaemonSet Agent | Log 수집 |
| Storage | Log 저장 |
| Dashboard | 분석 화면 |
Logging 구조를 이해하면 Kubernetes 환경에서 장애 원인을 빠르게 찾고 안정적인 Production 서비스를 운영할 수 있습니다.
다음 글에서는 Kubernetes에서 가장 많이 사용하는 Log 수집 Agent인 Fluent Bit 완벽 가이드! Kubernetes Container Log 수집 Agent 운영 구조 이해하기를 알아보겠습니다.