Projects · Dockerios
DockerIOS, the next generation
Taking every constraint found in the Docker-OSX teardown and answering it with software that already exists and is already supported. KubeVirt, CDI, CSI cloning, CPU pinning, VFIO passthrough, and an honest list of the seams that stay open.
DockerIOS, the next generation
The teardown ended with a table of things Docker-OSX does not do, and I was careful to say that none of them were defects. They were scope. One machine on your laptop does not need golden images, identity records, or graceful shutdown.
A fleet does. So this section is where the scope changes.
The primitives on this page are the floor for DockerIOS, the KubeVirt-on-x86 operator in section 03. They are not the floor for MacRack. MacRack leaves this stack behind on purpose, because the licence and the Intel sunset sit in the "no answer exists" column here, and a commercial product cannot be built on a seam I already named as unmovable.
If you want the operator that respects Apple's SLA, skip to section 04.
Everything proposed here has to already exist and already be supported. No research projects, no patches I would have to maintain, no "someone should write a driver for this".
Where a gap genuinely has no answer today, I say so and design around it rather than pretending a solution exists. There is a whole section for those, near the end, and it is the most useful part of the page.
What is in here
| Page | What it covers |
|---|---|
| Rebuilding on supported primitives | Every constraint from the teardown, answered with an existing supported mechanism. The substrate decision, storage, networking, CPU, GPU, lifecycle, identity, and observability, plus the seams that stay open and what I would build first |
There is a fork in the road right at the start, and almost everything else follows from it: do you run QEMU yourself inside a privileged pod, the way the Docker-OSX Helm chart does, or do you let something else own the virtual machine lifecycle and configure it declaratively.
I take the second path, and the first document explains why in detail. The short version is that the first option means writing a hypervisor controller, and that job is already done.