쿠버네티스 [볼륨]이란?

JACKJACK·2023년 1월 18일

📝쿠버네티스 볼륨이란?

파드안의 컨테이너들은 CPU, RAM, Network Interface는 공유하나, 파일시스템은 각각의 파드에 고유하게 분리되어있어 이를 공유해주는 개념.

볼륨은 파드의 구성요소로 파드가 시작될 때 생성되고, 파드가 삭제되면 경우 볼륨도 사라진다.

이전에 실행한 컨테이너에서 파일시스템의 어떤것도 볼 수 없다. 따라서 이전 컨테이너의 파일시스템을 유지하고 싶은 경우 쿠버네티스에선 스토리지 볼륨을 정의해 이 기능을 제공한다.
볼륨은 독립적인 쿠버네티스 오브젝트가 아니며 파드안에 내재되어 있으며, 자체 생성/삭제가 불가능하다.

다음과 같이 리눅스에서는 파일시스템을 파일 트리의 임의 경로에 마운트 할 수 있고, 마운트된 파일시스템 내용은 다른 마운트된 디렉토리에서 접근이 가능하다.

-> publicHTML 볼륨은 [WebServer 컨테이너의 /var/htdocs]와 [ContentAgent 컨테이너의 /var/html]에 다른경로로 마운트 된다. 이런 경우 콘텐츠 생성기가 작성한 내용을 웹 서버가 서비스 할 수 있다.

emptyDir: 비어있는 볼륨(일시적인 데이터를 저장하는 빈 디렉터리)
gitRepo: 깃 리포지터리의 콘텐츠를 체크아웃 해 초기화시킨 볼륨
hostPath: 워커 노드의 파일 시스템을 파드의 디렉터리로 마운트 하는데 사용
Persistent Storage -> 클라우드 스토리지를 사용해 영구적으로 스토리지를 사용할 수 있다.(ebs)
Persistent Volume, Persistent Volumn Claim -> 파드를 생성할 때마다 Persistent Storage를 만들어줄 수 없으므로 두가지 개념이 등장함 PV를 만들고 PVC가 PV를 찾아서 다른스토리지를 바인딩해줌
StorageClass(동적 프로비저닝) -> PVC 프로비저너가 있어서 PVC가 관리자의 스토리지클래스를 토대로 PV를 만들어줌.
AWS Elastic Block -> 클라우드 제공자의 전용 스토리지 마운트에 사용
ComfigMap도 볼륨의 종류이다.
등의 볼륨이 다양한 목적을 위해 사용된다.

emptyDir 가장 단순한 볼륨의 유형이며 다른 유형의 기반이 되는 볼륨이다.
emptyDir은 동일 파드에서 실행중인 컨테이너 간의 파일을 공유할 때 유용하다.(컨테이너에서 가용한 메모리에 넣기에 큰 임시 데이터 등) 다음은 emptyDir 볼륨 사용 예시이다.

-> 클라이언트가 파드의 포트80으로 보낸 HTTP요청은 fortune메세지를 응답으로 받음

gitRepo은 기본적으로 emptyDir 볼륨이며 파드가 시작되면(컨테이너가 생기기 전) 깃 리포지토리를 복제하고 특정 리비전(branch)을 체크아웃해 데이터로 채운다.
이 때 깃헙을 통해 HTML 파일을 변경했고 새로운 버전을 적용하고 싶다면 파드를 삭제하고 재 생성해야한다. 이러한 동기화를 하기 위해서는 사이드카 컨테이너를 실행시켜 동작을 보완해주면 된다. 주로 많이쓰는 이미지로는 "git sync"를 도커허브에서 확인할 수 있다.
앞으로 설명하는 emptyDir, gitRepo를 제외한 다른 볼륨들은 새 디렉터리를 생성하지 않고 기존에 존재하는 외부 디렉터리를 파드의 컨테이너 파일 시스템에 마운트한다.

대부분의 파드는 호스트 노드를 인식하지 못하며 노드의 파일시스템에 접근할 수 없도록 되어있다. 하지만 시스템 레벨의 파드는 노드의 파일을 읽거나 파일시스템에 접근해야하므로 쿠버네티스에서 hostPath 볼륨을 지원해준다.
hostPath 볼륨은 다음과 같이 노드의 특정 파일이나 디렉터리를 컨테이너의 파일시스템에 마운트시킨다.

파드에서 실행중인 애플리케이션이 디스크에 데이터를 유지해야하고 파드가 다른 노드로 스케줄링 되더라도 데이터를 유지시키기 위해 사용하는 개념이다.
다음과 같이 퍼시스턴트 스토리지(GCE의 퍼시스턴트 디스크 볼륨, AWS의 EBS를 파드의 볼륨)를 파드의 볼륨에 마운트 시킨다.

쿠버네티스는 GCE, AWS 외에도 다른 스토리지 기술들을 지원하는데, 쿠버네티스 API 레퍼런스나 kubectl explain을 통해 사용하기 위한 정보를 찾아 사용해야 한다. 하지만 개발자가 파드와 관련된 스토리지 세부사항을 매번 처리해줄 수 없고, 실제 기반 인프라스트럭처를 참고하는것은 좋지 않다. 때문에 이를 개선하기 위에 퍼시스턴트볼륨(pvc), 퍼시스턴트볼륨클레임(pvc)이 등장한다.
사용예시)
관리자가 기반 스토리지 설정 -> 쿠버네티스API pv디스크립터 게시 및 볼륨 생성 -> 사용자가 최소크기, 접근 모드 명시한 pvc 생성 -> pv가 부합하는 pv를 찾아 파드의 볼륨에 바인딩
pv와 pvc 생성에 쓰이는 yaml예시
백문이 불여일견이다. yaml 파일로 create 후에 kubectl get pv, kubectl get pvc로 확인이 가능하다.
옵션 accessModes 에는 RWO(ReadWriteOnce), ROX(ReadOnlyMany), RWX(ReadWriteMany)가 있으며 각각 단일 노드만 읽/쓰, 다수 노드 읽기만, 다수 노드 읽/쓰로 마운트할 수 있다. RWO일 경우 볼륨의 마운트를 해제할 때까지 다른 파드에서 클레임(사용)이 불가하다.
또한 persistentVolumnClaimPolicy의 Retain, Delete, Recycle과 같은 리클레임 정책을 통해 재사용, 리셋을 시킬 수 있다.

pvc를 사용하기 위해선 퍼시스턴스 스토리지와 pv를 프로비저닝 하는 절차가 생기는 불편함이 있었다. 하지만 쿠버네티스에서는 스토리지 클래스를 통해 pv의 동적 프로비저닝이 가능하다.
pvc의 스펙에 사용할 스토리지 클래스를 지정하면 pvc 생성 시 그에맞게 pv가 생성된다.
사용 예시)
pv프로비저너 생성(kubernetes.io/aws-ebs) -> sc 생성 -> sc참조 pvc 생성 -> pv 생성 -> pvc로 볼륨에 바인딩 준비 -> 파드와 볼륨 생성