WHY?

지금까지의 디플로이먼트는 상태가 없는 APP
DB 처럼 데이터를 보유해야하는 상태가 필요한 APP의 데이터는 어떻게 관리해야 할까?
포드의 데이터를 영속적으로 저장하기 위한 방법이 필요
- Docker volume: 데이터를 보존하는 것이 가능하지만, 클러스터 환경에서 노드가 옮겨지면 데이터를 사용할 수 없게 됨
- 어느 노드에서도 접근할 수 있는 퍼시스턴트 볼륨을 사용하자

퍼시스턴트 볼륨(PV)

워커 노드들이 네트워크 상에서 스토리지를 마운트해 영속적으로 데이터를 저장할 수 있는 볼륨
장애가 생겨 포드가 다른 노드로 옮겨지더라도 PV에 연결해 데이터를 계속 사용할 수 있음

HostPath

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-pod
spec:
  containers:
    - name: my-container
      image: busybox
      args: [ "tail", "-f", "/dev/null" ]
      volumeMounts:
      - name: my-hostpath-volume
        mountPath: /etc/data # 1. 여기에 파일을 생성하면
  volumes:
    - name: my-hostpath-volume
      hostPath:
        path: /tmp # 2. (호스트의) 여기에 파일이 저장됨

다른 노드로 포드가 옮겨가면, 데이터를 사용할 수 없음
쓰지 말자.

emptyDir

한 컨테이너가 파일을 관리하고, 한 컨테이너가 그 파일을 사용하는 경우 유용


apiVersion: v1
kind: Pod
metadata:
name: emptydir-pod
spec:
containers:
- name: content-creator
image: alicek106/alpine-wget:latest
args: ["tail", "-f", "/dev/null"]
volumeMounts:
- name: my-emptydir-volume
  mountPath: /data   # 1. 이 컨테이너가 /data 에 파일을 생성하면

- name: apache-webserver
image: httpd:2
volumeMounts:
- name: my-emptydir-volume
  mountPath: /usr/local/apache2/htdocs/  # 2. 아파치 웹 서버에서 접근 가능

volumes:
- name: my-emptydir-volume
  emptyDir: {}   # 포드 내에서 파일을 공유하는 emptyDir

kubectl apply -f emptydir-pod.yaml

kubectl exec -it emptydir-pod -c content-creator sh

echo Hello World >> /data/test.html

kubectl describe pod emptydir-pod | grep IP

kubectlrun -i --tty --rm debug --image=alicek106/ubuntu:curl --restart=Never -- curl 10.1.0.7/test.html


### 네트워크 볼륨
#### NFS
- 네트워크 스토리지
- 여러개의 클라이언트가 동시에 마운트해서 사용 가능
- 우선은 임시로 쿠버네티스 클러스터 내부에서 NFS를 만들어서 사용해보자
#### NFS 서버 생성

kubectl apply -f nfs-deployment.yaml

kubectl apply -f nfs-service.yaml

