Kubernetes Volumes

 

기초용어

Drive: 저장장치

Volume: 논리적인 저장장치 ex. Window의 C:, D:, 독자적인 단일 스토리지 영역

볼륨은 논리적인 저장장치라고 할 수 있음. 우리는 볼륨을 가지고 뭘할거냐?

pod를 보면 스토리지 관련된게 있었지만 이게 어떻게 설치된건지 몰랐음. 포드 안에 볼륨 없이 그냥 웹서버로 기초적으로 deploy를 했지만 실제 포드는 스토리지 기능이 묶여져있다. 볼륨을 붙여준다. Mount Volume이라고 부름. 우린 이 방법에 대해 학습할 거임

즉 pod에 스토리지를 붙이는 것을 배운다.

How to persist data in Kubernetes using volumes?

 🧩

kubernetes.io 가서 좀 모르는 개념들을 찾아보기!‼️ Documentation에 모든 문서들이 다 들어가있음. volume은 전문성있어야 공부할 수 있는 영역이긴함.

들어가서보면 볼륨에도 되게 종류가 많음

</aside>

우리가 배울거는~

emptyDir : pod가 죽으면 사라져버리는 애, 메인메모리 이용한 임시적인 볼륨

hostpath : 서버에 있는 스토리지, 서버를 사서 꾸미면 얘가 존재함. 서버가 고장나거나 다른 노드에서는 사용 못한다는 점에서 제한이 있음. 상용화할 때는 잘 안쓰고 pvc쓴다.

설치자의 입장은 매우 전문적이고, 우리는 사용자의 입장에서 공부하기 때문에 그거는 문서에서 찾아볼 수 있음. 우리는 pv, pvc 두개를 많이 사용함. 여기에 hostpath, emptydir 이런걸 쓰게 됨

이걸 어떻게 쓰는지 오늘 공부할 거다!

The need for volumes

mysql에다가 뭘 추가, 업데이트 할 수 있고, pod가 죽었다살아나도 다시 사용할 수 있어야한다. ⇒ 스토리지가 가져야할 특성(persistence)

(만약 emptydir일 경우는 임시적이기 때문에 pod가 죽었다가 살아나면 다 사라져.)

my-app이라는 pod와, mysql이라는 DB engine역할의 pod가 있고 이 둘이 연결되어 있는 상태일때, pod가 죽었다가 restart된다면? 죽은 pod안의 데이터는 유지될 수가 없다!(No data persistence out of the box!)

Storage Requirements

1. Storage that doesn’t depend on the pod lifecycle.
2. 스토리지는 pod가 죽어도 영향을 받지 않는다. 즉 계속 유지되어야 한다.
3. Storage must be available on all nodes.
4. pod가 죽었다 살아남 node1에서 죽고 node2에서 살아났다면? 스케쥴러가 노드를 정해주니깐 바뀔 수 있음. 근데 이렇게 노드가 바뀌었어도 스토리지는 계속 다시 쓸 수 있어야 함.(hostpath나 empydir은 이걸 보장 못해)
5. Storage needs be survive even if cluster crashes.ex) 스토리지 서버를 다른 시스템에 둔다던지, 아니면 클라우드 사업자가 제공하는 클러스터를 이용하던지 이런식으로..
6. 서버가 죽었다? 근데 데이터가 사라졌다? 이러면 말이 안되잖아. 그러니까 클러스터가 고장나는 경우도 대비해야함. 즉 스토리지는 클러스터 내에 구성되어있으면 안되고, 따로 구성되어있어야함.

Persistent Volume

사용입장이 아니라 준비하는 입장에서 클러스터가 쓸 수있는 스토리지를 준비하고, 얘가 쓸 수 있는 리소스를 정의해놔야한다. 이 새로운 리소스가 바로 persistentVolume 이다.

(CPU나 RAM처럼 하나의 Cluster Resource에 해당하는 것이 바로 Persistent Volume!)

얘 역시 리소스니까 우리가 전에 pod생성하고 할 때도 YAML작성했듯이, YAML을 작성한다.

kind: PersistentVolume

그렇지만,,,,

Cluster는 서버가 여러개 묶여있는데, 그 서버중에 스토리지만 가지고 있는 서버도 존재할 수 있고, 스토리지가 붙어있는 서버도 있을 수 있다. 이런 서버를 1) 로컬디스크 라고 한다.

또는 클러스터에 Network File System 즉 2) nfs 서버를 연결해서 쓸 수도 있다.

또는 클라우드 사업자들이 제공하는 3) Cloud Storage를 사용할 수도 있다.

Persistent Volume YAML Example

NFS storage 일 경우 써줘야할 spec들이 공홈에 다 적혀 있음

apiVersion : v1
kind : PersistentVolume
metadata:
	name: pv-name
spec: 
	capacity:
		storage: 5Gi
		volumeMode: Filesystem
		accessModes:
			- ReadWriteOnce
		persistentVolumeReclaimPolicy: Recycle
		storageClassName: slow
		mountOptions:
			- hard
			- nfsvers=4.0
		------
		# 여기부터는 nfs server에 존재하는 parameter
		------
		nfs:
			path: /dir/path/on/nfs/server
			server: nfs-server-ip-address
			

Google Cloud도… Local storage도 … 얘네만의 독자적인 parameter가 있다.그러므로 사용자 입장에서는 얘네가 있다는 것만 알지 잘 알지 못함. 머 머신러닝서버면 object storage써서 딜레이 줄이게하고.. 뭐용도에 따라서 다른 스토리지를 써야함 근데 보통 이건 스토리지 전문가가 하고, volume으로 define해서 사용자에게 제공하는 그런느낌 . 즉, 우리도 사용하는 입장에서 그 안의 파라미터에 대해서 다 알지는 못함.

근데 뭐 여기서 readwriteOnce 이런 접근 정도도 있고, Local storage의 node affinity..

우리는 근데 실습때 해봐야 emptydir이나 hostpath정도 써볼거임.

다른 스토리지는 그냥 어느정도로만 알고있으면 될 듯?

쿠버네티스어드미니스트레이터 자격증 시험도 persistent volume은 이미 준비되어있음. 이 클레임을 쓸 수 있냐를 시험으로 봄

• accessModes: 에 대해서• ROX (ReadOnlyMany): 여러 파드에서 읽기만 가능.• RWO-P (ReadWriteOncePod): 오직 하나의 파드에서만 읽기/쓰기 가능 (v1.22 이상).
• • RWX (ReadWriteMany): 여러 파드에서 읽기와 쓰기 모두 가능.
• • RWO (ReadWriteOnce): 한 개의 파드에서만 읽고 쓰기 가능.

Persistent Volumes are NOT namespaced

volume은 네임스페이스와 무관하게 따로 존재하는 리소스이다. 엔지니어가 persistent volume을 만들었으면, 이건 모두가 쓸수있어야함.

Local vs. Remote Volume Types

<aside>

• Local Volume Type: Local Disk Storage (물리적인 로컬 디스크, 특정 노드에 종속)
• Remote Volume Type: NFS 및 Cloud Storage (네트워크를 통해 원격으로 접근하는 스토리지) </aside>

Remote쪽에 있는 볼륨을 쓰면 상관없지만 Local한 볼륨(Local storage)을 쓴다면 아까의 요구사항 2번, 3번을 충족시키지 못한다.

1. Storage must be available on all nodes.
2. Storage needs be survive even if cluster crashes.

그래서 보통 중요한 데이터를 유지할때는 Remote storage를 쓰는 것이 일반적이다!

K8s Adiministrator and K8s User

결국 PV는 클러스터를 구축하는 단계에서 관리자가 만드는 것이다. 그러면 pod라는 것이 스토리지를 항상 필요로 하는데, 그렇다면 PV는 미리 존재해야 하는 것이 아닌가?하는 의문이 생긴다.

그래서 PVC라는 개념을 만들어서 PV를 만드는 것과 사용하는 것을 분리시켰다! 라고 할 수 있다. 우리는 PVC라는 스펙을 통해서 PV를 요청한다.

Persistent Volume Claim Component

엔지니어가 pv만들면, 내가 이걸 쓰고싶다면 내것으로 abstration해와야 함. 논리적으로 존재시키는 작업. 매번 pv를 붙들고 쓰는게아니라 pvc를 통해서 리소스를 내가 쓸 수있는 영역으로 끌어들임. 이걸 abstraction이라고 한다.

PVC안에 내가 가지고 싶은 볼륨 스펙을 작성하게 된다. 그리고 접근경로를 설정해줘야하고, pv와 달리 namespace 안에 종속이다.

그니까, pv쓰려면 pvc를 만드는 일부터 시작한다. 내가 pvc를 만들어놓으면 여기에 짝이 되는 pv가 붙게 된다. 그래서 나는 그 뒤로 pvc를 쓰는 것이다.

