[Docker] 퍼시스턴트 볼륨(PV)과 퍼시스턴트 볼륨 클레임(PVC)

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

9.1 로컬 볼륨 : hostPath, emptyDir

9.1.1 워커 노드의 로컬 디렉터리를 볼륨으로 사용 : hostPath

• 호스트의 디렉터리를 포드와 공유해 데이터를 저장
• 바람직하지 않은 방법임
  • 디플로이먼트의 포드에 장애가 생겨 다른 노드로 옮겨갔ㅇ르 경우 이전 노드에 저장된 데이터를 사용할 수 없음
  • 스케줄링을 이용해 특정 노드에만 포드를 배치하는 방법 사용할 수 있지만 호스트 서버에 장애가 생기면 데이터를 잃게 된다는 단점 존재
• 모든 노드에 배치해야 하는 특수한 포드의 경우 유용하게 사용 가능
  • 모니터링 툴

9.1.2 포드 내의 컨테이너 간 임시 데이터 공유: emptyDir

• 포드가 실행되는 도중에만 필요한 휘발성 데이터를 각 컨테이너가 함꼐 사용할 수 있도록 임시 저장 공간 생성
  • 데이터를 영속적으로 보존하지 않음
  • 비어있는 상태로 생성되고 포드가 삭제되면 저장되어 있던 데이터도 함께 삭제됨
• 한 컨테이너가 파일을 관리하고 한 컨테이너가 그 파일을 사용하는 경우에 유용하게 사용 가능

9.2 네트워크 볼륨

• 별도의 플러그인 설치없이 다양한 종류의 네트워크 볼륨을 포드에 마운트 할 수 있음
  • NFS, iSCSI, GlusterFS, Ceph, AWS-EBS, GCP-gcePersistentDisk
• 네트워크 볼륨의 위치는 특별히 정해진 것 없음
  • 네트워크로 접근할 수만 있으면 쿠버네티스 클러스터 내부, 외부 어느 곳에 존재해도 크게 상관 없음
  • 단 AWS의 EBS와 같은 클라우드에 종속적인 볼륨을 사용하려면 AWS에서 쿠버네티스 클러스터를 생성할 때 특정 클라우드를 위한 옵션이 별도로 설정돼 있어야 함

NFS를 네트워크 볼륨으로 사용하기

• 대부분의 운영체제에서 사용할 수 있는 네트워크 스토리지
• 여러 개의 클라이언트가 동시에 마운트해 사용할 수 있음
• 여러 개의 스토리지를 클러스터링하는 다른 솔루션에 비해 안정성이 떨어질 수는 있으나 하나의 서버만으로 간편하게 로컬 스토리지처럼 사용할 수 있다는 장점 있음
• NFS 서버와 NFS 클라이언트가 각각 필요
  • NFS 서버는 영속적인 데이터가 실제로 저장되는 네트워크 스토리지 서버
  • NFS 클라이언트는 워커 노드의 기능을 사용. 따로 준비 필요하지 않음
• 포드가 다른 노드로 옮겨가거나 포드를 재시작해도 삭제되지 않음

9.3 PV, PVC를 이용한 볼륨 관리

9.3.1 퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임을 사용하는 이유

• YAML 파일에 한 타입의 네트워크 볼륨을 명시하면 다른 타입을 명시하는 별도의 YAML파일을 여러 개 만들어서 배포해야함
• Persistent Volumn과 Persistent Volumn Claim이라는 오브젝트를 통해 포드가 볼륨의 세부적인 사항을 몰라도 볼륨을 사용할 수 있도록 추상화해줌
• 사용자가 디플로이먼트의 포드에 볼륨을 마운트해 사용하기 위한 과정
  1. 인프라 관리자가 네트워크 볼륨의 정보를 이용해 퍼시스턴트 볼륨 리소스를 미리 생성.
     • NFS나 iSCSI와 같은 스토리지 서버에 마운트하기 위한 엔드포인트 포함
  2. 사용자(개발자)는 포드를 정의하는 YAML 파일에 ‘이 포드는 데이터를 영속적으로 저장해야 하므로 마운트할 수 있는 외부 볼륨이 필요하다’라는 의미의 퍼시스턴트 볼륨 클레임 명시하고 해당 퍼시스턴트 볼륨 클레임 생성
  3. 쿠버네티스는 기존에 인프라 관리자가 생성해 뒀던 퍼시트턴트 볼륨의 속성과 사용자가 요청한 퍼시스턴트 볼륨 클레임의 요구 사항이 일치한다면 두 개의 리소스를 매핑시켜 바인드
     • 포드가 이 퍼시스턴트 볼륨 클레임을 사용함으로써 포드의 컨테이너 내부에 볼륨이 마운트 된 상태로 생성
• 사용자는 디플로이먼트의 YAML 파일에 볼륨의 상세한 스펙을 정의하지 않아도 됨
  • 이 디플로이먼트에 볼륨을 마운트할 수 있어야 한다는 의미의 퍼시스턴트 볼륨 클레임을 명시. 실제로 마운트 되는 볼륨이 무엇인지 알 필요 없음
• YAML 파일에도 볼륨정의가 필요없기 때문에 좀 더 보편적인 방식으로 작성 가능

9.3.2 퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임 사용하기

AWS에서 EBS를 퍼시스턴트 볼륨으로 사용하기

