0부터 시작하는 Kubernetes 공부 - PV & PVC & ResourceQuota

namespace 삭제시, 해당 namespace 에 속한 모든 것이 삭제된다

1. PV 와 PVC 방식

Volume 의 필요성 & Storage 의 종류

Volume 의 필요성

Pod 에서 생성한 내용을 기록하고 보관하거나, 모든 Pod 가 동일한 동일한 설정 값을 유지하고, 관리하기 위해 공유된 Volume 으로부터 공통된 설정을 가지고 오게 하기 위해 외부 Storage 의 Volume 을 사용한다

Storage 의 종류

• file storage -> 디렉토리 ( ex. nfs ) - bind
• block storage -> 외부 스토리지의 볼륨을 disk 형태 ( ex. /dev/sd5 ) 로 가져온다 - mount
• object storage -> 사용자 별로 지정된 공간을 제공

PV 와 PVC 방식

p. 188

• 일반적인 Volume 제공 방법은 개발자가 요청을 하면, 운영자쪽에서 Volume 생성을 하고, 해당 Volume 을 개발자에게 mount 하라고 요청해서 개발자가 mount 해야 한다

• PV 와 PVC 를 사용하면, 개발자가 PVC 를 작성해서 Pool 에 보내면, Pool 에서 미리 준비된 PV 중에서 요청 사항에 맞는 PV 를 찾아 자동으로 해당 PV 를 PVC 에 Bound 시켜준다

  • Pool 에 저장된 PV 는 자신의 사양을 명시해야 한다. 이는 용량, 방식, multi access 가능 여부, 재사용 방식 등이 있다

Pod 에 PVC 를 넣어줘야 한다. 이때, Pod 의 Volume 선언 부분에 PVC 옵션을 넣어 사용할 PVC 이름을 지정해주면 된다. 이를 통해 Pod 와 PV 를 연결할 수 있다

• PVC 는 배포시, 요청 사항이 전달되어 PV 와 Bound 된 것이다. 이때 PVC 는 볼륨이 아니며 단순 명세서와 같은 것으로, Bound 시 연결된 PV 정보를 담고 있다. 이를 통해 Pod 에 PVC 를 넣어주면, Pod 는 PVC 와 Bound 된 PV 정보를 확인하고 Bind / Mount 된다

2. PV & PVC 구현 - NFS

PV 는 자원을 미리 준비해두는 것이므로, PV 를 만드는 것은 프로비저닝 이다. pvc 나 quota 는 배포이다

• network 나 volume 같은 자원을 준비하는 것은 배포가 아닌 프로비저닝 이다

yaml 생성

• PV, PVC 용 yaml 이 필요하고, 이를 활용하기 위한 deploy yaml 이 필요하다

  • PVC 는 deploy 에 넣어 사용한다. 즉, 개발자가 PVC, deploy 를 작성하고, 운영자가 PV 를 작성해야 한다

PV yaml 작성

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity: # pv capacity
    storage: 100Mi
  accessModes: #access mode
    - ReadWriteMany # != ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain # recycle policy
  nfs:
    server: 211.183.3.100
    path: /shared

• capacity : 용량
• accessModes : 다중 접속 허가 ( Many ) / 불허가 ( Once )
• persistentVolumeReclaimPolicy : PV 재사용에 대한 설정
• nfs : 방식

PVC yaml 작성

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

• spec 에 요청 사항을 작성한다

배포 및 확인

• 해당 디렉토리 안에 있는 모든 yaml 을 배포해주자. PV 는 프로비저닝 해주는 것이다
  
• pv 와 pvc 를 확인하자. pvc 요청 용량은 50Mi 지만, pv 의 용량은 100Mi 이다. 요청 사항과 pv 의 용량이 다르지만 Bound 가 되있다. 50Mi 를 요청했지만 100Mi 를 받은 것을 확인할 수 있다
  
• 반대로 pvc 의 request storage 를 200Mi 로 늘리면 pv 의 용량 이상으로 요청하면 bound 가 안된다

PVC 와 PV 가 용량을 제외한 모든 Spec 이 동일할 때, PV 의 용량보다 PVC 요청 용량이 작으면 Bound 가 되지만, PVC 요청 용량이 더 크면 Bound 가 안된다. 즉, PVC 에서 요청한 용량은 최소 용량인 것이다

• 이때 PVC 는 요청 용량을 보장 받으며, 그 이상의 용량도 사용할 수 있다. 그래서 50Mi 를 요청했는데 100Mi 라고 나온 것이다
• Nfs 에서 크기는 의미없다. 이러한 크기를 고정시키려면 Volume 을 사용해야 한다

PV 의 상태

• Available ( 독립적인 상태 )
• Bound ( 연결이 된 상태 )
• Release ( 연결이 되었다가 해제 된 상태 )

Deploy 배포 전 준비 사항

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

