[kubernetes] NFS 정적 프로비저닝 (PV, PVC)

이번 포스팅에서는 NFS를 이용한 정적 프로비저닝에 대하여 써보겠다. 

 

정적 프로비저닝이랑 PV 및 PVC리소스를 직접 생성하고 사용하는 방식이다. 

 

이전 포스팅에서는 직접 워커노드에 NFS서버를 설치하고 클라이언트 노드의 디렉터리와 마운트하는 방식으로 

스토리지를 공유했지만 정적 프로비저닝 방식을 사용하면 동일한 작업을 조금더 편하게 할 수 있다.

 

혹시 쿠버네티스의 스토리지 관리에 대하여 사전지식이 없다면 아래 링크에서 PV/PVC개념만 읽고오는 것을 추천한다.

[kubernetes] 쿠버네티스의 스토리지 관리

 

---

PV(Persistent Volume) 생성

• PV 생성하기

- PV파일을 생성하는 yaml파일을 만들어주고 실행시켜주자.

[root@master1 storage]# cat nfs-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: test-pv
spec:
  capacity: #용량
    storage: 1Gi # PersistentVolume(PV) 사이즈를 지정한다.
  accessModes:
    - ReadWriteMany #여러 클라이언트를 위한 읽기 쓰기 마운트
  nfs:
    server: 192.168.56.30 # nfs서버의 ip주소
    path: /nfs #nfs서버에서 공유한 디렉토리명


[root@master1 storage]# kubectl apply -f nfs-pv.yaml
persistentvolume/test-pv created

 

접근모드

RWO ( ReadWriteOnce ) : 단일 노드만이 읽기/쓰기용으로 보륨을 마운트 할 수 있다.

ROX ( ReadOnlyMany ) : 다수 노드가 읽기용으로 볼륨을 마운트할 수 있다.

RWX ( ReadWriteMany ): 다수 노드가 읽기/쓰기용으로 볼륨을 마운트할 수 있다.

 

• 생성한 PV 확인

1) persistentVolumeReclaimPolicy: Retain 기본 정책으로 설정됨 확인 , 클레임이 해제된 후 PV은 유지돼야 한다. (삭제되면 안 됨)

3) 아직 PVC를 생성하지 않았으므로 PV는 Available로 표시된다.

4) PV는 특정 네임스페이스에 속하지 않는다. PV는 노드와 같은 클러스터 수준 리소스이다.

 

 

 

---

PVC(Persistent Volume Claim) 생성

• PVC 생성하기 
• GKE, EKS 등을 사용하면 밴더(클라우드 공급자)의 default storage class가 자동으로 제공된다. 이를 고려하여 실행 파일을 만들어준다.

$cat nfs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc ##PVC의 이름으로 나중에 pod의 볼륨을 요청할 때 사용한다
spec:
  storageClassName: ""
  accessModes:
    - ReadWriteMany #ReadWriteMany(RWX) : 여러 개의 노드가 마운트 가능
  resources:
    requests:
      storage: 1Gi #1 GiB의 스토리지를 요청한다.



$ kubectl apply -f nfs-pvc.yaml
persistentvolumeclaim/test-pvc created


$kubectl get pv

-status가 bound로 변경된 것을 확인
-claim이 test-pvc로 변경되었다.



$kubectl get pvc

-bound 된 pvc확인 가능
-volume으로 test-pv를 사용하고 있다.

 

---

PVC(Persistent Volume Claim)를 사용하는 pod 생성

• pvc를 사용하는 pod를 여러 개 생성한 후 워커 노드에서 서로 데이터를 공유하는지 확인한다.
• 여러 개의 pod가 서로 pvc를 참조하여 같은 볼륨을 사용하고 있다.

$ cat nfs-pvc-pod.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test 1
spec:
  replicas: 12
  selector:
    matchLabels:
      app: test 1
  template:
    metadata:
      name: test 1
      labels:
        app: test 1
    spec:
      containers:
      - image: hewon16/image1:1 #실습에 사용하는 실습용 컨테이너 이미지 실제로는 본인이 사용할 이미지 사용
        name: test 1
        volumeMounts:
        - name: testpath
          mountPath: /mnt #컨테이너의 마운트 디렉터리
      volumes:
      - name : testpath
        persistentVolumeClaim:  #pod 볼륨에서 이름으로 PVC을 참조한다.
          claimName: test-pvc

 

$kubectl get pod -o wide 

