k8s.io/utils/exec.CodeExitError was the only remaining direct use of
k8s.io/utils. Replace it with a local error type implementing the same
interface. The streaming server uses this interface to distinguish commands
terminating with a non-zero exit status from errors executing the
command, and to propagate the exit status to the client.
Add a FIXME to define this error contract in k8s.io/cri-streaming,
where it is consumed, instead of requiring runtime implementations
to implicitly match k8s.io/utils/exec.ExitError.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Populate the NRI container's Image field from the image identity recorded in the container metadata at creation, so plugins can identify and verify the container's image by digest. The following fields have been added:
- name: The image reference (ex. registry.k8s.io/pause:3.10)
- digest: Digest the image reference resolves to. Based on the image reference, it is a digest of one of:
- image index
- OCI: application/vnd.oci.image.index.v1+json
- Docker: application/vnd.docker.distribution.manifest.list.v2+json
- manifest
- OCI: application/vnd.oci.image.manifest.v1+json
- Docker: application/vnd.docker.distribution.manifest.v2+json
- config_digest: The image configuration digest
- OCI: application/vnd.oci.image.config.v1+json
- Docker: application/vnd.docker.container.image.v1+json
Signed-off-by: Eshaan Mathur <eshaanm25@gmail.com>
The direct use was two lines in `internal/cri/nri/nri_api_linux.go` -- constructing a `generate.Generator{Config: spec}` solely to satisfy the `nrigen.UnderlyingGenerator` interface defined in `containerd/nri`. Since that interface already exists, we just need an implementation. Add `spec_generator.go` in the same package, implementing `UnderlyingGenerator` directly on `*rspec.Spec` with no external dependencies beyond `runtime-spec`.
Assisted-By: "claude my eyes right out"
Signed-off-by: Tianon Gravi <tianon.gravi@docker.com>
The container_start_time_seconds metric was reporting nanoseconds
instead of Unix seconds. The CRI container status stores StartedAt
as nanoseconds (per the CRI API spec), but the metric name and help
text indicate seconds. Convert by dividing by time.Second.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
When collectContainerMetrics fails for a single container, the
goroutine was returning nil which exited the loop entirely. The
sandbox metrics, including pod-level network metrics and any
successfully collected container metrics, were never appended to
the response.
Replace return nil with continue so that individual container
failures only skip that container.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
Remove support for restoring checkpoint data during CreateContainer,
which was previously deprecated in v2.3.
Assisted-by: Antigravity
Signed-off-by: Samuel Karp <samuelkarp@google.com>
Drop internal/cri/seutil/seutil.go in favor of direct call to newly
introduced selinux.SetProcessKind.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The io.containerd.runhcs.v1 shim can scrub sensitive information from
logs it emits. Since v0.15.0-rc.2 this is done by default, but older
branches still require the option to be explicitly enabled. Explicitly
enable the scrubbing by default for the CRI configuration.
See also: https://github.com/microsoft/hcsshim/pull/2725
Google-Bug-Id: 481375460
Signed-off-by: Samuel Karp <samuelkarp@google.com>
Add server-streaming variants of CRI list RPCs (StreamContainers,
StreamPodSandboxes, StreamContainerStats, StreamPodSandboxStats,
StreamPodSandboxMetrics, StreamImages) that send results in batches
of 5000 items.
Signed-off-by: Ayato Tokubi <atokubi@redhat.com>
Add a new `enable_criu` configuration option under CRI plugin runtime
settings. When set to false, any checkpoint or restore request will fail
fast with an error indicating that CRIU support is disabled by
configuration. `enable_criu` currently defaults to true.
Add an integration test script to verify that setting `enable_criu` to
false in containerd configuration successfully disables checkpoint and
restore operations and fails fast.
Assisted-by: Antigravity
Signed-off-by: Samuel Karp <samuelkarp@google.com>
Perform an early validation check on both container checkpoint and
restore paths to fail-fast if the CRIU binary is missing or is older
than the minimum required version (3.16.0).
To support runtime-configured environments, the validation respects the
custom PATH from the shim manager environment if configured, skipping
any relative paths to avoid incorrect daemon-relative resolution. If not
configured, it falls back to a standard system PATH lookup. The check
result is cached using sync.Once to prevent redundant process spawning.
Assisted-by: Antigravity
Signed-off-by: Samuel Karp <samuelkarp@google.com>
Adds a nil guard to GetIPs on criPodSandbox before accessing promoted
struct fields on the embedded Sandbox pointer.
During pod sandbox teardown or race conditions during container exit
events, nriPodSandbox can return a criPodSandbox instance where the
embedded Sandbox pointer is nil.
Assisted-by: Antigravity
Signed-off-by: Chris Henzie <chrishenzie@gmail.com>
introspectRuntimeFeatures returned an error for any runtime type other
than io.containerd.runc.v2, so non-runc shims such as
containerd-shim-runsc-v1 never had their OCI features surfaced to the
CRI RuntimeHandlerFeatures, even though they implement the shim "-info"
command.
The runc-only guard worked around a nil-pointer panic when marshalling
nil runtime options. That case is already covered by the "if options !=
nil" check, making the guard redundant. Dropping it lets all runtimes be
introspected; shims that do not implement "-info" still fail gracefully
and are logged at debug level, so behavior for those is unchanged.
Guard against nil plugin info Extra, nil runtime Features, and nil
features.Linux before unmarshalling or evaluating CRI user namespace
support.
Signed-off-by: Amir Alavi <amiralavi7@gmail.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Address review feedback on the previous commit:
- Use MiB/s (binary, 1024^2) consistently. The divisor was already
1024*1024; the constant name (mbToByte) and the Help/comment text
mislabeled the unit.
- Keep image_pulling_throughput for backwards compatibility but mark
it Deprecated. Its prom.DefBuckets top out at 10 MiB/s, which
saturates almost immediately on modern hardware.
- Add image_pulling_throughput_mibps with buckets covering 0.1 MiB/s
through 4000 MiB/s (~31 Gbps), enough for 10G+ NICs. Above that,
disk write throughput becomes the bottleneck rather than the
network, so finer buckets aren't worth the cardinality.
- Both metrics observe the same value (fetched bytes / pull duration,
cached layers excluded; fully-cached pulls skipped). Only the
buckets and deprecation status differ.
Signed-off-by: Ahmet Alp Balkan <ahmet@linkedin.com>
The image_pulling_throughput histogram divided the full image size (all
layers plus config) by wall-clock pull duration. Layers already present
in the content store were counted in the numerator, so the reported
MB/s came out way higher than what was actually fetched. Fully-cached
pulls were the worst case: they "pulled" in milliseconds but reported
the full image size, showing up as huge outliers in the histogram.
Both pull paths (local client.Pull and the transfer service) already
maintain a totalBytesRead counter in pullRequestReporter for progress
and timeout checks. Cached blobs never trigger a fetch, so the counter
naturally excludes them. Plumb that value out of both helpers and use
it in place of image.Size(ctx). Fully-cached pulls (bytesPulled == 0)
are not observed, so they don't produce near-infinite samples.
Also updates the metric's Help text to say the denominator is the
end-to-end pull duration including layer extraction and snapshotter
unpack, not just network transfer.
Addresses #13244
Signed-off-by: Ahmet Alp Balkan <ahmet@linkedin.com>
Before this fix, CreateContainer would proceed even if the sandbox
had already stopped or was in an unknown state. This could result in
containers being created in an unusable sandbox, leading to confusing
errors downstream.
StartContainer already guards with the same check:
if sandbox.Status.Get().State != sandboxstore.StateReady {
return nil, fmt.Errorf("sandbox container %q is not running", ...)
}
Apply the identical guard in CreateContainer, immediately after the
sandbox state is known, so that callers receive a clear error instead
of a partial container object.
Fixes#13599
Signed-off-by: crawfordxx <crawfordxx@users.noreply.github.com>
CRImportCheckpoint built the combined environment (image env followed by
the CRI container env) into a local slice, then re-appended that slice to
imageConfig.Env, duplicating every image environment variable on the
restored container. Assign the combined slice directly instead.
Fixes#13611
Signed-off-by: Aman Raj <aman.yug@gmail.com>
The CRI checkpoint restore path unpacked checkpoint archive/OCI image content
directly into the container's persistent state directory and read files such as
container.log back from it with a symlink-following copy. Checkpoint content is
externally provided, so make restore more defensive about what it unpacks and
how it reads those files back.
Behavior changes:
- Only unpack regular files and directories from the checkpoint archive.
- Unpack checkpoint content into a dedicated <state>/ctrd-restore
subdirectory created fresh rather than into the state dir itself, so
checkpoint content cannot collide with containerd's own files (e.g.
the "status" blob). Restore and cleanup operate on that subdir;
cleanup is now a single RemoveAll of it.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Image config labels are copied onto the container by both the CRI
plugin (BuildLabels) and the client's WithImageConfigLabels option
used by `ctr run`. Labels in the containerd.io/* namespace are
interpreted by containerd itself and labels in the io.cri-containerd*
namespace are interpreted by the CRI plugin. An image config is not a
trusted source for labels in either namespace.
Skip labels in both reserved namespaces when copying labels from an
image config to a container, and warn about each label skipped: an
image that tries to set them may be attempting to alter containerd
behavior. Oversized image labels are already skipped this way by
the CRI plugin.
Labels set explicitly by clients, for example via `ctr run --label`
or in the CRI request, are unaffected.
Verified with the CRI plugin and with `ctr run` against an image
whose config carries labels like these: the labels are no longer
present on the created container and a warning is logged for each.
Assisted-by: Claude Code
Signed-off-by: Ben Cressey <ben@cressey.org>
Signed-off-by: Samuel Karp <samuelkarp@google.com>
Mike Brown