
쿠버네티스(Kubernetes)는 강력한 컨테이너 오케스트레이션 도구지만, 그 동적이고 분산된 특성 때문에 문제가 발생했을 때 원인을 파악하기가 매우 어렵습니다. 수십, 수백 개의 컨테이너와 노드가 쉴 새 없이 상호작용하는 환경에서 장애의 실마리를 찾을 수 있는 유일한 단서는 바로 로그입니다.
체계적인 로그 수집 및 관리 시스템 없이는 단순한 오류 해결조차 긴 시간과 노력을 허비하는 미로 찾기가 될 수 있습니다. 반대로, 필수적인 로그들을 잘 수집하고 있다면 안정적인 시스템 운영을 위한 가장 강력한 무기를 손에 쥐는 것과 같습니다.
이번 글에서는 성공적인 쿠버네티스 운영을 위해 반드시 수집해야 하는 로그의 종류들을 상세히 알아보고, 각 로그가 어떤 중요한 정보를 담고 있는지 살펴보겠습니다.
1. 컨테이너 로그 (애플리케이션 로그) 📦
가장 기본적이면서 가장 중요한 로그입니다. 우리가 쿠버네티스를 사용하는 이유, 바로 애플리케이션이 남기는 기록이기 때문입니다.
- 수집 대상: 컨테이너화된 애플리케이션이 표준 출력(stdout)과 표준 에러(stderr)로 내보내는 모든 로그
- 왜 중요한가?:
- 애플리케이션의 비즈니스 로직 수행 여부, 오류, 성능 지표 등을 파악할 수 있는 유일한 정보입니다.
- CrashLoopBackOff와 같은 파드 비정상 종료 상태의 직접적인 원인을 담고 있습니다.
- 수집 방법:
- 컨테이너화된 애플리케이션은 로그를 파일로 남기지 않고 stdout/stderr로 스트리밍하는 것이 표준입니다. 쿠버네티스는 이 스트림을 자동으로 수집하여 kubectl logs <pod-name> 명령어로 확인할 수 있게 해줍니다.
- 구조화된 로깅(Structured Logging): 로그를 일반 텍스트가 아닌 JSON과 같은 형식으로 출력하는 것이 매우 중요합니다. {"level": "error", "timestamp": "...", "user_id": 123, "message": "Failed to process payment"}와 같이 구조화된 로그는 나중에 중앙 로깅 시스템에서 검색, 필터링, 시각화하기 훨씬 용이합니다.
2. 노드 로그 (컴포넌트 및 시스템 로그) 🖥️
파드가 실행되는 기반인 워커 노드(Worker Node) 자체에서 발생하는 로그입니다. 컨테이너나 애플리케이션 문제가 아닌, 인프라 레벨의 문제를 진단하는 데 필수적입니다.
- 수집 대상:
- Kubelet 로그: 각 노드에서 파드의 라이프사이클을 관리하는 핵심 에이전트입니다. 파드가 왜 Pending 상태에 머무는지, 이미지를 왜 받아오지 못하는지, Liveness/Readiness Probe가 왜 실패하는지와 같은 파드 수준의 문제를 진단하는 데 결정적인 정보를 제공합니다.
- 컨테이너 런타임 로그: containerd나 CRI-O와 같이 실제로 컨테이너를 실행하는 런타임의 로그입니다. 컨테이너 시작 실패, 스토리지 볼륨 마운트 오류 등 컨테이너 실행 자체의 문제를 파악할 수 있습니다.
- 시스템 로그: systemd 저널(journalctl), /var/log/syslog 등 노드 운영체제(OS)에서 발생하는 로그입니다. 커널 패닉, 네트워크 인터페이스 오류, 디스크 문제 등 하드웨어나 OS 레벨의 문제를 진단하는 데 사용됩니다.
- 왜 중요한가?: 애플리케이션은 정상이지만 "파드가 시작되지 않아요", "갑자기 파드가 사라졌어요"와 같은 문제들은 대부분 노드 레벨의 로그에 단서가 있습니다.
3. 컨트롤 플레인 로그 🧠
클러스터의 두뇌 역할을 하는 컨트롤 플레인(Control Plane) 컴포넌트들의 로그입니다. 클러스터 전반의 동작과 상태, 정책과 관련된 문제를 해결하는 열쇠입니다. GKE, EKS, AKS와 같은 매니지드 쿠버네티스(Managed Kubernetes)를 사용하면 클라우드 제공업체가 이 로그들을 수집하여 제공해 줍니다.
- 수집 대상:
- API 서버 로그 (kube-apiserver): 모든 쿠버네티스 요청이 거쳐가는 관문입니다. "누가, 언제, 무엇을 요청했는지"에 대한 모든 기록이 담겨있어 보안 감사와 인증/인가 문제 해결에 가장 중요합니다. 특정 사용자의 요청이 왜 거부되었는지, 어떤 컨트롤러가 API 서버에 과도한 부하를 주는지 등을 파악할 수 있습니다.
- 스케줄러 로그 (kube-scheduler): 파드를 어떤 노드에 배치할지 결정하는 컴포넌트입니다. 파드가 Pending 상태로 계속 대기할 때, 스케줄러 로그를 보면 "리소스 부족", "Taint/Toleration 불일치", "Affinity 규칙 위반" 등 배치 실패 원인을 명확히 알 수 있습니다.
- 컨트롤러 매니저 로그 (kube-controller-manager): Deployment, ReplicaSet 등 클러스터의 상태를 관리하는 컨트롤러들의 로그입니다. "Deployment를 만들었는데 왜 파드가 생성되지 않지?"와 같은 상태 불일치 문제를 진단할 때 유용합니다.
- etcd 로그: 클러스터의 모든 상태 정보(모든 오브젝트의 명세)를 저장하는 핵심 데이터베이스입니다. etcd 로그는 클러스터의 성능 저하, 불안정성, 데이터 손상과 같은 심각한 문제를 진단할 때 필요하지만, 매우 상세하고 양이 많아 주로 최후의 수단으로 분석합니다.
4. 네트워크 및 보안 로그 🛡️
클러스터 내부 통신과 외부 접근에 관련된 로그들입니다. 복잡한 마이크로서비스 환경에서 통신 문제를 해결하고 보안을 강화하는 데 필수적입니다.
- 수집 대상:
- Ingress Controller 로그: NGINX, Traefik 등 외부 트래픽을 내부 서비스로 연결해주는 Ingress Controller의 접근 로그와 오류 로그입니다. "외부에서 서비스 접속이 안 돼요", "HTTP 502/503 오류가 발생해요"와 같은 외부 트래픽 관련 문제 해결의 첫걸음입니다.
- CNI 플러그인 로그: Calico, Cilium, Flannel 등 파드 간 통신을 담당하는 CNI(Container Network Interface) 플러그인의 로그입니다. 파드 간 통신 문제를 진단하는 데 사용됩니다.
- Network Policy 로그: Calico, Cilium과 같이 네트워크 정책(Network Policy)을 지원하는 CNI의 경우, 특정 파드의 트래픽이 정책에 의해 허용되거나 차단될 때 로그를 남길 수 있습니다. "분명히 서비스가 떠 있는데 옆에 있는 파드에서 접속이 안 돼요"와 같은 문제를 해결하는 데 결정적입니다.
- 쿠버네티스 감사 로그 (Audit Logs): API 서버 로그의 일종이지만 보안에 특화된 로그입니다. 클러스터에서 발생하는 모든 활동(생성, 삭제, 수정 등)에 대한 보안 감사 추적을 위해 반드시 활성화하고 수집해야 합니다. 누가 어떤 리소스를 삭제했는지, 누가 어떤 권한을 사용했는지 등을 명확히 기록하여 보안 사고 분석과 규정 준수(Compliance)에 필수적입니다.
결론: 중앙화된 로깅 시스템은 선택이 아닌 필수
지금까지 살펴본 것처럼, 쿠버네티스 환경에서는 애플리케이션부터 인프라, 컨트롤 플레인에 이르기까지 매우 다양하고 분산된 로그가 생성됩니다. kubectl logs나 각 노드에 직접 접속하여 로그를 확인하는 방식은 임시방편일 뿐, 실제 운영 환경에서는 거의 불가능에 가깝습니다.
따라서 Fluentd/Fluent-bit, Logstash와 같은 로그 수집기를 사용하여 모든 로그를 한곳으로 모으고, Elasticsearch나 Loki와 같은 중앙 로깅 시스템에 저장하여 검색 및 분석할 수 있는 환경을 구축하는 것이 무엇보다 중요합니다.
어떤 로그를 수집해야 할지 아는 것은 안정적인 쿠버네티스 운영의 시작입니다. 오늘 소개된 로그들을 체계적으로 수집하고 관리하여 어떤 장애 상황에서도 자신감 있게 대처할 수 있는 강력한 관측 가능성(Observability)을 확보하시길 바랍니다.
'클라우드 > 쿠버네티스' 카테고리의 다른 글
| 쿠버네티스 QoS 클래스, 어떤 파드의 우선순위를 높여야 할까? 🚀 (4) | 2025.08.01 |
|---|---|
| 내 클러스터 지키는 파수꾼: 쿠버네티스 리소스 요청(Request)과 제한(Limit) 완벽 가이드 (4) | 2025.07.31 |
| 쿠버네티스 Ingress Controller 대표 주자 3대장: NGINX, Traefik, HAProxy 전격 비교 (5) | 2025.07.31 |
| ☸️ 쿠버네티스와 🏦 Vault를 연동한 시크릿 관리 아키텍처 (5) | 2025.07.30 |
| 🤫 쿠버네티스 시크릿 관리의 정석: Vault와 KMS로 etcd 데이터 안전하게 지키기 (1) | 2025.07.30 |