끄적끄적
쿠버네티스의 볼륨 -2 본문
지난 글에 이어 볼륨에 대해 설명하겠다. 마지막 부분으로 네트워크 볼륨이 있다. 네트워크 볼륨은 pv와 pvc을 통해 이루어진다.
PersistentVolume(PV) & PersistentVolumeClaim(PVC)
쿠버네티스는 복잡성을 추상화하고 개발자들이 손쉽게 자원을 사용할 수 있도록 하는 개념을 가지고 있다. 임시, 로컬 디스크가 아닌 디스크 볼륨을 설정하려면 물리적인 스토리지를 생성하고 관리해야 하는데, 이는 개발자에게 부담이 될 수 있다.
따라서 시스템 관리자는 인프라에 대한 것에 집중하도록, 개발자는 개발에 관해 집중하도록 하는 개념이 PV, PVC이다.
시스템 관리자가 스토리지를 생성하고 이를 PersistentVolume으로 쿠버네티스에 등록하면, 개발자는 Pod를 생성할 때, 볼륨을 정의하고 PersistentVolumeClaim을 지정하여 시스템 관리자가 생성한 PV에 연결한다.
(출처: https://gruuuuu.github.io/cloud/k8s-volume/# )
PV
- 시스템 관리자에 의해 제공된 이용 하거나 동적프로비저닝 된 클러스터에 저장하는 부분
- Pod와 별개로 관리되고 별도의 생명주기를 가진다.
- Local, Azuer, AWS 등의 저장소를 정의하고 연결한다.
PVC
- 사용자에 의해 어떤 저장소를 사용할지에 대한 요청 명세
- Pod는 자신이 어떤 스토리지를 사용하고 있는지 신경 쓰지 않아도 된다.
pv, pvc의 생명주기
- pv, pvc는 4가지의 형태를 갖고 변화한다.
- 프로비저닝(Provisioning)
pv를 사용하기 위해서 pv를 만드는 단계이다. pv 프로비저닝 방법에는 2가지가 있는데, pv를 미리 만들어두고 사용하는 정적(static) 방법과 pv를 만드는 동적(dynamic) 방법이 있다.
정적인 방법은 클러스터 관리자가 미리 pv를 만들어두고 사용자 요청이 있을 시 미리 만들어둔 pv를 할당하는 방식이다.
동적인 방법은 pv를 미리 준비해두는 것이 아니고 사용자가 pvc로 요청 시 pv를 생성해서 제공해주는 방식이다.
- 바인딩(Binding)
프로비저닝을 통해 만들어진 pv와 pvc를 바인딩하는 단계이다. pvc가 원하는 스토리지 용량과 접근방법을 명시해서 요청하면 거기에 맞는 pv가 할당된다. 맞는 pv가 없어 pvc 요청 실패 시엔 계속 대기하고 있다가 맞는 pv가 생기면 바인딩된다. pv와 pvc가 1대 1로 매핑되고, 하나의 pvc에 여러 pv가 바인딩될 수 없다.
- 사용중(Using)
할당된 pvc는 포드가 유지되는 동안 계속 사용되고, 사용 중엔 임의로 pvc를 삭제할 수 없다. 이를 스토리지 객체 보호라고 한다.
- 리클레이밍(Reclaimg)
사용이 끝난 pvc는 삭제하고 pvc가 사용했던 pv를 초기화하는 단계이다. Retain, Delete, Recycle의 3가지가 있다.
- Retain: pv를 그대로 보존함을 의미. 사용이 끝나도 pv안에 데이터는 그대로 유지된다.
- Delete: pv를 삭제하고 연계되어 있는 외부 스토리지 볼륨도 삭제한다.
- Recycle: pv 데이터를 삭제하고 pv를 다시 새로운 pvc에서 사용 가능한 형태로 만들어둔다.
실습하기
1. hostpath를 사용하여 pv, pvc 실습하기
- pv 생성
- spec.volumeMode: 볼륨을 파일 시스템으로 사용
- spec.accessModes: pod의 접근제어
- ReadWriteOnce: 하나의 pod에서만 읽고 쓸 수 있음
- ReadOnlyMany: 여러 개의 pod에서 읽을 수 있음
- ReadWriteMany: 여러개의 pod에서 읽고 쓸 수 있음
- spec.storageClassName: 스토리지 클래스를 지정하고 해당 클래스에 맞는 pvc와 연결
- spec.PersistentVolumeReclaimPolicy: 위에 지정한 retain, delete, recycle 중 하나. 볼륨 종료 시 삭제
- hostPath: 노드에 저장되는 디렉터리를 설정
- pvc 생성
pvc를 생성한 뒤 확인해보면 잘 바인딩되어서 Bound가 된 것을 볼 수 있다.
- pvc를 사용할 디플로이먼트 생성
- metadata.labels.app: deployment의 레이블을 설정
- spec.selector: 어떤 레이블의 파드를 선택하여 관리할 것인지 설정. 앱 컨테이너의 test-deployment레이블을 식별하여 해당되는 피드들을 관리.
- spec.template.metadata: 어떤 파드에 실행할지에 대한 정보를 설정
- spec.template.spec.containers.volumeMounts: 볼륨 마운트 할 컨테이너 안의 경로를 작성하고, 이 경로를 저장한 볼륨 마운트 정보를 dev-volume이라는 이름으로 지정
- spec.template.spec.volumes: 위에 작성한 컨테이너에서 사용할 볼륨 마운트 이름을 가져오고, 이 정보와 연결 요청을 보낼 pvc를 dev-pvc로 지정. 이때 이름은 pvc의 이름과 같아야 함
pod의 정보를 출력해보면 slave2에 생성된 것을 확일할 수 있다.
퍼드에 접속하여 마운트 경로로 이동한 뒤 test 1이라는 텍스트를 생성해주었다.
slave2에서 /tmp/log_backup으로 이동하여 보니 test1이 생성된 것을 확인할 수 있다.
2. NFS를 이용한 pv, pvc 실습하기
이번에는 물리적인 스토리지를 통한 pv, pvc를 실습해보고자 한다. 이를 위해 우선 nfs를 설치하였다.
참고)
nfs 서버와 클라이언트에 관한 유틸을 모두 설치한 뒤, 마운트 할 공유 디렉터리를 생성하고,
mount -t nfs {ip 또는 호스트 이름} /마운트 디렉터리 경로/
명령어를 통해 마운트 한다. 나는 서버 클라이언트 모두 master노드에 설정하였다. 또 방화벽을 이미 다 내려두었기 때문에 따로 해제하지 않았다.
참고한 글
- https://psnote.tistory.com/196
https://server-talk.tistory.com/117
https://makebob.tistory.com/163
- pv 생성
- pvc 생성
pv, pvc를 생성 후 확인하였더니 잘 바인딩되었다.
- deployment 생성
deployment를 생성한 뒤 pod를 확인해본 결과 정상 동작함을 확인할 수 있다. 처음에 생성하였을 땐 바인딩까지는 잘되었는데, 컨테이너가 생성하는 부분에 있어 충돌이 생겨 제대로 작동하지 않았다. deployment 파일을 꼼꼼히 살펴 조정하였더니 문제를 해결할 수 있었다.
생성된 pod에 접속하여 test.txt라는 파일을 생성하였다.
설정해둔 디렉터리로 이동하여 확인해보니 test.txt 파일이 있는 것을 확인할 수 있다.
참고자료
https://psnote.tistory.com/196
https://gruuuuu.github.io/linux/basic-nfs/#
https://gruuuuu.github.io/cloud/k8s-volume/#
https://waspro.tistory.com/580
https://arisu1000.tistory.com/27849
'클라우드' 카테고리의 다른 글
| 쿠버네티스 jira, jenkins, gitlab을 통한 CICD (0) | 2020.10.19 |
|---|---|
| 쿠버네티스의볼륨 - 1 (0) | 2020.08.10 |
| 도커 스웜 시작하기 (0) | 2020.07.31 |
| 컨테이너 생성하기 (0) | 2020.07.17 |
| 컨테이너 (0) | 2020.07.09 |
