고급 문제 해결: 쿠버네티스 로그, 이벤트 및 메트릭 심층 분석

쿠버네티스 문제 해결은 세 가지 질문을 분리하면 더 쉬워집니다: 컨테이너가 무엇을 말했는가, 컨트롤 플레인이 무엇을 했는가, 메트릭이 무엇을 보여주는가? 로그, 이벤트 및 메트릭은 동일한 인시던트의 서로 다른 부분에 답변합니다.

아래 예제는 파드가 충돌하거나, 이미지를 가져올 수 없거나, 워크로드를 스케줄링할 수 없거나, 서비스가 정상으로 보이지만 느리게 응답할 때 세 가지를 모두 함께 사용하는 방법을 보여줍니다.

쿠버네티스 로그: 디버깅의 기초

로그는 애플리케이션 또는 시스템 프로세스가 수행하는 작업에 대한 상세 기록입니다. 쿠버네티스에서 로그는 파드 내에서 실행되는 컨테이너에 의해 생성됩니다. 애플리케이션이 예상대로 작동하지 않을 때 가장 먼저 확인하는 곳인 경우가 많습니다.

컨테이너 로그 액세스

kubectl logs 명령은 파드에서 로그를 검색하는 주요 도구입니다. 다재다능하며 여러 유용한 옵션을 제공합니다.

파드의 단일 컨테이너에서 로그 가져오기:
```
kubectl logs <파드-이름>
```
파드에 컨테이너가 하나만 있는 경우 이 명령이 직접 작동합니다.
멀티 컨테이너 파드의 특정 컨테이너에서 로그 가져오기:
```
kubectl logs <파드-이름> -c <컨테이너-이름>
```
충돌한 컨테이너의 이전 인스턴스 로그 보기: 오류로 인해 컨테이너가 재시작된 경우 --previous 플래그를 사용하여 재시작 전의 로그를 볼 수 있습니다:
```
kubectl logs <파드-이름> --previous
```
실시간 로그 팔로우: tail -f와 유사하게 -f(또는 --follow) 플래그를 사용하면 새 로그 항목이 생성될 때 실시간으로 스트리밍할 수 있어 실시간 문제 디버깅에 매우 유용합니다.
```
kubectl logs -f <파드-이름> -c <컨테이너-이름>
```
시간별 로그 필터링: 끝에서부터 검색할 줄 수(--tail) 또는 특정 기간의 로그(--since)를 지정할 수 있습니다.
```
kubectl logs <파드-이름> --tail=100 # 마지막 100줄
kubectl logs <파드-이름> --since=1h # 지난 1시간 로그
```

중앙 집중식 로깅 솔루션

kubectl logs는 즉각적인 디버깅에 탁월하지만 대규모 장기 로그 관리에는 실용적이지 않습니다. 프로덕션 환경에서는 중앙 집중식 로깅 솔루션이 필수적입니다. 이러한 솔루션에는 일반적으로 다음이 포함됩니다:

로그 에이전트: 모든 파드에서 로그를 수집하기 위해 각 노드에서 에이전트(예: Fluentd, Fluent Bit, Filebeat) 실행.
로그 저장소 및 인덱싱: 중앙 저장소(예: Elasticsearch, Loki, Splunk)에 로그 저장.
로그 시각화 및 분석: 로그를 검색, 필터링 및 시각화하는 인터페이스 제공(예: Kibana, Grafana, Splunk UI).

로깅 모범 사례

구조화된 로깅: 중앙 집중식 로깅 시스템에서 쉽게 구문 분석하고 쿼리할 수 있도록 구조화된 형식(예: JSON)으로 로그를 출력합니다.
적절한 로그 레벨: 다양한 로그 레벨(DEBUG, INFO, WARN, ERROR, FATAL)을 사용하여 메시지를 분류하고 자세한 정도를 제어합니다.
민감한 정보 피하기: 민감한 데이터(비밀번호, PII)를 직접 로깅하지 마십시오.

쿠버네티스 이벤트: 클러스터의 이야기꾼

쿠버네티스 이벤트는 클러스터 내에서 발생하는 상태 변경 및 작업에 대한 기록입니다. 이는 사용자의 원하는 상태에 응답하여 쿠버네티스 자체가 무엇을 하고 있는지(또는 실패하고 있는지)에 대한 중요한 통찰력을 제공합니다. 이벤트는 파드가 스케줄링되지 않거나, 이미지를 가져오지 못하거나, 볼륨이 마운트되지 않는 이유를 이해하는 데 매우 중요합니다.

쿠버네티스 이벤트 액세스

클러스터 전체 이벤트:

kubectl get events

이 명령은 현재 네임스페이스의 모든 최근 이벤트를 표시합니다. --all-namespaces를 추가하여 전체 클러스터의 이벤트를 볼 수 있습니다.

