14. Volume - Dynamic Provisioning, StorageClass, Status, ReclaimPolicy / Accessing API - Overview

1. Dynamic Provisioning

 

 Volume은 데이터를 안정적으로 유지하기 위해 사용합니다. 실제 데이터는 k8s 클러스터와 분리돼서 관리됩니다. 이런 방식으로 관리할 수 있는 종류가 많은데 크게 내부망에서 관리하는 경우 외부망에서 관리하는 경우로 나눌 수 있습니다. 외부망으로는 aws, gcp, microsoft Azure 같은 cloud storage를 두고 여기에 본인의 k8s와 연결해서 사용할 수 있습니다. 내부망에는 이 k8s를 구성하는 노드들이 있는데, k8s에는 노드들의 실제 물리적인 공간에 데이터를 만들 수 있는 hostPath, local Volume이 있고, 별도의 On-premise solution들을 이 노드들에 설치할 수 있습니다. 이 솔루션들이 알아서 노드의 자원을 이용해서 Volume을 관리해줍니다. 또 NFS를 사용해서 다른 서버를 Volume 자원으로도 사용할 수 있습니다.

 

 위처럼 k8s 클러스터 밖에 실제 볼륨들이 마련되어 있다면, 관리자는 PV를 만드는데 저장 용량과 액세스 모드를 정하고, Volume을 선택해서 연결을 해요. 사용자는 원하는 용량과 액세스 모드로 PVC를 만들면 k8s가 알아서 적절한 PV와 연결하게 되고, 이 PVC를 Pod에서 사용합니다. 이는 앞에서 배웠던 내용입니다.

 

k8s 액세스 모드 종류로는 3가지가 있습니다. 모두 이렇게 지원되는 것은 아니고 각각의 Volume마다 지원되는 것이 다릅니다.

1. ReadWriteOnce (RWO)

2. ReadOnlyMany (ROM)

3. ReadWriteMany (RWM)

 

 하지만 위와 같은 방식은 복잡하기에 k8s에서 Dynamic Provisioning이라고 해서 사용자가 PVC를 만들면 알아서 PV를 만들어주고 실제로 볼륨과 연결해주는 기능이 있습니다. 모든 PV에는 각각의 상태가 존재하는데, 이 상태를 통해 PV가 PVC에 연결되어 있는 상태인지, 끊겼는지 또는 에러가 남는지 등을 알 수 있고, PV를 삭제하는 부분에 있어서 정책적인 요소가 있습니다.

 

 

Dynamic Provisioning

 

 

 이를 사용하려면 사전작업으로 지원해주는 storage solution을 설치해줘야 합니다. 설치를 하면 Service, Pod 등 여러 오브젝트들이 생성이 되지만 이 중에서 중요한 것은 StorageClass 라는 오브젝트 입니다.

 

 이 StorageClass를 사용해서 동적으로 PV를 만들 수 있는데 PVC 만들 때 StorageClassName 이라는 부분이 있습니다. 앞 강의에서는 로컬 볼륨을 사용해서 PV가 만들어졌고, StorageClassName에 넣으면 적절한 PV에 연결이 됐었죠. 근데 만약 여기에 만들어져 있는 StorageClassName을 넣으면 자동으로 스토리지 OS를 가진 PV가 만들어집니다.

 

 그리고 StorageClass는 추가로 만들 수 있고, Default라는 것을 설정할 수 있는데 이렇게 만들어 놓으면 PVC에 StorageClassName을 생략했을 때 Default StorageClass가 적용이 돼서 PV가 만들어집니다. 

 

 

