Day 3 — ConfigMap / 이미지 불변성

한 줄 요약

이미지는 그대로 두고, ConfigMap만 바꿔서 서비스 동작을 변경했다.
→ 운영에서 왜 “설정 외부화”가 필요한지 체감.

---

🎯 목표

• 이미지 불변성 이해
• ConfigMap을 이용해 이미지 재빌드 없이 설정 변경

---

✅ 실습 내용

1. ConfigMap 생성 (nginx 설정 파일)

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config
data:
  default.conf: |
    server {
      listen 80;

      location / {
        return 200 "hello from configmap v1\n";
      }
    }

---

2. Deployment에 ConfigMap 적용

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
        - name: nginx
          image: nginx:1.25-alpine
          ports:
            - containerPort: 80
          volumeMounts:
            - name: nginx-config
              mountPath: /etc/nginx/conf.d/default.conf
              subPath: default.conf
      volumes:
        - name: nginx-config
          configMap:
            name: nginx-config

---

3. 동작 확인

kubectl port-forward deploy/nginx-demo 8080:80
curl localhost:8080

출력:

hello from configmap v1

---

4. ConfigMap 수정 후 재배포

return 200 "hello from configmap v2\n";

kubectl apply -f configmap.yaml
kubectl rollout restart deploy/nginx-demo

다시 확인:

hello from configmap v2

---

📌 결과

• 이미지 재빌드 ❌
• ConfigMap 수정 ✔
• Deployment 재시작 ✔
• 서비스 동작 변경 ✔

---

🧠 정리 포인트

volumes vs volumeMounts

• volumes : Pod가 어떤 ConfigMap을 쓸지 선언
• volumeMounts : 컨테이너에 어디에 적용할지 선언

subPath의 의미

• subPath 사용
  → 파일 고정, ConfigMap 변경 시 자동 갱신 ❌, 재시작 필요
• subPath 미사용
  → 파일은 바뀌지만 애플리케이션 동작은 그대로

중요한 개념

ConfigMap은 설정을 “전달”할 뿐,
설정을 “적용”하는 책임은 애플리케이션에 있다.

---

🧩 배운 점 (운영 관점)

• “ConfigMap 자동 반영”은 파일 기준 이야기다
• 실제 서비스 동작 변경을 원하면 명시적 재시작이 필요
• env 주입보다 파일(ConfigMap volume) 방식이
  가시성·변경·롤백 측면에서 안전
• 운영은 자동보다 예측 가능함이 더 중요하다