[K8S] 쿠버네티스에서 Volume을 공유하기 위한 방법들 (Volume, PV, PVC, StorageClass)

NewNewDaddy·2023년 12월 30일
0

DOCKER-KUBERNETES

목록 보기
6/10
post-thumbnail

0. VOLUME

  • Kubernetes에서 Volume은 컨테이너 내부 또는 컨테이너 간에 데이터를 저장하고 공유하기 위한 추상적인 개념입니다. 볼륨은 컨테이너의 파일 시스템과 연결되며, 파일이나 데이터를 컨테이너 간에 전달하거나 지속적으로 저장할 수 있도록 합니다. 또한 EmptyDir, HostPath, NFS, AZURE Disk, AWS EBS, GCP PD 등 다양한 종류의 볼륨들을 지원하여 스토리지 백엔드와 통합된 볼륨 유형을 사용할 수 있습니다.

1. emptyDir

  • 정의 : emptyDir는 파드 간에 데이터를 공유하는 일시적인 스토리지를 제공하는 Kubernetes 볼륨 타입입니다. 이 스토리지는 파드의 라이프사이클 동안 존재하며 파드가 삭제되면 데이터가 손실됩니다.

  • 특징

    • Pod가 있는 node에서 node - 특정 pod 끼리의 데이터 공유이므로 container의 restart시에는 데이터가 보존되지만 pod의 restart시에는 data가 보존되지 않습니다.
    • emptyDir는 비어있는 디렉터리로 시작하며, 파드가 실행될 때 생성됩니다.
    • 여러 컨테이너가 포함된 파드에서 emptyDir를 공유할 수 있습니다.
    • 파드 간에 데이터 공유 또는 간단한 캐싱 용도로 사용될 수 있습니다.
    • 데이터 또는 캐시 데이터를 저장하기에 적합하며, 데이터의 보존이 필요하지 않을 때 유용합니다.
  • 정의 방법

    
    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
    spec:
      containers:
        - name: my-container
          image: nginx
          volumeMounts:
            - name: my-volume
              mountPath: /data
      volumes:
        - name: my-volume
          emptyDir: {}

2. hostPath

  • 정의 : hostPath는 호스트 노드의 파일 시스템 경로를 파드 내에서 사용할 수 있도록 하는 Kubernetes 볼륨 타입입니다. 이를 통해 호스트 노드의 파일 시스템에 직접 액세스할 수 있습니다.

  • 특징

    • Pod가 위치한 Node에서 Node - Pod 끼리의 데이터 공유이므로 container 혹은 pod가 restart 되어도 데이터가 보존됩니다. 하지만 Node가 종료되면 데이터는 소실됩니다.
    • hostPath를 사용할 때 보안 및 이식성 문제가 발생할 수 있으며, 다른 노드에서 동일한 경로를 보장하지 않기 때문에 사용상에 주의가 필요하다.
    • 특정 노드에서만 작동하고 특정 호스트 노드에서만 사용되어야 하는 상황에서 사용됩니다.
  • 정의 방법

    
    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
    spec:
      containers:
        - name: my-container
          image: nginx
          volumeMounts:
            - name: my-volume
              mountPath: /hostpath-data  # docker container 내부
      volumes:
        - name: my-volume
          hostPath:
            path: /hostpath/data  # pod 내부

emptyDir는 일시적인 데이터 저장소로 사용되며, 파드 간에 데이터를 공유할 때 유용합니다. hostPath는 특정 노드의 파일 시스템에 직접 액세스해야 하는 경우에만 사용해야 하며 주의해야 합니다. 두 경우 모두 개발/테스트용으로는 사용하기 무난하지만 운영 환경에서는 Storage Class 및 PVC를 사용하는 것이 더 안전하고 이식성 있는 옵션입니다.

