ConfigMap 을 고치면 오브젝트는 즉시 바뀌지만 파드는 그대로다. 반영 방식은 그 ConfigMap 을 파드가 어떻게 쓰고 있느냐에 따라 다르다.
env:
- name: APP_MODE
valueFrom:
configMapKeyRef:
name: my-config
key: mode
값은 파드가 만들어질 때 한 번 읽혀 고정된다. ConfigMap 을 고쳐도 절대 반영되지 않으므로 파드를 다시 만들어야 한다.
volumes:
- name: config
configMap:
name: my-config
kubelet 이 주기적으로 갱신하므로 파일 내용은 시간이 지나면 바뀐다. 갱신 주기는 kubelet 의 동기화 주기와 캐시 정책에 달려 있어 즉시는 아니다. 파일이 바뀌어도 애플리케이션이 다시 읽지 않으면 의미가 없으므로, 설정 다시 읽기를 지원하는 제품인지 먼저 확인한다.
subPath 로 마운트한 파일은 갱신되지 않는다. 설정 파일 하나만 특정 경로에 올릴 때 흔히 쓰는 방식인데, 이 경우 파드를 다시 만들어야 바뀐다.
가장 확실하다. 롤링 업데이트로 순차 교체되므로 레플리카가 여럿이면 무중단으로 넘어간다.
kubectl rollout restart deployment my-app
kubectl rollout status deployment my-app
파드 템플릿의 애노테이션에 설정 내용의 해시를 넣어 두면, 설정이 바뀔 때 템플릿이 바뀌므로 롤링 업데이트가 자동으로 일어난다. Helm 차트에서 흔히 쓰는 방식이고 GitOps 와 궁합이 좋다.
spec:
template:
metadata:
annotations:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
ConfigMap 변경을 감지해 대상 워크로드를 자동으로 재시작해 주는 오퍼레이터를 쓰는 방법도 있다. 애노테이션 하나로 동작해 편하지만 구성 요소가 하나 늘고, 의도치 않은 시점에 재시작이 일어날 수 있다.
불변 ConfigMap(immutable: true)은 수정할 수 없고 새 이름으로 만들어 교체한다. API 서버 부하가 줄고 실수로 고치는 일을 막는다. 설정을 버전이 붙은 이름(my-config-v3)으로 만들고 참조를 바꾸는 방식도 같은 효과를 낸다 — 되돌리기도 쉽다.
Secret 도 동작이 같다. 볼륨은 갱신되고 subPath 와 환경 변수는 갱신되지 않는다.
secretKeyRef 사용.