[Kubernetes Volume] 4. 퍼시스턴트 스토리지(Persistent storage)와 사용법

목차

1. 퍼시스턴트 스토리지
2. GCE 퍼시스턴트 디스크 생성하기
3. GCE 퍼시스턴트 디스크 볼륨을 사용하는 파드 생성
4. 데이터베이스에 도큐먼트를 추가해 퍼시스턴트 스토리지에 데이터 쓰기
5. 파드를 다시 생성하도 이전 데이터를 읽을 수 있는지 확인
6. 다른 유형의 볼륨 사용
7. NFS 볼륨 사용
8. 다른 스토리지 기술 사용

---

퍼시스턴트 스토리지

퍼시스턴트 스토리지는 개별 컨테이너, Pod 또는 Kubernetes 클러스터의 노드 수명 주기를 넘어서 데이터가 지속적으로 유지되는 저장소 솔루션을 의미합니다. 컨테이너나 Pod가 종료되거나 다시 생성되더라도 상태, 구성 파일 또는 유지해야하는 기타 데이터를 저장해야하는 애플리케이션에 필수적인 요소입니다.

 

이전에 다루었던 볼륨들은 파드에서 실행 중인 애플리케이션이 디스크에 데이터를 유지해야 하고 파드가 다른 노드로 재스케줄링된 경우에 동일한 데이터를 사용할 수 없었습니다. 이러한 데이터는 어떤 클러스터 노드에서도 접근이 필요하기 때문에 NAS(Network-Attached Storage) 유형에 저장돼야 합니다.

Kubernetes는 Persistent Volume (PV) 및 Persistent Volume Claim (PVC)을 사용하여 견고하고 유연한 지속적인 저장소 솔루션을 제공합니다. 이 내용은 이번 포스팅에서는 간단하게 짚고 넘어가지만, 다음 포스팅에서 자세히 다뤄보도록 하겠습니다.

• Persistent Volume (PV)
  PV는 특정 Pod 또는 노드 수명 주기에 결합되지 않은 장기간 클러스터 전체의 저장소 리소스입니다. 클러스터 관리자가 수동으로 제공하거나 스토리지 클래스와 프로비저너를 사용하여 동적으로 프로비저닝 할 수 있습니다. PV는 블록 스토리지, 네트워크 연결 스토리지 (예: NFS, iSCSI) 또는 클라우드 기반 스토리지 (예: AWS EBS, Google Persistent Disk)로 백업될 수 있습니다.
  
  
• Persistent Volume Claim (PVC)
  PVC는 PV로 충족 가능한 저장소 요청입니다. PVC는 크기, 액세스 모드 및 스토리지 클래스와 같은 저장소 요구 사항을 정의합니다. PVC가 생성되면 Kubernetes는 요구 사항을 충족하는 기존 PV에 바인딩하거나 지정된 스토리지 클래스를 사용하여 동적으로 새로운 PV를 프로비저닝합니다.

---

GCE 퍼시스턴트 디스크 생성하기

먼저 GCE 퍼시스턴트 디스크를 생성하는 것부터 시작하겠습니다. 쿠버네티스 클러스터가 있는 동일한 영역zone에 생성한다. 어떤 영역에 클러스터를 생성했는지 확인하기 위해 다음 gcloud 명령어로 쿠버네티스 클러스터를 조회합니다.

 

$ gcloud container clusters list

 

명령어를 입력하면 클러스터가 어느 영역에 생성됐다는 것을 표시하고 GCE 퍼시스턴트 디스크도 동일한 영역에 생성해야 합니다. 생성하는 명령어는 다음과 같습니다.

 

$ gcloud compute disks create --size=1GiB --zone=europe-west1-b mongodb

 

이 명령은 mongodb라고 이름 붙여진 1GiB 크기의 GCE 퍼시스턴트 디스크를 생성한 다. 수행하는 테스트에서 디스크 성능은 고려하지 않으므로 디스크 사이즈에 대한 경고는 무시할 수 있다.

---

