Docker, Containers & Confusions

Published in

FAUN — Developer Community 🐾

9 min readFeb 25, 2022

Evolution of Containers, Kubernetes and related technologies around it…

Context

There is a lot of confusion about following common questions around docker, containers, kubernetes and related technologies and tools. If you are also not clear about these questions then this article is for you. I have compiled all these understandings and tried to clarify as much as possible.

What is docker and container ?
Why was kubernetes created ?
Why did kubernetes use docker ?
What is dockershim ?
What is a container runtime ?
What is the difference between Docker, Containerd, CRI-O ?
What is RunC ?
What are OCI and CRI specifications ?
What are different container runtimes available ?
Why did kubernetes remove support for docker ?
What alternative container tools are available ?
What is the difference between docker and podman ?

Scope

I will start from basics and try to clarify confusions about above mentioned questions by going through chronological order of evolution for different technologies and tools around containers.

What is a Container ?

I will not go into details about containers vs Virtual machines as it’s out of scope for this article but I hope the picture below explains the underlying building blocks for each one.

Container is a standard unit of software that packages up code and all its dependencies

In Reality, There is not any native container that exists in the linux system but it’s the magic of the container engine which uses linux namespace and control groups to create a namespace isolated process with resource restriction which we call it container.

What is Docker ?

Docker was released in March 2013 a self-contained project with everything you needed to build and run containers.

Docker is a Product or tool to work with containers.

It’s a monolithic client/server application called Docker Engine. There is a centralized process called Docker Daemon running as root.

It is Responsible for

Building container images
Pushing container images to registry
Downloading container images
Launching container processes
Monitoring container processes
Managing network and storage
Exposing remote API
Running health checks
Responding to user requests
Log collection

Docker revolutionized container technologies such that people started calling it docker containers and docker images instead of just treating it as a tool to build container images and run container images until more and more containerization technologies started evolving.

Containers in Kubernetes

Docker had everything it required to build images and run containers except the way to orchestrate container deployment in the cloud.

In Dec 2013, Google developed a prototype to address this issue which they released as Kubernetes.

As of June 2014, Kubernetes was released as an open-source container orchestration system for automating deployment, scaling, and management of containerized applications.

Kubernetes needed specific components only to run containers but Docker was released before kubernetes as a big monolithic application doing a lot of stuff and did not have any way to just use specific component to run containers so kubernetes created a tool called dockershim to run containers using docker engine.

Kubernetes had two options for running containers which was not good at all in the long run but for time being chose the first option.

Keep writing and managing shims around docker for every docker release
Start interacting with Linux Kernel (namespace, cgroups) directly to create containers

Docker Components

As Kubernetes started gaining popularity, Docker announced Docker Swarm and Docker Compose for container orchestration in Dec 2014.

With the evolution of Kubernetes, a lot of container related technologies and tools were required to integrate with docker which made it difficult due to the monolithic architecture of docker.

As of June 2015, Docker introduced Docker Engine 1.11 which is a modularized docker application.

Docker (Docker Client)

Users create and run containers with Docker CLI commands

Docker Engine (Docker Server/Engine)

It runs as a docker daemon which listens for docker CLI commands and passes request/response to and from Containerd.

Containerd (High Level Container Runtime OR Container engine)

It manages the complete container lifecycle of its host system, from image transfer and storage to container execution and supervision to low-level storage to network attachments and uses runc to run containers.

RunC (Low Level Container Runtime OR OCI Runtime)

It is a lightweight, portable container runtime. It includes all of the plumbing code used by Docker to interact with system features related to containers to create and run containerized processes.

Shim

RunC starts container, hands over container to shim process before exiting. The Shim process can be seen as the parent process for containers and decouples the container from the runtime and avoids long-running runtime processes. It makes containers run independently of Containerd and RunC so Containerd and RunC can be restarted or upgraded without impacting running containers.

Open Container Initiative (OCI)

Docker released OCI specification with its modularized docker engine 1.11 in association with Linux foundation.

OCI provides specifications for container images and how to run containers. It also provides reference implementation of runtime spec called RunC which was donated by Docker.

Image specification defines the format of container images defined in Dockerfile or Containerfile.
Runtime specification defines input parameters to RunC to create containers.
The idea behind the OCI is that one can choose between different container runtimes which conforms to the OCI spec.

Container Runtimes

Container runtime is divided into two parts based on their responsibilities.

High Level Container Runtime (Container engine)