근데 만약 pvc를 만들었는데 거기에 적합한 pv가 없다묜..? 엔지니어가 빨리 pv를 만들어야함. 하지만 정상적이라면 여러개의 pv를 준비해놓고, Pvc가 만들어졌을때 바로가서 챡 붙어야 한답

storage class : pvc가 만들어졋을때 pv가 없더라도, active하게 바로 만들어서 가서 챡 붙게 해주는애(개념은 좀이따 볼게)

28p에 있는 코드 잘 봐두기

apiVersion: v1
kind: Pod
metadata:
  name: mypod  # Pod의 이름을 정의
spec:
  containers:
    - name: myfrontend  # 컨테이너의 이름
      image: nginx  # 컨테이너에서 사용할 이미지 (nginx 웹서버)
      volumeMounts:
        - mountPath: "/var/www/html"  # 컨테이너 내에서 마운트할 경로 (여기에 PVC가 연결될 디렉토리)
          name: mypd  # 아래에 정의된 볼륨의 이름을 참조
  volumes:
    - name: mypd  # 컨테이너에서 마운트할 볼륨 이름
      persistentVolumeClaim:
        claimName: pvc-name  # PVC 이름을 참조하여 PersistentVolumeClaim 연결
        
      

<aside> 🧩

1. 이 파일은 mypod라는 이름의 Pod를 정의하고 있어
2. 이 Pod는 nginx 이미지를 사용하는 컨테이너를 포함하고, /var/www/html 디렉토리로 **PersistentVolumeClaim (PVC)**를 마운트해.
3. volumeMounts는 컨테이너의 /var/www/html 디렉토리와 mypd 볼륨을 연결하고, 이 mypd 볼륨은 PVC인 pvc-name에 연결돼 있어.
4. PVC는 Pod가 사용하는 PersistentVolume을 제공하며, Pod가 데이터를 영구적으로 저장할 수 있는 공간을 제공함.

</aside>

# PVC 정의
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-name  # PersistentVolumeClaim의 이름
spec:
  storageClassName: manual  # 스토리지 클래스, 수동 관리되는 PV를 사용
  volumeMode: Filesystem  # 볼륨의 파일시스템 모드 (일반적으로 파일시스템으로 사용)
  accessModes:
    - ReadWriteOnce  # 하나의 노드에서 읽기 및 쓰기가 가능한 모드
  resources:
    requests:
      storage: 10Gi  # 요청하는 스토리지 크기 (10GiB)

<aside> 🧩

1. 이 파일은 pvc-name이라는 **PersistentVolumeClaim (PVC)**를 정의하고 있어.
2. PVC는 10GiB의 스토리지를 요청하며, ReadWriteOnce 모드로 하나의 노드에서 읽기 및 쓰기를 할 수 있게 허용해.
3. storageClassName: manual은 수동으로 관리되는 **PersistentVolume (PV)**를 사용함을 나타내며, 이를 통해 PVC가 PV에 연결돼.
4. 이 PVC는 Pod에 의해 마운트되며, Pod는 PVC를 통해 영구 스토리지에 데이터를 저장하고 읽어올 수 있음.

</aside>

Why so many abstractions?

스토리지의 종류에 따라 붙여주는 건 엔지니어들이 미리 해놔야하고, 쓰는 사람 입장에서는 원하는 걸 Claim을 통해서 요청을 하는 거니까

사용자 입장에서는 Actual storage를 세팅할 필요가 없고, 안전하게 스토리지를 사용하기만 하면 된다!

ConfigMap and Secret

별도의 pv라는 볼륨을 define하지 않고, 특별한 용도로 사용되는 2개의 볼륨이 있다.

ConfigMap과 Secret이다.

• secret: password, token, key,
• cm: 세팅하기 위한 파라미터를 담아두는 파일

얘네는 미리 만들어져있는 볼륨이다. (즉 pvc가 필요없다.)YAML 에 쓰는 방식은 나름 비슷하다. configMap을 spec안에 정의해두면 된다.

그래서 하나의 pod안에 여러개 다양한 타입의 Volume이 있을 수도 있다.

Storage Class

• 자동화를 위해 추가된 새로운 리소스오브젝트
• pvc만들때 스토리지클래스이름써주면 그 스토리지클래스에 해당되는 pv를 만들어서 붙게됨
• 이 안에 provisioner에 관련된 sw tool이 있어서 뭐 사람없이 자동으로 pv를 설치해준다.

SC는 PV를 다이나믹하게 사용할 수 있게 한다. 미리 준비시키는 것이 아니라 필요할 때 딱딱 만들어줄 수 있게 한다.

뭐 어느정도의 클래스로 만들어두고, 사용자의 원하는 걸 그때그때 조금씩 바꿔서 만든다!

또다른 abstraction level이라고 할 수도 있고, 사람이 제공하던 것을 추상화시킨거다.

사용 방법은 나름 간단하다. 원래 PVC.yaml에서 storageClassName: manual 이렇게 설정해줬었는데 , sc를 쓰려면 이 안에 storageClassName: storage-class-name 이런 식으로 매핑해주면 된다.

# Storage Class Config
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
	name: storage-class-name
privisioner: kubernetes.io/aws-ebs
parameters:
	type: io1
	iopsPerGB: "10"
	fsType: ext4

오늘부터는 volume에 대해서 배워본다.

테크월드 윗나나?? 를 유튜브에 검색하면 여러가지 쿠버네티스랑 도커에 강의한 부부닝 있음

중간고사때까지는 수요일날 volume에 대해 실습할 수 있게 할 것임

담주월에는 daemonset이랑 job에 대해서

---

기초용어

Drive: 저장장치

Volume: 논리적인 저장장치 ex. Window의 C:, D:, 독자적인 단일 스토리지 영역

볼륨은 논리적인 저장장치라고 할 수 있음. 우리는 볼륨을 가지고 뭘할거냐?

pod를 보면 스토리지 관련된게 있었지만 이게 어떻게 설치된건지 몰랐음. 포드 안에 볼륨 없이 그냥 웹서버로 기초적으로 deploy를 했지만 실제 포드는 스토리지 기능이 묶여져있다. 볼륨을 붙여준다. Mount Volume이라고 부름. 우린 이 방법에 대해 학습할 거임

즉 pod에 스토리지를 붙이는 것을 배운다.

How to persist data in Kubernetes using volumes?

<aside> 🧩

kubernetes.io 가서 좀 모르는 개념들을 찾아보기!‼️ Documentation에 모든 문서들이 다 들어가있음. volume은 전문성있어야 공부할 수 있는 영역이긴함.

들어가서보면 볼륨에도 되게 종류가 많음

</aside>

우리가 배울거는~

emptyDir : pod가 죽으면 사라져버리는 애, 메인메모리 이용한 임시적인 볼륨

hostpath : 서버에 있는 스토리지, 서버를 사서 꾸미면 얘가 존재함. 서버가 고장나거나 다른 노드에서는 사용 못한다는 점에서 제한이 있음. 상용화할 때는 잘 안쓰고 pvc쓴다.

설치자의 입장은 매우 전문적이고, 우리는 사용자의 입장에서 공부하기 때문에 그거는 문서에서 찾아볼 수 있음. 우리는 pv, pvc 두개를 많이 사용함. 여기에 hostpath, emptydir 이런걸 쓰게 됨

이걸 어떻게 쓰는지 오늘 공부할 거다!

The need for volumes

mysql에다가 뭘 추가, 업데이트 할 수 있고, pod가 죽었다살아나도 다시 사용할 수 있어야한다. ⇒ 스토리지가 가져야할 특성(persistence)

(만약 emptydir일 경우는 임시적이기 때문에 pod가 죽었다가 살아나면 다 사라져.)

my-app이라는 pod와, mysql이라는 DB engine역할의 pod가 있고 이 둘이 연결되어 있는 상태일때, pod가 죽었다가 restart된다면? 죽은 pod안의 데이터는 유지될 수가 없다!(No data persistence out of the box!)

Storage Requirements

1. Storage that doesn’t depend on the pod lifecycle.
2. 스토리지는 pod가 죽어도 영향을 받지 않는다. 즉 계속 유지되어야 한다.
3. Storage must be available on all nodes.
4. pod가 죽었다 살아남 node1에서 죽고 node2에서 살아났다면? 스케쥴러가 노드를 정해주니깐 바뀔 수 있음. 근데 이렇게 노드가 바뀌었어도 스토리지는 계속 다시 쓸 수 있어야 함.(hostpath나 empydir은 이걸 보장 못해)
5. Storage needs be survive even if cluster crashes.ex) 스토리지 서버를 다른 시스템에 둔다던지, 아니면 클라우드 사업자가 제공하는 클러스터를 이용하던지 이런식으로..
6. 서버가 죽었다? 근데 데이터가 사라졌다? 이러면 말이 안되잖아. 그러니까 클러스터가 고장나는 경우도 대비해야함. 즉 스토리지는 클러스터 내에 구성되어있으면 안되고, 따로 구성되어있어야함.

Persistent Volume

