본문 바로가기
개발공부 개발새발/Kubernetes

Kubernetes ) Volume

by 휴일이 2024. 4. 24.

kubernetes 의 볼륨

쿠버네티스는 볼륨을 컨테이너에 탑재할 수 있다는 사실.

  • 다양한 볼륨 유형과 드라이버를 지원함.
  • 다른 클라우드 및 호스팅 프로바이더에서도 실행할 수 있으므로 데이터 실제 저장 위치에 매우 유연하다.
    • 로컬 볼륨, 클라우드 프로바이더 특정 볼륨 등…
    • 도커 볼륨과 비슷하지만 좀 더 강력(?)하다.
  • 도커 볼륨 시스템을 활용하지만 더 많은 기능과 옵션이 있다!

kubernetes 와 docker 의 볼륨

  • 쿠버네티스에 많은 볼륨 유형이 있지만 컨테이너 내부에서 볼륨이 동작하는 방식은 다르지 않다.
  • 다만, 컨테이너 외부에 저장되는 방식이 쿠버네티스와 유형이나 드라이버에 따라 다르다.

볼륨

볼륨은 pod 에 연결되고 pod 별로 다르니까 pod 를 구성하는 위치에 볼륨을 정의해야 한다! → Like deployment.yml

  • 쿠버네티스 볼륨은 기본적으로 pod 와 수명이 같다.
    • 컨테이너 밖과 pod 내에 있기에

emptyDir

볼륨 디폴트 설정

      containers:
        - name: story
          image: holidaykang/kub-data-demo:1
          volumeMounts:
            # dockerfileDirectory/text파일생성디렉토리
            - mountPath: /app/story
              # 볼륨 이름
              name: story-volume
      volumes:
        - name: story-volume
          emptyDir: {}
  • Pod 가 시작될 때마다 빈 디렉토리 생성
  • 파드가 살아있는 한 디렉토리 활성 상태로 유지, 데이터 채우기.
  • 컨테이너가 재시작되거나 제거되더라도 데이터는 유지
  • 하지만 pod 가 제거 되는 경우, 디렉토리도 제거
  • pod 가 재생성되면 새 디렉토리 생성

emptyDir 의 단점

파드가 여러 개인 경우 데이터가 열리지 않을 수도 있다.

사례

  • replica 가 2인 파드가 있다.
  • 파드1이 오류가 생겨 종료되었다.
  • 요청이 파드2로 가면 볼륨에 저장된 데이터를 반환할 수 없다.
  • 볼륨은 파드와 연결되어 있기 때문에 다른 볼륨과 연결되지 않은 다른 파드로 요청이 전송되면 데이터를 확인할 수 없다..!

hostPath

호스트 머신의 경로에서 볼륨 설정. 동일한 파드에서 모든 요청을 처리하는 경우에만 유용함. 호스트와 데이터 공유.

      containers:
        - name: story
          image: holidaykang/kub-data-demo:1
          volumeMounts:
            # dockerfileDirectory/text파일생성디렉토리
            - mountPath: /app/story
              # 볼륨 이름
              name: story-volume
      volumes:
        - name: story-volume
          hostPath:
            # 호스트 머신의 경로
            path: /data
            # 위 경로를 처리하는 방법 (지금 경우는 존재하지 않으면 생성한다는 전략)
            type: DirectoryOrCreate
  • 호스트와 폴더를 공유하는 것이라고 할 수 있다.
  • 이미 존재하는 데이터를 컨테이너에 공유하려는 경우도 유용하다.

hostPath 단점

  • 노드에 특정적이다.
  • 여러 워커 노드가 있는 더 큰 클러스터의 경우엔 동일안 데이터에 엑세스할 수 없다.

CSI (Container Strage Interface)

쿠버네티스가 제공하는 볼륨용 인터페이스. 클라우드 프로바이더가 제공하는 데이터 센터 등 모든 스토리지 솔루션에서 CSI 드라이버를 활용해 컨테이너와 다른 프로바이더를 연결 가능함!

영구 볼륨

pod 와 node 에 독립적임. 클러스터가 볼륨 권한을 가짐.

  • 클러스터에 새 리소스, 새 엔티티를 가짐.
  • 영구 볼륨 클레임을 만듬
    • 파드 옆에 추가되지만, 영구볼륨은 파드나 노드에 속해있지 않음. 그냥 참고용 객체라고 보면 됨
  • 영구 볼륨을 → CSI 유형을 사용해서 → 특정 클라우드 스토리지 서비스로 연결해서 실무 적용!

호스트 볼륨으로 영구 볼륨 실습해보기 !

참고로 호스트 볼륨은 단일 노드 테스트 환경에서만 작동한다. (클라우드 스토리지 서비스에서는 안 됨)

  • 볼륨 정의하기