NAME                     READY   STATUS    RESTARTS   AGE     IP               NODE      NOMINATED NODE   READINESS GATES

test1-7785bdc54c-22f6r   1/1     Running   0          3m47s   172.16.166.148   node1     <none>          

test1-7785bdc54c-b85g8   1/1     Running   0          10s     172.16.180.25    master2   <none>          

test1-7785bdc54c-l6qxd   1/1     Running   0          10s     172.16.136.55    master3   <none>          

....

 

 

• 워커노드에 배포된 파드에 연결하여 데이터 공유를 확인하자. (첫번째 파드)

# kubectl exec -it test1-7785bdc54c-22f6r -- /bin/sh

# ls /mnt
master2file1  master3file1  
master2file2  master3file2  

# touch /mnt/nfsfile1

# exit

 

• 워커노드에 배포된 파드에 연결하여 데이터 공유를 확인하자. (두번째 파드)

# kubectl exec -it test1-7785bdc54c-b85g8 -- /bin/sh

# ls /mnt

master2file1  master3file1  nfsfile1  

master2file2  master3file2  

# touch /mnt/nfsfile2

# ls /mnt

master2file1  master3file1  nfsfile1  

master2file2  master3file2  nfsfile2 

 

# exit

 

 

---

PV(Persistent Volume) 재사용

• PV를 재사용하여 새로운 클레임에 연결한다. 
• 기존에 사용했던 pod와 pvc를 삭제해준다. 
• 이후 pv의 상태를 확인한다. 

$kubectl get pv

NAME  CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM    STORAGECLASS   REASON   AGE
test-pv   1Gi               RWX               Retain           Released   default/test-pvc                               29m

=> pvc를 삭제했지만 pv 상태는 release와 claim에는 test-pvc에 대한 정보가 남아있다.
=> 중요: PV는 PVC와 이미 한번 바인딩된 정보가 있기 때문에 정보가 남아 있는것이다. 클러스터 관리자가 PV를 완전히 비우지 않으면 새로운 클레임에 바인딩 할 수 없다!

 

 

그럼 PV를 재사용할 수 있는 방법은 없는 것일까?

우리는 이러한 경우를 대비해서 Reclaimpolicy = "Retain"으로 설정해놓았다!

아래와 같은 순서로 기존의 PV를 재사용할 수 있다. 

 

1. 기존의 PV, PVC를 수동으로 삭제해주자.
$kubectl delete pv [pv명]
$kubectl delete pvc [pvc명]

2. 다시 새로운 PV, PVC 및 Pod를 생성해주자.

$kubectl apply -f nfs-pv.yaml
$kubectl apply -f nfs-pvc.yaml
$kubectl apply -f nfs-pvc-pod.yaml

3. 새 파드에 접속하여 기존 PV에 있는 데이터를 확인하자 
$Kubectl exec -it [pod 명] --/bin/sh 
# ls /mnt
# exit

 

정리

1.  persistentVolumeReclaimPolicy를 Retain으로 설정하면 클레임이 해제돼도 볼륨과 컨텐츠를 유지한다.

2.  퍼시스턴트볼륨을 수동으로 재사용할 수 있는 방법은 퍼시스턴트볼륨(PV) 리소스를 삭제하고 다시 생성하는 것이 유일한 방법이다.

3.  기반 스토리지 ( PD )의 파일을 삭제할지 남겨둘지 결정해야 한다. (RETAIN 말고 이외의 속성을 사용할지 말지)

 

 

리클레임 정책(persistentVolumeReclaimPolicy)

1.     Recycle 정책 : 볼륨의 콘텐츠를 삭제하고 볼륨이 다시 클레임될 수 있도록 볼륨을 사용 가능하게 만든다. PV는 여러 다른 PVC와 다른 POD에서 재사용할 수 있다. Recycle 반환 정책은 더 이상 사용하지 않는다.

 

2.     Delete 정책 :  기반 스토리지를 삭제한다. Delete 반환 정책을 지원하는 볼륨 플러그인의 경우 AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨 관련 스토리지 자산을 모두 삭제한다. 동적으로 프로비저닝된 볼륨은 스토리지클래스의 반환 정책을 상속하며 기본값은 Delete이다.

 

3.     Retain(보존): 퍼시스턴트볼륨클레임이 삭제되면 퍼시스턴트볼륨은 여전히 존재하며 볼륨은 "릴리스”된다.

볼륨을 수동으로 삭제하거나 동일한 볼륨을 재사용하려면 새 퍼시스턴트볼륨을 생성한다.