Containerd

containerd는 컨테이너의 생명주기 관리를 담당하는 컨테이너 런타임이다. Docker, Inc.가 2015년 12월에 최초 공개했으며, 이후 클라우드 네이티브 컴퓨팅 환경에서 컨테이너의 핵심 실행 계층으로 널리 채택되었다. 이 도구는 이미지 전송 및 저장, 저수준 스토리지 관리, 네트워크 인터페이스 및 네트워크 네임스페이스 관리, 실행 중인 컨테이너의 감시 등 컨테이너 운영에 필요한 기본적인 기능을 제공한다.

containerd는 복잡한 컨테이너 오케스트레이션 시스템이나 컨테이너 엔진 아래에서 동작하는 표준화된 중간 계층을 목표로 설계되었다. 이는 Docker 엔진의 핵심 구성 요소로 시작했으나, 이후 독립적인 오픈 소스 프로젝트로 분리되어 CNCF(Cloud Native Computing Foundation)에 기증되었다. 이러한 설계는 Kubernetes와 같은 오케스트레이터가 다양한 런타임을 일관된 방식으로 사용할 수 있는 기반을 마련했다.

주요 용도는 컨테이너의 생성, 시작, 정지, 삭제와 같은 생명주기 관리에 있으며, OCI(Open Container Initiative) 런타임 사양을 준수한다. 이를 통해 runc와 같은 하위 런타임을 조정하여 실제 컨테이너 프로세스를 실행한다. 결과적으로 containerd는 고수준의 관리 도구와 저수준의 운영 체제 리소스 사이에서 안정적이고 효율적인 인터페이스 역할을 수행한다.

containerd는 2015년 12월 Docker, Inc.에 의해 최초로 공개된 컨테이너 런타임이다. 이 프로젝트는 Docker 엔진의 핵심 기능 중 하나였던 컨테이너의 실행과 관리를 담당하는 부분을 분리하고 모듈화하기 위한 목적으로 시작되었다. 초기에는 Docker 엔진 내부의 데몬 컴포넌트로 존재했으나, 클라우드 네이티브 컴퓨팅 생태계의 성장과 함께 컨테이너 기술의 표준화와 상호운용성에 대한 요구가 높아지면서 독립적인 프로젝트로 발전하게 되었다.

이러한 배경에는 Kubernetes와 같은 오케스트레이션 플랫폼이 등장하면서, Docker 엔진 전체가 아닌 보다 가볍고 효율적인 컨테이너 런타임에 대한 필요성이 대두된 점이 크게 작용했다. containerd는 Docker의 복잡한 기능 세트 중에서 컨테이너의 생명주기 관리, 이미지 전송 및 저장, 저수준 스토리지 관리와 같은 핵심적인 저수준 기능에 집중하도록 설계되었다. 이로써 더 높은 수준의 도구나 플랫폼이 containerd를 안정적인 기반으로 활용할 수 있는 길이 열렸다.

2017년 3월, containerd 프로젝트는 공식적으로 Cloud Native Computing Foundation(CNCF)에 기증되어 호스팅되기 시작했다. 이는 프로젝트의 중립성과 공개 생태계 내에서의 협업을 강화하는 중요한 전환점이었다. 이후 containerd는 CNCF의 졸업 프로젝트로 성장했으며, Kubernetes의 표준 컨테이너 런타임 인터페이스(CRI)를 완벽하게 지원하는 런타임으로 자리매김하여 현대 클라우드 네이티브 인프라의 핵심 기반 중 하나가 되었다.

containerd는 원래 Docker 엔진의 핵심 구성 요소로 개발되었다. 초기 Docker는 단일한 모놀리식 바이너리였으나, 점차 모듈화와 특정 기능의 분리를 추구하게 되었다. 이 과정에서 컨테이너의 생명주기 관리, 이미지 관리, 저장소 관리와 같은 저수준의 핵심 기능을 담당하는 컴포넌트가 containerd로 분리되어 추상화 계층을 제공하게 되었다. 이는 Docker 엔진이 더 가볍고 유지보수하기 쉬운 구조를 가지도록 하는 데 기여했다.