Creates network for containers
Manages local/persistent storage for containers
Prepares environment for containers
Fetches image for repository and creates bundles including rootfs and json config
Hands over container creation to low level container runtime RunC
Monitors containers created by RunC

Low Level Container Runtime (OCI Runtime)

Accepts rootfs and json config as parameter
Executes RunC to create container by interacting with Linux system utilities like namespace and control groups

Any OCI compliant runtime can create containers out of OCI compliant images.

Containerd and CRI-O are majorly used high level runtimes and RunC is the default low level container runtime which is OCI compliant.

Container Runtime Interface (CRI)

If you look at kubernetes architecture, Kubelet talks to container runtime to create/manage containers and container runtime (docker) was tightly coupled with kubelet so It was difficult for kubernetes to manually add support for different container runtimes going forward.

Kubernetes announcement “In the Kubernetes 1.5 release, we are proud to introduce the Container Runtime Interface (CRI) — a plugin interface which enables kubelet to use a wide variety of container runtimes, without the need to recompile”

The CRI was built on the top of OCI specs to enable support for interchangeable container runtimes within Kubernetes.

CRI defines the way that Kubernetes interacts with different container runtimes so you can use any runtime which implements CRI specification.

Container Echo System

This is how it looks if I put all these containerization technologies and tools together.

Kubernetes can use Containerd and CRI-O as CRI compatible container runtimes.
Kubernetes uses docker using dockershim which was the first integration with docker and is going to be deprecated soon.
Crictl is the client tool to debug pods and containers for CRI-O runtime.
Docker is a CLI client used to build and run containerized application images by calling docker engine.
Podman is another tool like docker which uses libpod as a container engine and runC as OCI runtime.
Containerd was revised to use the CRI plugin to implement CRI specs and it’s majorly used container runtime in kubernetes.
CRI-O is another implementation of CRI specification by openshift. It was specifically created from the ground up as a container runtime for Kubernetes.
RunC is the default OCI runtime implementation used by all high level container runtimes.
Kata-runtime is OCI compliant VM based runtime which runs containers in a lightweight VM.
gVisor is OCI compliant and runs each container in a tight security sandbox having an isolated kernel.

Kubernetes without Docker Runtime

Kubernetes deprecated docker runtime in its 1.20 release and announced it will remove docker runtime support latest by early 2022.

What it means is that it will no longer support docker container runtime using dockershim but still you can use any container runtime which supports OCI spec like Containerd or CRI-O. You can still use OCI formatted container images built using docker.

What is the impact ?

You need to change container runtime for kubernetes from Docker to Containerd or CRI-O.
If you are executing docker cli command to docker engine from kubernetes pods then it will not work going forward after kubernetes deprecates docker.
All existing workflow should not be impacted unless you are using docker CLI commands for building images from kubernetes pod.

Dockerless Container Tools

Why Dockerless ?

There have been some security concerns from the start for docker as docker daemon is running as a root. you can still run docker without root privileges with some limitations.

Docker announced to charge subscription fees for professional use of docker desktop.

Docker gave up to Kubernetes

Docker sold its enterprise business to Mirantis.
Docker decided to stop active development on docker swarm saying kubernetes will be the primary orchestration tool going forward.
Twitter, who originally developed Mesos, another container orchestration, moved to kubernetes.

What are docker alternatives tools ?

I hope the reasons mentioned including kubernetes deprecating docker are good enough to think about why it’s worth being aware of alternative tools available in the market irrespective of whether it can replace docker completely or not.

I have mentioned container tools alternative to docker with small description and pointers which you can go through to find more details.

Podman: Tool by Redhat for managing containers like docker.

Buildah: Tool by Redhat for managing container images like building, pushing, pulling images.

Crictl: Tool by Openshift, If you are using CRI-O as container runtime then you can use crictl to debug pods and containers.

Kaniko: Tool by Google for building container images from a Dockerfile, inside a container or Kubernetes cluster.

Out of all these, I found podman is the closest one to docker feature wise, It internally uses Buildah for building images. It runs and support all docker cli commands seamlessly just by aliasing docker=podman

Podman Vs Docker

I will not go into details of podman but mentioned below some differences with docker.

If you are heavily using docker-compose then you may not be able to move to podman otherwise it’s the best alternative available out today.

Conclusion

I have tried to cover different tools and technologies around containers to give better understanding without making you more confused. I hope things are clearer now. Thanks for reading !

References

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