같은 tag가 레지스트리에서 새 image digest를 가리켜도 이미 실행 중인 컨테이너의 image가 자동으로 바뀌지는 않습니다. 새 Pod가 어떤 digest를 가져오는지는 imagePullPolicy와 노드에 있는 이미지에 따라 달라질 수 있습니다.
실제 변경이 적용됐는지 확인하려면 Deployment의 원하는 image reference뿐 아니라 rollout 결과, Pod별 imageID와 플랫폼을 비교해야 합니다. tag 문자열 하나만으로 배포된 코드 버전을 증명하지 않습니다.
tag는 별칭이고 digest는 이미지 내용을 식별합니다
Docker image pull 문서는 이미지 다운로드 뒤 digest를 보여 주고, tag 대신 digest로 지정해 한 시점의 이미지를 고정할 수 있다고 설명합니다. Kubernetes 문서는 tag가 가리키는 코드가 레지스트리에서 바뀌면 같은 tag를 사용하는 Pod 사이에 구·신 이미지가 섞일 수 있다고 안내합니다. 따라서 stable이나 prod 같은 tag는 배포 버전을 고정하는 식별자가 아닙니다.
Kubernetes에서 IfNotPresent는 해당 노드에 image가 있으면 다시 pull하지 않습니다. Always는 컨테이너를 시작할 때 registry에서 tag 또는 이름을 digest로 해석하도록 runtime에 요청하지만, 이미 실행 중인 컨테이너를 새 image로 교체하지는 않습니다. 기존 Deployment가 tag 문자열을 그대로 유지하면 tag의 원격 값 변경만으로 Pod template 변경이 생기지 않아 rollout이 시작되지 않을 수도 있습니다.
레지스트리 tag와 실행 Pod를 나눠 비교합니다
| 관측 | 창작 값 | 의미 |
|---|---|---|
| 원하는 Deployment image | registry.example/edu/app:stable | 요청 spec은 mutable tag만 지정 |
| 레지스트리 tag 현재값 | stable → digest sha256:EDU-B | 새로 resolve할 때 사용할 수 있는 이미지 reference |
| 기존 Pod A | imageID sha256:EDU-A, 상태 Running | 이미 실행 중인 컨테이너는 이전 image로 남아 있음 |
| 새 Pod B | 노드에 EDU-A cache 있음, policy IfNotPresent, imageID EDU-A | 새 Pod라도 로컬 cache 때문에 이전 내용으로 시작할 수 있음 |
| 새 Pod C | 새 노드, Always, registry resolve 결과 EDU-B | 새 실행에서 새 tag 값이 선택될 수 있음. 기존 Pod가 자동 교체된 것은 아님 |
| 고정 reference | registry.example/edu/app@sha256:EDU-B | 요청된 image 내용을 특정 digest로 고정 |
이 예시처럼 tag가 움직이면 Pod A와 Pod C가 서로 다른 image를 실행할 수 있습니다. 다중 아키텍처 이미지에서는 OCI index digest가 플랫폼별 manifest digest로 이어질 수 있으므로, 레지스트리 상위 digest와 runtime imageID를 반드시 문자열 그대로 일치시켜야 하는 것은 아닙니다. CPU 플랫폼, 실제 Pod spec, registry manifest 관계를 함께 확인합니다.
원하는 상태와 실제 실행 상태를 비교합니다
- 승인된 배포 정의에서 image repository·tag 또는 digest와 imagePullPolicy를 확인합니다.
- 레지스트리의 해당 tag가 현재 가리키는 digest와 변경 시각·승인 정보를 확인합니다.
- Kubernetes 문서에 따라 object를 처음 만들 때 설정된 imagePullPolicy가 나중에 tag 변경만으로 바뀌지 않을 수 있음을 확인합니다.
- rollout 상태와 새 ReplicaSet·Pod가 실제 만들어졌는지 확인합니다. Registry tag 변경만 있었다면 기존 Pod가 그대로일 수 있습니다.
- 각 Pod의 실행 상태와 imageID, node platform을 확인해 혼재된 버전이 있는지 대조합니다.
- 새 배포가 승인된 digest를 실행하는지 확인한 뒤 취약 수정 적용 여부와 보안 시험 결과를 별도로 기록합니다.
digest 고정은 자동 최신화와 맞바꾸는 선택입니다
digest를 명시하면 같은 내용을 반복해서 실행할 수 있지만, 그 digest가 이후 보안 수정으로 자동 이동하지는 않습니다. 새 수정 버전이 나오면 승인된 digest를 갱신하고 rollout 결과를 다시 확인해야 합니다. 반대로 mutable tag를 계속 쓰면 업데이트를 당겨올 수 있어도 어느 Pod가 어떤 내용을 실행하는지 정확히 추적하기 더 어려울 수 있습니다. 실제 운영 방식은 공급망 정책과 롤백 전략에 맞춰 결정합니다.
복습: registry tag만 바뀌면 실행 Pod도 바뀌나요?
문제: Deployment의 image tag는 변하지 않았지만 registry에서 그 tag가 새 digest로 이동했습니다. 기존 Pod의 imageID는 바뀌었을까요?
정답: 기존 Pod의 imageID가 자동 변경되지는 않습니다. 새로운 Pod가 생겼는지, pull policy와 노드 cache가 무엇인지, 각 실행 Pod의 imageID가 목표 버전과 맞는지 확인합니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
가상 registry에서 stable이 EDU-A에서 EDU-B로 바뀌었습니다. 기존 Pod A는 EDU-A이고, 새 Pod B는 IfNotPresent로 EDU-A를 시작했습니다. 배포가 완료됐다고 결론 내리기 전 확인할 것을 말하세요.
정답과 해설 확인
Deployment/rollout에서 새 Pod가 모두 생성됐는지와 각 Pod의 imageID·platform을 확인하고, 목표 digest EDU-B를 실제 실행하는지 대조합니다. tag 변경만으로 기존 Pod나 cache된 이미지가 교체됐다고 보지 않습니다.tag는 재지정될 수 있고 IfNotPresent는 node에 image가 있으면 다시 받지 않습니다. 실행 중인 컨테이너와 레지스트리 tag는 별도로 관측해야 합니다.