[CKA] 55. Volumes in Kubernetes

Date

2026/01/29

Volumes

Docker 볼륨

•

도커 컨테이너는 일시적(transient)이다.

•

컨테이너가 처리한 데이터도 기본적으로 컨테이너와 함께 삭제된다.

•

그래서 컨테이너가 생성될 때 볼륨을 붙여서(volume attach), 컨테이너가 만든/처리한 데이터를 볼륨에 저장한다.

•

컨테이너가 삭제되어도 볼륨에 저장된 데이터는 남는다.

Kubernetes 볼륨

•

쿠버네티스에서 생성되는 Pod 역시 본질적으로 일시적이다.

•

Pod를 만들어서 데이터를 처리하고 Pod를 삭제하면, Pod 내부에 있던 데이터도 함께 사라진다.

•

해결 방식도 동일하다: Pod에 볼륨을 붙인다.

•

이제 Pod가 만든 데이터는 볼륨에 저장되므로 Pod가 삭제되어도 데이터는 유지된다.

Volume 구현 (Single Node)

시나리오:

•

단일 노드 Kubernetes 클러스터

•

Pod가 1~100 난수 생성

•

결과를 컨테이너 내부 경로에 파일(/opt/number.out)로 기록

•

Pod 종료/삭제

Pod가 사라져도 파일을 남기려면 볼륨을 만들고 볼륨이 사용할 스토리지를 지정해야 한다.

→ 가장 단순한 방식은 호스트의 디렉토리를 스토리지로 쓰는 방식이다.

•

호스트의 /data 디렉토리를 볼륨 스토리지로 지정

•

컨테이너 내부의 /opt에 마운트

•

컨테이너가 /opt/number.out에 쓰면 → 실제론 호스트 /data에 저장되는 형태

apiVersion: v1
kind: Pod
metadata:
	name: random-number-generator
spec:
	containers:
	- image: alpine
		name: alpine
		command: ["/bin/sh","-c"]
		args: ["shuf -i 0-100 -n 1 >> /opt/number.out;"]
		volumeMounts:
		- mountPath: /opt
			name: data-volume
	volumes:
	- name: data-volume
		hostPath:
			path: /data
			type: Directory
YAML
복사

Volume 구현 (Multi Node)

hostPath가 단일 노드에서는 잘 동작하지만, 멀티 노드 클러스터에서는 권장되지 않는다. 이유는 다음과 같다:

•

Pod가 어떤 노드에 뜰지 보장되지 않는다

•

모든 노드가 /data라는 경로를 갖고 있어도, 서로 다른 서버의 로컬 디렉토리이므로 같은 데이터가 아니다

•

즉, Pod가 노드를 옮겨가면 데이터 연속성이 깨질 수 있다.

•

멀티 노드에서 같은 데이터를 유지하기 위해선 외부 공유/복제 스토리지가 필요하다

Kubernetes는 hostPath 외에도 다양한 스토리지 솔루션을 지원한다:

•

온프레미스/클러스터 스토리지: NFS, Flocker, Fibre Channel, CephFS, ScaleIO 등

•

퍼블릭 클라우드: AWS EBS, Azure Disk/File, GCP Persistent Disk 등

볼륨의 스토리지 옵션으로 스토리지 솔루션을 사용하려면 hostPath를 해당 솔루션에 대한 필드로 변경하면 된다.

volumes:
- name: data-volume
	awsElasticBlockStore:
		volumeID: <volume-id>
		fsType: ext4
YAML
복사

Persistent Volumes

기존 방식

Volume을 Pod 정의 파일 내부에 직접 구성하는 위와 같은 방식은, 볼륨을 만들기 위해 필요한 스토리지 설정(hostPath, EBS 등)이 매번 Pod YAML 안에 들어가는 구조이다. 이 방식은 환경이 커지면 문제가 생긴다.

문제점

Pod에 볼륨을 직접 넣는 방식의 문제는 사용자 수가 많고, Pod도 많아지는 환경에서 발생한다.

사용자 수가 많고, Pod도 많아지는 환경에서는:

•

Pod를 배포하는 사용자가 매번 스토리지 설정을 직접 작성해야 한다

•

스토리지 타입이 바뀌거나 설정이 변경되면 모든 Pod 정의 파일을 일괄 수정해야 한다

→ 결과적으로 스토리지가 분산 관리되고, 운영/변경 비용이 커진다

기존 방식의 해결

스토리지가 분산 관리되고, 운영/변경 비용이 커지는 기존 방식을 해결하기 위해선:

•

관리지가 큰 스토리지 풀(pool)을 만들어 두고

•

사용자가 필요할 때 그 풀에서 필요한 만큼을 “떼어” 써서 Pod에 붙인다

이 개념이 Persistent Volume(PV)이다

Persistent Volume

PV = 관리자가 미리 클러스터에 준비해 둔 “클러스터 전체” 스토리지 리소스

•

