📦 Container Storage Interface (CSI)

---

🧩 CSI가 생긴 이유

기존에는 쿠버네티스가 Docker에 의존적이었고, Docker와 통신하는 코드가 Kubernetes 내부에 하드코딩되어 있었음.
이 구조는 아래 문제를 발생시킴:

• ❌ 새로운 컨테이너 런타임(CRI-O, containerd 등) 을 지원하기 어려움
• ❌ 새로운 스토리지 솔루션을 도입하려면 쿠버네티스 소스 코드를 수정해야 했음

그래서 아래와 같은 표준 인터페이스들이 만들어졌어:

표준	목적
CRI (Container Runtime Interface)	쿠버네티스가 다양한 컨테이너 런타임과 통신 가능
CNI (Container Networking Interface)	다양한 네트워크 솔루션을 플러그인 형태로 통합
CSI (Container Storage Interface)	다양한 스토리지 벤더의 솔루션과 연동 가능

---

🔌 CSI란 무엇인가?

• CSI는 스토리지 벤더가 자신들의 플러그인을 Kubernetes에 연결할 수 있게 해주는 표준 인터페이스

• CSI 스펙을 구현하면 쿠버네티스는 해당 스토리지와 상호작용 가능

• CSI는 쿠버네티스 전용이 아니라 범용 표준으로,

  • Cloud Foundry, Mesos 등 다른 오케스트레이터도 사용할 수 있어

---

🛠 CSI 구조 – RPC 기반 인터페이스

CSI는 gRPC 기반의 호출 규칙(RPC) 을 정의해놓음.

예: CreateVolume RPC

• Kubernetes가 Pod을 생성할 때 PVC(Persistent Volume Claim)를 통해 스토리지를 요청

• CSI 드라이버는 CreateVolume RPC를 구현하여,

  • 스토리지 벤더의 API를 호출하고,
  • 실제 스토리지에 볼륨을 프로비저닝
  • 성공/실패 응답을 Kubernetes에 전달

CSI가 제공하는 주요 RPC 목록

RPC	설명
CreateVolume	볼륨 생성
DeleteVolume	볼륨 삭제
ControllerPublishVolume	노드에 볼륨 attach
ControllerUnpublishVolume	노드에서 볼륨 detach
NodePublishVolume	컨테이너에 볼륨 mount
NodeUnpublishVolume	컨테이너에서 볼륨 unmount

---

🌍 대표적인 CSI 드라이버 예시

벤더	CSI 드라이버 이름
AWS	ebs.csi.aws.com
GCP	pd.csi.storage.gke.io
Azure	disk.csi.azure.com
NetApp	trident.netapp.io
Portworx	pxd.portworx.com
VMware	csi.vsphere.vmware.com

---

📐 CSI 도입 전후 비교

항목	CSI 도입 전	CSI 도입 후
스토리지 연동 방식	쿠버네티스 내에 내장 / 하드코딩	플러그인 형태로 동적 연동 가능
스토리지 확장성	제한적 (K8s 코드 수정 필요)	뛰어남 (CSI 규격만 따르면 됨)
오케스트레이터 호환성	Kubernetes 전용	Kubernetes, Mesos, CloudFoundry 등 호환

---

✍️ 마무리 요약

• CSI는 스토리지 연동을 위한 범용 표준
• CSI 드라이버를 사용하면 스토리지 벤더와 Kubernetes의 결합도를 낮추고, 유연한 확장성 제공
• Kubernetes는 CSI를 통해 동적으로 볼륨을 생성/삭제/마운트할 수 있음
• CSI 스펙은 GitHub CSI Repo에서 확인 가능