사용입장이 아니라 준비하는 입장에서 클러스터가 쓸 수있는 스토리지를 준비하고, 얘가 쓸 수 있는 리소스를 정의해놔야한다. 이 새로운 리소스가 바로 persistentVolume 이다.

(CPU나 RAM처럼 하나의 Cluster Resource에 해당하는 것이 바로 Persistent Volume!)

얘 역시 리소스니까 우리가 전에 pod생성하고 할 때도 YAML작성했듯이, YAML을 작성한다.

kind: PersistentVolume

그렇지만,,,,

Cluster는 서버가 여러개 묶여있는데, 그 서버중에 스토리지만 가지고 있는 서버도 존재할 수 있고, 스토리지가 붙어있는 서버도 있을 수 있다. 이런 서버를 1) 로컬디스크 라고 한다.

또는 클러스터에 Network File System 즉 2) nfs 서버를 연결해서 쓸 수도 있다.

또는 클라우드 사업자들이 제공하는 3) Cloud Storage를 사용할 수도 있다.

Persistent Volume YAML Example

NFS storage 일 경우 써줘야할 spec들이 공홈에 다 적혀 있음

apiVersion : v1
kind : PersistentVolume
metadata:
	name: pv-name
spec: 
	capacity:
		storage: 5Gi
		volumeMode: Filesystem
		accessModes:
			- ReadWriteOnce
		persistentVolumeReclaimPolicy: Recycle
		storageClassName: slow
		mountOptions:
			- hard
			- nfsvers=4.0
		------
		# 여기부터는 nfs server에 존재하는 parameter
		------
		nfs:
			path: /dir/path/on/nfs/server
			server: nfs-server-ip-address
			

Google Cloud도… Local storage도 … 얘네만의 독자적인 parameter가 있다.그러므로 사용자 입장에서는 얘네가 있다는 것만 알지 잘 알지 못함. 머 머신러닝서버면 object storage써서 딜레이 줄이게하고.. 뭐용도에 따라서 다른 스토리지를 써야함 근데 보통 이건 스토리지 전문가가 하고, volume으로 define해서 사용자에게 제공하는 그런느낌 . 즉, 우리도 사용하는 입장에서 그 안의 파라미터에 대해서 다 알지는 못함.

근데 뭐 여기서 readwriteOnce 이런 접근 정도도 있고, Local storage의 node affinity..

우리는 근데 실습때 해봐야 emptydir이나 hostpath정도 써볼거임.

다른 스토리지는 그냥 어느정도로만 알고있으면 될 듯?

쿠버네티스어드미니스트레이터 자격증 시험도 persistent volume은 이미 준비되어있음. 이 클레임을 쓸 수 있냐를 시험으로 봄

• accessModes: 에 대해서• ROX (ReadOnlyMany): 여러 파드에서 읽기만 가능.• RWO-P (ReadWriteOncePod): 오직 하나의 파드에서만 읽기/쓰기 가능 (v1.22 이상).
• • RWX (ReadWriteMany): 여러 파드에서 읽기와 쓰기 모두 가능.
• • RWO (ReadWriteOnce): 한 개의 파드에서만 읽고 쓰기 가능.

Persistent Volumes are NOT namespaced

volume은 네임스페이스와 무관하게 따로 존재하는 리소스이다. 엔지니어가 persistent volume을 만들었으면, 이건 모두가 쓸수있어야함.

Local vs. Remote Volume Types

<aside>

• Local Volume Type: Local Disk Storage (물리적인 로컬 디스크, 특정 노드에 종속)
• Remote Volume Type: NFS 및 Cloud Storage (네트워크를 통해 원격으로 접근하는 스토리지) </aside>

Remote쪽에 있는 볼륨을 쓰면 상관없지만 Local한 볼륨(Local storage)을 쓴다면 아까의 요구사항 2번, 3번을 충족시키지 못한다.

1. Storage must be available on all nodes.
2. Storage needs be survive even if cluster crashes.

그래서 보통 중요한 데이터를 유지할때는 Remote storage를 쓰는 것이 일반적이다!

K8s Adiministrator and K8s User

결국 PV는 클러스터를 구축하는 단계에서 관리자가 만드는 것이다. 그러면 pod라는 것이 스토리지를 항상 필요로 하는데, 그렇다면 PV는 미리 존재해야 하는 것이 아닌가?하는 의문이 생긴다.

그래서 PVC라는 개념을 만들어서 PV를 만드는 것과 사용하는 것을 분리시켰다! 라고 할 수 있다. 우리는 PVC라는 스펙을 통해서 PV를 요청한다.

Persistent Volume Claim Component

엔지니어가 pv만들면, 내가 이걸 쓰고싶다면 내것으로 abstration해와야 함. 논리적으로 존재시키는 작업. 매번 pv를 붙들고 쓰는게아니라 pvc를 통해서 리소스를 내가 쓸 수있는 영역으로 끌어들임. 이걸 abstraction이라고 한다.

PVC안에 내가 가지고 싶은 볼륨 스펙을 작성하게 된다. 그리고 접근경로를 설정해줘야하고, pv와 달리 namespace 안에 종속이다.

그니까, pv쓰려면 pvc를 만드는 일부터 시작한다. 내가 pvc를 만들어놓으면 여기에 짝이 되는 pv가 붙게 된다. 그래서 나는 그 뒤로 pvc를 쓰는 것이다.

근데 만약 pvc를 만들었는데 거기에 적합한 pv가 없다묜..? 엔지니어가 빨리 pv를 만들어야함. 하지만 정상적이라면 여러개의 pv를 준비해놓고, Pvc가 만들어졌을때 바로가서 챡 붙어야 한답

storage class : pvc가 만들어졋을때 pv가 없더라도, active하게 바로 만들어서 가서 챡 붙게 해주는애(개념은 좀이따 볼게)

28p에 있는 코드 잘 봐두기

apiVersion: v1
kind: Pod
metadata:
  name: mypod  # Pod의 이름을 정의
spec:
  containers:
    - name: myfrontend  # 컨테이너의 이름
      image: nginx  # 컨테이너에서 사용할 이미지 (nginx 웹서버)
      volumeMounts:
        - mountPath: "/var/www/html"  # 컨테이너 내에서 마운트할 경로 (여기에 PVC가 연결될 디렉토리)
          name: mypd  # 아래에 정의된 볼륨의 이름을 참조
  volumes:
    - name: mypd  # 컨테이너에서 마운트할 볼륨 이름
      persistentVolumeClaim:
        claimName: pvc-name  # PVC 이름을 참조하여 PersistentVolumeClaim 연결
        
      

<aside> 🧩

1. 이 파일은 mypod라는 이름의 Pod를 정의하고 있어
2. 이 Pod는 nginx 이미지를 사용하는 컨테이너를 포함하고, /var/www/html 디렉토리로 **PersistentVolumeClaim (PVC)**를 마운트해.
3. volumeMounts는 컨테이너의 /var/www/html 디렉토리와 mypd 볼륨을 연결하고, 이 mypd 볼륨은 PVC인 pvc-name에 연결돼 있어.
4. PVC는 Pod가 사용하는 PersistentVolume을 제공하며, Pod가 데이터를 영구적으로 저장할 수 있는 공간을 제공함.

</aside>

# PVC 정의
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-name  # PersistentVolumeClaim의 이름
spec:
  storageClassName: manual  # 스토리지 클래스, 수동 관리되는 PV를 사용
  volumeMode: Filesystem  # 볼륨의 파일시스템 모드 (일반적으로 파일시스템으로 사용)
  accessModes:
    - ReadWriteOnce  # 하나의 노드에서 읽기 및 쓰기가 가능한 모드
  resources:
    requests:
      storage: 10Gi  # 요청하는 스토리지 크기 (10GiB)

<aside> 🧩

1. 이 파일은 pvc-name이라는 **PersistentVolumeClaim (PVC)**를 정의하고 있어.
2. PVC는 10GiB의 스토리지를 요청하며, ReadWriteOnce 모드로 하나의 노드에서 읽기 및 쓰기를 할 수 있게 허용해.
3. storageClassName: manual은 수동으로 관리되는 **PersistentVolume (PV)**를 사용함을 나타내며, 이를 통해 PVC가 PV에 연결돼.
4. 이 PVC는 Pod에 의해 마운트되며, Pod는 PVC를 통해 영구 스토리지에 데이터를 저장하고 읽어올 수 있음.

</aside>

Why so many abstractions?

스토리지의 종류에 따라 붙여주는 건 엔지니어들이 미리 해놔야하고, 쓰는 사람 입장에서는 원하는 걸 Claim을 통해서 요청을 하는 거니까

사용자 입장에서는 Actual storage를 세팅할 필요가 없고, 안전하게 스토리지를 사용하기만 하면 된다!

ConfigMap and Secret

별도의 pv라는 볼륨을 define하지 않고, 특별한 용도로 사용되는 2개의 볼륨이 있다.

ConfigMap과 Secret이다.

