[쿠버네티스 실전] 애플리케이션 볼륨 사용법

1. EmptyDir (빈디렉터리)

정의 :  쿠버네티스에서 빈디렉터리(emptyDir)는 파드(pod)가 생성될 때 함께 생성되고, 그 포드가 삭제되면 같이 삭제되는 임시 볼륨이다. 쉽게 말해, 포드 내부의 컨테이너들이 서로 파일을 공유하거나, 임시로 데이터를 저장할 수 있는 일회성 공유 메모장이라고 생각할 수 있다.

 

주요 특징 :

• 생명 주기(Lifecycle)의 동기화 : emptyDir은 파드와 운명을 같이 합니다. 컨테이너가 Crash 되어 재시작되어도 emptyDir 안의 데이터는 유지되지만, 파드 자체가 노드에서 삭제되거나 퇴거 되면 데이터는 영구적으로 삭제된다.
• 컨테이너 간 데이터 공유 : 하나의 파드 안에 여러 컨테이너가 들어있을 때, 이 컨테이너들이 동일한 emptyDir 볼륨을 마운트하여 서로 데이터를 읽고 쓸 수 있습니다.
• 저장 매체 선택 가능 : 기본적으로 노드(Node)의 디스크 디렉터리에 생성되지만, 메모리(RAM)를 매체로 사용하도록 설정할 수도 있다.

 

pod-emptydir.yaml

 

스크립트 설명 :

Pod (pod-emptydir) 안에 web-page(nginx), html-builder (alpine), 볼륨 : empty-directory이 있다.

 

컨테이너 1 - web-page (nginx)

• nginx 웹서버 이미지 사용
• empty-directory 볼륨을 /usr/share/nginx/html 에 마운트
• nginx의 기본 웹 루트 디렉토리로, 여기 있는 HTML 파일을 서빙한다.

컨테이너 2 - html-builder (alpine)

• alpine 리눅스 이미지 사용
• 동일한 empty-directory 볼륨을 /html-dir 에 마운트

echo "This page created on $(date +%Y-%m-%d)" > /html-dir/index.html
  sleep infinity

-> 현재 날짜가 담긴 index.html을 생성하고 계속 대기

 

볼륨 - empty-directory (emptyDir)

• Pod가 노드에 할당될 때 빈 상태로 생성되는 임시 볼륨
• 두 컨테이너가 동일한 볼륨을 공유 -> 파일을 주고받을 수 있음
• Pod가 삭제되면 데이터도 함께 사라짐

 

2. 호스트경로(hostPath)

정의 : hostPath는 Pod가 실행 중인 노드(호스트)의 실제 파일 시스템 디렉터리나 파일을 Pod에 마운트하는 볼륨 타입이다. 

 

주요 특징 : 

일반적인 애플리케이션(웹 서버, DB 등)에는 잘 사용하지 않지만, 다음과 같은 특수한 경우에 주로 사용된다.

• 노드 레벨의 시스템 모니터링 / 로그 수집 : 노드의 /var/log 디렉터리를 파드에 마운트하여 Fluented나 Logstash 같은 도구로 로그를 수집할 때 사용한다.
• 호스트 시스템 리소스 접근 : 노드의 Docker 데몬 (예: /var/run/docker.sock)이나 컨테이너 런타임에 파드가 직접 접근해야 할 때 사용한다.
• 성능 최적화 : 로컬 노드의 강력한 스토리지 성능이 필요할 때 가끔 활용된다.

 

deploy-hostpath.yaml, ds-hostpath.yaml

[출처 : 그림으로배우는쿠버 조훈]

 

1. 실제 서버의 폴더 지정 (volumes)

volumes:
  - name: hostpath-directory
    hostPath:
      path: /var/log

• hostPath: path: /var/log 
  • 파드가 떠 있는 실제 컴퓨터(노드)의 시스템 로그 폴터(/var/log)를 가져오겠다는 뜻
• name: hostpath-directory
  • 가져온 연결 통로의 이름을 임의로 hostpath-directory라고 붙여둔 것이다.

2. 컨테이너 내부에 꽂아 넣기 

volumeMounts:
    - mountPath: /host-log
      name: hostpath-directory

• name: hostpath-directory 
  • 바로 밑에서 정의한 이름과 똑같은 볼륨을 찾아서 연결한다.
