Summary
The ARM↔pod I/O bridge built under #762 (exec + tar over pods/exec, sharing emptyDir volumes between helper containers and the activity container) is runtime-tier-agnostic in principle but is only designed and validated against the process tier (runc) on a kind cluster. The vm / microvm tier — activities isolated inside lightweight VMs via Kata Containers (with a Cloud-Hypervisor / MSHV / Firecracker VMM) — has bridge specifics that have not been validated and are explicitly out of scope for the #762 phase.
This issue tracks the investigation and follow-up work to confirm (or adapt) the bridge for the VM-isolated tier. Do not implement as part of the #762 phase.
Why the VM tier may differ
pods/exec for a Kata-isolated pod is proxied by the kata-agent across the VM boundary — tar streaming bandwidth, framing, and timeout behavior need to be characterized under that path.emptyDir (tmpfs) semantics and the shared-volume mount topology inside the guest VM may differ from runc; the init-container/native-sidecar volume sharing must be confirmed to hold across the guest boundary.- Native sidecars (
restartPolicy: Always init containers) require Kubernetes ≥ 1.28 and a Kata runtime class that honors that pod shape — needs validation.
- Hardened SecurityContext (seccomp
RuntimeDefault, dropped caps, read-only rootfs) interaction with the kata-agent inside the guest needs a separate pass.
Scope (investigation, not implementation here)
- Characterize
pods/exec + tar round-trip for inputs and outputs against a Kata runtimeClassName pod.
- Confirm shared
emptyDir volume topology and native-sidecar support inside the guest VM.
- Identify any per-tier branching ARM needs (e.g., chunk sizing, timeouts, fallback to a plain helper container kept alive by the driver).
- File concrete implementation tasks from the findings.
Out of scope
- Any production code changes for the VM tier (deferred to follow-ups filed from this investigation).
References
Summary
The ARM↔pod I/O bridge built under #762 (
exec+taroverpods/exec, sharingemptyDirvolumes between helper containers and the activity container) is runtime-tier-agnostic in principle but is only designed and validated against theprocesstier (runc) on a kind cluster. Thevm/microvmtier — activities isolated inside lightweight VMs via Kata Containers (with a Cloud-Hypervisor / MSHV / Firecracker VMM) — has bridge specifics that have not been validated and are explicitly out of scope for the #762 phase.This issue tracks the investigation and follow-up work to confirm (or adapt) the bridge for the VM-isolated tier. Do not implement as part of the #762 phase.
Why the VM tier may differ
pods/execfor a Kata-isolated pod is proxied by the kata-agent across the VM boundary —tarstreaming bandwidth, framing, and timeout behavior need to be characterized under that path.emptyDir(tmpfs) semantics and the shared-volume mount topology inside the guest VM may differ from runc; the init-container/native-sidecar volume sharing must be confirmed to hold across the guest boundary.restartPolicy: Alwaysinit containers) require Kubernetes ≥ 1.28 and a Kata runtime class that honors that pod shape — needs validation.RuntimeDefault, dropped caps, read-only rootfs) interaction with the kata-agent inside the guest needs a separate pass.Scope (investigation, not implementation here)
pods/exec+tarround-trip for inputs and outputs against a KataruntimeClassNamepod.emptyDirvolume topology and native-sidecar support inside the guest VM.Out of scope
References
design/components/activity-runtime-manager/design.mddesign/components/activity-runtime-manager/implementation-plan-io-bridge.md