Docker 엔진은 사용자에게 친숙한 CLI와 API를 제공하는 상위 레이어 역할을 하고, 실제 컨테이너 생성 및 실행과 같은 저수준 작업은 내부적으로 containerd에 위임하는 구조를 갖추게 되었다. 이 관계는 마치 운영 체제의 커널과 셸의 관계와 유사하다고 볼 수 있다. Docker는 사용자 인터페이스와 고수준의 편의 기능을, containerd는 안정적이고 효율적인 컨테이너 런타임 운영을 각각 담당하게 된 것이다.

2017년, Docker는 클라우드 네이티브 컴퓨팅 재단(CNCF)에 containerd를 기증하여 프로젝트를 완전히 오픈 소스화하고 공동체 주도로 발전시키기로 결정했다. 이는 containerd가 Docker 생태계를 넘어서 Kubernetes와 같은 다른 오케스트레이션 플랫폼에서도 표준적인 컨테이너 런타임으로 채택되는 중요한 계기가 되었다. 현재 Docker는 여전히 containerd를 기본 런타임으로 사용하고 있지만, containerd 자체는 독립적인 프로젝트로서 더 넓은 생태계에서 표준의 지위를 확보하게 되었다.

이러한 분리는 컨테이너 기술의 발전에 있어 중요한 이정표였다. 핵심 런타임의 표준화와 분리는 생태계의 호환성을 높이고, 사용자와 개발자에게 더 많은 선택권과 유연성을 제공하게 되었다. 결과적으로 containerd는 Docker로부터 태어났지만, 이제는 클라우드 네이티브 스택의 기반을 이루는 핵심 인프라 컴포넌트로서 독자적인 정체성을 가지게 되었다.

containerd는 쿠버네티스 생태계에서 컨테이너 런타임의 핵심 구성 요소로 작동한다. 쿠버네티스는 컨테이너 런타임 인터페이스(CRI)라는 표준 API를 정의하여 다양한 컨테이너 런타임을 플러그인 방식으로 통합한다. containerd는 이 CRI 표준을 완벽히 준수하는 런타임으로, containerd 데몬 내부의 CRI 플러그인을 통해 쿠버네티스 kubelet과 직접 통신한다. 이 통합 구조를 통해 쿠버네티스는 파드 생성, 컨테이너 실행, 이미지 풀링, 로그 수집 등의 저수준 작업을 containerd에 위임할 수 있게 되었다.

쿠버네티스에서 containerd를 사용하는 주요 이점은 성능과 안정성에 있다. 도커 엔진을 사용할 때는 도커 데몬이 중간 레이어로 존재했지만, containerd는 보다 경량화되고 직접적인 통신 경로를 제공한다. 이는 불필요한 추상화 계층을 제거하여 컨테이너 시작 시간을 단축하고 자원 사용을 최적화한다. 결과적으로 containerd는 도커 셰임이나 CRI-O와 함께 쿠버네티스의 권장 컨테이너 런타임 중 하나로 자리 잡았다.

이러한 통합 덕분에 시스템 관리자는 쿠버네티스 클러스터를 구성할 때 런타임으로 containerd를 선택할 수 있으며, 이는 특히 대규모 클라우드 네이티브 환경에서 표준 구성으로 널리 채택되고 있다. containerd의 모듈화된 설계는 쿠버네티스의 빠른 진화와 다양한 하드웨어 및 클라우드 플랫폼 지원 요구를 효과적으로 뒷받침한다.

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

설치 후에는 containerd 데몬이 시스템 서비스로 등록되어 백그라운드에서 실행된다. 주요 구성 파일은 /etc/containerd/config.toml에 위치하며, TOML 형식으로 작성된다. 이 파일을 통해 런타임 클래스 설정, 플러그인 활성화 여부, 이미지 저장소 위치, 로그 레벨, cgroup 드라이버, 샌드박스 이미지 등 다양한 저수준 설정을 조정할 수 있다. 기본적으로 제공되는 설정 파일은 containerd config default 명령으로 생성할 수 있다.

