[Kubernetes] Kubernetes에서 PV(Persistent Volume)와 PVC(Persistent Volume Claim)의 관계

728x90

개요

Kubernetes에서 스토리지 관리는 애플리케이션이 데이터의 영속성을 유지하도록 보장하는 데 매우 중요한 역할을 합니다. 특히 Pod가 재시작되거나 스케일링되는 상황에서도 데이터를 안전하게 유지하려면 PV와 PVC의 개념을 이해하는 것이 필수적입니다.

Persistent Volume(PV)란?

PV는 클러스터 전역에서 사용 가능한 스토리지 리소스를 의미합니다. 관리자가 클러스터에 사전에 프로비저닝한 스토리지로, 클라우드 스토리지, 네트워크 스토리지(NFS), 로컬 디스크 등 다양한 스토리지 백엔드를 지원합니다. PV는 기본적인 스토리지 기술을 애플리케이션에서 추상화하여, 사용자는 상세한 설정 없이 스토리지를 요청하고 사용할 수 있습니다.

PV의 주요 특징

클러스터 리소스 : PV는 클러스터 전체에서 관리되며, 특정 사용자나 애플리케이션에 구속되지 않습니다.
스토리지 백엔드 : PV는 AWS, EBS, NFS, Azure Disk, GCE PD 등 다양한 스토리지 백엔드와 연동됩니다.
프로비저닝 방식 :
- 정적 프로비저닝 : 관리자가 직접 PV를 생성합니다.
- 동적 프로비저닝 : PVC 요청 시 Kubernetes가 자동으로 PV를 생성합니다.

예시(nfs)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /exported/path
    server: 192.168.1.100

Persistent Volume Claim(PVC)란?

PVC는 사용자나 애플리케이션이 스토리지를 요청하는 방식입니다. PVC는 Kubernetes Pod와 PV를 연결하는 역할을 합니다. 사용자는 PVC에서 원하는 스토리지의 용량과 액세스 모드를 정의하고, Kubernetes는 이를 만족하는 PV를 찾아 자동으로 연결(Binding)합니다.

PVC 주요 특징

사용자 요청 : PVC는 애플리케이션 개발자가 필요한 스토리지를 요청하기 위해 생성합니다.
자동 바인딩 : Kubernetes는 PVC의 요구 조건과 일치하는 PV를 찾아 자동으로 바인딩합니다.
동적 프로비저닝 : StorageClass를 통해 PV가 자동으로 생성될 수 있습니다.

PVC 정의 예시

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

PV와 PVC의 관계

PV와 PVC의 관계는 제공자와 소비자의 관계로 이해할 수 있습니다.

PV(제공자) : 프로비저닝된 스토리지 리소스를 나타냅니다.
PVC(소비자) : 애플리케이션이 요구하는 스토리지 요청하는 방식입니다.

PVC가 생성되면 Kubernetes는 PVC의 조건(용량, 액세스 모드)에 맞는 PV를 찾아 바인딩합니다. 이 과정을 통해 사용자는 PV의 상세 설정을 몰라도 PVC를 통해 스토리지를 사용할 수 있습니다.

PV-PVC 바인딩의 주요 원칙

PVC가 요청한 스토리지 용량 ≤ PV 용량
PVC의 액세스 모드와 PV의 액세스 모드가 일치해야함
라벨 및 셀렉터를 사용하여 특정 PV와 PVC를 강제로 연결할 수 있음

PV-PVC 관계의 라이플 사이클

Available : PV가 PVC에 바인딩 되지 않은 상태
Bound : PVC가 PV와 매칭되어 사용 중인 상태
Released : PVC가 삭제되었지만 PV는 여전히 데이터가 남아있는 상태
Reclaimed : 관리자가 데이터를 정리한 후 PV를 재사용 가능한 상태로 전환

동적 프로비저닝과 Storage Class

StorageClass를 사용하면 PVC가 기존 PV를 요청하는 대신, PVC 요청 시 동적으로 새로운 PV를 생성할 수 있습니다. 이를 통해 스토리지 관리를 자동화하고, 수동 프로비저닝의 복잡성을 줄일 수 있습니다.

StorageClass 예시

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2

동적 PVC 예시

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: fast-storage

위 설정에서

PVC가 fast-storage StoreageClass를 사용해 스토리지를 요청합니다.
Kubernetes가 PVC의 요구 사항에 맞는 새로운 PV를 동적으로 생성합니다.

PVC 주요 액세스 모드

PVC는 다음과 같은 액세스 모드를 지원합니다.

ReadWriteOnce(RWO) : 한 노드에서만 읽기 및 쓰기 가능
ReadOnlyMany(ROX) : 여러 노드에서 읽기만 가능
ReadWriteMany(RWX) : 여러 노드에서 읽기 및 쓰기 가능

PV, PVC 사용 시나리오

정적 프로비저닝

관리자가 미리 PV를 생성
사용자가 PVC를 생성하여 미리 준비된 PV를 요청

