containerd

containerd는 컨테이너 런타임의 핵심 구성 요소이다. 이는 호스트 시스템에서 컨테이너의 전체 라이프사이클을 관리하는 데 사용되는 소프트웨어로, 컨테이너의 생성, 시작, 중지, 삭제, 이미지 전송 및 스토리지 관리를 담당한다. 본래 도커 엔진의 일부로 개발되었으나, 모듈화와 표준화를 위해 분리되어 독립적인 프로젝트가 되었다.

현재 containerd는 클라우드 네이티브 컴퓨팅 재단(CNCF)의 졸업(Graduated) 프로젝트로, 재단의 가장 성숙하고 안정적인 프로젝트 중 하나로 인정받고 있다. 이는 생태계 내에서 높은 채택률과 엔터프라이즈급 안정성을 입증한 것이다. containerd는 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼의 기본 런타임으로 널리 사용되며, 도커 엔진 또한 내부적으로 containerd를 런타임으로 활용한다.

이 프로젝트는 낮은 수준의 컨테이너 런타임 기능을 안정적이고 효율적으로 제공하는 데 중점을 둔다. 이를 통해 더 높은 수준의 도구와 플랫폼이 컨테이너 관리의 복잡성을 추상화하고, 표준화된 인터페이스를 통해 호환성을 유지할 수 있는 기반을 마련한다. 결과적으로 containerd는 현대 클라우드 네이티브 인프라스트럭처의 중요한 기반 기술로서 자리 잡았다.

containerd의 역사는 도커 생태계의 진화와 밀접하게 연결되어 있다. 2016년 12월, 도커는 컨테이너 런타임의 핵심 기능을 분리하여 더 가볍고 모듈화된 구성 요소를 만들기 위해 containerd 프로젝트를 시작했다. 이는 도커 엔진의 복잡성을 줄이고, 다른 시스템(특히 오케스트레이션 플랫폼)이 컨테이너 런타임을 더 쉽게 통합하고 관리할 수 있도록 하기 위한 전략적 결정이었다.

2017년 3월, 도커는 containerd를 클라우드 네이티브 컴퓨팅 재단(CNCF)에 기부하여 인큐베이팅 프로젝트로 편입시켰다. 이는 containerd가 도커의 독점적 영향력에서 벗어나 공정하고 중립적인 오픈소스 커뮤니티의 관리를 받게 되었음을 의미한다. 이후 containerd는 쿠버네티스의 기본 컨테이너 런타임 인터페이스(CRI)를 위한 표준 런타임으로 빠르게 채택되며 그 중요성이 부각되었다.

CNCF 내에서 containerd는 활발한 개발과 채택을 증명하여 2019년 2월에 졸업(Graduated) 프로젝트 지위를 획득했다. 이는 프로젝트가 성숙도, 지속 가능성, 생태계 내 영향력에 대한 CNCF의 엄격한 기준을 충족했음을 인정받은 것이다. 현재 containerd는 도커 엔진의 핵심 런타임 구성 요소로 계속 사용되는 동시에, 쿠버네티스를 비롯한 많은 클라우드 네이티브 플랫폼의 표준 기반 컨테이너 런타임으로 자리 잡았다.

containerd는 모듈화된 설계를 채택하여 핵심 컨테이너 런타임 기능을 제공하는 동시에 확장성을 보장한다. 그 아키텍처는 크게 클라이언트 인터페이스, 코어 런타임, 그리고 확장 가능한 플러그인 시스템으로 구성된다. 클라이언트는 gRPC API를 통해 containerd와 통신하며, 이 API는 컨테이너와 이미지의 전체 라이프사이클을 관리하는 서비스를 노출한다.

