Are you old enough to remember diskless terminals? After a quick look at this, it sounded to me like a more modern, "DevOps-ified" version of diskless terminals/workstations that is 1) more difficult to maintain, 2) lacking any type of persistence (for thing like, you know, $HOME), and 3) supports only a single user whose account must be baked into the container.

As for how it works, well, it looks like it's just your everyday, run-of-the-mill PXE booting, AFAICT.

----

(FWIW, if you know how PXE booting works, there's no reason to read any further; the rest of this wall of text is just my poor, long-winded attempt at a "simplified" explanation of how it works.)

Basically: on startup, the host sends out a message to everyone else on the network saying, "Attention, please! I'm looking for a DHCP server that has an IP address I can use for a little while -- oh, and I also need a kernel to boot. Can anyone please tell me the filename of the kernel I should boot, the IP address of the TFTP server I can download it from, and what IP address I should use to communicate with that TFTP server!?" (Technically, it also asks for a subnet mask, the IP address of a default router, the IP address of a DNS server or two, and a few other things, but those are the ones most relevant to this explanation.)

Assuming there is a DHCP server on the same network -- or another host whose job it is to listen for such requests and pass them along to such a DHCP server -- it will receive a response with the information it asked for. (The computer wants to make sure it heard everything correctly so it asks for "confirmation" from DHCP server -- or its delegate.)

[In case it wasn't clear, I was trying to explain (simply) the four-way DHCP transaction (a.k.a. "DORA".)

Having all of the information it needs, the computer then sends out a message, via TFTP, to the IP address it was told, saying, "Please send me the file named '/boot/kernel'" and (since that's its job) the TFTP server does so. (Note: In some cases, the client that's trying to boot may ask for a few files instead of just one, or it might ask for the file(s) via a different method, such as HTTP.)

Very shortly -- well, maybe not THAT shortly, TFTP can be slooooooow! -- this trying-to-boot-itself-up computer will have most of it what it needs to start the booting process. At this point, that's usually a kernel and an "initial ramdisk" that contains 1) the drivers that it needs (or may possibly need) in order to get up and running.

Now, remember that this computer (or whatever it is) is "diskless". It doesn't have a hard drive of its own that it can mount its root filesystem ("/") from. Now what? Well, lucky for us, some folks at a company named Sun recently (well, "recently-ish"... four decades or so ago, perhaps) came up with a protocol that they called the Network File System ("NFS"). This particular trying-to-boot-itself-up computer doesn't NEED a hard drive of its own. As long as someone that's close by -- let's call them an "NFS server" -- has a copy of the files that the "boot client" needs and is willing to share them, well, that'll do. (With the much larger amounts of RAM that computers have nowadays, it's also possible for the client to download a specially-prepared-for-exactly-this-purpose file that contains an entire (read-only, of course) filesystem with everything it will need, keep that in its RAM, and use it as its root filesystem (this is how many (most?) "live CDs" work nowadays).

(I probably should have just pointed you towards the "Network Boot and Exotic Root HOWTO" [0] instead -- even though the last revision was almost 17 years ago, the basic premise really isn't much different today.)

[0]: https://www.tldp.org/HOWTO/Network-boot-HOWTO/index.html