Udemy CKA 강의 정리 183: Container Storage Interface(CSI)

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이제 컨테이너 스토리지 인터페이스를 살펴보겠습니다.

Container Runtime Interface

과거 쿠버네티스는 컨테이너 런타임 엔진으로 도커만 사용했고, 도커와 연동되는 모든 코드는 쿠버네티스 소스 코드에 builtin되어 있었습니다. Rocket 및 CRI-O와 같은 다른 컨테이너 런타임이 등장함에 따라 Kubernetes 소스 코드에 의존하지 않고 다른 컨테이너 런타임으로 작업할 수 있도록 지원을 개방하고 확장하는 것이 중요했습니다. 이것이 컨테이너 런타임 인터페이스가 탄생한 배경입니다.

Container Storage Interface

컨테이너 스토리지 인터페이스는 Kubernetes와 같은 오케스트레이션 솔루션이 Docker와 같은 컨테이너 런타임과 통신하는 방법을 정의하는 표준입니다. 따라서 미래에 새로운 컨테이너 런타임 인터페이스가 개발되면 CRI 표준을 따를 수 있으며 새로운 컨테이너 런타임은 Kubernetes 개발자 팀과 실제로 작업하거나 Kubernetes 소스 코드를 만질 필요 없이 Kubernetes에서 작동합니다.

짐작할 수 있듯이 Container Storage Interface는 여러 스토리지 솔루션을 지원하도록 개발되었습니다. CSI를 사용하면 이제 자체 스토리지용 드라이버를 작성하여 Kubernetes와 함께 사용할 수 있습니다. Port Works, Amazon EBS, Azure Desk, Dell EMC Isilon, PowerMax Unity, XtremIO, NetApp, Nutanix, HPE, Hitachi, Pure Storage. 누구나 자신만의 CSI 드라이버를 가지고 있습니다. CSI는 Kubernetes 특정 표준이 아닙니다. 이것은 보편적인 표준을 의미하며 구현된 경우 모든 컨테이너 오케스트레이션 도구가 지원되는 플러그인이 있는 모든 스토리지 공급업체와 작동할 수 있습니다. 현재 Kubernetes Cloud Foundry와 Mesos는 CSI에 탑재되어 있습니다. 이것이 CSI의 모습입니다.

이것은 컨테이너 오케스트레이터에 의해 호출될 RPC 또는 원격 프로시저 호출 세트를 정의하며 스토리지 드라이버에 의해 구현되어야 합니다. 예를 들어 CSI는 파드가 생성되고 볼륨이 필요할 때 컨테이너 오케스트레이터(이 경우 Kubernetes)가 볼륨 생성 RPC를 호출하고 볼륨 이름과 같은 세부 정보 집합을 전달해야 한다고 말합니다. 스토리지 드라이버는 이 RPC를 구현하고 해당 요청을 처리하고 스토리지 어레이에서 새 항목을 프로비저닝하고 작업 결과를 반환해야 합니다. 마찬가지로 컨테이너 오케스트레이터는 볼륨이 삭제될 때 볼륨 삭제 RPC를 호출해야 하며 스토리지 드라이버는 해당 호출이 이루어질 때 어레이에서 볼륨을 폐기하는 코드를 구현해야 합니다. 그리고 사양에는 색상이 전송해야 하는 파라미터, 솔루션에서 수신해야 하는 파라미터, 교환해야 하는 오류 코드가 정확히 무엇인지 자세히 설명되어 있습니다. 관심이 있는 경우 이 URL의 GitHub에 있는 CSI 사양에서 이러한 모든 세부 정보를 볼 수 있습니다. 

• https://github.com/container-storage-interface/spec

Container Networking Interface

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