The Sandbox API is an experimental API starting in containerd 1.7 that allows management of multiple containers via a "sandbox". The sandbox is runtime specific and could be anything from a set of containers sharing some resources (classic kubernetes pod), to containers running in a virtual machine (kata, windows, etc.). containerd is actively transitioning the CRI plugin to be entirely sandbox API based, but for testing a shim that tries to conform to this new API your current options are still to go through crictl, or use some local k8s solution. crictl is (as listed in the README here) not very friendly to users, and it would be much easier to be able to use nerdctl for sandbox aware shims.
Describe the solution you'd like
I think this is possible here by enlightening some of the existing commands to be sandbox aware, namely ps, create and run.
ps gets a --sandbox flag to list sandboxes known to containerd.
run gets --create-sandbox (or just --sandbox) and --sandbox-id flags to run a single container in a new sandbox, or subsequently run a container in an existing sandbox.
create similar to the above.
By virtue of the sandbox API still being experimental, the same would be true of this so I can see justification for waiting for it to be more stable, but given I think one of the pluses of this project in general is to showcase unique features of containerd, I think this idea has merit.
An additional point to really make it so crictl is not needed would be to add support for parsing k8s specs, and call into the CRI plugin in containerd, but that gets hairy and is mostly wishful thinking 😆
Additional context
I intend to play around with some of the ideas here in the coming weeks to see if its tenable
What is the problem you're trying to solve
The Sandbox API is an experimental API starting in containerd 1.7 that allows management of multiple containers via a "sandbox". The sandbox is runtime specific and could be anything from a set of containers sharing some resources (classic kubernetes pod), to containers running in a virtual machine (kata, windows, etc.). containerd is actively transitioning the CRI plugin to be entirely sandbox API based, but for testing a shim that tries to conform to this new API your current options are still to go through crictl, or use some local k8s solution. crictl is (as listed in the README here) not very friendly to users, and it would be much easier to be able to use nerdctl for sandbox aware shims.
Describe the solution you'd like
I think this is possible here by enlightening some of the existing commands to be sandbox aware, namely
ps
,create
andrun
.ps
gets a--sandbox
flag to list sandboxes known to containerd.run
gets--create-sandbox
(or just--sandbox
) and--sandbox-id
flags to run a single container in a new sandbox, or subsequently run a container in an existing sandbox.create
similar to the above.By virtue of the sandbox API still being experimental, the same would be true of this so I can see justification for waiting for it to be more stable, but given I think one of the pluses of this project in general is to showcase unique features of containerd, I think this idea has merit.
An additional point to really make it so crictl is not needed would be to add support for parsing k8s specs, and call into the CRI plugin in containerd, but that gets hairy and is mostly wishful thinking 😆
Additional context
I intend to play around with some of the ideas here in the coming weeks to see if its tenable