Today I Learned

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

쿠버네티스

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

하이라이터 2022. 10. 20. 16:01
728x90

6.4 퍼시스턴트 스토리지 사용

  • 애플리케이션이 디스크에 데이터를 유지해야 하고 다른 노드로 재스케줄링된 경우에도 동일한 데이터를 사용한다면,
    어떤 클러스터 노드에서도 접근이 필요하기 때문에 NAS(Network-Attached Storage) 유형에 저장돼야 한다.
  • 영구 데이터를 허용하는 볼륨을 알아보기 위해 MongoDB를 실행하는 파드를 생성해보자

6.4.1 GCE 퍼시스턴트 디스크를 파드 볼륨으로 사용하기

GCE 퍼시스턴트 디스크 생성하기

  • 먼저 GCE 퍼시스턴트 디스크를 쿠버네티스 클러스터가 있는 동일한 영역(zone)에 생성한다.
$gcloud compute disks create --size=10GB --zone=asia-northeast2-a mongodb

GCE 퍼시스턴트 디스크 볼륨으 사용하는 파드 생성하기

apiVersion: v1
kind: Pod
metadata:
  name: mongodb 
spec:
  volumes:
  - name: mongodb-data
    gcePersistentDisk:
      pdName: mongodb
      fsType: ext4
  containers:
  - image: mongo
    name: mongodb
    volumeMounts:
    - name: mongodb-data
      mountPath: /data/db
    ports:
    - containerPort: 27017
      protocol: TCP

  • 파드는 생성한 GCE 퍼시스턴트 디스크를 기반으로 한 단일 볼륨과 단일 컨테이너로 이뤄진다.
  • 볼륨을 컨테이너 내부의 MongoDB가 데이터를 저장하는 /data/db에 마운트한다.

 

MongoDB 데이터베이스에 도큐먼트를 추가해 퍼시스턴트 스토리지에 데이터 쓰기

 $kubectl exec -it mongodb -- mongosh

  • 간단한 JSON 데이터를 저장해 영구적으로 저장되는지와 파드가 다시 생성된 후에 데이터를 가져올 수 있는지 살펴보자

 

파드를 다시 생성하고 이전 파드가 저장한 데이터를 읽을 수 있는지 확인하기

  • 새로운 파드가 이전 파드와 동일한 GCE 퍼시스턴트 디스크를 사용하고 MongoDB 컨테이너가 실행중이므로 파드가 다른 노드에 스케줄링됐다 할지라도 동일한 데이터를 볼 수 있어야 한다.

  • 예상대로 파드를 삭제하고 재생성해도 데이터는 그대로 유지된다. 이런 식으로 GCE 퍼시스턴트 디스크를 파드 인스턴스 여러 개에서 데이터를 유지하는 데 사용할 수 있다.

6.4.2 기반 퍼시스턴트 스토리지로 다른 유형의 볼륨 사용하기

  • 쿠버네티스 클러스터가 GCE가 아닌 아마존 AWS EC2에서 실행중이라면 파드에 퍼시스턴트 스토리지를 제공하기 위해 awsElasticBlockStore 볼륨을 사용할 수 있다.
  • 마이크로소프트 Azure에서 클러스터를 실행 중이라면 azureFile이나 azureDisk 볼륨을 사용할 수 있다.

AWS Elastic Block Store 볼륨 사용하기

apiVersion: v1
kind: Pod
metadata:
  name: mongodb-aws
spec:
  volumes:
  - name: mongodb-data
    awsElasticBlockStore:
      volumeID: my-volume
      fsType: ext4
  containers:
  - image: mongo
    name: mongodb
    volumeMounts:
    - name: mongodb-data
      mountPath: /data/db
    ports:
    - containerPort: 27017
      protocol: TCP

 

NFS 볼륨 사용하기

  • 클러스터가 여러 대의 서버로 실행되는 경우 외장 스토리지를 볼륨에 마운트하기 위한 다양한 지원 옵션이 제공된다.
  • 예를 들어 NFS 공유를 마운트하기 위해 다음과 같이 NFS 서버와 서버에서 익스포트 경로를 지정할 수 있다.
apiVersion: v1
kind: Pod
metadata:
  name: mongodb-nfs
spec:
  volumes:
  - name: mongodb-data
    nfs:
      server: 1.2.3.4
      path: /some/path
  containers:
  - image: mongo
    name: mongodb
    volumeMounts:
    - name: mongodb-data
      mountPath: /data/db
    ports:
    - containerPort: 27017
      protocol: TCP

 

