Stackie’s Kubernetes plugin provisions and operates a real upstream K3s
distribution for local development. Kubernetes remains Kubernetes: Stackie
does not reimplement the API server, scheduler, controllers, kubelet, or
kubectl contract.
What each plugin owns
The Kubernetes and CRI packages are separately buildable first-party
plugins. The Kubernetes plugin owns verified K3s artifacts, cluster
processes, lifecycle, CNI setup, and persistent-data safety. The CRI plugin
owns the CRI v1 endpoint used by kubelet. Mocker compatibility alone decides
whether an image maps to a Stackie block; Stackied admits and supervises the
resulting workload.
In text: Kubernetes clients talk to upstream K3s. K3s’s kubelet calls the
separate CRI v1 plugin, which asks Mocker compatibility to classify images
before Stackied admits workloads. K3s uses the verified upstream CNI plugin
bundle for pod networking.
This dependency direction is deliberate. In a later sprint a future Mocker
plugin can provide the same compatibility capability to the Kubernetes and
CRI plugins; Docker-to-Stackie translation will not move into either plugin
or into Bridge.
Supported profile
Component
Pinned/supported value
Host
Linux amd64 or Linux arm64
Kubernetes distribution
K3s v1.36.2+k3s1
Kubernetes API version
v1.36.2
CRI API
k8s.io/cri-api v0.36.2, CRI v1
CRI validation
Unmodified upstream critest v1.36.0
OCI runtime
Upstream runc v1.4.2
Networking
Upstream CNI plugins v1.9.1
Stackie verifies every downloaded artifact against the repository’s pinned
HTTPS URL, size ceiling, and SHA-256 digest before it can become executable.
Unsupported hosts can display package availability, but start returns an
explicit unsupported result; Stackie never substitutes a simulated
Kubernetes or another container runtime.
Package, administration, and subscription are separate
Build inclusion and runtime entitlement are independent generic host facts.
Including the package does not grant a subscription, and a subscription
cannot materialise a package omitted from a build.
Kubernetes and CRI currently declare the same canonical
kubernetes_development product module, so one Kubernetes Development
entitlement gates the pair. The plugin architecture also supports assigning
distinct catalog modules—and therefore distinct paid tiers—to either package
without adding host-side product checks.
Package
Administrator state
Subscription
Platform
Result
Absent
Any
Any
Any
Kubernetes is unavailable; no plugin service starts
Present
Disabled
Any
Supported
Installed but administrator-disabled and inactive; cluster data is preserved
Present
Enabled
Missing
Supported
Subscription-required state; processes stop and data is preserved
Present
Enabled
Granted
Unsupported
Explicit unsupported-platform state; no fallback starts
Present
Enabled
Granted
Supported
K3s server and agent may start after artifact and health checks pass
The dashboard, API, and CLI report these facts separately so “not included,”
“disabled,” “subscription required,” “unsupported,” and “failed” are not
collapsed into a misleading generic error.
Lifecycle and recovery
Cluster operations are durable. Stackie records the intended generation
before starting or stopping K3s, validates the exact executable and process
start identity it owns, and resumes or repairs interrupted operations after
restart. A stale process, executable mismatch, or superseded operation is
rejected instead of being adopted or terminated by name alone.
Action
Processes and disposable state
Persistent volumes
Stop
Stops the owned K3s server and agent
Preserved
Subscription loss
Stops local Kubernetes and marks entitlement absent
Preserved
Reset
Stops processes and removes disposable sockets, runtime state, artifact caches, and CNI state
Preserved
Uninstall
Removes package/disposable state
Preserved and still registered
Purge
Requires a fresh confirmation matching the current cluster generation and persistent-volume count
Permanently deleted only after that confirmation
Reset and uninstall are therefore safe recovery actions, not aliases for
deleting data. Permanent deletion is always the distinct, explicit purge
operation. If the cluster changes after confirmation is shown, the purge is
refused and must be confirmed again.
Operational boundary
Use ordinary Kubernetes clients and manifests against the provisioned K3s
endpoint. Kubernetes API behavior, scheduling, controllers, and kubelet
conformance come from the pinned upstream distribution. Stackie owns local
provisioning and workload integration only; managed-cloud Kubernetes such
as EKS, GKE, and AKS remains a separate Spaceport follow-up.