PVC, PV
- pvc와 pv의 사용은 Pod의 container에서 실제 node의 물리적인 위치를 사용하기 위한것이다.
- PV : 관리자에 의해서 생성된 볼륨 (실제 물리 디스크 위치)
- PVC : 사용자가 볼륨을 사용하기 위해 pv에 요청
PV 종류
- 임시 볼륨
- emptyDir
- 파드가 노드에 할당될 때 처음 생성되며, 파드가 실행되는 동안에만 존재
- 파드 삭제시 영구적으로 데이터가 삭제
- 컨테이너 크래시될때는 사라지지 않음
- emptyDir
- 로컬 볼륨
- hostpath
- 각 호스트 노드의 파일시스템에 있는 파일, 디렉터리를 마운트
- hostpath는 호스트의 디렉터리를 Pod와 공유해 사용하는 방식
- 각 파드의 노드 파일이 다르기때문에 노드마다 다르게 동작
- Pod가 삭제되어도 hostpath에 저장된 파일들은 호스트에 저장되어 남아있음
- (필수 및 주의) host가 바뀌면 안되기 때문에, 특정 호스트를 nodeSelector를 통해 지정해주지 않으면 매번 컨테이너가 다른 호스트에 할당됨.
- 기본 호스트에 생성된 파일, 디렉터리는 root만 사용할수 있음(또는 권한 수정필요)
- 도커 설정, cAdvisor 실행등의 설정값을 보기위해 주로 사용됨
- Type
- DirectoryOrCreate : 필요에따라 빈디렉터리 생성
- Directory : 디렉터리가 있어야함
- FileOrCreate, 필요에따라 빈디렉터리 생성
- File : 주어진 경로에 파일이 있어야함
- Socket : 주어진 경로에 UNIX 소켓이 있어야함
- CharDevice : 주어진 경로에 문자 디바이스가 있어야함
- BlockDevice : 주어진 경로에 블록 디바이스가 있어야함
- 각 호스트 노드의 파일시스템에 있는 파일, 디렉터리를 마운트
- local
- 디스크 파티션 또는 디렉터리 같은 마운트된 로컬 스토리지 장치
- local 볼륨은 데이터를 로컬 호스트에 저장한다는 점에서는 hostPath와 동일
- 로컬 볼륨이 존재하는 호스트를 인식해 컨테이너를 할당한다는 특징
- 해당 local 볼륨을 사용하는 Pod는 자동으로 해당 호스트로 할당되는 방식
- hostpath의 기능에 nodeConstraint를 적용한 NodeAffinity의 역할을 동시에 선언해 사용하는거와 비슷함
- 해당 호스트에 장애가 발생할 경우 Pod의 데이터를 사용할 수 없음
- 정적으로 생성된 PV만 사용
- hostPath에 비해 local은 수동으로 파드를 노드에 예약하지 않고, 내구성과 휴대성을 갖춘 방식을 사용
- PV의 nodeAffinity를 설정하여 볼륨의 노드 제약 조건을 인식
- PV는 nodeAffinity에 설정한대로 올바른 노드로 스케줄링함
- Node Affinity
- 로컬 볼륨에 대해서는 노드를 명시적으로 설정
- 볼륨에 접근할 수 있는 노드를 제한하는 제약 조건을 정의할 수 있음
- PV를 사용하는 파드는 Node affinity에 의해 선택된 노드로만 스케줄링됨
- 로컬 볼륨에 대해서는 노드를 명시적으로 설정
- hostpath
- 네트워크 볼륨
- iSCSI
- iSCSI (SCSI over IP) 볼륨을 파드에 마운트
- 파드 제거시 iscsi볼륨은 유지되고, 볼륨은 마운트 해제
- NFS
- 네트워크 파일 시스템과 마운트
- cephFS
- CephFS 볼륨을 파드에 마운트
- glusterFS
- Glusterfs (오픈 소스 네트워크 파일시스템) 볼륨을 파드에 마운트
...
- Glusterfs (오픈 소스 네트워크 파일시스템) 볼륨을 파드에 마운트
- iSCSI
- 네트워크 볼륨 (클라우드 종속)
- gcePersistentDisk
- awsEBS
- azureFile
사용하기 위한 Lifecycle
1. Provisioning
- 정적 또는 동적인 pv를 생성하는 단계
- 정적 : 실제 pv를 정의하여 생성
- 동적 : client-provisioner를 통하는것으로, pvc 생성시 자동으로 pv가 생성
- 최초 PV 생성시 상태는 Available
- PV의 접근 모드
- ReadWriteOnce(RW0) : 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있음
- ReadOnlyMany(ROX) : 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있음
- ReadWriteMany(RWX) : 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있음
- Binding
- PV를 PVC에 연결시키는 단계
- PVC는 사용자가 요청하는 볼륨을 PV에 요청하고, PV는 그에 맞는 볼륨이 있으면 할당
- PVC와 PV는 1:1관계
- PVC와 PV가 연결시 상태는 Bound
- PVC는 Kubernetes상의 동일 Namespace의 Resource에서만 사용할 수 있다.
- Using
- Pod는 PVC를 볼륨으로 사용
- Pod가 사용중인 PVC를 삭제 하려고 하면 삭제되지 않음.
- Pod가 사용하지 않을때까지 삭제 요청은 연기
- Reclamiming
- PV는 기존에 사용했던 PVC가 아니라도 재활용 가능
- PVC를 삭제 할때, 사용했던 PV의 데이터를 어떻게 처리할지에 대한 설정이 필요함
- Retain : PV의 데이터를 그대로 보존
- PVC와 연결 해제시 Realesed 상태가 되어 남아 있게 됨
- 다른 PVC에 의해서 사용될 수 있는 상태가 아님
- 동일한 이름의 PV이름을 사용하고 싶으면 PV를 삭제 후 생성해야함
- PV가 삭제된 후에도 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산이 존재
- storageprovisioning으로 storage class로 nfs연동시 동일
- Delete : 사용이 종료되면 해당 볼륨을 삭제
- PVC와 연결 해제시 Realesed 상태가 되면, PV와 연결된 디스크 내부 데이터 자체를 삭제
- 주로 동적으로 PV를 생성 할때 사용됨
- StorageClass의 Reclaim Policy는 기본적으로 Delete로 설정
- pv가 삭제되면 AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산을 모두 삭제
- storageprovisioning으로 storage class로 nfs연동시 pv만 삭제, 스토리지는 archived-xxx로 남아 있음
- Failed(실패) : 볼륨이 자동 반환에 실패함
Recycle : 재사용하게될 경우 기존의 PV 데이터들을 모두 삭제 후 재사용
- Retain : PV의 데이터를 그대로 보존
사용예제
- PV 생성
apiVersion: v1
kind: PersistentVolume
metadata:
name: dev-pv
spec:
capacity:
storage: 2Gi # 사용할 용량을 2GB로 설정
volumeMode: Filesystem # 볼륨 사용대상
acceessModes: # Storage 특정 접근 모드 선택
- ReadWriteOnece
storageClassName: manual # 스토리지클래스에 맞는 PVC와 연결
persistentVolumeReclaimPolicy: Delete # 사용이 종료되면 볼륨 삭제
hostPath: # 노드에 저장되는 디렉토리 (각 노드마다)
path: /tmp/log_backup- PVC 생성
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dev-pvc
spec:
accessModes: # PV에서 정의한 접근 모드 선택
- ReadWriteOnce
volumeMode: Filesystem # PV에서 정의한 볼륨 사용대상
resources:
requests:
storage: 2Gi # 사용할 용량을 2GB로 설정 (PV에서 정의한것보다 작아야함)
storageClassName: manual- Deployment 생성
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-deployment
labels:
app: test-deployment
spec:
replicas: 1
selector:
matchLabels:
app: test-deployment
template:
metadata:
labels:
app: test-deployment
spec:
containers:
- name: test-deployment
image: nginx
ports:
- containerPort: 8080
volumeMounts: # 컨테이너 안에 Volume Mount되는 경로
- mountPath: "/var/log/test.log"
name: dev-volume
volumes: # 컨테이너에서 사용할 PVC Match
- name: dev-volume
persistentVolumeClaim:
claimName: dev-pvcPV의 acceessModes
- PersistentVolume는 리소스 공급자가 지원하는 방식으로 호스트에 마운트 할 수 있음
- 리소스 공급자는 서로 다른 기능을 가지며 각 PV의 액세스 모드는 해당 특정 볼륨에서 지원하는 특정 모드로 설정
- 예를 들어 NFS는 여러 읽기 / 쓰기 클라이언트를 지원할 수 있지만, 특정 NFS PV는 서버에서 읽기 전용으로 사용할 수도 있음
- PV는 특정 PV의 기능을 설명하는 자체 액세스 모드 세트로 셋팅 할수 있음
PVC, PV 매칭
- PVC에서 PV의 이름으로 직접 매칭 (아래 조건 만족시)
- accessModes는 PVC에서 요청한것보다 PV에서 더 많은 모드를 포함하거나 일치해야함
- PVC의 accessModes와 PV의 accessModes의 일치가 되어야하는데, 만약 PVC가 RWO를 요청하지만, 사용가능한 볼륨이 NFS PV(RW0 + ROX + RWX)인경우 RWO를 지원하기 때문에 해당 PV와 매칭됨
- storage 크기는 PVC에서 요청한거보다 PV가 크거나 같아야함
아래는 ReadWriteOnce, ReadOnlyMany두개를 지원하는 PVC, PV를 사용한 예로 initContainers에서는 readWrite를 사용하고, container에서는 readonly를 사용
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
labels:
app: my-app
spec:
replicas: 1
selector:
matchLabels:
app: debian
template:
metadata:
labels:
app: debian
spec:
containers:
- name: debian
image: debian
command: ['sh', '-c', 'sleep 3600']
volumeMounts:
- mountPath: "/mnt"
name: my-volume
readOnly: true
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: example-pvc-2
initContainers:
- name: init-myservice
image: busybox
command: ['sh', '-c', 'echo "Content of my file" > /mnt/my_file']
volumeMounts:
- mountPath: "/mnt"
name: my-volume
Fullstack developer