내부적으로 containerd는 여러 핵심 컴포넌트로 세분화된다. 컨테이너의 메타데이터와 상태를 관리하는 '메타데이터 서비스', 컨테이너 실행을 담당하는 '런타임 서비스', 그리고 컨테이너 이미지의 풀(pull), 푸시(push), 관리 기능을 제공하는 '컨텐츠 서비스'와 '이미지 서비스'가 대표적이다. 특히 실행 계층은 runc와 같은 하위 OCI 호환 런타임을 통해 실제 컨테이너 프로세스를 생성하고 관리한다.

이러한 모듈성은 플러그인 아키텍처를 통해 구현된다. containerd는 스냅샷터(snapshotter), 런타임, 이미지 전송 프로토콜 등 다양한 기능을 플러그인 형태로 교체하거나 확장할 수 있도록 설계되었다. 예를 들어, 스냅샷터 플러그인을 통해 오버레이FS, 블록 디바이스 등 다양한 스토리지 백엔드를 지원한다. 이 설계는 containerd를 경량화하면서도 쿠버네티스나 도커 엔진과 같은 상위 시스템에 안정적인 기반을 제공하는 데 기여한다.

containerd는 컨테이너의 핵심 라이프사이클을 관리하는 데 특화된 컨테이너 런타임이다. 주요 기능은 컨테이너 이미지의 관리와 스토리지에서 컨테이너의 실행, 모니터링, 네트워크 및 스토리지 인터페이스 제공, 하위 시스템 관리에 이르는 전체 생명주기를 효율적으로 처리하는 것이다. 이를 통해 사용자는 리눅스나 윈도우 호스트 시스템 위에서 컨테이너를 생성, 시작, 중지, 일시 정지, 삭제할 수 있다.

이 런타임은 gRPC를 통해 노출되는 안정적인 API를 제공하여 다른 상위 레벨 시스템이나 오케스트레이션 플랫폼이 컨테이너를 제어할 수 있는 표준화된 인터페이스를 만든다. 또한 OCI 런타임 사양을 준수하는 runc와 같은 런타임을 플러그인 형태로 사용하여 실제 컨테이너 프로세스를 실행한다. 이러한 모듈식 설계는 확장성과 유연성을 보장한다.

주요 기능에는 컨테이너 이미지의 풀, 푸시, 관리와 같은 이미지 레지스트리 연동, 로컬 이미지 및 스냅샷 관리가 포함된다. 또한 컨테이너의 네트워크 네임스페이스 생성을 위한 네트워크 플러그인 지원과 컨테이너의 영구 데이터를 위한 스토리지 플러그인 지원도 핵심이다. 이러한 기능들은 containerd를 도커 엔진이나 쿠버네티스와 같은 상위 시스템에 내장되어 안정적인 기반을 제공하게 한다.

containerd는 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼과 통합될 때, 주로 컨테이너 런타임 인터페이스(CRI)를 통해 상호작용한다. CRI는 쿠버네티스 kubelet이 다양한 컨테이너 런타임을 사용할 수 있도록 정의한 플러그인 인터페이스이다. containerd 자체는 CRI를 직접 구현하지 않지만, cri 플러그인이라는 내장 컴포넌트를 통해 CRI 서비스를 제공한다. 이 플러그인이 활성화되면 containerd는 CRI 호환 런타임으로 동작하여 쿠버네티스의 파드 및 컨테이너 생명주기 관리 명령을 처리할 수 있다.

이러한 구조는 쿠버네티스 생태계에서 containerd의 역할을 명확히 한다. kubelet은 CRI를 통해 containerd의 cri 플러그인과 통신하고, 플러그인은 내부의 핵심 containerd API를 호출하여 실제 이미지 관리, 컨테이너 실행, 스토리지, 네트워킹 등의 저수준 작업을 수행한다. 이 분리된 아키텍처는 모듈성과 유연성을 보장하며, 쿠버네티스가 다른 CRI 호환 런타임(예: CRI-O)으로 쉽게 전환할 수 있는 기반을 마련한다.

