Kubernetes 생태계 표준화와 Container Interface(CRI, CSI, CNI)

Overview

오늘은 Kubernetes에서 핵심 컴포넌트와 외부 시스템 간의 모듈식 연동을 가능하게 하는 표준 인터페이스, 즉 CRI, CSI, CNI, CDI 등 다양한 Container 인터페이스에 대해 알아본다.

 

Kubernetes는 다양한 클라우드 환경과 기술 스택에 확장성과 유연성을 제공하기 위해, 특정 런타임이나 네트워킹/스토리지 기술에 의존하지 않고 표준화된 인터페이스를 통해 구성 요소를 분리해왔다.

이러한 구조는 새로운 기술의 빠른 통합, 공급자 중립성 확보, 클러스터 운영 단순화, 그리고 생태계의 확장을 가능하게 했다.

 

이번 글에서는 각 인터페이스가 무엇을 해결하고자 등장했는지,

그리고 어떤 방식으로 Kubernetes 환경에서 동작하고 있는지를 이해함으로써,

쿠버네티스가 왜 현대 클라우드 네이티브 인프라에서 중요한 오케스트레이션 플랫폼이 되었는지를 살펴본다.

 

 

 

출처 : https://community.veeam.com/blogs-and-podcasts-57/about-container-runtimes-in-2-minutes-5791

 

 

 

 

 

---

 

 

 

 

 

Kubernetes 생태계 표준화

 

앞서 Oveivew에서 설명했던 것처럼 표준화가 필수적이었던 주요 이유에 대해서 알아본다.

 

인터페이스를 통해 Kubernetes는 사내, 퍼블릭 클라우드 또는 하이브리드 설정 등 모든 인프라에서 작동할 수 있는

확장 가능하고 휴대 가능하며 확장 가능한 오케스트레이션 플랫폼이라는 핵심 원칙을 유지할 수 있다.

​

 

 

 

 

Decoupling Core Kubernetes from Specific Technologies(쿠버네티스 코어와 특정 기술의 분리)

• Flexibility(유연성): 인터페이스가 도입되기 전에 쿠버네티스는 특정 구현(컨테이너 런타임 및 특정 네트워킹 솔루션용 도커)과 긴밀하게 결합되었다. 이러한 결합으로 인해 쿠버네티스를 다양한 환경에 적용하거나 새로운 기술을 통합하는 것이 어려웠다.
• Modularity(모듈성): 쿠버네티스는 명확한 인터페이스를 정의함으로써 런타임, 스토리지 및 네트워킹을 처리하는 실제 서비스에서 오케스트레이션 계층을 분리할 수 있었다. 이 분리를 통해 핵심 쿠버네티스 시스템에 영향을 주지 않고 구성 요소 간의 업데이트, 유지 관리 및 스왑을 더 쉽게 할 수 있다.

 

 

 

 

Facilitating Innovation and Inclusion of New Technologies(혁신 및 신기술 도입)

• Vendor Neutrality(벤더 중립성): 표 준 인터페이스를 사용하면 정의된 API 사양을 준수하는 한 모든 벤더가 쿠버네티스에서 플러그인을 개발하거나 기술을 지원할 수 있다. 이로 인해 쿠버네티스 코어 개발 팀의 명시적이고 맞춤형 지원이 필요하지 않은 지원 기술이 확산되었다.
• Innovation(혁신): 표준 인터페이스를 통해 컨테이너, 스토리지 및 네트워킹 분야의 새롭고 새로운 기술을 훨씬 더 빠르게 쿠버네티스에 통합할 수 있다. 이는 이러한 기술의 빠른 진화와 채택을 지원한다.

 

 

 

Simplifying Cluster Operations and Management(클러스터 운영 및 관리 단순화)

• Interoperability(상호 운용성): 표준 인터페이스는 서로 다른 공급업체가 개발한 구성 요소가 원활하게 함께 작동할 수 있도록 보장한다. 운영자는 성능, 비용 또는 기능 요구 사항에 따라 서로 다른 공급업체의 기술을 혼합하고 일치시킬 수 있다.
• Ease of Management(관리 용이성): 런타임 및 스토리지 시스템과 같은 구성 요소를 통합하는 표준화된 방식을 사용하면 운영 모델이 기본 기술에 관계없이 일관성 있게 유지되므로 클러스터 관리가 단순해진다.

 

 

 

 

Promoting a Robust Ecosystem(견고한 생태계 조성)

• Community Growth(커뮤니티 성장): 쿠버네티스는 새로운 공급업체와 솔루션의 진입 장벽을 낮춤으로써 풍부한 생태계를 조성한다. 강력한 생태계는 경쟁과 혁신을 촉진하고, 이는 다시 더 나은 제품과 서비스의 개발을 촉진한다.
• Collaboration(협업): 표준 인터페이스는 단일 공급업체 우선 순위가 아닌 공동의 노력에 의해 개선 및 기능이 주도되는 커뮤니티 협업의 기반을 만든다.

 

 

 

 

