[Kubernetes] Object - Volume이란 (2)

[Kubernetes] Object - Volume이란 (2)DevOps/Kubernetes2022. 3. 28. 16:17@TTOII

Table of Contents

728x90

✔️ Network 볼륨 (Persistent Storage)

Pod 내부에서 특정 데이터를 보유해야 하는 stateful한(ex. DB) app의 경우 stateless한(Pod, deployment) 데이터를 영속적으로 저장하기 위한 방법이 필요하다.

Pod에서 실행 중인 어플리케이션이 디스크에 데이터를 유지해야하고 Pod가 다른 노드로 Rescheduling된 경우에도 동일한 데이터를 사용해야 한다면 Local Volume(emptyDir, hostPath volume)을 사용할 수 없다.

어떤 클러스터 노드에서도 접근할 수 있어야 하므로 NAS 유형의 스토리지에 저장이 되어야한다.

온프렘 환경에서도 구축할 수 있는 NFS, iSCSI, GlusterFS, Ceph 뿐 아니라 EBS, gcePersistentDisk와 같은 클라우드 플랫폼의 volume에 마운트할 수 있다.

따라서 네트워크 볼륨부터 PersistentVolume(PV)와 PersistentVolumeClaim(PVC)라는 개념이 도입된다.

✔️ 기반 스토리지 기술과 파드 분리

쿠버네티스는 인프라에 대한 복잡성을 추상화를 통해 간단하게 하고 개발자들이 손쉽게 필요한 인프라(컨테이너, 디스크, 네트워크)를 설정할 수 있도록 하는 개념을 가지고 있다.

즉, 쿠버네티스에 어플리케이션을 배포하는 개발자는 어떤 종류의 스토리지 기술이 사용되는지 알 필요가 없어야 한다.

개발자가 파드를 실행하기 위해 어떤 유형의 물리 서버가 사용되는지 알 필요가 없는 것과 마찬가지다.

이는 전적으로 클러스터 관리자만의 영역이어야 한다.

개발자가 파드를 실행할 때 CPU, 메모리와 다른 리소스를 요청할 수 있는 것 처럼 Persistent Storage를 필요로 하면 쿠버네티스에 요청할 수 있어야한다. 이를 해결하기 위해 Persistent Volume과 Persistent Claim 개념이 등장한다.

PV (Persistent Volume)

PV는 volume 자체를 의미한다.

Kubernetes Cluster에서 관리되는 저장소로 Pod와는 별개로 관리되고 별도의 생명주기를 가지고 있어

Pod가 재실행되더라도 PV 데이터는 정책에 따라 유지/삭제된다.

즉, 실제 물리 디스크와 같은 의미를 가진다.

시스템 관리자(admin)은 Volume Object를 사용하기 위해 가장 먼저 실제 저장공간을 생성하고 이를 PV로 kubernetes에 등록해야 한다.

개발자는 Pod를 생성할 때 볼륨을 정의하고 이 볼륨 정의 부분에 물리적 디스크에 대한 특성을 정의하는 것이 아닌 PVC를 지정하여 관리자가 생성한 PV와 연결한다.

시스템 관리자가 생성한 물리 디스크를 쿠버네티스 클러스터에 표현한 것이 PV이며, Pod의 볼륨과 이 PV를 연결하는 관계가 PVC가 된다.

이때 주의할 점은 볼륨은 생성된 후에 직접 삭제하지 않으면 삭제되지 않는다.

PV의 생명 주기는 쿠버네티스 클러스터에 의해 관리되며 Pod의 생성 또는 삭제에 상관없이 별도로 관리된다. (Pod와 상관없이 직접 생성, 삭제해야 함)

PV 특징

Cluster Storage의 일부

Cluster Node와 같은 리소스

Namespace에 속하지 않음

Pod와 독립적인 lifeCycle 가짐

PV 생성 방법

hostPath를 사용해 만든 예제 파일

apiVersion: v1
kind: PersistentVolume      # PV를 생성함을 명시
metadata:
  name: ssh-pv-hostpath
  labels:
    storage: ssh-pv-test
spec:
  capacity:             
    storage: 5Gi
  accessModes: 
  - ReadWriteOnce
  volumeMode: Filesystem  
  storageClassName: ssh-storage # 예제에서는 설명을 위해 추가함 
  persistentVolumeReclaimPolicy: Delete 
                   
  hostPath: 
    path: /volumeK8s

[storage]

용량을 지정 (Mi : 메가, Gi : 기가, Ti : 테라)

[accessModes]

volume의 읽기/쓰기에 관한 옵션을 지정한다.

volume은 한번에 하나의 accessModes만 설정 가능하다.

해당 옵션은 volume의 종류에 따라 설정 가능 여부가 결정된다.

ReadWriteOnce : 하나의 노드가 볼륨을 Read/Write 가능하도록 마운트
ReadOnlyMany : 여러개의 Node 또는 Pod가 Read 전용으로 시작하도록 마운트
ReadWriteMany : 여러개의 Node 또는 Pod가 Read/Write 가능하도록 마운트

[volumeMode]

