챕터6: 볼륨: 컨테이너에 디스크 스토리지 연결

챕터6: 볼륨: 컨테이너에 디스크 스토리지 연결

*다루는 내용

• 다중 컨테이너 파드 생성
• 컨테이너 간 디스크 스토리지를 공유하기 위한 볼륨 생성
• 파드 내부에 깃 리포지토리 사용
• 파드에 GCE 퍼시스턴트 디스크와 같은 퍼시스턴트 스토리지 연결
• 사전 프로비저닝된 퍼시스턴트 스토리지
• 퍼시스턴트 스토리지의 동적 프로비저닝

새로운 컨테이너가 시작할 때마다 컨테이너 이미지를 빌프할 때 추가한 파일들을 갖는 컨테이너를 시작한다.

→ 새로 시작한 컨테이너는 이전에 실행했던 컨테이너에 쓰여진 파일시스템의 어떤 것도 볼 수 없다.

스토리지 볼륨은 파드의 일부분으로 정의되며 파드와 동일한 라이프사이클을 가진다.

→ 이 때문에 볼륨의 콘텐츠는 컨테이너를 다시 시작해도 지속된다.

6.1 볼륨 소개

• 쿠버네티스 볼륨은 파드의 구성요소로 컨테이너와 동일하게 파드 스펙에서 정의된다.
• 볼륨은 독립적인 쿠버네티스 오브젝트가 아니므로 자체적으로 생성,삭제 될 수 없다.

6.1.1 예제의 볼륨 설명

• 세 컨테이너가 독립적으로 있지만 각각 컨테이너 자체만으로는 큰 쓸모가 없다.

• 볼륨 두개를 파드에 추가하고 세 개의 컨테이너 내부의 적절한 경로에 마운트한다면 나은 시스템이 생성된다.
• 이 경우 볼륨 두개를 컨테이너 세 개에 마운트 한다.
• 컨테이너와 볼륨이 같은 파드에 구성됐더라도 컨테이너는 그 파일에 접근할 수 없다.
• 예제의 두 볼륨은 빈 상태로 초기화되므로 emptyDir 유형의 볼륨이다.

6.1.2 사용 가능한 볼륨 유형 소개

• emptyDir: 일시적인 데이터를 저장하는데 사용되는 간단한 빈 디렉터리
• hostPath: 워커 노드의 파일시스템을 파드의 디렉터리로 마운트하는데 사용
• gitRepo: 깃 리포리저틸의 콘텐츠를 체크아웃해 초기화한 볼륨
• nfs: NFS 공유를 파드에 마운트한다.
• gcePersistentDisk, awsElasticBlockStore,azureDisk: 클라우드 제공자의 전용 스토리지를 마운트하는데 사용한다.
• cinder, cephfs, iscsi, flocker, glusterfs, quobyte, rbd, flexVolume, vsphere Volume, photoPersistentDis, scaleIO: 다른 유형의 네트워크 스토리지를 마운트하는 데 사용한다.
• configMap, secret, downwardAPI: 쿠버네티스 리소스나 클러스터 정보를 파드에 노출하는 데 사용되는 특별한 유형의 볼륨
• persistentVolumneClaim: 사전에 혹은 동적으로 프로비저닝된 퍼시스턴트 스토리지를 사용하는 방법인다.

6.2 볼륨을 사용한 컨테이너 간 데이터 공유

하나의 파드에 있는 여러 컨테이너에서 데이터를 공유한는 방법

6.2.1 emptyDir 볼륨 사용

볼륨이 빈 디렉터리로 시작된다.

emptyDir 볼륨은 동일 파드에서 실행 중인 컨테이너 간

파일을 공유할 때 유용하다.

단일 컨테이너에서도 임시 데이터를 디스크에 쓰는 목적인 경우 사용할 수 있다.

파드에 emptyDir 볼륨 사용

파드 생성하기

//동일한 볼륨을 공유하는 컨테이너가 두개 있는 파드:fortune-pod.yaml
apiVersion: v1
kind: pod
metadata:
	name: fortune
