CSI — 볼륨 생성과 마운트의 구현

결론부터

CSI 드라이버는 Kubernetes의 저장소 요청을 실제 볼륨 생성·연결·마운트 작업으로 바꾼다.

StorageClass는 어떤 구현을 사용할지 지정한다. 이 장에서는 그 뒤에서 일하는 Controller 플러그인과 노드의 플러그인을 구분하고, 설치된 드라이버를 확인하는 명령까지 익힌다.

CSI — 스토리지 확장 인터페이스

스토리지 벤더가 새 제품을 지원하려면 예전에는 Kubernetes 본체에 코드를 넣어야 했다. 드라이버 수정 하나가 Kubernetes 릴리스 주기를 기다려야 했고, 드라이버 버그가 kubelet을 같이 죽였다. CSI(Container Storage Interface)는 스토리지 벤더가 Kubernetes 코드 밖에서 드라이버를 만들 수 있게 한 표준 인터페이스다 — 벤더는 정해진 gRPC 인터페이스만 구현하고 자기 속도로 배포한다.

예전에는 스토리지 드라이버가 Kubernetes 코드 안에 있었다 (in-tree)
지금은 전부 CSI 드라이버로 분리되었다. 벤더가 독립적으로 배포한다
in-tree 플러그인은 대부분 제거되었고 CSI로 마이그레이션되었다

kubectl get csidrivers
kubectl get csinodes
kubectl get pods -n kube-system | grep csi

컴포넌트	역할
Controller 플러그인	볼륨 생성·삭제·attach (Deployment/StatefulSet)
Node 플러그인	노드에서 마운트 (DaemonSet)
sidecar 컨테이너들	`provisioner`, `attacher`, `resizer`, `snapshotter`

sidecar 컨테이너들은 벤더가 매번 다시 만들 필요가 없도록 Kubernetes 프로젝트가 제공하는 공용 조각이다. 각자 API 서버를 지켜보다가(PVC가 생겼다, 크기가 바뀌었다) 그 요청을 드라이버의 gRPC 호출로 번역한다 — 여기서도 축은 같다. 선언(PVC)과 실제(볼륨)의 차이를 줄이는 루프가 드라이버 바깥의 sidecar에 들어 있는 셈이다.

CSI는 커리큘럼의 “확장 인터페이스(CNI, CSI, CRI) 이해” 항목이다. 확장에서 함께 정리한다.

시험 비중 낮음 다만 드라이버를 직접 배포하거나 sidecar 구성을 손보는 수준까지 팔 필요는 없다 — 층이 어떻게 나뉘는지와 kubectl get csidrivers로 무엇이 설치돼 있는지 확인할 줄 알면 충분하다.

요약

Controller 쪽은 볼륨 생성·삭제·연결을, Node 쪽은 노드에서의 마운트를 맡는다.
공용 사이드카는 Kubernetes API의 요청을 CSI 드라이버 호출로 연결한다.
드라이버 내부 구현보다 csidrivers·csinodes와 관련 Pod의 위치를 먼저 확인한다.

다음: 스토리지 진단 — Pending과 마운트 실패