• mouthPath: /host-log
  • 실제 서버에서 가져온 폴더를, 컨테이너 내부의 /host-log 라는 이름의 폴더로 만들어서 집어넣겠다는 뜻

 

DaemonSet을 사용하는 이유:

• 모든 서버(노드)를 빠짐없이 관리할 때 사용하는 특수 방식이다.

 

 

3. NFS(Network File System) 볼륨

정의 : 네트워크로 연결된 공용 외장 하드디스크이다. 여러 서버(노드)에 떠 있는 수많은 파드들이 동시에 접속해서 읽고 쓸 수 있는 공유 폴더 역할을 한다.

 

주요 특징 :

• 데이터 공유(ReadWriteMany 지원) 
  • 여러 개의 파드가 동시에 같은 데이터를 읽고 써야 할 때 필수적이다. (ex. 여러 웹 서버가 동일한 이미지 업로드 폴더를 공유해야 할 때)
• 이식성과 안정성 
  • 파드가 죽어서 101번 서버에 102번 서버로 이사를 가도, 어차피 네트워크를 통해 원격 NFS 서버에 접속하므로 데이터가 그대로 유지된다. 

 

deploy-nfs.yaml

출처 : 그림으로배우는 쿠버 조훈

 

1. 원격 공유 하드디스크 지정 (volumes)

volumes:
  - name: nfs-vol
    nfs:
      server: 192.168.1.10
      path: /nfs_shared/nfs-vol

• nfs : 이번엔 내 서버 디스크 (hostPath)가 아니라, 네트워크로 연결된 NFS 서버에서 폴더를 가져올게라는 선언이다.
• server: 192.168.1.10 
  • 원격에 있는 NFS 파일 서버의 IP 주소이다.
• path: /nfs_shared/nfs-vol
  • 그 NFS 서버 안에 만들어 둔 실제 공유 폴더의 경로이다.
• name: nfs-vol
  • 이 네트워크 연결 통로의 이름을 nfs-vol 이라고 지음

 

2. 컨테이너 내부에 꽂아 넣기 (volumeMounts)

volumeMounts:
    - name: nfs-vol
      mountPath: /audit

• name: nfs-vol
  • 바로 아래에서 정의한 NFS 연결 통로 (name: nfs-vol)를 화살표를 따라 그대로 가져온다.
• mountPath: /audit 
  • 컨테이너 내부에 /audit 라는 폴더를 만들어서 그 원격 공유 폴더를 꽂아 넣겠다는 뜻

 

 

4. 퍼시스턴트볼륨(PV)과 퍼시스턴트볼륨클레임(PVC)

쿠버네티스에서 PV(PersistentVolume)와 PVC(PersistentVolumeClaim)는 쉽게 말해 방을 빌려주는 건물주와 방을 구하는 세입자의 관계라고 생각하면 된다.

 

쿠버네티스의 Pod는 언제든 죽고 다시 살아날 수 있는 임시적인 존재라, 파드 내부에 데이터를 저장하면 파드가 사라질 때 데이터도 함께 날아갑니다. 이를 해결하기 위해 데이터를 영구적으로 저장하는 공간이 필요한데, 이때 PV와 PVC를 사용하게 된다.

 

출처 : 그림으로배우는 쿠버네티스 조훈

 

PersistentVolume (PV)

• 개념 : 클러스터 관리자가 미리 만들어 두거나, 스토리지 시스템에 의해 동적으로 생성된 실제 물리적인 저장 공간이다.
• 역할 : 하드디스크, AWS EBS, NFS 등 실제 어떤 스토리지 기술을 사용하는지 구체적인 스펙을 담고 있다.
• 특징 : 파드와는 별개로 쿠버네티스 클러스터 자체의 리소스로 관리되므로, 파드가 사라져도 PV와 그 안의 데이터는 안전하게 유지된다.

 

PersistentVolumeClaim (PVC)

• 개념 : 사용자가 관리자에게 "나 이정도 크기의 공간이 필요해"라고 요청하는 요청서이다.
• 역할 : 필요한 용량은 얼마인지, 읽기/쓰기 권한은 어떠해야 하는지를 정의한다.
• 특징 : 개발자는 실제 하드디스크가 어디에 어떻게 연결되어 있는지 몰라도, 원하는 스펙을 PVC에 적어두면 쿠버네티스가 알아서 알맞은 PV를 찾아 연결해 준다.

 