• secret: password, token, key,
• cm: 세팅하기 위한 파라미터를 담아두는 파일

얘네는 미리 만들어져있는 볼륨이다. (즉 pvc가 필요없다.)YAML 에 쓰는 방식은 나름 비슷하다. configMap을 spec안에 정의해두면 된다.

그래서 하나의 pod안에 여러개 다양한 타입의 Volume이 있을 수도 있다.

Storage Class

• 자동화를 위해 추가된 새로운 리소스오브젝트
• pvc만들때 스토리지클래스이름써주면 그 스토리지클래스에 해당되는 pv를 만들어서 붙게됨
• 이 안에 provisioner에 관련된 sw tool이 있어서 뭐 사람없이 자동으로 pv를 설치해준다.

SC는 PV를 다이나믹하게 사용할 수 있게 한다. 미리 준비시키는 것이 아니라 필요할 때 딱딱 만들어줄 수 있게 한다.

뭐 어느정도의 클래스로 만들어두고, 사용자의 원하는 걸 그때그때 조금씩 바꿔서 만든다!

또다른 abstraction level이라고 할 수도 있고, 사람이 제공하던 것을 추상화시킨거다.

사용 방법은 나름 간단하다. 원래 PVC.yaml에서 storageClassName: manual 이렇게 설정해줬었는데 , sc를 쓰려면 이 안에 storageClassName: storage-class-name 이런 식으로 매핑해주면 된다.

# Storage Class Config
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
	name: storage-class-name
privisioner: kubernetes.io/aws-ebs
parameters:
	type: io1
	iopsPerGB: "10"
	fsType: ext4

오늘부터는 volume에 대해서 배워본다.

테크월드 윗나나?? 를 유튜브에 검색하면 여러가지 쿠버네티스랑 도커에 강의한 부부닝 있음

중간고사때까지는 수요일날 volume에 대해 실습할 수 있게 할 것임

담주월에는 daemonset이랑 job에 대해서

---

기초용어

Drive: 저장장치

Volume: 논리적인 저장장치 ex. Window의 C:, D:, 독자적인 단일 스토리지 영역

볼륨은 논리적인 저장장치라고 할 수 있음. 우리는 볼륨을 가지고 뭘할거냐?

pod를 보면 스토리지 관련된게 있었지만 이게 어떻게 설치된건지 몰랐음. 포드 안에 볼륨 없이 그냥 웹서버로 기초적으로 deploy를 했지만 실제 포드는 스토리지 기능이 묶여져있다. 볼륨을 붙여준다. Mount Volume이라고 부름. 우린 이 방법에 대해 학습할 거임

즉 pod에 스토리지를 붙이는 것을 배운다.

How to persist data in Kubernetes using volumes?

<aside> 🧩

kubernetes.io 가서 좀 모르는 개념들을 찾아보기!‼️ Documentation에 모든 문서들이 다 들어가있음. volume은 전문성있어야 공부할 수 있는 영역이긴함.

들어가서보면 볼륨에도 되게 종류가 많음

</aside>

우리가 배울거는~

emptyDir : pod가 죽으면 사라져버리는 애, 메인메모리 이용한 임시적인 볼륨

hostpath : 서버에 있는 스토리지, 서버를 사서 꾸미면 얘가 존재함. 서버가 고장나거나 다른 노드에서는 사용 못한다는 점에서 제한이 있음. 상용화할 때는 잘 안쓰고 pvc쓴다.

설치자의 입장은 매우 전문적이고, 우리는 사용자의 입장에서 공부하기 때문에 그거는 문서에서 찾아볼 수 있음. 우리는 pv, pvc 두개를 많이 사용함. 여기에 hostpath, emptydir 이런걸 쓰게 됨

이걸 어떻게 쓰는지 오늘 공부할 거다!

The need for volumes

mysql에다가 뭘 추가, 업데이트 할 수 있고, pod가 죽었다살아나도 다시 사용할 수 있어야한다. ⇒ 스토리지가 가져야할 특성(persistence)

(만약 emptydir일 경우는 임시적이기 때문에 pod가 죽었다가 살아나면 다 사라져.)

my-app이라는 pod와, mysql이라는 DB engine역할의 pod가 있고 이 둘이 연결되어 있는 상태일때, pod가 죽었다가 restart된다면? 죽은 pod안의 데이터는 유지될 수가 없다!(No data persistence out of the box!)

Storage Requirements

1. Storage that doesn’t depend on the pod lifecycle.
2. 스토리지는 pod가 죽어도 영향을 받지 않는다. 즉 계속 유지되어야 한다.
3. Storage must be available on all nodes.
4. pod가 죽었다 살아남 node1에서 죽고 node2에서 살아났다면? 스케쥴러가 노드를 정해주니깐 바뀔 수 있음. 근데 이렇게 노드가 바뀌었어도 스토리지는 계속 다시 쓸 수 있어야 함.(hostpath나 empydir은 이걸 보장 못해)
5. Storage needs be survive even if cluster crashes.ex) 스토리지 서버를 다른 시스템에 둔다던지, 아니면 클라우드 사업자가 제공하는 클러스터를 이용하던지 이런식으로..
6. 서버가 죽었다? 근데 데이터가 사라졌다? 이러면 말이 안되잖아. 그러니까 클러스터가 고장나는 경우도 대비해야함. 즉 스토리지는 클러스터 내에 구성되어있으면 안되고, 따로 구성되어있어야함.

Persistent Volume

사용입장이 아니라 준비하는 입장에서 클러스터가 쓸 수있는 스토리지를 준비하고, 얘가 쓸 수 있는 리소스를 정의해놔야한다. 이 새로운 리소스가 바로 persistentVolume 이다.

(CPU나 RAM처럼 하나의 Cluster Resource에 해당하는 것이 바로 Persistent Volume!)

얘 역시 리소스니까 우리가 전에 pod생성하고 할 때도 YAML작성했듯이, YAML을 작성한다.

kind: PersistentVolume

그렇지만,,,,

Cluster는 서버가 여러개 묶여있는데, 그 서버중에 스토리지만 가지고 있는 서버도 존재할 수 있고, 스토리지가 붙어있는 서버도 있을 수 있다. 이런 서버를 1) 로컬디스크 라고 한다.

또는 클러스터에 Network File System 즉 2) nfs 서버를 연결해서 쓸 수도 있다.

또는 클라우드 사업자들이 제공하는 3) Cloud Storage를 사용할 수도 있다.

Persistent Volume YAML Example

NFS storage 일 경우 써줘야할 spec들이 공홈에 다 적혀 있음

apiVersion : v1
kind : PersistentVolume
metadata:
	name: pv-name
spec: 
	capacity:
		storage: 5Gi
		volumeMode: Filesystem
		accessModes:
			- ReadWriteOnce
		persistentVolumeReclaimPolicy: Recycle
		storageClassName: slow
		mountOptions:
			- hard
			- nfsvers=4.0
		------
		# 여기부터는 nfs server에 존재하는 parameter
		------
		nfs:
			path: /dir/path/on/nfs/server
			server: nfs-server-ip-address
			

Google Cloud도… Local storage도 … 얘네만의 독자적인 parameter가 있다.그러므로 사용자 입장에서는 얘네가 있다는 것만 알지 잘 알지 못함. 머 머신러닝서버면 object storage써서 딜레이 줄이게하고.. 뭐용도에 따라서 다른 스토리지를 써야함 근데 보통 이건 스토리지 전문가가 하고, volume으로 define해서 사용자에게 제공하는 그런느낌 . 즉, 우리도 사용하는 입장에서 그 안의 파라미터에 대해서 다 알지는 못함.

근데 뭐 여기서 readwriteOnce 이런 접근 정도도 있고, Local storage의 node affinity..

우리는 근데 실습때 해봐야 emptydir이나 hostpath정도 써볼거임.

다른 스토리지는 그냥 어느정도로만 알고있으면 될 듯?

쿠버네티스어드미니스트레이터 자격증 시험도 persistent volume은 이미 준비되어있음. 이 클레임을 쓸 수 있냐를 시험으로 봄

• accessModes: 에 대해서• ROX (ReadOnlyMany): 여러 파드에서 읽기만 가능.• RWO-P (ReadWriteOncePod): 오직 하나의 파드에서만 읽기/쓰기 가능 (v1.22 이상).
• • RWX (ReadWriteMany): 여러 파드에서 읽기와 쓰기 모두 가능.
• • RWO (ReadWriteOnce): 한 개의 파드에서만 읽고 쓰기 가능.

Persistent Volumes are NOT namespaced

volume은 네임스페이스와 무관하게 따로 존재하는 리소스이다. 엔지니어가 persistent volume을 만들었으면, 이건 모두가 쓸수있어야함.

Local vs. Remote Volume Types

<aside>

• Local Volume Type: Local Disk Storage (물리적인 로컬 디스크, 특정 노드에 종속)
• Remote Volume Type: NFS 및 Cloud Storage (네트워크를 통해 원격으로 접근하는 스토리지) </aside>

