ConfigMap/Secret 주입 방식 — env는 재시작해야, 볼륨은 알아서 갱신된다
Kubernetes CrashLoopBackOff 진단 및 ConfigMap/Secret 주입 방식 공식 문서·운영 블로그 종합 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/configuration/secret), Komodor/GKE 운영 문서 Kubernetes 공식문서 Secrets
이 모듈을 다 읽으면
- 환경변수 주입과 볼륨 마운트 주입이 설정 변경 시 왜 다르게 반응하는지 설명할 수 있다
- kubelet의 configMapAndSecretChangeDetectionStrategy 세 전략을 구분할 수 있다
k8s-learn-01에서 다룬 kubelet의 역할(노드에 배정된 Pod를 감시하고 유지)을 전제로, ConfigMap·Secret을 컨테이너에 주입하는 두 방식이 설정 변경에 어떻게 다르게 반응하는지를 정리한다.
환경변수(env) — 시작할 때 한 번 고정되고 다시는 안 바뀐다
ConfigMap·Secret을 환경변수로 주입하면, 그 값은 컨테이너 프로세스가 시작하는 시점에 고정된다. 프로세스의 환경변수는 그 이후로는 절대 새로고침되지 않는다 — 프로세스가 한 번 시작되면 그 환경은 그 프로세스의 생애주기 내내 고정되며, Kubernetes가 실행 중인 컨테이너 안에 들어가 PID 1의 환경변수를 바꿔치기할 방법은 없다. 즉 원본 ConfigMap·Secret이 바뀌어도, 환경변수로 주입받은 컨테이너는 재시작하기 전까지는 옛 값을 그대로 쓴다.
핵심 포인트
- 환경변수 주입: 컨테이너 시작 시점에 값이 고정 — 그 이후 원본이 바뀌어도 프로세스 환경은 절대 자동 갱신 안 됨(재시작해야 새 값 반영)
- Kubernetes는 실행 중인 컨테이너의 PID 1 환경변수를 외부에서 바꿀 방법이 없음(OS 프로세스 모델의 근본적 제약)
볼륨 마운트 — kubelet이 주기적으로 확인해 알아서 갱신한다
ConfigMap·Secret을 볼륨으로 마운트하면 얘기가 다르다 — kubelet이 주기적으로(sync 주기마다) 변경 여부를 확인해 마운트된 파일을 다시 투영(re-project)해준다. 이 방식의 갱신은 보통 30초에서 90초 사이에 반영된다. 즉 애플리케이션이 파일 변경을 감시하는 로직(파일 워처)을 갖고 있다면, 재시작 없이도 설정 변경을 실시간에 가깝게 반영할 수 있다는 게 환경변수 방식과의 결정적 차이다.
핵심 포인트
- 볼륨 마운트: kubelet이 주기적으로 변경을 확인해 마운트된 파일을 자동 재투영 — 보통 30~90초 안에 반영
- 애플리케이션이 파일 변경 감시(워처) 로직을 가지면 재시작 없이 설정 변경을 실시간에 가깝게 반영 가능 — 환경변수 방식과의 결정적 차이
kubelet의 변경 감지 전략 — Watch/Cache/Get
kubelet 설정의 configMapAndSecretChangeDetectionStrategy 필드가 이 갱신을 어떤 방식으로 감지할지 결정한다. Watch(기본값)는 kubelet이 API 서버에 대한 감시(watch)를 걸어 변경을 실시간에 가깝게 통지받는 방식이고, Cache는 TTL 기반의 로컬 캐시에만 의존해 그 TTL이 지나야 갱신을 인지하는 방식이며, Get은 매 sync 루프마다 API 서버에서 최신 값을 직접 가져오는 방식이다. Secret이 바뀐 시점부터 실제로 Pod에 새 값이 투영되기까지의 전체 지연은 이 전략에 따른 지연에 kubelet sync 주기가 더해진 만큼이 된다.
핵심 포인트
- Watch(기본): API 서버 감시로 실시간에 가깝게 통지 / Cache: TTL 기반 로컬 캐시, TTL 만료 전까진 갱신 인지 못함 / Get: 매 sync 루프마다 API 서버에서 직접 조회
- Secret 변경→Pod 반영까지의 전체 지연 = 전략별 감지 지연 + kubelet sync 주기