인사이트

인사이트리포트

디지털프렌스포메이션 최신 정보 및 트렌드를 제공합니다.

IT 트렌드

OCI와 CRI 중심으로 재편되는 컨테이너 생태계: 흔들리는 도커(Docker)의 위상

2020.07.24김준석
다운로드

컨테이너 표준 정립

IT 업계 종사자라면 컨테이너(Container)에 대해 한 번쯤은 들어본 적이 있을 것이다. 애플리케이션과 바이너리, 라이브러리 등을 패키지로 묶어 배포하는 컨테이너는 서로 다른 컴퓨팅 환경에서 애플리케이션을 안정적으로 실행할 수 있으며 개발 환경에 구애 받지 않고 빠른 개발과 배포가 가능하다는 장점이 있다. 대표적인 IT 기업 중 하나인 구글은 지메일에서 유튜브, 검색에 이르기까지 모든 제품을 컨테이너에서 실행하고 있다. 이처럼 컨테이너 기술은 IT 개발과 운영에 있어 빼놓을 수 없는 필수 요소로 자리 잡았다.

컨테이너에 대한 관심이 급격히 증가하면서 대부분의 주요 IT 벤더와 클라우드 공급자들은 컨테이너 기반의 솔루션을 발표했고 관련 스타트업 또한 급증해 컨테이너 생태계를 넓혀왔다. 하지만 포맷과 런타임에 대한 특정한 규격이 없다 보니 컨테이너의 미래는 불안했던 것이 사실이다. 일례로 2013년 출시된 도커(Docker)가 사실상의 컨테이너 표준 역할을 했지만 코어OS(CoreOS)는 도커와는 다른 규격으로 표준화를 추진하려 했다. 이러한 문제를 해결하기 위해 2015년 6월 도커, 코어OS, AWS, 구글, 마이크로소프트, IBM 등 주요 플랫폼 벤더들은 애플리케이션 이식성(Portability)의 관점에서 컨테이너 포맷과 런타임에 대한 개방형 업계 표준을 만들기 위해 OCI(Open Container Initiative)를 구성하였다. 이후 컨테이너 시장은 OCI의 런타임 명세와 이미지 명세를 준수하는 방향으로 성장하였고 그 과정에서 2016년 12월 쿠버네티스(Kubernetes)의 컨테이너 런타임을 만들기 위한 CRI(Container Runtime Interface)가 등장했다.

 

 

컨테이너 런타임

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

그림1. 컨테이너 실행단계. 1이미지다운로드, 2 이미지를 번들로 압축해제, 3 번들에서 컨테이너 실행

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

 

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

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

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

OCI를 준수하는 저수준 컨테이너 런타임으로 가장 잘 알려진 것은 runC이다. runC는 원래 도커에서 컨테이너를 실행하기 위해 개발되었으나 OCI 런타임 표준을 위해 독립적인 라이브러리로 사용되었다.

저수준 컨테이너 런타임은 컨테이너를 실제 실행하는 역할을 하지만 이미지로부터 컨테이너를 실행하려면 이미지와 관련된 API 같은 기능이 필요하다. 이러한 기능은 고수준 컨테이너 런타임이 제공한다.

 

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

일반적으로 고수준 컨테이너 런타임은 원격 애플리케이션이 컨테이너를 논리적으로 실행하고 모니터링 하는데 사용할 수 있는 데몬 및 API를 제공한다. 또한 컨테이너를 실행하기 위해 저수준 런타임 위에 배치된다.

이처럼 컨테이너를 실행하려면 저수준 및 고수준 컨테이너 런타임이 필요하기 때문에 OCI 런타임과 함께 도커가 그 역할을 했다. 도커는 docker-containerd라는 가장 잘 알려진 고수준 컨테이너 런타임을 제공한다. containerd도 runC와 마찬가지로 도커에서 컨테이너를 실행하기 위해 개발되었으나 나중에 독립적인 라이브러리로 추출되었다.

그림3. 고수준. 저수준 컨테이너 런타임 관계와 아키텍처_수준 컨테이너 런타임은 원격 애플리케이션이 컨테이너를 논리적으로 실행하고 모니터링 하는데 사용할 수 있는 데몬 및 API를 제공한다. 또한 컨테이너를 실행하기 위해 저수준 런타임 위에 배치 CLI etc에서 API로 Registry에서 Pull로 High-Level Runtime으로 전송하며, 도커 아키텍쳐에서는 Registry 단계에서 docker-containerd로 Pull 한다.

 

CRI (Container Runtime Interface)

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

그림4. Kubelet 동작 흐름과 CRI_ Kubelet > CRI(Container Runtime interface)에서 각각 (OCI-Runtime, runC), Dockerd, etc로 전송

 

 