Remote쪽에 있는 볼륨을 쓰면 상관없지만 Local한 볼륨(Local storage)을 쓴다면 아까의 요구사항 2번, 3번을 충족시키지 못한다.

1. Storage must be available on all nodes.
2. Storage needs be survive even if cluster crashes.

그래서 보통 중요한 데이터를 유지할때는 Remote storage를 쓰는 것이 일반적이다!

K8s Adiministrator and K8s User

결국 PV는 클러스터를 구축하는 단계에서 관리자가 만드는 것이다. 그러면 pod라는 것이 스토리지를 항상 필요로 하는데, 그렇다면 PV는 미리 존재해야 하는 것이 아닌가?하는 의문이 생긴다.

그래서 PVC라는 개념을 만들어서 PV를 만드는 것과 사용하는 것을 분리시켰다! 라고 할 수 있다. 우리는 PVC라는 스펙을 통해서 PV를 요청한다.

Persistent Volume Claim Component

엔지니어가 pv만들면, 내가 이걸 쓰고싶다면 내것으로 abstration해와야 함. 논리적으로 존재시키는 작업. 매번 pv를 붙들고 쓰는게아니라 pvc를 통해서 리소스를 내가 쓸 수있는 영역으로 끌어들임. 이걸 abstraction이라고 한다.

PVC안에 내가 가지고 싶은 볼륨 스펙을 작성하게 된다. 그리고 접근경로를 설정해줘야하고, pv와 달리 namespace 안에 종속이다.

그니까, pv쓰려면 pvc를 만드는 일부터 시작한다. 내가 pvc를 만들어놓으면 여기에 짝이 되는 pv가 붙게 된다. 그래서 나는 그 뒤로 pvc를 쓰는 것이다.

근데 만약 pvc를 만들었는데 거기에 적합한 pv가 없다묜..? 엔지니어가 빨리 pv를 만들어야함. 하지만 정상적이라면 여러개의 pv를 준비해놓고, Pvc가 만들어졌을때 바로가서 챡 붙어야 한답

storage class : pvc가 만들어졋을때 pv가 없더라도, active하게 바로 만들어서 가서 챡 붙게 해주는애(개념은 좀이따 볼게)

28p에 있는 코드 잘 봐두기

apiVersion: v1
kind: Pod
metadata:
  name: mypod  # Pod의 이름을 정의
spec:
  containers:
    - name: myfrontend  # 컨테이너의 이름
      image: nginx  # 컨테이너에서 사용할 이미지 (nginx 웹서버)
      volumeMounts:
        - mountPath: "/var/www/html"  # 컨테이너 내에서 마운트할 경로 (여기에 PVC가 연결될 디렉토리)
          name: mypd  # 아래에 정의된 볼륨의 이름을 참조
  volumes:
    - name: mypd  # 컨테이너에서 마운트할 볼륨 이름
      persistentVolumeClaim:
        claimName: pvc-name  # PVC 이름을 참조하여 PersistentVolumeClaim 연결
        
      

<aside> 🧩

1. 이 파일은 mypod라는 이름의 Pod를 정의하고 있어
2. 이 Pod는 nginx 이미지를 사용하는 컨테이너를 포함하고, /var/www/html 디렉토리로 **PersistentVolumeClaim (PVC)**를 마운트해.
3. volumeMounts는 컨테이너의 /var/www/html 디렉토리와 mypd 볼륨을 연결하고, 이 mypd 볼륨은 PVC인 pvc-name에 연결돼 있어.
4. PVC는 Pod가 사용하는 PersistentVolume을 제공하며, Pod가 데이터를 영구적으로 저장할 수 있는 공간을 제공함.

</aside>

# PVC 정의
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-name  # PersistentVolumeClaim의 이름
spec:
  storageClassName: manual  # 스토리지 클래스, 수동 관리되는 PV를 사용
  volumeMode: Filesystem  # 볼륨의 파일시스템 모드 (일반적으로 파일시스템으로 사용)
  accessModes:
    - ReadWriteOnce  # 하나의 노드에서 읽기 및 쓰기가 가능한 모드
  resources:
    requests:
      storage: 10Gi  # 요청하는 스토리지 크기 (10GiB)

<aside> 🧩

1. 이 파일은 pvc-name이라는 **PersistentVolumeClaim (PVC)**를 정의하고 있어.
2. PVC는 10GiB의 스토리지를 요청하며, ReadWriteOnce 모드로 하나의 노드에서 읽기 및 쓰기를 할 수 있게 허용해.
3. storageClassName: manual은 수동으로 관리되는 **PersistentVolume (PV)**를 사용함을 나타내며, 이를 통해 PVC가 PV에 연결돼.
4. 이 PVC는 Pod에 의해 마운트되며, Pod는 PVC를 통해 영구 스토리지에 데이터를 저장하고 읽어올 수 있음.

</aside>

Why so many abstractions?

스토리지의 종류에 따라 붙여주는 건 엔지니어들이 미리 해놔야하고, 쓰는 사람 입장에서는 원하는 걸 Claim을 통해서 요청을 하는 거니까

사용자 입장에서는 Actual storage를 세팅할 필요가 없고, 안전하게 스토리지를 사용하기만 하면 된다!

ConfigMap and Secret

별도의 pv라는 볼륨을 define하지 않고, 특별한 용도로 사용되는 2개의 볼륨이 있다.

ConfigMap과 Secret이다.

• secret: password, token, key,
• cm: 세팅하기 위한 파라미터를 담아두는 파일

얘네는 미리 만들어져있는 볼륨이다. (즉 pvc가 필요없다.)YAML 에 쓰는 방식은 나름 비슷하다. configMap을 spec안에 정의해두면 된다.

그래서 하나의 pod안에 여러개 다양한 타입의 Volume이 있을 수도 있다.

Storage Class

• 자동화를 위해 추가된 새로운 리소스오브젝트
• pvc만들때 스토리지클래스이름써주면 그 스토리지클래스에 해당되는 pv를 만들어서 붙게됨
• 이 안에 provisioner에 관련된 sw tool이 있어서 뭐 사람없이 자동으로 pv를 설치해준다.

SC는 PV를 다이나믹하게 사용할 수 있게 한다. 미리 준비시키는 것이 아니라 필요할 때 딱딱 만들어줄 수 있게 한다.

뭐 어느정도의 클래스로 만들어두고, 사용자의 원하는 걸 그때그때 조금씩 바꿔서 만든다!

또다른 abstraction level이라고 할 수도 있고, 사람이 제공하던 것을 추상화시킨거다.

사용 방법은 나름 간단하다. 원래 PVC.yaml에서 storageClassName: manual 이렇게 설정해줬었는데 , sc를 쓰려면 이 안에 storageClassName: storage-class-name 이런 식으로 매핑해주면 된다.

# Storage Class Config
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
	name: storage-class-name
privisioner: kubernetes.io/aws-ebs
parameters:
	type: io1
	iopsPerGB: "10"
	fsType: ext4

오늘부터는 volume에 대해서 배워본다.

테크월드 윗나나?? 를 유튜브에 검색하면 여러가지 쿠버네티스랑 도커에 강의한 부부닝 있음

중간고사때까지는 수요일날 volume에 대해 실습할 수 있게 할 것임

담주월에는 daemonset이랑 job에 대해서

---

기초용어

Drive: 저장장치

Volume: 논리적인 저장장치 ex. Window의 C:, D:, 독자적인 단일 스토리지 영역

볼륨은 논리적인 저장장치라고 할 수 있음. 우리는 볼륨을 가지고 뭘할거냐?

pod를 보면 스토리지 관련된게 있었지만 이게 어떻게 설치된건지 몰랐음. 포드 안에 볼륨 없이 그냥 웹서버로 기초적으로 deploy를 했지만 실제 포드는 스토리지 기능이 묶여져있다. 볼륨을 붙여준다. Mount Volume이라고 부름. 우린 이 방법에 대해 학습할 거임

즉 pod에 스토리지를 붙이는 것을 배운다.

How to persist data in Kubernetes using volumes?

<aside> 🧩

kubernetes.io 가서 좀 모르는 개념들을 찾아보기!‼️ Documentation에 모든 문서들이 다 들어가있음. volume은 전문성있어야 공부할 수 있는 영역이긴함.

들어가서보면 볼륨에도 되게 종류가 많음

</aside>

우리가 배울거는~

emptyDir : pod가 죽으면 사라져버리는 애, 메인메모리 이용한 임시적인 볼륨

hostpath : 서버에 있는 스토리지, 서버를 사서 꾸미면 얘가 존재함. 서버가 고장나거나 다른 노드에서는 사용 못한다는 점에서 제한이 있음. 상용화할 때는 잘 안쓰고 pvc쓴다.