출처 : 그림으로배우는 쿠버네티스 조훈

생명 주기

1. 프로비저닝(Provisioning) : 관리자가 PV를 미리 많이 만들어 두거나(정적), PVC가 요청될 때 자동으로 생성되도록(동적) 설정한다.
2. 바인딩 (Binding) : 사용자가 PVC를 생성하면, 쿠버네티스가 요구 조건에 딱 맞는 PV를 찾아서 서로 짝을 지어준다.
3. 사용 (Using) : 파드를 생성할 때 "나 이 PVC 쓸래"라고 지정하면, 파드가 그 저장 공간을 사용하기 시작한다.
4. 반환(Reclaiming) : 파드가 다 쓰고 PVC를 삭제했을 때, 남은 PV와 데이터를 어떻게 처리할지 결정한다. (그냥 둔댜 = Retain, 같이 지운다 = Delete)

 

두 개로 나눈 이유

 

"개발자와 인프라 관리자의 역할을 분리하기 위해서"이다.

 

만약 PV/PVC 개념이 없다면 개발자는 파드를 만들 때마다 "AWS EBS ID, NFS 서버 IP" 같은 인프라 환경을 다 알고 코드를 짜야 한다. 환경이 바뀌면 코드도 다 고쳐야 한다.

 

하지만 이 구조 덕분에

• 인프라 관리자는 실제 스토리지(PV)만 관리하고,
• 개발자는 인프라가 무엇이든 상관없이 공간 요청만 하면 된다. 환경이 AWS에서 Azure로 바뀌어도 개발자의 PVC 코드는 바뀔 필요가 없다.

 

출처 : 그림으로배우는 쿠버네티스 조훈

 

1.  관리자의 PV (왼쪽 yaml)
   • capacity / storage: 100Mi : 관리자가 총 100MB 크기의 저장 공간을 준비했습니다.
   • accessModes: - ReadWriteMany : 아래 표에 나와 있듯, 여러 개의 노드(서버)가 동시에 읽고 쓸 수 있도록 허용하겠다는 의미
   • persistentVolumeReclaimPolicy: Retain : 반환 정책이다. 우측 하단 표에 있듯, 나중에 개발자가 이 공간을 다쓰고 PVC를 삭제하더라도 실제 데이터와 PV는 보존(Retain)하겠다는 안정장치
   • nfs : ... : 이 볼륨의 실체는 192.168.1.10 주소를 가진 NFS 서버의 /nfs_shared/pvc-vol 경로라는 뜻이다. 
2. 개발자의 PVC (오른쪽 yaml)
   • accessModes: -ReadWriteMany : 개발자가 여러 노드가 읽고 쓸 수 있는 공간이 필요해라고 조건을 걸었습니다.
     • 초록색 화살표를 보면, PV의 조건과 PVC의 조건이 서로 일치하는 것을 볼 수 있다. 이렇게 조건이 맞아야 매핑(바인딩)이 된다.
   • resources / requests / storage: 10Mi : 개발자가 필요한 크기는 최소 10MB이다. 
     • PV가 가진용량(100Mi)이 PVC가 요구한 용량(10Mi) 보다 크거나 같기 때문에, 쿠버네티스는 이 PV를 빌려주면 되겠다 인지하여 통과시킨다.

 

5. StorageClass

쉽게 말해 스토리지 자동 자판기이자 방 종류 안내서이다. 앞서 관리자가 PV를 수동으로 만들어 두는 방식을 정적 프로비저닝이라고 했는데, 개발자가 PVC를 수백 개씩 요청할 때마다 관리자가 밤새워가며 NFS 서버에 폴더 파고 PV yaml을 만들 순 없다.

 

이 문제를 해결하기 위해 개발자가 PVC를 올리면, 실제 저장 공간(PV)을 자동으로 뚝딱 만들어주는 자동화 시스템이 바로 StorageClass이다.

 

출처 : 그림으로배우는 쿠버네티스 조훈

 

 

StorageClass 종류

 

 

 

 

출처 : 그림으로배우는 쿠버 조훈

