So, What If I Don’t Want My Persistent Storage To Be Yet Another Bindmount?
summary
Proposes moving filesystem mount and post‑mount work into the microVM guest so the host avoids multiple bind‑mounts and virtio‑fs penalties; a Kata prototype implements a direct volume CLI, per‑pod mount-info.json, guest agent mounting over vhost‑user block devices and fio microbenchmarks showing virtio‑fs has worse random IO than block passthrough. Targets CSI/Kube changes via KEP 2857, requires runtime capability advertising and warns subpath and secret handling are immature; starts with block devices and a new access mode readWriteOncePod under the direct assignment model.
AI-written summary · about
chapters (10)
- 0:00Start
- 0:30Introduction
- 2:13Pod Startup from Kubelet's Perspective
- 8:51Regular Path for FS Operations on a PV
- 11:14MicroVM-based Runtime
- 12:22Kata Containers architecture
- 14:11Performance and Security Trade-offs
- 14:47Performance Comparison of virtio fs vs blk
- 15:56Direct Assigned PV: Mount Volume
- 26:47Questions
related talks
06m⚡ Lightning Talk: Kata Confidential Containers Meet Persistent Storage: Overcoming CSI Driver Challenges
28mWant a VM with local storage? Fine, just try it with Hwameistor!
28mKubernetes Storage Evolution: Enabling High Performance Distributed Datastores
35mBlock Volumes Support in Kubernetes [I]
32mYour Pods can be stateless, your VMs cannot! How to manage state in k8s
36mTips and tricks for Kubernetes storage
26mPains and Gains: Lessons From Orchestrating Volumes for Remote Storage in Cloud Native AI Scenarios
35mKubernetes Storage Lingo 101