설치자의 입장은 매우 전문적이고, 우리는 사용자의 입장에서 공부하기 때문에 그거는 문서에서 찾아볼 수 있음. 우리는 pv, pvc 두개를 많이 사용함. 여기에 hostpath, emptydir 이런걸 쓰게 됨

이걸 어떻게 쓰는지 오늘 공부할 거다!

The need for volumes

mysql에다가 뭘 추가, 업데이트 할 수 있고, pod가 죽었다살아나도 다시 사용할 수 있어야한다. ⇒ 스토리지가 가져야할 특성(persistence)

(만약 emptydir일 경우는 임시적이기 때문에 pod가 죽었다가 살아나면 다 사라져.)

my-app이라는 pod와, mysql이라는 DB engine역할의 pod가 있고 이 둘이 연결되어 있는 상태일때, pod가 죽었다가 restart된다면? 죽은 pod안의 데이터는 유지될 수가 없다!(No data persistence out of the box!)

Storage Requirements

1. Storage that doesn’t depend on the pod lifecycle.
2. 스토리지는 pod가 죽어도 영향을 받지 않는다. 즉 계속 유지되어야 한다.
3. Storage must be available on all nodes.
4. pod가 죽었다 살아남 node1에서 죽고 node2에서 살아났다면? 스케쥴러가 노드를 정해주니깐 바뀔 수 있음. 근데 이렇게 노드가 바뀌었어도 스토리지는 계속 다시 쓸 수 있어야 함.(hostpath나 empydir은 이걸 보장 못해)
5. Storage needs be survive even if cluster crashes.ex) 스토리지 서버를 다른 시스템에 둔다던지, 아니면 클라우드 사업자가 제공하는 클러스터를 이용하던지 이런식으로..
6. 서버가 죽었다? 근데 데이터가 사라졌다? 이러면 말이 안되잖아. 그러니까 클러스터가 고장나는 경우도 대비해야함. 즉 스토리지는 클러스터 내에 구성되어있으면 안되고, 따로 구성되어있어야함.

Persistent Volume

사용입장이 아니라 준비하는 입장에서 클러스터가 쓸 수있는 스토리지를 준비하고, 얘가 쓸 수 있는 리소스를 정의해놔야한다. 이 새로운 리소스가 바로 persistentVolume 이다.

(CPU나 RAM처럼 하나의 Cluster Resource에 해당하는 것이 바로 Persistent Volume!)

얘 역시 리소스니까 우리가 전에 pod생성하고 할 때도 YAML작성했듯이, YAML을 작성한다.

kind: PersistentVolume

그렇지만,,,,

Cluster는 서버가 여러개 묶여있는데, 그 서버중에 스토리지만 가지고 있는 서버도 존재할 수 있고, 스토리지가 붙어있는 서버도 있을 수 있다. 이런 서버를 1) 로컬디스크 라고 한다.

또는 클러스터에 Network File System 즉 2) nfs 서버를 연결해서 쓸 수도 있다.

또는 클라우드 사업자들이 제공하는 3) Cloud Storage를 사용할 수도 있다.

Persistent Volume YAML Example

NFS storage 일 경우 써줘야할 spec들이 공홈에 다 적혀 있음

apiVersion : v1
kind : PersistentVolume
metadata:
	name: pv-name
spec: 
	capacity:
		storage: 5Gi
		volumeMode: Filesystem
		accessModes:
			- ReadWriteOnce
		persistentVolumeReclaimPolicy: Recycle
		storageClassName: slow
		mountOptions:
			- hard
			- nfsvers=4.0
		------
		# 여기부터는 nfs server에 존재하는 parameter
		------
		nfs:
			path: /dir/path/on/nfs/server
			server: nfs-server-ip-address
			

Google Cloud도… Local storage도 … 얘네만의 독자적인 parameter가 있다.그러므로 사용자 입장에서는 얘네가 있다는 것만 알지 잘 알지 못함. 머 머신러닝서버면 object storage써서 딜레이 줄이게하고.. 뭐용도에 따라서 다른 스토리지를 써야함 근데 보통 이건 스토리지 전문가가 하고, volume으로 define해서 사용자에게 제공하는 그런느낌 . 즉, 우리도 사용하는 입장에서 그 안의 파라미터에 대해서 다 알지는 못함.

근데 뭐 여기서 readwriteOnce 이런 접근 정도도 있고, Local storage의 node affinity..

우리는 근데 실습때 해봐야 emptydir이나 hostpath정도 써볼거임.

다른 스토리지는 그냥 어느정도로만 알고있으면 될 듯?

쿠버네티스어드미니스트레이터 자격증 시험도 persistent volume은 이미 준비되어있음. 이 클레임을 쓸 수 있냐를 시험으로 봄

• accessModes: 에 대해서• ROX (ReadOnlyMany): 여러 파드에서 읽기만 가능.• RWO-P (ReadWriteOncePod): 오직 하나의 파드에서만 읽기/쓰기 가능 (v1.22 이상).
• • RWX (ReadWriteMany): 여러 파드에서 읽기와 쓰기 모두 가능.
• • RWO (ReadWriteOnce): 한 개의 파드에서만 읽고 쓰기 가능.

Persistent Volumes are NOT namespaced

volume은 네임스페이스와 무관하게 따로 존재하는 리소스이다. 엔지니어가 persistent volume을 만들었으면, 이건 모두가 쓸수있어야함.

Local vs. Remote Volume Types

<aside>

• Local Volume Type: Local Disk Storage (물리적인 로컬 디스크, 특정 노드에 종속)
• Remote Volume Type: NFS 및 Cloud Storage (네트워크를 통해 원격으로 접근하는 스토리지) </aside>

Remote쪽에 있는 볼륨을 쓰면 상관없지만 Local한 볼륨(Local storage)을 쓴다면 아까의 요구사항 2번, 3번을 충족시키지 못한다.

1. Storage must be available on all nodes.
2. Storage needs be survive even if cluster crashes.

그래서 보통 중요한 데이터를 유지할때는 Remote storage를 쓰는 것이 일반적이다!

K8s Adiministrator and K8s User

결국 PV는 클러스터를 구축하는 단계에서 관리자가 만드는 것이다. 그러면 pod라는 것이 스토리지를 항상 필요로 하는데, 그렇다면 PV는 미리 존재해야 하는 것이 아닌가?하는 의문이 생긴다.

그래서 PVC라는 개념을 만들어서 PV를 만드는 것과 사용하는 것을 분리시켰다! 라고 할 수 있다. 우리는 PVC라는 스펙을 통해서 PV를 요청한다.

Persistent Volume Claim Component

엔지니어가 pv만들면, 내가 이걸 쓰고싶다면 내것으로 abstration해와야 함. 논리적으로 존재시키는 작업. 매번 pv를 붙들고 쓰는게아니라 pvc를 통해서 리소스를 내가 쓸 수있는 영역으로 끌어들임. 이걸 abstraction이라고 한다.

PVC안에 내가 가지고 싶은 볼륨 스펙을 작성하게 된다. 그리고 접근경로를 설정해줘야하고, pv와 달리 namespace 안에 종속이다.

그니까, pv쓰려면 pvc를 만드는 일부터 시작한다. 내가 pvc를 만들어놓으면 여기에 짝이 되는 pv가 붙게 된다. 그래서 나는 그 뒤로 pvc를 쓰는 것이다.

근데 만약 pvc를 만들었는데 거기에 적합한 pv가 없다묜..? 엔지니어가 빨리 pv를 만들어야함. 하지만 정상적이라면 여러개의 pv를 준비해놓고, Pvc가 만들어졌을때 바로가서 챡 붙어야 한답

storage class : pvc가 만들어졋을때 pv가 없더라도, active하게 바로 만들어서 가서 챡 붙게 해주는애(개념은 좀이따 볼게)

28p에 있는 코드 잘 봐두기

apiVersion: v1
kind: Pod
metadata:
  name: mypod  # Pod의 이름을 정의
spec:
  containers:
    - name: myfrontend  # 컨테이너의 이름
      image: nginx  # 컨테이너에서 사용할 이미지 (nginx 웹서버)
      volumeMounts:
        - mountPath: "/var/www/html"  # 컨테이너 내에서 마운트할 경로 (여기에 PVC가 연결될 디렉토리)
          name: mypd  # 아래에 정의된 볼륨의 이름을 참조
  volumes:
    - name: mypd  # 컨테이너에서 마운트할 볼륨 이름
      persistentVolumeClaim:
        claimName: pvc-name  # PVC 이름을 참조하여 PersistentVolumeClaim 연결
        
      

<aside> 🧩

1. 이 파일은 mypod라는 이름의 Pod를 정의하고 있어
2. 이 Pod는 nginx 이미지를 사용하는 컨테이너를 포함하고, /var/www/html 디렉토리로 **PersistentVolumeClaim (PVC)**를 마운트해.
3. volumeMounts는 컨테이너의 /var/www/html 디렉토리와 mypd 볼륨을 연결하고, 이 mypd 볼륨은 PVC인 pvc-name에 연결돼 있어.
4. PVC는 Pod가 사용하는 PersistentVolume을 제공하며, Pod가 데이터를 영구적으로 저장할 수 있는 공간을 제공함.

