[Cloud] Kubernetes Volumes I (emptyDir, hostPath, Persistent Volume)

Kubernetes Volumes

• Drive(storage device): 물리적 or 가상적인 저장 장치 자체를 의미
• Mount Volume: 외부의 저장소(Storage)를 컨테이너 내부의 특정 경로(Directory)에 연결하여, 컨테이너가 마치 자기 것처럼 사용할 수 있게 하는 과정
  • Worker Node(컨테이너)에게 저장소를 할당하는 과정

 

Types of Volume

• Storage에서 파생된 리소스의 종류
• Temporary space(임시 저장 공간): 임시적인 데이터 공간
  • 데이터의 생명주기가 Pod와 운명을 같이 함
  • emptyDir, ConfigMap / Secret, Downward API
• filesystem(Node 수준의 저장 공간)
  • 호스트 노드의 파일 시스템에 있는 파일이나 디렉터리를 Pod에 마운트
    
    • hostPath
• drably storing data(지워지면 안 되는 데이터)
  • 데이터의 생명주기가 포드와 분리됨
  • 포드가 삭제되어도 데이터는 유지되어야 할 때 사용
  • Persistent Volume
    • = Persist Volume Claim

 

emptyDir (Pod 공유)

• Pod 안에 생성되어 동일한 Pod 안에 실행 중인 컨테이너들이 공유할 수 있는 임시 공간(Temp)
• 저장 위치: 기본적으로 노드의 디스크 공간 사용
• 생명 주기: Pod가 해당 노드에서 실행되는 동안만 존재
  • Pod가 삭제되면 emptyDir 안의 데이터도 영구 삭제
    
    • 컨테이너가 재시작되는 것과는 별개 (Pod 안에서 컨테이너가 돌아가기 때문에 독립적임)
• 생성 과정
  1. 사용자가 emptyDir이 포함된 Pod를 배포
  2. kubelet이 포드 명세를 확인하고 emptyDir이 필요하단 것을 인지
  3. kubelet이 해당 노드의 로컬 디스크에 실제 Directory 생성
  4. 컨테이너 엔진에게 요청
  5. 컨테이너 엔진이 kubelet이 시킨 대로 노드의 특정 경로와 컨테이너 내부 경로를 마운팅

• name의 emptyDir을 만들어달라고 요청 중
• 컨테이너 2개를 만들어서 각각 /test1, /test2라는 mountPath를 입력
  • test1, test2라는 Directory를 각각 만들어서 거기에다 emptyDir을 연동(name: test-dir) 중

 

hostPath (Node filesystem 공유)

• Pod가 실행 중인 호스트 노드(Worker Node)의 특정 폴더를 컨테이너 안에 그대로 연결(Mount)하는 방식
• 저장 위치: 실제로는 노드의 디스크(Filesystem)에 저장
• 데이터 보존
  
  • Pod 바깥에 존재하므로 Pod를 죽여도 메모리가 살아있음
  • node(컴퓨터)가 재부팅되어도 디스크에 저장된 것이므로 해당 노드엔 일반적인 파일이 남아있음
    • 하지만 Pod가 A 노드에서 B 노드로 옮겨가서 재실행되면, B 노드에는 이전 데이터가 없음
      >> Pod가 다른 노드로 옮겨갈 수도 있으므로 데이터가 항상 보전된다고 보장하지 못함 

• container는 mountPath를 통해 저장소를 사용할 경로를 명시함
  • container를 만들어서 test-volume이라는 hostPath 볼륨(데이터 원본)과 마운팅
     = /test1이라는 Directory를 만들어서 데이터를 사용하는 통로를 만든 것
• DirectoryOrCreate: 노드에 /test-volume 폴더가 없으면, 쿠버네티스가 알아서 폴더를 만든 뒤 마운트해줌
• test1이라는 폴더에 test-volume이라는 git을 clone 한 느낌
  • 근데 이제 git이 local git이고 컴퓨터가 바뀌면 데이터 못 찾음

 

Persistent Volume (Claim)

 

• PV(Persistent Volume): 외부에 저장공간을 미리 정의, 사라지지 않는 메모리 (실제 저장 장치)
  • Cloud 관리자가 미리 만들어줘야 함
  • namespace에 종속되지 않음
  • ex) AWS EBS, NFS, 로컬 디스크 등
• PVC(Persistent Volume Claim): 사용자가 PV를 사용하기 위해 던지는 요청서(Claim)
  • 사용자 입장에선 이 친구만 알면 PV 사용 가능
    • 메모리(PV)를 미리 만드는 것은 Cloud 관리자의 영역이라 몰라도 됨
  • PVC 자체는 namespace에 종속됨 (어떠한 namespace가 PV를 사용한다는 의미기 때)
• PVC가 특정 PV와 연결(Binding)되면, 그 PV는 해당 PVC를 소유한 namespace 전용이 됨
  • 다른 namespace에서 그 PV를 탐내도 이미 예약 완료 상태임 
• SC: PV 생성기
  • 사용자가 PVC를 통해 요청하면, 실시간으로 PV를 생성함
  • Cloud 관리자가 미리 PV를 만들 필요가 없어지고, 사용자가 PVC만 던지면 알아서 PV를 찍어냄

 

PV 생성

• 리소스(PV) 생성 명령어: kubectl apply -f 3-pv.yaml
• 리소스(PV) 생성 확인 명령어: kubectl get pv

yaml files

 

PVC 생성

• 리소스(PVC) 생성 명령어: kubectl apply -f a-pvc.yaml
• 리소스(PVC) 배포 확인: kubectl get pvc -n a
  
  • "kubectl get pvc -A"로 모두 확인 가능
• kubernetes가 요청한 storage 크와 최적으로 맞는 PV를 자동으로 할당해줌

 

Pod 생성 with PVC Mount

• 리소스(Pod) 생성: kubectl apply -f a-pod.yaml
• 리소스(Pod) 확인: kubectl get po -n a -o wide

 

Namespace of PV/PVC

Persistent Volumes are NOT namespaced

• PV: 어떠한 특정 namespace에 종속되지 않고, 모든 namespace에서 사용할 수 있음
• PVC: 어떤 namespace에서 이 PV를 접근하는 것이기 때문에 namespace에 종속됨
  • 이걸 다른 namespace들이랑 어떻게 사용할지 의논하는 게 StatefulSet
  • 근데 사실상 PV는 하나의 namespace에만 종속하기에 위 그림은 틀린 그림임

 

실습 끝나고 복습할 것

• emptyDir, hostPath 복습 겸 만들어보기
• 만들어진 storage access 해서 파일도 만들어보고 해 보기
• 껐다 켜보기도 하고 개념 확인, 원리 분석