다른 스토리지 기술 사용하기

  • 지원되는 다른 옵션으로 ISCSI 디스크 리소스를 마운트하기 위한 iscsi, GlusterFS 마운트를 위한 glusterfs 등이 있다.
  • 하지만 이런 유형의 인프라스트럭처 관련 정보를 파드 정의에 포함한다는 것은 파드 정의가 특정 쿠버네티스 클러스터에 밀접하게 연결됨을 의미한다.
  • 볼륨을 이런 방식으로 사용하는 것은 파드에 퍼시스턴트 스토리지를 연결하는 최적의 방법이 아니다.

6.5 기반 스토리지 기술과 파드 분리

  • 이상적으로 쿠버네티스에 애플리케이션을 배포하는 개발자는 기저에 어떤 종류의 스토리지 기술이 사용되는지 알 필요가 없어야 하고, 동일한 방식으로 파드를 실해하기 위해 어떤 유형의 물리 서버가 사용되는지 알 필요가 없어야 한다.

6.5.1 퍼시스턴트볼륨과 퍼시스턴트볼륨클레임 소개

  • 퍼시스턴트볼륨(PV)과 퍼시스턴트볼륨클레임(PVC)는 인프라스트럭처의 세부 사항을 처리하지 않고 애플리케이션이 쿠버네티스 클러스터에 스토리지를 요청할 수 있도록 하기 위해 도입된 리소스이다.


6.5.2 퍼시스턴트볼륨 생성

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mongodb-pv
spec:
  capacity: 
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  gcePersistentDisk:
    pdName: mongodb
    fsType: ext4
  • 퍼시스턴트볼륨을 생성할 때 쿠버네티스에게 용량이 얼마가 되는지 단일 노드나 동시에 다수 노드에 읽기나 쓰기가 가능한지 여부를 알려야 한다.
  • 또한 퍼시스턴트 볼륨이 해제되면 어떤 동작을 해야 할지 알려야 한다.
  • 마지막으로 퍼시스턴트볼륨을 지원하는 실제 스토리지 유형, 위치, 그 밖의 속성 정보를 지정해야 한다.

  • 아직 퍼시스턴트볼륨클레임을 생성하지 않았으므로 퍼시스턴트볼륨이 Available로 표시된다.


6.5.3 퍼시스턴트볼륨클레임 생성을 통한 퍼시스턴트볼륨 요청

퍼시스턴트볼륨클레임 생성하기

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongodb-pvc 
spec:
  resources:
    requests:
      storage: 1Gi
  accessModes:
  - ReadWriteOnce
  storageClassName: ""
  • 퍼시스턴트볼륨클레임이 생성되자마자 쿠버네티스는 적절한 퍼시스턴트볼륨을 찾고 클레임에 바인딩한다.
  • 퍼시스턴트볼륨의 용량과 접근 모드는 클레임의 요청을 수용할 수 있어야 한다.

퍼시스턴트볼륨클레임 조회하기

  • 클레임이 퍼시스턴트볼륨 mongodb-pvc에 Bound 되었음을 나타낸다.
  • 접근 모드로 사용되는 약어
    • RWO(ReadWriteOne): 단일 노드만이 읽기/쓰기용으로 볼륨을 마운트할 수 있다.
    • ROX(ReadOnlyMany): 다수 노드가 읽기용으로 볼륨을 마운트할 수 있다.
    • RWX(ReadWriteMany): 다수 노드가 읽기/쓰기용으로  볼륨을 마운트할 수 있다.

 

퍼시스턴트볼륨 조회하기

  • 퍼시스턴트볼륨이 Bound 상태가 되어 더 이상 Available로 표시되지 않으며 default/mongodb-pvc 클레임에 바인딩됨을 보여준다.
  • 퍼시스턴트볼륨은 클러스터 수준의 리소스이므로 특정 네임스페이스에 생성할 수 없으며, 동일한 네임스페이스의 파드에서만 사용할 수 있다.

6.5.4 파드에서 퍼시스턴트볼륨클레임 사용하기

  • 파드 내부에서 볼륨을 사용하기 위해 다음과 같이 퍼시스턴트볼륨클레임을 참조한다.
apiVersion: v1
kind: Pod
metadata:
  name: mongodb 
spec:
  containers:
  - image: mongo
    name: mongodb
    volumeMounts:
    - name: mongodb-data
      mountPath: /data/db
    ports:
    - containerPort: 27017
      protocol: TCP
  volumes:
  - name: mongodb-data
    persistentVolumeClaim:
      claimName: mongodb-pvc
  • 파드가 동일 퍼시스턴트 볼륨과 기반 GCE PD를 사용하는지 확인해보자.
  • mongoDB 셸을 다시 실행해보면 이전에 저장한 데이터를 확인할 수 있어야 한다.

