[비개발자의 눈] #3 - K8s study : 컨테이너 런타임 탐구 (runC, Containerd, cri-o)

컨테이너는 애플리케이션을 패키징하는 기술로, 이 컨테이너를 다루기 위해서는 컨테이너 런타임이라는 도구가 필요합니다. 컨테이너의 개념은 명확한데에 비해 컨테이너 런타임은 명확하게 그 정의를 설명하고 어떤 역할을 수행하는지 설명하기는 쉽지 않다고 합니다. 그래서 아래와 같이 직접 알아봤습니다! 컨테이너에 대한 자세한 내용은 ‘[비개발자의 눈] #1’을 참고해주세요

컨테이너 업계 표준 구성

OCI

2013년, Docker는 Linux 컨테이너 기술을 보다 쉽게 다룰 수 있는 기능을 아래와 같이 제공했습니다.

컨테이너 이미지 형식(union mount)
이미지 빌드 방법(Dockerfile, docker build)
이미지 공유(docker push, pull)
이미지 관리(docker image ls, docker image rm, etc)
컨테이너 인스턴스 관리(docker ps, docker rm, etc)
컨테이너 실행(docker run)

그런데 당시에는 컨테이너 런타임에 대한 표준 인터페이스가 존재하지 않아 런타임별 서로 다른 인터페이스를 갖는 경우가 빈번했습니다. 포맷 그리고 런타임에 대한 특정한 규격이 없다보니, 많은 혼란과 불편함이 발생했고 더불어 컨테이너의 미래가 불안해보였던 것도 사실입니다. 2015년 6월 IBM, Docker, 레드햇(구 CoreOS), Google, MS 등 주요 회사들은 애플리케이션의 이식성(Portability) 관점에서 컨테이너 런타임에 대한 업계 표준을 만들기 위해 OCI(Open Container Initiative)를 구성하였고 현재 런타임 사양(runtime-spec), 이미지 사양(image-spec) 및 배포 사양(distribution-spec)의 세 가지 사양이 포함되어 있습니다. OCI는 컨테이너 런타임에 대한 표준을 제시하였고, 대부분의 컨테이너 런타임은 이를 따르고 있습니다.

컨테이너 런타임

컨테이너 런타임은 실제로 컨테이너를 실행하는 저수준 컨테이너 런타임과 컨테이너의 이미지 전송과 관리, 이미지 압축 풀기 등을 실행하는 고수준 컨테이너 런타임으로 나뉩니다.

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

OCI Runtime이라고도 부르는 저수준 컨테이너 런타임은 namespace^[각주:1]와 cgroup^[각주:2]을 설정 및 구성하여 작업을 수행하며 오로지 컨테이너를 실행하는 기능만을 제공합니다. 따라서 대부분 고수준 컨테이너 런타임에 의해 호출되는 것이 일반적인 케이스입니다.

lmctfy, rkt 등 다양한 저수준 컨테이너 런타임이 존재했지만 현재까지 OCI 표준 규격을 지키며 살아남은 것은 runC로, 사실상 runC가 시장을 지배했다고 봐도 무방하다는 의견이 다수입니다.

runC

저수준 컨테이너 런타임으로 가장 잘 알려진 것은 runC입니다. runC는 도커에서 컨테이너를 실행하기 위해 개발되었지만, OCI 런타임 표준을 위해 독립적인 라이브러리로 사용되었습니다. 공식문서에서는 runC를 OCI 런타임 표준을 준수하는 컨테이너를 생성 및 실행하기 위한 CLI 툴이라고 정의했습니다.

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

저수준 컨테이너 런타임이 컨테이너를 실제로 실행하는 역할을 하지만 최초 이미지로부터 컨테이너를 실행하려면 이미지와 관련된 API와 같은 기능이 필요합니다. 이러한 기능을 제공하는 것이 바로 고수준 컨테이너 런타임이고, 이를 위해 저수준 런타임 위에 배치됩니다.

Containerd

Containerd는 Docker에서 만들고 CNCF에 기증한 Container Runtime입니다. RunC 기반이며 OCI 표준을 따르고 사실상 표준 컨테이너 런타임으로 봐도 무방하다는 입장이 많습니다.

고수준 컨테이너 런타임 중에서 Containerd가 가장 널리 사용되고 있고 Docker Engine에 기본적으로 탑재되어 있습니다. containerd도 runC와 마찬가지로 도커에서 컨테이너를 실행하기 위해 개발되었으나, 나중에 독립적인 라이브러리로 추출되었습니다.

CRI-O

Red Hat, Intel, SUSE, Hyper, IBM 쪽에서도 OCI 표준에 따라 Kubernetes 전용 Container Runtime을 만들었는데 이것이 CRI-O입니다. 공식 문서에서 CRI-O는 OCI(Open Container Initiative) 호환 런타임을 사용할 수 있도록 하는 Kubernetes CRI(Container Runtime Interface)의 구현이며 OCI 컨테이너 이미지를 지원하고 모든 컨테이너 레지스트리에서 가져올 수 있다고 설명합니다. 즉, Kubernetes의 CRI 표준 컴포넌트를 최소한의 런타임으로 구현하는 것으로 Kubernetes와의 통합을 염두하고 설계했습니다. CRI-O는 Kubernetes에서 주로 사용됐던 Docker를 대체하는 목적으로 만들어졌는데, 컨테이너의 실행 목적으로 경량화했기 때문에 컨테이너의 생성이나 이미지 빌드 같은 과정에서는 여전히 Docker가 필요합니다.

마치며

컨테이너는 클라우드 컴퓨팅 분야에서 특히 주목받는 기술 중 하나로 지속적인 성장을 하고 있음에 틀림없습니다. 그 중심에는 도커가 있지만 컨테이너의 표준화가 이루어진 이후 OCI와 CRI를 중심으로 성장하고 있음을 알 수 있었습니다. 이에 따라 사실상 컨테이너의 표준으로 사용됐던 도커를 대신할 수 있는 다양한 기술이 나오고 있고 도커의 보안과 관련한 단점을 보완하는 기능도 추가로 제공하고 있기도 합니다.