개요
k8s에서 volume을 어떻게 관리하는지 알아보겠습니다.
본 글에서 k8s에서 volume의 사용법, 그리고 Persistent Volumes과 Persistent Volume Claims 대하여 알아보겠습니다.
목차
volume 개념
volume 사용법
Persistent Volumes 개념
Persistent Volume Claims 개념
volume
container의 data를 container가 종료돼도 유지할 수 있게 해주는 기능입니다.
Temp 전용 volume
EmptyDir
Pod가 생성될 때마다 새로운 빈 디렉터리를 생성합니다. Pod 내의 모든 container에서 공유될 수 있습니다
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx
volumeMounts:
- name: my-emptydir-volume
mountPath: /data
volumes:
- name: my-emptydir-volume
emptyDir: {}
Host 전용 volume
HostPath
Node의 파일 시스템을 Pod에 마운트합니다.
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx
volumeMounts:
- name: my-hostpath-volume
mountPath: /data
volumes:
- name: my-hostpath-volume
hostPath:
path: /var/lib/some-data
Network volume의 type 및 사용법
종류
network를 통하여 data를 공유하기 위한 solution으로 아래와 다양한 것이 존재합니다.
그러나 이 중에서 그나만 간단한 NFS와 PV를 알아보겠습니다.
NFS (Network File System)
네트워크 파일 시스템을 Pod에 마운트 합니다.
apiVersion: v1
kind: Pod
metadata:
name: nfs-client-pod
spec:
containers:
- name: nfs-client-container
image: nginx
volumeMounts:
- name: nfs-volume
mountPath: /usr/share/nginx/html # 이 경로에 NFS 서버의 데이터가 마운트됩니다.
volumes:
- name: nfs-volume
nfs:
server: 192.168.1.100 # NFS 서버의 IP 주소
path: /var/nfs/general # NFS 서버에서 공유하는 디렉터리
PV - PVC - POD 관계 및 소개
PV(Persistent Volume)
PersistentVolume (PV)은 클러스터 내에서 지속적으로 사용할 수 있는 storage volume을 나타냅니다.
저장 공간을 확보하는 용도입니다.
PVC(Persistent Volume Claim)
Kubernetes에서 PersistentVolumeClaim (PVC)은 PersistentVolume (PV)에 대한 요청 또는 "Claim"을 나타냅니다.
PV로 확보된 저장공간을 요청하는 용도입니다.
POD
Pod에서는 PVC를 사용합니다.
PV - PVC - Pod관계 도식
PersistentVolume (PV)
용도
PersistentVolume (PV)은 클러스터 내에서 지속적으로 사용할 수 있는 storage volume을 나타냅니다.
PV는 클러스터가 존재하는 한 지속적으로 존재합니다. 즉, Pod가 생성되거나 삭제되어도 PV는 삭제되지 않습니다.
주요 필드
volumeMode
volumeMode는 PersistentVolume(PV) 또는 PersistentVolumeClaim(PVC)에서 볼륨이 어떻게 액세스되고 마운트될지를 지정하는 옵션입니다. volumeMode는 두 가지 모드를 지원합니다.
Filesystem 모드
- 기본 설정으로, volumeMode가 명시되지 않으면 Filesystem 모드로 설정됩니다.
- 볼륨이 파일 시스템으로 포맷되어 Pod에 마운트됩니다.
- 컨테이너 내에서 파일 시스템처럼 디렉토리와 파일을 다루는 방식으로 사용됩니다.
- 예를 들어, ext4 또는 xfs와 같은 파일 시스템으로 포맷된 후 컨테이너에서 파일 시스템으로 접근할 수 있습니다.
Block 모드
- volumeMode를 Block으로 설정하면, 볼륨을 원시 블록 장치로 액세스합니다.
- 파일 시스템 없이 블록 장치 그대로 사용해야 할 때 사용됩니다.
- 일반적으로 데이터베이스와 같은 애플리케이션에서 고성능 IO를 위해 블록 장치를 직접 접근하고자 할 때 사용됩니다.
- 컨테이너에 직접 마운트되며, 파일 시스템 없이 바이트 스트림 방식으로 데이터를 읽고 씁니다.
volumeMode 필드는 PersistentVolume 및 PersistentVolumeClaim (PVC) 리소스 정의에서 설정할 수 있으며, PVC가 요청하는 스토리지의 타입을 PV가 제공해야 합니다. 예를 들어, PVC가 Block 모드를 요청한다면, 이를 충족하는 Block 모드의 PV와 연결되어야 합니다.
이러한 설정은 특히 고성능이 필요한 애플리케이션에서 중요할 수 있으며, 올바른 volumeMode를 선택함으로써 애플리케이션의 요구사항과 최적의 성능을 맞출 수 있습니다.
capacity
PV는 정해진 용량을 가지며, 이 용량을 넘을 수 없습니다.
accessModes
PV는 다양한 접근 모드를 지원합니다.
ReadWriteOnce : 하나의 노드만 쓰기 가능
ReadOnlyMany : 여러 노드에서 읽기만 가능
ReadWriteMany: 여러 노드에서 쓰기 가능
ReadWriteOncePod : 볼륨이 단일 파드에서 읽기-쓰기로 마운트 될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야 하는 경우 ReadWriteOncePod 접근 모드를 사용한다
storageClassName
PV는 스토리지 클래스에 연결될 수 있습니다. 이를 통해 동적 프로비저닝이 가능합니다.
backend storage
다양한 백엔드 스토리지를 지원합니다. 예를 들어, AWS의 EBS, Google Cloud의 Persistent Disk, NFS, iSCSI 등이 있습니다.
PV 생성
yaml로 생성
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv
spec:
capacity:
storage: 1Gi # 볼륨 크기
accessModes:
- ReadWriteOnce # 접근 모드
storageClassName: fast-storage # 사용할 StorageClass 지정 (필요시 사용)
persistentVolumeReclaimPolicy: Retain # 재활용 정책
hostPath:
path: "/roo/data" # 물리적 위치 (예시)
항목 설명
persistentVolumeReclaimPolicy
Retain(유지)
PersistentVolumeClaim이 삭제되면 해당 PersistentVolume은 자동으로 삭제되지 않습니다. 대신 "Released" 상태로 이동하고 Volume의 Data는 그대로 유지됩니다.
Delete
PersistentVolumeClaim이 삭제되면 해당 PersistentVolume도 자동으로 삭제됩니다. 이는 PersistentVolumeClaim이 삭제되면 데이터를 유;할 필요가 없는 경우에 유용합니다. 이를 지원하는 볼륨의 경우, 기본 스토리지도 삭제됩니다 (예: AWS의 EBS 볼륨).
PV 확인
kubectl get pv
PV 삭제
kubectl delete pv {pv-name}
PersistentVolumeClaim (PVC)
용도
Kubernetes에서 PersistentVolumeClaim (PVC)은 PersistentVolume (PV)에 대한 요청 또는 "Claim"을 나타냅니다. PVC를 사용하면 사용자는 필요한 storage 크기, 접근 모드 등을 쉽게 지정할 수 있으며, 이 정보를 바탕으로 k8s는 적절한 PV를 찾아 연결(bind)합니다.
PVC는 종종 개발자나 애플리케이션 운영자가 사용합니다. 복잡한 백엔드 스토리지 세부 정보를 몰라도 원하는 스토리지를 요청할 수 있습니다
주요 필드
accessModes
PVC에서는 ReadWriteOnce (하나의 노드에서 읽기/쓰기), ReadOnlyMany (다수의 노드에서 읽기 전용), ReadWriteMany (다수의 노드에서 읽기/쓰기) 등의 접근 모드를 지정할 수 있습니다.
capacity
필요한 스토리지 크기를 resources.requests.storage 필드에 지정할 수 있습니다.
storageClassName
PVC는 storageClassName 필드를 통해 특정 StorageClass에 바인딩될 수 있습니다. 이를 통해 동적 프로비저닝이 가능합니다.
사용법
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 500Mi
작동 방식
PVC 객체를 생성하여 원하는 스토리지 사양을 지정합니다.
쿠버네티스 스케줄러는 이 요구 사항에 적합한 PV를 찾아 PVC에 바인딩합니다.
바인딩된 PV는 이후에 파드에서 사용될 수 있습니다.
파드가 종료되거나 PVC가 삭제되더라도, PV와 데이터는 유지되며 재사용이 가능하거나 리클레임 정책에 따라 처리됩니다.
PVC는 사용자가 쉽게 지속적인 스토리지를 요청하고 사용할 수 있도록 하는 중요한 쿠버네티스 리소스입니다.
StorageClass(SC)
Kubernetes에서 "동적 스토리지 프로비저닝(Dynamic Storage Provisioning)" 을 지원하기 위해 사용되는 Resource입니다.
개념
StorageClass는 스토리지의 종류, 성능, 접근 방식 등을 지정하여, 사용자가 원하는 스토리지 유형을 정의할 수 있게 해줍니다. 예를 들어, 빠른 속도를 필요로 하는 SSD 스토리지, 저비용의 HDD 스토리지, 네트워크 기반의 파일 스토리지(NFS) 등 다양한 스토리지 옵션을 정의할 수 있습니다.
StorageClass는 특히 PersistentVolume(PV)을 동적으로 생성할 때 사용되며, 사용자는 스토리지의 세부적인 구현 방식에 신경 쓰지 않고 필요한 종류의 스토리지에 대한 요구 사항만 지정할 수 있습니다.
사용법
StorageClass를 사용하기 위해서는 다음과 같은 단계가 필요합니다:
StorageClass 생성
- 클러스터 관리자가 미리 정의한 스토리지 유형에 맞게 StorageClass를 생성합니다.
- StorageClass에는 provisioner라는 필드가 있으며, 이 필드는 Kubernetes가 특정 스토리지를 자동으로 생성할 때 사용할 storage provisioner를 지정합니다. 각 cloud나 storage 시스템마다 다른 provisioner를사용할 수 있습니다
예제
아래 예시에서는 fast-storage라는 StorageClass를 정의하며, AWS EBS(Elastic Block Store)를 사용하여 고성능 스토리지(gp2 타입)를 제공합니다.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-storage
provisioner: kubernetes.io/aws-ebs # AWS EBS 사용 예시
parameters:
type: gp2
iopsPerGB: "10"
fsType: ext4
PV - PVC
PV와 PVC를 Label과 selector를 사용하여 연결 하기
SC - PV - PVC
연결관계 빨간색 Pod로 표시
SC (name) <-> PV (storageClassName)
PV (storageClassName) <-> PVC (storageClassName)
PVC (name) <-> POD claimName
SC - PVC (NFS)
storageClassName를 사용하여 연결이 됩니다.
SC - PVC (google-storage)
PVC에 storage class 연결하기
알면 좋은 것 : 내부적으로 storageClass는 PV를 생성하여 관리합니다.
storageclass확인
kubectl get storageclass
bind확인 pending시 사항
storageclass는 WaitForFirstConsumer로 설정된 VolumeBindingMode를 사용하면
PertantVolumeClaim을 사용하는 Pod가 생성될 때까지 PertantVolume의 binding 및 provisioning이 지연됩니다.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
- debug
volumeBindingMode: Immediate
VolumeBindingMode옵션
Immediate
- 설명: Immediate 모드에서는 PVC가 생성될 때 즉시 PV와 바인딩을 시도합니다. 이 모드에서는, 클러스터에 사용 가능한 PV가 있으면 PVC 생성과 동시에 해당 PV에 바인딩됩니다.
- 사용 시나리오: 일반적인 시나리오에 적합하며, 대부분의 경우에 이 모드가 기본값으로 설정됩니다. PVC가 생성되는 즉시 사용 가능한 PV에 연결됩니다.
WaitForFirstConsumer
- 설명: WaitForFirstConsumer 모드에서는 PVC가 생성된 후에도 바로 PV에 바인딩되지 않습니다. 대신, PVC를 사용하는 첫 번째 파드(Pod)가 스케줄링되는 시점에 PV와의 바인딩이 발생합니다.
- 사용 시나리오: 이 모드는 볼륨의 배치를 최적화하려는 경우에 유용합니다. 예를 들어, 파드가 실행되는 노드와 가까운 위치에 있는 스토리지를 선택하는 등의 결정이 필요할 때 사용됩니다. 동적 프로비저닝 환경에서 특히 유용하며, 볼륨의 지연 바인딩을 통해 스토리지 사용 효율을 높일 수 있습니다.
Pod에서 PVC 사용법
Pod에서는 volume의 persistentVolumeClaim를 이용하여 PVC를 연결 합니다.
yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
labels:
test: MyApp
spec:
containers:
- name: my-container
image: nginx
ports:
- containerPort: 80
name: http-web-svc
volumeMounts:
- name: my-volume
mountPath: /usr/share/nginx/html
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: myclaim
TroubleShooting
pvc가 pending인 경우 pv와 pvc의 accessModes가 같은지 먼저 확인해보세요
아래 중 하나의 값이 여야 합니다.
- RWO - ReadWriteOnce
- ROX - ReadOnlyMany
- RWX - ReadWriteMany
- RWOP - ReadWriteOncePod
정리
PV(Persistent Volume)
PersistentVolume (PV)은 클러스터 내에서 지속적으로 사용할 수 있는 storage volume을 나타냅니다.
저장 공간을 확보하는 용도입니다.
PVC(Persistent Volume Claim)
Kubernetes에서 PersistentVolumeClaim (PVC)은 PersistentVolume (PV)에 대한 요청 또는 "Claim"을 나타냅니다.
PV로 확보된 저장공간을 요청하는 용도입니다.
POD
Pod에서는 PVC를 사용합니다.
참고
https://velog.io/@idnnbi/kubernetes-pvc-pv
Next Post
'Cloud > k8s-CKA' 카테고리의 다른 글
[CKA] 36. Security - TLS 통신과정 (0) | 2023.09.21 |
---|---|
[CKA] 35. Security - TLS통신 이해를 위한 PKI 기본 지식 (0) | 2023.09.17 |
[CKA] 33. docker의 volume관리 (volume driver) (0) | 2023.08.30 |
[CKA] 32. docker의 image layer관리 (storage driver) (0) | 2023.08.15 |
[CKA] 31. service - plugin (0) | 2023.07.27 |