Success of CRI: Bringing Hypervisor Based Container to Kubernetes [I]
summary
Hypervisor-based container runtime (HyperContainer) plugs into Kubernetes via CRI and ships three components: hyperd (OCI-compatible hypervisor shim), hyperstart (init/streaming agent) and CNI-based network glue. Implementation runs as a separate streaming server, maps pod resource requests into VM memory/CPU limits, supports mixed runtimes on one node, and passes ~95% of Kubernetes node e2e conformance tests with 100% imminent. Overhead is a single-digit‑MB per sandbox and TAP devices expose VM interfaces.
AI-written summary · about
chapters (15)
- 0:00Start
- 4:12Combine the best parts
- 5:33Bring HyperContainer to Kubernetes?
- 7:12Container Runtime Interface (CRI)
- 11:33How Frakti Works?
- 13:111. Lifecycle
- 14:432.1 Streaming (old version)
- 15:562.2 Streaming (CRI version)
- 17:433.1 Pod Level Resource Management
- 19:283.2 Pod Level Resource Management in Frakti
- 20:234. CNI Network in Frakti
- 22:525.2 Frakti: Mixed Runtimes
- 24:33Architecture of Hypernetes v1.3
- 25:29Roadmap of Hypernetes 1.6
- 26:02Summary
related talks
46mCRI-O: All the Runtime Kubernetes need
29mCRI-O: All the Runtime Kubernetes Needs, and Nothing More
33mCRI-O Still Loves Kubernetes
34mContainer Runtime Evolving in Kubernetes
42mCRI Runtimes Deep Dive: Who's Running My Kubernetes Pod!?
23mOCI, CRI, ??: Making Sense of the Container Runtime Landscape in Kubernetes - Phil Estes, IBM
38mIntroduction to CRI-O
34mContainer Runtime Evolving in Kubernetes