spec:
	containers:
	- image: luksa/fortune
		name: html-generator //첫 번째 컨테이너는 html-generator이름에 luksa/fortune 이미지를 실행한다.
		volumeMounts:
		- name: html
			mountPath: /var/htdocs //html이란 이름의 볼륨을 컨테이너의 /var/htdocs에 마운트한다.
	- image: nginx:alpine
		name: web-server //두 번째 컨테이너
		volumneMounts:
		- name: html
			mountPath: /usr/share/nginx/html
			readOnly: true //위와 동일한 볼륨을 읽기전용으로 마운트한다.
		ports:
		- containerPort: 80
			protocol: TCP
	volumes:
	- name: html
		emptyDir: {} //html이란 단일 emptyDir 볼륨을 위의 컨테이너 두 개에 마운트한다 

• 파드는 컨테이너 두 개와 각 컨테이너에 각기 다른 경로로 마운트된 단일 볼륨을 갖는다.
• html-generator 컨테이너가 매 10초마다 fortune 명령의 결과를 /var/htdocs/index.html에 쓰기 시작한다.
• web-server 컨테이너가 시작 하자마자 컨테이너는 /usr/share/nginx/html 디렉터리의 HTML파일을 서비스하기 시작한다.

emptyDir을 사용하기 위한 매체 지정하기

쿠버네티스에 emptyDir을 디스크가 아닌 메모리를 사용하는 tmpfs 파일시스템으로 생성하도록 요청할 수 있다.

→ 이를 위해 emptyDir의 medium을 Memory로 지정한다.

volumes:
	- name: html
		emptyDir:
			medium: Memory // 이 emptyDir의 파일들은 메모리에 저장될 것이다.

emptyDir 볼륨은 가장 단순한 볼륨의 유형이지만 다른 유형들도 이 볼륨을 기반으로 한다.

6.2.2 깃 리포지터리를 볼륨으로 사용하기

• gitRepo 볼륨은 기본적으로 emptyDir 볼륨이며 파드가 시작되면 깃 리포지터리를 복제하고 특정 리비전을
  체크아웃해 데이터로 채운다.
• gitRepo 볼륨이 생성된 후에는 참조하는 리포지터리와 동기화하지 않는다.
• 깃 리포지터리에 추가 커밋을 푸시해도 볼륨에 있는 파일은 변경되지 않는다.
• 레플리케이션컨트롤러가 파드를 관리하는 경우 파드를 삭제하면 새 파드가 생성되고 이 파드의 볼륨은 최신 커밋을 포함한다.

복제된 깃 리포지터리 파일을 서비스하는 웹 서버 실행하기

//gitRepo 볼륨을 사용하는 파드: gitrepo-volume-pod.yaml
apiVersion: v1
kind: Pod
metadata:
	name: gitrepo-volume-pod
spec:
	containers:
	- images: nginx:apline
		name: web-server
		volumeMounts:
		- name: html
			mountPath: /usr/shar/nginx/html
			readOnly: true
		ports:
		- containerPort: 80
			protocol: TCP
		volumes:
		- name: html
			gitRepo: //깃 레포 볼륨 생성
				reqpository: 깃 레포지토지.git //볼륨은 이 깃 리포지터리를 복제
				revision: master //master 브랜치를 체크아웃
				directory: . //볼륨의 루트 디렉터리에 리포지터리를 복제

• 파드를 생성하면 볼륨은 먼저 빈 디렉터리를 초기화하고 특정 깃 레포를 복제한다.
• 디렉토리를 . 으로하였기에 볼륨의 루트 디렉토리에 복제된다.

깃 리포지터리와 파일 동기화 여부 확인하기

깃 리포지터리의 내용이 변경되서 새 버전을 보려면 파드를 삭제하고 다시 생성해야 한다.

