This change adds support for CDI devices to the ctr --device flag.
If a fully-qualified CDI device name is specified, this is injected
into the OCI specification before creating the container.
Note that the CDI specifications and the devices that they represent
are local and mirror the behaviour of linux devices in the ctr command.
Signed-off-by: Evan Lezar <elezar@nvidia.com>
This flag allows cpuset.mems to be specified when running a container. If
provided, the container will use only the defined memory nodes.
Signed-off-by: Peteris Rudzusiks <rye@stripe.com>
This flag allows cpuset.cpus to be specified when starting a container. If
provided, the container will use only the defined CPU cores.
Signed-off-by: Peteris Rudzusiks <rye@stripe.com>
Go 1.18 and up now provides a strings.Cut() which is better suited for
splitting key/value pairs (and similar constructs), and performs better:
```go
func BenchmarkSplit(b *testing.B) {
b.ReportAllocs()
data := []string{"12hello=world", "12hello=", "12=hello", "12hello"}
for i := 0; i < b.N; i++ {
for _, s := range data {
_ = strings.SplitN(s, "=", 2)[0]
}
}
}
func BenchmarkCut(b *testing.B) {
b.ReportAllocs()
data := []string{"12hello=world", "12hello=", "12=hello", "12hello"}
for i := 0; i < b.N; i++ {
for _, s := range data {
_, _, _ = strings.Cut(s, "=")
}
}
}
```
BenchmarkSplit
BenchmarkSplit-10 8244206 128.0 ns/op 128 B/op 4 allocs/op
BenchmarkCut
BenchmarkCut-10 54411998 21.80 ns/op 0 B/op 0 allocs/op
While looking at occurrences of `strings.Split()`, I also updated some for alternatives,
or added some constraints; for cases where an specific number of items is expected, I used `strings.SplitN()`
with a suitable limit. This prevents (theoretical) unlimited splits.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
For Kata Containers, starting a privileged container will fail
if passing all host devices to container due to the permission
issue, like the `privileged_without_host_devices` for CRI service,
add a `privileged-without-host-devices` to `ctr run` command will
disable passing all host devices to containers.
Signed-off-by: bin liu <liubin0329@gmail.com>
Added new runc shim binary in integration testing.
The shim is named by io.containerd.runc-fp.v1, which allows us to use
additional OCI annotation `io.containerd.runtime.v2.shim.failpoint.*` to
setup shim task API's failpoint. Since the shim can be shared with
multiple container, like what kubernetes pod does, the failpoint will be
initialized during setup the shim server. So, the following the
container's OCI failpoint's annotation will not work.
This commit also updates the ctr tool that we can use `--annotation` to
specify annotations when run container. For example:
```bash
➜ ctr run -d --runtime runc-fp.v1 \
--annotation "io.containerd.runtime.v2.shim.failpoint.Kill=1*error(sorry)" \
docker.io/library/alpine:latest testing sleep 1d
➜ ctr t ls
TASK PID STATUS
testing 147304 RUNNING
➜ ctr t kill -s SIGKILL testing
ctr: sorry: unknown
➜ ctr t kill -s SIGKILL testing
➜ sudo ctr t ls
TASK PID STATUS
testing 147304 STOPPED
```
The runc-fp.v1 shim is based on core runc.v2. We can use it to inject
failpoint during testing complicated or big transcation API, like
kubernetes PodRunPodsandbox.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
This patch adds support for a container annotation and two separate
pod annotations for controlling the blockio class of containers.
The container annotation can be used by a CRI client:
"io.kubernetes.cri.blockio-class"
Pod annotations specify the blockio class in the K8s pod spec level:
"blockio.resources.beta.kubernetes.io/pod"
(pod-wide default for all containers within)
"blockio.resources.beta.kubernetes.io/container.<container_name>"
(container-specific overrides)
Correspondingly, this patch adds support for --blockio-class and
--blockio-config-file to ctr, too.
This implementation follows the resource class annotation pattern
introduced in RDT and merged in commit 893701220.
Signed-off-by: Antti Kervinen <antti.kervinen@intel.com>
when user executes ctr run --cni to start a container,it will call cni plugin to create network .But when user kills it,the network won’t be removed. if we run a container with same namespace and name again will trigger a bug. we should remove the network when user kills task if it enables cni plugin.
Fix:#6604
Signed-off-by: SongJiang Han <songjiang.dark@gmail.com>
add '--snapshotter-labels' in ctr run and ctr c create
which can pass labels to snappshotter on preparing new
snapshot.
Pass command label to snapshotter can help it determine
which kind of writable snapshots should be provide.
For some snapshotter, such as overlaybd:
( https://github.com/alibaba/accelerated-container-image ),
it can provide 2 kind of writable snapshot (overlayfs dir or
blockdevice) by command label values.
Signed-off-by: Yifan Yuan <tuji.yyf@alibaba-inc.com>
This enables cases where devices exist in a subdirectory of /dev,
particularly where those device names are not portable across machines,
which makes it problematic to specify from a runtime such as cri.
Added this to `ctr` as well so I could test that the code at least
works.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This adds linux cni support to `ctr run` via a `--cni` flag. This uses the
default configuration for CNI on `ctr` to configure the network namespace for a
container.
Signed-off-by: Michael Crosby <michael@thepasture.io>
If runtime is not runc, it doesn't make sense to send runc Options
as container create options, which will confuse other runtimes and
it actually causes kata shimv2 to fail to unmarshal the requset.
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
* --uidmap support for one remapping
* --gidmap support for one remapping
* create IoUid and IoGid options for getNewTaskOpts
Signed-off-by: Jie Hao Liao <liaojh1998@gmail.com>
