본문 바로가기

프로그래밍/컴퓨터 서적 리뷰 & After Service

가상머신 Kubernetes 환경에서 NFS를 이용한 PV, PVC 관리(feat. 시작하세요 도커/쿠버네티스)

책의 9장에서 퍼시스턴트 볼륨(PV)와 퍼시스턴트 볼륨 클레임(PVC)를 이용하는 부분에 대한 설명이 있는데 9.3 절에서 본격적으로 PV와 PVC에 대한 설명을 하고 있다. 그러나 문제는 이 설명을 위해 사용하는 실습방법이 AWS의 EBS를 이용한 방법이어서 나 같이 AWS를 이용하지 않을 경우 실습하는 방법에 문제가 발생하여서 이 부분을 해결하기 위해 NFS를 이용하는 PV와 PVC로 실습 방법을 바꾸어보았다. 저자의 블로그에 NFS를 이용하는 PV, PVC를 구축하는 방법이 있어서 책에서 구현한 예제를 블로그 글 및 쿠버네티스 공식 문서를 같이 보며 맞추었다. PV 문서 구조의 예제는 쿠버네티스 공식 문서에 있는 예제가 NFS여서 그걸 기본으로 했다. NFS Mount 옵션과 관련되어서는 이 글을 참조했으나 사실 의미가 무엇인지 파악하고자 한거라 옵션을 머 이리저리 다양하게 줘가며 테스트하지는 않았다. NFS 서버는 책에서 예제로 사용한 NFS Pod을 가지고 그대로 이용했다. 아래의 yml은 PV를 생성하기 위한 yml 이다.

 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 2Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  mountOptions:
    - hard
  nfs:
    path: /
    server: 10.104.175.113

 

yml의 각 항목에 대해서는 책에 설명이 있기 때문에 여기서는 차이가 나는 부분에 대해서만 얘기하도록 하겠다.

 

volumeMode는 책에는 없는 내용인데 이것은 kubernetes 1.18 에서 지원되는 항목이다. 공식문서에는 Filesystem 기반의 볼륨과 연결될때는 Filesystem, Filesystem이 없는 Block 장치와 연결될때는 Block 으로 설정하라고 되어 있다. 기본값은 Filesystem. 일단 책에는 없는 내용이라 설정을 한번 해보았다(1.18을 사용할 경우 해당되는 옵션인데 현재 내가 사용하는 k8s가 1.18이어서 써보았다) 책의 경우는 NFS가 아닌 EBS를 사용하고 있는데 EBS가 Elastic Block Store 인걸 보면 EBS로 PV를 만들경우 volumeMode를 Block으로 설정해야 하지 않을까 싶다(확실한건 아님)

 

persistentVolumeReclaimPolicy는 책에 설명되어 있는데 나는 Recycle을 써보았다. NFS를 이용할 경우 이 항목에는 Delete를 사용할 수 없기 때문에 Retain 아니면 Recycle 인데 단순하게 생각하면 Retain을 사용하면 PVC를 삭제하더라도 PV로 사용되는 NFS 서버에 마운트 된 내용은 지워지지 않지만 Recycle을 사용하게 되면 NFS 서버에 마운트 된 내용도 같이 지워지게 된다. 책에서 persistentVolumeReclainPolicy에 대한 설명을 하기 전까지는 이 항목을 사용하고 있지는 않은데 이 항목을 설정하지 않으면 기본이 Retain이다. 책에서는 Retain에 대한 예제는 나와있기 때문에 이 글에서는 Recycle로 설정했을 경우 어떤 결과가 나오는지를 설명하려 한다.

 

mountOptions 항목은 책에는 없는 내용인데 해당 볼륨이 mount 될 때 추가 옵션을 설정하는 것이다. NFS와 mount 되고 있기 때문에 hard 옵션을 주어 mount 되고 있다.

 

nfs.server 에서 가르키는 ip 주소는 책에서 예제로 사용한 NFS Pod과 연결된 Service의 IP 주소이다. 이제 이러한 정보를 기반으로 어떤 결과가 나오게 되는지는 아래 나열되는 그림에서 확인할 수 있다.(그림에서 사용된 k는 kubectl에 대한 alias 이다. alias k="kubectl" 을 실행시켜주면 실행 이후 k가 kubectl 명령어를 의미하게 된다)

 

[그림 1] NFS Server Pod이 올라와 있는 상태
[그림 2] NFS Pod과 연결되어 있는 Service인 nfs-service의 정보(위의 yml에서 nfs.server 항목에 입력한 ip인 10.104.175.113은 이 그림의 CLUSTER-IP 항목에서 가져온 것이다) 
[그림 3] 위의 yml을 이용해 생성한 PV의 정보. RECLAIM POLICY가 Recycle로 되어 있다

 

