[Kubernetes] 파드 내부의 데이터를 영속적으로 저장하자: PV, PVC

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.
 

Kubernetes

---

1. 데이터를 보존해야만 하는 파드 : stateful 파드

쿠버네티스와 관련된 직전 포스팅까지는 모두 파드가 상태가 없는 즉, stateless한 애플리케이션이었다. 상태가 없는 파드라는 것은 그 파드의 내부에는 별도의 데이터를 갖고 있지 않으며, 단순히 파드 외부에서 해당 파드로 요청을 보냈을 때, 어떤 처리만을 수행하고 응답을 반환하기만 했음을 의미한다. 하지만 경우에 따라 파드 내부에서 별도의 데이터를 가지고 있어야 할 수도 있다. 곧 파드가 상태가 있는 즉, stateful한 경우가 있을 수 있다. 이렇게 되면 stateful 한 파드들은 내부에 갖고 있는 데이터를 영속적으로 유지해야 할 필요가 있다. 왜냐하면 기본적으로 파드는 삭제되거나 재시작될 경우 파드 내부에 있는 데이터들은 휘발되기 때문이다.

 

물론 쿠버네티스에서도 도커처럼 호스트 디렉토리의 볼륨을 컨테이너에 마운트해서 파드 내부의 데이터를 공유하고 보관할 수도 있다. 하지만 이는 한계점이 존재한다. 예를 들어, 쿠버네티스는 기본적으로 파드를 생성할 때 쿠버네티스 클러스터 내의 워커 노드들 중 하나를 선택해 특정 워커 노드에 파드를 생성하게 된다. 그리고 파드를 생성한 노드의 호스트 디렉토리의 볼륨을 파드에 마운트하게 된다. 그런데 만약 해당 노드에 장애가 생겨 노드가 재시작하거나 삭제된다면, 그 노드에서 생성되었던 파드 내부의 데이터는 어떻게 될까? 당연히 휘발된다.

 

Worker node 1에 장애가 생겼을 경유

 

위 그림처럼 Worker node 1에 파드를 배포했고, Worker node 1이라는 호스트의 /mnt 디렉토리라는 것을 마운트했다. 그러다가 Worker node 1에 장애가 발생했고 이에 따라 Worker node 1에 있던 파드가 재생성되었는데, 재생성될 때는 Worker node 2에 생성되었다고 해보자. 하지만 Worker node 2에는 Worker node 1이랑 다르게 mnt 라는 디렉토리는 존재하지 않을 것이고, 이렇게 되면 Worker node 1의 /mnt 디렉토리에 보관되어 있던 파드의 데이터는 유실되게 된다.

 

이러한 문제를 막기 위해 어떤 노드에서도 접근해 사용할 수 있는 퍼시스턴트 볼륨(이하 PV, Persistent Volume)을 사용한다. PV는 워커 노드들이 네트워크 상에서 스토리지를 마운트 하여 영속적으로 데이터를 저장할 수 있는 볼륨을 의미한다. 따라서 PV를 이용하면 위 그림과 같은 노드 레벨에서의 장애 상황이 발생하여도 데이터가 유실되는 것을 막을 수 있게 된다.

 

쿠버네티스에서도 위와 같은 문제를 막기 위해 PV(Persistent Volume)과 PVC(Persistent Volume Claim)이라는 리소스 오브젝트를 제공한다. 이제 이 오브젝트들에 대한 개념과 사용법에 대해서 알아보도록 하자.

2. 로컬 볼륨 : hostPath 와 empyDir

PV와 PVC에 대해 알아보기에 앞서서 쿠버네티스가 볼륨을 어떻게 관리하는지 이해하기 위해 쿠버네티스에서 볼륨을 간단하게 사용해볼 수 있는 2가지 기법에 대해서 알아보도록 하자.

2-1. 호스트 볼륨 공유: hostPath

