[Kubernetes] Container Runtimes(컨테이너 런타임) - DevelopMoon

 

Container Runtimes

쿠버네티스 컨테이너 런타임이란 쿠버네티스에서 컨테이너를 실행하고 관리하는 소프트웨어이다.

컨테이너 런타임은 애플리케이션이 운영 환경에서 격리된 상태로 동작할 수 있도록 컨테이너를 생성, 실행, 관리하는 역할을 한다.

---

Docker vs ContainerD

가장 많이 사용되는 컨테이너 런타임으로는 Docker와 containerd가 있다.

Docker는 컨테이너화 기술의 초기부터 널리 쓰여왔지만, 최근에는 가벼운 구조와 쿠버네티스와의 높은 호환성 덕분에 containerd가 더 선호되고 있다.

---

Docker

컨테이너화 기술이 등장하기 전, Docker는 가장 먼저 널리 쓰인 컨테이너 도구였다.

rkt와 같은 다른 컨테이너 도구들도 있었지만, Docker는 사용자 경험을 간소화하여 컨테이너 작업을 매우 쉽게 만들어 주었고, 결과적으로 가장 지배적인 도구가 되었다.

 

1. Docker의 출현과 사용자 경험

• Docker는 초기 컨테이너화 기술의 대표주자로, rkt와 같은 다른 도구들에 비해 사용자 친화적인 경험을 제공한다.
• Docker 덕분에 컨테이너 작업은 간단해졌고, 이는 Docker의 지배적인 위치를 확립하는 데 기여했다.

2. Kubernetes와의 관계

• Docker를 오케스트레이션(Orchestration) 하기 위해 쿠버네티스가 등장했으며, 초기에는 Docker만을 지원했다.
• 그러나 쿠버네티스가 컨테이너 오케스트레이터(Orchestrator)로 인기를 끌면서, 사용자들은 Docker 외에도 다양한 컨테이너 런타임을 사용할 수 있기를 원했다.

3. CRI(Container Runtime Interface) 도입

• 쿠버네티스는 CRI라는 표준 인터페이스를 도입하여, 다양한 컨테이너 런타임을 지원할 수 있는 기반을 마련했다.
• CRI 덕분에 쿠버네티스는 OCI(Open Container Initiative) 표준을 준수하는 모든 런타임과 연동할 수 있게 되었다.

4. OCI 표준과 Docker

• OCI 표준은 이미지의 빌드 방식과 런타임 규격을 정의하는 이미지스펙(imagespec)을 포함하고 있다. 이를 통해 모든 컨테이너 런타임은 일관된 규격에 맞춰 쿠버네티스와 호환될 수 있다.
• Docker는 CRI가 나오기 이전에 만들어진 도구이며, CRI 표준을 지원하려고 만든 것이 아니기 때문에 CRI와 호환되지 않았다. 이를 위해 쿠버네티스는 임시방편으로 dockershim을 도입하여 Docker가 CRI 표준 없이도 동작하도록 했다.
• 그러나 이는 유지보수 측면에서 큰 부담이 되었고, 결과적으로 쿠버네티스는 v1.24 버전에서 dockershim을 제거하기로 결정하여 Docker 지원을 공식적으로 해제했다.
• 이후 Docker는 OCI 표준에서 imagespec을 따르며, Docker가 만든 모든 이미지는 이 표준에 맞춰 다양한 런타임과 호환될 수 있다.

 

containerd

Containerd는 Docker의 일부로 개발되었지만, 현재는 독립된 프로젝트로 운영되고 있다. Docker의 나머지 기능(예를 들어, Docker의 이미지 관리, 오케스트레이션, 네트워크 설정 등)이 필요 없다면, Docker를 설치하지 않고도 containerd만으로 컨테이너를 직접 실행할 수 있다.

 

1. containerd의 명령줄 도구

• 일반적으로 Docker CLI를 통해 컨테이너를 실행했다면, containerd에서는 ctr이라는 명령줄 도구를 사용해 작업할 수 있다.
• 하지만 ctr은 디버깅 용도로 제한된 기능만 제공하므로 사용자 친화적이지 않으며, 컨테이너 관리에 적합한 인터페이스도 아니다. 예를 들어, Redis 이미지를 가져오려면 ctr의 이미지 명령을 통해 수동으로 이미지 주소를 입력해야 하고, 실행 명령을 사용해 컨테이너를 직접 구동해야 한다.

2. ctr의 대안 - nerdctl

