Ch 06 볼륨: 컨테이너에 디스크 스토리지 연결

6.1 볼륨 소개

컨테이너의 파일 시스템은 컨테이너끼리 독립적이며 컨테이너가 재시작할 때마다 초기화
볼륨은 파드가 생성되고 삭제될 때 같이 생성, 삭제되며  컨테이너의 파일시스템 경로에 마운트하여 데이터 저장 가능

- WebServer 컨테이너: 생성된 html을 서빙하는 서버
- ContentAgent 컨테이너: html 생성하는 서버
- LogRotator 컨테이너: 사용자와 상호작용시 로그를 남기는 서버

 

를 운용할 때, 컨테이너 내 파일시스템만 이용하면 각각의 컨테이너에서 다른 컨테이너의 파일시스템에 접근 불가
(ContentAgent 컨테이너 내 파일 경로에 html 을 저장했다고 하더라도 WebServer 컨테이너에서 접근 불가)

대안으로 WebServer 컨테이너, ContentAgent 컨테이너 사이에 볼륨 / WebServer 컨테이너, LogRotator 컨테이너 사이에 볼륨을 두고 마운트 하면 컨테이너 간 스토리지 공유 가능


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

1) empyDir 볼륨 사용

파드 생성하기

① html 컨텐츠를 생성하는 fortune 컨테이너(/var/htdocs 경로와 볼륨 마운트)
② nginx 웹 서버(/usr/share/nginx/html 경로와 볼륨 마운트)

fortune-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: fortune
spec:
  containers:
  - image: luksa/fortune
    name: html-generator
    volumeMounts:
    - name: html
      mountPath: /var/htdocs
  - image: nginx:alpine
    name: web-server
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
      readOnly: true
    ports:
    - containerPort: 80
      protocol: TCP
  volumes:
  - name: html
    emptyDir: {}

localhost 8080 포트를 파드 80 포트로 연결

(kubectl port-forward fortune 8080:80)

 

 

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

파드가 생성될 때 기본적으로 emptyDir 볼륨으로 시작, 깃 레포지토리의 특정 브랜치 데이터로 해당 볼륨을 채우는 방식
단, gitRepo에 새로운 커밋이 푸시될 때마다 볼륨과 동기화 되지 않고 동기화하려면 별도의 사이드카 컨테이너가 필요

gitrepo-volume-pod.yaml

(...생략)  

volumes:
  - name: html
    gitRepo:
      repository: https://github.com/luksa/kubia-website-example.git
      revision: master
      directory: .

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

hostPath

노드 파일 시스템을 사용하기 위한 볼륨
워커 노드의 특정 파일이나 디렉터리를 컨테이너의 파일시스템에 마운트


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

이전에 언급된 파드들의 경우 파드가 재시작하거나 다른 노드로 재스케줄링 된 경우 동일한 데이터 보존이 불가하기 때문에 영구적으로 사용할 수 있는 디스크 필요


1) GCE 퍼시스턴트 디스크 생성

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

사이즈가 1GB 이고 이름이 mongodb인 퍼시스턴트 디스크를 europe-west1-b 클러스터에 생성


2) 파드 생성

apiVersion: v1
kind: Pod
metadata:
  name: mongodb
spec:
  volumes:
  - name: mongodb-data
    gcePersistentDisk:
      pdName: mongodb
      fsType: ext4
  containers:
  - image: mongo
    name: mongodb
    volumeMounts:
    - name: mongodb-data
      mountPath: /data/db
    ports:
    - containerPort: 27017
      protocol: TCP

컨테이너의 /data/db 경로 -> mongodb-data 볼륨 -> mongodb gcePersistentDisk로 연결

 

3) MongoDB 데이터베이스에 도큐먼트 추가

kubectl exec -it mongodb mongo

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

4) 파드 삭제 후 재생성된 파드가 해당 데이터를 읽을 수 있는지 확인

파드를 삭제하고 재생성하더라도 퍼시스트 디스크에 그대로 남아있는 데이터 확인 가능

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

1) 퍼시스트볼륨/퍼시스트볼륨클레임

개발자가 기반 스토리지 인스트럭처 관련 사항을 모르고 애플리케이션 개발만 담당할 수 있도록 스토리지 기술과 파드를 분리하는 방법

① 클러스터 관리자
- 네트워크 스토리지 유형 설정 및 퍼시스트볼륨(PV)를 생성하여 쿠버네티스 API에 전송

② 사용자(개발자)
- 퍼시스트볼륨클레임(PVC)를 생성하여 쿠버네티스 API에 전송 (쿠버네티스가 해당 PVC 조건에 맞는 PV를 찾아 바인딩)
- 쿠버네티스가 해당 PVC 조건에 맞는 PV를 찾아 바인딩

- 사용자가 파드 생성 시 PVC 참조


2) 퍼시스트볼륨 재사용

(내가 이해한 바로는...) 퍼시스트볼륨 생성시
- persistentVolumeClaimPolicy를 retain 으로 설정하면 퍼시스트볼륨클레임을 삭제했을 때는 퍼시스트볼륨을 재사용할 수 없지만, 퍼시스트볼륨을 수동으로 삭제하고 다시 생성했을 때 이전 파드가 저장한 콘텐츠를 다시 사용할 수 있음

- Recycle 로 설정하면 클레임을 삭제했을 때 볼륨의 컨텐츠가 삭제되고 다른 클레임이 볼륨을 재사용 가능
- Delete 로 설정하면 기반 스토리지 삭제


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

 

미리 프로비저닝 된 볼륨이 아니라, 클레임이 생성될 때 볼륨을 생성하는 방식

 

1) 스토리지 클래스를 이용한 동적 프로비저닝
: 스토리지 클래스를 만들어둔 후, 클레임 yaml에 해당 스토리지 이름을 적어 스토리지 클래스에서 정의한 스펙의 볼륨을 생성

2) 스토리지 클래스 없이 동적 프로비저닝
: 클래임 yaml 에 storageClassName 을 지정하지 않으면 기본 스탠다드 스토리지 클래스로 볼륨 생성

3) storageClassName: "" 
: 동적 프로비저닝 없이 클레임에서 수동으로 볼륨 지정