역할 : NFS 프로비저너 배포를 위한 Deployment 정의 (상반부)

 

이 파일은 nfs-subdir-external-provisioner 라는 오픈소스 프로비저너를 쿠버네티스 클러스터에 하나의 파드(Pod)로 띄우기 위한 Deployment 설정의 앞부분이다.

 

• startegy.type : Recreate : 파드가 업데이트될 때 기존 파드를 완전히 종료한 후 새 파드를 생성하는 전략이다.
• 오른쪽 일러스트 (관리자 + RBAC) : 이 프로비저너 파드가 쿠버네티스 API 서버와 통신하며 볼륨을 자동으로 생성•삭제하려면 권한이 필요하다. 이를 위해 RBAC(역할 기반 접근 제어) 설정인 rbac.yaml이 함께 필요하다는 점을 명시하고 있다. 

 

출처 : 그림으로배우는 쿠버 조훈

 

역할 : Deployment 설정 (하반부 - 실제 컨테이너 및 NFS 서버 연결)

 

프로비저너 파드가 실행될 때 어떤 이미지를 쓰고, 실제 어떤 NFS 서버의 어떤 디렉터리와 연결할지를 결정하는 핵심 설정이다. 

 

• serviceAccountName: nfs-client-provisioner : 앞서 언급한 권한(RBAC)을 이 파드에 부여하기 위해 계정을 지정하는 부분이다.
• containers 및 image (라인 21-23) : 실제로 실행될 프로피저너의 컨테이너 이미지 주소를 지정하고 있다.
• volumeMounts & volumes (라인 24-26, 라인 34-38) :
  • 하단 volumes : 쿠버네티스 클러스터 외부에 있는 실제 NFS 서버 주소(192.168.1.10)와 공유 디렉터리 경로 (/nfs_shared/dynamic-vol)를 정의한다.
  • 상단 volumeMounts : 외부 NFS 디렉터리를 프로비저너 컨테이너 내부의 /persistentvolumes 라는 경로에 마운트(연결)한다.
• env (환경변수, 라인 27-33) :
  • PROVISONER_NAME : 이 프로비저너의 고유 식별자 이름이다. 나중에 StorageClass 가 이 이름을 보고 호출하게 된다.
  • NFS_SERVER 및 NFS_PATH : 하단의 볼륨 정보와 동일하게 실제 NFS 서버 정보를 컨테이너 안의 환경 변수로 주입해 준다. (화면의 상화 화살표 = 마크는 하단 볼륨 설정값과 상단 환경 변수 값이 일치해야 함을 보여준다.)
   

출처 : 그림으로배우는 쿠버 조훈

 

역할 : 사용자가 요청할 수 있는 저장소 규격 정의 (storageclass.yaml)

 

개발자나 사용자가 "나 용량 10기가짜리 디스크가 필요해!"라고 요청(PVC)할 때, 어떤 방식으로 볼륨을 만들어 줄지 정의하는 템플릿 같은 개념이다.

 

• kind: StorageClass : 이 파일이 스토리지 클래스 자원임을 명시
• metadata.name: managed-nfs-storage : 사용자가 PVC를 작성할 때 스토리지 클래스 이름으로 적게 될 이름이다. (예 : storagecClassName: managed-nfs-storage)
• provisioner: k8s-sigs.io/nfs-subdir-external-provisioner (라인9)  : 가장 중요한 연결고리다. 사용자가 이 스토리지 클래스로 요청을 보내면, 시스템은 두 번째 파일 환경변수(PROVISONER_NAME)에서 정의했던 똑같은 이름의 프로비저너 파드를 찾아서 NFS 폴더에 하위 디렉터리 하나 파줘라고 명령을 전달하게 된다.

흐름 정리 :

1. storageclass.yaml 을 통해 사용자가 볼륨을 요청할 수 있는 창구를 열어두면
2. 사용자의 요청이 있을 때 deployment.yaml에 의해 실행된 프로비저너 파드가
3. 지정된 외부 NFS 서버에 자졷ㅇ으로 폴더를 만들어 컨테이너에게 디스크 볼륨으로 배정해 주는 일련의 자동화 시스템 설정이다.

 

6. volumeClaimTemplates

volumeClaimTemplates는 StatefulSet에서만 사용 할 수 있다.

• 디플로이먼트(Deployment) : 파드들이 완전히 동일하고 대체 가능한 Stateless(상태없음) 환경을 지향한다. 어떤 파드가 죽고 새로 살아나도 상관없는 웹 서버 같은 구조이다. 
• 스테이트풀셋(StatefulSet) : 데이터베이스(MySQL, MongoDB, ElasticSearch 등)처럼 파드 하나하나가 고유한 ID와 자신만의 고유한 데이터(상태)를 유지해야 하는 Stateful(상태 있음) 환경을 위해 존재한다.
• 이러한 근본적인 목적 차이 때문에 파드마다 독립된 볼륨을 자동으로 생성해주는 volumeClaimTemplates가 스테이트풀셋에만 필수적으로 들어가게 된다. 

출처 : 그림으로배우는 쿠버 조훈

 

스테이트풀셋이 volumeClaimTemplates를 사용해 파드와 볼륨을 어떻게 매칭하는지 보여주는 그림이다.

 

• volumeClaimTemplates의 작동 방식 : 그림을 보면 sts(StatefulSet)가 파드를 3개 띄울 때, 중앙의 volumeclaimtemplates 설정을 기반으로 PV#0,1,2 라는 고유한 볼륨 3개를 파드 개수에 맞춰 각각 생성한다.
• 고유한 1:1 매칭 : 
  • pod-1(오른쪽)은 오직 PV#1에만 연결된다.
  • 만약 pod-1이 죽었다가 다시 살아나도, 쿠버네티스는 이 파드가 기존의 pod-1임을 식별하고 정확히 원래 쓰던 PV#1을 다시 붙여준다.
• 오른쪽 Headless Service : 스테이트풀셋은 파드마다 고유한 네트워크 식별자(Domain #0, #1, #2)를 가진다. 이를 통해 외부에서 특정 데이터베이스 복제번(Master 혹은 Slave)에 정확히 찾아 갈 수 있게 한다.

 

출처 : 그림으로배우는 쿠버 조훈

 

반면, 디플로이먼트가 볼륨을 다루는 일반적인 방식을 보여준다.

 

• 단일 PVC 공유 구조 :
  • 디플로이먼트는 템플릿 내부에 volumeClaimTemplates 구조를 가질 수 없다. 대신 사전에 만들어진 단 하나의 PVC를 지정한다.
• 동일한 볼륨 바라보기 :
  • 그림을 보면 디플로이먼트로 생성된 3개의 파드가 모두 똑같은 하나의 PVC를 통해 하나의 PV를 바라보고 있다. 만약 이 볼륨이 여러 파드에서 동시에 일기/쓰기가 안 되는 방식(ReadWriteOnce)이라면, 파드 하나만 볼륨을 점유하고 나머지 파드는 에러가 나거나 대기하게 된다.
    • 동시에 읽기/쓰기가 가능한 파일 시스템(NFS)을 쓰더라도, 모든 파드가 똑같은 저장소를 공유하므로 데이터베이스 분선 저장(Sharding/Replication) 같은 고유 디스크 구조를 만들 수 없다.

 

출처 : 그림으로배우는 쿠버 조훈

 

• storageCalssName: "managed-nfs-storage" : 이 스크립트가 실행되면 앞서 구축했던 NFS 프로비저너에게 자동으로 신호가 간다.
• 자동 생성 메커니즘 : 쿠버네티스는 replicas: 3 정보와 이 템플릿을 조합하여 총 3개의 PVC를 아래 규칙으로 자동 빌드한다.
  • each-sts-backup-sts-0 ➔ sts-0 파드에 연결 (20Gi)
  • each-sts-backup-sts-1 ➔ sts-1 파드에 연결 (20Gi)
  • each-sts-backup-sts-2 ➔ sts-2 파드에 연결 (20Gi)
• 흐름 요악 : 
  • 개발자가 이 스크립트를 적용하면, 쿠버네티스는 "managed-nfs-storage(NFS 프로비저너) 제품을 써서, 각 파드(0, 1, 2번)를 위한 20GB짜리 개별 폴더를 원격 NFS 서버에 각각 파준 다음, 컨테이너 안의 /backup_data 경로에 독립적으로 1:1 마운트 하는 명령을 완수한다.