Ensuring Future-Proofing and Scalability(미래 보장 및 확장성 보장)

• Adaptability(적응성): 클라우드 네이티브 기술이 발전함에 따라 쿠버네티스는 최신 발전을 지원함으로써 관련성을 유지해야 한다. 표준 인터페이스는 전체 시스템을 정비하지 않고도 미래 기술을 쉽게 통합할 수 있도록 해준다.
• Scalability(확장성): 표준화된 프로토콜과 API는 Kubernetes가 수많은 노드와 다양한 환경에서 확장할 때 성능과 기능의 일관성을 보장한다.

 

 

 

 

---

 

 

 

 

 

Container xxx Interface (컨테이너 xxx 인터페이스)

CNI(컨테이너 네트워크 인터페이스)로 알려진 또 다른 중요한 인터페이스를 포함하여 이들 각각을 분석해 보겠다.

 

 

 

CRI(컨테이너 런타임 인터페이스)

• 목적: CRI는 Kubernetes와 통합하기 위한 컨테이너 런타임용 표준 API를 정의한다. 이를 통해 Kubernetes는 Docker, Containerd 및 CRI-O를 포함하여 재컴파일할 필요 없이 다양한 컨테이너 런타임을 사용할 수 있다.
• 기능: 인터페이스는 컨테이너 시작, 중지, 일시 중지와 같은 컨테이너의 수명 주기 작업을 지원한다. 또한 이미지 관리(이미지 가져오기, 푸시, 나열) 및 런타임 구성을 처리한다.

 

 

CSI(컨테이너 스토리지 인터페이스)

• 목적: CSI를 사용하면 스토리지 공급업체가 Kubernetes 핵심 코드를 수정하지 않고도 맞춤형 스토리지 플러그인을 생성할 수 있다. 이를 통해 Kubernetes에서 새로운 스토리지 시스템에 대한 지원을 더 쉽게 추가할 수 있다.
• 기능: CSI는 노드에서 볼륨 생성, 삭제, 마운트, 마운트 해제, 연결 또는 분리와 같은 볼륨 수명주기 관리를 위한 표준 API를 정의한다. 또한 스냅샷 관리를 지원하여 스냅샷 생성, 삭제, 복원이 가능하다.

 

 

CNI(컨테이너 네트워크 인터페이스)

• 목적: CNI는 Linux 컨테이너용 네트워크 인터페이스 구성을 위한 표준을 지정한다. Kubernetes에서 파드 네트워킹 및 네트워크 분리를 관리하는 데 사용된다.
• 기능: CNI 플러그인은 컨테이너의 네트워크 연결을 처리하고 각 컨테이너에 고유한 IP 주소가 있는지 확인한다. 플러그인은 방화벽이나 라우팅 규칙과 같은 추가 네트워킹 리소스를 관리할 수도 있다.

 

CDI(컨테이너 장치 인터페이스)

• 목적 : CDI는 GPU, TPU, FPGA와 같은 컨테이너 내의 다양한 하드웨어 장치를 사용할 수 있도록 하는 것을 목표로 하는 새로운 표준이다. 이는 특정 하드웨어 가속이 필요한 워크로드에 필수적이다.
• 기능 : CDI는 하드웨어 장치를 컨테이너에 연결하고, 장치 권한을 관리하고, 이러한 장치가 다중 테넌트 환경 내에서 적절하게 격리되고 보안되는지 확인하는 방법을 정의한다.

 

 

오픈 컨테이너 이니셔티브(OCI)

• 목적 : OCI는 컨테이너 런타임 및 이미지 형식에 대한 표준을 지정한다. 인터페이스 자체는 아니지만 다양한 컨테이너 기술에서 상호 운용성과 표준화를 보장하는 데 중요한 역할을 한다.
• 기능 : OCI 표준은 다양한 컨테이너 런타임과 이미지 형식 간의 호환성을 보장하여, 하나의 환경에서 구축된 컨테이너가 수정 없이 다른 환경에서 실행될 수 있도록 보장한다.

 

 

 

 

---

 

 

 

인터페이스 간 상호작용 흐름 예시

Kubernetes에서 하나의 Pod가 실행될 때 내부적으로 다양한 인터페이스가 유기적으로 작동한다. 이를 간략한 시나리오로 설명하면 다음과 같다.

 

1. Pod 생성 요청 (API Server → Scheduler)
   사용자가 Deployment 등을 통해 Pod 생성을 요청하면, Kubernetes는 해당 요청을 수신하고, 적절한 노드를 선택하여 Pod를 스케줄링한다.
