mirror of
https://github.com/kata-containers/kata-containers.git
synced 2025-04-27 19:35:32 +00:00
6d55b1bafa
cri-containerd plugin is deprecated, use containerd instead. Fixes: #2791 Signed-off-by: bin <bin@hyper.sh>
96 lines
3.8 KiB
Markdown
96 lines
3.8 KiB
Markdown
## Design requirements
|
|
|
|
The Kata Containers runtime **MUST** fulfill all of the following requirements:
|
|
|
|
### OCI compatibility
|
|
The Kata Containers runtime **MUST** implement the [OCI runtime specification](https://github.com/opencontainers/runtime-spec) and support all
|
|
the OCI runtime operations.
|
|
|
|
### [`runc`](https://github.com/opencontainers/runc) CLI compatibility
|
|
In theory, being OCI compatible should be enough. In practice, the Kata Containers runtime
|
|
should comply with the latest *stable* `runc` CLI. In particular, it **MUST** implement the
|
|
following `runc` commands:
|
|
|
|
* `create`
|
|
* `delete`
|
|
* `exec`
|
|
* `kill`
|
|
* `list`
|
|
* `pause`
|
|
* `ps`
|
|
* `start`
|
|
* `state`
|
|
* `version`
|
|
|
|
The Kata Containers runtime **MUST** implement the following command line options:
|
|
* `--console-socket`
|
|
* `--pid-file`
|
|
|
|
### [CRI](http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html) and [Kubernetes](https://kubernetes.io) support
|
|
The Kata Containers project **MUST** provide two interfaces for CRI shims to manage hardware
|
|
virtualization based Kubernetes pods and containers:
|
|
- An OCI and `runc` compatible command line interface, as described in the previous section.
|
|
This interface is used by implementations such as [`CRI-O`](http://cri-o.io) and [`containerd`](https://github.com/containerd/containerd), for example.
|
|
- A hardware virtualization runtime library API for CRI shims to consume and provide a more
|
|
CRI native implementation. The [`frakti`](https://github.com/kubernetes/frakti) CRI shim is an example of such a consumer.
|
|
|
|
### Multiple hardware architectures support
|
|
The Kata Containers runtime **MUST NOT** be architecture-specific. It should be able to support
|
|
multiple hardware architectures and provide a modular and flexible design for adding support
|
|
for additional ones.
|
|
|
|
### Multiple hypervisor support
|
|
The Kata Containers runtime **MUST NOT** be tied to any specific hardware virtualization technology,
|
|
hypervisor, or virtual machine monitor implementation.
|
|
It should support multiple hypervisors and provide a pluggable and flexible design to add support
|
|
for additional ones.
|
|
|
|
#### Nesting
|
|
The Kata Containers runtime **MUST** support nested virtualization environments.
|
|
|
|
### Networking
|
|
|
|
* The Kata Containers runtime **MUST** support CNI plugin.
|
|
* The Kata Containers runtime **MUST** support both legacy and IPv6 networks.
|
|
|
|
### I/O
|
|
|
|
#### Devices direct assignment
|
|
In order for containers to directly consume host hardware resources, the Kata Containers runtime
|
|
**MUST** provide containers with secure pass through for generic devices such as GPUs, SRIOV,
|
|
RDMA, QAT, by leveraging I/O virtualization technologies (IOMMU, interrupt remapping).
|
|
|
|
#### Acceleration
|
|
The Kata Containers runtime **MUST** support accelerated and user-space-based I/O operations
|
|
for networking (e.g. DPDK) as well as storage through `vhost-user` sockets.
|
|
|
|
#### Scalability
|
|
The Kata Containers runtime **MUST** support scalable I/O through the SRIOV technology.
|
|
|
|
|
|
### Virtualization overhead reduction
|
|
A compelling aspect of containers is their minimal overhead compared to bare metal applications.
|
|
A container runtime should keep the overhead to a minimum in order to provide the expected user
|
|
experience.
|
|
The Kata Containers runtime implementation **SHOULD** be optimized for:
|
|
|
|
* Minimal workload boot and shutdown times
|
|
* Minimal workload memory footprint
|
|
* Maximal networking throughput
|
|
* Minimal networking latency
|
|
|
|
### Testing and debugging
|
|
|
|
#### Continuous Integration
|
|
Each Kata Containers runtime pull request **MUST** pass at least the following set of container-related
|
|
tests:
|
|
|
|
* Unit tests: runtime unit tests coverage >75%
|
|
* Functional tests: the entire runtime CLI and APIs
|
|
* Integration tests: Docker and Kubernetes
|
|
|
|
#### Debugging
|
|
|
|
The Kata Containers runtime implementation **MUST** use structured logging in order to namespace
|
|
log messages to facilitate debugging.
|