Status & ReclaimPolicy

 

 

 이번에는 Volume의 Status, ReclaimPolicy에 대해 설명하겠습니다. Status는 최초 PV가 만들어졌을 때 Available 상태입니다. PVC와 연결이 되면 Bound 상태로 변합니다. 이렇게 PV를 직접 만드는 경우에는 아직 Volume의 실제 데이터가 만들어진 상태는 아니고, Pod가 PVC를 사용해서 구동이 될 때 실제 볼륨이 만들어집니다. 이렇게 Pod의 서비스가 유지가 되다가 Pod가 삭제될 경우에는 PVC, PV에는 아무런 변화가 없기에 Pod가 삭제되더라도 데이터에는 변화가 없습니다. PVC를 삭제해야지만, PV와 연결이 끊어지면서 PV의 상태가 Released 상태로 변하게 됩니다. 또 이런 과정 중에 PV와 실제 데이터 간의 연결에 문제가 생기면 Failed 상태로 변하기도 합니다.

 

 이 상태들 중에서 PVC가 삭제됐을 때 상황에 대해 PV에 설정해놓은 ReclaimPolicy에 따라서 PV에 대한 상태가 달라집니다. Retain, Delete, Recycle 이렇게 3가지의 정책이 있습니다.

 

1)Retain은 PVC 삭제시 PV 상태가 Released 되는데 PV를 만들 때 Reclaim Policy를 별도로 설정하지 않았을 경우 기본 정책입니다. (실제 볼륨의 데이터 보존, 다른 PVC에서 재사용 불가) 삭제도 수동으로 해줘야 함.

 

2)Delete의 경우, PVC를 지우면 PV도 함께 지워집니다. StorageClass 사용해서 자동으로 만들어진 PV의 경우 Default 정책입니다. Volume의 종류에 따라 실제 데이터가 삭제되기도 하고 안되기도 합니다. (StorageClass 사용시 Default, 재사용 불가)

 

3)Recycle은 PV 상태가 Avaliable이 되면서 PVC에서 다시 연결할 수 있는 상태가 됩니다. 하지만 현재는 deprecated 되었고, 실제 데이터가 삭제되면서 PV를 재사용할 수 있습니다.

 

 

 

2. Accessing API

 

 Master 노드에 k8s API 서버가 있는데 이 API 서버를 통해서만 k8s 자원을 만들거나 조회를 할 수 있습니다. k8s 설치 시 kubectl 설치를 해서 CLI로 자원을 조회할 수 있는 것이 이 API 서버를 통해서 가능한 것 입니다. 외부에서 API 서버로 접근하려면 인증서를 가지고 있는 사람만 https로 보안접근이 가능합니다. 만약 내부 관리자가 kubectl 명령으로 proxy를 열어뒀다면 인증서 없이 http로 API 서버에 접근이 가능합니다.

 

 kubectl은 Master 내부에서만 설치할 수 있는 것이 아니고 외부 PC에서도 설치를 해서 사용이 가능한데, Config 기능을 활용하면 k8s 클러스터가 여러 대가 있을 때 간편한 명령을 통해 내가 접근할 수 있는 클러스터의 연결 상태를 유지할 수 있고, 연결이 된 상태에서는 kubectl get 명령으로 해당 클러스터의 Pod 정보를 가져올 수 있습니다.

 

 이러한 접근 방법들은 유저 입장에서 API  서버에 접근을 하는 방법이고, 이런 부분을 User Account 하는데, 이번에는 Pod 입장에서 생각해보겠습니다. k8s에서는 Service Account 라고 해서 Pod가 API 서버로 접근하는 방법이 있습니다. 결국 k8s에는 유저들이 API 서버에 접근을 하기 위한 User Account, Pod에서 접근할 수 있는 Service Acoount가 있고, Service Account를 잘 사용하면 외부에서도 접근 방법으로 사용할 수 있습니다. 이는 k8s API 서버에 접근하는 Authentication에 대한 설명입니다. 

 

 만약 Namespace로 Pod가 분리되어 있는 상태에서 이 Namespace에 있는 Pod가 API 서버에 접근할 수 있다고 해서 Namespace A에 있는 Pod 조회해도 문제가 없을까요? 이런 부분을 Authorization 부분입니다. 권한까지 문제가 없다면 마지막으로 Admission Control이라고 해서 만약 PV를 만들 때 관리자가 용량을 1GB 이상으로 만들지 못하도록 설정을 해놨다면 Pod를 만들라는 API 요청이 왔을 때 k8s는 설정된 크기를 넘지 못하게 해야겠죠. 앞으로 강의는 지금까지 설명한 User Account, Service Account 통한 인증, 인가에 대해 설명할 것 입니다.