[k8s] Dynamic Provisioning을 통해 스토리지 리소스 자동으로 할당받기

프로비저닝(provisioning)이란?

쿠버네티스에서 프로비저닝은 일반적으로 저장소와 관련하여 특정 애플리케이션이나 서비스의 요구 사항을 충족시키기 위해 필요한 저장소 자원을 할당하고 구성하는 과정을 의미한다. 

 

쿠버네티스엔 2가지 유형의 프로비저닝이 있다. 

 

 

1. 정적 프로비저닝

정적 프로비저닝에서는 클러스터 관리자가 수동으로 Persistent Volume(PV)을 생성하며, 해당 PV의 용량, 액세스 모드 및 저장소 유형과 같은 하위 저장소의 세부 정보를 지정한다. 이러한 PV는 사용자가 생성하는 Persistent Volume Claim(PVC)에서 요청될 수 있다. 사용자가 PVC를 생성하면 쿠버네티스는 해당 PVC의 요구 사항과 일치하는 사용 가능한 PV에 바인딩한다. 

 

 

2. 동적 프로비저닝

동적 프로비저닝에서는 PVC요청에 대한 PV를 생성하는 과정을 자동화한다. 클러스터 관리자는 PV생성을 위한 템플릿인 StorageClass를 정의한다. 각 StorageClass는 PV를 생성하는 책임이 있는 프로비저너를 지정한다. 사용자가 특정 StorageClass를 참조하는 PVC를 생성하면 프로비저너는 PVC의 요구 사항과 일치하는 PV를 자동으로 생성하여 클러스터 관리자의 수동 개입을 없애준다. 

 

 

 

환경 구성

Dynamic Provisioning을 사용하기 위해서는 해당 기능을 지원하는 솔루션을 설치해야 한다. 

ex) STORAGEOS, NFS

 

설치를 완료하면 Service/Pod/Secret 등의 여러 Object가 생성된다. 

 

Dynamic Provisioning을 사용하면 PV를 미리 생성하는 것과 달리, 볼륨이 바로 생성 됩니다. PV를 미리 생성하는 방법은 Pod가 연결 될 때 Volume 이 생성된다. 

 

 

아래와 같이 default를 설정하면 PVC를 생성할 때 StorageClassName을 생략하면 default StorageClass가 적용이되어 동적으로 생성된다. 

 

 

 

StorageOS Operator 설치부터 해보자.

# 설치
kubectl apply -f https://github.com/storageos/cluster-operator/releases/download/1.5.0/storageos-operator.yaml

# 설치 확인 
kubectl get all -n storageos-operator

# Deployment 수정
kubectl edit deployments.apps storageos-cluster-operator -n storageos-operator

# spec.containers.env의 DISABLE_SCHEDULER_WEBHOOK의 Value를 true로 설정
spec:
  containers:
  - command:
    - cluster-operator
    env:
    - name: DISABLE_SCHEDULER_WEBHOOK
      value: "false"    # true 로 변경
    image: storageos/cluster-operator:1.5.0
    imagePullPolicy: IfNotPresent

 

 

관리 계정을 위한 Secret 생성 (username 및 password를 Base64문자로 만들기)

echo -n "admin" | base64
echo -n "1234" | base64

 

 

apiUsername 및 apiPassword 부분에 위 결과로 나온 문자 넣기

kubectl create -f - <<END
apiVersion: v1
kind: Secret
metadata:
  name: "storageos-api"
  namespace: "storageos-operator"
  labels:
    app: "storageos"
type: "kubernetes.io/storageos"
data:
  apiUsername: YWRtaW4=  # admin
  apiPassword: MTIzNA==  # 1234
END

 

 

Dashboard 접속을 위한 Service 수정

kubectl edit service storageos -n storageos

 

 

spec에 externalIPs와 Master IP 추가

spec:
  clusterIP: 10.109.77.121
  externalIPs:     # 추가
  - 192.168.0.30   # Master IP 추가
  ports:

 

 

접속

http://192.168.0.30:5705/

 

 

Default StorageClass 추가

kubectl apply -f - <<END
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: default
  annotations: 
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/storageos
parameters:
  adminSecretName: storageos-api
  adminSecretNamespace: storageos-operator
  fsType: ext4
  pool: default
END

 

StorageClass 확인

kubectl get storageclasses.storage.k8s.io

NAME                PROVISIONER               AGE
default (default)   kubernetes.io/storageos   3s
fast                kubernetes.io/storageos   59s

 

 

1. PersistentVolume (PV 2개 생성)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-hostpath1
spec:
  capacity:
    storage: 1G
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: /mnt/hostpath
    type: DirectoryOrCreate
    
--------------------
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-hostpath2
spec:
  capacity:
    storage: 2G
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: /mnt/hostpath
    type: DirectoryOrCreate

 

2. PersistentVolumeClaim (정적1개, 동적2개)

# 직접 연결
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-hostpath1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1G
  storageClassName: ""
----------------

# 동적 연결
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-fast1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1G
  storageClassName: "fast"
  --------------
  
# 동적 연결
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-default1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2G

 

위와 같이 오브젝트를 생성하면 아래와 같이 PV가 생성된다. 이때 상위 2개는 동적으로 만들어졌기 때문에 이미 노드에 실제 볼륨 디렉토리 생성됐지만, 네번째 경우엔 직접 연결했고 Pod에 연결되지 않았기 때문에 볼륨 디렉토리가 생성되지 않았다. 또한 동적으로 만든 경우 PV가 새로 생성된걸 확인할 수 있다. 

 

 

 

 

 

 

 

 

 

Status & ReclaimPolicy

Status는 최초 PV가 만들어졌을 때 Available 상태이고 PVC와 연결이 되면 Bound 상태로 변하게 된다.

 

 

PV 직접 만드는 경우엔 PV의 Status가 최초 Available이고, PVC와 연결된다면 PV의 Status는 Bound 상태가 된다. 하지만 PVC와 연결된다고 볼륨이 생성되는 것은 아니고, Pod가 PVC를 사용해서 구동이 될 때 실제 볼륨이 만들어 진다.

 

 

만약 이후에 Pod가 삭제될 경우 PV/PVC에는 아무 변화가 없고 Bound 상태가 유지 된다. 이 때 PVC를 삭제해야지만 PV와 연결이 끊어지면서 PV가 Released 상태가 됩니다.

PV와 실제 Data간의 연결에 문제가 생기는 경우 Failed 상태가 되기도 한다.

 

 

 

PVC가 삭제가 되는 경우 PV에 설정해 놓은 RecalimPolicy에 따라 PV의 상태가 달라지는데 Retain / Delete / Recycle 3가지가 있다.

• Retain: Default, 데이터 보존, 재사용 불가
• Delete: StorageClass를 사용하여 만들어진 볼륨의 Default 정책, Volume에 따라 데이터가 삭제되기도 안되기도 함,재사용 불가
• Recycle: Deprecated 된 옵션, 데이터 삭제, 재사용 가능