Logging - 쿠버네티스 로깅 기초

쿠버네티스에서 “로깅”은 결국 한 문장으로 정리됩니다.

• 애플리케이션은 로그를 표준 출력(stdout) / 표준 에러(stderr)로 찍고
• 쿠버네티스는 그 스트림을 수집해서 kubectl logs로 조회할 수 있게 해준다

이 글에서는 강의 흐름 그대로 Docker에서의 로그 확인 → Kubernetes에서의 로그 확인 → 멀티 컨테이너 파드에서의 로그 조회까지 한 번에 정리합니다. 중간중간 실제로 많이 쓰는 옵션과 운영에서 부딪히는 제한도 함께 넣었습니다.

---

1) Docker에서 로그 보기: docker logs의 동작부터 이해하기

강의에서는 “이벤트 시뮬레이터” 컨테이너를 예로 들었습니다. 이 컨테이너는 웹서버처럼 동작하는 척하면서 무작위 이벤트 로그를 표준 출력으로 계속 찍는 프로그램입니다.

1-1. 포그라운드 실행 vs 백그라운드 실행

컨테이너를 포그라운드로 실행하면 터미널에 로그가 계속 보입니다.

docker run --name event-simulator some-registry/event-simulator

하지만 -d(detached) 옵션으로 백그라운드 실행하면 터미널에 로그가 바로 보이지 않습니다.

docker run -d --name event-simulator some-registry/event-simulator

이때 로그를 확인하는 명령이 docker logs입니다.

docker logs event-simulator
# 또는 컨테이너 ID로도 가능
docker logs <container-id>

1-2. 실시간 로그 추적: -f (follow)

실시간으로 계속 붙어서 보고 싶다면 -f를 씁니다.

docker logs -f event-simulator

이 “백그라운드 실행 + 로그는 별도 명령으로 조회” 패턴이 쿠버네티스에서도 거의 동일하게 이어집니다.

---

2) Kubernetes에서 로그 보기: kubectl logs (핵심은 동일)

Docker에서 하던 걸 Kubernetes로 옮기면 다음이 됩니다.

• Docker 컨테이너 → Kubernetes 파드(안에 컨테이너가 돌아감)
• docker logs → kubectl logs

2-1. 동일 이미지로 파드 생성

예시 파드 매니페스트(단일 컨테이너):

apiVersion: v1
kind: Pod
metadata:
  name: event-simulator
spec:
  containers:
    - name: event-simulator
      image: some-registry/event-simulator

적용:

kubectl apply -f pod.yaml

2-2. 로그 조회

파드가 실행되면 다음으로 로그를 봅니다.

kubectl logs event-simulator

실시간 추적은 Docker와 동일하게 -f입니다.

kubectl logs -f event-simulator

여기서 중요한 포인트:

• kubectl logs는 파드 안에서 실행 중인 컨테이너가 stdout/stderr로 내보낸 로그를 보여줍니다.
• 파일에 직접 쓴 로그(/var/log/app.log 같은)는 기본 kubectl logs 대상이 아닙니다. (이건 고급 로깅에서 다룹니다)

---

3) 멀티 컨테이너 파드에서 로그는 어떻게 보나?

강의에서 강조한 핵심이 여기입니다.

“Kubernetes 파드에는 여러 컨테이너가 있을 수 있다.
여러 컨테이너면 어떤 컨테이너 로그를 볼지 지정해야 한다.”

3-1. 멀티 컨테이너 파드 예시

예를 들어 event-simulator 외에 image-processor 컨테이너를 추가했다고 해봅시다.

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
    - name: event-simulator
      image: some-registry/event-simulator
    - name: image-processor
      image: some-registry/image-processor

3-2. 컨테이너를 지정하지 않으면?

파드에 컨테이너가 2개 이상이면, 다음을 실행했을 때:

kubectl logs multi-container-pod

대부분의 경우 “어떤 컨테이너를 볼지 지정해라” 또는 “기본 컨테이너를 선택했다” 같은 메시지가 나오거나, 원하는 컨테이너가 아닌 로그가 나올 수 있습니다.

3-3. -c로 컨테이너 지정

정답은 컨테이너 이름을 지정하는 것입니다.

kubectl logs multi-container-pod -c event-simulator
kubectl logs multi-container-pod -c image-processor

실시간 추적도 동일합니다.

kubectl logs -f multi-container-pod -c event-simulator

---

4) 실전에서 바로 쓰는 kubectl logs 옵션들

강의 범위를 크게 벗어나지 않으면서도, 현장에서 가장 많이 쓰는 옵션 몇 개는 같이 알아두는 게 좋습니다.

4-1. 이전 컨테이너 로그 보기: --previous

컨테이너가 재시작되면 “직전 실행”의 로그가 필요할 때가 많습니다.

kubectl logs <pod> -c <container> --previous

예: CrashLoopBackOff에서 “왜 죽었는지” 확인할 때 거의 필수입니다.

4-2. 최근 N초/시간만 보기: --since, --since-time

kubectl logs <pod> --since=10m
kubectl logs <pod> --since=1h

4-3. 라인 수 제한: --tail

kubectl logs <pod> --tail=100
kubectl logs -f <pod> --tail=200

4-4. 라벨로 여러 파드 로그 한 번에: -l

디플로이먼트처럼 동일 앱 파드가 여러 개면 라벨 셀렉터로 모을 수 있습니다.

kubectl logs -l app=myapp --tail=100

(클러스터/버전에 따라 동작이나 출력 순서가 기대와 다를 수 있어, 운영에서는 보통 로그 수집 시스템과 함께 씁니다.)

---

5) “쿠버네티스 로깅의 기본”에서 꼭 기억할 3가지

(1) 애플리케이션 로그는 stdout/stderr로 내보내는 게 표준

• 컨테이너 내부 파일에만 쓰면,
  • kubectl logs로 보기 어렵고
  • 중앙 수집도 까다로워집니다.
• 따라서 “파일 로그”가 필요해도 표준 출력으로도 내보내는 구조가 보편적입니다.

(2) kubectl logs는 “현재/최근” 조회에 강하지만 “보관/분석”은 별개

• 파드가 사라지면 로그도 같이 사라지거나 접근이 어려워집니다.
• 노드 장애/재스케줄링/로그 로테이션 등으로 과거 로그가 유실될 수 있습니다.

(3) 운영에서는 중앙 로그 수집이 거의 필수

강의가 다음 시간에 다룬다고 예고한 부분이 바로 여기입니다.

• 노드/파드 전반에서 로그를 모아서
• 검색/필터링/대시보드/알람까지 하려면
• 보통 다음 계열을 붙입니다:
  • EFK/ELK(Elasticsearch + Fluentd/Fluent Bit + Kibana)
  • Loki + Promtail + Grafana
  • 상용: Datadog, Dynatrace 등

---

6) 정리

• Docker:
  • 백그라운드(-d)로 돌리면 docker logs로 본다
  • 실시간은 docker logs -f
• Kubernetes:
  • 파드 로그는 kubectl logs <pod>
  • 실시간은 kubectl logs -f <pod>
  • 멀티 컨테이너면 -c <container>로 반드시 지정

이 정도가 “개발자가 쿠버네티스를 시작할 때 알아야 하는 최소 로깅”의 핵심입니다.