동적 프로비저닝

관리자가 StorageClass를 설정
사용자가 PVC를 생성하면 Kubernetes가 자동으로 PV를 생성하여 요청 처리

Reclaim 정책

Retain : PVC가 삭제되어도 PV를 삭제하지 않음
Recycle : PV를 초기화한 뒤 재사용 가능 상태로 전환(현재는 사용되지 않음)
Delete : PVC 삭제 시 PV와 백엔드 스토리지를 모두 삭제

직접 관리할 일이 줄어든 PVC

최근 Kubernetes 환경에서 PVC를 잘 사용하지 않는다는 말을 들었는데, 완전히 쓰이지 않는 것이 아니라 직접 PVC를 관리할 일이 줄어든 것이였다. Kubernetes의 스토리지 관리 방식이 발전하면서 PVC의 필요성이 줄어든 이유를 살펴보겠습니다.

PVC 사용이 줄어든 이유

클라우드 네이티브 스토리지 솔루션의 발전

AWS EKS, Google GKE, Azure AKS 같은 클라우드 기반 Kubernetes 서비스에서는 PVC를 직접 정의하지 않고도 스토리지를 사용할 수 있습니다.

AWS EKS + EFS CSI 드라이버 : PVC를 직접 생성하지 않아도 Amazon EFS를 동적으로 마운트 할 수 있습니다.
Google GKE Persistent Disks : StorageClass를 지정하면 PVC 없이 자동으로 스토리지 할당이 가능합니다.
Azure AKS Files : Azure Files를 사용하면 CSI(Container Storage Interface)로 PVC 없이 볼륨을 관리할 수 있습니다.

즉 PVC는 여전히 존재하지만 사용자가 직접 생성하지 않아도 되는 환경이 많아지고 있다는 것 입니다.

StatefulSet + Kubernetes Operator의 발전

과거에는 PostgreSQL, MySQL, Redis 같은 Stateful 애플리케이션을 운영할 때 PVC를 직접 생성하고 관리해야 했습니다.

그러나 이제는 Operator(운영자 패턴)를 활용하면 PVC를 자동으로 관리할 수 있습니다.

예제 : PostgreSQL Operator를 사용하면, PVC를 따로 생성할 필요 없이 Operator가 알아서 PVC를 생성하고 관리합니다.
대표적인 Stateful Operator 예시
- Rook : Cepth 기반 스토리지 관리
- OpenEBS : Kubernetes 네이티비 블록 스토리지
- KubeDB : 데이터 베이스 자동 배포 및 관리

이런 솔루션을 사용하면 개발자는 PVC를 직접 정의하지 않고도 Stateful 애플리케이션을 운영할 수 있습니다.

그렇다면 PVC는 정말로 필요 없을까?

아직도 PVC가 필요한 경우는 많습니다.

✅ PVC가 여전히 필요한 경우

클라우드 환경이 아닌 온프레미스 Kubernetes 클러스터
- 직접 NFS, Ceph, GlusterFS 등의 스토리지를 운영해야 하는 경우.
StatefulSet을 직접 운영하는 경우
- PVC 없이 MySQL, Redis, Kafka 같은 애플리케이션을 배포하기 어려움.
하이브리드 클라우드 또는 멀티 클러스터 환경
- PVC 없이 로컬 및 원격 스토리지를 통합 관리하는 것이 어려움.
스토리지 성능 최적화가 필요한 경우
- 자동 프로비저닝된 PVC보다 직접 설정한 PV/PVC가 성능 조정에 유리한 경우.

PVC를 대체할 수 있는 방법은?

✔ StorageClass를 활용한 동적 프로비저닝

PVC를 직접 생성하지 않고, StorageClass를 사용하면 자동으로 PV가 생성됩니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2

이렇게 하면 PVC를 생성할 때 자동으로 스토리지가 할당됩니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: fast-storage

✔ Kubernetes Operator 활용

PostgreSQL Operator, Redis Operator, MongoDB Operator 등을 사용하면 PVC를 직접 생성하지 않아도 됩니다.

✔ 클라우드 네이티브 스토리지 사용

AWS EFS, Google Filestore, Azure Files와 같은 서비스를 사용하면 PVC를 직접 정의할 필요 없이 Kubernetes에서 자동으로 마운트됩니다.

✔ 외부 데이터베이스 사용

Kubernetes 내부에서 데이터베이스를 운영하는 대신, AWS RDS, Google Cloud SQL 같은 관리형 데이터베이스를 사용하면 PVC 없이 데이터를 저장할 수 있습니다.

결론 : PVC를 완전히 쓰지 않는 것이 아니라 직접 관리할 일이 줄어든 것이다.

🚀 PVC는 여전히 Kubernetes에서 중요한 역할을 합니다.
다만,

