2491a39bca
virtio-net, vhost-net and vhost-user-net were spread across three device managers with three config types, three error enums and three insert paths, even though they are all network interfaces of the guest behind one InsertNetworkDevice request. Merge them into a single NetworkDeviceMgr with one info_list, dispatching on the Backend enum per device, the way the block manager keeps its backends in one list keyed by BlockDeviceType. The unified NetworkInterfaceConfig moves from api/v1 into the manager, as the other managers define theirs, and the per-backend config conversions disappear. Device identity becomes the caller-supplied iface_id for every backend, matching how every other device class is identified, instead of vhost-user-net borrowing its socket path as its id. The socket path becomes a conflict-checked resource alongside the tap name and the guest MAC, so two devices claiming one vhost-user socket are refused (DuplicatedUdsPath) rather than silently collapsing into one entry. Behaviour changes, all deliberate: - A device with an empty iface_id is refused (MissingIfaceId). The id is the interface name inside the guest, so an unnamed device would silently take the place of another unnamed one and the VM would boot with an interface missing. Callers that relied on inserting vhost-user-net devices without an id must now supply one. - Hotplugging a device whose id is already in use is refused (DeviceIDAlreadyExist): the old config-update path would have left the already-attached device live on the bus with no handle left to remove it. Before boot, a repeated id still reconfigures the device as it does for every other device class. - Teardown no longer stops at the first device that fails to be destroyed; the failure is logged and the remaining devices are still removed. This path newly matters because vhost-user-net devices now retain their device handle like the other backends do. The unused open_tap helper (never called since the file was introduced) and the NetworkDeviceInfo alias are dropped rather than carried over. vhost-user-net devices inserted through runtime-rs receive their id in the following commit; with only this commit they are refused for the missing id. Signed-off-by: Xuewei Niu <niuxuewei.nxw@antgroup.com>
Kata Containers
Welcome to Kata Containers!
This repository is the home of the Kata Containers code for the 2.0 and newer releases.
If you want to learn about Kata Containers, visit the main Kata Containers website.
Introduction
Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.
License
The code is licensed under the Apache 2.0 license. See the license file for further details.
Platform support
Kata Containers currently runs on 64-bit systems supporting the following technologies:
| Architecture | Virtualization technology |
|---|---|
x86_64, amd64 |
Intel VT-x, AMD SVM |
aarch64 ("arm64") |
ARM Hyp |
ppc64le |
IBM Power |
s390x |
IBM Z & LinuxONE SIE |
Hardware requirements
The Kata Containers runtime provides a command to determine if your host system is capable of running and creating a Kata Container:
$ kata-runtime check
Notes:
This command runs a number of checks including connecting to the network to determine if a newer release of Kata Containers is available on GitHub. If you do not wish this to check to run, add the
--no-network-checksoption.By default, only a brief success / failure message is printed. If more details are needed, the
--verboseflag can be used to display the list of all the checks performed.If the command is run as the
rootuser additional checks are run (including checking if another incompatible hypervisor is running). When running asroot, network checks are automatically disabled.
Getting started
New to Kata Containers? Start with the Quick Start Guide to learn the basics and run your first workload, then see the installation guide.
Documentation
See the official documentation including:
Configuration
Kata Containers uses a single configuration file which contains a number of sections for various parts of the Kata Containers system including the runtime, the agent and the hypervisor.
Hypervisors
See the hypervisors document and the Hypervisor specific configuration details.
Community
To learn more about the project, its community and governance, see the community repository. This is the first place to go if you wish to contribute to the project.
Getting help
See the community section for ways to contact us.
Raising issues
Please raise an issue in this repository.
Note: If you are reporting a security issue, please follow the vulnerability reporting process
Developers
See the developer guide.
Components
Main components
The table below lists the core parts of the project:
| Component | Type | Description |
|---|---|---|
| runtime | core | Main component run by a container manager and providing a containerd shimv2 runtime implementation. |
| runtime-rs | core | The Rust version runtime. |
| agent | core | Management process running inside the virtual machine / POD that sets up the container environment. |
dragonball |
core | An optional built-in VMM brings out-of-the-box Kata Containers experience with optimizations on container workloads |
| documentation | documentation | Documentation common to all components (such as design and install documentation). |
| tests | tests | Excludes unit tests which live with the main code. |
Additional components
The table below lists the remaining parts of the project:
| Component | Type | Description |
|---|---|---|
| packaging | infrastructure | Scripts and metadata for producing packaged binaries (components, hypervisors, kernel and rootfs). |
| kernel | kernel | Linux kernel used by the hypervisor to boot the guest image. Patches are stored here. |
| osbuilder | infrastructure | Tool to create "mini O/S" rootfs and initrd images and kernel for the hypervisor. |
| kata-debug | infrastructure | Utility tool to gather Kata Containers debug information from Kubernetes clusters. |
agent-ctl |
utility | Tool that provides low-level access for testing the agent. |
kata-ctl |
utility | Tool that provides advanced commands and debug facilities. |
trace-forwarder |
utility | Agent tracing helper. |
ci |
CI | Continuous Integration configuration files and scripts. |
ocp-ci |
CI | Continuous Integration configuration for the OpenShift pipelines. |
katacontainers.io |
Source for the katacontainers.io site. |
|
Webhook |
utility | Example of a simple admission controller webhook to annotate pods with the Kata runtime class |
Packaging and releases
See the installation guide for release tarballs, the
kata-deploy Helm chart on Kubernetes, and build-from-source instructions.
General tests
See the tests documentation.
Glossary of Terms
See the glossary of terms related to Kata Containers.