• 파드 공부하면서 파드가 CPU, RAM, 네트워크 인터페이스 등을 공유한다고 했었다.
    • 하지만 파일시스템은 컨테이너 이미지에서 제공하기 때문에 서로 분리되어 있다.
    • 또한 컨테이너가 재실행 되면 기존 파일들도 초기화 된다.
    • 이런 문제를 해결하는 리소스가 볼륨이다.
  • 볼륨
    • 파드의 spec에서 정의된다.
    • 파드 내의 모든 컨테이너에서 사용할 수 있다.
    • 컨테이너에서 볼륨을 사용하기 위해서는 컨테이너의 spec에도 VolumeMount를 정의해야 한다.
    • 파드의 라이프사이클과 바인딩 되어 파드와 함께 사라지는 볼륨도 있지만, 파드와 볼륨이 사라져도 볼륨의 파일은 유지되고 새로운 볼륨에 마운트 될 수 있는 볼륨 유형도 있다.
  • 볼륨 유형
    • emptyDir: 임시 데이터 저장용 빈 디렉터리
    • hostPath: 워커 노드의 파일시스템을 파드의 디렉터리에 마운트
    • gitRepo: 깃 Repo의 콘텐츠로 초기화한 볼륨 (현재는 deprecated됨)
    • nfs: NFS공유와 파드를 마운트
    • awsElasticBlockStore, azureDisk, gcePersistentDisk: 클라우드의 전용 스토리지를 마운트
    • configMap, secreat: 쿠버네티스 리소스나 클러스트 정보를 파드에 노출하는 데 사용
    • persistentVolumeClaim: 사전에 혹은 동적으로 프로비저닝된 퍼시스턴트 스토리지를 사용하는 방법
  • 볼륨을 포함한 파드 yaml 작성
    • spec에 Volumes로 volume을 정의하고
    • spec에 Containers의 각 컨테이너에 VolumeMounts로 volume을 지정하여 마운트한다.
    apiVersion: v1
    kind: Pod
    ...
    spec:
    	Containers:
    		-image: write-html
    		volumeMounts:
    		- name: html
    			mountPath: /var/htdocs
    		...
    		-image: nginx:alpine
    		volumeMounts:
    		- name: html
    			mountPath: /usr/share/nginx/html
    			readOnly: true
    	Volumes:
    	- name: html
    		emptyDir: {}
    
    • 컨테이너에서 볼륨에 데이터를 쓰면 컨테이너의 Read/Write 레이어가 아닌 볼륨에 쓴다.
  • hostPath 볼륨
    • 노드의 파일에 컨테이너가 마운트를 한다.
    • 동일한 노드 안의 파드들이 노드안의 파일을 공유할 수 있다.
    • 파드가 삭제 되어도 삭제 되지 않는다. (퍼시스턴트 스토리지)
    • 단 파드가 삭제 되고 다른 노드로 이사를 가면 이전 파일을 볼 수 없다.
    • 일반적으로 노드의 시스템 파일에 읽기,쓰기 하기 위해서 쓴다.
    • 파드의 데이터를 유지하기 위해서는 쓰지 않는게 좋다.
  • 클라우드 스토리지를 볼륨으로 만들기
    • 클라우드에 스토리지 생성
    • 파드를 생성하는 yaml의 volumes에 클라우드 유형과 스토리지 이름, 파일시스템 이름 입력
    • 컨테이너의 볼륨 마운트에 방금 적은 volumes의 이름과 mountPath를 지정한다.
    • 이제 영구히 저장되는 볼륨 사용이 가능하다.
    • 그런데 지금까지의 방법은 파드에 볼륨을 지정한다. 파드의 정의가 클러스터와 밀접해지게 되는 것, 다른 클러스트에서는 이 파드 정의를 이용할 수 없다.
    • 그래서 나온 리소스가 퍼시스턴트 볼륨과, 퍼시스턴트 볼륨 클레임 이다.
  • 퍼시스턴트 볼륨, 퍼시스턴트 볼륨 클레임
    • 기반 스토리지 설정 후 퍼시스턴트볼륨 리소스 생성
    • 볼륨의 크기와 지원 가능한 접근 모드 설정
    • 파드에 필요한 스토리지의 최소 크기와 필요한 접근 모드를 적은 퍼시스턴트볼륨클레임 매니페스트(yaml)를 생성
    • 그럼 쿠버네티스가 적절한 퍼시스턴트 볼륨을 찾아서 클레임에 볼륨을 바인딩
    • 이제 클레임은 파드 내부의 볼륨 중 하나로 사용될 수 있음.
    • 사용된 퍼시스턴트 볼륨은 바인딩이 삭제될 때까지 사용 불가
    • +) 퍼시스턴트 볼륨은 클러스터 수준의 리소스여서 네임스페이스에 포함되지 않는다.
  • 접근 모드
    • Read Write Only : 단일 노드만 읽기 쓰기로 마운트 가능
    • Read Only Many : 다수 노드에서 읽기로만 마운트 가능
    • Read Write Many : 다수 노드에서 읽기 쓰기 마운트 가능
  • 리클레임 정책
    • 클레임이 삭제될 때 볼륨을 어떻게 할지 정하는 것
    • retain : 볼륨 데이터를 유지한다. 다만 클레임을 삭제하고 데이터가 남아있으면 이 퍼시스턴트 볼륨은 다시 못쓴다. 퍼시스턴트 볼륨을 삭제하고 다시 생성해야한다. 볼륨을 삭제할때 기존 데이터를 삭제할지 물어본다.
    • recycle : 볼륨의 데이터를 삭제하고 다시 사용할 수 있는 상태로 바꾼다. (유지보수 중단)
    • delete : 스토리지 자체를 삭제
  • 퍼시스턴트 볼륨 동적 프로비저닝 (스토리지 클래스)
    • 지금까지는 직접 스토리지를 생성하고 볼륨과 연결하는 작업을 했지만 이를 자동으로 프로비저닝 해주는 리소스가 있다. 바로 스토리지 클래스.
    • 먼저 프로비저너를 배포해야 한다. ( 클라우드에는 대부분 자동으로 있다)
    • 스토리지 클래스를 생성해두고 클레임에서 스토리지 클래스를 참조하면 프로비저너가 자동으로 프로비저닝 해준다.
    • 만약 수동으로 프로비저닝 하고자 하면 매니패스트 파일에서 스토리지 클래스 부분을 “” 으로 두어야 한다. 아니면 기본 스토리지클래스로 동적 프로비저닝 되게 된다.

+ Recent posts