오픈 컨테이너 이니셔티브편집자 확인

런타임 스펙은 오픈 컨테이너 이니셔티브가 정의하는 핵심 표준 중 하나로, 컨테이너를 실행하는 데 필요한 런타임의 동작과 환경을 명시한다. 이 사양은 컨테이너의 생명주기, 즉 생성, 시작, 일시 정지, 삭제와 같은 과정을 어떻게 관리해야 하는지에 대한 기술적 요구사항을 제공한다. 또한 컨테이너가 실행될 때 격리되어야 하는 리소스와 리눅스 커널의 네임스페이스, cgroups와 같은 기본 기술을 어떻게 활용할지에 대한 가이드라인을 포함한다.

이 사양의 주요 목적은 서로 다른 컨테이너 런타임 간의 상호 운용성을 보장하는 것이다. 예를 들어, runc나 containerd와 같은 서로 다른 런타임 구현체가 모두 동일한 런타임 스펙을 준수한다면, 사용자는 특정 벤더에 종속되지 않고 자유롭게 런타임을 선택하고 교체할 수 있다. 이는 도커와 코어OS 등 초기 주도 기업들이 각자의 방식으로 발전시켜 온 컨테이너 기술을 하나의 공통된 표준 아래 통합하는 데 기여했다.

런타임 스펙은 JSON 형식의 구성 파일인 'config.json'을 통해 컨테이너의 실행 환경을 정의한다. 이 파일에는 컨테이너에서 실행될 실행 파일의 경로, 마운트될 파일 시스템, 설정할 환경 변수, 사용할 호스트의 디바이스 및 네트워크 설정 등이 포함된다. 이러한 표준화된 구성 방식을 통해 컨테이너 실행의 예측 가능성과 이식성이 크게 향상되었다.

결과적으로, 런타임 스펙은 클라우드 컴퓨팅과 컨테이너 오케스트레이션 플랫폼인 쿠버네티스의 기반이 되는 중요한 표준으로 자리 잡았다. 쿠버네티스는 OCI 호환 런타임을 통해 컨테이너를 실행하며, 이는 다양한 클라우드 서비스 제공자와 온프레미스 환경에서 일관된 방식으로 애플리케이션을 배포하고 관리할 수 있게 해준다.

오픈 컨테이너 이니셔티브의 이미지 스펙은 컨테이너 이미지의 형식, 레이아웃, 구성 요소를 정의하는 공식 표준이다. 이 스펙은 컨테이너 이미지가 특정 런타임이나 호스트 시스템에 종속되지 않고, OCI 호환 런타임이라면 어디서나 동일하게 실행될 수 있도록 보장하는 것을 목표로 한다. 이를 통해 도커와 같은 특정 벤더의 이미지 형식에 대한 의존성을 줄이고, 컨테이너 생태계 전반의 상호 운용성을 실현한다.

이미지 스펙에서 정의하는 핵심 구성 요소는 다음과 같다.

이 표준화된 형식은 레지스트리에서 이미지를 저장하고 배포하는 방식에도 영향을 미친다. OCI 이미지는 도커 허브나 쿠버네티스와 같은 다양한 컨테이너 오케스트레이션 플랫폼 및 도구에서 호환되어 사용될 수 있다. 결과적으로 개발자는 하나의 표준 형식으로 이미지를 빌드하면, 이를 runc, containerd, CRI-O 등 서로 다른 OCI 호환 런타임에서 모두 실행할 수 있게 된다. 이는 클라우드 환경 간 이식성을 높이고, 벤더 락인을 방지하는 데 기여한다.

배포 스펙은 컨테이너 이미지를 저장하고 배포하기 위한 프로토콜과 API를 정의한다. 이 스펙은 도커 레지스트리 프로토콜을 기반으로 하여 표준화했으며, 컨테이너 런타임이나 오케스트레이션 도구가 원격 레지스트리에서 이미지를 당겨오거나(pull) 밀어넣는(push) 상호작용 방식을 규정한다. 이를 통해 서로 다른 벤더의 도구들도 동일한 방식으로 이미지를 관리하고 교환할 수 있게 된다.

주요 내용으로는 이미지 매니페스트의 구조, 레이어 블롭의 식별 및 전송 방법, 그리고 레지스트리와의 HTTP 기반 통신 규약 등이 포함된다. 이 스펙은 이미지 스펙에서 정의된 실제 이미지 내용물을 어떤 경로를 통해 주고받을지에 대한 '운송 수단' 역할을 한다고 볼 수 있다.

배포 스펙의 표준화는 클라우드 네이티브 생태계에서 컨테이너 이미지의 유통을 단순화하고 안정화하는 데 기여했다. 쿠버네티스나 다양한 CI/CD 파이프라인은 이 표준화된 프로토콜을 통해 공개 또는 사설 레지스트리에서 이미지를 원활하게 가져와 사용한다. 결과적으로 개발자는 특정 회사의 도구나 서비스에 종속되지 않고 자유롭게 컨테이너 이미지를 빌드, 저장, 공유할 수 있는 기반이 마련되었다.

