[MLOps] Kubernetes CKA자격증 공부 - Storage

이번주에 끝내야할 내용

 

Storage가 필요한 이유

- docker image위에 특정 파일을 작업하고 저장해두었고, 만일 어떤 일이 발생해서 쿠버네티스의 해당 컨테이너를 삭제를 하게된다면, 작업한 파일들도 다같이 날라가게 된다(따라서 기본적으로 컨테이너는 stateless 앱이라고함). 따라서 저장되는 파일에 대해서 특정 Storage에 저장해두고 작업하면, 컨테이너를 삭제해도 작업한 파일들은 온전하게 보관을 할수있음

Volumes

그렇다면 쿠버네티스에서는 이런 Storage를 어떻게 구현할까?

강의에서는 Pod을 예시로 Volume에 관련된 내용을 알려주었다.

• 컨테이너 안에 opt폴더안에 number.out이라는 파일을 생성했다고 할때 (args부분)
  • 볼륨을 지정하기전에 해당 컨테이너가 삭제되면 생성된 파일도 동일하게 삭제처리가 된다
• 하지만, host에 /data폴더 밑에 컨테이너에서 생성된 파일을 저장한다고 지정해주면 컨테이너가 내려가도 파일이 삭제되지않는다
  
  • volumes구조체에 host에 저장될 공간 지정
  • volumeMounts에는 컨테이너에서 저장할 데이터에 대해 지정

여기서 hostPath에는 다양한 외부 솔루션을 넣을수가 있다(ex. awsElasticBlockStore, AzureDist, etc...)

Persistent Volume (PV)

그렇다면 여러개의 Pod이있고 공통된 저장소를 쓸때 어떻게 해야할까. 또한, 여러개의 Pod이 동일한 저장소를 사용하고, 용량이 부족하게된다면 어떻게 대응해야할까. 또한 매번 위와같이 특정 경로를 지정해줘야하는 번거로움이 있다. 이를 해소하기위해 PV, PVC(Persistent Volume Claim)개념이 필요하다. PV, PVC를 생성하게 된다면, Pod과 연결된 PVC는 자동으로 유효한 PV를 찾게되서 매핑이된다. 즉, 특정경로를 바꾸게 된다면 PV에 대한 정보만 바꾸면 되는것.

 

PV에는 공통적으로 사용해야하는 공간 및 크기에 대해서 정의하고

PVC에는 공통적으로 사용해야하는 공간을 지정 및 사용 공간에 대해서 정의한다

- 여기서 PV, PVC의 accessModes는 동일해야지 할당된다.

- PV와 PVC는 1:1 대응 관계를 갖는다

Pod에서 PVC를 연결해주려면, volumes구조체에서 hostPath대신 persistentVolumeClame 밑에 claimName으로 PVC를 특정지어준다.

만일 Pod에 PVC를 할당해주었을때, PVC를 삭제하려고하면 삭제가 되지않는다. 당연하게도, Pod이 해당 PVC를 사용하고있기 때문이다.

StorageClass(SC)

쿠버네티스의 특정 버전이후에는 Dynamic Provisioning이라는 방식이 나왔는데, 이는 PVC만 선언하게 된다면 자동으로 PV와 그에 대응하는 Disk가 생성된다.

 

PV에서는 특정 공간크기를 지정해줘야하는 단점이 있다. 이를 Static Provisioning이라고 한다. 만약에 동적으로 공간크기를 할당 및 물리 Disk를 생성하려면 어떻게 해야할까? 여기서 StorageClass개념이 사용된다.

StorageClass는 Dynamic Provisioning에 속한다. PV과 동일하게 kind를 StorageClass로 두고 YAML파일을 만들수가 있다.

그다음엔 PVC를 생성하는데 이때, spec구조체 아래에 storageClassName 정보를 넣어준다.

StorageClass를 생성하게되면 자동으로(Dynamic Provisioning) PV가 생성이되고, PV에 상응하는 물리적 Disk또한 생성이 된다.

문제1. 생성된 StorageClasses안에 Dynamic Provisioning이 아닌것은?

답: kubectl get sc -o wide 명령어로 PROVISIONER이 없는 SC를 고르면된다