The CRI plugin is Stackie’s separately buildable Kubernetes runtime
integration. It serves the official CRI v1 RuntimeService and ImageService
used by upstream kubelet, while the Kubernetes plugin separately provisions
and operates K3s.
In text: kubelet calls the CRI plugin. The plugin delegates image
classification to Mocker compatibility, sends only transport-neutral
evidence to Stackied, and returns the protocol-defined CRI result. It does
not translate Docker or Compose fields and never provides an alternate CRI
fallback.
Mocker’s mocker.images metadata remains the sole image-to-block authority.
Catalog-mapped images keep their Stackie block identity; images required by
K3s system pods and other unmatched workloads remain verified OCI images.
A future Mocker plugin will provide the same narrow compatibility capability
to this plugin without moving Docker semantics into CRI or Bridge.
Supported contract
Surface
Support
Protocol
Official CRI v1 from k8s.io/cri-api v0.36.2
Transport
Host-leased Unix-domain listener
Platforms
Linux amd64 and Linux arm64
Runtime/Image RPCs
Every applicable v1 RPC has a maintained implementation and traceability row
Checkpointing
Returns the protocol-defined unsupported result only when the selected runtime lacks checkpoint support
Validation
100% applicable CRI v1 traceability and 100% passage of unmodified upstream critest v1.36.0 are release requirements
The vendored upstream protocol is digest-verified before Tonic generates the
Rust service surface. There is no handwritten partial protocol, hidden
legacy fallback, skipped applicable RPC, or patched conformance suite.
Runtime behavior
Pod sandboxes, containers, images, filesystems, resources, status, stats,
metrics, runtime configuration, and container events use CRI-native
request and response semantics.
Image pulls verify registry descriptors, manifests, configuration, layer
digests, safe archive paths, and final immutable content identity.
ExecSync is bounded and returns captured output and exit status.
Interactive exec, attach, and port-forward sessions use short-lived,
single-use tokens rather than embedding local authority in URLs.
CRI log files preserve stdout/stderr stream identity, timestamps, partial
records, rotation, and reopen behavior expected by kubelet.
Container events are durably ordered and replayable. Restart does not
silently discard known sandboxes, containers, images, or pending events.
Garbage collection is bounded and respects active references, leases,
snapshots, mounted filesystems, and persistent-volume ownership.
Availability states
CRI uses the same generic package and subscription mechanisms as the
Kubernetes plugin. Build inclusion, administrator enablement, subscription
entitlement, platform support, dependency health, listener acquisition, and
runtime health are reported independently.
Both packages currently share the canonical kubernetes_development
product module and are therefore commercially gated together. A future
catalog may give CRI its own module or tier through descriptor data alone;
the host and capability architecture require no CRI-specific billing path.
State
User-visible result
Package absent
CRI is not available and no listener exists
Present but administrator-disabled
Installed, inactive, and data-preserving
Enabled without Kubernetes Development entitlement
Subscription required; runtime remains stopped
Entitled on an unsupported host
Explicit Linux amd64/arm64 requirement; no fallback
Dependency, artifact, or listener failure
Failed with a redaction-safe reason; never reported as healthy
Enabled, entitled, supported, and healthy
Host leases the listener and kubelet can use CRI v1
Listener paths and data namespaces come from host capabilities; the plugin
cannot self-grant them. Subscription loss or Kubernetes shutdown stops new
runtime work without turning reset or uninstall into persistent-data
deletion. The Kubernetes plugin’s separately confirmed purge is the only
operation that permanently removes registered cluster volumes.
Conformance promise
Stackie releases this support only when the CRI traceability inventory maps
every applicable upstream v1 service and method to implementation, tests,
and conformance evidence, and the version-matched upstream critest suite
passes unmodified in the real K3s topology. Unit tests, mocks, or a custom
smoke suite cannot substitute for either gate.
The checked-in cri-traceability.yaml is the canonical API index. Its
source-derived denominator includes all 41 pinned RPCs and all 99 normative
proto comment blocks. Each applicable row links its Tonic method, behavior
owner, Rustdoc, focused evidence, and unmodified critest selector.
Windows-only field rows remain visible with a sourced Linux-profile
exclusion. The closed applicability schema cannot configure local focus,
skip, retry, patches, alternate tests, or assertion changes.