→ 변경 사항이 있을 때 마다 파드를 삭제하는 대신 볼륨이 항상 깃 리포를 동기화하도록 추가 프로세스를 실행할 수 있다.

 

사이드카 컨테이너 소개

사이드카 컨테이너는 파드의 주 컨테이너의 동작을 보완한다.

도커 허브의 “git sync” 이미지를 통해 깃 레포볼륨를 최신으로 유지할 수 있다.

예제의 파드에서 새 컨테이너에 이 이미지를 사용하고 기존 깃 레포볼륨을 새 컨테이너에 마운트한 뒤,

깃 동기화 컨테이너가 깃 리포지터리와 파일 동기화를 유지하도록 설정한다.

 

프라이빗 깃 리포지터리로 gitRepo 볼륨 사용하기

프라이빗 깃 리포지터리르 컨테이너에 복제하려면 깃 동기화 사이드카나 git Repo 볼륨을 대신하는 다른 유사 방법을 사용해야 한다.

 

gitRepo 볼륨에 대한 정리

볼륨을 포함하는 파드를 위해 특별히 생성되고 독점적으로 사용되는 전용 디렉티러다.

6.3 워커 노드 파일시스템의 파일 접근

특정 시스템 레벨의 파드는 노드의 파일을 읽거나 파일시스템을 통해 노드 디바이스를 접근하기 위해 노드의 파일시스템을 사용해야 한다.

→ 쿠버네티스는 hostPath 볼륨으로 가능케 한다.

6.3.1 hostPath 볼륨 소개

• hostPath 볼륨은 노드 파일시스템의 특정 파일이나 디렉터리를 가리킨다.
• hostPath 볼륨의 콘텐츠는 파드가 종료되어도 삭제되지 않는다.
• 파드가 삭제되면 다음 파드가 호스트의 동일 경로를 가리키는 hostPath 볼륨을 사용하고, 이전 파드와 동일한 노드에 스케줄링된다는 조건에서 새로운 파드는 이전 파드가 남긴 모든 항목을 볼 수 있다.

6.3.2 hostPath 볼륨을 사용하는 시스템 파드 검사하기

대부분이 노드의 로그파일이나 kubeconfig, CA 인증서를 접근하기 위해 이 유형의 볼륨을 사용한다는 것을 볼 수 있다.

그중 어느 것도 hostPath 볼륨을 자체 데이터를 저장하기 위한 목적으로 사용하지 않는다는 것을 볼 수 있다.

6.4 퍼시스턴트 스토리지 사용

파드에서 실행 중인 애플리케이션이 디스크에 데이터를 유지해야하고 다른 노드로 재스케줄링된 경우에도 데이터를 유지해야한다면 이러한 데이터는 클러스터 노드에서도 접근이 필요하기 때문에 NAS(Network-Attached Storage)유형에 저장돼야 한다.

6.4.1 GCE 퍼시스턴트 디스크를 파드 볼륨으로 사용하기

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

쿠버네티스 클러스터가 있는 동일한 영역에 생성한다.

• 이 명령은 mongodb라고 이름 붙여진 1GB 크기의 GCE 퍼시스턴트 디스크를 생성한다.

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

//gcePersistentDisk 볼륨을 사용하는 파드: mongodb-pod-gcepd.yaml
apiVersion: v1
kind: Pod
metadata:
	name: mongodb
spec:
	volumes:
	- name: mongodb-data
		gcePersistentDisk: //볼륨의 유형은 GCE퍼시스턴트 디스크
			pdName: mongodb //퍼시스턴트 디스크의 이름은 반드시 이전에 생성한 실제 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 데이터베이스에 도큐먼트를 추가해 퍼시스턴트 스토리지에 데이터 쓰기

컨테이너 내부에 MongoDB 셸을 실행해 데이터 스토리지에 데이터를 쓰는데 사용할 수 있다.

 

GCE 퍼시스턴트 디스크를 파드 인스턴스 여러 개에서 데이터를 유지하는 데 사용할 수 있다.

