Skip to main content

docker 와 cri-o 비교

소 개

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

컨테이너 런타임 레벨 종류

  1. low-level runtime
    1. 각 컨테이너별 cpu나 메모리 같은 리소스 양 제한하는 역활 (ex. runC, Container, Docker)

  2. high-level runtime

    1. 어플리케이션을 실행하고 모니터링을 위한 API제공
    2. low-level 위에 실행되는 runtime (ex. containerd, docker, cri-o)

CRI-O 소개

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

CRI-O 컴포넌트 종류

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

crictl과 podman 차이

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

프로세스 구동모델 소개

  1. fork/exec 모델과 서버/클라이언트 모델의 동작 방식 비교image-20220421233815-1.png
  2. podman 과 Docker의 프로세스 실행 비교image-20220421233815-2.png

  3. 프로세스 구동방식 비교


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


reference

 

Back to top