컨테이너의 새로운 생태계

CRI가 만들어진 후 주요 플랫폼 벤더들은 본격적으로 컨테이너 런타임 구축을 위해 노력하였다. 그 중 레드햇, 인텔, SUSE, Hyper, IBM 등의 관리자와 컨트리뷰터들이 커뮤니티 중심의 오픈소스 프로젝트인 CRI-O를 개발하였다.

 

CRI-O (Container Runtime Interface – Open Container Initiative)

CRI-O는 CRI와 OCI에서 유래된 프로젝트로 컨테이너 런타임 및 이미지가 OCI와 호환되는 것에 중점을 두고 있다. CRI 표준 컴포넌트를 최소한의 런타임으로 구현하며 쿠버네티스에서 모든 OCI 호환 런타임 및 컨테이너 이미지를 지원한다.

그림5. 쿠버네티스와 도커 및 CRI-O_ kubernetes Worker node_ Kubelet, dockershim, docker, docker-containerd, docker-runC, pod. Kubelet, CRI-O, OCI runtime(s), pod

CRI-O는 컨테이너의 실행을 목적으로 경량화했기 때문에 도커가 제공하는 컨테이너 생성 및 이미지 빌드와 같은 기능은 제공하지 않는다. 즉, CRI-O 덕분에 쿠버네티스는 컨테이너를 실행할 때 도커가 필요 없었으나 컨테이너의 생성 및 이미지 빌드와 같은 과정에서는 여전히 도커를 필요로 했다. 이러한 이유로 CRI-O 개발팀은 도커를 대체할 수 있는 새로운 생태계를 만들기 위해 노력하였다.

 

도커의 문제점

도커가 컨테이너의 생성 및 이미지 빌드를 모두 처리하는데 새로운 툴이 왜 필요할까? 물론 기존 방식대로 도커를 사용할 수 있다. 그럼에도 CRI-O 개발팀이 도커의 역할을 대신할 수 있는 생태계를 위한 툴(Buildah빌다, Podman포드맨, Skopeo스코피오)을 개발한 이유는 다음과 같은 문제점이 제기되었기 때문이다.

도커는 클라이언트·서버 애플리케이션으로 클라이언트인 Docker CLI와 서버인 Docker daemon으로 구성된다. 그 중 서버는 컨테이너 이미지 빌드, 관리, 공유, 실행 및 컨테이너 인스턴스 관리와 같이 너무 많은 기능을 담당하는 데몬으로 모든 컨테이너를 자식 프로세스로 소유한다. 이로 인해 무거울 뿐 아니라 장애가 발생하면 모든 자식 프로세스에 영향을 끼쳐 단일 실패점(Single point of failure)이 될 위험이 있다. 또한 클라이언트-서버 모델을 사용할 경우 리눅스의 audit.log를 통해 관리자가 시스템의 보안 이벤트를 감시하고 기록된 정보를 볼 수 있는 audit 보안 기능을 사용할 수 없게 된다.

그림6. fork.exe 모델 및 클라이언트-서버 모델에서의 UID, auid 설정 동작 방식_fork/exec 모델 - 도커는 클라이언트·서버 애플리케이션으로 클라이언트인 Docker CLI와 서버인 Docker daemon으로 구성된다. 그 중 서버는 컨테이너 이미지 빌드, 관리, 공유, 실행 및 컨테이너 인스턴스 관리와 같이 너무 많은 기능을 담당하는 데몬으로 모든 컨테이너를 자식 프로세스로 소유한다. 이로 인해 무거울 뿐 아니라 장애가 발생하면 모든 자식 프로세스에 영향을 끼쳐 단일 실패점(Single point of failure)이 될 위험이 있다. 클라이언트/서버 모델 - 리눅스의 audit.log를 통해 관리자가 시스템의 보안 이벤트를 감시하고 기록된 정보를 볼 수 있는 audit 보안 기능을 사용할 수 없게됨.

추가로 모든 도커 명령은 루트 권한을 가진 사용자에 의해서만 실행할 수 있어 보안 문제가 발생할 수 있다. 이는 아래에 소개하는 Buildah, Podman, Skopeo를 사용하면 해결할 수 있다.

 

CRI-O와 함께 사용 가능한 툴: Buildah, Podman, Skopeo

Buildah, Podman, Skopeo는 별도의 데몬 없이 전통적인 fork·exec 모델을 사용하며 사용자 네임 스페이스를 이용해 컨테이너를 실행함으로써 단일 실패점, audit 보안 기능 사용 및 루트 권한 문제를 해결하였다. 도커의 서버가 너무 많은 기능을 가지고 있는 단점은 각 툴 별로 다음과 같이 기능을 나누어 제공하는 방식으로 보완하였다.