6.4.2 기반 퍼시스턴트 스토리지로 다른 유형의 볼륨 사용하기

구글 쿠버네티스 엔진 - GCE 퍼시스턴트 디스크 볼륨

AWS EC2 - awsElasticBlockStore

Azure - azureFile, azureDisk

 

NFS 볼륨 사용하기

클러스터가 여러 대의 서버로 실행되는 경우 외장 스토리지를 볼륨에 마운트하기 위해 다양한 지원 옵션이 제공된다.

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

NFS 공유를 마운트하기 위해 위와같이 NFS서버와 서버에서 익스포트 경로를 지정하면 된다.

 

다른 스토리지 기술 사용하기

동일한 파드 정의를 다른 클러스터에서는 사용할 수 없다.

6.5 기반 스토리지 기술과 파드 분리

인프라스트럭처 관련 처리는 클러스터 관리자만의 영역이어야 한다.

6.5.1 퍼시스턴트볼륨과 퍼시스턴트볼륨클레임 소개

인프라스트럭처의 세부 사항을 처리하지 않고 애플리케이션이 쿠버네티스 클러스터에 스토리지를
요청할 수 있도록 하기 위한 새로운 리소스 2개

• 퍼시스턴트 볼륨
• 퍼시스턴트 볼륨 클레임
  
  

• 클러스터 관리자가 기반 스토리지를 설정하고 쿠버네티스 API 서버로 퍼시스턴트 볼륨 리소스를 생성해 쿠버네티스에 등록한다.
• 퍼시스턴트볼륨이 생성되면 관리자는 크기와 지원 가능한 접근 모드를 지정
• 클러스터 사용자는 접근 모드를 명시한 퍼시스턴트볼륨클레임 매니페스트를 생성한다.
  그리고 쿠버네티스 API 서버에 게시하고 쿠버는 적절한 퍼시스턴트 볼륨을 찾아 클레임에 볼륨을 바인딩한다.
• 퍼시스턴트볼륨클레임은 파드 내부의 볼륨 중 하나로 사용될 수 있다.
• 퍼시스턴트볼륨클레임의 바인딩을 삭제해 릴리스될 때까지 다른 사용자는 동일한 퍼시스턴트 볼륨을 사용할 수 없다.

6.5.2 퍼시스턴트볼륨 생성

//gcePersistentDisk 퍼시스턴트볼륨: mongodb-pv-gcepd.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
	name: mongodb-pv
spec:
	capacity:
		storage: 1Gi //PersistentVolume 사이즈를 지정
	accessModes:
	- ReadWriteOnce //이 pv는 단일 클라이언트의 일기/쓰기용 이나 여러 클라이언트를 위한 읽기 전용으로 마운트된다.
	- ReadOnlyMany
	persistentVolumeReclaimPolicy: Retain //클레임이 해제된 후 퍼시스턴트볼륨은 유지돼야 한다.
	gcePersistentDisk: //퍼시스턴트볼륨은 이전에 생성한 GCE 퍼시스턴트 디스크를 기반으로 한다.
		pdName: mongodb
		fsTpye: ext4

• 퍼시스턴트볼륨을 생성할 때 관리자는 쿠버네티스에게 용량이 얼마나 되는지
  단일 노드나 동시에 다수 노드에 읽기나 쓰기가 가능한지 여부를 알려야함.
• 또한 쿠버네티스에게 퍼시스턴트볼륨이 해제되면 어떤 동작을 해야할지.
  
  

• 퍼시스턴트볼륨은 특정 네임스페이스에 속하지 않는다.
• 퍼시스턴트볼륨은 노드와 같은 클러스터 수준 리소스다.

6.5.3 퍼시스턴트볼륨클레임 생성을 통한 퍼시스턴트 볼륨 요청

파드가 재스케줄링되더라도 동일한 퍼시스턴트볼륨클레임이 사용 가능한 상태로 유지되기를 원하기 때문에

→ 클레임은 파드를 생성하는 것과 별개의 프로세스다.

 

