[CKA] Container Storage Interface (CSI)

컨테이너 스토리지 인터페이스를 살펴보자.
과거에 쿠버네티스는 컨테이너 런타임 엔진으로 도커를 단독으로 사용했으며, 도커와 함께 작동하기 위한 모든 코드는 쿠버네티스 소스 코드에 내장되어 있었다. Rocket 및 CRI-O와 같은 다른 컨테이너 런타임이 들어오는 상황에서, Kubernetes 소스 코드에 의존하지 않고 다른 컨테이너 런타임으로 작업할 수 있도록 지원을 개방하고 확장하는 것이 중요했다. 이것이 컨테이너 런타임 인터페이스의 탄생 배경이다.

컨테이너 스토리지 인터페이스는 쿠버네티스와 같은 오케스트레이션 솔루션이 도커와 같은 컨테이너 런타임과 통신하는 방법을 정의하는 표준이다. 그래서 미래에 새로운 컨테이너 런타임 인터페이스가 개발된다면 단순히 CRI 표준을 따 따르기만 라면 되고, 새로운 컨테이너 런타임은 개발자들로 구성된 쿠버네티스 팀과 협력하거나 쿠버네티스 소스 코드를 터치할 필요 없이 쿠버네티스와 함께 작동할 것이다.

마찬가지로, 다양한 네트워킹 솔루션에 대한 지원을 확장하기 위해 컨테이너 네트워킹 인터페이스가 도입되었다. 이제 새로운 네트워킹 공급업체는 CNI 표준을 기반으로 플러그인을 개발하고 Kubernetes와 함께 솔루션을 작동시킬 수 있다.

그리고 컨테이너 스토리지 인터페이스는 다중 스토리지 솔루션을 지원하도록 개발되었다. CSI를 사용하면 이제 Kubernetes와 함께 작동할 스토리지에 대한 드라이버를 직접 작성할 수 있다.

portworx, Amazon EBS, Azure Desk, Dell EMC Isilon, PowerMax Unity, XtremIO, NetApp, Nutanix, HPE, Hitachi, Pure Storage 등 모든 사람들은 자신만의 CSI 드라이버를 가지고 있다.

CSI는 Kubernetes 특정 표준이 아니다. 이 표준은 범용 표준이며, 구현된 경우 모든 컨테이너 오케스트레이션 도구가 지원되는 플러그인을 사용하는 스토리지 벤더와 함께 작동할 수 있습니다. 현재 CSI에는 쿠버네티스, 클라우드 파운드리, 메소스가 참여하고 있다.

CSI는  컨테이너 오케스트레이터가 호출할 일련의 RPC 또는 원격 프로시저 호출을 정의하며 이러한 호출은 스토리지 드라이버에 의해 구현되어야 한다. 예를 들어 CSI는 포드가 생성되고 볼륨이 필요한 경우 컨테이너 오케스트레이터가 볼륨 생성 RPC를 호출하여 볼륨 이름과 같은 세부 정보 집합을 전달해야 한다. 스토리지 드라이버는 이 RPC를 구현하고 해당 요청을 처리하고 스토리지 어레이에서 새 프로비저닝을 수행한 후 작업 결과를 반환해야 한다. 마찬가지로 컨테이너 오케스트레이터는 볼륨을 삭제할 때 볼륨 삭제 RPC를 호출하고 스토리지 드라이버는 볼륨을 호출할 때 어레이에서 해제하는 코드를 구현해야 한다. 그리고 규격에는 솔루션에서 수신해야 할 파라미터와 교환해야 할 에러 코드가 색상별로 정확히 명시되어 있다.