GCE 퍼시스턴트 디스크 볼륨을 사용하는 파드 생성

이제 물리 스토리지가 적절하게 구성됐으므로 MongoDB 파드에서 볼륨으로 사용할 수 있습니다. 다음 예제와 같이 파드를 위한 YAML을 준비합니다.

apiVersion: v1
kind: Pod
metadata:
    name: mongodb
spec:
    volumes:
    - name: mongodb-data          < 볼륨의 이름(볼륨을 마운트할 때 참조한다)
      gcePersistentDisk:               < 볼륨의 유형은 GCE 퍼시스턴트 디스크다.
          pdName: mongod            <  퍼시스턴트 디스크의 이름은 반드시 이전에 생성한 실제 PD와 일치해야 한다.
          fsType: ext4                     <  파일시스템 유형은 EXT4(리눅스 파일시스템 유형 중 하나)이다.
  containers:
  - image: mongo
    name: mongodb
    volumeMounts:
    - name: mongodb-data
      mountPath: /data/db            <  MongoDB가 데이터를 저장할 경로다.
    ports:
    - containerPort: 27017
      protocol: TCP

파드는 생성한 GCE 퍼시스턴트 디스크를 기반으로 한 단일 볼륨과 단일 컨테이너로 이뤄집니다. 볼륨을 컨테이너 내부의 MongoDB가 데이터를 저장하는 /data/db에 마운트합니다.

---

데이터베이스에 도큐먼트를 추가해 퍼시스턴트 스토리지에 데이터 쓰기

파드를 생성해 컨테이너가 시작됐으므로 컨테이너 내부에 MongoDB 셸을 실행해 데이터 스토리지에 데이터를 쓰는 데 사용할 수 있습니다. 다음과 같이 셀을 실행 시킬 수 있습니다.

 

$ kubectl exec-it mongodb mongo

MongoDB shell version: 3.2.8
connecting to: mongodb://127.0.0.1:27017 Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see
      http://docs.mongodb.org/
Questions? Try the support group
      http://groups.google.com/group/mongodb-user
>

MongoDB는 JSON 도큐먼트 저장을 허용하므로 한 건의 데이터를 저장해 영구적으 로 저장되는지와 파드가 다시 생성된 후에 데이터를 가져올 수 있는지 살펴볼 것입니다. 다음과 같이 JSON 도큐먼트를 추가합니다.

 

> use mystore

switched to db mystore

> db.foo.insert({name: 'foo'})

WriteResult({ "nInserted": 1 })

 

