gke 클러스터 저장소 구성은 총 3개로 구성되어 있습니다.
볼륨 사용
영구 볼륨 사용
SMB CSI 드라이버를 사용하여 Windows Server 노드에서 SMB 볼륨에 액세스
그렇다면 볼륨의 유형에는 어떤 것들이 있고 어떻게 구성하는지 알아보겠습니다.
개념상 볼륨이란 Pod에 있는 모든 컨테이너가 액세스할 수 있는 디렉터리입니다. Pod 사양에서 선언된 볼륨 소스는 디렉터리 생성 방법, 사용되는 저장소 매체, 디렉터리의 초기 콘텐츠를 결정합니다. Pod는 그것에 포함되는 볼륨과 컨테이너가 볼륨을 마운트하는 경로를 각각 지정합니다.
임시 볼륨 유형은 자신을 둘러싸고 있는 Pod와 수명이 같습니다. 이러한 볼륨은 Pod가 생성될 때 생성되며, 컨테이너가 다시 시작될 때까지 유지됩니다. Pod가 종료되거나 삭제되면 볼륨도 함께 종료 또는 삭제됩니다.
그 밖의 볼륨 유형은 Pod와 독립되어 있는 내구성 있는 스토리지 인터페이스입니다. 임시 볼륨과는 달리 내구성 있는 스토리지가 지원하는 볼륨의 데이터는 Pod가 제거되어도 보존됩니다. 볼륨은 단지 마운트 해제되며 데이터는 다른 Pod에 전달할 수 있습니다. 직접 지정하지 않고 PersistentVolume 리소스를 사용하여 내구성 있는 스토리지 유형의 수명주기를 관리해야 합니다.
emptyDir : emptyDir 볼륨은 Pod의 컨테이너가 읽고 쓸 수 있는 빈 디렉터리를 제공합니다. 어떤 이유로든 노드에서 Pod가 제거되면 emptyDir의 데이터가 완전 삭제됩니다. emptyDir 볼륨은 노드를 백업하는 모든 매체에 저장됩니다. 이 매체는 환경에 따라 디스크, SSD 또는 네트워크 스토리지일 수 있습니다. emptyDir 볼륨은 스크래치 공간은 물론 Pod의 여러 컨테이너 간에 데이터를 공유하는 데 유용합니다.
모든 emptyDir 마운트는 컨테이너 쓰기 가능 레이어와 로그도 포함하는 노드 임시 스토리지의 일부입니다. 기본적으로 GKE Autopilot은 임시 스토리지를 1GiB로 설정하여 앱에 일부 파일을 만들 수 있는 작은 공간을 제공합니다. 공간이 많이 또는 적게 필요하면 다음을 설정하여 배포에서 임시 스토리지를 조정하면 됩니다.
ConfigMap : ConfigMap 리소스는 Pod에 구성 데이터를 주입하는 방법을 제공합니다. ConfigMap 객체에 저장된 데이터는 ConfigMap 유형의 볼륨에서 참조된 후 Pod에서 실행되는 파일을 통해 소비될 수 있습니다. ConfigMap 볼륨의 파일은 ConfigMap 리소스에 의해 지정됩니다.
Secret : Secret 볼륨은 애플리케이션에서 비밀번호, OAuth 토큰, SSH 키와 같은 민감한 정보를 사용할 수 있게 하는 데 사용됩니다. Secret 객체에 저장된 데이터는 Secret 유형의 볼륨에서 참조된 후 Pod에서 실행되는 파일을 통해 소비될 수 있습니다.
downwardAPI : downwardAPI 볼륨은 애플리케이션에서 Downward API 데이터를 사용할 수 있게 하는 데 사용됩니다. 이 데이터에는 애플리케이션이 실행되는 Pod와 컨테이너에 대한 정보가 포함됩니다. 예를 들어 Pod의 네임스페이스와 IP 주소가 포함된 DownwardAPIVolumeFile을 애플리케이션에 노출하도록 Pod를 구성할 수 있습니다.
PersistentVolumeClaim : PersistentVolumeClaim 볼륨은 클러스터 운영자가 애플리케이션이 사용할 내구성 있는 스토리지를 프로비저닝하는 데 사용할 수 있습니다. Pod는 PersistentVolumeClaim을 사용하여 이 내구성 있는 스토리지가 지원하는 볼륨을 마운트할 수 있습니다.
실습은 GCP Cloud Shell을 이용하겠습니다.
'test'라는 이름으로 영역 클러스터를 하나 만들고 emptyDir 볼륨을 이용한 배포를 해보겠습니다.
gcloud config set project PROJECT_ID
# 기본 프로젝트 ID를 설정합니다.
gcloud config set compute/zone COMPUTE_ZONE
# 영역 클러스터를 사용하는 경우 기본 컴퓨팅 영역을 설정합니다.
gcloud components update
# gcloud를 최신 버전으로 업데이트합니다.
클러스터를 만들 수 있는 올바른 권한이 있는지 확인합니다.
최소한 Kubernetes Engine 클러스터 관리자 권한이 있어야 합니다.
gcloud container clusters create CLUSTER_NAME \
--region COMPUTE_REGION \
--node-locations COMPUTE_ZONE \
--release-channel None
# 단일 영역 노드 풀로 리전 클러스터 만들기(정적 기본 버전 사용)
ClUSTER_NAME : test
COMPUTE_REGION : asia-northeast2
COMPUTE_ZONE : asia-northeast2-a
'volumes-demo.yaml' 이라는 yaml 파일을 만들고 배포하겠습니다.
파일의 내용은 다음과 같습니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: volumes-example-deployment
spec:
replicas: 3
selector:
matchLabels:
app: demo
template:
metadata:
labels:
app: demo
spec:
containers:
- name: test-container
image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
metadata: name 필드는 volumes-example-deployment라는 배포를 지정합니다.
Pod 템플릿 사양에는 cache-volume이라는 emptyDir 볼륨을 설명하는 volumes 필드가 포함되어 있습니다.
컨테이너 사양에는 cache-volume이라는 볼륨이 파일 경로 /cache에 마운트되도록 지정하는 volumeMounts: 필드가 포함됩니다.
kubectl apply -f volumes-demo.yaml
# 배포
kubectl describe pods volumes-example-deployment
# 다음의 명령어로 확인합니다.
클러스터를 삭제하면 다음 리소스들이 삭제됩니다.
제어 영역 리소스
클러스터의 모든 노드 인스턴스
이러한 인스턴스에서 실행 중인 모든 포드
클러스터 생성 시 GKE가 만든 모든 방화벽과 경로
호스트 hostPath 및 emptyDir 볼륨에 저장된 데이터
클러스터에서 생성된 외부 부하 분산기, 클러스터에서 생성된 내부 부하 분산기, 영구 디스크 볼륨은 삭제되지 않을 수도 있습니다.
gcloud container clusters delete [CLUSTER_NAME]
# 실습에서는 test라는 이름으로 클러스터를 만들었습니다.
gcloud 명령어에서 --project, --zone, --region 플래그를 사용하여 이러한 기본 설정을 재정의할 수 있습니다.
참고 : https://cloud.google.com/kubernetes-engine/docs/quickstart