[Docker] OCI(Open Container Initiative) & CRI(Container Runtime Interface)

초창기 Docker Model

초기 Docker 구조

초창기 Docker는 LXC에 의존하여 Container를 관리하였으며 monolithic 한 구조로 Docker Daemon 하나에서 Docker client, Docker API, Container Runtime, image build 등 여러 기능들을 관리하였다.

 

---

 

LXC (Linux Container)

 

LXC는 단일 컨트롤 호스트 상에서 여러 개의 고립된 리눅스 시스템들을 실행하기 위한 운영 시스템 가상화 방법이다.

 

cgroup, namespaces 기술을 사용하여 Container들이 독립된 환경에서 실행되도록 하는 기술이며 현재의 Docker Container의 부모(?)라고 볼 수 있다.

 

---

 

Docker Container Runtime (libcontainer)

 

LXC가 이름에서도 알 수 있듯이 Linux 호스트에서만 동작하였고 여러 플랫폼을 지원하기가 힘든 구조였다.

 

또한 Docker의 Monolithic 구조가 발목을 잡기 시작하였다. 하나의 데몬에 여러 기능이 집중되어있다 보니 무겁기도 하고 Daemon에서 문제발생 시 모든 기능에 문제가 발생하였기 때문이다. (특히 Container Runtime의 장애는 치명적이었다.)

 

따라서 Docker는 Monolithic한 구조를 하나씩 분리하기 시작하였고, 그 과정에서 LXC를 대체할 libcontainer(https://github.com/opencontainers/runc/tree/main/libcontainer) 를 개발하였다.

GitHub - opencontainers/runc: CLI tool for spawning and running containers according to the OCI specification

 

libcontainer를 사용한 CLI wrapper의 구현체가 runc이고 현재 Kubernetes에서도 사용 중인 container runtime CLI 툴이다.

 

---

OCI (Open Container Initiative)

 

2013년 Docker가 세상에 등장한 이후 IT에서는 컨테이너 환경으로의 전환이 가속화되었다.

 

이후 Docker가 Monolithic 한 구조를 분리하면서 Container Runtime도 분리하게 되는데 Docker를 포함한 여러 개의 집단에서 Container Runtime을 한참 개발하고 있는 시기였다.

 

Container Runtime에 대한 표준이 없었기 때문에 당연하게도 각각의 Container Runtime들끼리의 이식성 및 호환성에 대한 문제가 대두되기 시작하였다.

 

이 문제를 해결하기 위해서 Docker, AWS, CoreOS, Google, MS, IBM 등의 선발주자들이 모여서 Container Runtime에 대한 표준화를 진행하였고 그 결과가 바로 OCI(Open Container Initiative)이다.

(https://github.com/opencontainers/runtime-spec)

GitHub - opencontainers/runtime-spec: OCI Runtime Specification

 

이후 OCI 스펙에 맞춰서 각 기업들이 Container Runtime을 발전시켰고, Docker의 경우 OCI 표준에 맞춰 탄생한 Container Runtime이 runc이다. (Docker Container Runtime CLI Tool)

 

---

CRI (Container Runtime Interface)

 

OCI 표준이 탄생하고 여러 기업에서 Container Runtime들이 탄생하고 있던 시기에 Container의 선두주자였던 Kubernetes는 Docker뿐만 아니라 여러 Container Runtime을 지원하였다.

 

Kubernetes에서는 kubelet이라는 Agent로 Container Runtime을 관리하였는데 다양한 Container Runtime들이 생겨나면서 kubelet의 유지보수에 대한 어려움이 발생하기 시작하였다.

 

따라서 kubelet의 유지보수 문제를 해결하면서 여러 Container Runtime들을 지원하기 위해 kubelet에서 Container Runtime을 관리할 수 있는 인터페이스를 개발하였는데 이것이 바로 CRI(Container Runtime Interface)이다.

 

정리하자면 OCI는 Container Runtime 개발 시 약속한 표준 스펙이고 CRI는 Kubernetes에서 Container Runtime 종류에 상관없이 Container Runtime을 관리할 수 있는 표준 인터페이스이다.