Local Kubernetes on Linux Using Minikube

This article explores how the Linux operating system handles local container orchestration through Minikube. It details the underlying architecture, explaining how Minikube utilizes Linux virtualization drivers, kernel isolation features like cgroups and namespaces, virtual networking interfaces, and local storage backends to run a fully functional, single-node Kubernetes cluster on a developer's workstation.

Driver Abstraction and Execution Environments

Minikube does not orchestrate containers directly; instead, it deploys a single-node Kubernetes cluster that handles workload management. On Linux, Minikube must determine how to isolate this cluster from the host system. It supports several execution drivers:

• Docker or Podman (Container-in-Container): The default and recommended approach. Minikube launches a single container on the Linux host that runs the entire Kubernetes control plane and node components (Kubelet, API Server, etcd, containerd).
• KVM2 (Kernel-based Virtual Machine): Uses the native Linux KVM hypervisor via libvirt. This spins up a dedicated virtual machine with its own Linux kernel, completely separating the cluster from the host kernel.
• None (Bare Metal): Runs Kubernetes components directly as system processes on the host Linux OS. This bypasses virtualization or container isolation, requiring root access and direct dependency management.

Linux Kernel Primitives: Namespaces and Cgroups

Once Minikube establishes its node environment, the host (or guest) Linux kernel enforces workload isolation. Container orchestration fundamentally relies on two native Linux kernel subsystems:

1. Namespaces: The Linux kernel creates isolated views of system resources for each pod. It provisions separate namespaces for processes (PID), networking (NET), mount points (MNT), inter-process communication (IPC), and user IDs (USER). This prevents containers managed by Minikube from interfering with one another or the host.
2. Control Groups (cgroups): The kernel regulates, accounts for, and isolates resource usage (CPU, memory, disk I/O, network bandwidth). When resource limits are applied to Kubernetes pods, Minikube communicates them to the container runtime, which writes corresponding limits into the Linux /sys/fs/cgroup directory.

Virtual Networking and Traffic Routing

Minikube configures local network orchestration using Linux's advanced networking stack. Depending on the chosen driver, Linux sets up virtual ethernet pairs (veth), bridge interfaces, and packet-filtering rules.

When using the Docker driver, traffic from the host to the cluster traverses a dedicated Docker network bridge. Inside the cluster, a Container Network Interface (CNI) plugin (such as Kindnet or Calico) creates virtual network interfaces for each scheduled pod. The Linux kernel's iptables or nftables frameworks process routing rules, port forwarding, and Network Address Translation (NAT), allowing services to expose ports locally and communicate across private pod subnets without external networking hardware.

Local Storage and Volume Allocation

Persistent storage in local orchestration requires mapping container volumes to the host's filesystem. Minikube provisions a default storage class powered by a local path provisioner.

When a Kubernetes PersistentVolumeClaim (PVC) is requested, the underlying Linux OS creates a dedicated directory—typically under /tmp/hostpath_pv or /var within the Minikube environment. The Linux Virtual File System (VFS) then mounts these host directories directly into the target containers using bind mounts (mount --bind). This mechanism ensures data persistence across container restarts while maintaining fast, native disk I/O read and write speeds.