- 파드 공부하면서 파드가 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 : 스토리지 자체를 삭제
- 퍼시스턴트 볼륨 동적 프로비저닝 (스토리지 클래스)
- 지금까지는 직접 스토리지를 생성하고 볼륨과 연결하는 작업을 했지만 이를 자동으로 프로비저닝 해주는 리소스가 있다. 바로 스토리지 클래스.
- 먼저 프로비저너를 배포해야 한다. ( 클라우드에는 대부분 자동으로 있다)
- 스토리지 클래스를 생성해두고 클레임에서 스토리지 클래스를 참조하면 프로비저너가 자동으로 프로비저닝 해준다.
- 만약 수동으로 프로비저닝 하고자 하면 매니패스트 파일에서 스토리지 클래스 부분을 “” 으로 두어야 한다. 아니면 기본 스토리지클래스로 동적 프로비저닝 되게 된다.
'CS > Infra' 카테고리의 다른 글
쿠버네티스 공부 10일차 :: 디플로이먼트 (0) | 2022.11.18 |
---|---|
쿠버네티스 공부 9일차 :: 컨피그맵과 시크릿 (0) | 2022.11.09 |
쿠버네티스 공부 7일차 :: 서비스의 친구 인그레스 (0) | 2022.10.28 |
쿠버네티스 공부 6일차 :: 서비스는 누구지? 파드를 외부와 연결하기 (0) | 2022.10.24 |
쿠버네티스 공부 5일차 :: 파드가 혼자 잘 실행하도록 관리하자 (라이브니스 프로브, 레플리카 셋, 데몬 셋, 잡) (1) | 2022.10.19 |