apiVersion: v1
# 영구 볼륨
kind: PersistentVolume
metadata:
  name: host-pv
spec:
  capacity:
    # 저장 용량 (1GB)
    storage: 1Gi
  # 저장 유형 (가상 머신 내부의 파일 시스템에 폴더가 있기 때문에 파일 시스템 스토리지로 설정)
  volumeMode: Filesystem
  # 액세스 방법 (볼륨 만드는 방법 정의, 여러개 가능)
  accessModes:
    # 단일 노드에 의해, 읽기/쓰기 볼륨으로 마운트 가능, 여러 Pod 에 의해 수행되지만 모두 동일한 노드여야 함.
    - ReadWriteOnce
    # 읽기 전용이지만 여러 노드에서 요청 가능, 그러나 hostPath 는 사용할 수 없음. -> hostPath 는 한 노드에 정의되기 때문
    # - ReadOnlyMany
    # ReadOnlyMany 에서 쓰기 권한 추가, 마찬가지로 hostPath 는 사용 불가.
    # - ReadWriteMany
  # 기본 스토리지 구성을 사용해도 충분
  storageClassName: standard
  # 노드와 독립적이지 않으며 노드가 하나만 있는 경우에만 작동.
  hostPath:
    path: /data
    type: DirectoryOrCreate

한번만 만들면 어느 파드에서든 동일한 영구 볼륨을 사용 가능하다 ^0^/)

엑세스 모드

  • ReadWriteOnce : 단일 노드에 의해 읽기/쓰기 볼륨으로 마운트 가능, 여러 Pod 에 의해 수행되지만 동일한 노드에서 진행.
  • ReadOnlyMany : 읽기 전용, 여러 노드에서 요청 가능. → hostPath 사용 불가
  • ReadWriteMany : 읽기/쓰기 전용. 역시 여러 노드에서 요청 가능. → hostPath 사용 불가

hostPath 사용 불가 이유 : hostPath 는 한 노드에 정의되지만 —Many 는 여러 노드에서 요청하기 때문.

영구 볼륨 클레임 생성

볼륨 클레임 설정 yml 파일

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: host-pvc
spec:
  # 영구 볼륨 이름
  volumeName: host-pv
  accessModes:
    - ReadWriteOnce
  # 기본 스토리지 구성을 사용해도 충분
  storageClassName: standard
  # 볼륨 설정의 capacity 에 대응.
  resources:
    requests:
      # 볼륨에 대한 용량 요구치, 최대는 요구하는 볼륨 최대 용량이며 그거보다 더 적게 요청도 가능.
      storage: 1Gi
  • 구성을 보면 알겠지만 파드와 연결하는 것이 아니다.
  • 이 설정으로 파드에서 영구 볼륨에 대한 클레임을 만드는 것임.
  • 이제 deployment.yml 로 가서 파드와 클레임을 연결한다.

스토리지 클래스

쿠버네티스에서 관리자에게 스토리지 관리 방법 / 볼륨 구성 방법을 세부적으로 제어할 수 있게 해줌.

  • 우리가 설정한 PersistentVolume 구성에 중요한 정보를 제공한다.

실행해보기

kubectl apply -f=host-pv.yml
kubectl apply -f=host-pvc.yml
kubectl apply -f=deployment.yml

# 영구 볼륨 리스트 불러와보기
kubectl get pv

NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS   REASON   AGE
host-pv   1Gi        RWO            Retain           Bound    default/host-pvc   standard                42s

# 클레임 리스트 불러오기
kubectl get pvc

NAME       STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
host-pvc   Bound    host-pv   1Gi        RWO            standard       2m7s

 

  • 쿠버 대시보드 참고

볼륨 vs 영구 볼륨

모든 볼륨은 컨테이너와는 독립적이지만 파드와는 별개가 아니다.

볼륨

  • 파드와 생명 주기가 같다. 파드가 삭제되면 파드에 연결된 데이터가 지워질 수도 있다.
  • 파드 설정 파일과 동일한 파일에 볼륨을 정의한다.
  • 큰 서비스같은 경우 여러 디플로이먼트, 여러 파드, 각각 볼륨설정을 하려면 계속 코드를 반복해서 짜증날 수 있음.

영구 볼륨

  • 스탠드 얼론으로, 특정 파드에 직접 연결되진 않음.
  • 한번 정의해놓고, 그 볼륨을 클레임으로 생성해 연결한다.
  • 구성이 하나의 파일에 있으니 재사용하기 쉽다. 반복 횟수가 적어짐. 큰 프로젝트에 용이함.
  • 데이터가 손실되지 않도록 보장해줌.

 

728x90