정리 사유
컨테이너 생태계에서 Docker runtime이 왜 하나로 통합되지 않고, 이미지별로 다른 runtime이 필요한지에 대해 의문이 들었습니다. 이를 이해하기 위해 OCI와 CRI의 개념을 중심으로 컨테이너 런타임의 역할과 구조를 정리해 보았습니다.
주로 흔들리는 도커(Docker)의 위상 - OCI와 CRI 중심으로 재편되는 컨테이너 생태계 를 중심으로 정리했습니다. OCI와 CRI의 개념을 중심으로 해당 내용을 풀어가려고 합니다.
세줄 요약
- OCI는 컨테이너 런타임 표준화의 출발점입니다. OCI 가 모든 통일을 하진 않았기에 다양한 컨테이너 런타임이 생성됐습니다. CRI는 쿠버네티스가 다양한 런타임과 통신하도록 설계된 인터페이스입니다.
핵심 키워드
- 컨테이너 레벨 분리
- OCI (=Open Container Initiative)
- docker 등의 포맷과 런타임에 대한 약속입니다.
- runC : 도커에서 컨테이너 실행용 라이브러리로 시작. low level 이라 high 레벨 에서 이미지 관련 API 와 같이 이용됩니다.
- CRI (=Container Runtime interface)
- 쿠버네티스의 컨테이너 런타임을 만든다. 컨테이너 런타임의 추상화 계층입니다.
- CRI-O
OCI
컨테이너 표준화를 위한 OCI의 등장
도커가 사실상 컨테이너 표준 역할을 해왔지만, 다른 회사들은 자체 규격을 통해 표준화를 시도할 여지가 있었습니다. 이를 해결하기 위해 2015년 6월, 도커를 비롯한 주요 플랫폼 벤더들(AWS, 구글, 마이크로소프트 등)은 컨테이너 포맷과 런타임에 대한 개방형 업계 표준을 정의하고자 OCI(Open Container Initiative)를 구성하였습니다.
컨테이너 실행 과정
컨테이너 실행 과정은 크게 세 단계로 이루어집니다:
- 이미지 다운로드
- 이미지를 번들로 압축 해제
- 번들에서 컨테이너 실행
이 중 OCI는 컨테이너 실행(3번) 단계에 초점을 맞추어 표준화했으며, 나머지 두 단계는 고수준 런타임이 담당합니다.
고수준과 저수준 컨테이너 런타임의 역할
정리하자면,
- 고수준 컨테이너 런타임: 컨테이너 이미지의 다운로드, 관리, 압축 해제 등을 수행합니다. (containerd, CRI-O 등)
- 저수준 컨테이너 런타임: 컨테이너 실행을 담당하며, namespace와 cgroup을 설정해 프로세스를 격리 및 제어합니다. (runc)
저수준 컨테이너 런타임
통일된 저수준 컨테이너 런타임에 대해 알아보겠습니다.
저수준 런타임은 컨테이너의 핵심인 namespace와 cgroup을 활용합니다.
- namespace: 가상화된 자원 격리를 제공하여, 각 컨테이너가 독립된 파일 시스템, 네트워크 등을 가지도록 합니다. 예를 들어, 하나의 컨테이너가 'eth0'이라는 네트워크 인터페이스를 사용할 때 다른 컨테이너는 동일한 네트워크 인터페이스를 보지 못하도록 격리합니다.
- cgroup: CPU, 메모리 등 자원을 제한하거나 할당하여 각 컨테이너가 시스템 자원을 효율적으로 사용하도록 합니다. 예를 들어,하나의 컨테이너가 과도한 메모리를 사용할 경우 cgroup을 통해 이를 제한하여 다른 컨테이너와 시스템 전체의 안정성을 유지합니다.
OCI의 런타임 사양(runtime-spec)을 구현한 대표적인 도구는 runC로, 대부분의 컨테이너 플랫폼에서 사용됩니다.
OCI 의 한계
모든 컨테이너 표준화를 한것은 아니기때문에 다양한 컨테이너 런타임이 생성됐습니다.
CRI
= 쿠버네티스의 컨테이너 런타임 인터페이스
- 2016년 12월, 쿠버네티스(Kubernetes)는 다양한 컨테이너 런타임과의 호환성을 높이고 특정 런타임에 종속되는 문제를 해결하기 위해 CRI(Container Runtime Interface)를 도입했습니다. 이는 쿠버네티스가 컨테이너 런타임과 상호작용하는 방식을 표준화한 인터페이스로, 유연성과 확장성을 제공합니다.
CRI의 핵심 개념
CRI는 쿠버네티스가 컨테이너 런타임과 상호작용할 때 사용하는 추상화 계층입니다. 이를 통해:
- 컨테이너 런타임에 대한 의존성을 제거하고,
- 개발자가 필요에 따라 새로운 런타임을 추가하거나 직접 구축할 수 있도록 합니다.
이러한 표준화를 통해 쿠버네티스는 특정 런타임(Docker 등)에 국한되지 않고 다양한 런타임(containerd, CRI-O 등)과 호환성을 유지할 수 있습니다.
대표적인 CRI 기반 컨테이너 런타임
1. containerd
Docker에서 분리된 경량화된 컨테이너 런타임으로, 현재 쿠버네티스의 기본 런타임으로 널리 사용됩니다.
컨테이너 실행, 네트워크 설정, 볼륨 관리 등 고수준 런타임 기능을 지원합니다.
2. CRI-O
CRI-O(Container Runtime Interface OpenContainer Initiative)는 CRI의 구현을 위해 개발된 경량화된 런타임입니다. Docker 없이도 컨테이너 실행을 지원하며, 주로 레드햇, SUSE, IBM 등 다양한 벤더가 오픈소스로 개발에 참여했습니다.
정리하자면, CRI-O는 CRI와 OCI의 연결 고리 역할을 하며, Docker 의존성을 제거하고 가볍고 효율적인 런타임 환경을 제공합니다. 주로 레드햇, SUSE, IBM 등의 기업이 지원하며, 최소한의 기능으로 구성되어 높은 확장성을 제공합니다.
주요 특징:
- 고수준 런타임 생략: 최소한의 기능만 구현하여 CRI와 OCI를 연결합니다.
- 도커 의존성 제거: 컨테이너 실행에는 도커가 필요 없지만, 컨테이너 이미지를 생성하거나 빌드할 때는 도커와 같은 추가 도구를 사용할 수 있습니다.
- 효율적인 리소스 사용과 가벼운 실행 환경을 제공합니다.
결론
결론적으로는 OCI는 컨테이너 런타임 표준화의 출발점이었고, OCI 가 모든 통일을 하진 않았기에 다양한 컨테이너 런타임이 생성됐습니다. CRI는 쿠버네티스가 다양한 런타임과 통신하도록 설계된 인터페이스입니다. CRI에 대한 설명을 통해 상위레벨에서 다양한 컨테이너 런타임을 쿠버네티스에서 이용하고 있다라 설명하고자 했습니다.
참고문헌
