09. Kubernetes Volume 개념

클라우드/Kubernetes

09. Kubernetes Volume 개념

이쿠우우 2020. 8. 17. 18:59

Kubernetes Volume Object 개념

[kubernetes volume 관련 글 목록]
Kubernetes Volume Object 개념
Kubernetes Volume [Static Provisioning]

Kubernetes Volume [Dynamic Provisioning]

Kubernetes StatefulSet Controller

1. Kubernetes Volume 이란?

저장소와 관련된 Object.

Pod의 Container에서 접근하여 데이터를 저장할 수 있는 directory.

컨테이너는 기본적으로 상태가 없는(Stateless) 앱을 사용함.

앱의 특성에 따라서 컨테이너가 죽더라도 데이터가 사라지면 안 되고 보존되어야 하는 경우가 있음.

예) MySQL 같은 데이터베이스도 컨테이너가 내려가거나 재시작했다고 해서 데이터가 사라지면 안 됨.

그때 사용할 수 있는 게 Volume Object.

Volume을 사용하게 되면 컨테이너가 재시작을 하더라도 데이터가 사라지지 않고 유지됨.

Volume 은 Pod내의 컨테이너 간의 공유가 가능함.

호스트 디렉터리를 그대로 사용할 수도 있고

Amazon Elastic Block Store (EBS) 같은 스토리지를 동적으로 생성하여 사용할 수 도 있음.

Stateless란?

어떤 이유로 컨테이너가 죽었을 때 현재까지의 데이터가 사라진다는 것

Volume의 종류

[ 임시 디스크 (Temp Storage) ]

emptyDir

[ 내부 디스크 (Local Storage) ]

hostPath

local

[ 외부 디스크 (Network Stroage) ]

glusterFS

gitRepo (deprecated)

NFS

iscsi

gcePersistentDisk

vsphereVolume

azureDisk

azureFile

awsElasticBlockStore

FC (fibre channel)

등등이 있음

Volume Object는 컨테이너의 외장 디스크 역할을 함

Pod가 기동 할 때 디폴트로, 컨테이너마다 디스크를 생성해서 기동 되는데,

이 디스크의 경우에는 영구적이지 못함.

즉 컨테이너가 Restart 되거나 새로 배포될 때마다 로컬 디스크는

Pod 설정에 따라서 새롭게 정의돼서 배포되기 때문에,

디스크에 기록된 내용이 유실됨.

DataBase와 같이 영구적으로 파일을 저장해야 하는 경우에는

컨테이너 Restart/Create/Delete에 상관없이 파일을 영속적으로 저장해야 하는데,

이럴 때 사용하는 형태의 스토리지를 Volume이라고 함.

이때 예를 들어 비유를 하자면

외장 디스크 : PV
외장 디스크를 사용하기 위한 설정으로 PVC
PV, PVC라는 개념이 등장함

Kubernetes에서 사용하는 Volume 구조는 PV와 PVC 가 있음

[ PV, PVC와 Pod 구조 예시 그림 ]

PV (PersistentVolume)

PV는 Volume 자체를 의미

Kubernetes Cluster에서 관리되는 저장소로

Pod 하고는 별개로 관리되고 별도의 생명주기를 가지고 있어서

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

즉 실제 물리 디스크와 같은 의미.

시스템 관리자는 Volume Object를 사용하기 위해서 가장 먼저

실제 저장공간을 생성하고

이를 PV로 kubernetes에 등록해야 함

PV 특징

Cluster Storage의 일부

Cluster Node와 같은 리소스

Namespace에 속하지 않음

Pod와 독립적인 lifeCycle 가짐.

PV 생성 방법

PV 생성 예제 Yaml 파일

내부 디스크(Local Storage ) Type의 hostPath를 사용해서 만들어봄

[ pvTest.yaml ]

apiVersion: v1
kind: PersistentVolume # PV를 생성함을 명시
metadata:
  name: iksoon-pv-hostpah
  labels:
storage: iksoon-pv-test
spec:
capacity:
  storage: 5Gi
  accessModes:
