ADR-005 Sandbox means the node runtime behind CRI

"Sandbox" in the description of this project means the container runtime on every worker node: the program the kubelet drives through the Container Runtime Interface, whose central object is literally called the pod sandbox. Since Kubernetes 1.24 removed dockershim, the kubelet speaks only CRI, and what clusters run there today is containerd or CRI-O.

The goal is not a general container engine. No image building, no command line for people, no compose, nothing the kubelet does not call. Only the CRI runtime and image services, as the kubelet uses them, made as lean as they can be because that narrow job is all they do.

It is a later phase and is not part of the first demonstration. It will be a separate binary in this repository, since it runs on every node while the store runs only beside the API server.

What it will need, which is why it waits:

• Linux namespaces, cgroup v2 and mounts. The standard library wraps none of these, so they go behind one unsafe syscall boundary, as QuantyDB's reactor does (its ADR-023).
• Image pulls: HTTPS to registries, so QuantyCore's TLS client first, plus gzip decompression, tar extraction and SHA-256 digest checks.
• gRPC as a server on the node, which QuantyCore provides by then anyway (its ADR-004).
• Pod networking through the standard CNI plugins, which are separate executables and are invoked, not rewritten.

"Most efficient" is a claim under ADR-002: pod start latency and memory per pod against containerd and runc, measured on the same machine, or it is not said. Stronger isolation through micro VMs is a separate product idea and stays out of this record.