PV는 생성했으니 이제 PVC를 생성해보자. 다음의 yml은 이 pv를 사용하는 pvc와 그러한 pvc를 이용하는 pod을 생성하는 yml 이다

 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-nfs-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: nfs-mount-container
spec:
  containers:
  - name: nfs-mount-container
    image: busybox
    args: ["tail", "-f", "/dev/null"]
    volumeMounts:
    - name: nfs-volume
      mountPath: /mnt
  volumes:
  - name: nfs-volume
    persistentVolumeClaim:
      claimName: my-nfs-pvc

 

pvc가 생성될때 원하는 pv를 보면 저장공간이 2기가 이상에 accessMode가 ReadWriteOnce 로 되어 있는 것을 찾고 있다. pv를 생성할때 사용된 yml을 보면 이러한 조건을 만족하고 있다. 이제 이 yml을 이용해서 pod과 pvc를 생성하면 pod 정보와 pvc 정보가 다음과 같다.

 

[그림 4] 생성된 pvc와 이를 이용하는 pod의 정보

여기서 봐야 할 항목은 생성된 pod의 상세정보에서 노란색 박스가 쳐져 있는 부분이다. 첫번째 박스는 /mnt 디렉토리를 nfs-volume에 mount하고 있다는 내용이고 두번째 박으는 이러한 nfs-volume이 my-nfs-pvc 란 이름의 pvc를 사용한다는 것을 의미하는 것이다. 이러한 과정을 거치면 pv는 다음과 같이 바뀌게 된다.

 

[그림 5] PV의 변화된 정보

맨처음 PV를 생성했을때의 정보인 [그림 1]과 비교해보면 STATUS가 Available에서 Bound로, CLAIM이 default/my-nfs-pvc로 바뀐 것을 알 수 있다. 이렇게 NFS 서버를 이용한 PV와 이를 이용하는 PVC가 연결된 모습을 확인할 수 있게 되는데 이제 여기서 책에서는 언급이 안되어 있는, 즉 persistentVolumeReclaimPolicy를 Recycle로 설정한 PV를 이용하고 있는 PVC를 삭제했을 경우 PV는 과연 어떤 상황으로 바뀌는지 보도록 하자.

 

[그림 6] PVC를 삭제한 뒤의 PV의 변화

그림 6은 PVC를 삭제하기 전의 PV 정보와 삭제한 후의 PV정보를 한꺼번에 보여주고 있다. PVC인 default/my-nfs-pvc가 삭제되었기 때문에 STATUS가 Available로 바뀌게 된다. 여기서 약간 미묘한 차이가 있다. 책에서 언급한 EBS 기반의 PV는 Reclaim Policy를 Retain 으로 설정하면 PVC를 삭제해도 PV는 삭제가 안되며 STATUS가 Released로 바뀌며 Reclaim Policy를 Delete로 하면 PVC가 삭제될때 PV도 같이 삭제가 된다. 책에서도 언급됐듯이 EBS나 GCP의 영구 디스크는 동적으로 스토리지를 클라우드에서 할당받아 사용하는 개념이기 때문에 이를 삭제하면 클라우드에게 할당받은 공간을 되돌려주게 된다. 그래서 Reclaim Policy가 Delete로 설정하는 것이 가능하지만 NFS의 경우에는 내가 NFS 서버에 특정 용량을 할당받는것이 아니라 NFS 서버의 특정 디렉토리와 연결되는 개념이기 때문에 이러한 삭제개념을 사용할 수 없다. 그리고 EBS나 영구 디스크는 할당 받은 공간을 삭제할 경우 이를 다른 서비스가 바로 사용하는 것이 아니라 일단 할당 받은 공간을 클라우드가 받고 그 다음에 이를 필요로 하는 서비스에게 재할당 하는 개념이지만 NFS는 특정 디렉토리에 대한 연결이 끊어지더라도 이를 다른 서비스가 다시 연결해서 사용이 가능하기 때문에 Recycle 이란 설정이 가능한것이다. 대신 다른 서비스가 이용하게 되기 때문에 그 안에 있던 내용은 지워지게 되는 것이다. 외형적인 모습만 보면 내용이 삭제되기 때문에 EBS나 영구 디스크를 사용할때 쓰는 Delete 설정과 비슷하지만 그 이면을 좀더 들여다보면 이렇게 미묘한 차이가 있다(물론 내용을 남겨두는 Retain의 경우는 EBS나 영구 디스크, NFS 서버가 차이는 없다)