- ReadWriteOnce
  volumeMode: Filesystem
  storageClassName: iksoon-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 : valume을 RAW 파일 시스템 형식으로 붙여서 사용하게 함
- block : Filesysetm이 없는 Block 장치와 연결될 때는 Block으로 설정

[storageClassName]

아래에서 설명할 Dynamic Provisioning 방식에 사용하는 옵션

(예제에서는 설명을 하기 위해 추가함).

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

[persistentVolumeReclaimPolicy]

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

(아래의 PV와 PVC의 LifeCycle 항목에서 자세히 설명함)

[hostPath]

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

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

hostpath이외에 상위 1.1 volume의 종류에 명시되어있는

다양한 종류의 저장공간을 설정해서 사용할 수 있음

hostPath Type이란?

Worker Node의 로컬 디스크 경로를 Pods에 마운트 해서 사용하는 방법
Worker Node 가 다수일 경우 랜덤 하게 특정 Worker Node의 로컬 디스크 경로를 사용함
주의할 점 중의 하나는 Pod가 재시작돼서 다른 Worker Node에서 기동 될 경우,
해당 Worker Node의 hostPath를 사용하기 때문에,
이전에 다른 Worker Node에서 사용한 hostPath의 파일 내용은 액세스가 불가능.

기초 개념 정리)

일반 파일 시스템

파일 시스템은 저장장치 내에서 데이터를 읽고 쓰기 위해 미리 정해진 약속을 뜻함
종류로는 FAT, NTFS 등이 있음

RAW 파일 시스템

위에서 설명한 일반 파일 시스템 종류에 해당하지 않는
이외의 파일 시스템을 RAW 파일 시스템이라 함.
포맷되지 않은 원시적인 하드디스크 드라이브 or 파티션을 뜻함

Block 장치

HDD/CD-ROM드라이브/메모리 영역 등의 주소 지정 가능한 기기를 뜻함
블록 장치는 개별 바이트 단위가 아닌 일정 크기(block) 단위로 접근하는 장치를 말하는 것으로
간단히 말하면 하드 디스크와 같은 대용량 저장 장치를 말함

PV 상태 설명

Available : PVC에서 사용할 수 있게 준비된 상태

Bound : 특정 PVC에 연결된 상태

Released : PVC는 삭제된 상태이고 PV는 아직 초기화되지 않은 상태

Failed : 자동 초기화가 실패한 상태

PVC (PersistentVolumeClaim)

PVC는 사용자가 PV에 하는 요청으로

PV를 추상화하여 개발자가 손쉽게 PV를 사용할 수 있도록 해주는 기능.

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

개발자는 Pod를 생성할 때 volume을 정의하고

이 볼륨 정의 부분에 물리적 디스크에 대한 특성을 정의하는 것이 아니라

PVC를 지정하여, 관리자가 생성한 PV와 연결.

Storage를 Pod에 직접 할당하는 게 아니라 중간에 PVC를 통해서 사용하기 때문에

Pod와 Storage 관리를 명확히 구분해서 할 수 있음

예)

가동 중인 Pod의 Storage를 변경하기 위해
pod 자체를 restat 혹은 재생성할 필요 없이
pod에 연결된 PVC만 수정하면
Pod와는 상관없이 PVC를 통해 Storage를 관리할 수 있음

PVC 특징

Storage에 대한 사용자의 요청

PV Resource 소비

특정 Size나 Access mode를 요청

PVC 생성 방법

PVC 생성 예제 Yaml 파일

[ pvcTest.yaml ]

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

[ 생성 결과 ]

PV와 PVC 가 연결되어서 상태가 Bound로 나오는 것을 확인할 수 있음

PV와 PVC의 LifeCycle

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

Provisioning

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

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

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

PV Provisioning을 만드는 방법으로는 정적(Static)과 동적(Dynamic) 방법이 있음.

Static Provisioning

특정 용량을 가진 PV를 미리 생성해두고 요청이 있을 시

미리 생성한 PV를 할당하여 사용하는 방법.

Storage 용량에 제한이 있을 때 사용됨.

주의)