6.5.5 퍼시스턴트볼륨과 퍼시스턴트볼륨클레임 사용의 장점 이해하기

  • 개발자는 실제 스토리지 기술을 알 필요가 없으며, 파드와 클레임 메니페스트는 인트라스터럭처와 관련된 어떤 것도 참조하지 않으므로 다른 쿠버네티스 클러스터에서도 사용할 수 있다.

6.5.6 퍼시스턴트볼륨 재사용

  • 파드와 퍼시스턴트볼륨클레임을 삭제하고 재생성한 후 결과를 확인해보자

  • 클레임의 상태가 Pending으로 표시된다. 즉시 퍼시스턴트볼륨에 바인딩되지 않은 이유는 무엇일까?

  • 퍼시스턴트볼륨을 조회해보면 STATUS가 Released로 표시되어 있다.
  • 이미 볼륨을 사용해서 데이터를 가지고있기 때문에 클러스터 관리자가 볼륨을 완전히 비우지 않으면 새로운 클레임에 바인딩할 수 없다.
  • 볼륨을 비우지 않았다면 동일한 퍼시스턴트볼륨을 사용하는 새 파드는 이전 파드가 저장한 데이터를 읽을 수 있다.

퍼시스턴트볼륨을 수동으로 다시 클레임하기

  • persistentVolumeClaimPolicy를 Retain으로 설정하면 클레임이 해제되어도 볼륨과 콘텐츠를 유지한다.
  • 수동으로 재사용하려면 퍼시스턴트볼륨 리소르를 삭제하고 다시 생성해야 한다.

퍼시스턴트볼륨을 자동으로 다시 클레임하기

  • Recycle 정책은 볼륨의 콘텐츠를 삭제하고 볼륨이 다시 클레임될 수 있도록 볼륨을 사용 가능하게 만든다.
  • Delete 정책은 기반 스토리지를 삭제한다.


6.6 퍼시스턴트볼륨의 동적 프로비저닝

  • 클러스터 관리자가 퍼시스턴트볼륨을 생성하는 대신 퍼시스턴트볼륨 프로비저너를 배포하고 사용자가 선택 가능한 퍼시스턴트볼륨의 타입을 하나 이상의 스토리지클래스 오브젝트로 정의할 수 있다.
  • 사용자가 퍼시스턴트볼륨클래스에서 스토리지클래스를 참조하면 프로비저너가 퍼시스턴트 스토리지를 프로비저닝할 때 이를 처리한다.


6.6.1 스토리지클래스 리소스를 통한 사용 가능한 스토리지 유형 정의하기

  • 스토리지클래스 리소스는 퍼시스턴트볼륨클레임이 스토리지클래스에 요청할 때 어떤 프로비저너가 퍼시스턴트볼륨을 프로비저닝하는 데 사용돼야 할지를 지정한다.
  • 스토리지클래스에 정의된 파라미터들은 프로비저너에 전달되며, 파라미터는 각 프로비저너 플러그인마다 다르다.

6.6.2 퍼시스턴트볼륨클레임에서 스토리지 클래스 요청하기

  • 크기와 접근 모드를 지정하는 것 외에도 퍼시스턴트볼륨클레임에 사용할 스토리지클래스를 지정해야 한다.
  • 클레임을 생성하면 fast 스토리지클래스 리소스에 참조된 프로비저너가 퍼시스턴트볼륨을 생성한다.

 

동적 프로비저닝된 PV와 생성된 PVC 검사하기

  • VOLUME 열은 클레임에 바인딩된 퍼시스턴트볼륨을 표시한다.

  • 동적으로 프로비저닝된 퍼시스턴트볼륨을 볼 수 있으며, 리클레임 정책은 Delete로 PVC가 삭제되면 퍼시스턴트 볼륨이 삭제됨을 의미한다.
  • PV 외에 실제 스토리지도 프로비저닝 되었으며, fast 스토리지클래스는 GCE 퍼시스턴트 디스크를 프로비저닝하는 kubernates.io/gee-pd 프로비저너를 사용하도록 설정됐다.

 

스토리지 클래스 사용하는 법 이해하기

  • 클러스터 관리자는 성능이나 특성이 다른 여러 스토리지 클래스를 생성하고, 개발자는 각 클레임에 가장 적합한 스토리지를 결정한다.
  • 스토리지클래스는 클레임 이름으로 참조되므로 다른 클러스터 간의 스토리지 클래스 이름을 동일하게 사용하면 PVC 정의들 다른 클러스터로 이식 가능하다.
728x90
Comments