일반적인 이벤트 출력은 다음과 같습니다:

LAST SEEN   TYPE      REASON      OBJECT                         MESSAGE
3m21s       Normal    Scheduled   pod/my-app-789c6f66-abcde      Successfully assigned default/my-app-789c6f66-abcde to node01
3m20s       Normal    Pulling     pod/my-app-789c6f66-abcde      Pulling image "example/my-app:1.2.3"
2m58s       Warning   BackOff     pod/my-app-789c6f66-abcde      Back-off restarting failed container app

단일 객체에 대한 이벤트:
```
kubectl describe pod <파드-이름>
```
하단의 Events 섹션은 단일 파드의 스케줄링, 풀링, 마운팅 및 재시작 문제를 가장 빠르게 확인할 수 있는 방법인 경우가 많습니다.

생성 시간별로 이벤트 정렬:

kubectl get events --sort-by=.metadata.creationTimestamp

이벤트가 일반적으로 알려주는 것

이벤트는 수명이 짧은 기록이므로 최근 실패에 가장 적합합니다. 다음과 같은 일반적인 이유를 찾으십시오:

FailedScheduling: 스케줄러가 파드를 배치할 수 없습니다. 노드 셀렉터, 테인트, 톨러레이션, 리소스 요청 및 사용 가능한 용량을 확인하십시오.
ImagePullBackOff 또는 ErrImagePull: 쿠버네티스가 이미지를 가져올 수 없습니다. 이미지 이름, 태그, 레지스트리 액세스 및 이미지 풀 시크릿을 확인하십시오.
FailedMount: 볼륨을 마운트할 수 없습니다. PVC 바인딩, 스토리지 클래스, 노드 권한 및 CSI 드라이버 상태를 확인하십시오.
BackOff: 컨테이너가 계속 실패합니다. 이벤트를 kubectl logs --previous와 함께 사용하십시오.

쿠버네티스 메트릭: 리소스 보기

메트릭은 클러스터에 워크로드에 충분한 CPU, 메모리 및 용량이 있는지 알려줍니다. 또한 애플리케이션 버그와 리소스 압력을 분리하는 데 도움이 됩니다.

metrics-server를 사용한 빠른 확인

metrics-server가 설치된 경우 kubectl top을 사용하십시오:

kubectl top nodes
kubectl top pods
kubectl top pod <파드-이름> --containers

컨테이너 제한에 가까운 높은 파드 메모리는 종종 OOMKilled 재시작과 일치합니다. 높은 노드 CPU는 파드 로그가 깨끗해 보여도 지연 시간을 설명할 수 있습니다.

Prometheus를 사용한 심층 메트릭

프로덕션에서는 Prometheus와 Grafana가 일반적으로 kubectl top이 부족한 기록 보기를 제공합니다. 유용한 신호는 다음과 같습니다:

시간 경과에 따른 컨테이너 재시작.
낮은 CPU 제한이 있는 컨테이너의 CPU 스로틀링.
제한과 비교한 메모리 작업 세트.
네임스페이스별 대기 중인 파드.
API 서버 요청 지연 시간 및 오류율.
노드 디스크 압력, 메모리 압력 및 네트워크 포화.

로그, 이벤트 및 메트릭 상호 연관

시간 창을 사용하고 증상에서 원인으로 이동하십시오:

파드 상태 확인:

kubectl get pod <파드-이름> -o wide
kubectl describe pod <파드-이름>

현재 및 이전 로그 읽기:

kubectl logs <파드-이름> -c <컨테이너-이름>
kubectl logs <파드-이름> -c <컨테이너-이름> --previous

최근 네임스페이스 이벤트 확인:

kubectl get events --sort-by=.metadata.creationTimestamp

리소스 사용량 비교:

kubectl top pod <파드-이름> --containers
kubectl top node

예를 들어, CrashLoopBackOff 상태이고 이전 로그가 메모리 부족 오류로 끝나며 메트릭이 제한에 가까운 메모리를 보여주는 파드는 메모리 제한 또는 애플리케이션 메모리 문제를 가리킵니다. FailedScheduling 이벤트와 낮은 노드 용량으로 Pending 상태에 갇힌 파드는 컨테이너 버그가 아닌 스케줄링 압력을 가리킵니다.

핵심 요점

단일 신호만으로 쿠버네티스를 디버깅하지 마십시오. 로그는 애플리케이션 동작을 설명하고, 이벤트는 컨트롤 플레인 결정을 설명하며, 메트릭은 리소스 압력을 설명합니다. 시간과 객체 이름별로 정렬하면 근본 원인을 증상과 훨씬 쉽게 분리할 수 있습니다.