100TB 용량의 디스크 공간( Storage )이 있더라도
관리자가 미리 만들어놓은 PV의 용량이 100GB로 설정되어 있는 상태라면
사용자가 PVC로 150GB를 사용하겠다 하면 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를 이용하여 설정 가능.

이를 Reclaining이라 함.

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

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

Delete

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

외부 Storage의 Volume 도 삭제함.

예) 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에서 지원이 어렵다고 하여 사용하고 있지 않은 상태.

외부 Storagae 란?

상위에 있는 [1.1. Volume 종류] 부분에서 설명하는 Network 디스크에 해당.

StorageClass

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

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

그 방법이 바로 StorageClass 임.

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

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

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

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

Volume object 그림 설명

Static Provisioning 과정

1. 인프라 관리자가 사용할 수 있는 Storage에 해당하는 PV를 생성

예제에서는 HostPah, NFS와 public cloud GCP, AWS, Azure의 Storage를 사용할 수 있는 상태.

2개의 PV 생성

[ Local Storage와 Public Cloud Storage의 Access mode에 대한 설명 ]

ReadWriteOnce(RWO) :

해당 PV는 하나의 Pod에만 마운트 되고 하나의 Pod에서만 읽고 쓰기가 가능.

ReadOnlyMany (ROM):

여러 개의 Pod에 마운트가 가능하며, 여러 개의 Pod에서 동시에 읽기가 가능. 쓰기는 불가능.

ReadWriteMany (RWM):

여러 개의 Pod에 마운트가 가능하고, 동시에 여러개의 Pod에서 읽기와 쓰기가 가능.

위와 같이 여러개의 모드가 있지만, 모든 디스크에 사용이 가능한 것은 아니고 디스크의 특성에 따라서 선택적으로 지원

하위 표에서 자세히 설명

[ Volume 종류 및 AccessMode 표 ]

참고: https://kubernetes.io/ko/docs/concepts/storage/volumes/#awselasticblockstore

Storage	Volume Plugin	ReadWriteOnce	ReadOnlyMany	ReadWriteMany
public Cloud	AWS ElasticBlockStore	O	X	X
	Azure File	O	O	O
	Azure Disk	O	X	X
	GCP gcePersistentDisk	O	O	X
On-Premise Cloud	StorageOS	O	X	X
	VsphereVolume	O	X	X
	Glusterfs	O	O	O
	CephFS	O	O	O
	NFS	O	O	O
Kubernetes	HostPath	O	X	X
Kubernetes	emptyDir	O	X	X

2. 개발자가 Volume Object를 사용하기 위해 PVC 생성

특정 조건의 PVC를 생성하면

해당 PVC 조건에 맞는 PV를 kubernetes 가 자동으로 찾아서 매칭 시켜줌

[ 그림의 PVC 1의 경우 ]

PVC 1의 경우 조건에 맞는 PV 1 이 있어서 이를 kubernetes 자동으로 매칭 시켜주어

Status 상태가 정상적으로 Bound 가 됨

[ 그림의 PVC 2의 경우 ]

PVC 2의 경우 Storage 1TB 조건에 맞는 PV가 없음

Status 상태가 Pending 됨

PV 가 없음으로 조건에 맞는 PV가 생성될 때까지 무한히 Pending 상태로 대기하게 됨

조건에 맞는 PV 가 생성될 시 kubernetes 가 자동으로 연결시켜주며 Bound 상태가 될 것임.

[참고) 만약 PVC 1에서 Storage를 50G를 요청했다면?]
50G로 설정했다면 매칭되는 용량이 완전히 매칭되는 PV는 없고
50G가 보다 여유로운 100G인 PV1이 존재하고 있음.
이런 경우 PVC1이 PV1과 매칭되어
PVC1 이 50G 사용 가능으로 설정되지 않고
1G 사용 가능으로 설정됨.

3. Pod에 Volume Object로 PVC 연결

[ 그림의 Pod 1의 경우 ]

Pod 1의 경우 정상적으로 Bound 된 PVC 1 Volume Object를 사용했으므로