결과적으로, containerd는 도커 엔진에 비해 더 가볍고 효율적인 CRI 런타임으로 평가받으며, 많은 쿠버네티스 배포판의 기본 또는 권장 컨테이너 런타임으로 채택되고 있다. 이 관계를 통해 containerd는 클라우드 네이티브 스택의 핵심 인프라 계층을 안정적으로 지원하는 역할을 한다.

containerd는 원래 도커 엔진의 핵심 구성 요소로 개발되었다. 초기 도커는 컨테이너의 이미지 관리, 네트워크, 스토리지, 그리고 런타임 생명주기 관리 등 모든 기능을 단일 모놀리식 데몬인 dockerd에 통합했다. 2016년 12월, 도커는 아키텍처를 모듈화하고 핵심 컨테이너 런타임 기능을 분리하기로 결정했으며, 이 분리된 컴포넌트가 바로 containerd이다. 이로써 도커 엔진은 dockerd가 고수준의 API와 사용자 인터페이스를 제공하고, 실제 컨테이너 조작은 containerd에 위임하는 2계층 구조로 진화했다.

이러한 분리는 생태계에 중요한 영향을 미쳤다. containerd는 독립적인 오픈소스 프로젝트로 성장하여 2017년 3월 클라우드 네이티브 컴퓨팅 재단(CNCF)에 기증되었다. 이후 containerd는 CNCF의 졸업(Graduated) 프로젝트가 되어 다양한 컨테이너 도구와 오케스트레이션 플랫폼의 표준 런타임 기반으로 자리 잡았다. 반면, 도커는 여전히 containerd를 기본 런타임으로 사용하는 주요 사용자이자 기여자 역할을 유지하고 있다.

결과적으로, 현재 도커와 containerd의 관계는 공생 관계에 가깝다. 도커는 최종 사용자에게 친숙한 도구 체인과 개발자 경험을 제공하는 상위 레이어이고, containerd는 안정적이고 효율적인 저수준 컨테이너 런타임 서비스를 제공하는 기반 인프라이다. 이 분리는 쿠버네티스와 같은 다른 시스템이 도커 엔진 전체에 의존하지 않고도 containerd를 직접 통합할 수 있는 길을 열어주었다.

쿠버네티스는 컨테이너 오케스트레이션 플랫폼으로, 클러스터 내 수많은 컨테이너의 배포, 관리, 확장을 자동화한다. 쿠버네티스가 이러한 컨테이너를 실제로 실행하고 관리하려면 각 노드에 안정적인 컨테이너 런타임이 필요하다. containerd는 바로 이 역할을 수행하는 핵심 런타임 컴포넌트로, 쿠버네티스와 긴밀하게 통합되어 있다.

쿠버네티스는 CRI(Container Runtime Interface)라는 표준 플러그인 인터페이스를 통해 컨테이너 런타임과 통신한다. containerd는 CRI 플러그인(cri-containerd 또는 cri)을 내장하고 있어, CRI를 구현한 다른 런타임과 마찬가지로 쿠버네티스의 kubelet과 직접 연동될 수 있다. 이 통합 구조를 통해 쿠버네티스는 파드 생성, 컨테이너 이미지 풀(pull), 컨테이너 실행 및 모니터링 등의 명령을 containerd에 전달하고, containerd는 이를 호스트 시스템에서 실행한다.

containerd는 도커 엔진의 핵심 컴포넌트로 분리되어 발전했으며, 이후 클라우드 네이티브 컴퓨팅 재단의 졸업 프로젝트가 되었다. 이로 인해 높은 수준의 안정성과 업계 표준으로 인정받아, 많은 쿠버네티스 배포판과 클라우드 서비스의 기본 또는 권장 컨테이너 런타임으로 채택되었다. k3s나 특정 GKE(Google Kubernetes Engine) 버전과 같은 경량화된 환경에서도 containerd는 CRI-O와 함께 주요 런타임 옵션으로 사용된다.