퍼시스턴트볼륨클레임 생성하기

// 퍼시스턴트볼륨클레임: mongodb-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
	name: mongodb-pvc //퍼시스턴트볼륨클레임의 이름으로 나중에 파드의 볼륨을 요청할 때 사용한다.
spec:
	resources:
		requests:
			storage: 1Gi //1GiB의 스토리지 요청
	accessModes:
	- ReadWriteOnce //단일 클라이언트를 지원하는 스토리지(읽기 쓰기 모두 수행)
	storageClassname: ""

• 퍼시스턴트볼륨클레임이 생성되자마자 쿠버네티스는 적절한 퍼시스턴트볼륨을 찾고 클레임에 바인딩한다.
• 퍼시스턴트볼륨의 용량은 퍼시스턴트볼륨클레임의 요청을 수용할 만큼 커야한다.
• 볼륨 접근 모드는 클레임에서 요청한 접근 모드를 포함해야 한다.

퍼시스턴트볼륨클레임 조회하기

다음은 접근 모드로 사용되는 약어.

• RWO(ReadWriteOnce): 단일 노드만이 읽기/쓰기용으로 볼륨 마운트 가능
• ROX(ReadOnlyMany): 다수 노드가 읽기용으로 볼륨 마운트 가능
• RWX(ReadWriteMany): 다수 노드가 읽기/쓰기용으로 볼륨 마운트 가능

→이는 파드 수가 아닌 볼륨을 동시에 사용할 수 있는 워커 노드 수와 관련이 있다.

퍼시스턴트볼륨은 클러스터 수준의 리소스이므로 특정 네임스페이스에 생성할 수 없다.

그리고 동일한 네임스페이스의 파드에서만 사용할 수 있다.

6.5.4 파드에서 퍼시스턴트볼륨클레임 사용하기

// 퍼시스턴트볼륨클레임 볼륨을 사용하는 파드: mongodb-pod-pvc.yaml
apiVersion: v1
kind: Pod
metadata:
	name: mongodb
spec:
	containers:
	- image: mongo
		name: mongodb
		volumeMounts:
		- name: mongodb-data
			mountPath: /data/db
		ports:
		- containerPort: 27017
			protocol : TCP
		volumes:
		- name: mongodb-data
			persistentVolumeClaim:
				claimName: mongodb-pvc //파드 볼륨에서 이름으로 퍼시스턴트 볼륨 클레임을 창조한다

6.5.5 퍼시스턴트볼륨과 퍼시스턴트볼륨클레임 사용의 장점 이해하기

• 퍼시스턴트볼륨과 퍼스턴트볼륨클레임을 생성하는 추가 절차가 필요한 것은 맞지만 개발자는
  기저에 사용된 실제 스토리지 기술을 알 필요가 없다.
  
  
• 동일한 파드와 클레임 매니페스트는 인프라스트럭처와 관련된 어떤 것도 참조하지 않으므로
  다른 쿠버 클러스터에서도 사용할 수 있다.

6.5.6 퍼시스턴트볼륨 재사용

파드와 퍼시스턴트볼륨클레임을 삭제한다

→ 클레임의 상태가 Pending으로 표시된다.

→이미 볼륨을 사용했기 때문에 데이터를 가지고 있으므로 클러스터 관리자가 볼륨을 완전히 비우지 않으면 새로운 클레임에 바인딩할 수 없다.

→ 클러스터 관리자가 볼륨을 비우지 않았다면 클레임과 파드가 생성됐다고 할지라도 이전 파드가 저장한 데이터를 읽을 수 있다.

 

퍼시스턴트볼륨을 수동으로 다시 클레임하기

쿠버네티스에 persistentVolumeClaimPolicy를 Retain으로 설정하면 퍼시스턴트볼륨이 이러한 동작을 할 수 있다.

쿠버네티스가 클레임이 해제돼도 볼륨과 콘텐츠를 유지하도록 한다.

 

