쿠버네티스 (4) - 볼륨

EmptyDir 볼륨

주로 다수의 컨테이너들끼리 데이터를 공유하기 위해서 볼륨을 사용하는 한다

apiVersion: v1
kind: Pod
metadata:
  name: pod-emptydir
  labels:
    app: nginx
spec:
  containers:
  - name: web-page
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: empty-directory

  - name: html-builder
    image: alpine
    volumeMounts:
    - mountPath: /html-dir
      name: empty-directory
    command: ["/bin/sh", "-c"]
    args:
      - echo "This page created on $(date +%Y-%m-%d)" > /html-dir/index.html;
        sleep infinity;

  volumes:
  - name: empty-directory
    emptyDir: {}

이 볼륨은 파드안에 생성되기 때문에 파드에 문제가 생겨 재생성되면 데이터가 없어지는 단점이있다.

볼륨에 쓰인 데이터는 꼭 일시적인 사용목적을 가져야 한다

HostPath 볼륨

각 워커노드를 Path기준으로 사용한다.
Empty볼륨과 차이점은 Pod가 죽어도 워커노드에 저장되있기때문에 데이터가 사라지지않는다는 장점이있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-hostpath
  labels:
    app: deploy-hostpath
spec:
  replicas: 3
  selector:
    matchLabels:
      app: deploy-hostpath 
  template:
    metadata:
      labels:
        app: deploy-hostpath 
    spec:
      containers:
      - name: host-mon
        image: sysnet4admin/sleepy
        volumeMounts:
        - mountPath: /host-log  
          name: hostpath-directory 
      volumes:
      - name: hostpath-directory 
        hostPath:
          path: /var/log

취약점: Deploy는 모든 노드마다 균등하게 분배된다는 보장이없다.
그걸 보완하기위해 Hostpath를 데몬셋에 입혀서 사용하는경우가 많다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ds-hostpath
  labels:
    app: ds-hostpath
spec:
  selector:
    matchLabels:
      app: ds-hostpath 
  template:
    metadata:
      labels:
        app: ds-hostpath 
    spec:
      containers:
      - name: host-mon
        image: sysnet4admin/sleepy
        volumeMounts:
        - mountPath: /host-log  
          name: hostpath-directory 
      volumes:
      - name: hostpath-directory 
        hostPath:
          path: /var/log

데몬셋은 한 노드에 한개씩으로 올가가기때문에 Hostpath가 균등하게 생성된다.
hostPath는 파드 자신이 할당되어 있는 노드의 데이터를 읽거나 쓸 때 사용함

PV,PVC 볼륨

퍼시스턴트볼륨 (PV)은 관리자가 프로비저닝하거나 스토리지 클래스를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다.

PV를 만드는 방법은 2가지가 있다.

정적(static) 프로비저닝:
클러스터 관리자가 미리 적정 용량의 PV를 만들어 두고 사용자의 요청이 있으면 미리 만들어둔 PV를 할당함. 사용할 수 있는 스토리지 용량에 제한이 있을 때 유용하다.

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

accessModes 옵션

• ReadWriteOnce: 하나의 노드에서만 볼륨을 읽고 쓸 수 있음
• ReadOnlyMany : 여러개의 노드가 읽기
• ReadWirteMany:여러개의 노드가 읽고 쓰기

persistentVolumeReclaimPolicy 옵션

• Retain : PVC삭제시에도 PV 보존
• Delete : PVC삭제시에 PV도 삭제

PV가 만들어졌으면 PVC로 해당 PV에 요청을 넣어야한다

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

---
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 

PV와 PVC의 매핑은 1대1 관계이다.. PVC 하나가 여러 개 PV에 할당될 수 없습니다.

스토리지 클래스(StorageClass)

PV와 PVC할당의 문제점: 사용자가 PVC를 사용하려면 관리자가 PV를 계속 준비해 놔야한다

동적으로 프로비저닝 할 때는 사용자가 PVC를 거쳐서 PV를 요청했을 때 생성해 제공함. 쿠버네티스 클러스터에 스토리지가 있다면 사용자가 원하는 용량만큼을 생성해서 사용할 수 있습니다. PVC는 동적 프로비저닝할 때 여러가지 스토리지 중 원하는 스토리지를 정의하는 스토리지 클래스(Storage Class)로 PV를 생성한다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: storageClass
  labels:
    app: nginx
spec:
  storageClassName: aws-EBS
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi