k8s에서 데이터 영속성을 보장하는 방법

볼륨(Volume)이 뭐냐

영어로는 부피나 소리의 크기를 의미하지만 Kubernetes와 Docker에서의 볼륨은 데이터를 저장하고 관리하는 방식과 관련된 중요한 개념이다. → 영속성을 보장하기위한 개념

각각의 볼륨이 어떤 의미를 가지는지 알아보자.

---

Docker Volume

도커에서 볼륨은 컨테이너 내부와 호스트 사이에서 데이터를 공유하기 위한 방법으로 사용된다.

Docker 컨테이너는 기본적으로 격리된 가상화 환경에서 동작하기 때문에, 컨테이너 내부에서 생성된 데이터는 기본적으로 컨테이너의 라이프사이클에 종속된다.

문제점:

컨테이너가 삭제되면 내부 데이터도 모두 삭제되므로 영속적으로 데이터를 저장하거나 공유하려면 별도의 방법이 필요함.

해결책:

Docker 볼륨을 사용하면, 컨테이너 삭제와 관계없이 데이터를 유지하거나 컨테이너 간 데이터를 공유할 수 있음.

---

Docker 볼륨의 주요 사용 사례

1. 데이터베이스 데이터 관리
   • 데이터베이스 컨테이너를 운영할 때 볼륨을 사용하여 데이터를 영구적으로 저장하고, 백업하거나 마이그레이션 가능.

   docker run -d \\
     -v /var/lib/mysql:/var/lib/mysql \\
     -e MYSQL_ROOT_PASSWORD=example \\
     mysql

2. 업로드 파일 관리
   • 사용자가 업로드한 파일을 저장하는 디렉토리를 볼륨으로 설정하여 데이터를 유지.

   docker run -d \\
     -v /path/to/uploads:/app/uploads \\
     my-backend-app

3. 로그 데이터 관리
   • 컨테이너의 로그 파일을 분석하거나 모니터링 시스템으로 전송하기 위해 호스트에 저장.

   docker run -d \\
     -v /var/log/app:/app/logs \\
     my-backend-app

4. 설정 파일 및 인증서 관리
   • 환경 설정 파일(.env)이나 SSL 인증서를 관리하기 위해 볼륨을 활용.

   docker run -d \\
     -v /etc/myapp/config:/app/config \\
     -v /etc/ssl/certs:/etc/ssl/certs \\
     my-backend-app

5. 컨테이너 간 데이터 공유
   • 볼륨을 여러 컨테이너 간 공유하여 데이터를 동기화하거나 통합적으로 관리.

   version: '3.8'
   services:
     app:
       image: my-app
       volumes:
         - shared-data:/app/data
     worker:
       image: my-worker
       volumes:
         - shared-data:/worker/data
   volumes:
     shared-data:
   
   

---

Kubernetes Volume

쿠버네티스에서 볼륨은 도커와 유사하게 컨테이너와 호스트 간의 데이터 공유를 제공하지만

몇 가지 차이가 있음

쿠버네티스는 여러 호스트에서 컨테이너를 실행하고 관리하는 클러스터 환경에서 작동

---

Kubernetes 볼륨 유형

• emptyDir: Pod이 시작될 때 생성되고, Pod이 종료되면 삭제되는 임시 스토리지.
• hostPath: 노드의 파일 시스템을 마운트하여 사용.
• PersistentVolume(PV): 클라우드 스토리지, NFS, Ceph와 같은 외부 영구 스토리지와 연동.
• ConfigMap/Secret: 설정 데이터나 민감한 정보를 마운트.

---

Kubernetes 볼륨 사용 사례

1. 임시 데이터 저장 (emptyDir)
   • Pod 내 컨테이너 간 데이터를 공유하기 위해 임시 디렉토리 사용.

   volumes:
   - name: temp-data
     emptyDir: {}
   

2. 호스트 파일 시스템 연결 (hostPath)
   • 호스트의 특정 디렉토리를 마운트하여 사용.

   volumes:
   - name: host-data
     hostPath:
       path: /data
   
   

3. 외부 스토리지와 연결 (PersistentVolume)
   • 클라우드 스토리지나 네트워크 파일 시스템을 사용.

   volumes:
   - name: nfs-data
     persistentVolumeClaim:
       claimName: nfs-pvc
   
   

4. 설정 데이터 관리 (ConfigMap/Secret)
   • 환경 설정이나 민감 데이터를 볼륨으로 마운트.

   volumes:
   - name: config-volume
     configMap:
       name: app-config
   
   

---

결론:

• Docker에서는 컨테이너 삭제 후에도 데이터를 유지하거나 컨테이너 간 데이터를 공유하기 위해 볼륨을 사용.
• Kubernetes에서는 Pod 간 데이터 공유, 외부 스토리지 연동, 다양한 볼륨 유형 관리가 가능.

퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임 (PersistentVolume, PersistentVolumeClaim)

줄여서 아래와 같이 사용함

PV - PersistentVolume

PVC - PersistentVolumeClaim

• PV: 클러스터에서 사용할 수 있는 스토리지 자체.
• PVC: Pod가 PV에 접근하기 위한 요청서 또는 권한 요청 문서. - (Claim 이 청구이라는 뜻을 가짐)
  • pvc는 container나 node별로가 아닌 pod별로 관리가 된다.
  • 하나의 PV에서 어떤 데이터에 접근할지를 지정하는 방식이 아닌 여러 PV에서 골라 지정하는 방식

동적 프로비저닝 정적 프로비저닝

→ Kubernetes에서 PVC를 통해 PV를 할당하는 방식을 의미

미리 PV를 정의해두고 할당하는 방식이 정적

PVC의 class속성에 따라 그때 그때 생성하는 방식이 동적

정적 프로비저닝 ( Static Provisioning )

정의:

• 관리자가 미리 PV를 정의해두고, PVC가 생성되면 조건에 맞는 PV와 바인딩

동작 방식:

1. 관리자가 NFS, AWS EBS, GCP Persistent Disk 등 외부 스토리지를 생성.
2. 생성된 스토리지를 Kubernetes의 PV 객체로 등록.
3. PVC가 생성되면 Kubernetes가 조건에 맞는 PV를 자동으로 바인딩.PVC 정의에서 특정 PV를 명시적으로 지정하지 않으면 Kubernetes는 다음 기준으로 PVC와 PV를 자동으로 바인딩한다.
   1. 스토리지 크기:
      • PVC의 요청 크기(resources.requests.storage)가 PV의 크기 이상이어야 함.
   2. 접근 모드:
      • PVC의 accessModes가 PV의 accessModes를 만족해야 함.
   3. 스토리지 클래스:
      • PVC와 PV가 동일한 StorageClassName을 가져야 함.
      • PVC에서 StorageClassName이 생략되었으면 default StorageClass를 사용.
4. 자동 바인딩 기준
5. 자동 바인딩 방식

• 예시
  • 1. PersistentVolume 정의
       

       apiVersion: v1
       kind: PersistentVolume
       metadata:
         name: example-pv
       spec:
         capacity:
           storage: 10Gi
         accessModes:
           - ReadWriteMany
         nfs:
           path: /data
           server: nfs-server.example.com
       

        NFS 서버에서 /data 디렉토리를 Kubernetes 클러스터에 PV로 제공.
       • capacity.storage: PV의 크기(10Gi).
       • accessModes: ReadWriteMany를 사용하여 여러 Pod에서 동시에 읽고 쓰기 가능.
       • nfs.path와 nfs.server: NFS 서버의 경로(/data)와 서버 주소(nfs-server.example.com)
    2. PersistentVolumeClaim 정의

       apiVersion: v1
       kind: PersistentVolumeClaim
       metadata:
         name: example-pvc
       spec:
         accessModes:
           - ReadWriteMany
         resources:
           requests:
             storage: 5Gi
       

       Pod에서 사용할 스토리지를 요청하는 PVC 정의.
       • accessModes: ReadWriteMany로 PVC가 여러 Pod에서 사용 가능.
       • resources.requests.storage: 5Gi 스토리지를 요청. (10Gi PV에서 할당 가능)
       → 만약 특정 PV를 지정하기 위해선 volumeName을 지정해주면 된다.
    3. Pod 정의

       apiVersion: v1
       kind: Pod
       metadata:
         name: example-pod
       spec:
         containers:
         - name: app
           image: nginx
           volumeMounts:
           - mountPath: /app/data
             name: storage-volume
         volumes:
         - name: storage-volume
           persistentVolumeClaim:
             claimName: example-pvc
       

       1. PVC를 참조하여 스토리지를 마운트하는 Pod.
       
       
       • volumeMounts: 컨테이너 내부에서 /app/data 경로로 PVC를 마운트.
       • persistentVolumeClaim.claimName: example-pvc를 참조하여 연결.

    ---

    작동 흐름
    1. PV와 PVC의 바인딩:
       • Kubernetes는 PVC(example-pvc)가 요청한 조건(5Gi, ReadWriteMany)에 맞는 PV(example-pv)를 찾아 PVC와 자동으로 연결.
    2. Pod 실행:
       • Pod은 PVC를 참조하여 /app/data 경로에 NFS 서버의 /data 디렉토리를 마운트.
       • Pod 내부 애플리케이션은 /app/data에 파일을 저장하거나 읽을 수 있음.
    3. NFS 서버에 데이터 저장:
       • Pod 내부에서 생성된 파일은 NFS 서버의 /data 디렉토리에 저장됩니다.
       • 여러 Pod이 동일한 PVC를 참조하면 /data 디렉토리에서 데이터를 공유.
    응용
    • 클라우드 스토리지(AWS EBS, GCP Persistent Disk 등)를 사용하려면 nfs 대신 해당 스토리지 프로비저너를 정의하여 사용하면 됩니다.
    • 위 예제는 동적 프로비저닝을 사용하지 않는 경우이며, 필요하면 PVC 생성 시 storageClassName을 추가하여 동적 프로비저닝도 가능합니다.
    PVC를 사용하면 클러스터에서 스토리지를 효율적으로 관리할 수 있으며, Pod이 어떤 노드에서 실행되든 데이터를 지속적으로 사용할 수 있습니다. 😊

장점:

• 관리자가 스토리지를 직접 제어하므로 세부적인 관리와 보안 설정이 가능.
• 스토리지 사용량을 명확히 파악 가능.

단점:

• 관리자가 직접 PV를 정의하고 관리해야 하므로 작업 부담이 큼.
• 동적 요구 사항에 유연하게 대응하기 어려움.

동적 프로비저닝 (Dynamic Provisioning)

정의

• PVC의 StorageClass 속성에 따라 Kubernetes가 PV를 요청 시점에 동적으로 생성하는 방식.

동작 방식

1. 관리자가 StorageClass를 정의하여 스토리지의 동작 방식을 지정.
2. PVC가 스토리지 요청 시, Kubernetes가 StorageClass를 기반으로 PV를 동적으로 생성.
3. PVC는 생성된 PV와 자동으로 바인딩.

• 예시
  • PVC(dynamic-pvc)가 fast-storage StorageClass를 참조.
  • Kubernetes가 StorageClass(fast-storage)에 따라 AWS EBS에서 PV를 동적으로 생성.
  • 생성된 PV가 PVC와 바인딩.

# StorageClass 정의
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
---
# PVC 정의
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast-storage

장점:

• 자동으로 PV를 생성하므로 관리자의 작업 부담이 줄어듦.
• 사용자 요청에 따라 필요한 스토리지를 동적으로 할당.
• 클라우드 환경(AWS, GCP, Azure)에서 특히 유용.

단점:

• 스토리지 사용량을 사전에 예측하기 어려움.
• 동적 생성된 스토리지의 세부적인 제어가 어렵거나 제한적일 수 있음.

도커 실행 -d \\ -v /etc/myapp/config:/app/config \\ -v /etc/ssl/certs:/etc/ssl/certs \\ 내 백엔드 앱