쿠버네티스 사이드카 패턴 — 멀티컨테이너 파드 실전

kubectl get pod를 쳤을 때 READY 칼럼이 1/1이 아니라 2/2, 3/3으로 보인다면 그 파드 안에는 컨테이너가 여러 개 들어 있다는 뜻입니다. 쿠버네티스에서 파드는 배포의 최소 단위지 컨테이너의 최소 단위가 아닙니다. 같은 네트워크 네임스페이스와 볼륨을 공유해야 하는 보조 프로세스를 메인 앱 옆에 붙이는 것 — 이게 사이드카 패턴입니다.

왜 같은 파드에 넣나

별도 파드로 띄우면 통신이 네트워크를 타고, 라이프사이클도 따로 놉니다. 같은 파드에 넣으면 두 컨테이너가 localhost로 통신하고 emptyDir 볼륨을 공유하며, 함께 스케줄링·함께 종료됩니다. 로그 수집기, 프록시, 설정 리로더처럼 "메인 앱에 딱 붙어 있어야 의미가 있는" 보조 프로세스가 대상입니다.

세 가지 패턴

사이드카 구성 예시

emptyDir로 로그 디렉터리를 공유하고, 앱이 쓴 로그를 사이드카가 읽어 표준출력으로 흘립니다.

apiVersion: v1
kind: Pod
metadata:
  name: app-with-logger
spec:
  volumes:
    - name: logs
      emptyDir: {}
  containers:
    - name: app
      image: myapp:1.0
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
    - name: log-shipper
      image: busybox:1.36
      command: ["sh", "-c", "tail -F /var/log/app/out.log"]
      volumeMounts:
        - name: logs
          mountPath: /var/log/app

함정 — 기동·종료 순서

일반 컨테이너는 기동 순서가 보장되지 않습니다. 사이드카(예: 프록시)가 떠야 메인 앱이 동작하는데, 메인이 먼저 떠서 연결 실패로 죽는 경우가 흔합니다. 쿠버네티스 1.28+에서는 사이드카를 initContainers에 restartPolicy: Always로 선언해 "메인보다 먼저 뜨고 나중에 죽는" 순서를 보장합니다.

spec:
  initContainers:
    - name: proxy
      image: proxy:1.0
      restartPolicy: Always   # 이 줄이 사이드카로 만든다

또 하나, Job에서 사이드카가 안 죽으면 Job이 영영 Completed가 안 됩니다. 위 네이티브 사이드카 방식이 이 문제도 해결합니다.

점검 체크리스트

kubectl get pod app-with-logger          # READY가 2/2인지
kubectl logs app-with-logger -c app      # -c 로 컨테이너 지정
kubectl logs app-with-logger -c log-shipper
kubectl describe pod app-with-logger     # 컨테이너별 State 확인

-c 옵션을 빼먹으면 멀티컨테이너 파드에서 logs가 에러를 내니 항상 컨테이너 이름을 붙입니다.

사이드카로 로그·프록시를 직접 붙여 보고 종료 순서를 관찰하는 실습은 쿠버네티스 트랙에서 회원가입 없이 무료로 해볼 수 있습니다.