kubernetes 1.8 버전에 알파 기능으로 추가된 옵션

filesystem : default 옵션으로 volume을 일반 파일시스템 형식으로 붙여서 사용하게 한다.
raw : volume을 RAW 파일시스템 형식으로 붙여서 사용하게 한다.
block : Filesystem이 없는 Block 장치와 연결될 때는 Block으로 설정한다.

[storageClassName]

Dynamic Provisioning 방식에 사용하는 옵션

storage의 Name을 명시 특정 StorageClass 가진 PV는 그 스토리지 클래스에 맞는 PVC 하고만 연결됨
PV에 storageClassName이 없으면 storageClassName이 없는 PVC에만 연결

[persistentVolumeReclaimPolicy]

PV 생명주기 중 Reclaim에 해당

Delete : 볼륨 사용이 종료되면 실제 디스크내용도 삭제, 스토리지를 할당 받은 경우 할당받은 공간도 해제
Recycle: 볼륨 사용이 종료되면 실제 디스크내용도 삭제, 스토리지를 할당 받은 경우 할당받은 공간은 유지
Retain : 볼륨 사용이 중지되도 유지함, PVC를 삭제해도 PV유지, 실제 디스크내용은 지워지지 않음. 관리자가 수동으로 삭제할 때까지 유지되도록 설정.

[hostPath]

PV Type 을 설정하는 부분 hostname은 노드에 저장되는 실제 저장 공간 설정하는 방법

해당 예제에서는 hostPath로 생성(로컬 디스크 사용)

hostpath이외에 상위 1.1 volume의 종류에 명시되어있는 다양한 종류의 저장공간을 설정해서 사용할 수 있음

PVC (Persistent Volume Claim)

PVC는 Pod의 볼륨과 PVC를 연결(binding)하는 관계 선언이다.

PVC는 사용자가 PV에 하는 요청으로 PV를 추상화해 개발자가 손쉽게 PV를 사용할 수 있도록 해주는 기능이다.

사용하고 싶은 용량은 얼마인지 읽기/쓰기는 어떤 모드로 설정하고 싶은지 등을 정해서 PV에게 전달하는 역할을 한다.

개발자는 Pod를 생성할 때 Volume을 정의하고 이 볼륨 정의 부분에 물리적 디스크에 대한 특성을 정의하는 것이 아닌 PVC를 지정해 관리자가 생성한 PV와 연결한다.

Storage를 Pod에 직접 할당하는 것이 아닌 중간에 PVC를 통해 사용하기 때문에 Pod와 Storage 관리를 명확히 구분할 수 있다.

예를 들어 가동 중인 Pod의 Storage를 변경하기 위해 Pod 자체를 재시작, 재생성 할 필요 없이 Pod에 연결된 PVC만 수정하면 Pod와 별개로 PVC를 통해 Storage를 관리할 수 있다.

PVC 특징

Storage에 대한 사용자의 요청

PV Resource 소비

특정 Size나 Access mode를 요청

PVC 생성 방법

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ssh-pvc-hostpath
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:         # PV 자원 중 어느 정도의 자원을 사용할 것인지 명시 
    requests:
      storage: 1Gi   # storage 설정이 1GB로 되어있는데 상위 PV에서 5GB가 할당되어 있음으로
                         # pvc에서는 pv storage 용량 이하로 설정해야 함
                         # 만약 더 큰 용량을 설정하면 STATUS가 Pending 상태로 남게 되고 생성이 안됨.
  storageClassName: ssh-storage
  selector:             # 예제 설명을 위해 추가. PVC는 PV를 selector를 통해 Label로 확인할 수도 있음
    matchLabels:     # selector를 사용하지 않고 storageClassName도 사용하지 않을 시
                          # PVC에서 설정한 스펙의 PV가 있는지 자동으로 탐지하여 PV와 연결됨
      storage: ssh-pv-test

✔️ PV와 PVC의 LifeCycle

PV와 PVC는 Provisioning-Binding-Using-Reclaiming 생명주기를 가지고 있다.

Provisioning

Volume Object를 사용하기 위해서는 가장 먼저 실제 저장할 수 있는 공간을 확보해야 한다.

저장 공간이 확보되면 PV가 해당 저장 공간을 바라보며 생성된다.

즉, Provisioning은 디스크 공간( Storgae )을 확보하여 PV를 만드는 단계에 해당된다.

PV Provisioning 방법으로는 정적(Static)과 동적(Dynamic) 방법이 있다.

Static Provisioning

특정 용량을 가진 PV를 미리 생성해두고 요청이 있을 시 미리 생성한 PV를 할당해 사용하는 방법이다.

미리 생성한 PV를 할당하여 사용하는 방법으로 Storage 용량에 제한이 있을 때 사용된다.

관리자가 미리 만들어놓은 PV의 용량과 일치해야만 PVC 생성에 성공한다.

Dynamic Provisioning

Dynamic Provisioning의 경우 kubernetes 1.6부터 생긴 기능이다.

사용자 요청이 있을 때 PV를 생성하여 할당하므로 사용자는 원하는 만큼의 용량을 생성해서 자유롭게 사용할 수 있다.

