Kubernetes - 볼륨 2부

PV와 PVC에 대해 알아보려고 한다.

관리자가 NFS 볼륨을 만들면

이를 에일리어싱한 PersistentVolume을 생성한다.

그러면 개발자 담당에서는 

pv-nfs와 연결된 pvc-nfs를 이용한다.

pv-nfs가 pvc-nfs에게 피자 한조각 씩 때준거라 생각을 하자

 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs 
spec:
  capacity:
    storage: 100Mi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 192.168.1.10
    path: /nfs_shared/pvc-vol

관리자가 생성하는 pv코드이다.

 

accessModes에 접근 모드가 3개 있다.

ReadWriteOnce : 하나의 노드에서만 볼륨을 읽고 쓸 수 있게 마운트

ReadOnlyMany : 여러 개의 노드가 읽도록 마운트

ReadWriteMany : 여러 개의 노드가 읽고 쓸 수 있도록 마운트

 

persistentVolumeReclaimPolicy는 반환 정책이다. 3개가 있다.

Retain(보존) : pvc 삭제 시에도 pv를 보존

Delete(삭제) : pvc 삭제 시에 pv를 함께 삭제

Recycle(재활용) : 더 이상 사용되지 않는다.

 

 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-nfs  
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Mi

개발자 영역인 pvc 코드이다.

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-pvc
  labels:
    app: deploy-pvc 
spec:
  replicas: 3
  selector:
    matchLabels:
      app: deploy-pvc
  template:
    metadata:
      labels:
        app: deploy-pvc
    spec:
      containers:
      - name: chk-log 
        image: sysnet4admin/chk-log
        volumeMounts:
        - name: pvc-vol
          mountPath: /audit
      volumes:
      - name: pvc-vol
        persistentVolumeClaim:
          claimName: pvc-nfs

디플로이먼트 코드이다.

해당 코드의 claimName의 이름과

pvc코드의 이름이 링크되어있다.

pvc 볼륨이 만들어지고 마운트 된다는 것을 알고 있자.

 

 

근데 무언가 이상하다.

pv와 pvc를 연결해 주는 부분이 없다.

이는 pvc 되지 않은 pv를 자동으로 바운딩된다.

 

이 부분 관련해서는 다음에 더 찾아보아야겠다.

 

#!/usr/bin/env bash
nfsdir=/nfs_shared/$1

