쿠버네티스 저장소와 설정: PV·PVC, ConfigMap, Secret

컨테이너의 파일 시스템은 컨테이너가 다시 시작되면 사라진다. 쿠버네티스는 남겨야 할 데이터는 볼륨으로, 환경마다 다른 설정과 비밀 값은 ConfigMap·Secret으로 이미지 밖에 둔다. 같은 이미지를 모든 환경에 쓰려는 12요소 앱의 원칙과 같다.

볼륨 유형

PV와 PVC

노드(자원)와 파드(요청)의 관계처럼, PVC는 조건에 맞는 PV와 일대일로 묶인다(binding). 파드는 PV를 직접 모르고 PVC 이름만 가리키므로, 저장소 종류가 바뀌어도 파드 명세는 그대로다.

flowchart LR
  pod["Pod"] -->|"volumes: claimName"| pvc["PVC"]
  pvc -->|"바인딩"| pv["PV"]
  pv --> disk["실제 디스크"]
  pvc -->|"storageClassName"| sc["StorageClass<br/>(없으면 자동 생성)"]

접근 모드

접근 모드는 드라이버가 지원해야 한다. 블록 볼륨은 RWX를 지원하지 않는다. RWO 볼륨을 쓰는 Deployment를 롤링 업데이트하면 새 파드가 다른 노드에 놓여 볼륨을 붙이지 못하고 멈출 수 있어, 그런 앱은 Recreate 전략이나 StatefulSet을 쓴다.

회수 정책(Reclaim Policy)

PVC를 지워 PV가 풀려났을 때 실제 저장소를 어떻게 할지 정한다.

StorageClass와 동적 프로비저닝

StorageClass는 「어떤 종류의 저장소를 어떻게 만들지」를 정의한 템플릿이다. PVC가 StorageClass를 지정하면 해당 프로비저너가 그 자리에서 디스크를 만들고 PV를 생성해 묶는다. 관리자가 PV를 미리 만들어 둘 필요가 없다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3
  annotations: { storageclass.kubernetes.io/is-default-class: "true" }
provisioner: ebs.csi.aws.com
parameters: { type: gp3 }
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

• volumeBindingMode: WaitForFirstConsumer는 파드가 스케줄될 때까지 디스크 생성을 미룬다. Immediate면 디스크가 먼저 아무 가용 영역에 생겨, 파드가 다른 영역 노드에 놓이면 붙일 수 없다. 영역에 묶인 블록 스토리지는 WaitForFirstConsumer를 쓴다.
• allowVolumeExpansion: true면 PVC의 용량을 늘려 디스크를 키운다. 줄이기는 안 된다.
• 기본 StorageClass를 정해 두면 storageClassName을 생략한 PVC가 그것을 쓴다.

CSI

CSI(Container Storage Interface)는 스토리지 업체가 쿠버네티스 본체를 고치지 않고 드라이버를 붙이는 표준 인터페이스다. 예전에는 클라우드 디스크 드라이버가 쿠버네티스 코드 안(in-tree)에 있어 업체가 고치려면 쿠버네티스 릴리스를 기다려야 했다. 지금 in-tree 드라이버는 CSI로 옮겨졌다.

대표 드라이버는 AWS EBS·EFS CSI, GCE Persistent Disk CSI, Azure Disk·File CSI, Ceph(Rook), Longhorn, NFS CSI다. CSI는 VolumeSnapshot으로 스냅숏·복원도 지원한다.

ConfigMap

ConfigMap은 비밀이 아닌 설정을 키-값으로 저장한다. 크기는 1MiB까지다.

kubectl create configmap app --from-literal=LOG_LEVEL=info          # 키-값 직접
kubectl create configmap app --from-file=config.yaml                # 파일 하나: 키=파일 이름
kubectl create configmap app --from-file=conf/                      # 디렉터리: 파일마다 키
kubectl create configmap app --from-env-file=app.env                # KEY=VALUE 줄들을 각각 키로

주입 방식: 환경 변수 vs 볼륨

Secret

Secret은 비밀번호·토큰·인증서처럼 민감한 값을 담는다. 쓰는 방법(환경 변수, 볼륨)은 ConfigMap과 같지만 다루는 방식이 다르다.

Secret은 안전한가

기본 상태의 Secret은 암호화가 아니다. base64는 인코딩일 뿐 누구나 되돌린다.

Secret 유형

외부 비밀 저장소 연동

비밀의 원본을 Vault, AWS Secrets Manager, GCP Secret Manager 같은 전용 저장소에 두면 교체·감사·접근 제어를 한곳에서 한다.

외부 저장소에 접근하는 권한은 노드 전체가 아니라 파드의 서비스 계정에 묶는다(EKS의 IRSA·Pod Identity, GKE Workload Identity). 비밀 관리 원칙은 DevSecOps에 있다.

변경이 파드에 반영되지 않는 문제

ConfigMap·Secret을 고쳐도 환경 변수는 그대로고, 파일은 바뀌어도 앱이 시작할 때 한 번만 읽었다면 반영되지 않는다. 쿠버네티스는 설정이 바뀌었다고 파드를 다시 띄우지 않는다.

immutable: true인 ConfigMap·Secret은 고칠 수 없는 대신 kubelet이 변경을 감시하지 않아 API 서버 부하가 준다.

정리

• 파드와 같이 사라져도 되면 emptyDir, 남겨야 하면 PVC다. hostPath는 노드 에이전트 전용이다.
• PVC는 요청, PV는 실제 저장소이고, StorageClass가 있으면 PV가 자동으로 만들어진다. 영역에 묶인 디스크는 WaitForFirstConsumer로 만든다.
• 접근 모드는 RWO(노드 하나)·ROX·RWX·RWOP(파드 하나)이고, 회수 정책은 지킬 데이터면 Retain이다.
• ConfigMap·Secret을 환경 변수로 넣으면 바뀌어도 반영되지 않는다. 롤아웃을 일으키는 해시 패턴을 쓴다.
• Secret은 기본적으로 base64일 뿐이다. 저장 시 암호화, 좁은 RBAC, 외부 비밀 저장소로 보완한다.

관련 노트: 쿠버네티스 구조와 핵심 개념, 쿠버네티스 워크로드와 파드 생명주기, 쿠버네티스 보안, Docker 네트워크와 볼륨, DevSecOps, 12요소 앱