Kubernetes 기초 - Storage(5)

1. Volumes
2. Persistent Volumes(PV)
3. Projected Volumes
4. Ephemeral Volumes
5. Storage Classes                 ←  오늘 볼 내용

---

5. Storage Classes

https://kubernetes.io/ko/docs/concepts/storage/storage-classes/

스토리지 클래스

 

https://kubernetes.io/ko/docs/concepts/storage/dynamic-provisioning/

동적 볼륨 프로비저닝

 

 

스토리지 클래스는 PV를 동적으로 프로비저닝하는데 필요한 일종의 템플릿과 같은 것이다.

 

기본적인 구조는 다음과 같다.

 

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain			# 선택사항 default : Delete
allowVolumeExpansion: true		# 선택사항 default : false
mountOptions:					# 선택사항
  - debug
volumeBindingMode: Immediate	# 선택사항 dafault : Immediate

 

프로비저너(provisioner)

스토리지 클래스에서 프로비저너(provisioner)는 반드시 지정해야 하며 PV 프로비저닝에 사용되는 볼륨 플러그인을 결정한다.

클라우드 프로바이더, 오픈 소스 스토리지 시스템 등 종류에 따라 다양한 프로비저너를 가지므로 공식 문서를 확인해보길 바란다.

 

리클레임 정책(reclaimPolicy)

Delete와 Retain이 있으며 설정하지 않으면 기본값으로 Delete가 포함된다.

자세한 내용은 PV 포스트에서 persistentVolumeReclaimPolicy으로 설명했으니 궁금한 분은 참고하면 알 수 있을 것이다.

스토리지 클래스에서 reclaimPolicy가 PV에서 persistentVolumeReclaimPolicy이므로 혼동할 필요가 없다.

스토리지 클래스가 곧 해당 템플릿대로 PV를 동적으로 프로비저닝하는 것이기 때문이다.

 

 

볼륨 확장 허용(allowVolumeExpansion)

말그대로 볼륨을 확장하도록 허용할 것인가 물어보는 것이다.

하지만 해당 기능으로 확장은 허용이 되지만 축소는 불가능하다.

 

 

마운트 옵션(mountOptions)

프로비저너에서 지정한 볼륨 플러그인에서 지원하는 경우에만 사용 가능하다.

만약 지원하지 않는데 스토리지 클래스에 기재가 되어있으면 프로비저닝은 실패한다.

마운트 옵션은 클래스 또는 PV에서 검증되지 않는다.

PV 마운트가 유효하지 않으면, 마운트가 실패하게 된다.

 

 

볼륨 바인딩 모드(volumeBindingMode)

볼륨 바인딩과 동적 프로비저닝의 시작 시기를 제어한다.

Immediate와 WaitForFirstConsumer 두가지 설정이 있으며 설정되어 있지 않으면, Immediate 모드가 기본으로 사용된다.

Immediate 모드는 PVC가 생성되면 볼륨 바인딩과 동적 프로비저닝이 즉시 발생하는 것을 나타낸다.

토폴로지 제약이 있고 클러스터의 모든 노드에서 전역적으로 접근할 수 없는 스토리지 백엔드의 경우, 파드의 스케줄링 요구 사항에 대한 지식 없이 PV가 바인딩되거나 프로비저닝된다.

이로 인해 스케줄되지 않은 파드가 발생할 수 있다.
클러스터 관리자는 WaitForFirstConsumer 모드를 지정해서 이 문제를 해결할 수 있는데 이 모드는 PVC를 사용하는 파드가 생성될 때까지 PV의 바인딩과 프로비저닝을 지연시킨다.

PV는 파드의 스케줄링 제약 조건에 의해 지정된 토폴로지에 따라 선택되거나 프로비전된다.

여기에는 리소스 요구 사항, 노드 셀렉터, 파드 어피니티(affinity)와 안티-어피니티(anti-affinity) 그리고 테인트(taint)와 톨러레이션(toleration)이 포함된다.

파드에서 노드 어피니티를 사용하는 경우 nodeName 필드로 노드를 명시적으로 지정하는 것은 피해야 한다.
이렇게 설정하면 스케줄러가 바이패스되고 PVC가 pending상태로 남게 된다.

대신 nodeSelector를 통해 레이블로 노드를 지정하는 방법을 사용하면 된다.

apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  nodeSelector:
    kubernetes.io/hostname: kube-01
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

 

 

 

사실 클라우드 환경을 사용하지 않는 경우에서는 보여줄 수 있는 실습이 거의 없다.

클라우드를 활용하지 않는 온프레미스의 경우 스토리지 클래스에 프로비저너를 no-provisioner로 설정해서 사용할 수는 있지만 PV가 동적으로 프로비저닝 되지는 않는다.

스토리지 클래스의 목적이 PV를 동적으로 프로비저닝하는 것이기에 사용 의미를 많이 잃어버리는 것이다.

나머지 내용은 공식 문서에서 확인하는 것이 나을 것이라 생각한다.

스토리지 클래스를 사용하는 범위를 특정 Zone으로 제한하는 allowedTopologies와 같은 설정도 있고 각 클라우드 프로바이더에서 제공하는 다양한 설정을 원하는대로 지정하여 프로비저닝할 수 있다.

 

예를 들어, AWS EBS의 경우 볼륨의 타입을 지정하는 io1, 볼륨의 크기 당 IOPS(입출력 작업 수) 비율을 나타내는 iopsPerGB, 파일 시스템 타입을 나타내는 fsType이 있다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "10"
  fsType: ext4

 

 

GCP PD의 경우도 아래와 같이 볼륨 타입을 지정하는 type, 파일 시스템 타입을 지정하는 fstype, 디스크의 데이터를 어떻게 복제할 지 지정하는 replication-type이 있다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
  fstype: ext4
  replication-type: none

 

 

Azure Disk의 경우는 SKU(Stock Keeping Unit)를 지정하는 skuName, 프로비저닝 될 위치를 지정하는 location, Azure Disk가 속할 스토리지 계정의 이름을 나타내는 storageAccount가 있다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/azure-disk
parameters:
  skuName: Standard_LRS
  location: eastus
  storageAccount: azure_storage_account_name

 

 

각 세부 설정은 모두 파라미터 필드 아래에 정의되며 각 프로비저너에 따라 다 다르다.

이외에도 NFS, OpenStack Cinde, Ceph RBD, vCP(VMware Cloud Provider)와 같은 다양한 프로비저너가 있으므로 해당 내용들은 공식 문서를 통해 확인하길 바란다.