• PVC 의 요청 용량을 100Mi 로 지정하고, PV 와 PVC 를 배포해주자

mkdir /shared ; chmod 777 /shared
echo "jaehong" > /shared/index.html

• 공유할 디렉토리와 디렉토리 안에 파일 생성
  
• exports 설정 후 nfs-server 를 재시작 해주자

Deploy 배포 및 확인

apiVersion: apps/v1
kind: Deployment
metadata:
  name: testdeploy 
spec: 
  replicas: 3 
  selector: 
    matchLabels: 
      app: nginx 
  template: 
    metadata: 
      labels: 
        app: nginx 
    spec: 
      containers: 
      - name: testnginx 
        image: nginx 
        volumeMounts: 
        - name: pvpvc 
          mountPath: /usr/share/nginx/html 
      volumes: 
      - name: pvpvc 
        persistentVolumeClaim: 
          claimName: pvc

• 위와 같이 작성하자

  • volume 선언에 사용할 PVC 를 선언해주면 된다

• 배포해주자

root@manager:~/k8slab/pvpvclab# k exec testdeploy-7694f559b4-bvlgj -- cat /usr/share/nginx/html/index.html
jaehong

• Pod 에서 파일을 확인해보자. 잘 Bound 되었다

root@manager:~/k8slab/pvpvclab# k exec testdeploy-7694f559b4-bvlgj -- df -h
Filesystem             Size  Used Avail Use% Mounted on
overlay                 20G  9.1G  9.0G  51% /
tmpfs                   64M     0   64M   0% /dev
tmpfs                  971M     0  971M   0% /sys/fs/cgroup
/dev/sda5               20G  9.1G  9.0G  51% /etc/hosts
shm                     64M     0   64M   0% /dev/shm
211.183.3.100:/shared   20G  9.8G  8.4G  54% /usr/share/nginx/html
tmpfs                  971M   12K  971M   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                  971M     0  971M   0% /proc/acpi
tmpfs                  971M     0  971M   0% /proc/scsi
tmpfs                  971M     0  971M   0% /sys/firmware

• 디렉토리가 바인드 된 것을 확인할 수 있다

  • 우리는 PVC 로 100Mi 를 요청했지만, 20GB 로 나오고, 실제 사용 가능은 8.4 GB 라고 나온다. 이는 NFS 방식을 통해 실질적으로 디렉토리는 manager Node 에 있는 디렉토리 이기 때문이다. 이 20GB 는 Node 의 총 용량이다. 총 용량으로 나오는 이유는 manager Node 의 shared 디렉토리의 용량이 제한되지 않았기 때문이다
  • Overlay 환경이기에 Overlay 공유 자원도 나온다

3. ResourceQuota

quota & ResourceQuota

• 리눅스는 여러명의 사용자가 동시에 접속해서 사용할 수 있다. 이러한 사용자 별로 용량을 제한하기 위해 quota 를 사용할 수 있다

  • soft : 보장된 공간
  • hard : 최대 사용 가능 공간
  • grace time : hard 공간을 사용 가능한 시간이다. soft 이상의 공간을 사용시 최대 hard 에 정의한 용량만큼 사용할 수 있는데, 이 공간은 grace time 만큼 유지되며, grace time 이 끝나면 soft 초과 용량에 저장된 Data 는 삭제된다

• K8S 에서는 ResourceQuota 를 사용할 수 있다. 이때, hard 에 요청 가능한 PVC 수와 PVC 들의 용량 총 합을 제한하는 옵션이 있다

  • 이 ResourceQuota 는 Namespace 에 속한다
  • PVC 를 제한해야 한다. PVC 는 namespace 에 속하며, PV 는 namespace 에 속하지 않는다
  • ResourceQuota 는 soft 를 정의하지 않는다. hard 만 정의하여 제한한다

ResourceQuota 배포하기

apiVersion: v1
kind: ResourceQuota
metadata:
  name: testquota
spec:
  hard:
    persistentvolumeclaims: "5"
    requests.storage: "250Mi"

• 최대 claim 요청 가능 개수는 5 개이며, 이 PVC 들의 용량 합은 250Mi 로 제한된다. 이를 배포해주자
  
• 배포 후 다수의 PVC 를 배포해보았다. 두번째 PVC 까지는 아직 100 + 100 = 200 이므로 250 용량을 넘지 않으므로 배포가 되지만, 세번째 부터는 250 을 넘어서므로 오류가 나온다

StorageClass

• StorageClass 는 PV 와 PVC 를 일종의 그룹으로 묶는 역활을 한다

  • 이를 통해 배포한 PV 를 특정 사용자에게만 제공해줄 수 있다
  • StorageClass 에 PV 와 PVC 를 등록하면, 해당 PVC 에게만 PV 를 제공해준다

주로, 동적 프로비저닝에서 사용한다