Engine - Focused on packaging application with its dependencies. - Smart packaging of application in layered approach enabled sharing between images. - Efficiently using layered image with AUFS for creating containers. - End users were developers and QA. - Focused on - Application packaging. - Recreating and sharing of application on different machines/environment. - Saving time and space for dev/QA environment.
the OCI runtime • Used by Docker since 1.11 in 2016 as a container runtime • Relaunched in December 2016 with new scope • Docker now using 0.2.x branch • 1.0 master branch is where the new work is taking place Entirely new scope, and donated to CNCF
complexities from Docker - Smaller component with narrower focus - GRPC interfaces for all services - Long term interface stability - Supports OCI images & Runtimes - Supports Multitenancy (Namespaces) - Portable - Limited Scope - No Networking - No Volumes - No Build - No logging • Containerd Services ◦ Content ◦ Images ◦ Rootfs ◦ Execution ◦ Shim No!, Containerd is an evolution, not a rewrite
to contribute - Easy to maintain - Designed as per OCI specs. - Acceptance of standards for containers by community. - No Lockin. - Plugin architecture - Easy to extend. - Limited scope - Only features, which has consensus. - No bloating due unwanted features. - Multitenancy (Namespaces) - Run multiple orchestrator on same host, without interference.
/ Kubernetes - No, Probably you can continue using same. The change will happen implicitly and you may not realize it. - Cloud Providers - Yes, build your container service directly with integrating containerd. - Use docker, but don’t use its high level features. - No, If you have no issues with those high level features. - Probably Yes. If you know what you want exactly you want, and ready to develop on top of Containerd. - Running custom containers along with docker containers - Yes, using namespace feature, running custom containers is safe and easy.