Google Kubernetes Engine: Volumes

1. Volume 의 정의

Volume 은 Pod 내의 모든 Container 가 데이터를 접근할 수 있도록 공유할 수 있는 Directory 를 만드는 것을 말한다.

 

2. Volume 은 언제 사용해야할까?

1. Pod 안에 있는 모든 Container 들이 공유해야 할 데이터가 있는 경우

 

2. Pod 가 죽고 재시작하더라도 보존해야 할 데이터가 있는 경우

 

3. Volume 의 종류는?

Volume 은 크게 두 종류로 나뉜다:

• Ephemeral Volume (일시적으로만 유지하는 Volume)
• Peristent Volume (영구적으로 유지하는 Volume)

 

3.1 Ephemeral Volume

Pod 가 살아있는 동안에서만 해당 Directory 를 사용할 수 있다.

 

즉 Pod 가 죽으면 Directory 의 내용도 사라진다.

 

Pod 에서 사용하는 Ephemeral Volume 의 종류:

• emptyDir
• ConfigMap
• Secret
• Downtime API

 

3.1.1 emptyDir

이름이 emptyDir 인 이유는 Pod 가 시작될 때 만들어지며, 이때 빈 디렉토리로 시작되어서 그렇다.

 

일시적으로 관리해야하는 데이터가 있거나 Pod 내의 컨테이너들과 공유해야 할 데이터가 있다면 사용하면 좋다.

 

emptyDir 는 Pod 가 배치된 노드의 Local Disk 공간을 사용한다.

 

3.1.2 ConfigMap

어플리케이션이 Pod 로 실행될 때 설정되야 할 변수들을 쿠버네티스에서 주입해줘야 할 때 사용한다.

 

ConfigMap 은 Pod 가 시작될 때 ConfigMap 데이터들이 마운트 되는데 이 데이터들이 Pod 의 Lifecycle 과 동일하게 일시적인 것이다.

 

엄밀히 말하면 ConfigMap 자체는 Ephemeral Volume 은 아니다. 원본 ConfigMap 은 Etcd 에 저장되어서 보존어 있고 Pod 와는 무관하게 존재하고 있기 때문이다.

 

3.1.3 Secret

ConfigMap 과 유사하다.

 

차이점은 패스워드와 같은 민감한 데이터들을 다룰 때 Secret 을 사용한다는 점이다.

 

Pod 에서 Secret 을 사용할 떄 보안 목적으로 메모리에서만 이 값을 들고 있는다.

 

Secret 도 etcd 에 저장되지만 암호화되서 저장된다.

 

Secret 에 대한 접근은 K8s 에서 RBAC 를 통해 엄격하게 제어된다.

 

3.1.4 Download API

컨테이너가 실행되고 있는 Pod Environment 에 대해 알고 싶을 때 사용한다. (e.g Pod 의 Unique Identifier 를 알고싶을 때, Pod 의 이름을 알고 싶을 때 등)

 

3.2 Persistent Volume (PV)

PV 는 Pod 없이도 데이터가 영구적으로 존재한다. 

 

Pod 에서 PV 를 사용하려면 PVC (Persistent Volume Claim) 를 통해서 사용할 스토로지를 요청해야만 사용할 수 있다.

 

GKE 에서 PV 는 Network based Storage 를 통해서 지원하며, 기본으로 Google Computer Engine 에서 사용하는 Persistent Disk 를 이용한다.

 

Google Computer Engine 의 Virtual Machien 에서도 Persistent Disk 를 이용해서 스토로지를 지원한다. 뭐 애초에 GKE 자체가 Google Computer Engine 을 이용하는 것이니

 

3.2.1 GKE 에서는 PV 가 Pod 에서 어떻게 사용되는 것인가?

Pod 가 만들어질 때 GKE 는 Compute Engine API 를 사용해서 Pod 가 붙어있는 노드에 Persistent Disk 를 Attach 함으로써 PV 를 사용한다.

Pod 가 다른 노드에서 실행되면 이전 노드에 붙어 있는 Persistent Disk 는 detach 되고, 옮겨진 노드로 다시 attach 된다. 

 

중요한 건 PV 는 Pod 가 아니라 Node 에 Attach /Detach 가 된다는 것이고 PV 는 클러스터에서 관리한다. 

 

3.2.2 PV 는 어떻게 할당될 수 있는가?

Persistent Volume (PV)은 두 가지 방식으로 생성될 수 있다.

• 정적 프로비저닝(미리 생성)
• 동적 프로비저닝(PVC 요청 시 생성)

 

정적 프로비저닝:

• 이 방식에서는 관리자가 미리 PV를 생성해 두는 것.
• 사용자가 Persistent Volume Claim (PVC)을 생성하면, 쿠버네티스는 요구 사항에 맞는 기존 PV를 찾아 PVC에 한다. 이 경우, PV는 PVC가 요청되기 전에 이미 존재해야 한다.

 