간단한 JSON 도큐먼트를 단일 속성(name: 'foo'')으로 추가했다. 이제 find() 명령으 로 추가한 도큐먼트를 확인합니다.

 

>db.foo.find()

{"_id" : ObjectId("57a61eb9de0cfd512374cc75"), "name" : "foo" }

 

이제 도큐먼트는 GCE 퍼시스턴트 디스크에 저장돼 있어야 합니다.

---

파드를 다시 생성하도 이전 데이터를 읽을 수 있는지 확인

Mongodb 셸을 종료하고(exit 입력 후 엔터 누름) 파드를 삭제하고 다시 생성해봅시다.

 

$ kubectl delete pod mongodb

pod "mongodb" deleted

$ kubectl create -f mongodb-pod-gcepd.yaml

pod "mongodb" created

 

새로운 파드가 이전 파드와 같이 정확히 동일한 GCE 퍼시스턴트 디스크를 사용하고 MongoDB 컨테이너가 실행 중이므로 파드가 다른 노드에 스케줄링됐다 할지라도 정확히 동일한 데이터를 볼 수 있어야 합니다. 컨테이너가 가동되면 다음에 표시된 것과 같이 다시 MongoDB 셸을 실행해 이전에 저장한 도큐먼트가 다시 검색되는지 확인합니다.

 

$ kubectl exec -it mongodb mongo

MongoDB shell version: 3.2.8
connecting to: mongodb://127.0.0.1:27017
Welcome to the MongoDB shell.
...
> use mystore
switched to db mystore
>db.foo.find()
{"_id" : ObjectId("57a61eb9dedcfd512374cc75"), "name" : "foo" }

다행히 파드를 삭제하고 재생성해도 데이터는 그대로 유지됐습니다. 이런 식으로 GCE 퍼시스턴트 디스크를 파드 인스턴스 여러 개에서 데이터를 유지하는 데 사용할수 있습니다.

MongoDB 파드를 모두 사용했으므로 다시 삭제하되 기반 GCE 퍼시스턴트 디스크는 삭제하지 않는다. 6장 후반부에서 다시 사용할 것이다.

---

다른 유형의 볼륨 사용

다른 곳에서 클러스터를 실행 중이라면 기반 인프라 스트럭처에 따라 다른 유형의 볼륨을 사용해야 합니다. 예를 들어 쿠버네티스 클러스터가 아마존 AWS EC2에서 실행 중이라면 파드에 퍼시스턴트 스토리지를 제공하기 위해 awsElasticBlock Store 볼륨을 사용할 수 있습니다.

 

마이크로 소프트 Azure에서 클러스터를 실행 중이라면 azureFile이나 azureDisk 볼륨을 사용할 수 있습니다. 여기서 어떻게 사용하는지를 상세히 다루진 않겠지만 이전 예제와 거의 같습니다. 먼 저 실제 기반 스토리지를 생성하고 파드 정의에서 적절한 속성을 지정합니다.

 

예를 들어 GCE 퍼시스턴트 볼륨 대신 awsElasticBlockStore를 사용하려면 다음과 같이 볼륨 정의를 변경해야 합니다.

apiVersion: v1
kind: Pod
metadata:
   name: mongodb
spec:
    volumes:
    - name: mongodb-data
      awsElasticBlockStore:        >  gcePersistentDisk 대신 awsElasticBlockStore 사용한다.
          volumeId: my-volume     >  생성한 EBS 볼륨의 ID를 지정한다.
          fsType: ext4                    >  파일시스템 유형은 EXT4로 이전과 같다.
    ontainers:
...

---

NFS 볼륨 사용

클러스터가 여러 대의 서버로 실행되는 경우 외장 스토리지를 볼륨에 마운트하기 위한 다 양한 지원 옵션이 제공됩니다. 예를 들어 NFS 공유를 마운트하기 위해서 다음과 같이 NFS 서버와 서버에서 익스포트 경로를 지정하면 됩니다.

volumes:
- name: mongodb-data
  nfs:                                  >  이 볼륨은 NFS 공유를 사용한다.
      server: 1.2.3.4             >  NFS 서버의 IP이다.
      path: /some/path         >  서버의 익스포트된 경로다.

---

다른 스토리지 기술 사용

지원되는 다른 옵션으로 ISCSI 디스크 리소스를 마운트하기 위한 iscsi, GlusterFS 마운트를 위한 glusterfs, RADOS 블록 디바이스를 위한 rdb, 그 외 flexVolume, cinder, cephfs, flocker, fc(Fiber Channel) 등이 있습니다. 사용하지 않는다면 모든 것을 알 필요는 없습니다. 

 

각 볼륨 유형별로 필요한 속성의 세부 정보를 보려면 쿠버네티스 API 레퍼런스의 API 정의를 확인하거나 kubectl explain을 통해 정보를 찾아봐야 합니다. 특정 스토리지 기술에 익숙하다면 explain 명령을 사용해 적절한 유형의 볼륨을 어떻 게 마운트하고 파드에서 사용하는지 쉽게 확인할 수 있습니다.

 

이런 유형의 인프라스트럭처 관련 정보를 파드 정의에 포함한다는 것은 파드 정의가 특정 쿠버네티스 클러스터에 밀접하게 연결됨을 의미합니다. 동일한 파드 정의를 다른 클러 스터에서는 사용할 수 없습니다. 이것이 바로 볼륨을 이런 방식으로 사용하는 것이 파드에 퍼 시스턴트 스토리지를 연결하는 최적의 방법이 아닌 이유입니다.