부제: 같은 이미지를 dev·prod에서 그대로 쓰되, 바뀌는 값만 밖에서 주입한다
시리즈 A의 마지막 편이다. A1에서
이미지는 "얼려둔 불변 스냅샷"이라고 했다. 그런데 실무에서는 같은 앱을 개발·
스테이징·운영에서 조금씩 다른 설정으로 돌린다. DB 주소가 다르고, 로그 레벨이
다르고, 비밀번호가 다르다. 그렇다고 환경마다 이미지를 새로 빌드하면, "한 번
빌드해 어디서든 똑같이"라는 컨테이너의 이점이 무너진다.
그래서 쿠버네티스는 코드(이미지)와 값(설정)을 떼어놓는다. 이미지는 그대로
두고, 바뀌는 값만 밖에서 주입한다. 그 주입용 그릇이 ConfigMap과 Secret이다.
한 줄 정의부터
| 용어 | 한 줄 정의 |
|---|---|
| ConfigMap | 코드에서 설정값을 떼어내 밖에 보관하는(비밀 아닌) 설정 저장소 |
| Secret | 비밀번호·토큰 등 민감값을 (base64로) 분리 보관하는 저장소 |
| envFrom / 볼륨 | 위 둘을 Pod에 환경변수나 파일로 주입하는 방법 |
| requests/limits | Pod의 자원 요청·상한 → 실제로는 cgroup 값으로 내려감(A1과 수미상관) |

ConfigMap과 Secret — 무엇을, 어떻게 담나
둘은 역할이 같고 대상이 다르다. 둘 다 "코드 밖에 값을 두고 Pod에 주입"하는
그릇인데, ConfigMap은 비밀 아닌 설정(로그 레벨, 페이지 크기, 기능 플래그)을,
Secret은 민감값(비밀번호, API 토큰, 인증서)을 담는다.
주입 방법도 동일하다 — 환경변수(envFrom)로 넣거나 볼륨으로 파일처럼
마운트한다. 그래서 애플리케이션 코드는 "환경변수/파일에서 값을 읽는다"는
평범한 방식 그대로 두고, 그 값이 어디서 오는지는 신경 쓰지 않아도 된다.
실제 콘솔 — 주입, base64 함정, 그리고 cgroup
로컬 클러스터에서 직접 만들어 주입해 봤다.

- ① 생성 —
create configmap으로APP_MODE=production·PAGE_SIZE=20을,
create secret으로DB_PASSWORD를 코드 밖에 만든다. - ② Secret ≠ 암호화 (중요한 함정) — Secret에 넣은 값을 조회하면
czNjcjN0IXB3같은 암호문처럼 보이는 문자열이 나온다. 하지만 이건 암호화가
아니라 base64 인코딩일 뿐이라,base64 -d한 줄이면 원문s3cr3t!pw가
그대로 나온다. Secret에 넣었다는 사실만으로 안전해지지 않는다. 그건
"코드·ConfigMap과 분리했다"는 의미이지, 진짜 보호는 etcd 저장소 암호화·RBAC
접근 제한·외부 시크릿 매니저(Vault 등)로 따로 채워야 한다. - ③ Pod 주입 + cgroup 수미상관 — Pod에
envFrom으로 두 그릇을 붙이면
컨테이너 안에서APP_MODE·PAGE_SIZE·DB_PASSWORD가 환경변수로 잡힌다.
그리고 같은 Pod에 준resources.limits.memory: 128Mi는 컨테이너의
/sys/fs/cgroup/memory.max에서134217728(=128Mi) 로 확인된다 —
A1에서 "cgroup은 자원
제한"이라고 말한 그 장치가, 여기서 눈에 보이는 숫자로 닫힌다.
정리 — 그리고 시리즈 A를 닫으며
- ConfigMap = 설정을 코드 밖으로, Secret = 민감값을 분리 — 같은 이미지에
환경별 값만 주입해 dev·prod를 하나의 코드로 굴린다. - Secret은 base64일 뿐 암호화가 아니다. 분리의 의미이지 그 자체로 안전한 게
아니다. limits가 실제 cgroup 값으로 내려가며, 컨테이너를 "커널이 제한한
프로세스"로 봤던 A1과 수미상관으로 닫힌다.
이렇게 시리즈 A(정의와 목적) 를 마친다. 다섯 편을 관통한 방법은 하나였다 —
개념마다 한 줄 정의를 먼저 못박고, 실제 콘솔로 확인하고, 딱 쓰기에 어긋나지
않을 만큼만 정리하고 넘어가기. 컨테이너(A1) → 클러스터 아키텍처(A2) →
워크로드 컨트롤러(A3) → 서비스·노출(A4) → 설정·비밀(A5)까지, "이게 뭘 하는가"와
"큰 그림 어디에 서 있는가"는 이제 손에 잡혔을 것이다.
다음 갈래는 여기서 계속 미뤄 둔 네트워킹(B) — OSI 계층에서 시작해
kube-proxy가 iptables로 트래픽을 꽂는 실제 기계, 그리고 cgroup으로 OS를 나누는
격리의 안쪽 — 으로 이어진다.
참고
- Kubernetes Docs — ConfigMaps, Secrets, Managing Resources for Containers
- 콘솔 캡처:
docker-desktop로컬 클러스터에서 ConfigMap·Secret 주입 및memory.max실측
답글 남기기