동적 프로비저닝:

• 동적 프로비저닝에서는 PVC가 생성될 때 적절한 PV 가 없다면 자동으로 생성된다 이를 위해 StorageClass가 사용된다.  
  • GKE의 기본 storageClassName은 'standard' 이다.
• GKE 에서는 대부분의 상황에서 PV 를 미리 만들지 않고 PVC 를 통해서 사용하면 된다고 함. 

 

3.2.3 Persistent Volume VS Persistent Volume Claim

PV 는 쿠버네티스 관리자가 생성한다. 그리고 Pod 를 선언하는 개발자는 PVC 를 통해 사용할 스토로지를 요청만 하면 된다.

 

Pod 에서 PV 를 바로 사용하지 않고 PV 와 PVC 를 나눈 이유는 다음과 같다:

• 사용성 측면:
  • Pod 를 선언하는 개발자는 스토로지에 대한 요청인 PVC 만 하면 된다. 이를 통해 스토로지에 대한 세부 사항에 대해서 정의하지 않아도 된다. 
  • PV 를 Pod 에서 명시해서 사용해야한다면 쿠버네티스 환경이 달라질 경우 Pod 의 Yaml 도 달라져야한다. 
    • GKE 에서는 PV 를 일반적으로 Compute Engine 의 Persistent Disk 를 통해서 관리하지만 온프로미스 환경의 쿠버네티스라면 PV 는 일반적으로 vSphere 이라는 걸로 관리된다.

 

3.2.4 Persistent Volume Claim:

PV 를 Pod 에서 사용하기 위한 요청을 말한다. 이게 없으면 PV 를 Pod 에서 사용할 수 없다.

 

주의사항으로는 Pod 에서 PVC 를 지우면 PV 에 저장된 데이터도 같이 사라지게 된다. PV 를 유지하고 싶다면 persistentVolumeReclaimPolicy: retain 으로 줘야한다.

 

PVC 를 요청할 때 다음과 같은 정보를 명시해야한다:

• Storage Class:
• Volume Size:
• Access Mode:

 

3.2.4.1 Storage Class

StorageClass 는 다양한 스토리지 타입(예: SSD, HDD) 또는 스토리지 제공자(예: AWS EBS, Google Cloud Persistent Disk, NFS 등)에 대한 정보를 포함한다.

 

GKE는 'standard'라는 기본 StorageClass를 가지며, Compute Engine의 Standard Persistent Disk 유형을 사용한다.

 

SSD Persistent Disk를 사용하고자 할 경우, 'ssd'와 같은 새 StorageClass를 생성해서 사용해야한다.

 

3.2.4.2 Volume Size:

사용할 Volume 의 양을 말한다.

 

3.2.4.3 Access Mode:

Access Mode 는 PV 가 Pod 가 배치되는 노드 중 하나의 노드에만 마운트 되어야하는지 아니면 모든 노드에 마운트 되어야 하는지에 대한 설정과 읽기 모드로만 접근할 수 있는지, 읽기와 쓰기가 가능한 모드로 접근할 수 있는지에 대한 설정을 말한다.

 

Access Modes 설정은 다음과 같다:

• ReadWriteOnce: 하나의 노드에서 읽기/쓰기 가능.
• ReadOnlyMany: 여러 노드에서 읽기만 가능.
• ReadWriteMany: 여러 노드에서 읽기/쓰기 가능.

GCP Persistent Disks는 ReadWriteOnce와 ReadOnlyMany를 지원하지만, ReadWriteMany는 NFS 와 같은 PV 에서만 지원한다.

 

K8s 의 Deployment 오브젝트 에서는 ReadWriteOnce 가 적합하지 않을 것이다. replica 를 통해서 여러 Pod 가 동시에 뜨니까. 실제로 이렇게 사용하면 DeadLock 이 걸린다고 함.

 

ReadWriteOnce 는 StatefulSet 에서 적합하다. StatefulSet 에서 Pod 는 고유하게 식별되고 Pod 마다 PV 가 할당되니까. 

3.2.5 Regional Persistent Disks

PV 에 High Availability 를 제공하기 위한 기능이다.

 

데이터를 같은 Region 에 명시한 zone 으로 복제를 하는 것을 통해서 HA 를 제공한다.

 

Regional Persistent Disk 를 만드려면 다음과 같이 Storage Class 를 생성할 때 replication-type 과 zones 을 명시해야한다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: regionalpd-storageclass
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard  # 또는 pd-ssd
  replication-type: regional-pd
  zones: europe-west1-b, europe-west1-c  # 사용할 특정 존 지정

 

 

Refrerences:

https://www.coursera.org/specializations/architecting-google-kubernetes-engine