2. Container Runtime Interface (CRI)
   Scheduler가 선택한 노드에서는 kubelet이 작동하여 CRI를 통해 컨테이너 런타임(Containerd 등)에게 컨테이너 생성을 지시한다.
   여기서 컨테이너 이미지가 필요한 경우 이미지 풀링도 이루어진다.
3. Container Network Interface (CNI)
   컨테이너가 실행되기 전, kubelet은 CNI를 호출하여 해당 Pod에 네트워크 인터페이스(IP)와 네트워크 경로를 할당한다.
   예를 들어, Calico, Flannel, Cilium 등의 CNI 플러그인이 이 작업을 수행한다.
4. Container Storage Interface (CSI)
   Pod에 Persistent Volume이 연결되어야 한다면, kubelet은 CSI를 통해 적절한 스토리지 드라이버를 호출하여 Volume을 노드에 마운트한다.
   이 작업은 Pod 실행 전, 또는 필요 시점에 동적으로 수행된다.
5. Container Device Interface (CDI)
   GPU와 같은 특수 하드웨어가 필요하다면, CDI를 통해 해당 디바이스가 컨테이너에 연결된다.

 

 

 

인터페이스별 주요 구현체 및 사용 사례

 

각 인터페이스는 여러 벤더 및 오픈소스 프로젝트에서 다양한 구현체로 제공되며, 클러스터 목적과 환경에 따라 선택이 달라진다.

인터페이스	대표 구현체	사용 환경 예시
CRI (Container Runtime Interface)	containerd, CRI-O	Docker는 더 이상 기본 CRI가 아니며, 대부분의 배포판은 containerd를 기본으로 사용한다. OpenShift는 CRI-O를 사용.
CSI (Container Storage Interface)	Rook-Ceph, Longhorn, AWS EBS CSI, GCP PD CSI	Rook은 자체 Ceph 클러스터를 통해 스토리지 제공. 퍼블릭 클라우드에서는 클라우드 네이티브 CSI 드라이버가 주로 사용된다.
CNI (Container Network Interface)	Calico, Cilium, Flannel, Weave Net	Calico는 네트워크 정책 및 보안에 강점을 가지며, Cilium은 eBPF 기반의 고성능 처리로 최근 각광받고 있다.
CDI (Container Device Interface)	NVIDIA Container Toolkit (CDI 기반), Intel Device Plugin	AI/ML 워크로드에서 GPU를 사용하는 경우 NVIDIA CDI를 활용. 쿠버네티스 1.26+ 버전에서 CDI 사용 활성화 가능.

 

 

 

 

실무 적용 팁

• 범용성 필요 시: `containerd + Calico + Longhorn` 조합은 가장 일반적이며, on-prem/클라우드 모두 적합.
• 보안 중심 환경: Cilium은 Zero Trust 기반 네트워크 구성에 적합하며, eBPF로 높은 성능과 보안 정책을 제공한다.
• 고성능 데이터 처리: Ceph(Rook) 또는 OpenEBS는 Stateful 워크로드에 강하다.
• AI/ML 클러스터: NVIDIA CDI를 통해 쿠버네티스에 GPU 자원을 안전하게 할당하고, Pod 수준 격리를 구현할 수 있다.

 

 

 

 

 

 

---

 

 

 

 

마무리

Kubernetes의 성공은 단지 컨테이너를 잘 관리하는 오케스트레이터로서의 기능 때문만은 아니다.
그 핵심에는 런타임(CRI), 스토리지(CSI), 네트워크(CNI), 장치(CDI) 등 다양한 하위 시스템과의 표준화된 인터페이스 설계 철학이 있다.

 

이러한 인터페이스의 도입은 쿠버네티스를 특정 기술에 종속되지 않도록 하여 벤더 중립성과 유연한 기술 채택을 가능하게 했고,
동시에 새로운 기술의 생태계 진입 장벽을 낮추어 빠른 혁신과 협업을 촉진했다.

 

이제 쿠버네티스를 운영하거나 설계하는 입장에서 단순히 Pod와 Service만 이해하는 것에서 나아가,
표준 인터페이스가 어떻게 확장성, 보안성, 이식성을 보장하는지를 이해하는 것은 매우 중요하다.

 

앞으로도 클라우드 네이티브 기술은 계속해서 발전할 것이며, Kubernetes는 이러한 변화에 가장 유연하게 대응할 수 있는 플랫폼으로 자리매김할 것이다.

 

그 중심에 있는 것이 바로 오늘 살펴본 Container Interfaces라는 점을 기억하자

 

 

 

 

 

 

 

---

Reference

https://kubernetes.io/docs/concepts/architecture/cri/

https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/

https://www.cni.dev/

https://community.veeam.com/blogs-and-podcasts-57/about-container-runtimes-in-2-minutes-5791