containerd는 다양한 방법으로 설치할 수 있다. 가장 일반적인 방법은 운영 체제의 패키지 관리자를 이용하는 것이다. 예를 들어, 우분투나 데비안 계열의 리눅스에서는 apt 명령어를, CentOS나 페도라와 같은 RHEL 계열에서는 yum이나 dnf 명령어를 사용하여 공식 저장소에서 설치할 수 있다. 또한, 도커 엔진을 설치하면 자동으로 포함되어 설치되는 경우도 있다. 공식 GitHub 릴리스 페이지에서 직접 바이너리를 다운로드하여 설치하는 방법도 지원한다.

설치 후에는 기본적으로 /etc/containerd/config.toml 파일을 통해 구성을 관리한다. 이 설정 파일은 데몬의 동작 방식, 사용할 컨테이너 런타임(runc 등), 로깅 수준, 저장소 위치, CRI(Container Runtime Interface) 플러그인 설정 등을 정의한다. 초기 설치 시 containerd config default 명령을 실행하면 기본 구성 파일을 생성할 수 있어 편리하다. 시스템 관리자는 특정 저장소 미러 사용, cgroup 드라이버 변경(systemd 사용 여부), 또는 디버그 로그 활성화 등을 위해 이 파일을 수정한다.

쿠버네티스와 함께 사용할 경우, kubelet은 CRI를 통해 containerd와 통신한다. 이때 cri 플러그인이 활성화되어 있어야 하며, kubelet의 --container-runtime-endpoint 플래그를 unix:///run/containerd/containerd.sock과 같이 설정하여 연결한다. 네트워크와 영구 저장소 관리는 일반적으로 CNI(Container Network Interface) 플러그인과 외부 CSI(Container Storage Interface) 드라이버에 위임된다.

containerd는 단독으로 사용되기보다는 상위 시스템의 핵심 구성 요소로 통합되어 다양한 사용 사례를 지원한다. 가장 대표적인 사례는 쿠버네티스와 도커 엔진이다. 쿠버네티스는 컨테이너 런타임 인터페이스(CRI)를 통해 containerd를 표준 런타임으로 사용하여 파드 내 컨테이너의 실행과 관리를 위임한다. 이는 쿠버네티스 클러스터를 운영하는 데 있어 안정적이고 효율적인 기반을 제공한다. 또한 도커 엔진은 containerd를 내부의 핵심 런타임 컴포넌트로 사용하며, 사용자가 docker run 등의 명령을 실행할 때 실제 컨테이너 작업을 처리한다.

클라우드 네이티브 애플리케이션의 개발과 배포 파이프라인에서도 containerd는 중요한 역할을 한다. 지속적 통합 및 지속적 배포(CI/CD) 도구들은 테스트나 빌드 과정에서 컨테이너를 생성하고 실행하기 위해 containerd를 직접 호출할 수 있다. 이는 더 가볍고 제어 가능한 환경을 제공한다. 또한 서버리스 플랫폼이나 펑션 as 어 서비스(FaaS) 프레임워크에서 함수 인스턴스를 빠르게 실행하고 격리하는 용도로 사용되며, 엣지 컴퓨팅 환경과 같이 리소스가 제한된 장치에서도 경량의 컨테이너 런타임 솔루션으로 채택된다.

보다 직접적인 사용 사례로는 시스템 관리자나 개발자가 커맨드 라인 인터페이스 도구인 ctr이나 상위 도구인 nerdctl을 이용해 containerd에 직접 접근하는 경우가 있다. 이를 통해 도커 데몬 없이도 컨테이너 이미지를 풀(pull) 받고, 컨테이너를 실행하며, 스냅샷을 관리하는 등의 저수준 작업을 수행할 수 있다. 이는 컨테이너 기술을 깊이 이해하거나, 최소한의 오버헤드로 컨테이너 인프라를 구축하고자 할 때 유용하다.

