[기본 오브젝트] Volume
본문은 인프런의 대세는 쿠버네티스 [초급~중급] 강의를 정리한 글입니다.
모든 본문의 내용과 이미지의 출처는 강의자료에 있습니다.
Volume
empthDir
- Container들끼리 데이터를 공유하기 위해 Volume을 사용
- 최초 Volume이 생성될 때는 Volume 안에 내용이 비어있기 떄문에 emptyDir이라고 명칭된 것이다.
- 이미지 예시
- Container1 : Web 역할 서버
- Container2 : Backend 처리 서버
- 웹서버인 Container1에서 받은 특정 파일을 마운트된 Volume에 저장을 해두고, Backend단의 Container1 역시 이 Volume을 마운트해두면 두 서버가 이 Volume을 자신의 Local 에 있는 파일처럼 사용하기 때문에 두 서버가 서로 파일을 주고받을 필요없이 편리하게 사용할 수 있다.
- Volume은 pod 안에 생성되는 것이기 때문에, pod에 문제가 발생해서 재생성되면 데이터가 삭제된다.!!!!
- 이 Volume에 쓰이는 데이터는 꼭 일시적인 사용목적에 의한 데이터만 넣는 것이 좋다.
containers: volumeMounts: mountPath
: 이 Container가 이 Path로 Volume을 연결하겠다.spec: volumes: emptyDir: {}
hostPath
- 한 Host 즉, Pod들이 올라가져 있는 Node의 Path를 Volume으로서 사용
- Volume Path를 각각의 Pod들이 마운트해서 공유하기 때문에 Pod들이 죽어도 Volume(Node(에 있는 데이터는 사라지지 않는다.
- Pod 입장에서 문제가 있다.
- Pod가 죽어서 재생성될 때, 꼭 동일한 Node에 재생성되리란 보장이 없다.
- 스케쥴러가 자원 상황을 보고 다른 Node에 Pod을 만들 수 있다.
- 또는, Node1에 장애가 생겨서 다른 Node에 Pod이 옮겨질 수도 있다.
- pod가 Node2로 옮겨 졌을 때, Node1에 있는 Volume에 마운트할 수 없게 된다.
- hostPath이기 때문에, 자신의 pod이 올라가져 있는 Node만 사용할 수 있다.
- 해결법?
- Node2가 추가될 때마다 똑같은 이름의 경로를 만들어서 직접 Node에 있는 Path끼리 마운트 시켜주면 문제는 해결된다.
- 이렇게 구성하는 것이 어렵지는 않지만 쿠버네티스가 해주는 부분은 아니고 운영자가 직접 Node가 추가될 때 마다 리눅스 시스템 별도의 마운트 기술을 사용해서 연결을 해줘야 한다.
- 자동화할 때 사람의 기술이 들어가야하는 부분은 실수가 발생할 수 있어서 추천하는 방법은 아니다.
- 어떨 때 사용?
- 각각의 Node에는 각 노드 자신을 위해서 사용되는 파일(시스템 파일, 설정파일)들이 있다.
- Pod의 데이터를 저장하기 위한 용도가 아니라 Node에 있는 데이터를 사용하기 위한 것
- Pod 자신이 할당되어있는 Host의 데이터를 읽거나 써야될 때 사용하면 된다.
- HostPath Type
- DirectoryOrCreate : 실제 경로가 없다면 생성
- Directory : 실제 경로가 있어야됨
- 주의사항
- 이 옵션은 pod가 만들어지기 전에 사전에 만들어져 있어야지 pod가 생성될 때 에러가 나지 않는다.
- 주의사항
- FileOrCreate : 실제 경로에 파일이 없다면 생성
- File : 실제 파일이 었어야함
-
실습
spec: nodeSelector: kubernetes.io/hostname: k8s-node1
: 지금 생성할 Pod는k8s-node1
라는 Node에 만들 것이다.container
에서 접근할 mountPath는/mount1
이고, 마운트할 Volume의 이름은host-path
이다.host-path
가 정의된 Volumevolumes: hostPath
로 지정path: /node-v
: hostPath의 경로는 /node-vtype: DirectoryOrCreate
: 만약 이 path/node-v
가 Node에 없으면 직접 path를 생성한다. (이 경우 사전에 Node에 Path를 만들어둘 필요가 없다.)
apiVersion: v1 kind: Pod metadata: name: pod-volume-3 spec: nodeSelector: kubernetes.io/hostname: k8s-node1 containers: - name: container image: kubetm/init volumeMounts: - name: host-path mountPath: /mount1 volumes: - name : host-path hostPath: path: /node-v type: DirectoryOrCreate
PV/PVC (Persistent Volume, Persistent Volume Claim)
- pod의 영속성있는 Volume을 제공하기 위한 개념이다.
- 실제 Volume의 형태는 다양하다.
- Local Volume
- 외부의 원격으로 사용되는 형태의 Volume
- AWS나 git에 연결
- NFS를 써서 다른 서버와 연결
- STORAGEOS : Volume을 직접 만들고 관리하는 솔루션
- 각각 Persistent Volume을 정의하고 연결한다.
-
Pod는 PV에 바로 연결되지 않고 PVC을 통해서 PV와 연결된다.
- 왜 중간에 PVC를 두지?
- 쿠버네티스는 Volume 사용에 있어서 User 영역과 Admin 영역으로 나눴다.
- Admin 영역 : 쿠버네티스를 담당하는 운영자
- User 영역 : Pod에 서비스를 만들고 배포를 관리하는 서비스 담당자
- PV 정의 생성
-
Volume 종류는 많고 각각의 Volume을 연결하기 위한 설정들도 각각 다르다.
- 따라서 이를 전문적으로 관리하는 Admin이 PV를 만들어 두면
- PVC 생성
- User는 이 PV를 사용하기 위해 PVC를 만들어야 하는데
- PVC를 만들기 위한 설정에서 현재 만들어져있는 PV 중에 선택해서 사용된다.
strageClassName:
(추후에)
-
PV 연결
쿠버네티스가 PVC 내용에 맞는 적절한 Volume에 연결해준다.
PersistentVolume
의spec: capacity
와spec: accessModes
값을 근거로 -
Pod 생성시 PVC 마운팅
-
Pod를 만들 때 앞서 만들어 둔
volumes: name: claimName:
에 PVC를 연결해서 Volume을 만들면, container에서 이 Volume을 사용하면 된다. -
이미지 예시
- Local 타입의 PV는 실제 잘 사용하진 않음
- volumes: persistentVolumeClaim: claimName: pvc-01
- volume을 만들 때,
pvc-01
이라는 이름의persistentVolumeClaim
을 사용하겠다. - containers: volumeMounts: mountPath: /mount3
- 이 volume을 container에서 접근할 때, /mount3이라는 이름으로 접근하겠다.
apiVersion: v1 kind: Pod metadata: name: pod-volume-3 spec: containers: - name: container image: kubetm/init volumeMounts: - name: pvc-pv mountPath: /mount3 volumes: - name : pvc-pv persistentVolumeClaim: claimName: pvc-01