3. PV (PersistentVolume)

  • 정의 : PV는 클러스터 내의 지속적인 스토리지를 나타냅니다. 이는 클러스터 관리자에 의해 물리적으로 프로비저닝 된 스토리지 볼륨을 나타내며, 파드나 컨테이너에 연결하여 사용됩니다.

  • 특징

    • PV는 클러스터 수준에서 관리되며 네임스페이스와 무관하게 설정됩니다.
    • 스토리지 프로바이더와 특정 볼륨을 연결하고 볼륨의 용량, 접근 모드 등의 속성을 정의합니다.
    • PV는 수동으로 생성되거나 클러스터 관리자에 의해 자동으로 생성될 수 있습니다.
    • 파드에서 PV를 사용하려면 PVC를 통해 바인딩해야 합니다.
  • 정의 방법

    
    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: my-pv
    spec:
      capacity:
        storage: 5Gi
      volumeMode: Filesystem
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Retain
      storageClassName: slow
      hostPath:
        path: /tmp/data
  • AccessMode 종류

    • ReadWriteOnce (RWO) : 이 모드에서 PV는 읽기/쓰기 권한이 있는 단일 파드에만 마운트될 수 있습니다. 다른 파드에서는 마운트 및 읽기 또는 쓰기 액세스를 할 수 없습니다.
    • ReadOnlyMany (ROX) : 이 모드에서 PV는 여러 파드에서 읽기 전용으로 마운트될 수 있습니다. 여러 파드가 PV를 읽을 수 있지만 쓰기 권한은 없습니다.
    • ReadWriteMany (RWX) : 이 모드에서 PV는 여러 파드에서 읽기/쓰기 권한을 가지고 마운트될 수 있습니다. 여러 파드가 PV를 마운트하고 동시에 읽고 쓸 수 있습니다.

4. PVC (PersistentVolumeClaim)

  • 정의 : PVC는 사용자 또는 애플리케이션이 PV를 요청하고 바인딩하기 위한 객체입니다. PVC는 PV에 대한 동적 프로비저닝 요청을 할 수 있으며 스토리지를 사용할 수 있게 해줍니다.

  • 특징

    • PVC는 네임스페이스 내에서 사용되며 PV와 연결됩니다.
    • 파드나 애플리케이션은 PVC를 사용하여 지속적인 스토리지를 요청하고 PV와 바인딩할 수 있습니다.
    • PVC는 스토리지 클래스와 요청한 용량을 지정하여 생성됩니다.
    • PVC는 여러 파드에서 공유할 수 있거나 단독으로 사용될 수 있습니다.
  • 정의 방법

    
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: my-pvc
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 2Gi
      storageClassName: "demo-storage"

5. SC (StorageClass)

  • 정의 : StorageClass는 동적 스토리지 프로비저닝을 관리하기 위한 설정 및 옵션을 제공하는 객체입니다. 스토리지 프로바이더와 함께 동적으로 PV를 프로비저닝하도록 지원합니다.

  • 특징

    • StorageClass는 클러스터 관리자에 의해 설정되며 네임스페이스와 무관하게 사용됩니다.
    • 스토리지 클래스는 스토리지 프로바이더와 볼륨 프로비저닝을 위한 설정을 정의합니다. 예를 들어, 볼륨 타입, IOPS, 리플리케이션 수 등을 구성할 수 있습니다.
    • PVC를 생성할 때 사용자는 원하는 스토리지 클래스를 지정할 수 있으며, 해당 클래스에 따라 PV가 동적으로 프로비저닝됩니다. 따라서 먼저 StorageClass를 정의한 후 PVC를 요청하게 되면 SC가 그에 맞는 PV를 생성하여 binding 시켜줍니다.
  • 정의 방법

    
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: slow
    provisioner: kubernetes.io/no-provisioner
    volumeBindingMode: Immediate
  • volumeBindingMode 종류

    • Immediate (즉시 바인딩) : Immediate 바인딩 모드에서는 PV가 즉시 프로비저닝되어 요청된 PVC와 바인딩됩니다. 이 모드는 PVC를 만들 때 PV가 없는 경우에도 PVC가 즉시 생성됩니다. 그러나 PV 프로비저닝이 지연될 수 있으므로 클러스터의 노드 및 스토리지 상태에 따라 PV가 사용 가능한 상태가 될 때까지 대기해야 할 수 있습니다.

    • WaitForFirstConsumer (첫 번째 사용자 대기) : WaitForFirstConsumer 바인딩 모드에서는 PV가 PVC와 바인딩되기 전에 첫 번째 파드 또는 컨테이너가 PVC를 사용하기 위해 요청할 때까지 기다립니다. 즉, PV는 PVC의 첫 번째 사용자가 요청한 후에만 프로비저닝됩니다. 이 모드는 PV 프로비저닝을 늦추지만, PV가 실제 사용되는지 확인할 수 있는 추가적인 안정성을 제공합니다.

참고 자료

YOUTUBE__Kubernetes Volumes Simplified
DOCS__Kubernetes Volumes

profile
데이터 엔지니어의 작업공간 / #PYTHON #CLOUD #SPARK #AWS #GCP #NCLOUD

0개의 댓글