100TB 용량의 디스크 공간이( Storage ) 있으면 사용자가 필요할 때 해당 디스크 공간( Storage )에서 원하는 용량만큼을 생성해서 사용할 수 있다.

Dynamic Provisioning을 위해서 PVC는 StorageClasses를 사용해서 원하는 Storage에 PV를 생성한다.

Binding

상위의 Provisioning을 통해 만들어진 PV를 PVC와 연결(Binding)하는 단계

PVC의 요청에 맞는 Storage와 Access모드를 사용할 수 있는 PV를 찾았다면 PV를 PVC에 Binding 한다.

만약 PVC가 요청하는 PV가 없다면 해당 요청은 무한 대기하게 되고

추후에 PVC가 요청하는 스펙의 PV가 생성되면 그때 요청이 받아들여져 할당된다.

PV와 PVC의 매칭은 1:1 관계이며 하나의 PVC에 여러 개의 PV가 Binding 되는 건 불가능하다.

PVC와 PV 가 성공적으로 연결되면 bound 상태가 된다.

Using

pod는 PVC를 Volume object로 사용함.

kubernetes cluster는 PVC를 확인해서 Binding 된 PV를 찾고 해당 PV를 Pod에서 사용할 수 있도록 해줌

할당된 PVC는 Pod가 유지되는 동안 계속해서 사용됨.

Pod 가 사용 중인 PVC는 시스템에서 임의로 삭제할 수 없음.

이를 Storgae Object in Use Protection이라고 함

사용 중인 데이터를 임의의 로 삭제하면 치명적인 결과를 가져올 수 있어서

해당 보호 기능이 생김

Pod가 사용 중인 PVC를 삭제하려고 하면 상태가 Terminating으로 되지만

해당 PVC를 사용 중인 Pod가 남아 있는 도중에는 삭제되지 않고 남아 있게 됨.

Reclaiming

사용이 끝난 PVC가 삭제되면 PV는 회수되어 초기화 과정을 거치게 된다.

PV는 연결된 PVC가 삭제된 후 다시 다른 PVC에 의해서 재사용이 가능한데,

재사용 시에 디스크의 내용을 지울지 유지할지에 대한 정책을 Reclaim Policy를 이용하여 설정 가능하다.

이를 Reclaiming이라 한다.

회수된 PV는 설정에 따라 Delete, Retain, Recycle 3가지 상태를 가지게 된다.

PV 예제 .yaml에 있던 persistentVolumeReclaimPolicy 설정에 해당함

Delete

PV를 삭제하고 만약 외부 Storage와 연계되어 있었다면 외부 Storage의 Volume도 삭제한다.

ex) AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨까지 삭제됨

이렇게 되면 PVC가 삭제된 이후 PV도 사라지고 데이터도 사라진다.

Provisioning에서 동적으로 생성된 PV는 기본 Reclaiming 정책이 Delete 이므로 PV를 남겨두고 싶다면 옵션 수정이 필요하다.

Retain

PV를 보존한다.

PVC를 삭제하면 사용 중이던 PV는 해제 상태만 되고 사용했던 데이터가 그대로 남아있다.

예) AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨이 삭제되지 않고 남아있음

만약 외부 Storage와 연계되어 있었다면

외부 Storage의 Volume은 그대로 유지된다.

빈 PV가 아니기 때문에 아직 다른 PVC에 의해 재사용 가능한 상태는 아니므로

재사용을 하기 위해서는 아래의 3가지 방법 중 1개를 사용해야 한다.

1. PV를 삭제한다. 논리적인 할당이므로 물리적인 저장 공간과는 상관이 없음

2. 수동으로 PV안의 데이터를 직접 정리

3. 남아 있는 Storage을 삭제하거나 재사용하려면 해당 Volume을 사용하는 PV를 다시 생성

만약 Data를 유지한 상태로 다시 PV를 사용하기 위해서는

PV를 삭제한 다음 새로운 PV를 생성하면서 동일한 Storage 사용하게 해야 한다.

Recycle

PV에서 데이터를 삭제한 뒤 새로운 PVC에 사용할 수 있도록 준비함

예) 연결된 Storage에 rm -rf /* 명령을 내리고 다시 사용함

현재는 Kubernetes에서 지원이 어렵다고 하여 사용하고 있지 않은 상태

StorageClass

Static Provisioning 방법의 경우 관리자가 PV를 사용자로부터 요청을 받을 때마다 생성해줬어야 한다.

하지만 Kubernetes PV를 자동으로 생성할 수 있는 방법을 제공했는데

그 방법이 바로 StorageClass 이다.

즉, 관리자는 PV(PersistentVolume)을 여러 개 만드는 대신

Storage Object 를 정의 하여 사용하로 하여금 Storage Object를 사용하게 하는 것이다.

Static Provisioning 의 경우 PVC가 직접적으로 PV 를 바라봤다면

Dynamic Provisioning 의 경우 PVC가 StorageClass를 바라보도록 한다.

🔗출처

https://ikcoo.tistory.com/19