Kubernetes - Volume

기본 Objecet - Volume

 

1. emptyDir

2. hostPath

3. PVC/PV

 

1.emptyDir

컨테이너들끼리 data를 공유하기 위해 Volume을 사용하는 것

Volume - emptyDir의 구조

최초의 Volume이 생성될 때는 Volume의 내용이 비어있기 때문에 emptyDir로 명명

 

Container1이 Web 역할을 하는 서버이고 Container2가 backend단을 처리해주는 서버라고 하면

Web서버로 받은 특정 파일을 mount가 된 volume에 저장을 해놓고

Backend단의 Container도 volume에 mount해놓았다면 자신의 Local에 있는 파일처럼 사용 가능

(두 서버가 file을 주고 받을 필요없이 편하게 사용 가능)

 

Volume은 그림에서 처럼 Pod안에서 생성이 되기 때문에 

Pod에 문제가 생겨 재생성될 경우 Volume에 있는 데이터도 같이 삭제됨

* 삭제되기 때문에 일시적인 사용목적에 의한 data만 넣는게 좋다.

 

yaml 내용을 확인해보자.

Volume - emptyDir의 yaml 파일

container1과 container2는 둘다 mount하고 있고 path가 각각 mount1, mount2를 사용함

이 mountPath의 의미는 각 container가 각 path로 mount 하겠다는 의미이고 volume의 이름이 empty-dir로 같기 때문에 container마다 자신이 원하는 경로를 사용하고 있지만 결국 한 volume을 mount한다는 뜻

아래 volume의 속성은 emptyDir로 설정한 것을 확인할 수 있다.

 

 

2. hostPath

이름 그대로 한 host(Pod들이 올라가있는 Node)의 path를 Volume으로 사용하는 것

hostPath의 구조

emptyDir과 차이점!

path를 각각의 pod들이 mount해서 공유하기 때문에 Pod들이 죽어도 Node에 있는 data는 사라지지 않음!

좋아보일 수 있지만 Pod 입장에서는 큰 문제가 있음

> 만약 Pod2가 죽어서 재생성되면 해당 Node에 다시 생성되는 보장이 없음

재생성 시 다른 Node에 생성될 수 있음

재생성될 때 스케줄러가 자원상황을 보고 Node2에 만들수도 있고 Node1에 장애가 생겨 다른 Node로 옮겨질 수 있음

Pod가 다른 Node로 옮겨졌을때 새로만들어진 Pod는 Node1에 있는 Volume에 접근할 수 없음

 

하지만 굳이 방법을 찾는다면 Node가 추가될 때 마다 똑같은 이름의 경로를 만들어 직접 Node에 있는 Path끼리 mount를 시켜주면 문제가 없음

재생성 문제 해결할 수 있는 mount 방법(추천하지 않음)

이런 구성이 별로 어렵지 않지만 Kubernetes가 해주는 역할은 아니고 운영자가 직접 Node가 추가될 때마다 Linux 별도의 mount 기술을 사용해 연결해야 함(자동화 시키는데 있어서 실수할 수 있기때문에 추천하지 않음)

 

그럼 hostPath는 어떨 때 사용할까?

각각의 Node에는 기본적으로 각 Node 자신을 위해 사용되는 file들이 있음 (시스템 파일, 설정 파일 등)

이런 file에서 Pod 자신이 할당되어 있는 Host에 data를 읽거나 써야할 때 사용한다.

 

yaml 내용을 확인해보자.

hostPath의 yaml 파일 내용

Pod를 만들 때 container에서 volumeMount를 하는데 그 path가 mount1이다.

그 path에 대한 host-path라는 이름의 volume이 hostPath라는 속성으로 path는 node-v이고

type은 Directory 타입이다.

 

한가지 주의해야할 점은

이 host에 있는 path는 pod가 만들어지기 전에 사전에 만들어져있어야 함

(없으면 Error 발생)

 

host-path는 pod의 data를 저장하기 위한 용도가 아니라
Node에 있는 data를 pod에서 사용하기 위한 용도이다!

 

3. PVC/PV

 

PVC

Pod에 연속성있는 volume을 제공하기위한 개념

PVC/PV의 구성

실제 Volume의 형태는 다양하다.

Local volume 또는 외부의 원격 volume도 있다.(AWS, Git, NFS 등)

 

이런 Volume을 각각 PV(Persistent Volume)을 정의하고 연결함

Pod는 PV에 바로 연결하지 않고 PVC(Persistent Volume Claim)을 통해 PV와 연결됨

 

바로 Pod에서 PV에 연결하지 않는 이유는?

- Kubernetes는 Volume 사용에 있어서 User 영역과 Admin 영역으로 나눴다.

Kubernetes에서 Volume에 대해 User와 Admin 개념으로 나눔

Admin은 Kubernetes를 담당하는 운영자

User는 Pod에 Service를 만들고 배포 관리하는 서비스 담당자

 

Volume들의 종류는 많고 각각의 Volume을 연결하기 위한 설정도 다 다른데 yaml 내용을 확인해보자.

PersistentVolume의 yaml 파일 내용

PersistentVolume을 정의할 때 각각의 Volume에 따라 연결 속성이 다르게 들어간다.

따라서 전문적으로 연결을 관리하는 Admin이 PV를 만들어 놓으면 User는 이것을 사용하기 위해

PVC를 만들어야 함!

user 영역의 PVC yaml 파일 내용

PersistentVolumeClaim을 만들기 위한 yaml은

읽기쓰기 모드(ReadWriteOnce)가 되고 용량(resources)이 1G인 Volume을 할당해 달라고 요청하는 내용이다.

아래에 storageClassName이 있는데

현재 만들어져있는 PV에 선택이 된다는 뜻이다.

""를 안넣고 생략하면 다른 동작으로 사용될 수 있다. 다음에 더 자세히 알아보자.

 

 

마지막으로 Pod를 만들때 claimName에 앞서 만들었던 PVC 이름을 연결해 Volume을 만들고

이 Volume을 Container에서 사용한다.

 

Pod 생성 yaml 파일 내용

1. 최초 Admin이 PV를 정의해 생성한다.

2. User가 PVC를 생성한다.

3. Kubernetes가 PVC 내용에 맞는 적절한 Volume(PV)에 연결한다.

4. Pod 생성시 PVC 마운팅한다.

 

 

실습때는 hostPath 처럼 host에 있는 localPath를 사용(node-v)

아래 local 아래 내용은 차근차근 알아보도록 하고 결론은

PV에 연결되는 Pod들은 아래 node1이라고 labeling된 Node 위에만 만들어진다는 내용이다. 

 

이 Node에 지정되어 있는 path를 사용하면 좋을텐데 그렇지 않고 pod를 생성할 때

무조건 node1 라벨링 위에 Pod가 생성된다는 의미

Pod가 재생성될 때마다 data 영속적인 부분에서 문제가 없다!

 

Local Type의 PV는 잘 사용하지 않기 때문에 개념적으로만 이해하면 될 것 같다.

중요한 부분 중 하나가

spec이 설정되면 Kubernetes가 자동으로 연결해줄 수 있다는 점이다.