docker 와 cri-o 비교

소 개

Container 표준규격이 없을때 Container 포맷과 런타임의 사실상 표준은 Docker가 지배.
Google / Redhat / MS / IBM 등 Container 간의 이식성을 표준화 화기 위해 OCI(Open Container Initiative) 구성
k8s의 컨테이너 런타임 구성을 위해 CRI(Container Runtime Interface) 등장
RHEL 8버전이상, k8s 1.20 버전이상, Openstack 16버전이상, Openshift 4버전이상 , awx 18버전 이상에서 컨테이너 런타임을 podman으로 변경

컨테이너 런타임 레벨 종류

low-level runtime
1. 각 컨테이너별 cpu나 메모리 같은 리소스 양 제한하는 역활 (ex. runC, Container, Docker)
high-level runtime
1. 어플리케이션을 실행하고 모니터링을 위한 API제공
2. low-level 위에 실행되는 runtime (ex. containerd, docker, cri-o)

CRI-O 소개

cri-o는 컨테이너 실행만 가능하기 때문에 이미지 생성이나 관리를 하기 위해서는 추가 Component들이 필요함. (추가 Component정보는 아래 기술)
fork/exec 모델로 작동
인식가능한 파일시스템은 Overlayfs, devicemapper, btrfs 기반에서 가능하고, nfs,glusterfs,cephfs는 아직 stable하지 않음)
docker schema v1/2 모두 지원

CRI-O 컴포넌트 종류

podman(포드맨) : Container 실행을 위한 Tool
Buildah(빌다) : Container 이미지 생성
skopeo(스코피오) : 이미지 저장소 관리 Tool

crictl과 podman 차이

crictl은 cri프로토콜을 사용해서 cli 제공
podman은 daemon-less로 pod과 컨테이너를 관리하는 cli, docker와 동일한 cli기능 제공.
다만 cri-o와 직접 통신하지는 않기 때문에 cri-o에서 생성된 컨테이너를 볼수 없음.(libpod라는 podman의 컨테이너 관리 라이브러리 개발을 통해 개선할 예정)
Docker에서 실행 혹은 빌드된 컨테이너들을 podman으로 실행 가능.

프로세스 구동모델 소개

fork/exec 모델과 서버/클라이언트 모델의 동작 방식 비교
podman 과 Docker의 프로세스 실행 비교
프로세스 구동방식 비교

	Docker	Podman
구동 방식	Docker daemon 구동필요	Daemon-less (systemd 에서 podman 실행)
실행 권한	프로세스 구동시 root 권한 필요	root-less (1024 이하 포트 실행시에만 root권한 필요)
프로세스 실행 모델	서버/클라이언트	fork/exec

reference

Back to top