if [ $# -eq 0 ]; then
  echo "usage: nfs-exporter.sh <name>"; exit 0
fi

if [[ ! -d /nfs_shared ]]; then
  mkdir /nfs_shared
fi

if [[ ! -d $nfsdir ]]; then
  mkdir -p $nfsdir
  echo "$nfsdir 192.168.1.0/24(rw,sync,no_root_squash)" >> /etc/exports
  if [[ $(systemctl is-enabled nfs) -eq "disabled" ]]; then
    systemctl enable nfs
  fi
    systemctl restart nfs
fi

먼저 해당 코드를 이용해 pvc-vol 디렉터리를 생성한다.

pv에서 claim 할 때 path가 pvc-vol이다.

 

 

이제 pv코드를 배포한다.

해당 명령어를 통해 확인 가능하다.

 

 

얘를 사용하기 위해서 pvc를 배포해 준다.

pvc를 확인해 보면 pv-nfs에 bound 되어있다.

즉 묶여있다.

 

pvc를 사용하기 위해 디플로이먼트를 어플라이 해본다.

 

배포하고 curl을 때리면 /audit에 log가 남아 있을 것이다.

다른 파드에 접속해도 같은 로그가 남아있다.

 

pv와 pvc를 배포해 보았지만

문제점이 있다.

피자를 한 조각 뺴가는게 아니라

pv 전체를 가져가는 것이었다.

또한 관리자는 요청이 생길 때마다 pv를 생성해야 하므로

효율성이 나쁘다.

이제 이를 보완할 수 있는

스토리지클래스에 대해 알아본다.

 

AWS 공식 홈페이지에서 가져왔다.

개발자가 PVC를 만들면 스토리지 클래스에 자원이 요청된다.

그럼 스토리지 클래스는 PV를 만들고 

PV와 PVC를 바인드 해준다.

 

 

이런 생태계를 보면

프로비저닝 -> 바인딩 -> 사용중 -> 반환

4단계의 생명주기를 가진다.

 

직접 PV와 PVC를 만들고 클레임 해주는걸

정적 프로비저닝이라 하고

PVC요청을 받으면 PV를 제공해 주는 것을 동적 프로비저닝이라 한다.

 

바인딩은 accessModes이고

반환은 persistentVolumeReclaimPolicy이다.

 

스토리지 클래스가 종류가 다양하지만

나는 쿠버네티스의 NFS Provisioner를 이용한다.

 

이제 원할 때 피자를 뜯어먹는 스토리지 클래스를 배포해 본다.

먼저 NFS프로비저너 디플로이먼트 코드를 본다.

 

우리가 보면 되는 곳은 빨간 줄이다.

nfs서버를 구성하면

주소와 경로가 필요한데

빨간색끼리 맞추어야 한다.

 

스토리지클래스 코드를 본다.

# Origin Source
# https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
# or choose another name, must match deployment's env PROVISIONER_NAME'
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner 
parameters:
  # waits for nfs.io/storage-path annotation, if not specified will accept as empty string.
  pathPattern: "${.PVC.namespace}/${.PVC.annotations.nfs.io/storage-path}" 
  onDelete: delete

따로 수정할 필요는 없다.

 

 

이제 개발자가 담당하는 PVC 코드를 본다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-dynamic  
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: managed-nfs-storage

스토리지클래스 이름은 아까 전에 배포했던 스토리지클래스 이름으로 해준다.

이제 pvc를 만들었으면????

 

디플로이먼트 코드에 pvc이름 즉 pvc-dynamic이름을 매칭만 시켜주면 끝난다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-pvc 
  labels:
    app: deploy-pvc 
spec:
  replicas: 3
  selector:
    matchLabels:
      app: deploy-pvc
  template:
    metadata:
      labels:
        app: deploy-pvc
    spec:
      containers:
      - name: chk-log 
        image: sysnet4admin/chk-log
        volumeMounts:
        - name: pvc-vol
          mountPath: /audit
      volumes:
      - name: pvc-vol
        persistentVolumeClaim:
          claimName: pvc-dynamic

클레임 네임을 보면 pvc-dynamic으로 매칭이 되어있다.

pvc-dynamic을 pvc-vol이라는 이름으로 audit에 저장된다.

 

 

실습을 위해

먼저 nfs 볼륨을 만든다.

 

 

다음 nfs-subdir-external-provisioner을 통째로 배포한다.

storageclass도 배포

잘 배포되었다.

 

 

이제 pvc를 클레임 해보자

persistentvolumeclaim-dynamic을 배포

 

pvc를 클레임 했는데

pv가 생성되어 있다.

제대로 스토리지클래스가 작동된다.

디플로이먼트를 어플라이 해본다.

 

curl을 때리고 log가 들어가 있다.

다른 파드도 동일하다.

 

이제 삭제할 때는

스토리지클래스는 냅두고 삭제를 진행해야 한다.

앞으로 계속 쓰게 된다.

 

 

마지막 볼륨클레임템플릿에 대해 알아보려고 한다.

먼저

스테이트풀셋과 헤드레스에 대해 다시 생각을 해본다.

스테이프풀셋은 파드에 hash값이 붙는 게 아닌

도메인에 인덱스가 붙어 나오는 방식이다.

기본 배포방법으로 파드를 배포했을 때

문제가 생기면 파드를 지워버리면 되지만

스테이트풀셋은 각각의 파드들이 각자의 역할이 있어

지워버리면 문제가 생길 수도 있다.

 

그러고 헤드레스는 노출방법 중에 하나인데

얘는 ip를 소진하지 않고

클러스터 내에 파드들을 연결시켜 주는 역할이다.

도메인으로 연결을 한다.

 

볼륨클레임템플릿은 각각의 파드에 매칭되는

볼륨을 생성할 수 있다.

 

코드를 본다.

 

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sts
spec:
  replicas: 3
  serviceName: sts-svc-domain #statefulset need it
  selector:
    matchLabels:
      app: sts
  template:
    metadata:
      labels:
        app: sts
    spec:
      containers:
      - name: chk-hn
        image: sysnet4admin/chk-hn
        volumeMounts:
        - name: each-sts-backup
          mountPath: /backup_data
  volumeClaimTemplates:
  - metadata:
      name: each-sts-backup
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "managed-nfs-storage"
      resources:
        requests:
          storage: 20Gi

스테이프풀셋에서 볼륨클레임템플릿을 만들기 위해서는

accssModes는 ReadWriteOnce가 필수이다.

자신만의 독립적인 공간에서 read, write를 할 수 있어야 한다.

볼륨 이름은 each-sts-backup으로 매칭을 시켜준다.

 

pv와 pvc가 3개씩 만들어진 것을 확인할 수가 있다.

 

다음 공부는 쿠버네티스 노드를 관리하는 방법이다.