Kubernetes ConfigMap을 이용해서 데이터를 마운트

1. ConfigMap이란?

• ConfigMap은 쿠버네티스에서 애플리케이션이 사용하는 설정 파일이나 환경 변수를 외부로 분리해서 관리할 수 있게 해주는 리소스.
• 애플리케이션 이미지를 수정하지 않고도 설정만 바꿔서 동작을 변경.

---

2. ConfigMap 만들기

예를 들어, 아래처럼 간단한 설정파일이 있다고 해볼게요.

my-config.txt

key1=value1
key2=value2

이 파일을 ConfigMap으로 만들려면:

kubectl create configmap my-config --from-file=my-config.txt

또는 직접 yaml로 정의할 수도 있어요:

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  my-config.txt: |
    key1=value1
    key2=value2

적용은 이렇게:

kubectl apply -f configmap.yaml

---

3. ConfigMap을 Pod에 마운트하기 (Volume 형태)

Pod에 파일처럼 마운트하려면 volumes와 volumeMounts를 사용해요.

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: configmap-pod
spec:
  containers:
    - name: app
      image: busybox
      command: [ "sleep", "3600" ]
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: my-config

여기서 중요한 건:

• volumes 아래에 configMap 타입을 지정하고,
• volumeMounts로 /etc/config 디렉터리에 마운트.

결과:
Pod 안에서 /etc/config/my-config.txt 파일이 생기고, 그 안에 key1=value1 같은 내용.

---

4. ConfigMap을 환경 변수로 주입하기

파일이 아니라 환경 변수로

apiVersion: v1
kind: Pod
metadata:
  name: configmap-env-pod
spec:
  containers:
    - name: app
      image: busybox
      command: [ "sh", "-c", "env; sleep 3600" ]
      envFrom:
        - configMapRef:
            name: my-config

• envFrom을 이용하면 ConfigMap의 key들이 전부 환경변수.

---

요약

방법	목적	특징
volumeMounts	파일처럼 마운트	/etc/config/ 안에 파일로 사용
envFrom	환경 변수로 주입	container 안에 직접 환경변수 등록

 

---

추가 

• ConfigMap이 수정되더라도 Pod는 자동으로 반영되지 않음. Pod를 다시 시작하거나 롤링 업데이트 해야 반영해야됨
• 크기가 1MB를 초과하는 ConfigMap은 생성할 수 없어요.

---

"ConfigMap 자동 업데이트 반영"

---

1. 기본적으로 Pod는 ConfigMap 업데이트를 자동 반영하지 않음

• ConfigMap을 수정해도 이미 떠있는 Pod에는 변화가 없음.
• 왜냐하면 쿠버네티스는 "immutable(불변성)"을 기본 철학으로 삼아서, Pod이 생성될 때의 설정을 계속 유지하기 때문이에요.
• 그래서 보통은 Pod 재시작(롤링 업데이트)이 필요.

---

2. 방법 1: checksum 주입 → 변경 감지 & 자동 롤링 업데이트

가장 깔끔하고 많이 쓰는 방법은
ConfigMap의 해시(hash)를 Pod 스펙 안에 주입

예시:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: configmap-app
  template:
    metadata:
      labels:
        app: configmap-app
      annotations:
        configmap-checksum: "{{ checksum }}"
    spec:
      containers:
        - name: app
          image: busybox
          command: [ "sleep", "3600" ]
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: my-config

여기서 중요한 건 annotations에 configmap-checksum 같은 값을 넣는 것.

• checksum은 ConfigMap의 내용을 sha256 같은 걸로 해시(hash)한 값이에요.
• ConfigMap이 바뀌면 checksum도 바뀌고,
• Deployment의 template이 변경되었기 때문에 쿠버네티스가 자동으로 새로운 Pod를 생성해줘요.

=> 요약하면:
ConfigMap 수정 → 체크섬 변경 → 쿠버네티스가 "오, 스펙이 변경 인지" → 자동 롤링 업데이트

---

Q. checksum은 어떻게 생성하나요?

• CI/CD 툴(예: GitLab CI, Jenkins)이나
• kustomize를 쓸 때 configMapGenerator에서 자동으로 만들어 줄 수 있어요.

간단하게 스크립트로 하려면:

kubectl get configmap my-config -o yaml | sha256sum

이렇게 해시 값을 뽑아내고, Deployment 템플릿에 주입하면 됩니다.

---

3. 방법 2: Projected Volume + 자동 리로드하는 앱 사용

Pod 안에서 ConfigMap 파일 변화를 바로 감지하고 싶은 경우는?

• 쿠버네티스 1.18부터 ConfigMap이 업데이트되면 Projected Volume을 통해 실시간 갱신할 수 있어요.
• 단, 앱(컨테이너)이 파일 변화를 감지하고 리로드해야 해요.

volumeMount 예시

volumes:
  - name: config-volume
    projected:
      sources:
        - configMap:
            name: my-config

• projected 타입으로 잡으면 5초 주기로 쿠버네티스가 파일 변화를 체크합니다.
• 다만 이건 쿠버네티스 내부에서 파일만 바꿔주는 거지, 앱이 자동으로 reload 하진 않아요.

주의: 일반적으로 nginx, envoy 같은 일부 서버는 config 파일 변경 감지 후 자동 reload가 가능하지만, 대부분의 앱(Spring Boot 같은)은 별도 코드나 sidecar가 필요해요.

---

4. 방법 3: ArgoCD + 자동 sync

만약 ArgoCD를 쓴다면?

• ArgoCD가 Git의 ConfigMap 변화를 감지하고,
• Deployment를 자동으로 다시 배포(sync)해줄 수 있어요.

이 경우는 애초에 "Git 변경"을 트리거로 삼는 거지, 쿠버네티스 레벨의 변화를 직접 감지하는 건 아니에요.

---

✨ 정리

방법	특징	주의사항
Checksum 방식	체크섬 주입으로 Deployment 변경 감지 → 자동 롤링	CI/CD가 checksum 생성해줘야 함
Projected Volume 방식	파일 자체는 실시간 갱신됨	앱이 파일 변경을 감지하고 reload 해야 함
GitOps 방식 (ArgoCD 등)	Git 변경 감지 후 자동 배포	Git 변경이 선행되어야 함