Kubernetes의 초기 버전에서는 Docker를 유일한 컨테이너 런타임 엔진으로 사용하였습니다. Docker와 Kubernetes 간의 모든 작업은 Kubernetes 소스 코드 내에 직접 포함되어 있었습니다. 하지만, Rocket이나 CRI-O 같은 다른 컨테이너 런타임이 등장하면서 Kubernetes는 다양한 컨테이너 런타임을 지원하기 위해 소스 코드에 직접 의존하지 않는 확장성이 필요하게 되었습니다. 이러한 배경에서 탄생한 것이 바로 컨테이너 런타임 인터페이스(Container Runtime Interface, CRI)입니다.
컨테이너 런타임 인터페이스 (CRI)
CRI는 Kubernetes와 Docker와 같은 컨테이너 런타임 간의 통신 방법을 표준화한 인터페이스입니다. 이 표준을 따르는 새로운 컨테이너 런타임이 개발되면, Kubernetes 소스 코드에 직접적인 변경 없이 Kubernetes와의 연동이 가능해집니다. 이는 Kubernetes의 확장성을 크게 향상시켰고, 다양한 컨테이너 런타임을 지원할 수 있는 기반이 되었습니다.
컨테이너 네트워킹 인터페이스 (CNI)
네트워킹 솔루션의 확장성을 위해 도입된 것이 바로 컨테이너 네트워킹 인터페이스(Container Networking Interface, CNI)입니다. CNI를 통해 새로운 네트워킹 벤더들은 CNI 표준을 기반으로 플러그인을 개발하여 Kubernetes와 쉽게 연동할 수 있게 되었습니다. 이를 통해 다양한 네트워킹 솔루션이 Kubernetes에서 원활하게 동작할 수 있게 되었습니다.
컨테이너 스토리지 인터페이스 (CSI)
컨테이너 스토리지 인터페이스(Container Storage Interface, CSI)는 위의 CRI와 CNI와 유사한 맥락에서 다양한 스토리지 솔루션을 지원하기 위해 개발되었습니다. CSI를 사용하면 Kubernetes와 연동될 수 있는 스토리지 드라이버를 작성할 수 있습니다. Portworx, Amazon EBS, AzureDisk, Dell EMC, NetApp, Nutanix, HPE, Hitachi, Pure Storage 등 많은 스토리지 회사들이 자체 CSI 드라이버를 가지고 있습니다.
CSI의 보편성
CSI는 Kubernetes 특정 표준이 아니라 보편적인 표준으로서, 구현되면 어떤 컨테이너 오케스트레이션 툴에서도 지원되는 플러그인과 함께 작동할 수 있습니다. 현재 Kubernetes, Cloud Foundry, Mesos가 CSI를 지원하고 있으며, 이를 통해 다양한 환경에서 동일한 스토리지 솔루션을 사용할 수 있습니다.
CSI의 작동 방식
CSI는 컨테이너 오케스트레이터가 호출하는 일련의 원격 절차 호출(RPC)을 정의하며, 이는 스토리지 드라이버에 의해 구현되어야 합니다. 예를 들어, 포드가 생성되고 볼륨이 필요할 때 Kubernetes와 같은 컨테이너 오케스트레이터는 CreateVolume RPC를 호출하고 볼륨 이름과 같은 세부 정보를 전달합니다. 스토리지 드라이버는 이 RPC를 구현하고 해당 요청을 처리하여 스토리지 배열에 새 볼륨을 프로비저닝하고 작업 결과를 반환해야 합니다. 마찬가지로, 볼륨을 삭제할때는 DeleteVolume RPC를 호출하여 스토리지 드라이버가 해당 호출 시 스토리지 배열에서 볼륨을 해제하는 코드를 구현해야 합니다.
마치며
컨테이너 스토리지 인터페이스(Container Storage Interface, CSI)는 다양한 스토리지 솔루션과 Kubernetes와의 연동을 가능하게 하는 중요한 표준입니다. 이를 통해 Kubernetes의 스토리지 확장성이 크게 향상되었으며, 다양한 스토리지 벤더들이 자신들의 솔루션을 Kubernetes 환경에서 쉽게 사용할 수 있게 되었습니다. 앞으로도 CSI의 발전과 함께 더 많은 스토리지 솔루션이 Kubernetes와 원활하게 통합될 것으로 기대됩니다.