'호스트 볼륨 공유'라는 키워드는 사실 도커 포스팅(목차 5-1 참조)에서 배워본 적이 있다. 당시 포스팅에서 호스트 볼륨 공유에 대해서 설명할 때 사용한 그림 자료를 다시 살펴보자.

 

 

위 그림을 보면 호스트 볼륨 공유를 수행해서 컨테이너를 실행했을 때, 호스트와 컨테이너 간의 파일 시스템이 어떻게 바뀌는지 알 수 있다. 지금 소개하는 쿠버네티스에서의 호스트 볼륨 공유 즉, hostPath에서는 '호스트'가 바로 쿠버네티스 클러스터의 '워커 노드'가 된다. 즉, 워커 노드에서 생성된 파드가 워커 노드의 호스트 디렉터리를 공유해서 파드의 데이터를 그곳에 저장하는 것이다. hostPath 볼륨을 사용하는 예제 매니페스트는 다음과 같다.

 

apiVersion: v1
kind: Pod
metadata:
  name: host-path-pod
spec:
  containers:
    - name: zedd-container
      image: busybox
      args: ["tail", "-f", "/dev/null"]
      volumeMounts:
        - name: zedd-host-path-volume
          mountPath: /etc/data
  volumes:
    - name: zedd-host-path-volume
      hostPath:
        path: /tmp

 

위 매니페스트 파일에서 먼저 주목할 부분은 spec.volumes 항목이다. 해당 항목에 생성할 hostPath 볼륨명을 명시해주고, 호스트의 어떤 디렉토리를 마운트할지 명시해준다. /tmp 라는 디렉터리가 호스트 디렉터리가 된다. 그런 다음 spec.conatiners.volumeMounts 부분을 보자. 방금 생성한 hostPath 볼륨을 컨테이너 내부에 마운트할텐데, 마운트할 볼륨명과 마운트시킬 컨테이너 내부의 디렉터리 경로를 명시해주면 된다.

 

하지만 이러한 호스트 볼륨 공유 방식은 워커 노드에 장애가 났을 때 데이터가 유실될 수 있다는 단점이 존재한다.(아까 위 그림에서 본 것처럼) 물론 모든 워커 노드에 hostPath 볼륨을 배치해야 하는 경우라면 문제가 없다. 그런 경우는 대표적으로 CAdvisor 라는 모니터링 툴이 있다.

2-2. 파드의 데이터를 보관하기 위해 다른 파드를 이용: emptyDir

이번엔 파드의 데이터를 보관하기 위해서 호스트가 아닌 다른 파드의 디렉터리를 활용하는 방법이다. 파드들이 함께 사용할 수 있도록 임시 저장 공간을 생성해 파드들이 해당 공간을 이용하는 것이다. 하지만 당연히 관련된 파드들이 모두 삭제된다면 데이터도 삭제되게 된다. 사용 예제를 살펴보자.

 

apiVersion: v1
kind: Pod
metadata:
  name: emptydir-pod
spec:
  containers:
    - name: content-creator
      image: alicek106/alpine-wget:latest
      args: ["tail", "-f", "/dev/null"]
      volumeMounts:
        - name: zedd-emptydir-volume
          mountPath: /data
    - name: apache-webserver
      image: httpd:2
      volumeMounts:
        - name: zedd-emptydir-volume
          mountPath: /usr/local/apache2/htdocs/
  volumes:
    - name: zedd-emptydir-volume
      emptyDir: {}

 

먼저 spec.volumes 항목을 보자. 해당 항목에는 emptyDir 이라고 선언해 볼륨을 생성하였다. 그리고 spec.containers 중 content-creator 라는 이름의 volumeMounts 항목을 보자. 방금 생성한 볼륨을 명시하고 해당 컨테이너 내부에는 /data 라는 디렉터리를 마운트했다. 그리고 apache-webserver 라는 이름의 컨테이너의 volumeMounts 항목에도 똑같이 생성한 볼륨을 명시하고, 마운트할 디렉터리 경로를 명시했다.

 

