
쿠버네티스를 공부하다 보니까 initContainers 라는 게 갑자기 튀어나온다.
처음엔 “그냥 컨테이너 하나 더 넣는 건가?” 싶었는데,
언제 실행되는지, 왜 굳이 따로 분리해 놨는지 헷갈려서 한 번 정리해보기로 했다.
보통 애플리케이션 파드에 이런 작업들이 필요해질 때가 있다.
이걸 전부 앱 컨테이너의 entrypoint 스크립트에 때려 넣어도 되긴 하는데,
그러면 “준비 작업”과 “실제 애플리케이션 실행”이 섞여서 관리가 지저분해진다.
그래서 쿠버네티스는 초기화 컨테이너(Init Container) 라는 개념을 따로 두고 있다.
공식 문서에서는 이렇게 설명한다.
"Init 컨테이너는 앱 컨테이너가 시작되기 전에 실행되며,
각 Init 컨테이너는 완료될 때까지 실행된 뒤 다음 단계로 넘어간다."
즉,
“앱 컨테이너가 뜨기 전에 한 번만 돌려야 하는 준비 작업”을 담당하는 컨테이너이다.
정리하면 초기화 컨테이너는 이런 특징을 가진다.
그래서 느낌적으로 보면,
“앱 컨테이너가 타기 전에 먼저 돌고 가는 프리런(pre-run) 컨테이너”
라고 보면 된다.
쿠버네티스 공식 문서에 있는 예제를 그대로 가져와보았다.
파일명: 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
initContainers.install
volumes.workdir
결국 흐름은 이렇다.
즉,
“초기화 컨테이너가 웹페이지 파일을 준비해 놓고,
그 다음에 nginx가 그 파일을 서비스하는 구조”
라고 보면 된다.
참고자료:
[쿠버네티스 공식 홈페이지 - Init Containers]
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/