컨테이너 런타임 인터페이스편집자 확인

컨테이너 런타임 인터페이스(Container Runtime Interface, CRI)는 쿠버네티스가 컨테이너를 실행하고 관리하기 위해 사용하는 컨테이너 런타임과 통신하는 표준 API이다. 이 인터페이스는 쿠버네티스의 핵심 컴포넌트인 kubelet과 다양한 컨테이너 런타임 사이의 통신 계층을 정의한다.

CRI는 쿠버네티스가 특정 컨테이너 런타임(예: Docker)에 종속되는 것을 방지하기 위해 도입되었다. 이를 통해 사용자는 containerd, CRI-O 등 CRI를 준수하는 어떤 런타임이든 쿠버네티스와 함께 사용할 수 있다. CRI는 주로 gRPC 기반의 프로토콜을 사용하며, PodSandbox 생성/삭제, 컨테이너 생명주기 관리, 이미지 풀링 및 관리 등의 기능을 표준화한다.

CRI의 등장으로 쿠버네티스 생태계는 더욱 모듈화되고 유연해졌다. 컨테이너 런타임 제공자는 CRI 사양을 구현하기만 하면 쿠버네티스와 호환되는 런타임을 제공할 수 있다. 이는 오픈 컨테이너 이니셔티브(OCI) 표준과 함께 현대 컨테이너 인프라의 핵심 표준 중 하나로 자리 잡았다.

쿠버네티스 초기 버전은 도커 엔진과 직접 통합되어 컨테이너 생명주기를 관리했다. 이는 쿠버네티스가 도커에 강하게 종속되는 구조를 만들었으며, 다른 컨테이너 런타임을 지원하기 어렵게 했다. 당시 rkt와 같은 대안 런타임을 사용하려면 복잡한 통합 작업이 필요했다.

이러한 강한 결합은 여러 문제를 야기했다. 첫째, 쿠버네티스 코어 개발이 도커 엔진의 릴리스 주기와 내부 변경 사항에 영향을 받았다. 둘째, 다양한 컨테이너 기술(예: 가상머신 기반 컨테이너, 유니컨테이너)이 등장하는 상황에서 쿠버네티스 생태계가 이를 수용할 수 있는 유연한 구조가 필요했다. 이러한 필요성에 따라, 쿠버네티스는 컨테이너 런타임과의 통합 인터페이스를 표준화하기로 결정했다.

그 결과 2016년 말에 쿠버네티스 1.5 버전에서 컨테이너 런타임 인터페이스가 알파 기능으로 도입되었다. CRI의 주요 목표는 쿠버네티스 kubelet 컴포넌트와 다양한 컨테이너 런타임 사이에 명확한 계약을 정의하는 것이었다. 이를 통해 쿠버네티스는 내부 구현을 변경하지 않고도 새로운 런타임을 쉽게 지원할 수 있게 되었다.

CRI의 등장은 쿠버네티스 아키텍처의 중요한 진화를 의미했다. 이는 플러그인 가능한 아키텍처의 원칙을 구현하여, 사용자가 필요에 따라 containerd나 CRI-O 같은 가벼운 런타임을 선택할 수 있는 자유를 부여했다. 결국 CRI는 쿠버네티스 생태계의 다양성과 혁신을 촉진하는 기반이 되었다.

CRI의 핵심 구성 요소는 쿠버네티스 kubelet과 컨테이너 런타임 간의 표준 통신을 정의하는 gRPC 기반의 API와 프로토콜로 구성된다. 이 API는 크게 런타임 서비스(RuntimeService)와 이미지 서비스(ImageService)라는 두 가지 주요 서비스 그룹으로 나뉜다.

첫 번째 핵심 요소는 gRPC API이다. CRI는 프로토콜 버퍼(Protocol Buffers)를 인터페이스 정의 언어(IDL)로 사용하여 메시지 형식과 서비스 메서드를 명시한다. 이는 언어 중립적이며 효율적인 통신을 가능하게 한다. kubelet은 이 gRPC 클라이언트를 통해 런타임에 명령을 전송하고 상태를 조회한다.

두 번째 핵심 요소는 PodSandbox와 Container의 개념적 분리이다. CRI는 파드 단위의 격리 환경을 나타내는 PodSandbox와 그 안에서 실행되는 개별 애플리케이션 프로세스인 Container를 명확히 구분한다. 이 모델은 쿠버네티스의 파드 추상화를 직접 반영한다. 주요 작업은 다음과 같은 흐름으로 이루어진다.

세 번째 핵심 요소는 이미지 관리 서비스(ImageService)이다. 이 서비스는 컨테이너 이미지의 풀(pull), 목록 조회, 삭제와 같은 작업을 담당한다. PullImage, ListImages, RemoveImage 등의 메서드를 제공하여, 런타임이 이미지 레지스트리(도커 허브, 쿠버네티스 컨테이너 레지스트리 등)와 상호작용할 수 있는 표준화된 방법을 정의한다. 이를 통해 kubelet은 다양한 런타임 구현체에 일관된 방식으로 이미지 관리를 지시할 수 있다.