#### NFS 서버의 볼륨 마운트
```YAML
apiVersion: v1
kind: Pod
metadata:
  name: nfs-pod
spec:
  containers:
    - name: nfs-mount-container
      image: busybox
      args: [ "tail", "-f", "/dev/null" ]
      volumeMounts:
      - name: nfs-volume
        mountPath: /mnt           # 포드 컨테이너 내부의 /mnt 디렉터리에 마운트합니다.
  volumes:
  - name : nfs-volume
    nfs:                            # NFS 서버의 볼륨을 포드의 컨테이너에 마운트합니다.
      path: /
      server: {NFS_SERVICE_IP}

# export NFS_CLUSTER_IP=$(kubectl get svc/nfs-service -o jsonpath='{.spec.clusterIP}')
# cat nfs-pod.yaml | sed "s/{NFS_SERVICE_IP}/$NFS_CLUSTER_IP/g" | kubectl apply -f -
# kubectl exec -it nfs-pod sh

# kubectl get pod nfs-pod -o yaml | kubectl replace --force -f-

퍼시스턴트 볼륨 클레임(PVC)

위에서는 포드의 YAML 파일 내부에, nfs를 사용한다는 정보를 명시
이럴 경우, 볼륨과 애플리케이션이 의존
퍼시스턴트 볼륨 클레임이라는 오브젝트를 통해 추상화, 포드가 볼륨의 세부 사항을 몰라도 사용할 수 있도록 해줌

EBS 볼륨 생성

머릿속에서 완성

퍼시스턴트 볼륨 생성

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ebs-pv
spec:
  capacity:
    storage: 5Gi         # 이 볼륨의 크기는 5G입니다.
  accessModes:
    - ReadWriteOnce    # 하나의 포드 (또는 인스턴스) 에 의해서만 마운트 될 수 있습니다.
  awsElasticBlockStore:
    fsType: ext4
    volumeID: <VOLUME_ID> # 머릿속의 볼륨 아이디

퍼시스턴트 볼륨 클레임 생성

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-ebs-pvc                  # 1. my-ebs-pvc라는 이름의 pvc 를 생성합니다.
spec:
  storageClassName: ""
  accessModes:
    - ReadWriteOnce       # 2.1 속성이 ReadWriteOnce인 퍼시스턴트 볼륨과 연결합니다.
  resources:
    requests:
      storage: 5Gi          # 2.2 볼륨 크기가 최소 5Gi인 퍼시스턴트 볼륨과 연결합니다.
---
apiVersion: v1
kind: Pod
metadata:
  name: ebs-mount-container
spec:
  containers:
    - name: ebs-mount-container
      image: busybox
      args: [ "tail", "-f", "/dev/null" ]
      volumeMounts:
      - name: ebs-volume
        mountPath: /mnt
  volumes:
  - name : ebs-volume
    persistentVolumeClaim:
      claimName: my-ebs-pvc    # 3. my-ebs-pvc라는 이름의 pvc를 사용합니다.

accessModes와 resources 모두 만족하는 퍼시스턴트 볼륨과 연결
요구 사항을 만족하는 PV가 없다면 Pending 상태 유지 => 조건 맞는 PV 새로 생기면 자동 연결

PVC 선택 조건

accessMode

accessMode		descrption
ReadWriteOnce	RWO	1:1 마운트 / 읽기 쓰기 가능
ReadOnlyMany	ROX	1:N 마운트 / 읽기 전용
ReadWriteMany	RWX	1:N 마운트 / 읽기 쓰기 가능

storage

주의 accessMode와 storage capacity 모두 메타데이터일 뿐, 볼륨이 해당 속성을 가지도록 강제하지 않음
라벨 개념으로 이해해야 함

storageClassName / label Selector

진짜 라벨들

LifeCycle

Available: 볼륨 생성 완료. 연결 X
Bound: PVC와 연결 완료. 다른 PVC와 연결 불가
Released: PVC가 제거되면 사용이 끝났다는 의미의 Released
- 재사용 불가
- 데이터는 볼륨 내부에 그대로 유지되기 때문에, PV를 삭제하고 재생성하면 다시 사용 가능
- Reclaim Policy 가 default로 retain이기 떄문!

Reclaim Policy

Retain: PV releaed 상태로 변경, 데이터 유지
Delete: PV 삭제, EBS 등의 외부 볼륨 함께 삭제
Recycle: PV의 데이터 전부 삭제하고 Available 상태로 변경

다이나믹 프로비저닝

위에서는, EBS를 미리 생성해두고, PV에 입력
매번 수동으로 스토리지 생성하고 연결하는건 귀찮
다이나믹 프로비저닝 : PVC가 요구하는 조건과 일치하는 PV가 없을 경우, 자동으로 PV와 외부 스토리지를 생성, 연결

storageClass

storageClass 생성

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: fast
provisioner: kubernetes.io/aws-ebs # EBS 동적 프로비저너
parameters:
type: gp2 # EBS 종류 설정
fsType: ext4
zones: ap-northeast-2a

위의 클래스를 사용하는 PVC 생성

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-fast-sc 
spec:
storageClassName: fast # 위에서 생성한 className 명시
accessModes:
- ReadWriteOnce
resources:
requests:
  storage: 1Gi

이전에 생성되어있는 PV 중, 조건을 만족하는 PV가 있다면 새로 생성하지 않고 해당 PV 연결
다이나믹 프로비저닝을 사용해 생성된 PV의 Reclaim Policy는 Delete

annotations를 이용하여 default 스토리지 클래스를 설정 가능

metadata:
name: generic
annotations:
storageclass.kubernetes.io/is-default-class: "true"
...

스토리지 클래스를 명시하지 않으면 default로 연결됨
- 따라서 다이나믹 프로비저닝을 사용하지 않으려면 명시적으로 storageClassName을 " "와 같이 공백으로 설정해두는 것이 안전

sangw0804 / study-docker

9. 퍼시스턴트 볼륨(PV)과 퍼시스턴트 볼륨 클레임(PVC) #9

WHY?

퍼시스턴트 볼륨(PV)

HostPath

emptyDir

kubectl apply -f emptydir-pod.yaml

kubectl exec -it emptydir-pod -c content-creator sh

echo Hello World >> /data/test.html

kubectl describe pod emptydir-pod | grep IP

kubectlrun -i --tty --rm debug --image=alicek106/ubuntu:curl --restart=Never -- curl 10.1.0.7/test.html

kubectl apply -f nfs-deployment.yaml

kubectl apply -f nfs-service.yaml

퍼시스턴트 볼륨 클레임(PVC)

EBS 볼륨 생성

퍼시스턴트 볼륨 생성

퍼시스턴트 볼륨 클레임 생성

PVC 선택 조건

accessMode

storage

storageClassName / label Selector

LifeCycle

Reclaim Policy

다이나믹 프로비저닝

storageClass