목차
- 들어가며
- PV, PCV 원리
- 퍼시스턴트볼륨(PV) 생성
- 퍼시스턴트볼륨클레임(PVC) 생성
- PVC, PV 조회
- 파드에서 퍼시스턴트볼륨클레임 사용
- PV, PCV 장점
- 퍼시스턴트볼륨 재사용
들어가며
지금까지 살펴본 모든 퍼시스턴트 볼륨 유형은 파드 개발자가 실제 네트워크 스토리지 인프라스트럭처에 관한 지식을 갖추고 있어야 합니다. NFS 기반의 볼륨을 생성하려면 개발자는 NFS 익스포트가 위치하는 실제 서버를 알아야 합니다. 이는 인프라스트럭처의 세부 사항 에 대한 걱정을 없애고, 클라우드 공급자나 온프레미스 데이터센터를 걸쳐 이식 가능한 애플리케이션을 만들고, 애플리케이션과 개발자로부터 실제 인프라스트럭처를 숨긴다는 쿠 버네티스의 기본 아이디어에 반합니다.
이상적으로는 쿠버네티스에 애플리케이션을 배포하는 개발자는 기저에 어떤 종류의 스토리지 기술이 사용되는지 알 필요가 없어야 하고, 동일한 방식으로 파드를 실행하기 위해 어떤 유형의 물리 서버가 사용되는지 알 필요가 없어야 합니다. 인프라스트럭처 관련 처리는 클러스터 관리자만의 영역이어야 합니다.
개발자가 애플리케이션을 위해 일정량의 퍼시스턴트 스토리지를 필요로 하면 쿠버네티스에 요청할 수 있어야 하고, 동일한 방식으로 파드 생성 시 CPU, 메모리와 다른 리소스를 요청할 수 있어야 합니다. 시스템 관리자는 클러스터를 구성해 애플리케이션이 요구한 것을 제공할 수 있어야 합니다.
PV, PCV 원리
인프라스트럭처의 세부 사항을 처리하지 않고 애플리케이션이 쿠버네티스 클러스터에 스토리지를 요청할 수 있도록 하기 위해 새로운 리소스 두 개가 도입됐습니다. 바로 퍼시스턴트 볼륨(PV, PersistentVolume)과 퍼시스턴트볼륨클레임(PVC, PersistentVolumeClaim)입니다. 이전 포스팅에서 살펴본 것과 같이 일반 쿠버네티스 볼륨도 영구적인 데이터를 저장하는 데 사용할 수 있기 때문에 이름에 오해의 소지가 있을 수 있습니다.
파드에서 퍼시스턴트볼륨을 사용하면 일반 파드 볼륨을 사용하는 것에 비해 조금 복잡 하므로 파드, 퍼시스턴트볼륨, 퍼시스턴트볼륨클레임과 실제 기반 스토리지가 어떻게 관 련되는지 다음 그림에서 살펴봅시다.
개발자가 파드에 기술적인 세부 사항을 기재한 볼륨을 추가하는 대신 클러스터 관리 자가 기반 스토리지를 설정하고 쿠버네티스 API 서버로 퍼시스턴트볼륨 리소스를 생성해 쿠버네티스에 등록합니다. 퍼시스턴트볼륨이 생성되면 관리자는 크기와 지원 가능한 접근 모드를 지정합니다.
클러스터 사용자가 파드에 퍼시스턴트 스토리지를 사용해야 하면 먼저 최소 크기와 필 요한 접근 모드를 명시한 퍼시스턴트볼륨클레임 매니페스트를 생성합니다. 그런 다음 사용 자는 퍼시스턴트볼륨클레임 매니페스트를 쿠버네티스 API 서버에 게시하고 쿠버네티스는 적절한 퍼시스턴트볼륨을 찾아 클레임에 볼륨을 바인딩합니다.
그런 다음 퍼시스턴트볼륨클레임은 파드 내부의 볼륨 중 하나로 사용될 수 있습니다. 퍼시스턴트 볼륨 클레임의 바인딩을 삭제해 릴리스될 때까지 다른 사용자는 동일한 퍼시스턴트 볼륨을 사용할 수 없습니다.
퍼시스턴트볼륨(PV) 생성
MongoDB 예제를 살펴보겠습니다. 이전과 달리 파드에서 직접 GCE 퍼시스턴트 볼륨을 참조하지 않습니다. 그 대신 여러분이 클러스터 관리자의 역할이라고 가정하고 GCE 퍼시스턴트 볼륨을 기반으로 한 퍼시스턴트 볼륨을 생성합니다. 그런 다음 애플리케이션 개발자의 역할이라 가정하고 퍼시스턴트볼륨을 클레임해서 이것을 파드에서 사용합니다.
gcePersistentDisk 퍼시스턴트볼륨 생성 매니패스트는 다음과 같습니다.
apiVersion: v1
kind: PersistentVolume
metadata:
name: mongodb-pv
spec:
capacity: > PersistentVolume 사이즈를 지정합니다.
storage: 1Gi
accessModes: > 이 PV는 단일 클라이언트의 읽기/쓰기용 (ReadWirteOnce)이나
- ReadWriteOnce 여러 클라이언트를 위한 읽기 전용(ReadOnlyMany)으로
- ReadOnlyMany 마운트됩니다.
persistentVolumeReclaimPolicy: Retain > 클레임이 해제된 후 퍼시스턴트볼륨은 이전에 퍼시스턴트볼륨은
gcePersistentDisk: 유지돼야 합니다 (지워지거나 삭제되면 안 됩니다).
pdName: mongodb > 생성한 GCE 퍼시스턴트 디스크를 기반으로 합니다.
fsType: ext4
퍼시스턴트볼륨을 생성할 때 관리자는 쿠버네티스에게 용량이 얼마가 되는지 단일 노드나 동시에 다수 노드에 읽기나 쓰기가 가능한지 여부를 알려야 합니다. 또한 쿠버네티스에게 퍼시스턴트볼륨이 해제되면 어떤 동작을 해야 할지 알려야 합니다(바인딩된 퍼시스턴트볼륨 클레임이 삭제되는 경우).
마지막으로 퍼시스턴트볼륨을 지원하는 실제 스토리지의 유형, 위치, 그 밖의 속성 정보를 지정해야 합니다. 자세히 살펴보면 마지막 부분은 앞서 파드 볼륨으로 GCE 퍼시스턴트 디스크를 직접 참조하는 것과 동일합니다. 이 예시는 다음과 같습니다.
spec:
volumes:
- name: mongodb-data
gcePersistentDisk:
pdName: mongodb
fsType: ext4
...
kubectl create 명령어로 퍼시스턴트볼륨을 생성하고 나면 클레임할 준비가 됐습니다. 어떤 퍼시스턴트볼륨이 있는지 조회해봅시다.
$ kubectl get pv
아직 퍼시스턴트볼륨클레임을 생성하지 않았으므로 퍼시스턴트볼륨이 Available로 표시됩니다. 참고로 퍼시스턴트볼륨은 특정 네임스페이스에 속하지 않습니다. 퍼시스턴트볼륨은 노드와 같은 클러스터 수준 리소스입니다.
퍼시스턴트볼륨클레임(PVC) 생성
이제 개발자 입장이 돼서 퍼시스턴트 스토리지가 필요한 파드를 배포해야 할 차례입니다. 이전에 생성한 퍼시스턴트볼륨을 사용할 것입니다. 하지만 파드 에 직접 사용할 수는 없고 클레임을 먼저 해야 합니다. 파드가 재스케줄링되더라도 동일한 퍼시스턴트볼륨클레임이 사용 가능한 상태로 유지되기를 원하므로 퍼시스턴트볼륨에 대한 클레임은 파드를 생성하는 것과 별개의 프로세스입니다
- 재스케줄링: 이전의 파드가 삭제되고 새로운 파드가 생성되는 것을 의미합니다.
이제 클레임을 생성합니다. 예제 6.11과 같이 퍼시스턴트볼륨클레임 매니페스트를 준비하고 kubectl create 명령으로 쿠버네티스 API에 게시합니다.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mongodb-pvc > 퍼시스턴트볼륨클레임의 이름으로 나중에 파드의 볼륨을 요청할 때 사용합니다.
spec:
resources:
requests: > 1GiB의 스토리지를 요청합니다.
storage: 1Gi
accessModes: > 단일 클라이언트를 지원하는 스토리지입니다(읽기/쓰기를 모두 수행합니다).
- ReadWriteOnce
storageClassName: "" > 이 부분은 이후 '동적 프로비저닝'에서 자세히 다루도록 하겠다는 뜻입니다.
퍼시스턴트볼륨클레임이 생성되자마자 쿠버네티스는 적절한 퍼시스턴트볼륨을 찾고 클레임에 바인딩합니다. 퍼시스턴트볼륨의 용량은 퍼시스턴트볼륨클레임의 요청을 수용할 만큼 충분히 커야 합니다. 추가로 볼륨 접근 모드는 클레임에서 요청한 접근 모드를 포함해 야 합니다. 이 경우 퍼시스턴트볼륨클레임은 1GiB의 스토리지와 ReadWriteOnce 접근 모드 를 요청합니다. 이전에 요청한 퍼시스턴트볼륨은 두 가지 요구 사항을 만족하므로 퍼시스턴 트볼륨클레임에 바인딩됩니다. 퍼시스턴트볼륨클레임을 검사해 이를 확인할 수 있습니다.
PVC, PV 조회
PVC(PersistentVolumeClaim)의 상태를 보기 위해 모든 퍼시스턴트볼륨클레임을 조회합니다. 명령어를 사용할 때 PersistentVolumeClaim의 약어인 PVC를 사용할 수 있습니다.
$ kubectl get pvc NAME
클레임이 퍼시스턴트볼륨 mongodb-pv에 Bound 됐습니다고 나올 것입니다. 다음은 접근 모드로 사 용되는 약어입니다. 이 때 RWO, ROX, RWX는 파드 수가 아닌 볼륨을 동시에 사용할 수 있는 워커 노드 수와 관련이 있습니다.
- RWO (ReadWriteOnce): 단일 노드만이 읽기/쓰기용으로 볼륨을 마운트할 수 있습니다.
- ROX (ReadOnlyMany): 다수 노드가 읽기용으로 볼륨을 마운트할 수 있습니다.
- RWX (ReadWriteMany): 다수 노드가 읽기/쓰기용으로 볼륨을 마운트할 수 있습니다.
kubectl get으로 확인해보면 퍼시스턴트볼륨이 Bound 상태가 돼 더 이상 Available로 표시되지 않습니다.
$ kubectl get pv
퍼시스턴트볼륨이 default/mongodb-pvc 클레임에 바인딩됨을 볼 수 있을 것입니다. 이 중 default 부분은 클레임이 있는 네임스페이스입니다(퍼시스턴트볼륨클레임을 default 네임스페이스에 생성했다). 퍼시스턴트볼륨은 클러스터 수준의 리소스이므로 특정 네임스페이스에 생성할 수 없습니다. 그리고 동일한 네임스페이스의 파드에서만 사용할 수 있습니다.
파드에서 퍼시스턴트볼륨클레임 사용
여기까지 진행했다면 퍼시스턴트볼륨을 사용 중에 있을 것입니다. 볼륨을 해제할 때까지 다른 사용자는 동일한 볼륨에 클레임을 할 수 없습니다. 파드 내부에서 볼륨을 사용하기 위해 다음과 같이 파드 볼륨에서 이름으로 퍼시스턴트볼륨클레임을 참조합니다.
apiVersion: v1
kind: Pod
metadata:
name: mongodb
spec:
containers:
- image: mongo
name: mongodb
volumeMounts:
- name: mongodb-data
mountPath: /data/db
ports:
- containerPort: 27017
protocol: TCP
volumes:
- name: mongodb-data
persistentVolumeClaim: > 파드 볼륨에서 이름으로 퍼시스턴트 볼륨클레임을 참조합니다.
claimName: mongodb-pvc
이제 파드가 실제로 동일 퍼시스턴트볼륨과 기반 GCE PD(Google Compute Engine Persistent Disk)를 사용하는지 확인해봅니다. 예제 다음 예시와 같이 MongoDB 셸을 다시 실행해보면 이전에 저장한 데이터를 확인할 수 있어야 합니다.
$ kubectl exec-it mongodb mongo
MongoDB shell version: 3.2.8
connecting to: mongodb://127.0.0.1:27017
Welcome to the MongoDB shell.
...
>use mystore
switched to db mystore
>db.foo.find()
{"_id" : ObjectId("57a61eb9de0cfd512374cc75"), "name" : "foo" }
이렇게 이전에 MongoDB에 저장한 도큐먼트를 가져올 수 있습니다.
PV, PVC 장점
다음 그림은 파드가 GCE 퍼시스턴트 디스크를 직접 사용하는 방법과 퍼시스턴트볼륨과 퍼 시스턴트볼륨클레임으로 사용하는 방법을 보여줍니다.
애플리케이션 개발자(또는 클러스터 사용자)에게 인프라스트럭처에서 스토리지를 가져오는 간접적인 방식을 사용하는 것이 얼마나 간단한지 생각해봅시다. 퍼시스턴트볼륨과 퍼시스턴트볼륨클레임을 생성하는 추가 절차가 필요한 것은 맞지만 개발자는 기저에 사용된 실제 스토리지 기술을 알 필요가 없습니다.
게다가 동일한 파드와 클레임 매니페스트는 인프라스트럭처와 관련된 어떤 것도 참조 하지 않으므로 이제 다른 쿠버네티스 클러스터에서도 사용할 수 있습니다. 클레임은 “x만큼의 스토리지가 필요하고 한 번에 하나의 클라이언트에서 읽기와 쓰기를 할 수 있어야 합니다"라 고 말합니다. 그러면 파드는 볼륨 중 하나에서 해당 클레임을 이름으로 참조합니다.
퍼시스턴트볼륨 재사용
퍼시스턴트볼륨에 관해 마무리하기 전에 마지막으로 간단한 실험을 하나 해보겠습니다. 파드와 퍼시스턴트볼륨클레임을 삭제합니다.
$ kubectl delete pod mongodb
pod "mongodb" deleted
$ kubectl delete pvc mongodb-pvc
persistentvolumeclaim "mongodb-pvc" deleted
퍼시스턴트볼륨클레임을 다시 생성한 후 $ kubectl get pvc 명령어로 확인하면 클레임의 상태가 Pending으로 표시됩니다. 이전에 클레임을 생성했을 때는 클레임은 즉시 퍼시스턴트볼륨에 바인딩됐는데 이번엔 바인딩되지 않는 이유는 퍼시스턴트 볼륨을 조회해보면 이해할 수 있습니다.
$ kubectl get pv NAME C mongodb-pv 1Gi
STATUS 열은 퍼시스턴트볼륨을 Released로 표시되고 이전과 같은 Available이 아닙니다. 이미 볼륨을 사용했기 때문에 데이터를 가지고 있으므로 클러스터 관리자가 볼륨을 완전히 비우지 않으면 새로운 클레임에 바인딩할 수 없습니다. 클러스터 관리지가 볼륨을 비우지 않았다면 동일한 퍼시스턴트볼륨을 사용하는 새 파드는 다른 클러스터나 네임스페이스에서 클레임과 파드가 생성되었다 할지라도 이전 파드가 저장한 데이터를 읽을 수 있습니다.
- 퍼시스턴트볼륨을 수동으로 다시 클레임하기
쿠버네티스에 persistentVolumeClaimPolicy를 Retain으로 설정하면 퍼시스턴트볼륨이 이러한 동작을 할 수 있습니다. 쿠버네티스가 클레임이 해제돼도 볼륨과 콘텐츠를 유지하도록 합니다. 퍼시스턴트볼륨을 수동으로 재사용할 수 있는 유일한 방법은 퍼시스턴트볼륨 리소 스를 삭제하고 다시 생성하는 것입니다. 이렇게 할 때 기반 스토리지의 파일을 어떻게 할지 결정해야 합니다. 삭제할 수도 있고 다음 파드에서 다시 사용하도록 남겨둘 수도 있습니다. - 퍼시스턴트볼륨을 자동으로 다시 클레임하기
스토리지 유럽 정의하기 지프스 다른 두 가지 리클레임 정책은 Recycle과 Delete다. Recycle은 볼륨의 콘텐츠를 삭제하 고 볼륨이 다시 클레임될 수 있도록 볼륨을 사용 가능하게 만듭니다. 이렇게 하면 퍼시스턴트볼륨은 여러 번 다른 퍼시스턴트볼륨클레임과 다른 파드에서 재사용할 수 있습니다.
반대로 Delete 정책은 기반 스토리지를 삭제합니다. Recycle 옵션은 현재 GCE 퍼시스 턴트 디스크에서 사용할 수 없습니다. 이 유형의 퍼시스턴트볼륨은 Retain과 Delete 정책만 지원합니다. 다른 퍼시스턴트볼륨 유형도 이들 옵션을 지원할 수도 있고, 지원하지 않을 수 도 있으므로 퍼시스턴트볼륨을 생성하기 전에 볼륨으로 사용하는 특정 기반 스토리지에서 어떤 리클레임 정책을 지원하는지 확인해야 합니다.
이 방식처럼 기존 퍼시스턴트볼륨의 리클레임 정책도 변경할 수 있습니다. 예를 들어 Delete로 초기 설정했을 경우 데이터의 손실을 방지하기 위해 Retain으로 쉽게 변경할 수 있습니다.
다만 한가지 주의할 것은 지금 공부중인 이 내용이 쓰이던 당시에는 recycle 정책이 유효했지만, 현재는 유지보수가 중단되었습니다. 따라서 이 내용을 적용하는 데 있어서 주의를 요합니다. 사담을 조금 더하자면 IT 업계는 점차 업그레이드 되는 속도가 빨라지는 것 같습니다. 하물며 이 속도를 감당할 수 없을 것 같다하여 전 세계에서 잠시 AI 개발을 6개월만 멈추자라는 이야기가 나왔을 정도니까요. 책을 쓰는데는 1년 정도가 걸린다고 합니다. 따라서 책으로 공부를 한다면 그 내용은 과거의 것으로 현재와 충분히 다룰 수 있습니다. 이를 유의하면 좋을 것 같습니다.
'Container > Kubernetes' 카테고리의 다른 글
| [Kubernetes] 1. 도커 컨테이너 명령줄(command line) 인자 설정법 (2) | 2023.04.16 |
|---|---|
| [Kubernetes Volume] 6. 프로비저닝(Provisioner)의 정의와 스토리지 클래스(StorageClass) (0) | 2023.04.15 |
| [Kubernetes Volume] 4. 퍼시스턴트 스토리지(Persistent storage)와 사용법 (2) | 2023.04.14 |
| [Kubernetes Volume] 3. 워커노드 파일 시스템로 파일 접근(hostPath) (0) | 2023.04.13 |
| [Kubernetes Volume] 2. 파드 내부 컨테이너간 데이터 공유(emptyDir, gitRepo) (0) | 2023.04.12 |