kubernetes 의 볼륨
쿠버네티스는 볼륨을 컨테이너에 탑재할 수 있다는 사실.
- 다양한 볼륨 유형과 드라이버를 지원함.
- 다른 클라우드 및 호스팅 프로바이더에서도 실행할 수 있으므로 데이터 실제 저장 위치에 매우 유연하다.
- 로컬 볼륨, 클라우드 프로바이더 특정 볼륨 등…
- 도커 볼륨과 비슷하지만 좀 더 강력(?)하다.
- 도커 볼륨 시스템을 활용하지만 더 많은 기능과 옵션이 있다!
kubernetes 와 docker 의 볼륨
- 쿠버네티스에 많은 볼륨 유형이 있지만 컨테이너 내부에서 볼륨이 동작하는 방식은 다르지 않다.
- 다만, 컨테이너 외부에 저장되는 방식이 쿠버네티스와 유형이나 드라이버에 따라 다르다.
볼륨
볼륨은 pod 에 연결되고 pod 별로 다르니까 pod 를 구성하는 위치에 볼륨을 정의해야 한다! → Like deployment.yml
- 쿠버네티스 볼륨은 기본적으로 pod 와 수명이 같다.
- 컨테이너 밖과 pod 내에 있기에
emptyDir
볼륨 디폴트 설정
containers:
- name: story
image: holidaykang/kub-data-demo:1
volumeMounts:
# dockerfileDirectory/text파일생성디렉토리
- mountPath: /app/story
# 볼륨 이름
name: story-volume
volumes:
- name: story-volume
emptyDir: {}
- Pod 가 시작될 때마다 빈 디렉토리 생성
- 파드가 살아있는 한 디렉토리 활성 상태로 유지, 데이터 채우기.
- 컨테이너가 재시작되거나 제거되더라도 데이터는 유지
- 하지만 pod 가 제거 되는 경우, 디렉토리도 제거
- pod 가 재생성되면 새 디렉토리 생성
emptyDir 의 단점
파드가 여러 개인 경우 데이터가 열리지 않을 수도 있다.
사례
- replica 가 2인 파드가 있다.
- 파드1이 오류가 생겨 종료되었다.
- 요청이 파드2로 가면 볼륨에 저장된 데이터를 반환할 수 없다.
- 볼륨은 파드와 연결되어 있기 때문에 다른 볼륨과 연결되지 않은 다른 파드로 요청이 전송되면 데이터를 확인할 수 없다..!
hostPath
호스트 머신의 경로에서 볼륨 설정. 동일한 파드에서 모든 요청을 처리하는 경우에만 유용함. 호스트와 데이터 공유.
containers:
- name: story
image: holidaykang/kub-data-demo:1
volumeMounts:
# dockerfileDirectory/text파일생성디렉토리
- mountPath: /app/story
# 볼륨 이름
name: story-volume
volumes:
- name: story-volume
hostPath:
# 호스트 머신의 경로
path: /data
# 위 경로를 처리하는 방법 (지금 경우는 존재하지 않으면 생성한다는 전략)
type: DirectoryOrCreate
- 호스트와 폴더를 공유하는 것이라고 할 수 있다.
- 이미 존재하는 데이터를 컨테이너에 공유하려는 경우도 유용하다.
hostPath 단점
- 노드에 특정적이다.
- 여러 워커 노드가 있는 더 큰 클러스터의 경우엔 동일안 데이터에 엑세스할 수 없다.
CSI (Container Strage Interface)
쿠버네티스가 제공하는 볼륨용 인터페이스. 클라우드 프로바이더가 제공하는 데이터 센터 등 모든 스토리지 솔루션에서 CSI 드라이버를 활용해 컨테이너와 다른 프로바이더를 연결 가능함!
영구 볼륨
pod 와 node 에 독립적임. 클러스터가 볼륨 권한을 가짐.
- 클러스터에 새 리소스, 새 엔티티를 가짐.
- 영구 볼륨 클레임을 만듬
- 파드 옆에 추가되지만, 영구볼륨은 파드나 노드에 속해있지 않음. 그냥 참고용 객체라고 보면 됨
- 영구 볼륨을 → CSI 유형을 사용해서 → 특정 클라우드 스토리지 서비스로 연결해서 실무 적용!
호스트 볼륨으로 영구 볼륨 실습해보기 !
참고로 호스트 볼륨은 단일 노드 테스트 환경에서만 작동한다. (클라우드 스토리지 서비스에서는 안 됨)
- 볼륨 정의하기
apiVersion: v1
# 영구 볼륨
kind: PersistentVolume
metadata:
name: host-pv
spec:
capacity:
# 저장 용량 (1GB)
storage: 1Gi
# 저장 유형 (가상 머신 내부의 파일 시스템에 폴더가 있기 때문에 파일 시스템 스토리지로 설정)
volumeMode: Filesystem
# 액세스 방법 (볼륨 만드는 방법 정의, 여러개 가능)
accessModes:
# 단일 노드에 의해, 읽기/쓰기 볼륨으로 마운트 가능, 여러 Pod 에 의해 수행되지만 모두 동일한 노드여야 함.
- ReadWriteOnce
# 읽기 전용이지만 여러 노드에서 요청 가능, 그러나 hostPath 는 사용할 수 없음. -> hostPath 는 한 노드에 정의되기 때문
# - ReadOnlyMany
# ReadOnlyMany 에서 쓰기 권한 추가, 마찬가지로 hostPath 는 사용 불가.
# - ReadWriteMany
# 기본 스토리지 구성을 사용해도 충분
storageClassName: standard
# 노드와 독립적이지 않으며 노드가 하나만 있는 경우에만 작동.
hostPath:
path: /data
type: DirectoryOrCreate
한번만 만들면 어느 파드에서든 동일한 영구 볼륨을 사용 가능하다 ^0^/)
엑세스 모드
- ReadWriteOnce : 단일 노드에 의해 읽기/쓰기 볼륨으로 마운트 가능, 여러 Pod 에 의해 수행되지만 동일한 노드에서 진행.
- ReadOnlyMany : 읽기 전용, 여러 노드에서 요청 가능. → hostPath 사용 불가
- ReadWriteMany : 읽기/쓰기 전용. 역시 여러 노드에서 요청 가능. → hostPath 사용 불가
hostPath 사용 불가 이유 : hostPath 는 한 노드에 정의되지만 —Many 는 여러 노드에서 요청하기 때문.
영구 볼륨 클레임 생성
볼륨 클레임 설정 yml 파일
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: host-pvc
spec:
# 영구 볼륨 이름
volumeName: host-pv
accessModes:
- ReadWriteOnce
# 기본 스토리지 구성을 사용해도 충분
storageClassName: standard
# 볼륨 설정의 capacity 에 대응.
resources:
requests:
# 볼륨에 대한 용량 요구치, 최대는 요구하는 볼륨 최대 용량이며 그거보다 더 적게 요청도 가능.
storage: 1Gi
- 구성을 보면 알겠지만 파드와 연결하는 것이 아니다.
- 이 설정으로 파드에서 영구 볼륨에 대한 클레임을 만드는 것임.
- 이제 deployment.yml 로 가서 파드와 클레임을 연결한다.
스토리지 클래스
쿠버네티스에서 관리자에게 스토리지 관리 방법 / 볼륨 구성 방법을 세부적으로 제어할 수 있게 해줌.
- 우리가 설정한 PersistentVolume 구성에 중요한 정보를 제공한다.
실행해보기
kubectl apply -f=host-pv.yml
kubectl apply -f=host-pvc.yml
kubectl apply -f=deployment.yml
# 영구 볼륨 리스트 불러와보기
kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
host-pv 1Gi RWO Retain Bound default/host-pvc standard 42s
# 클레임 리스트 불러오기
kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
host-pvc Bound host-pv 1Gi RWO standard 2m7s
- 쿠버 대시보드 참고
볼륨 vs 영구 볼륨
모든 볼륨은 컨테이너와는 독립적이지만 파드와는 별개가 아니다.
볼륨
- 파드와 생명 주기가 같다. 파드가 삭제되면 파드에 연결된 데이터가 지워질 수도 있다.
- 파드 설정 파일과 동일한 파일에 볼륨을 정의한다.
- 큰 서비스같은 경우 여러 디플로이먼트, 여러 파드, 각각 볼륨설정을 하려면 계속 코드를 반복해서 짜증날 수 있음.
영구 볼륨
- 스탠드 얼론으로, 특정 파드에 직접 연결되진 않음.
- 한번 정의해놓고, 그 볼륨을 클레임으로 생성해 연결한다.
- 구성이 하나의 파일에 있으니 재사용하기 쉽다. 반복 횟수가 적어짐. 큰 프로젝트에 용이함.
- 데이터가 손실되지 않도록 보장해줌.
728x90
'개발공부 개발새발 > Kubernetes' 카테고리의 다른 글
Kubernetes ) Environment (0) | 2024.04.24 |
---|---|
Kubernetes ) 선언적 접근 방식으로 쿠버네티스 사용해보기 (0) | 2024.04.22 |
Kubernetes ) 명령적 접근 방식으로 쿠버네티스 사용해보기 (0) | 2024.04.22 |
Kubernetes ) 쿠버네티스가 뭐냐~면 (0) | 2024.04.17 |