쿠버네티스와 함께 사용할 경우, kubelet은 컨테이너 런타임 인터페이스를 통해 containerd와 통신한다. 이때 cri 플러그인이 활성화되어 있어야 하며, 이는 기본 설정에 포함되어 있다. 네트워크 구성은 일반적으로 CNI 플러그인에 의해 처리되며, containerd는 컨테이너의 네트워크 네임스페이스를 생성하고 관리하는 역할을 담당한다.

시스템 구성 후에는 ctr이나 nerdctl 같은 명령줄 도구를 사용하여 containerd를 직접 제어하고 테스트할 수 있다. ctr은 containerd에 내장된 간단한 클라이언트 도구이며, nerdctl은 도커 CLI와 유사한 사용자 경험을 제공하는 풍부한 기능의 외부 도구이다.

containerd는 주로 API를 통해 제어되지만, 사용자 편의를 위해 ctr이라는 커맨드라인 도구를 기본적으로 제공한다. ctr은 containerd의 기능을 직접 테스트하고 저수준 작업을 수행하는 데 사용되며, Docker나 Kubernetes와 같은 상위 레벨 도구를 사용할 때는 일반적으로 직접 다루지 않는다.

ctr 명령어의 기본 구조는 ctr [전역 옵션] 명령어 [명령어 옵션] [인자...]이다. 주요 명령어 카테고리는 다음과 같다.

실제 사용 예시로, docker.io/library/nginx:alpine 이미지를 다운로드하고 컨테이너를 실행하는 과정은 다음과 같다. 먼저 ctr images pull docker.io/library/nginx:alpine으로 이미지를 풀한다. 이후 ctr containers create --net-host docker.io/library/nginx:alpine nginx-container 명령으로 컨테이너를 생성하고, ctr tasks start -d nginx-container로 백그라운드에서 컨테이너 내 프로세스를 시작한다. 실행 상태는 ctr tasks list로 확인할 수 있다.

ctr은 gRPC 클라이언트로서 containerd 데몬과 통신한다. 상용 환경에서는 Kubernetes의 컨테이너 런타임 인터페이스(CRI) 플러그인을 통해 crictl 도구를 사용하거나, Docker Engine을 통해 간접적으로 containerd를 활용하는 것이 일반적이다. 이는 ctr이 사용자 친화적인 CLI를 목표로 하지 않는 저수준 도구이기 때문이다.

containerd는 단일 목적의 컨테이너 런타임으로 설계되어, 복잡한 컨테이너 생태계에서 명확한 책임 분리를 가능하게 한다는 점이 가장 큰 장점이다. 이는 모듈화된 아키텍처 덕분에 Docker 엔진과 같은 상위 레벨 도구나 쿠버네티스와 같은 오케스트레이션 플랫폼이 컨테이너의 핵심 생명주기 관리에 집중할 수 있게 하며, 시스템의 유지보수성과 안정성을 높인다. 또한, OCI 표준을 준수하는 런타임을 사용함으로써 호환성을 보장하고, CRI를 통해 쿠버네티스와의 원활한 통합을 제공한다. 이러한 표준 준수는 벤더 종속성을 줄이고 생태계의 건강한 발전에 기여한다.

containerd의 또 다른 강점은 성능과 효율성에 있다. 가볍고 빠른 데몬으로 설계되어 시스템 리소스 사용을 최소화하며, 컨테이너 생성 및 시작 속도가 빠르다. 이는 대규모 클라우드 네이티브 환경과 마이크로서비스 아키텍처에서 수천 개의 컨테이너를 효율적으로 관리해야 할 때 중요한 이점이 된다. 또한, 안정성이 검증된 프로덕션급 소프트웨어로서, CNCF의 졸업 프로젝트 지위를 획득할 만큼 엔터프라이즈 환경에서의 신뢰도가 높다.

반면, containerd는 저수준의 핵심 런타임에 특화되어 있기 때문에 단독으로 사용하기에는 기능이 제한적이라는 단점이 있다. 사용자는 컨테이너 이미지 빌드, 고수준의 네트워킹, 사용자 친화적인 CLI와 같은 기능을 직접 사용할 수 없으며, 이러한 작업을 위해서는 nerdctl이나 crictl과 같은 추가 도구나 상위 레벨 도구에 의존해야 한다. 이는 초보자에게는 진입 장벽으로 작용할 수 있다.

