Kubernetes in Action, Second Edition MEAP V15 정리중
Kubernetes는 이상적으로 어떤 환경에서도 실행과 배포가 가능해야 한다. 따라서 클라우드 스토리지의 실행 환경이나 파일 절대주소등을 넣지 않고도 사용할 방법이 필요하다.
--> PersistentVolume을 사용하자!
PersistentVolume 구조
Persistent Volume
network storage와 pod 사이의 중간과정을 만들어주어 Persistent Volume object에서 pod의 데이터들을 저장한다.
PV에 데이터가 있으므로 pod이 변경돼도 데이터를 보관할 수 있다.
Persistent Volume Claim
pod에서 Persistent volume의 데이터가 필요할 경우 PVC를 통해서 exclusive하게 데이터를 읽을 권한을 받는다.
PVC를 이용해서 접근하므로 Persistent Volume의 세부 저장환경에 구애받지 않고 PV의 이름만으로 연결해서 데이터를 가져온다.
DB의 운영자가 세부 실행환경을 맞추어 Persistent Volume을 설계하고, 이용자는 이것의 고려 없이 자유롭게 application의 데이터를 저장할 수 있다.
Access mode
ReadWriteOnce: 하나의 node에서 RW로 마운트 가능
ReadOnlyMany: 다수의 node에서 읽기 전용으로 마운트 가능
ReadWriteMany: 다수의 node에서 RW로 마운트 가능
ReadWriteOncePod: 노드의 단일 pod에서 RW로 마운트 가능
Dynamic provisioning
정적 provisioning의 단점
물리적 volume을 연결한 이후에 PersistentVolume object를 새로 만들어 주어야 하므로,
물리적 volume이 바인딩되고 해제될 때마다 해당 volume에 대한 PersistentVolume object를 계속 생산/삭제 해주어야함 -> volume의 수가 많아질수록 Kubernetes의 자동화에 악영향
To solve -> dynamic provisioning
우선 cluster admin이 storage class에 따라 PV Provisioner를 만든다. 유저가 PVC object를 먼저 만들면, cluster admin이 요청을 받아 PV Provisioner로부터 적합한 PV를 제공해준다. 제공된 PV와 PVC를 연결하는 것이다.
주의) cluster admin이 cloud같은 외부서버일 경우 Provisioner는 이미 구현되어 있지만, on-premise일 경우 custom provisioner를 직접 만들어줘야 한다.
Dynamic provisioning의 lifecycle
위에서 설명했던 내용과 같다. 유저가 PVC를 생성하면 PV Provisioner가 비동기적으로 PV를 만들어 준 후 바인딩한다.
Node-local persistent volume
네트워크 스토리지말고 로컬 스토리지의 DB들을 이용하면 접근 속도를 향상시킬 수 있다. 이전 장의 Hostpath 볼륨과 다른 점은 다음과 같다.
- hostpath 볼륨은 pod이 다른 node로 rescheduling될 경우 해당 node 권한에 따라 데이터 접근이 안될 수 있다. 그러나 node-local PV의 경우 scheduler 차원에서 PV의 node별 접근권한을 확인해 적절한 node로 pod을 보낼 수 있다.
- PV는 cluster manager에 의해 관리되므로 보안상 더 안전하다.
