[kubernates] 001. The Story Before Kubernetes

From the Origins of Linux to the Evolution of Kubernetes Runtimes

The Evolution of OS

The Beginning : Originally, there was UNIX, but its high cost prevented it from being widely adopted by the public.
Birth of Linux (1991) : Linux emerged as a powerful alternative, eventually splitting into two major branches: Debian (Free) and Red Hat (Paid/Commercial).
Debian Branch: Debian evolved and led to the creation of Ubuntu, one of the most popular distros today.
Red Hat Branch : Red Hat followed a specific pipeline: Fedora (Free/Experimental) → Stabilization → RHEL (Red Hat Enterprise Linux / Paid) → CentOS (Free version of RHEL).
CentOS Crisis : With IBM’s acquisition of Red Hat, it was announced that CentOS support would end in 2024.
Development flow shifted: Fedora → CentOS Stream (Upstream) → Stabilization → RHEL. This meant CentOS was no longer a stable “clone” of RHEL but a testing ground.
New Alternatives: To fill the gap left by the original CentOS, community-driven “clones” of RHEL emerged: Rocky Linux and AlmaLinux.

Advances in Linux Isolation: As Linux isolation technologies matured, Namespaces were introduced to provide process-level isolation.
LXC (Linux Containers): The first true containers emerged, primarily focused on OS virtualization.
Rise of Docker: Docker arrived with a focus on application deployment, making container technology accessible and easy for everyone to use.
rkt (Rocket): Emerged as a competitor to Docker, with a heavy emphasis on enhanced security.
Consolidation & Strategy: rkt was part of CoreOS, which was later acquired by Red Hat. This led to the creation of Fedora CoreOS, though Red Hat began prioritizing CRI-O as its main runtime.
Docker Deprecation Issue: A major shift occurred when Kubernetes announced it would move away from Docker as its direct runtime.
Rise of the Alternatives: containerd and CRI-O (both CNCF-hosted projects) rapidly emerged as the primary alternatives to Docker.
Docker’s Survival Effort: After its enterprise business was acquired by Mirantis, Docker has been working hard to remain integrated and relevant within the Kubernetes ecosystem.

What is Orchestration? It is the process of deploying containerized applications by leveraging concentrated operational expertise (best practices).
Kubernetes (K8s) Having achieved the highest market share, it has become the de facto standard and is virtually the sole survivor in the orchestration war.

Pod Creation Request: A request to create a Pod is sent to the kube-apiserver.
Communication with Kubelet: The kube-apiserver passes the creation request to the kubelet on the target node.
Runtime Request: The kubelet requests the Container Runtime (such as Docker, rkt, etc.) to create the actual containers.
CRI (Container Runtime Interface): To communicate with various runtimes, the kubelet uses a standardized interface called CRI.
OCI & Low-level Runtime: OCI (Open Container Initiative) manages the common standards for these interfaces. For instance, runc is used to access the kernel level directly (evolving from LXC).
The Deprecation of dockershim: Kubernetes decided to remove dockershim due to its high bug rate and maintenance overhead. This led to the widespread rumor that “Docker is being dropped.”
The Return of cri-dockerd: To address this, Mirantis revived the functionality of dockershim by introducing cri-dockerd.
Shift to Plugins: The architecture has shifted toward using specialized plugins on the container runtime side (e.g., cri-plugin, cri-docker) instead of relying on a built-in CRI bridge within Kubernetes.