8. [Architecture]: Storage - File / Object / Block Storage

쿠버네티스 아키텍처의 세 번째 기둥인 스토리지(Storage)에 대해 파헤쳐 보자. 데이터가 사라지면 서비스도 의미가 없기에, 엔지니어로서 스토리자를 어떻게 다루느냐는 매우 중요한 역량이다.

 

---

 

 

1. PV 생성 및 연결 방식 (Concept)

쿠버네티스에서 스토리지를 사용하는 방법은 크게 세 가지 흐름으로 나뉜다. 다시 정리해보자.

1. 일반적인 방법 (Static): 이미 알듯이, 관리자가 미리 PV(Persistent Volume)를 만들어 두고, 사용자가 PVC(Persistent Volume Claim)를 통해 이를 예약하여 사용하는 방식이다.
2. StorageClass 그룹화: StorageClass를 사용하여 PV들을 특정 그룹으로 묶어둔다. PVC를 만들 때 클래스 이름을 지정하면 해당 그룹 내에서 조건에 맞는 PV와 자동으로 매칭된다.
3. 동적 프로비저닝 (Dynamic Provisioning): 가장 진화된 방식으로, 프로비저너(Provisioner)가 설정된 StorageClass를 사용한다. 사용자가 PVC만 요청하면 프로비저너가 실시간으로 실제 스토리지를 할당하고 PV를 자동으로 생성해 준다.

 

 

 

2. PV의 속성과 볼륨 플러그인 (Volume Plugins)

PV를 정의할 때는 용량(Capacity), 접근 모드(accessModes), 그리고 실질적인 연결을 담당하는 볼륨 플러그인 설정이 필수다.

• 대표적 플러그인
  • hostPath: 워커 노드의 로컬 경로를 직접 사용한다.
  • NFS: 외부 NFS 서버와 연결한다. 단, 워커 노드 OS에 NFS 클라이언트가 반드시 설치되어 있어야 작동한다.
  • Cloud Service: Azure, GCE, AWS 등 클라우드 벤더의 전용 스토리지를 사용한다.
  • 3rd Party Vendors: Ceph, Glusterfs 등 전문 솔루션 업체의 스토리지를 연결한다.
• CSI (Container Storage Interface): 특정 솔루션이 쿠버네티스 코어에 포함되어 있지 않거나 최신 버전 지원이 필요할 때 사용하는 인터페이스다. 기업들이 가이드에 맞춰 CSI 플러그인을 만들어 배포하면 사용자는 이를 클러스터에 설치해 간단히 사용할 수 있다.

 

 

 

3. 스토리지 타입별 특성과 액세스 모드 (Storage Types)

이 부분이 실무에서 가장 중요하다. 내가 선택한 스토리지가 어떤 타입인지에 따라 지원되는 기능이 완전히 달라진다.

•  ReadWriteOnce(RWO)
  • 단일 노드 읽기/쓰기
  • 하나의 노드에서만 마운트 가능. (그 노드 안의 여러 포드는 공유 가능)
• ReadOnlyMany(ROX)
  • 여러 노드 읽기 전용
  • 여러 노드에서 동시에 읽을 수 있음. 쓰기는 불가.
• ReadWriteMany(RWX)
  • 여러 노드 읽기/쓰기
  • 여러 노드에서 동시에 읽고 쓰기 가능. (NFS 같은 공유 파일 시스템 필요)
    • NFS를 사용한 PV/PVC를 만들어야할 때 = 여러 노드에서 동시에 접근해야할 때.

스토리지 타입	대표 솔루션	특징	권장 액세스 모드
File Storage	NFS, CephFS	전형적인 공유 파일 시스템	RWO, ROX, RWM
Object Storage	AWS S3, Azure Blob	이미지 저장, 백업용으로 주로 사용	RWO, ROX, RWM
Block Storage	AWS EBS, Google PD	DB 데이터 저장용, 고성능 리드/라이트	RWO (전용)

 

 

 

 

⚠️ 블록 스토리지(Block Storage)의 기술적 제약

블록 스토리지는 기술적으로 한 번에 하나의 노드에만 마운팅이 가능하다.

• 노드 내 공유: 한 노드 위에 있는 여러 파드가 동시에 연결되는 것은 가능하다.
• 노드 간 공유 불가: 서로 다른 노드에 있는 파드들이 동시에 블록 스토리지를 사용하는 것은 불가능하다. 파드가 다른 노드로 옮겨가면 기존 노드와 연결을 끊고 새 노드와 다시 연결해야 한다.
• 결과: 따라서 블록 스토리지는 기본적으로 ReadWriteOnce (RWO) 옵션만 지원한다고 이해해야 한다.

 

 

 

💡 실무 포인트

 

• 스토리지를 선택할 때 "공유 데이터인가, 아니면 DB용인가?"를 먼저 고민해라.
  • 일반적인 앱 배포(Deployment)에는 파드가 어느 노드에 가든 데이터 접근이 쉬운 파일/오브젝트 스토리지가 유리하고,
  • 데이터 무결성과 성능이 중요한 DB 배포(StatefulSet)에는 블록 스토리지가 정답이다.

 

 

 

---

 

 

 

 

1. CSI(컨테이너 스토리지 인터페이스)의 구성 요소

스토리지 솔루션을 설치하면 네임스페이스에 정체 모를 파드들이 잔뜩 생기는데, 딱 두 가지만 기억하자.

• 컨트롤 플러그인 (The Brain): 주로 디플로이먼트로 생성된다. 클러스터 전체의 볼륨 생성, 삭제, 수정 같은 '행정 업무'를 담당하는 총괄 본부다.
• 노드 플러그인 (The Muscle): 각 노드에 데몬셋으로 깔린다. 실제로 해당 노드에서 볼륨을 만들고 마운트하는 '현장 업무'를 수행한다.

 

2. 볼륨을 관리하는 역할들

이 파드들 안에는 각자 맡은 임무가 명확한 전문자라고 할 수 있는 것들이 살고 있다.

• CSI 프로비저너 (Provisioner): PVC가 생기면 "어? 볼륨 필요해?" 하고 달려와서 PV를 만들어준다.
• CSI 리사이저 (Resizer): "볼륨이 좁아!" 하고 PVC 용량을 키우면, 실제 스토리지 크기를 늘려준다.
• CSI 스냅샤터 (Snapshotter): 특정 시점의 데이터 사진(스냅샷)을 찍어 보관한다.
• CSI 어태처 (Attacher): 볼륨이 다 만들어지면 파드와 볼륨을 끈끈하게 연결해 주는 연결 전문가다.

 

 

3. 볼륨이 탄생하고 파드에 붙기까지 (Life Cycle)

1. 발단: 사용자가 PVC를 만든다.
2. 생성: 프로비저너가 이를 감지하고 PV를 만들어 PVC와 짝을 맺어준다.
3. 실행: 노드의 CSI 플러그인이 솔루션 매니저에게 명령을 내리고, 최종적으로 엔진이 실제 물리 볼륨을 생성한다.
4. 연결: 파드가 PVC를 쓰려고 하면 볼륨 어태치먼트 오브젝트가 생기고, 이를 본 어태처가 볼륨을 파드에 꽂아준다.

 

나중에 kubectl get pod을 쳤는데 longhorn-csi-attacher-... 같은 파드가 Error 상태인 걸 본다면,*"아, 저 녀석이 죽어서 지금 내 볼륨이 파드에 안 붙고 있구나!"라고 원인을 바로 찾아낼 수 있게 된다.