위 매니페스트를 실행하면 content-creator 와 apache-webserver 라는 2개의 컨테이너는 서로 디렉터리를 마운트해 데이터를 공유할 수 있게 된다. 컨테이너 이름에서 알 수 있듯이, content-creator 에서 index.html 이나 기타 프론트엔드 관련 파일을 /data 경로에 생성하면 apache-webserver에서는 /usr/local/apache2/htdocs 라는 경로에 해당 파일들이 자동으로 생겨서 웹브라우저에 보여줄 수 있는 화면들이 생긴다.

 

이렇게 empryDir 볼륨은 하나의 컨테이너가 파일을 생성(write) 및 관리하고, 다른 컨테이너는 해당 파일을 사용(read)하는 역할로 분리되어 있을 때 유용하게 사용할 수 있다.

3. 네트워크를 통한 볼륨 공유

목차 2번에서 알아본 hostPath, emptyDir 볼륨은 로컬 볼륨으로서 목차 1번에서 언급한 문제는 해결하지 못한다. 이번 목차에서는 쿠버네티스를 사용하지 않고도 단순히 시중(?)에 존재하는 다양한 네트워크 볼륨을 사용해서 목차 1번에서 언급한 문제를 해결할 수 있다는 것에 대해 배워보도록 하자.(물론 쿠버네티스에서도 네트워크 볼륨을 사용할 수 있다) NFS, iSCSI, GlusterFS, Ceph, AWS EBS(Elastic Block Store), GCP gcePersistentDisk 같은 다양한 네트워크 볼륨이 있지만 해당 목차에서는 NFS를 활용한 네트워크 볼륨을 알아보자.

 

네트워크 볼륨의 위치는 네트워크로 접근할 수 만 있다면 쿠버네티스 클러스터 내부던 외부던 상관이 없다. NFS는 Netowkr File System의 줄임말로, 대부분의 OS에서 사용할 수 있는 네트워크 스토리지이다. NFS로 여러 개의 클라이언트가 동시에 마운트할 수 있다. 하지만 NFS는 보통 하나의 서버만으로 사용하기 때문에 여러 개의 스토리지를 클러스터링하는 다른 네트워크 볼륨 솔루션에 비해서는 당연히 안정성이 떨어진다. 

 

NFS를 사용하려면 NFS 서버와 NFS 클라이언트가 필요하다. NFS 서버는 영속적인 데이터가 실질적으로 저장되는 네트워크 스토리지 서버이고, NFS 클라이언트는 NFS 서버에 마운트해서 스토리지에 파일을 읽고 쓰는 역할을 한다. 

 

NFS를 네트워크 볼륨으로 활용하는 자세한 실습은 책 p.399쪽을 참조하도록 하자.

4. 네트워크 볼륨 종류가 뭐건 파드는 볼륨을 사용하기만 해! : PV, PVC

3번 목차에서 소개한 NFS 서버를 이용한 네트워크 볼륨도 쿠버네티스에서 사용할 수는 있다. 하지만 이렇게 네트워크 볼륨 종류 중 무엇을 사용할 것인지와 같은 볼륨에 대한 상세적인 스펙을 파드의 매니페스트에 같이 정의를 하게 되면 사용할 네트워크 볼륨과 파드 간의 종속성이 생겨버린다.

 

예를 들어, A, B, C라는 서로 다른 기능을 하는 애플리케이션을 각각 파드로 배포한다고 해보자. 그리고 이 모든 애플리케이션은 네트워크 볼륨을 사용하는데, 서로 다른 네트워크 볼륨을 사용한다. 그러면 A,B,C 애플리케이션에 대한 스펙을 명시하는 파드 매니페스트가 각각 있을 것이고, 그 각 매니페스트에 어떤 네트워크 볼륨을 사용할지, 그 볼륨에 대한 스펙은 무엇인지 파드 매니페스트에 모두 작성해야 한다.

 

