mirror of
https://github.com/kata-containers/kata-containers.git
synced 2025-05-05 15:07:31 +00:00
1. Explain why the current situation is a problem. 2. We are beyond a simple introduction now, it's a real proposal. 3. Explain why you think it is solid, and fix a grammatical error. 4. The Rust rationale does not really belong to the initial paragraph. Also, I rephrased it to highlight the contrast with Go and the Kata community's past experience switching to Rust for the agent. Fixes:#4193 Signed-off-by: Christophe de Dinechin <christophe@dinechin.org> |
||
---|---|---|
.. | ||
arch-images | ||
architecture | ||
architecture_3.0 | ||
data | ||
proposals | ||
core-scheduling.md | ||
direct-blk-device-assignment.md | ||
end-to-end-flow.md | ||
host-cgroups.md | ||
inotify.md | ||
kata-2-0-metrics.md | ||
kata-api-design.md | ||
kata-design-requirements.md | ||
kata-nydus-design.md | ||
README.md | ||
vcpu-handling.md | ||
virtualization.md | ||
VSocks.md |
Design
Kata Containers design documents:
- Kata Containers architecture
- API Design of Kata Containers
- Design requirements for Kata Containers
- VSocks
- VCPU handling
- Host cgroups
Inotify
support- Metrics(Kata 2.0)
- Design for Kata Containers
Lazyload
ability withnydus
- Design for direct-assigned volume
- Design for core-scheduling