• ctr의 한계를 느낀 사용자들에게 더 나은 대안은 nerdctl이다.
• nerdctl은 명령줄 도구로 Docker와 매우 유사하며, 컨테이너를 관리하는 데 유용한 CLI 도구이다.
• Docker가 지원하는 대부분의 옵션을 지원하며, 별도로 컨테이너에 구현된 최신 기능에 액세스 할 수 있는 기능이 있다.

3. nerdctl의 추가 기능

• nerdctl은 느린 이미지 풀링을 지원하며, P2P 이미지 배포, 이미지 서명 및 확인, 쿠버네티스의 네임스페이스와 같은 Docker에서는 사용 불가한 다양한 기능도 제공한다.
• 이러한 점에서 nerdctl은 containerd 기반의 컨테이너 관리에 있어 더욱 유용한 도구가 될 수 있다.

 

crictl

crictl은 CRI 호환 컨테이너 런타임 및 rkt와 같은 다른 런타임과 연결하는 단일 인터페이스를 제공하는 명령줄 유틸리티이다. 이 도구는 주로 Kubernetes의 관점에서 작동하며, Kubernetes 커뮤니티에 의해 개발 및 관리되고 있다.

crictl은 Kubernetes와 CRI 호환 런타임 간의 상호작용을 간소화하는 강력한 도구이며, 개발자들에게 보다 나은 컨테이너 관리 경험을 제공한다.

 

1. 다양한 컨테이너 런타임 지원

• crictl은 다양한 컨테이너 런타임에 걸쳐 작동할 수 있도록 설계되었다. 이는 ctr이나 nerdctl과 달리, CRI를 지원하는 모든 컨테이너 런타임과 상호작용할 수 있는 점에서 유용하다.
• 이러한 기능 덕분에 개발자들은 여러 런타임을 사용할 수 있는 유연성을 갖게 된다.

2. 디버깅 용도로 최적화된 도구

• crictl은 주로 디버깅 도구로 사용된다.
• 컨테이너 생성이 가능하긴 하지만, 이 도구는 컨테이너 제작에 최적화되어 있지 않으며, 사용하기가 쉽지 않다.
• crictl은 kubelet과 잘 연동되어 있으며, kubelet은 특정 컨테이너나 Pod를 노드에서 사용 가능하도록 보장한다.
• 만약 crictl을 통해 생성한 컨테이너가 kubelet에 의해 인식되지 않는 경우, kubelet이 모르게 생성된 컨테이너나 Pod를 처리하기 때문에 이를 삭제할 수 있다.
  
  

3. 기본적인 컨테이너 작업 수행

• crictl 명령을 실행하면 기본적인 컨테이너 관련 작업을 수행할 수 있다.
• 예를 들어, 이미지를 끌어오기, 기존 이미지 목록 확인, 컨테이너 목록 열거 등의 작업을 지원하며, 이러한 기능은 Docker 명령과 매우 유사하다.
• 특히, crictl의 주요 차이점 중 하나는 Pod를 인식할 수 있다는 점이다. 명령을 실행하면 파드를 열거할 수 있으며, 이는 Docker에서는 지원되지 않는 기능이다.

4. 과거와 현재의 변화

• 과거에 Kubernetes와 작업하는 동안 많은 개발자들이 Docker를 사용해 컨테이너 문제 해결과 로그 확인을 했다. 하지만 이제는 crictl을 활용하여 이러한 작업을 수행하는 것이 더욱 효과적이다.
• crictl은 다양한 컨테이너 런타임과의 통합을 지원하며, Kubernetes 환경에서의 디버깅을 용이하게 만들어 준다.

 

containerd 관련 명령줄 유틸리티

1. ctr

• containerd와 함께 제공되며, 디버깅 목적의 제한적인 기능만을 지원한다.
• 일반적인 컨테이너 관리를 위해 사용되기보다는 주로 특정 상황에서 디버깅에 사용된다.

2. nerdctl

• containerd 커뮤니티에서 개발된 CLI로, Docker와 유사한 사용성을 제공한다.
• 일반적인 컨테이너 생성 및 관리 작업을 지원하며, Docker CLI 이상의 기능도 포함되어 있어 containerd 환경에서 유용하다.

3. crictl

• 쿠버네티스 커뮤니티에서 개발된 CLI로, CRI 호환 컨테이너 런타임과 상호 작용하는 데 사용된다.
• 단일 인터페이스를 통해 모든 CRI 호환 런타임과 통합적으로 작동하며, ctr과 유사하게 주로 디버깅 목적으로 사용된다.

---

Reference

https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests

https://kubernetes.io/ko/docs/home/

---