Hairizuan Noorazman
Life is too exciting to just keep still!
Practical implementation notes, experiments, and lessons learned from building and operating software.
Recent
Introducing CNI to a Multikernel Linux Runtime
··4137 words·20 mins
My first Multikernel container networking experiment built a static /30 link for each child. The primary owned a TUN interface, routes, NAT, and firewall rules; mk-agent owned another TUN inside the child; and an authenticated packet pump transported IP frames between them.
The Isolation Boundary of Multikernel Linux Containers
··1322 words·7 mins
The phrase “one kernel per container” sounds like a stronger isolation claim than “one process namespace per container.” In a Multikernel Linux runtime, each child really does have its own kernel, process table, boot ID, CPUs, memory description, and root filesystem. That still does not make it equivalent to a virtual machine.
Designing a Runtime Protocol Across Multikernel Linux Kernels
··1955 words·10 mins
The components in my Multikernel container runtime do not share one ordinary process hierarchy. The containerd shim and mkruntimed run in the primary Linux system, while mk-agent and the workload run under a child kernel. Calls that would normally be local runtime operations therefore become protocol messages.
Running OCI Processes Inside a Multikernel Linux Child
··1541 words·8 mins
In Turning Container Images into Multikernel Linux Roots, I described how an unpacked image becomes a private root for a child kernel. That gets the files into the right place, but files are not yet a running container. Something inside the child still has to interpret the OCI process configuration, establish its safety boundaries, start the executable, and translate later exec, signal, terminal, and wait requests.
Recovering Multikernel Runtime State After a Crash
··1357 words·7 mins
My earlier walkthrough of a Multikernel container from the primary Linux system followed a successful task from containerd through a shim, mkruntimed, Kerf, and finally a child kernel. The normal path is only half of a runtime, though. The harder question is what to do when one of those steps succeeds but the caller disappears before learning the result.
Anatomy of a Multikernel Container from the Primary Linux Host
··3145 words·15 mins
My earlier posts looked at individual parts of the Multikernel container path: building image-derived roots, providing mediated networking, and implementing a containerd Runtime v2 shim. This post puts those pieces together from one particular viewpoint: what happens on the primary Linux system when containerd creates a container whose process will run under another kernel?
A containerd Runtime v2 Shim for Multikernel Linux
··1275 words·6 mins
My first Multikernel Linux runtime used a custom command-line client to create a child and ask an agent inside it to run a process. That proved the control and process layers, but it did not make Multikernel usable by existing container clients.
Networking Containers in Multikernel Linux Child Kernels
··1134 words·6 mins
Giving a Multikernel Linux child network access is not as simple as moving the host’s network interface into it. On Google Compute Engine (GCE), the virtual NIC is also the primary kernel’s route to SSH, metadata, and the guest agent. Assigning that device or its shared controller to a child would put management access at risk.
Turning Container Images into Multikernel Linux Roots
··2663 words·13 mins
My first Multikernel Linux experiment on GCE started child kernels with roots that I built ahead of time. That was useful for proving that the kernels could boot, but it was not how a container runtime should consume an image. A runtime should accept the root filesystem that containerd has already prepared and should not become another registry client, layer downloader, or snapshotter.
Persistent ext4 Roots for Multikernel Linux on Google Compute Engine
··1340 words·7 mins
My first Multikernel Linux experiment on Google Compute Engine (GCE) showed that one VM could run a primary kernel and multiple child kernels at the same time. The children could use different kernel binaries, but their root filesystems were either minimal initramfs images or DAXFS. That left an important question unanswered: could a child kernel have a persistent, read-write ext4 root filesystem?