퍼시스턴트볼륨을 자동으로 다시 클레임하기

리클레임 정책은 Recycle 과 Delete다.

Recycle: 볼륨의 콘텐츠를 삭제하고 볼륨이 다시 클레임될 수 있도록 볼륨을 사용가능하게 만든다(그림과 같이)

Delete: 기반 스토리지를 삭제한다.

6.6 퍼시스턴트볼륨의 동적 프로비저닝

클러스터 관리자가 퍼시스턴트볼륨을 생성하는 대신 퍼시스턴트볼륨 프로비저너를 배포 → 사용자가 선택 가능한 퍼시스턴트볼륨의 타입을 하나 이상의 스토리지 클래스 오브젝트로 정의할 수 있다.

6.6.1 스토리지클래스 리소스를 통한 사용 가능한 스토리지 유형 정의하기

사용자가 퍼시스턴트볼륨클레임을 생성하면 결과적으로 새로운 퍼시스턴트볼륨이 프로비저닝되므로 관리자는 하나 혹은 그 이상의 스토리지클래스 리소스를 생성해야한다.

//스토리지클래스 정의: storageclass-fast-gcepd.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
	name: fast
provisioner: kubernetes.io.gce-pd //퍼시스턴트볼륨 프로비저닝을 위해 사용되는 볼륨 플러그인이다.
parameters:
type: pd-ssd
zone: europe-west1-b //이런 파라미터가 프로비저너로 전달된다.

6.6.2 퍼시스턴트볼륨클레임에서 스토리지 클래스 요청하기

스토리지클래스 리소스가 생성되면 사용자는 퍼시스턴트볼륨클레임의 이름에 스토리지클래스를 참조할 수 있다.

특정 스토리지클래스를 요청하는 PVC 정의 생성하기

//동적 프로비저닝 PVC: mongodb-pvc-dp.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
	name: mongodb-pvc
spec:
	storageClassName: fast // PVC는 사용자 정의 스토리지 클래스를 요청한다.
resources:
	requests:
		storage: 100Mi
	accessModes:
		- ReadWriteOnce

6.3.3 스토리지 클래스를 지정하지 않은 동적 프로비저닝

스토리지 클래스를 지정하지 않고 퍼시스턴트볼륨클레임 생성하기

storageClassName 속성을 지정하지 않고 PVC를 생성하면 구글 쿠버네티스 엔진에서는 pd-standard 유형의 GCE 퍼시스턴트 디스크가 프로비저닝된다.

 

퍼시스턴트볼륨클레임을 미리 프로비저닝된 퍼시스턴트볼륨으로 바인딩 강제화하기

storageClassName 속성을 빈 문자열로 지정하지 않으면 미리 프로비저닝된 퍼시스턴트볼륨이 있다고 할지라도 동적 볼륨 프로비저너는 새로운 퍼시스턴트볼륨을 프로비저닝 한다.

 

퍼시스턴트볼륨 동적 프로비저닝의 전체 그림 이해하기

6.7 요약

• 다중 컨테이너 파드 생성과 파드의 컨테이너들이 볼륨을 파드에 추가하고 각 컨테이너에 마운트해 동일한 파일로 동작하게 한다.
• emptDir 볼륨을 사용해 임시, 비영구 데이터를 저장한다.
• gitRepo 볼륨을 사용해 깃 리포의 콘텐츠로 디렉터리를 채운다.
• hostPath 볼륨을 사용해 호스트 노드의 파일에 접근한다.
• 외부 스토리지 볼륨에 마운트해 파드가 재시작돼도 파드의 데이터를 유지한다.
• 퍼시스턴트볼륨과 퍼시스턴트볼륨클레임을 사용해 파드와 스토리지 인프라스트럭처를 분리한다.
• 각 PVC을 위해 PV을 원하는 스토리지클래스로 동적 프로비저닝한다.
• PVC을 미리 프로비저닝된 PV과 바인딩하고자 할 때 동적 프로비저너가 간섭하는 것을 막는다.