07 Volume
07 Volume
1. Note
1. Note
- 볼륨
- 볼륨은 각기 위치가 언제까지 존재하고
- 어디까지 접근이 가능한지 파악이 필요.
- 생성된 데이터들을 어떻게 잡아서 사용할 것인가
2. Volume
1. Volume
- Kubernetes 볼륨은 Pod 내의 하나 이상의 컨테이너가 사용할 수 있는 데이터 저장 공간
- 볼륨은 Pod의 일부로서,
컨테이너가 종료되거나 재시작될 때 데이터를 유지할 수 있게해줌 - 네트워크 디스크, 로컬 디스크 등 다양한 백엔드를 지원하며, 여러 컨테이너가 데이터를 공유할 수 있음
2. point
- POD는 내부 컨테이너를 선언한 상태로 유지하려고함.
- 컨테이너의 AP가 작업중에 문제가 생겨서 죽을 경우에는,
- 데이터도 같이 손실이 발생함.
- 이때 Volume 통해서 데이터 손실을 막고 지속적인 공유가 가능함.
- 데이터를 AP에서 지속적으로 생성/공유하는 경우
- 생성된 데이터를 여러 POD에서 동시에 접근하고,
- 필요에 따라서 사용, 제거 하는 경우 POD 접근이 필요.
- 이때 데이터 공용 공간에 저장해두면 별도 연결없이 공용 Volume에서 사용가능 함.
3. 구조
1
2
3
4
5
6
7
8
9
Pod
└── Volume (사용 방식)
├── emptyDir
├── hostPath
└── PVC (요청 방식)
↓
PV (실제 스토리지)
↓
NFS / EBS / 로컬디스크 / 기타 스토리지
3. emptyDir
1. emptyDir
- Pod가 생성될 때 함께 생성되는 임시 저장소
- 같은 Pod 내부 컨테이너끼리 데이터를 공유할 수 있음
Pod가 삭제되면 데이터도 함께 삭제됨- 컨테이너 재시작에는 유지되지만, Pod 자체가 사라지면 유지되지 않음
2. 용도
- 캐시 데이터
- 임시 파일 저장
- 컨테이너 간 데이터 공유
3. yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
volumes:
- name: shared-data # 볼륨 이름(ID) - 컨테이너가 이 이름으로 참조
emptyDir: {} # Pod 생성 시 비어있는 임시 저장공간 생성
# Pod 살아있는 동안 유지
# Pod 삭제 시 데이터 삭제
containers:
- name: app # app 컨테이너
volumeMounts:
- name: shared-data # 위에서 등록한 volume(shared-data) 연결
mountPath: /shared # app 컨테이너 내부에서 접근할 경로
- name: nginx # nginx 컨테이너
volumeMounts:
- name: shared-data # 같은 volume(shared-data) 연결
mountPath: /shared # nginx 내부에서도 같은 경로로 접근
4. hostPath 방식
1. hostPath
- Worker Node의 실제 디렉토리를 Pod 내부에 마운트하는 방식
Pod가 삭제되어도 Node에 데이터가 남음- 같은 Node에 다시 스케줄링되면 기존 데이터 재사용 가능
- 특정 Node의 파일 시스템을 직접 사용하는 구조
2. 용도
- 노드 로그 접근
- Docker/container runtime socket 공유
- 로컬 파일 접근
- 개발/테스트 환경의 영속 저장
3. yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
spec:
volumes:
- name: host-storage # 볼륨 이름(ID) - volumeMounts에서 이 이름으로 참조
hostPath: # hostPath 방식 사용 (워커노드 실제 경로 연결)
path: /data/shared # 워커노드 실제 디렉토리 경로
type: DirectoryOrCreate # 디렉토리 없으면 자동 생성
containers:
- name: app # 컨테이너 이름
image: nginx # 사용할 컨테이너 이미지
volumeMounts:
- name: host-storage # 위에서 등록한 볼륨 이름과 매칭
mountPath: /shared # 컨테이너 내부에서 접근할 경로
4. type
| type | 의미 | 주 용도 | 특징 | 실패 조건 |
|---|---|---|---|---|
DirectoryOrCreate | 디렉토리 없으면 생성 | 로그 저장, 임시 데이터, 개발환경 | 가장 많이 사용. 경로 자동 생성 | 거의 없음 |
Directory | 디렉토리 반드시 존재 | 운영 환경의 사전 생성 경로 | 실수 방지용 | 디렉토리 없으면 Pod 시작 실패 |
FileOrCreate | 파일 없으면 생성 | 설정파일, lock 파일 | 빈 파일 자동 생성 | 상위 디렉토리 없으면 실패 |
File | 파일 반드시 존재 | 설정파일 강제 사용 | 파일 검증용 | 파일 없으면 Pod 시작 실패 |
Socket | Unix Socket 이어야 함 | Docker/Container Runtime 연결 | IPC(프로세스 통신)용 | socket 파일 아니면 실패 |
CharDevice | Character Device | 하드웨어 장치 접근 | 키보드, tty, serial 장치 | char device 아니면 실패 |
BlockDevice | Block Device | 디스크 직접 마운트 | SSD/HDD raw access | block device 아니면 실패 |
5. PVC/PV
1. Point
- 컨테이너에서 직접
Volume를 마운트하던 것을 - PVC/PV 오브젝트로 추상화해서 대신 처리하도록함.
- 컨테이너 자체에서는 무엇을 어디에 어떻게 해야하는지 책임이 사라짐
- 단지 그냥 PVC로 연결해버리면 됨.
2. PVC/PV
- Kubernetes에서
영속 스토리지(Persistent Storage)를 사용하는 표준 방식 - Pod는 직접 스토리지를 쓰지 않고
PVC(PersistentVolumeClaim)를 요청함 - PVC가 조건에 맞는
PV(PersistentVolume)와 연결(Binding)됨 - 실제 저장소는 NFS, EBS, Ceph, Local Disk 등 다양한 백엔드 사용 가능
3. 용도
- DB 데이터 저장
- 업로드 파일 저장
- Pod 재생성 후에도 유지되어야 하는 데이터
4. yaml
1. PV(실제 저장소)
Yaml
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
apiVersion: v1 kind: PersistentVolume metadata: name: app-pv spec: capacity: storage: 5Gi # 저장 가능 용량 accessModes: - ReadWriteOnce # 하나의 노드에서 read/write 가능 persistentVolumeReclaimPolicy: Retain # PVC 삭제돼도 데이터 유지 hostPath: path: /data/pv-storage # Worker Node 실제 저장 위치정책 종류
정책 의미 데이터 유지 주 용도 RetainPV 남김 O 운영, DB DeletePV 삭제 X 클라우드 자동 관리 Recycle데이터 비우고 재사용 Deprecated 과거 버전
2. PVC(요청서)
1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: app-pvc
spec:
accessModes:
- ReadWriteOnce # PV와 조건 맞아야 함
resources:
requests:
storage: 1Gi # 1GB 요청
3. 파드
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
volumes:
- name: app-storage
persistentVolumeClaim:
claimName: app-pvc # PVC 이름 연결
containers:
- name: nginx
image: nginx
volumeMounts:
- name: app-storage
mountPath: /shared # 컨테이너 내부 경로
This post is licensed under CC BY 4.0 by the author.