쿠버네티스에서 PV, PVC를 이해하기 어려운 이유들
파드가 삭제되면 컨테이너 내부 파일도 함께 삭제되기 때문에 데이터를 영구적으로 보관하기 위해서는 PV, PVC를 생성해야 한다.
PV는 특정 워커 노드를 볼륨으로 사용하라는 속성(nodeAffinity)이 존재하고, PVC가 파드와 볼륨을 연결한다. 따라서 노드에 파일이 생성되고 파드가 삭제되었다가 재생성되어도 파일이 그대로 워커 노드에 보존된다.
참고로 워커 노드를 파일 저장소로 사용하는 방식은 지양하고 테스트 용도로만 사용해야 한다.
하지만 사실 이렇게 워커 노드 파일 시스템을 사용할 때는 파드의 hostPath 속성을 많이 사용하고 pv, pvc는 사용하지 않아도 된다.
이것이 PV, PVC를 이해하기 어려운 이유 "1. PV를 사용하는 것 자체가 불편하게 느껴짐."이다.
먼저 pvc에는 resource와 accessModes 속성이 존재한다. 이는 파드에서 사용할 수 있는 볼륨의 크기와 모드를 제한하기 위함이다. local PV를 사용하는 경우 리소스를 2GB로 제한하더라도 컨테이너 내부에서 2GB 이상으로, 워커 노드의 가용용량까지 저장할 수 있다.
또한 accessMode 역시 다른 속성으로 변경하더라도 한 곳에서만 연결이 되도록 하거나 여러 곳에서 연결이 되더라도 읽기 모드로 제한하여 동작하게 할 수 없다.
이것이 PV, PVC를 이해하기 어려운 이유 "2. PVC, PV를 위한 설정이 많지만 모두 동작하지 않는다."이다.
이러한 설정들은 사실 인터페이스로, 쿠버네티스에서 제공해주는 규격일 뿐 모두 볼륨들과 연결된 기능들이 아니다.
예를 들어 PV에 nfs 속성이 존재해 NFS 서버를 통해 볼륨과 연결될 수 있다.
하지만 NFS에는 디스크 제한 기능이 없어 pv의 capacity 속성을 2gb로 설정하더라도 이 속성을 동작시킬 수 없다. 이러한 속성들은 단순히 정보성의 기능이다.
NFS에는 acessMode 처럼 읽기 전용 모드, 한 곳에서만 읽기/쓰기 가능 등 기능이 있다. 하지만 이렇더라도 acessMode가 실제로 동작하지 않는다. 쿠버네티스에서 이 PV의 속성을 통해 NFS 볼륨과 연결하는 부분만 구현한 것이다. 실제로 NFS에 볼륨을 만들고 또 사용에 대한 권한까지 주는 기능을 만든 것이 아니라는 뜻.
이러한 내용들이 처음에 알기 어렵기 때문에 이 속성들이 왜 동작을 안하는지, 내가 잘못하고 있는건지 라는 생각이 들게한다.
실제 볼륨을 만들고 연결을 하기 위해서는 storageClass 리소스를 생성해야 한다. 해당 리소스로 여러가지 스토리지 솔루션을 컨트롤 할 수 있다. 지금까지는 PV를 명시적으로 생성하고 PVC를 생성하여 파드에 연결해주는 형태로 사용했다.
하지만 볼륨 솔루션을 사용할 때는 storageClass를 생성하고 PVC를 만들면 자동으로 PV가 만들어져 PVC와 연결된다.
사용자는 PVC만 생성하고 storageClass 이름만 지정해주면 되기 때문에 사용법이 더욱 간단하다.
하지만 storageClass의 종류가 많고, 각 솔루션 마다 사용방법이 다 다르다.
이것이 PV, PVC를 이해하기 어려운 이유 "3. 다양한 Volume 솔루션이 있어서 어떤걸 써야할지 막연함.", "4. 언제, 어떻게 사용해야 하는지에 대한 실무적인 유즈케이스를 모름."이다.
각 볼륨 솔루션을 어디서 어떤 케이스로 사용해야 하는지 알아야 한다.
Volume의 종류와 사용 목적에 대한 이해
블록 스토리지(Block Storage)
- 사용 구분: 하드 디스크(hdd, ssd, m2)
- 사용 방법: 물리적으로 장착 후 디스크처럼 사용
- 특징: 데이터 공유 불가, 처리 속도 빠름, 스토리지와 연결이 되어있는 상태
- 저장 구조: 고정 크기의 블록
파일 스토리지(File Storage)
- 사용 구분: 네트워크 공유 파일 시스템(NAS)
- 사용 방법: 네트워크 연결 후 내 디스크처럼 사용
- 특징: 처리 속도 (+@네트워크)가 블록 스토리지보다 느림. 스토리지와 연결이 되어있는 상태
- 저장 구조: 계층적 구조(디렉토리)
오브젝트 스토리지(Object Storage)
- 사용 구분: 스토리지 서비스
- 사용 방법: 서비스에 로그인 이후 API로 호출
- 특징: 디스크 확장이 용이해서 대규모 스토리지를 구축하는 데 사용.(youtube, github, docker hub)
- 저장 구조: 객체 단위로 저장
위 내용으로 3가지 타입의 스토리지, 즉 볼륨의 특징을 알아보았다. 몇가지 더 첨언하자면 다음과 같다.
블록 스토리지나 파일 스토리지는 연결이 되어있는 상태라서 디스크 공간을 확장하기 위해서는 메인보드에서 장착을 해제하거나 PC에서 연결을 끊은 후 저장 공간이 큰 스토리지로 교체해서 다시 연결해야한다. 이 때 기존 디스크의 파일을 복사해줘야 해서 번거롭다.
반면 오브젝트 스토리지는 스토리지 기술 자체가 여러 디스크에 분산해서 관리하고, 사용자와 디스크가 항상 연결되어있는 상태가 아니라 API를 호출해서 사용하는 형태이기 때문에 디스크가 아무리 늘어나도 사용자 입장에선 영향이 없다.
파일 스토리지의 경우 설치 파일이나 패키지를 다운받을 때 FTP를 이용한다. 서비스에 로그인 해야해서 오브젝트 스토리지와 특징이 똑같았다. FTP는 파일 스토리지에 있는 파일들을 원격에서 업로드/다운로드 받을 수 있게 만들어진 프로토콜이다. FTP를 사용하면 파일 스토리지와 오브젝트 스토리지의 차이가 거의 없어진다.
파일 스토리지는 기본적으로 연결해서 사용해야하고, FTP로 스토리지에 대한 활용이 넓어진 개념이다.
블록 스토리지도 PC에 네트워크를 연결하면 원격 사용이 가능해지며, 오브젝트 스토리지도 직접 연결하는 형태로 사용할 수 있긴 함.
쿠버네티스에서 Volume 구축 및 유즈케이스
볼륨 구축
- 테스트 용도로는 워커 노드 사용(hostPath)
- 기존 로컬 시스템에 구축된 볼륨이 있는 경우 해당 볼륨과 연결해서 사용. 이 솔루션들은 쿠버네티스 용도로 만들어진 경우가 많기 때문. 볼륨 솔루션 자체에는 여러 기능이 있을 수 있음. 쿠버네티스와 연결할 때는 제약적인 기능만 사용될 수 있다.
- 클라우드 서비스에 있는 볼륨 사용. 대체로 StorageClass를 지원하며 다양한 기능을 사용할 수 있다.
- 컨테이너 볼륨 솔루션 구축. 해당 워커 노드는 볼륨 전용 노드가 되는 것. 해당 노드에는 디스크를 많이 할당해주고 NodeSelector로 볼륨 노드, App 전용 노드를 구분해서 사용한다.
유즈 케이스
- 블록 스토리지
- 데이터베이스 (빠른 성능을 위한 데이터 저장 공간 필요)
- DB는 StatefulSet으로 배포. 이중화로 파드 두개를 만든다고 가정한다.
- 각 파드에 각각의 블록 스토리지 솔루션의 볼륨이 연결되어 데이터를 독립적으로 저장할 수 있도록 구성된다.
- Headless Service를 통해 한 쪽 파드만 사용한다.
- 데이터베이스 자체적으로 이중화를 위한 복제 기능을 제공한다.
- 따라서 쿠버네티스에서는 데이터베이스를 위해 헤드리스 서비스, StatefulSet, 블록 스토리지를 한 세트로 사용한다.
- 파일 스토리지
- 일반 app에서 사용 (이중화 시 데이터 공유를 위한 저장공간 필요)
- app은 deployment로 배포한다.
- app에는 db처럼 자체적인 데이터 이중화 기능이 없기 때문에, 모든 파드를 하나의 볼륨에 연결하여 관리한다.
- 프론트엔드 서버에서는 ClusterIP 타입의 서비스를 이용하여 모든 파드들에 API를 보내준다.
- 오브젝트 스토리지
- 일반 app에서 사용 (확장 가능한 대용량 저장 공간이 필요할 시 사용)
- 역시 deployment로 배포한다.
- 오브젝트 스토리지 솔루션에는 API를 받을 수 있는 서버기능과 볼륨이 존재한다. 파드에서 API를 보내 파일을 다운로드/업로드할 수 있다.
- 파일 스토리지와 같이 두 서버의 데이터 공유목적으로도 사용할 수 있지만 굳이..?
- Youtube, Github 처럼 대용량 저장 공간이 필요하고 계속해서 저장 공간이 늘어나야 하는 상황에서 오브젝트 스토리지를 사용하게 된다.