그림7. 도커의 동작 흐름 및 Podman, Buidah, Skopeo의 역할_Docker CLI에서 Docker Deamon으로 전송, Image Registry, Images, Containers, Kernel로 이동. Podman에서 skopeo로 Image Registry, buildah로 Images, Containers, Kernel로 이동 Images

Buildah는 CRI-O에서 이미지를 빌드할 때 도커의 종속성을 제거하기 위해 개발되었고 Dockerfile 없이 다른 스크립트 언어를 사용해 컨테이너 이미지를 빌드하는 것을 목표로 한다.

Podman은 pull 및 tag 지정과 같은 OCI 컨테이너 이미지를 유지관리하고 수정하는데 도움이 되는 모든 명령 및 기능을 제공한다. 또한 컨테이너 작성, 실행 및 유지보수도 할 수 있다. 즉, Docker CLI에서 수행할 수 있는 명령은 Podman CLI에서도 동일하게 수행 할 수 있다.

Buildah와 Podman는 일부 겹치는 기능이 있는데 Buildah는 OCI 이미지를 생성하는 효율적인 도구로, Podman은 그러한 이미지와 이미지를 통해 생성한 컨테이너를 유지하고 관리하는 도구로 이해하면 된다. 기술적으로 buildah run은 Dockerfile RUN을 에뮬레이트하며 podman run은 docker run을 에뮬레이트 한다.

Skopeo는 이미지 저장소에서 다양한 작업을 수행하는 명령줄 도구이다. 기존 도커가 다른 레지스트리에 이미지를 복사하기 위해 pull, tag, push를 사용했다면 Skopeo는 간단하게 copy 명령으로 해당 기능을 제공한다. 추가로 저장소에 있는 이미지 이름에 대해 로우 레벨 정보를 제공해준다.

 

 

컨테이너의 미래

지금까지 도커, OCI, CRI, Buildah, Podman 등 컨테이너 기술의 전반적인 흐름과 생태계에 대해 알아보았다.

컨테이너는 온프레미스 환경에서 클라우드 네이티브 환경으로 옮기는 것을 쉽게 해주기 때문에 클라우드 컴퓨팅 분야에서 가장 주목 받는 기술 중 하나로 성장하고 있다. 그리고 그 중심에는 단연 도커가 자리잡고 있다. 하지만 컨테이너의 표준화가 이뤄진 후 컨테이너 시장은 OCI와 CRI를 중심으로 성장하고 있다. 그 과정에서 사실상 컨테이너 표준으로 사용되던 도커의 역할을 대신하는 다양한 기술이 나오고 있으며 그 중 Buildah, Podman, Skopeo는 도커의 기능을 역할별로 나눠 구현하고 있다. 이들은 또한 도커의 보안 관련 단점을 보완하며 기존에는 없던 편리한 기능도 추가로 제공한다.

컨테이너 생태계는 계속해서 성장하고 있으며 도커 외에도 사용할 수 있는 다양한 대체기술이 선보이고 있다. 향후 컨테이너는 OCI의 설립 목적인 ‘통일된 표준을 통해 어디서든 작동하는 이식성 제공’을 실현하기 위해 OCI와 CRI 표준을 중심으로 생태계를 넓혀갈 것이다.

# References

- https://www.ianlewis.org/en/container-runtimes-part-1-introduction-container-r
- https://www.opencontainers.org/
- https://www.cncf.io/
- https://podman.io/blogs/2018/10/31/podman-buildah-relationship.html
- https://opensource.com/article/18/10/podman-more-secure-way-run-containers
- https://www.redhat.com/en/blog/why-red-hat-investing-cri-o-and-podman
- http://events19.linuxfoundation.org/wp-content/uploads/2017/11/How-Container-Runtime-Matters-in-Kubernetes_-OSS-Kunal-Kushwaha.pdf
- https://darumatic.com/blog/podman_introduction

김준석 프로

에스코어㈜ 소프트웨어사업부 오픈소스SW그룹

빅데이터 및 오픈소스SW 관련 연구 개발 프로젝트를 수행하였으며 현재 OSS 기술서비스와 아키텍처를 담당하고 있습니다.

연관 아티클

  • RBAC을 활용한 클라우드 접근제어 강화
    비즈니스 전략2023.12.19

    RBAC을 활용한 클라우드 접근제어 강화

    자세히 보기
  • 쏟아지는 신기술, “Know yourself.”
    데이터 관리2023.11.27

    쏟아지는 신기술, “Know yourself.”

    자세히 보기
  • EPC 현장 서지 정보화 추진 방안
    IT 트렌드2023.11.16

    EPC 현장 서지 정보화 추진 방안

    자세히 보기