PVC 스펙에 해당하는 Volume을 사용할 수 있음

Pod Status 상태가 정상적으로 Running 됨

[ 그림의 Pod 2의 경우 ]

Pod 2의 경우 Pending 상태로 PV 가 생성되기를 기다리는 중인 PVC 2 Volume Object를 사용했으므로

PVC 스펙에 해당하는 Volume을 사용할 수 없음

Pod Status 상태가 정상적으로 Pending으로 됨

PVC 가 없음으로 조건에 맞는 PVC가 생성될 때까지 Pod 2가 무한히 Pending 상태로 대기하게 됨

PVC 정상적으로 생성될 시 Pod가 Volume을 사용할 수 있게 되며 Running 상태가 될 것임.

Dynamic Provisioning

1. StorageClass Object를 생성

Dynamic Provisioning 방식으로 Volume을 사용하기 위해 StorageClass를 생성.

사용자가 원하는 조건으로 직접 생성할 수도 있지만

각 Public Cloud 사에서 kubernetes를 사용할 시

예) AWS의 EKS, GCP의 GKE

Default로 StorageClass 가 생성되어 있음

on-premise 환경의 경우 default StorageClass는 없음

아래 그림에서는 on-premise 환경에서

GCP와 연결되는 StroageClass를 생성함

2. 개발자가 원하는 조건의 PVC를 생성

개발자가 원하는 조건의 PVC를 생성.

PVC 에는 StorageClass 가 명시되어 있고

PVC와 StorageClass 가 연결되게 됨

3. PVC와 Storage 클래스 연결

PVC와 StorageClass가 연결되면

StorageClass는 PVC의 스펙에 맞는 PV를 생성하기 위해

provisioner 설정에 명시되어 있는 저장소와 연결됨

예제에서는 GCP임으로 GCP와 연결.

GCP에서 PVC 스펙과 동일한 Storage를 생성할 수 있는지 확인한 후

생성이 가능하면

StorageClass는 GCP를 사용해서 PVC 조건에 맞는 PV를 생성함

4. Pod에 Volume Object로 PVC 연결

Pod 생성할 경우 정상적으로 Bound 된 PVC Volume Object를 사용했으므로

PVC 스펙에 해당하는 Volume을 사용할 수 있음

Pod Status 상태가 정상적으로 Running 됨

제 글을 복사할 시 출처를 명시해주세요.
글에 오타, 오류가 있다면 댓글로 알려주세요! 바로 수정하겠습니다!

참고

https://tech.osci.kr/2019/04/15/71798599/

https://arisu1000.tistory.com/27849

https://bcho.tistory.com/1259

https://timewizhan.tistory.com/entry/Kubernetes-Volume

https://waspro.tistory.com/580

https://nirsa.tistory.com/157

https://gruuuuu.github.io/cloud/k8s-volume/#

볼륨 종류

https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes

PV 참고

https://kubernetes.io/ko/docs/concepts/storage/persistent-volumes/

파일 시스템

https://ko.wikipedia.org/wiki/%ED%8C%8C%EC%9D%BC_%EC%8B%9C%EC%8A%A4%ED%85%9C

persistentVolumeReclaimPolicy 옵션 참고

https://zgundam.tistory.com/179

Dynamic Provisioning 참고

https://timewizhan.tistory.com/entry/Kubernetes-Storage-StorageClass

https://medium.com/@myte/kubernetes-nfs-and-dynamic-nfs-provisioning-97e2afb8b4a9

PV, PVC 그림으로 이해

https://kubetm.github.io/practice/intermediate/object-volume/

'클라우드 > Kubernetes' 카테고리의 다른 글

11. Kubernetes Secret (0)	2020.08.17
10. Kubernetes ConfigMap (0)	2020.08.17
08. Kubernetes Network (Ingress) (2)	2020.08.12
07. Kubernetes Network (LoadBalancer) (3)	2020.08.09
06. Kubernetes Network (ClusterIP, NodePort) (0)	2020.08.09

현재글09. Kubernetes Volume 개념

이쿠의 슬기로운 개발생활