mirror of
https://github.com/aljazceru/kata-containers.git
synced 2025-12-18 06:44:23 +01:00
Move the networking details out of the architecture doc and into a separate file. Partially fixes: #3246. Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
49 lines
2.3 KiB
Markdown
49 lines
2.3 KiB
Markdown
# Networking
|
|
|
|
See the [networking document](networking.md).
|
|
|
|
Containers will typically live in their own, possibly shared, networking namespace.
|
|
At some point in a container lifecycle, container engines will set up that namespace
|
|
to add the container to a network which is isolated from the host network, but
|
|
which is shared between containers
|
|
|
|
In order to do so, container engines will usually add one end of a virtual
|
|
ethernet (`veth`) pair into the container networking namespace. The other end of
|
|
the `veth` pair is added to the host networking namespace.
|
|
|
|
This is a very namespace-centric approach as many hypervisors or VM
|
|
Managers (VMMs) such as `virt-manager` cannot handle `veth`
|
|
interfaces. Typically, `TAP` interfaces are created for VM
|
|
connectivity.
|
|
|
|
To overcome incompatibility between typical container engines expectations
|
|
and virtual machines, Kata Containers networking transparently connects `veth`
|
|
interfaces with `TAP` ones using Traffic Control:
|
|
|
|

|
|
|
|
With a TC filter in place, a redirection is created between the container network and the
|
|
virtual machine. As an example, the CNI may create a device, `eth0`, in the container's network
|
|
namespace, which is a VETH device. Kata Containers will create a tap device for the VM, `tap0_kata`,
|
|
and setup a TC redirection filter to mirror traffic from `eth0`'s ingress to `tap0_kata`'s egress,
|
|
and a second to mirror traffic from `tap0_kata`'s ingress to `eth0`'s egress.
|
|
|
|
Kata Containers maintains support for MACVTAP, which was an earlier implementation used in Kata. TC-filter
|
|
is the default because it allows for simpler configuration, better CNI plugin compatibility, and performance
|
|
on par with MACVTAP.
|
|
|
|
Kata Containers has deprecated support for bridge due to lacking performance relative to TC-filter and MACVTAP.
|
|
|
|
Kata Containers supports both
|
|
[CNM](https://github.com/docker/libnetwork/blob/master/docs/design.md#the-container-network-model)
|
|
and [CNI](https://github.com/containernetworking/cni) for networking management.
|
|
|
|
## Network Hotplug
|
|
|
|
Kata Containers has developed a set of network sub-commands and APIs to add, list and
|
|
remove a guest network endpoint and to manipulate the guest route table.
|
|
|
|
The following diagram illustrates the Kata Containers network hotplug workflow.
|
|
|
|

|