CRI-O (Container Runtime Interface + OCI[Open Container Initiative])

1) CRI-O의 등장? 왜 나타났을까? 이미 대표적인 Container Runtime인 Docker가 있는데..

사실 잘못 알고 있는 점이 있는데, 도커는 Kubernetes를 위해 등장한 기술은 아니다. 컨테이너 런타임이라는 기술을 만든것은 일종의 규격을 만들기 위할 뿐 컨테이너가 활용되는 다양한 오케스트레이션 플랫폼을 위해 도커는 존재한다.

따라서 도커가 Kubernetes를 지원하는 것이 아니라 Kubernetes가 도커를 지원하는 방식이다.

이는 최근 Kubernetes가 컨테이너 오케스트레이션 플랫폼의 대부분을 점유함으로써 도커에서는 무상으로 사용하는 것에 대한 문제를 삼게 되었다. Docker-CE가 존재하지만, 이 마저도 Docker에서는 지원 중단을 선언했다.

이로 인해 구글은 CRI-O를 개발했고 서서히 CRI-O로의 전환을 시도하고 있다.

 

2) Docker의 단점은?

- Docker는 너무 무겁다.

- DockerEE는 subscription 구매를 해야 한다.

- Docker Runtime의 불필요한 기능이 포함된 무거운 모듈

- 버그 픽스의 시간 소요 (Kubernetes에서 버그 픽스를 해야 함)

 

3) CRI-O는 무엇인가요?

- Docker -> CRI-O(Runtime), Podman(API)

- CRI-O는 구글에서 최초 개발

- PodMan은 Docker처럼 클러스터로 관리할 수 있음

- CRI-O는 Single node관리

- CRI-O는 Kubernetes를 위해 개발됨 (Only Kubernetes)

 

4) OCI 구성요소

- CRI-O (Runtime)

- PODMAN (API)

- BuildAH (이미지 빌드)

- Skepo (이미지 서버)