1. AWS에서 EBS 볼륨 생성. 볼륨 ID 기록
2. 1번에서 생성한 EBS 볼륨을 쿠버네티스 퍼시스턴트 볼륨으로 등록
   • awsElasticBlockStore 항목에 EBS의 볼륨 ID 명시
   • 볼륨의 읽기 및 쓰기 속성, 볼륨의 크기 별도 설정
3. 퍼시스턴트 볼륨 클레임을 먼저 정의해 생성
   • 원하는 볼륨의 조건 나열
4. 2번에서 생성한 퍼시스턴트 볼륨의 속성이 3번에서 생성한 퍼시스턴트 볼륨 클레임의 조건과 일치하기 때문에 두 리소스가 연결됨
   • 리소스 상태가 Bound 상태로 바뀜
5. 최종적으로 EBS 볼륨이 컨테이너 내부에 마운트됨

9.3.3 퍼시스턴트 볼륨을 선택하기 위한 조건 명시

• 퍼시스턴트 볼륨 클레임을 사용하면 실제로 볼륨의 상세 스펙을 알 필요는 없지만 사용하려의 볼륨이 애플리케이션에 필요한 최소조건을 맞출 필요는 있음
  • Accessmode나 볼륨의 크기 등

accessModes와 볼륨 크기, 스토리지클래스, 라벨 셀렉터를 이용한 퍼시스턴트 볼륨 선택

• accessModes: 볼륨에 대해 읽기 및 쓰기 작업이 가능한지, 여러 개의 인스턴스에 의해 마운트 될 수 있는지 등
  • ReadWriteOnce
  • ReadOnlyMany
  • ReadWriteMany
• 볼륨의 크기
• accessModes나 볼륨의 크기는 해당 볼륨의 메타데이터일 뿐 볼륨이 실제로 그러한 속성을 가지도록 강제하지 않음
• 스토리지 클래스나 라벨 셀렉터를 이용해 퍼시스턴트 볼륨의 선택을 좀 더 세분화 할 수 있음
  • 스토리지 클래스는 볼륨의 대표 속성을 나타냄
  • 퍼시스턴트 볼륨을 생성할 때 클래스를 설정하면 해당 클래스를 요청하는 퍼시스턴트 볼륨 클레임과 연결해 바인드
  • storageClassName을 별도로 YAML 파일에 명시하지 않으면 똑같이 스토리지 클래스가 설정되지 않은 퍼시스턴트 볼륨 또는 퍼시스턴트 볼륨 클레임과 매칭됨

9.3.4 퍼시스턴트 볼륨의 라이프사이클과 Reclaim Policy

• Available -> Bound -> Released
• Reclaim policy에 따라 Released된 후 퍼시스턴트 볼륨의 상태가 결정됨
  • Retain인 경우 퍼시스턴트 볼륨은 연결된 퍼시스턴트 볼륨 클레임을 삭제한 뒤에 Released 상태로 전환됨. 스토리지에 저장된 실제 데이터는 그대로 보존됨
  • Delete인 경우 퍼시스턴트 볼륨의 사용이 끝난 뒤에 자동으로 퍼시스턴트 볼륨이 삭제됨
  • Recycle은 Delete와 같지만 외부 스토리지 자체를 삭제하지 않는다는 점에서 다름. 쿠버네티스에서 deprecated됨.

9.3.5 StorageClass와 Dynamic Provisioning

• 다이나믹 프로비저닝: 퍼시스턴트 볼륨 클레임이 요구하는 조건과 일치하는 퍼시스턴트 볼륨이 존재하지 않는다면 자동으로 퍼시스턴트 볼륨과 외부 스토리지를 함꼐 프로비저닝하는 기능
  • 외부 스토리지를 미리 생성해 둘 필요가 없음
• 단계별 예시
  1. ‘fast’라는 이름의 스토리지 클래스에는 SDD를 생성하라는 설정을 ‘slow’라는 클래스에는 HDD를 생성하라는 설정을 미리 정의했다고 가정
  2. 퍼시스턴트 볼륨 클레임에 특정 스토리지 클래스를 명시해 생성. 하지만 AccessMode나 Capacity 등 조건과 일치하는 퍼시스턴트 볼륨이 존재하지 않는 상태.
  3. 조건에 일치하는 퍼시스턴트 볼륨을 새롭게 만들기 위해 스토리지 클래스에 정의된 속성에 따라서 외부 스토리지를 생성함.
  4. 새롭게 생성된 외부 스토리지는 쿠버네티스의 퍼시스턴트 볼륨으로 등록되고 퍼시스턴트 볼륨 클레임과 바인딩됨.
• 단, 다이나믹 프로비저닝은 모든 쿠버네티스 클러스터에서 범용적으로 사용할 수 있는 것은 아니고 다이나믹 프로비저닝 기능이 지원되는 스토리지 프로비저너가 미리 활성화 돼 있어야 함
• Reclaim Policy가 자동으로 Delete로 설정됨
  • Retain 정책을 사용하고 싶다면 스토리지 클래스를 정의하는 YAML 파일에 reclaimPolicy: Retain 명시하거나 kubectl edit 또는 patch 등의 명령어로 퍼시스턴트 볼륨의 속성을 직접 변경
• 다이나믹 프로비저닝을 사용할 떄 기본적으로 사용할 스토리지 클래스를 annotation을 추가해 설정 가능