컨테이너 런타임 인터페이스의 주요 구현체는 쿠버네티스가 컨테이너를 실행하고 관리하기 위해 직접 호출하는 런타임 컴포넌트이다. 이 구현체들은 CRI gRPC API를 구현하여 쿠버네티스 kubelet과 통신한다. 각 구현체는 설계 목표와 지원 기능에 차이가 있다.

가장 널리 사용되는 구현체는 containerd이다. 도커 엔진의 핵심 컴포넌트로 개발되었으며, 이후 독립적인 고수준 컨테이너 런타임으로 발전했다. containerd는 CRI 플러그인을 통해 네이티브로 CRI를 지원하며, Open Container Initiative 표준을 준수하는 runc를 하위 런타임으로 사용한다. 안정성과 성능, 광범위한 생태계 지원이 강점이다. 다른 주요 구현체는 CRI-O이다. 쿠버네티스와 OCI 호환 런타임 사이의 경량 브릿지 역할에 특화되어 설계되었다. 불필요한 중간 계층을 제거하여 가볍고 빠르며 보안에 중점을 둔다. 주로 레드햇 오픈시프트와 같은 쿠버네티스 배포판에서 선호된다.

과거에는 도커 엔진 자체가 dockershim이라는 어댑터 컴포넌트를 통해 CRI를 지원했다. 그러나 도커 엔진은 컨테이너 런타임 이상의 많은 기능을 포함하고 있어 무겁고, CRI 지원이 네이티브하지 않았다. 이로 인해 쿠버네티스 프로젝트는 dockershim 지원을 중단하고 사용자들이 containerd나 CRI-O 같은 네이티브 CRI 런타임으로 전환할 것을 권장했다[1].

주요 CRI 구현체 비교는 다음과 같다.

이러한 구현체들은 쿠버네티스 사용자에게 컨테이너 런타임 선택의 유연성을 제공한다. 특정 운영 환경의 요구사항(예: 보안, 성능, 기능 세트)에 따라 적합한 구현체를 선택할 수 있다.

쿠버네티스의 kubelet은 파드 생성 요청을 받으면, 설정된 컨테이너 런타임 인터페이스 엔드포인트를 통해 gRPC 호출을 시작합니다. 이 흐름은 주로 파드 샌드박스 생성과 컨테이너 생성이라는 두 단계로 구분됩니다.

첫 단계는 RunPodSandbox RPC 호출입니다. 이 호출은 파드의 공유 네트워크 네임스페이스, IPC 네임스페이스 등을 포함하는 격리된 실행 환경인 PodSandbox를 생성합니다. CRI 구현체(예: containerd, CRI-O)는 이 호출을 받아 리눅스 네임스페이스, cgroups 등을 설정하고, 필요한 경우 가상 네트워크 인터페이스를 구성합니다. 샌드박스가 성공적으로 실행되면, kubelet은 해당 샌드박스를 식별하는 ID를 받습니다.

다음으로, kubelet은 파드 명세에 정의된 각 애플리케이션 컨테이너에 대해 CreateContainer와 StartContainer 호출을 순차적으로 수행합니다. CreateContainer 호출은 컨테이너의 루트 파일시스템으로 사용할 컨테이너 이미지를 풀(pull)하고, 명령어, 환경 변수, 마운트 포인트 등의 구성을 지정합니다. CRI 구현체는 이 정보를 바탕으로 OCI 런타임 스펙 호환 런타임(예: runc)을 호출할 OCI 구성 파일을 생성합니다. 이후 StartContainer 호출이 이루어지면, OCI 런타임이 실행되어 실제 컨테이너 프로세스를 생성합니다. 컨테이너의 생명주기 동안 kubelet은 ListContainers, ContainerStatus 등을 통해 상태를 지속적으로 모니터링하고, 종료 시 StopContainer 및 RemoveContainer를 호출합니다.

전체 흐름을 간략히 정리하면 다음과 같습니다.

이러한 표준화된 흐름 덕분에 kubelet은 내부 구현을 알 필요 없이 일관된 API를 통해 다양한 컨테이너 런타임을 운영할 수 있습니다.

CRI와 OCI 표준은 현대 컨테이너 생태계를 구성하는 상호 보완적인 두 개의 계층적 표준이다. CRI는 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼이 런타임과 통신하기 위한 상위 수준의 API를 정의하는 반면, OCI 표준은 실제 컨테이너를 실행하고 관리하는 저수준의 런타임 사양을 규정한다. 이 관계는 CRI가 '무엇을' 실행할지 지시하고, OCI 호환 런타임이 '어떻게' 실행할지 구현하는 분업 구조로 이해할 수 있다.

구체적으로, CRI 구현체(예: containerd, CRI-O)는 OCI 사양을 준수하는 런타임(주로 runc)을 하위 구성 요소로 사용한다. 예를 들어, 쿠버네티스 kubelet이 CRI를 통해 컨테이너 생성 요청을 보내면, CRI 구현체는 해당 요청을 해석하여 OCI 호환 번들(파일 시스템 스냅샷과 설정 파일)을 생성하고, 최종적으로 OCI 런타임을 호출하여 컨테이너 프로세스를 생성한다. 이 아키텍처는 다음과 같은 표를 통해 요약할 수 있다.