PV는 클러스터 범위(cluster-wide) 리소스이다

•

애플리케이션 배포자는 PV를 직접 만지는 대신, PVC(Persistent Volume Claim)로 “필요한 스토리지”를 요청/선택한다

→ PV는 공급(관리자), PVC는 소비(사용자)의 개념이다

apiVersion: v1
kind: PersistentVolume
metadata:
	name: pv-vol1
spec:
	accessModes:
	- ReadWriteOnce
	capacity:
		starage: 1Gi
	awsElasticBlockStore:    # volume type으로 hostPath도 사용 가능하지만 프로덕션 환경에서 권장되지 않음
		volumeID: <volume-id>
		fsType: ext4
YAML
복사

•

accessModes:

◦

ReadOnlyMany: 여러 노드에서 읽기 전용

◦

ReadWriteOnce: 한 노드에서 읽기/쓰기

◦

ReadWriteMany: 여러 노드에서 읽기/쓰기

•

capacity: PV에 “예약해 둘” 스토리지 용량

Persistent Volume Claim

PV와 PVC는 서로 다른 오브젝트로, PVC는 사용자가 필요한 스토리지를 요청하는 객체이다.

Bind

PVC가 생성되면 Kubernetes는 PVC의 요청 조건(request/properties)을 기준으로 적절한 PV를 찾아 바인딩한다.

규칙

모든 PVC는 단 하나의 PV에만 바인딩이 되는 1대1 구조이기 때문에, 바인딩 시 고려되는 조건들에 매칭되야 한다:

•

capacity: 요청한 용량 이상인지

•

accessModes

•

volumeMode

•

storageClass 등

PV와 PVC는 위 조건들을 일치시켜야 하지만 capacity 같은 경우, PVC의 값이 PV보다 작을 수 있다. 즉, 작은 PVC가 더 큰 PV에 붙을 수 있다. 하지만 PV에 여유 공간이 생기더라도, 1대1 관계이므로 다른 PVC가 남는 용량을 나눠 쓰지 못한다.

조건에 매칭되는 PV가 없을 경우, PVC는 Pending 상태로 남는다. 새로운 PV가 클러스터에 제공되면 Pending PVC는 자동으로 그 PV에 바인딩 된다.

Label + Selector

여러 후보가 매칭될 수 있는 상황에서 특정 PV를 선택하고 싶으면 labels + selectors를 사용해 원하는 PV로 바인딩할 수 있다.

PVC

PVC 생성 예시

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi
YAML
복사

apiVersion: v1
kind: PersistentVolume
metadata:
	name: pv-vol1
spec:
	accessModes:
	- ReadWriteOnce
	capacity:
		starage: 1Gi
	awsElasticBlockStore:
		volumeID: <volume-id>
		fsType: ext4
YAML
복사

PV가 1Gi이고, PVC는 500Mi인 예시이다.

•

accessModes가 일치하고

•

PV 용량(1Gi)이 PVC 요청(500Mi)보다 크며

•

다른 후보 PV가 없다면

→ PVC는 해당 PV에 바인딩 된다.

Reclaim Policy

PVC를 삭제하면 PV는 어떻게 되는가에 대해서는 reclaim policy에 의해 결정된다

Retain (기본)

•

PVC가 삭제돼도 PV가 남는다

•

관리자가 수동으로 정리/삭제하기 전까지 유지된다

•

다른 PVC에서 재사용이 불가능하다 (정리 작업 필요)

Delete

•

PVC가 삭제되면 PV도 함께 삭제된다

•

클라우드 스토리지 같은 경우 실제 리소스 삭제로 이어질 수 있다

Recycle (Deprecated)

•

PV 내부 데이터를 지운 뒤 재사용 가능하게 만드는 옵션

•

과거에는 “Recycler Pod”가 볼륨을 마운트하고 rm -rf 같은 방식으로 파일을 지우는 “best effort wipe”였다

•

하지만 실무적으로 충분하지 않아 deprecated 되었다.

◦

안전한 삭제(secure erase) 보장 불가

◦

스냅샷 처리 불가

◦

provider metadata 처리 불가

◦

지원 플리거인/백엔드가 제한적

◦

실제 정리에서는 unmount, detach, 재포맷, 스냅샷, 정책 처리, 암호화/키 로테이션, provider-level delete call 등 다양한 작업이 필요할 수 있음

◦

rm -rf는 inode metadata를 남길 수 있고, 권한 문제로 실패할 수 있음

→ 이러한 이식성/보안 격차 때문에 Kubernetes는 더 최신 모델로 전환했다

Using PVC in Pod

생성된 PVC에 대해 Pod는 volume 섹션에 pvc 명을 정의 파일에 넣으면 된다. 이는 ReplicaSets나 Deployments에서도 Pod 섹션에서 동일하게 적용된다.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim
YAML
복사

이전 게시물

다음 게시물

[CKA] 56. StorageClass