Persistence Volume(PV)
docker에도 volume이 있음.
-> 컨테이너의 데이터를 영구적으로 보관하기 위해서 이용함.
-> POD 에도 이를 지원하는 기능이 있음.
apiVersion: v1
kind: Pod
metadata:
name: tmp
spec:
containers:
- image:
...
volumeMounts:
- mountPath: /opt //컨테이너 내부 경로
name: data-volume
volumes:
- name: data-volume
hostPath:
path:/data
type: Directory하지만 클러스터에서는 권장하지 않는 방법이라고 함.(단일 노드는 상관이 없음.)
-> 이는 모든 노드의 /data 에 모두 같은 데이터가 있기를 기대하기 때문임.
-> 이를 해결하기 위해서는 k8s가 지원하는 다양한 솔루션을 이용하면 됨.
(NFS, amazon web services 등)
volumes:
- name: data-volume
awsElasticBlockStore:
volumeID: <volume-id>
fsType: ext4이런 식으로 사용 가능.
apiVsersion: v1
kind : PersistentVolume
metadata:
name: pv-voll
spec:
accessModes:
- ReadWriteOnce //ReadOnlyMany, ReadWriteMany 옵션도 있음.
capacity:
storage: 1Gi
hostPath: // 앞에서 처럼 aws 등 다양한 솔루션 사용 가능.
path: /tmp/data
access mode 관련 설명
Persistence Volume Claim
이는 하나의 PV 로 묶여 있음.
-> 더 큰 용량의 PV에 묶일 수도 있음.
-> 사용 가능한 볼륨이 없으면, 보류 상태가 됨.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: cl
spec:
accessModes:
- ReadWriteOnce
resources:
reqeusts:
storage: 500Mi
이는 이전에 생성된(위의 yaml)에 bine 됨.
(위에서는 1기가이며 accessMode가 일치해서)
만약이 PVC가 삭제되면, 해당 볼륨에 어떠한 작업을 수행하는지?
- Retain : 리소스를 수동으로 삭제할 때 까지 다른 claim에서 사용하지 못함.
- Delete: 데이터, PV 삭제
- Recycle: 더 이상 사용하지 않는다고 함.(공식 홈페이지) 대신 동적 프로비저닝이라는 것을 사용한다고 함. 기존 데이터만 삭제
Pod - PVC - PV 를 통해 PVC 를 볼륨처럼 사용할 수 있음.
-> 이렇게 하는 이유는 파드의 각각 상황에 따라서 다양한 스토리지를 사용할 수 있게 해줌.
Storage
앞에서는 PVC를 이용하여 요청하려면, PV 를 계속 만들어줘야 하는 단점이 있음.
-> 이를 static provisioning 이라고 함.
반대는 dynamic provisioning. 이를 위해서 Storage 가 있음.
apiVersion: storage.k8s.io/v1
kind: StroageClass
metadata:
name: google-storage
provisioner: kubernetis.io/gce-pd
parameters:
... //프로비저너에 전달하는 파라미터들. 이는 홈페이지 참고
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: cl
spec:
accessModes:
- ReadWriteOnce
storageClassName: google-storage // 추가된 부분
resources:
reqeusts:
storage: 500Mi
StorageClass에 의해서 PV가 자동으로 생성이 됨.
(PV가 생성되지 않는 것은 아님!!)
ConfigMap
이를 이용하여 Pod에 값을 전달할 수 있음(ENV 등)
k create configmap <config-name> --from-literal=<key>=<value>
k create configmap <config-name> --from-file=<file>
yaml로도 생성 가능.
apiVersion: v1
kind: ConfigMap
metadata:
name: game-demo
data:
# 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨
player_initial_lives: "3"
ui_properties_file_name: "user-interface.properties"
# 파일과 비슷한 키
game.properties: |
enemy.types=aliens,monsters
player.maximum-lives=5
user-interface.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
주의 사항은 이는 암호화를 제공하지 않음.
-> 이를 위해서 k8s의 Secret을 이용하거나 써드파티 도구를 이용하면 됨.
pod 에 해당 정보를 주기 위해서는
apiVersion: v1
kind: Pod
metadata:
name: configmap-demo-pod
spec:
containers:
- name: demo
image: alpine
command: ["sleep", "3600"]
envFrom:
- configMapRef:
name: app-config // config 이름
env 등 주입할 때 다양한 방법이 있음.
apiVersion: v1
kind: Pod
metadata:
name: configmap-demo-pod
spec:
containers:
- name: demo
image: alpine
command: ["sleep", "3600"]
env:
# 환경 변수 정의
- name: PLAYER_INITIAL_LIVES # 참고로 여기서는 컨피그맵의 키 이름과
# 대소문자가 다르다.
valueFrom:
configMapKeyRef:
name: game-demo # 이 값의 컨피그맵.
key: player_initial_lives # 가져올 키.
- name: UI_PROPERTIES_FILE_NAME
valueFrom:
configMapKeyRef:
name: game-demo
key: ui_properties_file_name
volumeMounts:
- name: config
mountPath: "/config"
readOnly: true
volumes:
# 파드 레벨에서 볼륨을 설정한 다음, 해당 파드 내의 컨테이너에 마운트한다.
- name: config
configMap:
# 마운트하려는 컨피그맵의 이름을 제공한다.
name: game-demo
# 컨피그맵에서 파일로 생성할 키 배열
items:
- key: "game.properties"
path: "game.properties"
- key: "user-interface.properties"
path: "user-interface.properties"
'BackEnd > K8S' 카테고리의 다른 글
| [K8S] 쿠버네티스 스터디 - 2(Service, Ingress) (0) | 2024.05.20 |
|---|---|
| [K8S] 쿠버네티스 스터디 - 1(pod, replica set, deployment, namespace) (0) | 2024.05.08 |