runc는 오픈 컨테이너 이니셔티브의 런타임 사양을 구현한 경량의 컨테이너 런타임이다. 이는 리눅스 시스템에서 컨테이너를 직접 생성하고 실행하는 데 필요한 모든 저수준 기능을 담당하는 CLI 도구로, 도커 엔진의 초기 컨테이너 런타임 컴포넌트로부터 분리되어 발전했다. runc는 OCI 런타임 사양의 레퍼런스 구현체 역할을 하며, 리눅스 커널의 cgroups와 네임스페이스 같은 기능을 직접 활용하여 컨테이너를 격리된 프로세스로 실행한다.

runc의 가장 큰 특징은 단일성과 명확성에 있다. 이 도구는 단일 컨테이너를 라이프사이클 관리하는 데 특화되어 있으며, 이미지 관리나 네트워크, 스토리지와 같은 상위 수준의 기능은 포함하지 않는다. 대신, containerd나 CRI-O와 같은 상위 레벨의 컨테이너 런타임이 runc를 내부 엔진으로 호출하여 컨테이너를 실행하는 구조를 가진다. 이러한 설계는 모듈성과 유연성을 높여, 다양한 컨테이너 오케스트레이션 플랫폼과 도구들이 표준화된 방식으로 컨테이너를 실행할 수 있는 기반을 제공한다.

runc는 Go 언어로 작성되었으며, 도커를 비롯한 레드햇, 구글, IBM 등 주요 기업들의 기여를 통해 개발되고 유지보수된다. 이는 쿠버네티스의 기본 컨테이너 런타임 인터페이스인 CRI를 지원하는 런타임들의 핵심 구성 요소로서, 현대 클라우드 네이티브 생태계의 중요한 인프라를 이루고 있다.

containerd는 도커가 2015년 6월에 기여한 고수준 컨테이너 런타임이다. 이는 OCI의 런타임 스펙을 구현하는 runc와 같은 저수준 런타임을 관리하고 추상화하는 역할을 한다. containerd는 컨테이너의 전체 수명 주기, 즉 생성, 시작, 중지, 삭제와 같은 핵심 작업을 담당하며, 컨테이너 이미지의 전송, 저장, 관리를 위한 기능도 제공한다. 도커 엔진은 내부적으로 containerd를 사용하여 컨테이너를 실행한다.

containerd의 주요 구성 요소는 다음과 같다. | 구성 요소 | 주요 기능 |

|---|---|

| 컨테이너 런타임 | runc를 통해 컨테이너 실행 및 관리 |

| 이미지 관리 | 로컬 이미지 저장소 및 전송 관리 |

| 스토리지 | 컨테이너와 이미지에 대한 스냅샷 관리 |

| 네트워킹 | 컨테이너 네트워크 네임스페이스 관리 |

이러한 설계로 인해 containerd는 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼의 런타임 인터페이스인 CRI를 직접 지원하는 CRI-O와 함께, 클라우드 네이티브 환경에서 가장 널리 사용되는 컨테이너 런타임 중 하나가 되었다. containerd는 마이크로소프트, 구글, IBM 등 여러 주요 기업의 지속적인 기여를 받으며 발전하고 있다.

CRI-O는 쿠버네티스의 컨테이너 런타임 인터페이스를 구현한 경량화된 컨테이너 런타임이다. 쿠버네티스가 도커에 대한 의존성을 줄이고, 컨테이너 생태계를 더욱 개방적으로 만들기 위해 도입한 CRI 표준을 준수하도록 설계되었다. 주로 레드햇의 OpenShift와 같은 쿠버네티스 기반 플랫폼에서 사용되며, 쿠버네티스의 kubelet이 직접 통신할 수 있는 최소한의 런타임 계층을 제공하는 것이 목표이다.

CRI-O는 오픈 컨테이너 이니셔티브의 표준을 기반으로 구축되어, runc를 하위 런타임으로 사용하며 OCI 호환 이미지를 직접 풀링하고 실행한다. 이는 containerd와 유사한 역할을 하지만, 쿠버네티스에 특화되어 불필요한 기능을 제거함으로써 더 간결하고 안정적인 운영을 가능하게 한다. 주요 구성 요소로는 이미지 관리, 컨테이너 스토리지, 모니터링을 담당하는 라이브러리들이 포함된다.

CRI-O의 등장은 쿠버네티스 생태계에서 컨테이너 런타임의 선택지를 다양화하고, 도커 엔진에 대한 종속성을 해소하는 데 기여했다. 이는 클라우드 네이티브 환경에서의 유연성과 보안성을 높이며, 마이크로서비스 아키텍처의 효율적인 운영을 지원한다.