이러한 현상은 어떤 경우일 때 문제가 될까? 사실 개발자가 쿠버네티스라는 인프라도 관리하고, 애플리케이션을 개발하기도 하는 풀스택 개발자면 상관이 없다. 하지만 조직에서 시스템이 커짐에 따라 인프라를 관리하는 개발자와 애플리케이션을 개발하는 개발자가 명확히 역할이 분리되기 마련이다. 이렇게 되면 서로 협업을 편하게 하기 위해서는 인프라 관리자는 애플리케이션 레벨을 신경쓰지 않고 편하게 쿠버네티스를 관리하면 좋고, 반대로 애플리케이션 개발자는 인프라 레벨에 구애받지 않고 편하게 애플리케이션만 개발하면 참 좋을 것이다. 어떻게 보면 PV, PVC라는 리소스 오브젝트는 이러한 협업을 편리하게 하도록 하기 위해 등장했다고 할 수 있다.

 

PV, PVC를 사용하면 인프라 관리자와 애플리케이션 개발자가 담당하는 부분이 분리된다

 

PV, PVC를 사용하게 되면 위 그림처럼 인프라 관리자와 애플리케이션 개발자가 각각 관리하는 부분이 분리된다. 일단 인프라 관리자는 PV라는 오브젝트를 사용해서 어떤 PV가 어떤 외부 스토리지를 사용해서 생성될지만을 관리하면 된다. 그리고 애플리케이션 개발자는 PVC 라는 오브젝트를 사용해서 생성하려는 파드에서 사용할 볼륨에 대한 요구사항만 명시해주면 된다. 이 때, PVC에 명시되는 볼륨에 대한 요구사항은 해당 볼륨이 어떤 외부 스토리지를 사용한다는 것보다는 그 볼륨이 생성될 때 사용할 스토리지의 용량, 그 볼륨에 몇 개의 파드(인스턴스)만 마운트가 가능한지 등과 같은 요구사항을 명시할 수 있다.

 

이렇게 되면 애플리케이션 개발자 입장에서는 어떤 외부 스토리지 종류를 사용해서 볼륨을 생성해야 하는지에 대해서는 신경쓸 필요 없이 단지 애플리케이션에 필요한 볼륨의 용량이 얼마이고, 해당 볼륨에 몇 개의 파드만 접근이 가능하도록 해야되고 하는 등 애플리케이션의 입장에서 필요한 부분만 명시하면 된다.

 

마지막으로, PV, PVC를 이용하는 방법에 대해서 순차적으로 단계화한 그림은 다음과 같다.

 

 

1. PV를 생성할 때 기반이 되는 즉, 실질적인 데이터가 저장될 저장소는 외부 스토리지를 생성한다. 
2. 생성한 외부 스토리지를 기반으로 하는 PV를 생성한다.
3. 파드에서 마운트하고 싶어하는 PV에 대한 스펙을 명시하는 PVC 항목을 파드 매니페스트에 명시한다.
4. PVC 항목에 명시된 스펙을 충족하는 PV를 하나 선택해서 PVC 와 PV 간에 바인딩한다.
5. 바인딩딘 PV를 파드 내에 마운트 시킨다.

PV, PVC를 사용하는 이유와 사용법에 대한 설명은 위 내용이 핵심이다. 그 이외에 PV를 선택하기 위해 PVC에 명시하는 다양한 조건에 대한 설명, PV 사용이 종료되었을 때 이후 어떤 단계를 거치는지를 명시하는 라이프사이클과 Reclaim Policy, 외부 스토리지를 미리 생성하는 것도 자동화시킬 수 있는 스토리지 클래스와 다이나믹 프로비저닝과 같은 내용에 대해서는 책 p.411쪽부터 살펴볼 수 있다.