마지막으로, containerd는 주로 리눅스 환경을 위해 설계되었다. 다른 운영체제에 대한 지원은 도커 데스크톱과 같은 통합 솔루션을 통해 간접적으로 이루어지는 경우가 많아, 윈도우나 macOS에서의 네이티브 사용이나 특정 기능의 완전한 호환성에는 제약이 있을 수 있다. 또한, 모든 설정이 구성 파일을 통해 이루어지기 때문에, 복잡한 사용 사례의 경우 상대적으로 세밀한 구성이 필요할 수 있다.

containerd는 클라우드 네이티브 컴퓨팅 생태계의 핵심 구성 요소로서, 여러 상위 레벨 도구와 프로젝트와 긴밀하게 연동되어 동작한다. 가장 대표적인 연동 사례는 Docker와 Kubernetes이다. Docker는 containerd를 자신의 핵심 컨테이너 런타임 엔진으로 채택하여 사용하며, Kubernetes는 컨테이너 런타임 인터페이스(CRI)를 통해 containerd와 통신하여 파드 내 컨테이너를 생성하고 관리한다. 이러한 통합 덕분에 containerd는 대규모 컨테이너 오케스트레이션 환경의 표준 기반이 되었다.

containerd의 기능을 확장하거나 보완하는 다양한 도구들이 존재한다. BuildKit은 컨테이너 이미지를 빌드하기 위한 전문 도구로, containerd와 연동하여 빌드된 이미지를 직접 containerd의 저장소에 푸시할 수 있다. nerdctl은 Docker CLI와 유사한 사용자 경험을 제공하는 containerd 전용 명령줄 도구로, 개발자들이 containerd를 더 쉽게 제어하고 실험할 수 있게 해준다. 또한, CNI(Container Network Interface) 플러그인들은 containerd가 컨테이너의 네트워크를 구성할 때 사용되는 표준 인터페이스를 제공한다.

containerd 자체도 모듈식 아키텍처를 채택하여 다양한 기능을 플러그인 형태로 확장할 수 있도록 설계되었다. 이를 통해 커뮤니티나 벤더들은 특정 스토리지 백엔드, 런타임, 또는 모니터링 도구와의 통합을 위한 플러그인을 개발할 수 있다. 이러한 개방성과 확장성은 containerd가 클라우드 네이티브 재단(CNCF)의 졸업 프로젝트로서 생태계의 표준을 주도하는 데 기여하고 있다.

containerd는 Docker 엔진의 핵심 구성 요소로 시작하여 독립적인 오픈 소스 컨테이너 런타임으로 성장했다. 이 분리 과정은 클라우드 네이티브 컴퓨팅 생태계의 모듈화 경향을 반영하며, Kubernetes와 같은 오케스트레이션 플랫폼이 보다 가볍고 전문화된 런타임을 요구한 배경이 있다. containerd는 이러한 요구에 부응하여 CNCF(Cloud Native Computing Foundation)에 기증되었고, 2019년 2월에 졸업 프로젝트로 승격되어 프로덕션 환경에서의 안정성과 성숙도를 공식적으로 인정받았다.

containerd의 발전은 마이크로서비스 아키텍처의 철학과도 맞닿아 있다. 복잡한 Docker 데몬을 여러 전담 구성 요소로 분해함으로써, 각 계층(예: 런타임, 이미지 관리, 네트워크)의 책임이 명확해지고 유지보수성과 확장성이 향상되었다. 이는 OCI(Open Container Initiative) 표준의 채택과 함께 컨테이너 기술의 산업 표준화를 촉진하는 데 기여했다.

현재 containerd는 Kubernetes의 기본 컨테이너 런타임 중 하나로 널리 채택되어 있으며, AWS, Google Cloud, Microsoft Azure와 같은 주요 퍼블릭 클라우드 서비스의 관리형 Kubernetes 서비스에서도 핵심 인프라를 구성한다. 또한, 도커 데스크톱과 Moby 프로젝트에도 여전히 통합되어 있어, 개발자 경험과 엔터프라이즈 인프라 사이를 연결하는 중요한 역할을 계속하고 있다.