Docker is a runtime container image which contains source code + dependent libraries + OS base layer configuration. It provides portable container which can be deployed and run on any platform.
Docker is a first citizen for the Kubernetes containers. It’s a tool for developers to package all the deployable source code, dependencies and environment dependencies. DevOps can this as a tool to deploy on Kubernetes containers.
Docker: Build once and run anywhere!Portable to all OS bases. Please refer official docs of Kubernetes containers for detail information.
Docker is more suitable to package microservices and run on any private, public and hybrid Kubernetes clusters.
Dockerization: Process to convert any source code to Docker portable image.
What is OCI Image:
The Open Container Initiative is a standard authority to standardized docker as a runtime container. It’s industry standard to around container image formats and runtimes to run faster with ease.
What’s Docker Hub:
Docker Hub a docker image registry which is available as a SAAS service on cloud for public. They also offer paid private image repository. It’s provided easy way to start with to push and pull images from Kubernetes deployments.
It’s a logical small packaging of source code+dependencies+OS configuration which is required at run-time. Docker image can be run on container using runtime environment like Java runtime, Nginx etc.
Containers decouple applications from underlying host infrastructure. This makes deployment easier in different cloud or OS environments.
The container runtime is the software that is responsible for running containers.
Kubernetes supports several container runtimes: Docker Engine, Containerd container runtime with an emphasis on simplicity, robustness and portability, CRI-O, and any implementation of the Kubernetes CRI (Container Runtime Interface).
In containerd 1.1, the cri-containerd daemon is now refactored to be a containerd CRI plugin. The CRI plugin is built into containerd 1.1, and enabled by default. Unlike cri-containerd, the CRI plugin interacts with containerd through direct function calls. This new architecture makes the integration more stable and efficient, and eliminates another grpc hop in the stack. Users can now use Kubernetes with containerd 1.1 directly. The cri-containerd daemon is no longer needed.
“Does switching to containerd mean I can’t use Docker Engine anymore?” We hear this question a lot, the short answer is NO.
Docker Engine is built on top of containerd. The next release of Docker Community Edition (Docker CE) will use containerd version 1.1. Of course, it will have the CRI plugin built-in and enabled by default. This means users will have the option to continue using Docker Engine for other purposes typical for Docker users, while also being able to configure Kubernetes to use the underlying containerd that came with and is simultaneously being used by Docker Engine on the same node. See the architecture figure below showing the same containerd being used by Docker Engine and Kubelet: