CRI-O was created specifically as a Kubernetes-only container runtime meaning it adheres to the Container Runtime Interface (CRI) and only provides features that are needed by Kubernetes to spin up new containers. This significantly reduces the complexity when compared to a full-featured daemon like dockerd (which spins up containers, fetches/push images, builds images, offers non-root capabilities, has an embedded P2P network, etc).
CRI-O is getting near the 1.0.0 release and it seems like the main focus is to replace Docker with it on the backend. We should investigate how to deploy CRI-O and stress test it.
Issues we have found while deploying Docker 1.12:
- Random errors with devicemapper while creating/destroying containers
- UDEV cookie leakage (hitting max semaphore limits)
- Excessive memory consumption (2GB+ RSS)
- Inability from Docker Inc. to accept PRs for fixes (for various reasons, the Docker provided in RHEL/CentOS/Fedora is a fork Red Hat had to create to apply those fixes)
In summary, CRI-O looks like the future standard for Kubernetes cluster. However, the project is still only officially supporting Docker 1.12 and rkt runtimes in producton so we should be careful and investigate this thoroughly.