<aside>
CloudWave · W04 · 3/5 · 예상 읽기 7분
</aside>
이미지를 다시 만들지 않고 환경별 설정을 바꾸려면 설정을 어디에 두어야 하는지가 질문이었다.
ConfigMap은 환경 이름이나 포트처럼 비밀이 아닌 설정을 저장한다. Secret은 비밀번호나 토큰처럼 접근을 제한해야 하는 값을 전달하는 객체다. 두 객체 모두 키와 값의 묶음으로 Pod에 환경 변수나 파일 형태로 주입할 수 있다. 이렇게 하면 이미지와 설정의 변경 주기를 분리할 수 있다.
Kubernetes의 객체는 명령어 목록이라기보다 원하는 상태를 표현하는 문서에 가깝다. 컨트롤러는 그 문서와 현재 상태의 차이를 관찰하고 필요한 조정을 반복한다. 이 관점으로 보면 생성 명령 자체보다 선택자, 템플릿, 복제본, 실패 시 대체 행동을 읽는 일이 중요해진다. 이름이 비슷한 객체라도 책임 범위가 다르므로, 무엇이 상태를 보관하고 무엇이 연결을 제공하는지 나누어 읽었다.
Secret의 data에 보이는 base64 값은 암호화가 아니라 인코딩이다. 따라서 누구나 디코딩할 수 있다는 전제로 접근 권한, 저장소 암호화, 감사 로그와 회전 정책을 함께 생각해야 한다. 공개 예제에서는 실제 자격 증명 대신 example-app, demo 같은 가상 값만 사용한다.
실무에서는 설정의 소유자와 변경 주기를 먼저 정한다. 애플리케이션이 시작할 때만 읽는 값인지, 실행 중 갱신 가능한 값인지도 확인한다. ConfigMap과 Secret을 환경 변수로 주입할 때는 키 이름과 누락 시 동작을 검증하고, 파일 마운트 방식에서는 권한과 갱신 타이밍을 점검한다.
작은 예제로 시작할 때도 리소스 이름은 example-app처럼 가상으로 두고, 실제 자격 증명이나 인프라 식별자는 문서에 넣지 않는다. 변경 전후의 상태를 비교하고, 실패했을 때 되돌릴 기준을 먼저 적어 두면 선언형 운영의 장점이 드러난다. 자동화는 사람의 판단을 없애는 것이 아니라 판단을 반복 가능한 절차로 바꾸는 일에 가깝다.
둘을 단순히 일반 값과 암호 값으로만 외우면 부족하다. Secret이라고 해서 자동으로 암호화되는 것도 아니고, ConfigMap에 민감한 값을 넣어도 안 된다. 이미지에 값을 baked-in 하는 방식은 재배포와 노출 범위를 키우므로 피하는 편이 안전하다.
또 하나의 오해는 Kubernetes가 모든 운영 결정을 대신한다는 생각이었다. Kubernetes는 객체와 컨트롤러의 공통 언어를 제공하지만, 데이터 보존, 권한, 비용, 백업, 장애 범위는 별도의 설계 대상이다. 그래서 실습 결과를 기록할 때도 성공 여부보다 어떤 조건에서 무엇이 관찰됐는지를 중심에 두려고 했다.
nn이 과정을 기록하며 확인한 기준은 세 가지였다. 먼저 객체의 이름과 라벨이 서로 의도한 대상을 가리키는지 확인한다. 다음으로 컨트롤러가 관찰하는 상태와 사용자가 보는 애플리케이션 상태를 나누어 본다. 마지막으로 변경을 적용하기 전에 실패했을 때 남는 자원과 되돌릴 방법을 생각한다. 이 기준은 로컬 클러스터에서 작은 예제를 읽을 때도, 관리형 클러스터의 배포 문서를 검토할 때도 같은 순서로 적용할 수 있다. 결국 중요한 것은 특정 명령을 외우는 일이 아니라, 선언한 내용이 어떤 객체를 통해 실행되고 어떤 신호로 정상 여부를 판단하는지 설명하는 능력이었다.nn## 오늘의 한 줄 정리
선언형 운영은 원하는 상태를 적는 데서 끝나지 않고, 그 상태를 계속 확인하고 안전하게 수렴시키는 설계다.