Container Runtime Interface(CRI)

자료 조사 중 container의 OCI와 CRI에 대한 언급이 발견됨. 그 과정에서 OCI의 정확한 정의와 목적에 대해 알아보고, OCI compatible여부의 의미를 정리함. 이후, CRI의 정의와 컨테이너 런타임에 대한 추가적인 정보 정리의 필요성이 나타남. 이에 아래 보고서에 컨테이너 런타임과 CRI에 대한 자료 조사 결과를 정리함.

---

컨테이너 런타임

CRI의 등장 배경을 이해하려면 먼저 컨테이너 런타임에 대해 살펴봐야 한다. 컨테이너를 실행하기 위해서는 Figure 1과 같은 세 단계를 거친다.

Figure 1. 컨테이너 실행 단계

OCI가 만들어질 당시 비공식적 표준 역할을 하던 도커는 컨테이너 런타임의 표준화를 위해 필요한 모든 단계가 아닌 세 번째 단계인 컨테이너의 실행 부분만 표준화하였다. 이로 인해 컨테이너의 런타임은 실제 컨테이너를 실행하는 저수준 컨테이너 런타임인 OCI 런타임과 컨테이너 이미지의 전송 및 관리, 이미지 압축 풀기 등을 실행하는 고수준 컨테이너 런타임으로 나뉘게 되었다.

---

저수준 컨테이너 런타임(Low-Level Container Runtimes)

컨테이너는 Linux namespace와 cgroup을 사용하여 구현된다. Namespace는 각 컨테이너에 대해 파일 시스템이나 네트워킹과 같은 시스템 리소스를 가상화하고 cgroup은 각 컨테이너가 사용할 수 있는 CPU 및 메모리와 같은 리소스 양을 제한하는 역할을 한다. 저수준 컨테이너 런타임은 이러한 namespace와 cgroup을 설정한 다음 해당 namespace 및 cgroup 내에서 명령을 실행한다.

Figure 2. Docker 와 runC

그림 2는 Docker 컨테이너와 runc의 관계를 표현하고 있다. OCI를 준수하는 저수준 컨테이너 런타임으로 가장 잘 알려진 것은 runC이다. runC는 원래 도커에서 컨테이너를 실행하기 위해 개발되었으나, OCI 런타임 표준을 위해 독립적인 라이브러리로 사용되고 있다. 저수준 컨테이너 런타임은 컨테이너를 실제 실행하는 역할을 하지만 이미지로부터 컨테이너를 실행하려면 이미지와 관련된 API 같은 기능이 필요하며, 이러한 기능은 고수준 컨테이너 런타임에서 제공된다.

---

고수준 컨테이너 런타임(High-Level Container Runtimes)

일반적으로 고수준 컨테이너 런타임은 원격 애플리케이션이 컨테이너를 논리적으로 실행하고 모니터링 하는데 사용할 수 있는 데몬 및 API를 제공한다. 또한 컨테이너를 실행하기 위해 저수준 런타임 위에 배치된다. 이처럼 컨테이너를 실행하려면 그림 3과 같이 저수준 및 고수준 컨테이너 런타임이 필요하기 때문에 OCI 런타임과 함께 도커가 그 역할을 한다. 도커는 docker-containerd라는 가장 잘 알려진 고수준 컨테이너 런타임을 제공한다. continerd도 runC와 마찬가지로 도커에서 컨테이너를 실행하기 위해 개발되었으나 나중에 독립적인 라이브러리로 추출되었다.

Figure 3. 컨테이너 런타임 관계와 docker architecture

---

Container Runtime Interface (CRI)

CRI는 쿠버네티스에서 만든 컨테이너 런타임 인터페이스로, 개발자들의 컨테이너 런타임 구축에 대한 진입 장벽을 낮추어 준다. 초기 쿠버네티스는 컨테이너를 실행하기 위해 도커를 사용하였는데 이는 쿠버네티스 클러스터 워커 노드의 에이전트인 Kubelet 소스코드 내부에 통합되어 있다. 이처럼 통합된 프로세스는 Kubelet에 대한 깊은 이해를 필요로 하였고 쿠버네티스 커뮤니티에 상당한 유지보수 오버헤드를 발생시켰다. 이러한 문제를 해결하기 위해 쿠버네티스는 CRI를 만들어 명확하게 정의된 추상화 계층을 제공함으로써 개발자가 컨테이너 런타임 구축에 집중할 수 있게 하였다.

Figure 4. Kubelet workflow and CRI

 

Reference

[1]   https://www.samsungsds.com/kr/insights/docker.html