쿠버네티스 초기(init) 컨테이너

도람·2025년 11월 24일
post-thumbnail

쿠버네티스를 공부하다 보니까 initContainers 라는 게 갑자기 튀어나온다.
처음엔 “그냥 컨테이너 하나 더 넣는 건가?” 싶었는데,
언제 실행되는지, 왜 굳이 따로 분리해 놨는지 헷갈려서 한 번 정리해보기로 했다.


왜 초기화 컨테이너가 필요할까

보통 애플리케이션 파드에 이런 작업들이 필요해질 때가 있다.

  • 컨테이너가 뜨기 전에 설정 파일이나 HTML 파일을 미리 생성해야 할 때
  • 어플리케이션 시작 전에 외부에서 뭔가를 한 번 받아와야 할 때 (예: 파일 다운로드)
  • 본 컨테이너랑 다른 이미지 / 다른 툴셋을 써서 준비 작업을 하고 싶을 때

이걸 전부 앱 컨테이너의 entrypoint 스크립트에 때려 넣어도 되긴 하는데,
그러면 “준비 작업”과 “실제 애플리케이션 실행”이 섞여서 관리가 지저분해진다.

그래서 쿠버네티스는 초기화 컨테이너(Init Container) 라는 개념을 따로 두고 있다.

공식 문서에서는 이렇게 설명한다.

"Init 컨테이너는 앱 컨테이너가 시작되기 전에 실행되며,
각 Init 컨테이너는 완료될 때까지 실행된 뒤 다음 단계로 넘어간다."

즉,

“앱 컨테이너가 뜨기 전에 한 번만 돌려야 하는 준비 작업”을 담당하는 컨테이너이다.


초기화 컨테이너(Init Container)란?

정리하면 초기화 컨테이너는 이런 특징을 가진다.

  • 파드의 spec.initContainers 아래에 정의된다.
  • 앱 컨테이너(spec.containers)보다 먼저 실행된다.
  • 각 Init 컨테이너는 순서대로 하나씩 실행되고,
    이전 Init 컨테이너가 성공적으로 끝나야 다음 컨테이너로 넘어간다.
  • 전부 성공해야만 앱 컨테이너들이 시작된다.
  • 실패하면 파드는 Init:Error, Init:CrashLoopBackOff 같은 상태가 된다.
    Kubernetes

그래서 느낌적으로 보면,

“앱 컨테이너가 타기 전에 먼저 돌고 가는 프리런(pre-run) 컨테이너”

라고 보면 된다.


공식 YAML 예제로 보는 초기화 컨테이너 흐름

쿠버네티스 공식 문서에 있는 예제를 그대로 가져와보았다.

파일명: init-containers.yaml (혹은 pods/init-containers.yaml)

# 파일명: init-containers.yaml
apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - containerPort: 80
      volumeMounts:
        - name: workdir
          mountPath: /usr/share/nginx/html

  # 여기서부터 초기화 컨테이너
  initContainers:
    - name: install
      image: busybox:1.28
      command:
        - wget
        - "-O"
        - "/work-dir/index.html"
        - http://info.cern.ch
      volumeMounts:
        - name: workdir
          mountPath: /work-dir

  dnsPolicy: Default
  volumes:
    - name: workdir
      emptyDir: {}

이 YAML의 핵심을 구조로 보면 이렇게 된다.

  • containers.nginx

    • 실제 서비스용 nginx 컨테이너
    • /usr/share/nginx/html 에 workdir 볼륨을 마운트
  • initContainers.install

    • 먼저 실행되는 초기화 컨테이너
    • busybox 이미지 사용
    • wget 으로 HTML을 다운로드해서 /work-dir/index.html 에 저장
    • 같은 workdir 볼륨을 /work-dir 경로로 마운트
  • volumes.workdir

    • emptyDir 볼륨
    • 파드가 살아있는 동안만 유지되는 임시 디렉터리

결국 흐름은 이렇다.

  • 파드 생성
  • Init 컨테이너 install 실행
    http://info.cern.ch 페이지를 받아서 index.html 로 저장
    → 이 파일은 emptyDir 볼륨에 위치
  • Init 컨테이너가 성공적으로 종료
  • 그 다음에야 nginx 컨테이너가 시작됨
    → nginx는 같은 볼륨을 /usr/share/nginx/html 로 마운트
    → 결국 Init 컨테이너가 받아온 HTML을 바로 서빙하게 된다.

즉,

“초기화 컨테이너가 웹페이지 파일을 준비해 놓고,
그 다음에 nginx가 그 파일을 서비스하는 구조”

라고 보면 된다.



참고자료:
[쿠버네티스 공식 홈페이지 - Init Containers]
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

profile
정도를 걷는 엔지니어

0개의 댓글