</aside>

# PVC 정의
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-name  # PersistentVolumeClaim의 이름
spec:
  storageClassName: manual  # 스토리지 클래스, 수동 관리되는 PV를 사용
  volumeMode: Filesystem  # 볼륨의 파일시스템 모드 (일반적으로 파일시스템으로 사용)
  accessModes:
    - ReadWriteOnce  # 하나의 노드에서 읽기 및 쓰기가 가능한 모드
  resources:
    requests:
      storage: 10Gi  # 요청하는 스토리지 크기 (10GiB)

<aside> 🧩

1. 이 파일은 pvc-name이라는 **PersistentVolumeClaim (PVC)**를 정의하고 있어.
2. PVC는 10GiB의 스토리지를 요청하며, ReadWriteOnce 모드로 하나의 노드에서 읽기 및 쓰기를 할 수 있게 허용해.
3. storageClassName: manual은 수동으로 관리되는 **PersistentVolume (PV)**를 사용함을 나타내며, 이를 통해 PVC가 PV에 연결돼.
4. 이 PVC는 Pod에 의해 마운트되며, Pod는 PVC를 통해 영구 스토리지에 데이터를 저장하고 읽어올 수 있음.

</aside>

Why so many abstractions?

스토리지의 종류에 따라 붙여주는 건 엔지니어들이 미리 해놔야하고, 쓰는 사람 입장에서는 원하는 걸 Claim을 통해서 요청을 하는 거니까

사용자 입장에서는 Actual storage를 세팅할 필요가 없고, 안전하게 스토리지를 사용하기만 하면 된다!

ConfigMap and Secret

별도의 pv라는 볼륨을 define하지 않고, 특별한 용도로 사용되는 2개의 볼륨이 있다.

ConfigMap과 Secret이다.

• secret: password, token, key,
• cm: 세팅하기 위한 파라미터를 담아두는 파일

얘네는 미리 만들어져있는 볼륨이다. (즉 pvc가 필요없다.)YAML 에 쓰는 방식은 나름 비슷하다. configMap을 spec안에 정의해두면 된다.

그래서 하나의 pod안에 여러개 다양한 타입의 Volume이 있을 수도 있다.

Storage Class

• 자동화를 위해 추가된 새로운 리소스오브젝트
• pvc만들때 스토리지클래스이름써주면 그 스토리지클래스에 해당되는 pv를 만들어서 붙게됨
• 이 안에 provisioner에 관련된 sw tool이 있어서 뭐 사람없이 자동으로 pv를 설치해준다.

SC는 PV를 다이나믹하게 사용할 수 있게 한다. 미리 준비시키는 것이 아니라 필요할 때 딱딱 만들어줄 수 있게 한다.

뭐 어느정도의 클래스로 만들어두고, 사용자의 원하는 걸 그때그때 조금씩 바꿔서 만든다!

또다른 abstraction level이라고 할 수도 있고, 사람이 제공하던 것을 추상화시킨거다.

사용 방법은 나름 간단하다. 원래 PVC.yaml에서 storageClassName: manual 이렇게 설정해줬었는데 , sc를 쓰려면 이 안에 storageClassName: storage-class-name 이런 식으로 매핑해주면 된다.

# Storage Class Config
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
	name: storage-class-name
privisioner: kubernetes.io/aws-ebs
parameters:
	type: io1
	iopsPerGB: "10"
	fsType: ext4

오늘부터는 volume에 대해서 배워본다.

테크월드 윗나나?? 를 유튜브에 검색하면 여러가지 쿠버네티스랑 도커에 강의한 부부닝 있음

중간고사때까지는 수요일날 volume에 대해 실습할 수 있게 할 것임

담주월에는 daemonset이랑 job에 대해서

---

기초용어

Drive: 저장장치

Volume: 논리적인 저장장치 ex. Window의 C:, D:, 독자적인 단일 스토리지 영역

볼륨은 논리적인 저장장치라고 할 수 있음. 우리는 볼륨을 가지고 뭘할거냐?

pod를 보면 스토리지 관련된게 있었지만 이게 어떻게 설치된건지 몰랐음. 포드 안에 볼륨 없이 그냥 웹서버로 기초적으로 deploy를 했지만 실제 포드는 스토리지 기능이 묶여져있다. 볼륨을 붙여준다. Mount Volume이라고 부름. 우린 이 방법에 대해 학습할 거임

즉 pod에 스토리지를 붙이는 것을 배운다.

How to persist data in Kubernetes using volumes?

<aside> 🧩

kubernetes.io 가서 좀 모르는 개념들을 찾아보기!‼️ Documentation에 모든 문서들이 다 들어가있음. volume은 전문성있어야 공부할 수 있는 영역이긴함.

들어가서보면 볼륨에도 되게 종류가 많음

</aside>

우리가 배울거는~

emptyDir : pod가 죽으면 사라져버리는 애, 메인메모리 이용한 임시적인 볼륨

hostpath : 서버에 있는 스토리지, 서버를 사서 꾸미면 얘가 존재함. 서버가 고장나거나 다른 노드에서는 사용 못한다는 점에서 제한이 있음. 상용화할 때는 잘 안쓰고 pvc쓴다.

설치자의 입장은 매우 전문적이고, 우리는 사용자의 입장에서 공부하기 때문에 그거는 문서에서 찾아볼 수 있음. 우리는 pv, pvc 두개를 많이 사용함. 여기에 hostpath, emptydir 이런걸 쓰게 됨

이걸 어떻게 쓰는지 오늘 공부할 거다!

The need for volumes

mysql에다가 뭘 추가, 업데이트 할 수 있고, pod가 죽었다살아나도 다시 사용할 수 있어야한다. ⇒ 스토리지가 가져야할 특성(persistence)

(만약 emptydir일 경우는 임시적이기 때문에 pod가 죽었다가 살아나면 다 사라져.)

my-app이라는 pod와, mysql이라는 DB engine역할의 pod가 있고 이 둘이 연결되어 있는 상태일때, pod가 죽었다가 restart된다면? 죽은 pod안의 데이터는 유지될 수가 없다!(No data persistence out of the box!)

Storage Requirements

1. Storage that doesn’t depend on the pod lifecycle.
2. 스토리지는 pod가 죽어도 영향을 받지 않는다. 즉 계속 유지되어야 한다.
3. Storage must be available on all nodes.
4. pod가 죽었다 살아남 node1에서 죽고 node2에서 살아났다면? 스케쥴러가 노드를 정해주니깐 바뀔 수 있음. 근데 이렇게 노드가 바뀌었어도 스토리지는 계속 다시 쓸 수 있어야 함.(hostpath나 empydir은 이걸 보장 못해)
5. Storage needs be survive even if cluster crashes.ex) 스토리지 서버를 다른 시스템에 둔다던지, 아니면 클라우드 사업자가 제공하는 클러스터를 이용하던지 이런식으로..
6. 서버가 죽었다? 근데 데이터가 사라졌다? 이러면 말이 안되잖아. 그러니까 클러스터가 고장나는 경우도 대비해야함. 즉 스토리지는 클러스터 내에 구성되어있으면 안되고, 따로 구성되어있어야함.

Persistent Volume

사용입장이 아니라 준비하는 입장에서 클러스터가 쓸 수있는 스토리지를 준비하고, 얘가 쓸 수 있는 리소스를 정의해놔야한다. 이 새로운 리소스가 바로 persistentVolume 이다.

(CPU나 RAM처럼 하나의 Cluster Resource에 해당하는 것이 바로 Persistent Volume!)

얘 역시 리소스니까 우리가 전에 pod생성하고 할 때도 YAML작성했듯이, YAML을 작성한다.

kind: PersistentVolume

그렇지만,,,,

Cluster는 서버가 여러개 묶여있는데, 그 서버중에 스토리지만 가지고 있는 서버도 존재할 수 있고, 스토리지가 붙어있는 서버도 있을 수 있다. 이런 서버를 1) 로컬디스크 라고 한다.

또는 클러스터에 Network File System 즉 2) nfs 서버를 연결해서 쓸 수도 있다.

또는 클라우드 사업자들이 제공하는 3) Cloud Storage를 사용할 수도 있다.

Persistent Volume YAML Example

NFS storage 일 경우 써줘야할 spec들이 공홈에 다 적혀 있음

apiVersion : v1
kind : PersistentVolume
metadata:
	name: pv-name
spec: 
	capacity:
		storage: 5Gi
		volumeMode: Filesystem
		accessModes:
			- ReadWriteOnce
		persistentVolumeReclaimPolicy: Recycle
		storageClassName: slow
		mountOptions:
			- hard
			- nfsvers=4.0
		------
		# 여기부터는 nfs server에 존재하는 parameter
		------
		nfs:
			path: /dir/path/on/nfs/server
			server: nfs-server-ip-address
			