클라우드 네이티브 환경에서는 PVC 없이도 자동으로 스토리지를 사용할 수 있고,
StatefulSet 및 Operator를 활용하면 PVC를 직접 생성하지 않아도 되고,
Ephemeral(휘발성) 스토리지를 쓰거나 외부 데이터베이스를 이용하는 경우 PVC가 필요 없기도 합니다.

즉, “PVC를 사용하지 않는다”는 말은 PVC 자체가 사라진 것이 아니라, 사용자가 직접 PVC를 관리하는 일이 줄어들었다는 의미로 이해하는 것이 맞습니다. 🎯

🔥 PVC를 쓰지 않아도 되는 경우

✔ 클라우드에서 EFS, Filestore, Azure Files 같은 네이티브 스토리지 사용
✔ StatefulSet + Operator 활용 (PostgreSQL, Redis, MongoDB 등)
✔ 외부 관리형 데이터베이스 (AWS RDS, Google Cloud SQL 등) 사용
✔ Ephemeral 스토리지 (emptyDir, ConfigMap, Secret 등) 사용

💡 PVC를 여전히 써야 하는 경우

✔ 온프레미스 환경 (Bare Metal, 자체 호스팅 Kubernetes)
✔ 고성능 스토리지 튜닝이 필요한 경우
✔ 멀티 클러스터 및 하이브리드 클라우드 환경

'DevOps > Kubernetes' 카테고리의 다른 글

[EKS] aws-load-balancer-controller 배포 (0)	2025.02.14
[EKS] EKS 애플리케이션 배포 실습 (0)	2025.02.13
[EKS] kubectl 설치 & eksctl 명령어 설치 후 EKS 생성 test (0)	2025.02.11
[Kubernetes] CoreDNS: Kubernetes 네트워킹의 핵심을 파헤치다 (0)	2025.02.08
[Kubernetes] 쿠버네티스 서비스 및 로드 밸런싱 이해 (1)	2025.02.07

estar987

[Kubernetes] Kubernetes에서 PV(Persistent Volume)와 PVC(Persistent Volume Claim)의 관계

개요

Persistent Volume(PV)란?

PV의 주요 특징

Persistent Volume Claim(PVC)란?

PVC 주요 특징

PV와 PVC의 관계

PV-PVC 바인딩의 주요 원칙

PV-PVC 관계의 라이플 사이클

동적 프로비저닝과 Storage Class

StorageClass 예시

동적 PVC 예시

PVC 주요 액세스 모드

PV, PVC 사용 시나리오

정적 프로비저닝

동적 프로비저닝

Reclaim 정책

직접 관리할 일이 줄어든 PVC

PVC 사용이 줄어든 이유

클라우드 네이티브 스토리지 솔루션의 발전

최신 애플리케이션이 점점 더 Ephemeral(휘발성)화 됨

StatefulSet + Kubernetes Operator의 발전

그렇다면 PVC는 정말로 필요 없을까?

✅ PVC가 여전히 필요한 경우

PVC를 대체할 수 있는 방법은?

✔ StorageClass를 활용한 동적 프로비저닝

✔ Kubernetes Operator 활용

✔ 클라우드 네이티브 스토리지 사용

✔ 외부 데이터베이스 사용

결론 : PVC를 완전히 쓰지 않는 것이 아니라 직접 관리할 일이 줄어든 것이다.

🔥 PVC를 쓰지 않아도 되는 경우

💡 PVC를 여전히 써야 하는 경우

'DevOps > Kubernetes' 카테고리의 다른 글

티스토리툴바

[Kubernetes] Kubernetes에서 PV(Persistent Volume)와 PVC(Persistent Volume Claim)의 관계

개요

Persistent Volume(PV)란?

PV의 주요 특징

Persistent Volume Claim(PVC)란?

PVC 주요 특징

PV와 PVC의 관계

PV-PVC 바인딩의 주요 원칙

PV-PVC 관계의 라이플 사이클

동적 프로비저닝과 Storage Class

StorageClass 예시

동적 PVC 예시

PVC 주요 액세스 모드

PV, PVC 사용 시나리오

정적 프로비저닝

동적 프로비저닝

Reclaim 정책

직접 관리할 일이 줄어든 PVC

PVC 사용이 줄어든 이유

클라우드 네이티브 스토리지 솔루션의 발전

최신 애플리케이션이 점점 더 Ephemeral(휘발성)화 됨

StatefulSet + Kubernetes Operator의 발전

그렇다면 PVC는 정말로 필요 없을까?

✅ PVC가 여전히 필요한 경우

PVC를 대체할 수 있는 방법은?

✔ StorageClass를 활용한 동적 프로비저닝

✔ Kubernetes Operator 활용

✔ 클라우드 네이티브 스토리지 사용

✔ 외부 데이터베이스 사용

결론 : PVC를 완전히 쓰지 않는 것이 아니라 직접 관리할 일이 줄어든 것이다.

🔥 PVC를 쓰지 않아도 되는 경우

💡 PVC를 여전히 써야 하는 경우

'DevOps > Kubernetes' 카테고리의 다른 글

관련글

티스토리툴바