CKA 준비과정 - Storage (2) / CSI, Volume

CSI - Container Storage Interface

컨테이너 저장소 인터페이스는 쿠버네티스가 현재 사용하고 있는 런타임 엔진이다. 과거에는 Docker를 통째로 사용했지만, 확장성을 위해 Container Runtime Interface(CRI)를 개발하게 되었다.

 

CRI는 도커와 같은 Container Runtime과 오케스트레이션 솔루션이 어떻게 통신할 지 정의하는 인터페이스이다.

CRI가 있음으로써 다른 새로운 컨테이너 런타임 엔진이 도입되어도, 해당 엔진이 CRI 표준을 따른다면 쿠버네티스에 바로 적용을 할 수 있다.

 

Container Networking Interface(CNI) 표준도 있는데, 이를 따르는 네트워킹 솔루션은 쿠버네티스에 바로 적용이 가능하다.

 

마지막으로, 이번에 학습할 Container Storage Interface(CSI)는 다중 Storage 솔루션을 지원하도록 개발되었다. 이에 따라 쿠버네티스는 작동할 스토리지 드라이버를 선택할 수 있게 되었다. (이전 포스팅에서 각 OS에 맞는 스토리지 드라이버를 자동으로 적용한다고 학습하였다.)

 

CSI는 쿠버네티스에만 적용되는 것이 아닌, Storage 지원에 대한 표준이기 때문에 여타 다른 오케스트레이션 툴에서도 적용할 수 있는 사항이다. CSI 표준을 따르는 오케스트레이션 툴과, CSI 표준에 따른 Storage Interface는 서로 별다른 작업 없이 동작이 가능하다.

 

Volumes

도커에서 컨테이너의 데이터는 볼륨에 저장되어 보존됨을 학습했다.

 

쿠버네티스에서도 동일하게 동작한다. 파드가 삭제되면 파드의 데이터도 같이 삭제된다. 따라서 파드의 데이터를 보존하고 싶다면 볼륨을 붙여 데이터를 볼륨에 저장하도록 설정하면 된다.

 

단일 노드 내에서는 위 그림같이 볼륨을 붙이면 된다.

하지만, 호스트의 경로 옵션을 통해 볼륨 스토리지를 지정하는 것은 다중 노드 형태에서는 권장되지 않는다. (hostPath)

=> 파드는 모든 노드에서 /data 디렉토리를 사용한다. 이 때 모두 동일한 데이터를 가지길 기대하지만, 노드들은 각각 data 디렉토리를 별개로 가지기 때문에 데이터는 다를 수밖에 없다.

 

따라서 외부 저장소 솔루션을 사용하는 것이 일반적이다.

 

Persistent Volume

Persistent Volume(PV) 는 대용량 공용 저장소라 이해할 수 있다.

파드에 볼륨을 마운트하여 데이터를 보존하는 방식을 학습했다. 하지만 사용자가 많아지고 파드가 많아질수록 각 파드마다 마운트를 할때마다 일일히 지정을 해줘야 하는 번거로움이 있다.

PV는 대용량의 저장소를 생성한 뒤 각 파드들이 저장소의 일부분을 가져가 마운트하게 해준다.

그리고 해당 작업을 도와주는 것이 Persistent Volume Claim 이다. Claim은 파드가 PV의 일부 용량을 할당할 수 있게 도와준다.

 

PV 역시 yaml 파일로 정의할 수 있다.

accessMode : 볼륨이 마운트되는 방식을 정의하며, ReadOnlyMany, ReadWriteOnce, ReadWriteMany 3가지 방식 중 하나를 채택할 수 있다.

hostPath : 경로를 지정, 일반적으로 권장되지 않는다.

 

 

Persistent Volume Claim

PV와 PVC는 Namespace마다 별개로 존재한다.

관리자는 PV를 생성하고, 사용자는 PVC를 생성하여 파드에 PV를 마운트하는 식으로 사용하게 된다.

PVC가 생성되면 쿠버네티스는 PVC에 PV를 볼륨에 설정된 요청과 속성에 따라 묶는다.

 

사용자가 설정한 조건에 맞게 PVC가 생성되며 PVC는 요구사항에 맞추어 PV의 일부를 바인딩한다.

먼저 용량부터 체크하고, Access mode / volume mode / storage class 등을 고려하여 적합한 PV를 할당한다.

만약 적절한 PV가 없다면, 조건보다 높은 용량의 PV가 할당될 수도 있다. 단 이 경우, PV의 용량이 남는다고 해도 다른 PVC에 잔여 용량을 할당할 수는 없다. (PV와 PVC는 1:1 관계다)

그럼에도 바인딩에 실패한다면, PVC는 PV의 볼륨 여유분이 생길 때까지 보류 상태에 들어간다.

 

PVC와 PV를 정의 파일로 생성해본다.

PVC 설정

accessModes : ReadWriteOnce

Request Storage : 500Mi

 

PV 설정

accessModes : ReadWriteOnce

request Storage : 1Gi

 

위의 상황에서 PVC와 PV의 액세스 모드가 일치하지만 볼륨 크기는 일치하지 않는다. 이럴 경우에는 다른 500Mi 에 맞는 선택지가 없을 때 1Gi 의 볼륨을 할당할 수 있다.

 

PVC 삭제는 아래와 같이 진행된다.

kubectl 을 통해 PVC를 삭제한다. PVC가 삭제되면 파드에 바인딩 되어 있던 볼륨은 언마운트된다.

볼륨은 언마운트만 될 뿐 자동으로 삭제되진 않는다.

삭제 시, 3가지의 옵션 중에 선택할 수 있다.

1. 분리된 상태로 유지, 다른 PVC에 재사용 될 수 없는 상태로 관리자가 수동으로 삭제해야 함

2. PVC 삭제 시 PV도 자동삭제 되도록 설정

3. PVC 삭제 시 다른 PVC가 PV를 활용할 수 있도록 설정