containerd는 단독으로 동작하지 않고, 클라우드 네이티브 컴퓨팅 재단 생태계 내의 다른 핵심 프로젝트들과 긴밀하게 연동되어 완전한 컨테이너 솔루션을 구성한다. 가장 직접적인 관련 프로젝트는 쿠버네티스와의 통합을 위한 컨테이너 런타임 인터페이스이다. CRI는 쿠버네티스 kubelet이 containerd와 같은 하위 런타임과 표준화된 방식으로 통신할 수 있게 하는 플러그인이다. containerd는 이 CRI 플러그인을 내장하고 있어, 쿠버네티스 클러스터의 기본 런타임으로 널리 사용된다.

containerd의 핵심 기능은 이미지 관리와 스토리지이며, 이는 도커와의 관계에서 잘 드러난다. 도커 엔진은 1.11 버전 이후로 컨테이너 실행 기능을 containerd에 위임하는 아키텍처로 전환했다. 즉, 사용자가 docker run 명령을 실행하면 도커 엔진은 내부적으로 containerd를 호출하여 실제 컨테이너를 생성하고 실행한다. 이로 인해 containerd는 도커 생태계의 기반 런타임이 되었다.

CNCF 생태계 내에서 containerd는 다른 졸업 프로젝트들과도 협력한다. 예를 들어, 분산 키-값 저장소인 etcd는 쿠버네티스 클러스터 상태를 저장하는 데 사용되며, containerd가 실행 중인 클러스터의 구성 정보를 간접적으로 의존할 수 있다. 또한, 모니터링 도구인 프로메테우스는 containerd에서 노출하는 메트릭을 수집하여 컨테이너의 성능과 상태를 관찰하는 데 활용될 수 있다. 네트워킹 및 보안 분야의 CNI나 CoreDNS와 같은 프로젝트들도 containerd가 실행하는 컨테이너의 네트워크 구성과 서비스 디스커버리 기능을 제공한다.

containerd는 원래 도커 엔진의 핵심 구성 요소로 개발되었다. 도커는 1.11 버전부터 컨테이너 런타임 기능을 분리하여 containerd라는 독립 실행형 데몬으로 만들었다. 이는 모듈성을 높이고 다른 시스템에서도 containerd를 쉽게 재사용할 수 있도록 하기 위한 전략이었다. 이후 containerd는 2017년 클라우드 네이티브 컴퓨팅 재단(CNCF)에 기증되었고, 2019년 CNCF 졸업(Graduated) 프로젝트 지위를 획득했다. 이는 프로젝트가 성숙도, 안정성, 생태계 내 채용도에서 최고 수준에 도달했음을 의미한다.

containerd의 성공은 그 단순함과 집중된 역할에 기인한다. 고수준의 오케스트레이션 도구인 쿠버네티스나 완전한 사용자 경험을 제공하는 도커와 달리, containerd는 컨테이너의 실행과 관리를 위한 견고한 기반에만 집중한다. 이러한 설계 철학은 유닉스 철학의 '한 가지 일을 잘 한다'는 원칙을 따르며, 결과적으로 다양한 상위 레이어 도구들이 이를 표준 런타임으로 채택하는 결과를 낳았다.

현재 containerd는 쿠버네티스의 기본 컨테이너 런타임 인터페이스(CRI) 호환 런타임으로 널리 사용된다. 또한 도커 엔진 자체도 내부적으로 containerd를 런타임 엔진으로 활용하고 있다. 이는 containerd가 클라우드 네이티브 스택의 보이지 않는 기반이 되었음을 보여준다. 많은 사용자가 직접 containerd와 상호작용하지는 않지만, 그들이 사용하는 대부분의 컨테이너 플랫폼은 결국 containerd에 의해 구동된다고 해도 과언이 아니다.

• 위키백과 - containerd

• Cloud Native Computing Foundation - containerd

• GitHub - containerd/containerd

• Docker Docs - About containerd

• IBM - What is containerd?

• Red Hat - What is containerd?

• AWS - Containerd

• Microsoft Learn - Containerd overview

• Google Cloud - Containerd on Google Kubernetes Engine

• OCI - Open Container Initiative runtime spec

• ko.wikipedia.org