Google Cloud도… Local storage도 … 얘네만의 독자적인 parameter가 있다.그러므로 사용자 입장에서는 얘네가 있다는 것만 알지 잘 알지 못함. 머 머신러닝서버면 object storage써서 딜레이 줄이게하고.. 뭐용도에 따라서 다른 스토리지를 써야함 근데 보통 이건 스토리지 전문가가 하고, volume으로 define해서 사용자에게 제공하는 그런느낌 . 즉, 우리도 사용하는 입장에서 그 안의 파라미터에 대해서 다 알지는 못함.

근데 뭐 여기서 readwriteOnce 이런 접근 정도도 있고, Local storage의 node affinity..

우리는 근데 실습때 해봐야 emptydir이나 hostpath정도 써볼거임.

다른 스토리지는 그냥 어느정도로만 알고있으면 될 듯?

쿠버네티스어드미니스트레이터 자격증 시험도 persistent volume은 이미 준비되어있음. 이 클레임을 쓸 수 있냐를 시험으로 봄

• accessModes: 에 대해서• ROX (ReadOnlyMany): 여러 파드에서 읽기만 가능.• RWO-P (ReadWriteOncePod): 오직 하나의 파드에서만 읽기/쓰기 가능 (v1.22 이상).
• • RWX (ReadWriteMany): 여러 파드에서 읽기와 쓰기 모두 가능.
• • RWO (ReadWriteOnce): 한 개의 파드에서만 읽고 쓰기 가능.

Persistent Volumes are NOT namespaced

volume은 네임스페이스와 무관하게 따로 존재하는 리소스이다. 엔지니어가 persistent volume을 만들었으면, 이건 모두가 쓸수있어야함.

Local vs. Remote Volume Types

<aside>

• Local Volume Type: Local Disk Storage (물리적인 로컬 디스크, 특정 노드에 종속)
• Remote Volume Type: NFS 및 Cloud Storage (네트워크를 통해 원격으로 접근하는 스토리지) </aside>

Remote쪽에 있는 볼륨을 쓰면 상관없지만 Local한 볼륨(Local storage)을 쓴다면 아까의 요구사항 2번, 3번을 충족시키지 못한다.

1. Storage must be available on all nodes.
2. Storage needs be survive even if cluster crashes.

그래서 보통 중요한 데이터를 유지할때는 Remote storage를 쓰는 것이 일반적이다!

K8s Adiministrator and K8s User

결국 PV는 클러스터를 구축하는 단계에서 관리자가 만드는 것이다. 그러면 pod라는 것이 스토리지를 항상 필요로 하는데, 그렇다면 PV는 미리 존재해야 하는 것이 아닌가?하는 의문이 생긴다.

그래서 PVC라는 개념을 만들어서 PV를 만드는 것과 사용하는 것을 분리시켰다! 라고 할 수 있다. 우리는 PVC라는 스펙을 통해서 PV를 요청한다.

Persistent Volume Claim Component

엔지니어가 pv만들면, 내가 이걸 쓰고싶다면 내것으로 abstration해와야 함. 논리적으로 존재시키는 작업. 매번 pv를 붙들고 쓰는게아니라 pvc를 통해서 리소스를 내가 쓸 수있는 영역으로 끌어들임. 이걸 abstraction이라고 한다.

PVC안에 내가 가지고 싶은 볼륨 스펙을 작성하게 된다. 그리고 접근경로를 설정해줘야하고, pv와 달리 namespace 안에 종속이다.

그니까, pv쓰려면 pvc를 만드는 일부터 시작한다. 내가 pvc를 만들어놓으면 여기에 짝이 되는 pv가 붙게 된다. 그래서 나는 그 뒤로 pvc를 쓰는 것이다.

근데 만약 pvc를 만들었는데 거기에 적합한 pv가 없다묜..? 엔지니어가 빨리 pv를 만들어야함. 하지만 정상적이라면 여러개의 pv를 준비해놓고, Pvc가 만들어졌을때 바로가서 챡 붙어야 한답

storage class : pvc가 만들어졋을때 pv가 없더라도, active하게 바로 만들어서 가서 챡 붙게 해주는애(개념은 좀이따 볼게)

28p에 있는 코드 잘 봐두기

apiVersion: v1
kind: Pod
metadata:
  name: mypod  # Pod의 이름을 정의
spec:
  containers:
    - name: myfrontend  # 컨테이너의 이름
      image: nginx  # 컨테이너에서 사용할 이미지 (nginx 웹서버)
      volumeMounts:
        - mountPath: "/var/www/html"  # 컨테이너 내에서 마운트할 경로 (여기에 PVC가 연결될 디렉토리)
          name: mypd  # 아래에 정의된 볼륨의 이름을 참조
  volumes:
    - name: mypd  # 컨테이너에서 마운트할 볼륨 이름
      persistentVolumeClaim:
        claimName: pvc-name  # PVC 이름을 참조하여 PersistentVolumeClaim 연결
        
      

<aside> 🧩

1. 이 파일은 mypod라는 이름의 Pod를 정의하고 있어
2. 이 Pod는 nginx 이미지를 사용하는 컨테이너를 포함하고, /var/www/html 디렉토리로 **PersistentVolumeClaim (PVC)**를 마운트해.
3. volumeMounts는 컨테이너의 /var/www/html 디렉토리와 mypd 볼륨을 연결하고, 이 mypd 볼륨은 PVC인 pvc-name에 연결돼 있어.
4. PVC는 Pod가 사용하는 PersistentVolume을 제공하며, Pod가 데이터를 영구적으로 저장할 수 있는 공간을 제공함.

</aside>

# PVC 정의
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-name  # PersistentVolumeClaim의 이름
spec:
  storageClassName: manual  # 스토리지 클래스, 수동 관리되는 PV를 사용
  volumeMode: Filesystem  # 볼륨의 파일시스템 모드 (일반적으로 파일시스템으로 사용)
  accessModes:
    - ReadWriteOnce  # 하나의 노드에서 읽기 및 쓰기가 가능한 모드
  resources:
    requests:
      storage: 10Gi  # 요청하는 스토리지 크기 (10GiB)

<aside> 🧩

1. 이 파일은 pvc-name이라는 **PersistentVolumeClaim (PVC)**를 정의하고 있어.
2. PVC는 10GiB의 스토리지를 요청하며, ReadWriteOnce 모드로 하나의 노드에서 읽기 및 쓰기를 할 수 있게 허용해.
3. storageClassName: manual은 수동으로 관리되는 **PersistentVolume (PV)**를 사용함을 나타내며, 이를 통해 PVC가 PV에 연결돼.
4. 이 PVC는 Pod에 의해 마운트되며, Pod는 PVC를 통해 영구 스토리지에 데이터를 저장하고 읽어올 수 있음.

</aside>

Why so many abstractions?

스토리지의 종류에 따라 붙여주는 건 엔지니어들이 미리 해놔야하고, 쓰는 사람 입장에서는 원하는 걸 Claim을 통해서 요청을 하는 거니까

사용자 입장에서는 Actual storage를 세팅할 필요가 없고, 안전하게 스토리지를 사용하기만 하면 된다!

ConfigMap and Secret

별도의 pv라는 볼륨을 define하지 않고, 특별한 용도로 사용되는 2개의 볼륨이 있다.

ConfigMap과 Secret이다.

• secret: password, token, key,
• cm: 세팅하기 위한 파라미터를 담아두는 파일

얘네는 미리 만들어져있는 볼륨이다. (즉 pvc가 필요없다.)YAML 에 쓰는 방식은 나름 비슷하다. configMap을 spec안에 정의해두면 된다.

그래서 하나의 pod안에 여러개 다양한 타입의 Volume이 있을 수도 있다.

Storage Class

• 자동화를 위해 추가된 새로운 리소스오브젝트
• pvc만들때 스토리지클래스이름써주면 그 스토리지클래스에 해당되는 pv를 만들어서 붙게됨
• 이 안에 provisioner에 관련된 sw tool이 있어서 뭐 사람없이 자동으로 pv를 설치해준다.

SC는 PV를 다이나믹하게 사용할 수 있게 한다. 미리 준비시키는 것이 아니라 필요할 때 딱딱 만들어줄 수 있게 한다.

뭐 어느정도의 클래스로 만들어두고, 사용자의 원하는 걸 그때그때 조금씩 바꿔서 만든다!

또다른 abstraction level이라고 할 수도 있고, 사람이 제공하던 것을 추상화시킨거다.

사용 방법은 나름 간단하다. 원래 PVC.yaml에서 storageClassName: manual 이렇게 설정해줬었는데 , sc를 쓰려면 이 안에 storageClassName: storage-class-name 이런 식으로 매핑해주면 된다.

# Storage Class Config
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
	name: storage-class-name
privisioner: kubernetes.io/aws-ebs
parameters:
	type: io1
	iopsPerGB: "10"
	fsType: ext4