이러한 분리는 생태계에 큰 유연성을 제공한다. CRI는 다양한 OCI 호환 런타임을 플러그인처럼 사용할 수 있게 하여, 쿠버네티스가 특정 런타임 구현에 종속되지 않도록 한다. 동시에 OCI 표준은 컨테이너 이미지 형식(OCI Image Spec)과 런타임 사양(OCI Runtime Spec)을 표준화함으로써, 서로 다른 벤더의 도구들이 호환성을 유지하며 협업할 수 있는 기반을 마련한다[2]. 따라서 CRI와 OCI는 함께 작동하여 컨테이너 기술의 상호운용성과 혁신을 동시에 추구하는 표준화의 중추 역할을 한다.

CRI는 쿠버네티스와 컨테이너 런타임 간의 결합을 느슨하게 만들어 유연성과 확장성을 크게 향상시켰다. 이전에는 쿠버네티스가 도커 엔진에 직접 의존했지만, CRI를 통해 다양한 컨테이너 런타임을 플러그인 방식으로 지원할 수 있게 되었다. 이는 사용자가 특정 런타임에 종속되지 않고, 성능, 보안, 기능 요구사항에 맞춰 containerd, CRI-O 또는 기타 CRI 호환 런타임을 자유롭게 선택할 수 있음을 의미한다. 또한 새로운 런타임이 등장하더라도 CRI 표준을 준수하기만 하면 쿠버네티스 생태계에 통합될 수 있어 시스템의 미래 지향적 확장이 용이해졌다.

표준화된 인터페이스는 생태계 통합과 유지보수성을 높이는 핵심 이점을 제공한다. CRI는 gRPC 기반의 명확한 프로토콜을 정의함으로써, 쿠버네티스 코어 컴포넌트인 kubelet의 개발과 컨테이너 런타임의 개발을 독립적으로 진행할 수 있게 했다. 이로 인해 양측의 릴리스 주기가 분리되고, 상호 간의 복잡한 의존성이 제거되어 안정성이 개선되었다. 더불어, OCI 표준과의 조화를 통해 컨테이너 이미지 형식과 런타임 사양의 표준화도 함께 이루어져, 벤더 락인을 방지하고 건강한 오픈 소스 생태계를 조성하는 데 기여했다.

CRI가 가져온 구체적인 운영상의 이점은 다음과 같이 정리할 수 있다.

결과적으로 CRI는 쿠버네티스가 다양한 배포 환경(온프레미스, 퍼블릭 클라우드, 엣지 컴퓨팅)에 더욱 효과적으로 적응할 수 있는 기반을 마련했다. 이 표준은 컨테이너 오케스트레이션의 핵심 인프라를 더욱 모듈화하고 강건하게 만들어, 궁극적으로 사용자에게 선택의 자유와 운영 효율성을 보장한다.

CRI는 주로 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼의 핵심 런타임 계층으로 사용된다. 쿠버네티스의 kubelet은 노드에서 파드와 컨테이너의 생명주기를 관리하는 에이전트인데, 이 kubelet이 CRI를 통해 특정 런타임 구현체와 통신한다. 따라서 CRI를 지원하는 모든 런타임은 쿠버네티스와 호환되어 사용될 수 있다.

주요 배포 환경은 크게 클라우드 환경과 온프레미스 환경으로 나눌 수 있다. 대부분의 주요 퍼블릭 클라우드 서비스의 관리형 쿠버네티스 서비스는 CRI를 기반으로 구축된다.

특수한 사용 사례로는 보안 강화 환경이 있다. CRI-O는 Red Hat의 OpenShift와 같은 엔터프라이즈 플랫폼에서 보안 정책과의 긴밀한 통합을 위해 자주 사용된다. 또한 도커 엔진에서 CRI 구현체로 전환하는 과정에서, 기존 도커 환경을 유지하면서 쿠버네티스를 운영하던 사용자들은 dockershim을 통해 CRI를 사용했다[3]. 현재는 표준 CRI 구현체로의 전환이 권장된다.

CRI는 다양한 리눅스 배포판과 운영체제에서도 지원된다. 쿠버네티스 클러스터를 구성하는 모든 노드의 운영체제에 적합한 CRI 구현체를 설치함으로써, 이기종 환경에서도 일관된 컨테이너 런타임 인터페이스를 유지할 수 있다. 이는 하이브리드 클라우드 및 멀티 클라우드 전략의 기반 인프라를 구성하는 데 중요한 역할을 한다.

• Kubernetes 공식 문서 - Container Runtime Interface (CRI)

• Kubernetes 블로그 - CRI 소개 및 업데이트

• GitHub - Kubernetes CRI 프로토콜 정의

• Open Container Initiative (OCI) 공식 사이트

• CNCF (Cloud Native Computing Foundation) - CRI 관련 자료

• IBM Developer - Kubernetes CRI 이해하기

• Red Hat - 컨테이너 런타임과 CRI-O 소개