Ephemeral Containers — 셸도 없는 이미지에 디버깅 도구를 몰래 끼워 넣는다
Kubernetes Ephemeral Containers 및 Pod Topology Spread Constraints 공식 문서 종합 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/workloads/pods/ephemeral-containers, concepts/scheduling-eviction/topology-spread-constraints) Kubernetes 공식문서 Ephemeral Containers
이 모듈을 다 읽으면
- kubectl exec이 왜 distroless 이미지에서 무력한지, Ephemeral Container가 이를 어떻게 우회하는지 설명할 수 있다
- Ephemeral Container가 일반 컨테이너와 달리 재시작이나 자체 리소스 보장이 없다는 제약을 설명할 수 있다
k8s-learn-13에서 다룬 CrashLoopBackOff 진단(로그·Events 확인)을 전제로, 그 로그만으로 원인이 안 잡힐 때 실행 중인 Pod 안으로 직접 들어가 조사하는 Ephemeral Container를 정리한다.
왜 필요한가 — kubectl exec이 안 통하는 이미지
kubectl exec은 컨테이너 이미지 '안에' 실행할 바이너리(셸 등)가 있어야 동작한다. 그런데 distroless 이미지(애플리케이션과 그 의존성만 담고 셸·디버깅 도구를 아예 빼버린 이미지)에서는 exec으로 들어갈 셸 자체가 없다. Ephemeral Container는 이 문제를 우회한다 — 이미 실행 중인 Pod에 디버깅 도구가 담긴 임시 컨테이너를 새로 주입하고, 그 Pod의 네트워크·프로세스 네임스페이스를 공유시켜, 애플리케이션 컨테이너를 재시작하거나 수정하지 않고도 그 안을 들여다볼 수 있게 한다.
핵심 포인트
- kubectl exec은 이미지 안에 셸 등 실행할 바이너리가 있어야 동작 — distroless 이미지엔 그게 없어 무력
- Ephemeral Container: 실행 중인 Pod에 디버깅 도구가 담긴 임시 컨테이너를 주입, 네트워크·프로세스 네임스페이스 공유 — 애플리케이션 재시작·수정 없이 내부 조사 가능
kubectl debug — 실무에서 쓰는 명령과 제약
실무에서는 kubectl debug 명령으로 Ephemeral Container를 붙인다 — 멀티 컨테이너 Pod에서는 --target 플래그로 어느 컨테이너의 프로세스 네임스페이스를 공유할지 지정해, 그 컨테이너의 프로세스·파일시스템을 들여다볼 수 있다. 프로덕션 환경에서도 실행 중인 Pod에 대한 방해를 최소화한다는 게 큰 장점이다. 다만 제약도 있다 — Ephemeral Container는 자체 리소스 보장이 없고(Pod에 이미 할당된 리소스만 씀), 재시작이 안 되며, 포트를 노출할 수도 없다.
핵심 포인트
- kubectl debug --target=<컨테이너명>으로 멀티 컨테이너 Pod에서 특정 컨테이너의 네임스페이스 공유 지정 — 실행 중인 Pod 방해 최소화
- 제약: 자체 리소스 보장 없음(Pod에 이미 할당된 리소스 사용), 재시작 불가, 포트 노출 불가