입문

며칠 전 다음의 Qiita 기사를 썼는데 공개된 후에 컨테이너 운행 시간에 대한 이야기가 전혀 나오지 않았기 때문에 이번에는 컨테이너 운행 시간의 동향을 정리하려고 합니다.
Docker Kubernetes 주변 동향 정리를 해봤어요.
또 최근 containerd, cri-o, gVisor 등의 이름을 듣는 경우가 늘었지만 각자 다른 점을 이해하지 못하기 때문에 자기 학습의 목적으로 인터넷상의 정보 등을 바탕으로 정리하고 싶습니다.

컨테이너 규격 표준

조직 컨테이너가 실행되기 전에 OCI(Open Container Initiative) 및 CRI(Container Runtime Interface)를 요약하십시오.

OCI(Open Container Initiative)

Open Container Initiative(OCI)는 Linux Foundation 산하의 개원 단체로 2015년 6월 Docker사 등 여러 기업이 설립하여 컨테이너 운행 시와 이미지를 위한 개방적인 업계 표준을 제정하고자 한다.
2018년 7월의 구성원은 다음과 같다. 아마존, 마이크로소프트, 구글, 페이스북 등 거의 모든 대형 기술 기업이 참가했다.

※ 참조: https://www.opencontainers.org/about/members
2017년 7월에는'OCI v1.0'을 제정하여 용기가 실행될 때의 표준 규격인'Runtime Specification'과 용기 이미지의 표준 규격인'Image Format Specification'을 발표했다.
그리고 2018년 4월에 우리는 용기 이미지 배포 표준 규격을 제정하는'배포 규범'프로젝트에 착수했다.
※ 참고: https://www.opencontainers.org/blog/2018/04/09/distribution-spec-is-here

CRI(Container Runtime Interface)

CRI(Container Runtime Interface)는 2016년 12월 Kubernetes 1.5로부터α게시된kubelet과 용기가 실행될 때 통신하는 I/F입니다.
CRI의 개요는 다음 그림과 같습니다.

※ 참조: https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/
CRI가 규정하기 전에 용기가 실행될 때 쿠벨렛의 내부 구조를 알아야 하며, 새로운 용기가 실행될 때 쿠베르넷에 병합하는 것은 매우 장애가 된다.그러나 CRI의 규정 때문에 Kubernetes는 Docker 이외의 컨테이너가 실행될 때 더 쉽게 끼워 넣을 수 있습니다.
또한 OCI와 CRI의 관계는 다음 그림과 같습니다.
CRI는 쿠블렛과 고급 용기가 실행될 때의 통신 I/F를 규정하고, OCI(Runtime Specification v1.0)는 고급 용기가 실행될 때와 저급 용기가 실행될 때의 통신 I/F를 규정한다.

갑자기 높은 등급과 낮은 등급의 용기가 운행되면 혼란을 초래할 수 있지만, 높은 등급의 용기가 운행할 때는 CRI가 규정한 I/F를 통해kubelet이 호칭하는 용기에서 운행할 때, 낮은 등급의 용기가 운행할 때는 OCI가 규정한 I/F 호칭의 용기를 통해 운행할 때아시면 괜찮을 거예요.

컨테이너 런타임 유형

containerd

컨테이너는 원래 Docker 내부에서 사용되던 Docker사가 개발한 것으로 2017년 3월 클라우드 네이티브 컴퓨팅 재단(CNCF)에 기부한 컨테이너 운행 시간이다.
2018년 5월에'containerd v1.1'이 정식으로 발표되었고 CRI에 로컬 서비스를 제공할 것이라고 발표했다.
또한 용기가 실행될 때 Docker를 사용할 때의 내부 구조는 다음과 같다. Docker는 CRI를 지원하지 않기 때문에dockershim이라는 다리를 통해 통신한다.

그 다음으로 2017년 12월에 정식으로 발표된'containerd v1.0'에서 CRI-containerd를 연결했지만 CRI는 현지인에게 대응할 수 없었다.

이에 비해 "containerd v1.1"은 CRI 로컬에 대응하여 Kubernetes (kubelet) 에서containerd를 직접 조작할 수 있습니다.따라서 CPU 메모리 활용도가 감소합니다.
※ 참조: https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

rkt

kt는 코어OS사(2018년 1월 레드햇이 인수)가 도커로 운행할 때의 대체 개발로 2017년 3월 클라우드 네이티브 컴퓨팅 재단(CNCF)에 기부한 컨테이너 운행 때다.
Docker에 비해 간단한 프로세스 모델과 Pod 등을 로컬로 처리할 수 있는 것이 특징이다.
Docker와 rkt의 공정 모델은 다음과 같습니다.

※ 참조: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html

cri-o

cri-o는 Kubernetes Incubator Project로 개발한 것으로 CRI와 OCI 두 가지 기준에 부합되는 경형 컨테이너로 운행할 때 2017년 10월 v1.0을 정식으로 발표했다.
공급업체는 Red Hat, Intel, IBM 등을 포함하지만 모두 지역 사회가 주도하는 개원 프로젝트로 개발되었다.
cri-o의 체계 구조는 다음과 같다.
CRI에 부합되기 때문에kubelet과 직접 합작하고 OCI와도 부합되기 때문에Low-Level의 용기로 운행할 때runC와 합작합니다.

※ 참조: http://cri-o.io/

runC

runC는 OCI를 실현하는 저급 용기가 실행될 때입니다.상술한containerd와cri-o에 사용됩니다.

gVisor

gVisor는 구글이 개발하고 오픈한 준가상화 구조로 안전성을 높인 컨테이너 운행 시간을 공개했다.
전통적인 용기가 운행할 때 용기 간에 운영체제 핵을 공유하기 때문에 용기에서 운영체제를 직접 호출하는 시스템을 통해 호출하면 안전 문제를 일으키기 쉽다.
이에 비해 아래 그림에서 보듯이 자신의 gVisor층을 제공함으로써 모래상자화 용기를 실현했다.

※ 참조: https://github.com/google/gvisor
또한 gVisor도 OCI에 부합되기 때문에runC로 교환할 수 있고cri-o조합과Kubernetes와 합작할 수 있으나 2018년 7월까지 생산환경에서 사용하는 것을 추천하지 않습니다.
※ 참고: https://github.com/google/gvisor

Kata Containers

OpenStack Foundation에서 개발한 것으로 용기 간에 핵을 공유하지 않고 분리 수준을 높이는 용기 운행 시간으로 2018년 5월 v1.0을 정식으로 발표했다.
나타나는 배경은 gVisor와 마찬가지로 전통적인 용기가 실행될 때의 안전성을 높이기 위해 개발된 것이다.
Kata Containers의 아키텍처는 다음과 같습니다.
그것은 운영체제의 핵을 공유하지 않고 경량급 관리자를 사용하여 용기의 격리 단계를 높여 용기의 안전성을 높인다.

※ 참조: https://katacontainers.io/media/uploads/katacontainers/uploads/katacontainers/kata-containers-1pager.pdf
OCI와 CRI 표준에도 부합하기 때문에 전통적인 용기가 실행될 때와 마찬가지로 사용할 수 있다.

요약 (느낌)

본 보도는 컨테이너가 운행할 때의 동향을 정리하였다.
지난번 Docker Kubernetes 주변 동향 정리를 해봤어요. 보도와 마찬가지로 이번 보도도 만들어서 솔직히 힘들었다.
관리 도구의 경우 Kubernetes는 기본적으로 수치 표준이지만 OCI·CRI라는 표준 표준의 제정으로 컨테이너 운행 시간에는 여러 가지 움직임이 있는 것 같다.