[쿠버네티스 인 액션] 6. 볼륨: 컨테이너에 디스크 스토리지 연결 (1)

6장에서 다루는 내용

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

---

• 파드 내부의 각 컨테이너는 고유하게 분리된 파일 시스템을 가지기 때문에 컨테이너 간 파일 공유는 불가능하다.
• 하지만 물리 머신에서 프로세스를 다시 시작하는 것과 같이 새로운 컨테이너가 이전에 종료된 위치에서 계속되기를 원할 수 있고, 실제 디렉터리를 보존하고 싶을 수도 있다.
• 쿠버네티스는 스토리지 볼륨을 정의하는 방법으로 이 기능을 제공한다.
• 컨테이너가 다시 시작되면 새로운 컨테이너는 이전 컨테이너가 볼륨에 기록한 모든 파일을 볼 수 있으며, 여러 개의 컨테이너가 볼륨을 공유할 수 있다.

---

6.1 볼륨 소개

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

---

6.1.1 예제의 볼륨 설명

• 첫 번째 컨테이너는 /var/htdos 디렉터리에서 HTML 페이지를 서비스하고 /var/logs에 엑세스 로그를 저장하는 웹서버를 실행한다.
• 두 번째 컨테이너는 /var/html에 HTML 파일을 생성하는 에이전트를 실행한다.
• 세 번째 컨테이너는 /var/logs 디렉터리의 로그를 처리한다.

• 이런 세 개의 컨테이너 구성에 볼륨이 없다면 파드는 아무런 동작을 하지 않는다.
• 그러나 볼륨 두 개를 파드에 추가하고 세 개의 컨테이너 내부의 적절한 경로에 마운트한다면 함께 동작할 수 있다.

---

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

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

---

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

6.2.1 emptyDir 볼륨 사용

• 동일 파드에서 실행 중인 컨테이너 간 파일을 공유할 때 유용하며, 단일 컨테이너에서도 데이터 세트의 정렬 작업을 수행하는 것과 같이 가용한 메모리에 넣기엔 커서 임시 데이터를 디스크에 쓰는 목적인 경우에 사용할 수 있다.

 

파드에 emptyDir 볼륨 사용

• 앞선 예제를 단순화해서 웹서버 컨테이너와 콘텐츠 에이전트, HTML을 위한 단일 볼륨으로 파드를 구성한다.
• Nginx를 웹 서버로 사용하고 유닉스 fortune 명령으로 HTML 콘텐츠를 생성한다.
• forturn 명령은 실행할 때마다 임의의 인용문을 출력한다.
• 매 10초마다 fortune 명령을 실행하고 출력을 index.html에 저장하는 스크립트를 생성한다.

 

파드 생성하기

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: {}

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

 

실행중인 파드 보기

• fortune 메시지를 보려면 파드의 접근을 활성화해야 한다. 이 작업은 로컬 머신의 포트를 파드로 포워딩하면 된다.

 

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

• emptyDir은 파드를 호스팅하는 워커 노드의 실제 디스크에 생성되므로 노드 디스크가 어떤 유형인지에 따라 성능이 결정됐다.
• 반면 emptyDir을 디스크가 아닌 메모리를 사용하는 tmpfs 파일시스템으로 생성하도록 요청할 수 있다.

volumes:
  - name: html
  emptyDir:
    medium: Memory

---

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

• gitRepo 볼륨은 기본적으로 emptyDir 볼륨이며 파드가 시작되면 깃 리포지터리를 복제하고 특정 리비전을 체크아웃해 데이터로 채운다.

• 매번 파드가 생성될 때 웹사이트의 최신 버전을 가져와 서비스되지만, gitRepo에 변경을 푸시할 때마다 파드를 재시작해야 적용된다.

 

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

apiVersion: v1
kind: Pod
metadata:
  name: gitrepo-volume-pod
spec:
  containers:
  - image: nginx:alpine
    name: web-server
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
      readOnly: true
    ports:
    - containerPort: 80
      protocol: TCP
  volumes:
  - name: html
    gitRepo:
      repository: https://github.com/luksa/kubia-website-example.git
      revision: master
      directory: .

 

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

• gitRepo 볼륨은 깃 리포지터리와 동기화하지 않기 때문에 변경 사항이 있을 경우 Nginx 웹 서버에서는 보이지 않는다.
• 변경 사항이 있을 때마다 파드를 삭제하는 대신 볼륨이 항상 깃 리포지터리와 동기화하도록 추가 프로세스를 실행할 수 있다.

 

사이드카 컨테이너 소개

• 깃 동기화 프로세스가 Nginx 웹 서버와 동일 컨테이너와 실행되면 안 되며 두 번째 컨테이너는 사이트카 컨테이너에서 실행돼야 한다.
• 로컬 디렉터리를 깃 리포지터리와 동기화되도록 유지하는 기존의 컨테이너 이미지를 찾으려면 도커 허브로 가서 "git sync"로 검색해본다.

 

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

• gitRepo 볼륨은 추가 설정 옵션을 필요로 하기 때문에 프라이빗 깃 리포지터리로 사용할 수 없다.
• 프라이빗 깃 리포지터리를 컨테이너에 복사하려면 깃 동기화 사이드카나 gitRepo 볼륨 대신 다른 방법을 사용해야 한다.

---

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

• 특정 시스템 레벨의 파드(보통 데몬셋으로 관리)는 노드의 파일을 읽거나 파일시스템을 통해 노드 디바이스를 접근하기 위해 노드의 파일시스템을 사용해야 한다.

---

6.3.1 hostPath 볼륨 소개

• hostPath 볼륨은 노드 파일시스템의 특정 파일이나 디렉터리를 가리킨다.
• 동일 노드에 실행중인 파드가 hostPath 볼륨의 동일 경로를 사용 중이면 동일한 파일이 표시된다.

• gitRepo나 emptyDir 볼륨의 콘텐츠는 파드가 종료되면 삭제되는 반면, hostPath 볼륨의 콘텐츠는 삭제되지 않는다.
• 파드가 삭제되면 다음 파드가 호스트의 동일 경로를 가리키는 hostPath 볼륨을 사용하고, 동일 노드에 스케줄링된다면 새로운 파드는 이전 파드가 남긴 모든 항목을 볼 수 있다.
• 볼륨의 콘텐츠는 특정 노드의 파일 시스템에 저장되므로 다른 노드로 스케줄링되면 더 이상 이전 데이터를 볼 수 없다. 따라서 데이터베이스의 데이터 디렉터리로 사용하기에는 적절하지 않다.

---

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

• 이미 생성된 시스템 전역 파드를 조회하고 어떤 종류의 볼륨을 사용하는지 살펴보자.

$kubectl get pods --namespace kube-system

$kubectl describe po fluentbit-gke-qxjn7 --namespace kube-system

• 대부분의 파드들이 노드의 로그파일이나 kubeconfig, CA 인증서를 접근하기 위해 이 유형의 볼륨을 사용한다.
• 하지만 그 중 어느 것도 hostPath 볼륨을 자체 데이터를 저장하기 위한 목적으로 사용하지 않으며, 노드 데이터에 접근하기 위해 사용한다.