github/kata-containers
1
0
Fork 1
mirror of https://github.com/kata-containers/kata-containers.git synced 2025-06-20 20:52:07 +00:00
Code Issues Projects Releases Wiki Activity

docs: Update networking details in the architecture doc

Browse Source 
Updated the doc to clarify certain networking details and
external links to some of the networking terms used.

Fixes #3308

Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
This commit is contained in:
Archana Shinde 2022-01-25 17:04:27 +05:30
parent 7d1a956471
commit 75ae536196
1 changed files with 20 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
docs/design/architecture/networking.md
View File

@ -1,36 +1,37 @@
# Networking # Networking
See the [networking document](networking.md). Containers typically live in their own, possibly shared, networking namespace.
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 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 to add the container to a network which is isolated from the host network.
which is shared between containers
In order to do so, container engines will usually add one end of a virtual In order to setup the network for a container, container engines call into a
ethernet (`veth`) pair into the container networking namespace. The other end of networking plugin. The network plugin will usually create a virtual
the `veth` pair is added to the host networking namespace. ethernet (`veth`) pair adding one end of the `veth` pair into the container
networking namespace, while 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 This is a very namespace-centric approach as many hypervisors or VM
Managers (VMMs) such as `virt-manager` cannot handle `veth` Managers (VMMs) such as `virt-manager` cannot handle `veth`
interfaces. Typically, `TAP` interfaces are created for VM interfaces. Typically, [`TAP`](https://www.kernel.org/doc/Documentation/networking/tuntap.txt)
connectivity. interfaces are created for VM connectivity.
To overcome incompatibility between typical container engines expectations To overcome incompatibility between typical container engines expectations
and virtual machines, Kata Containers networking transparently connects `veth` and virtual machines, Kata Containers networking transparently connects `veth`
interfaces with `TAP` ones using Traffic Control: interfaces with `TAP` ones using [Traffic Control](https://man7.org/linux/man-pages/man8/tc.8.html):
![Kata Containers networking](../arch-images/network.png) ![Kata Containers networking](../arch-images/network.png)
With a TC filter in place, a redirection is created between the container network and the With a TC filter rules in place, a redirection is created between the container network
virtual machine. As an example, the CNI may create a device, `eth0`, in the container's network and the virtual machine. As an example, the network plugin may place a device,
namespace, which is a VETH device. Kata Containers will create a tap device for the VM, `tap0_kata`, `eth0`, in the container's network namespace, which is one end of a VETH device.
and setup a TC redirection filter to mirror traffic from `eth0`'s ingress to `tap0_kata`'s egress, Kata Containers will create a tap device for the VM, `tap0_kata`,
and a second to mirror traffic from `tap0_kata`'s ingress to `eth0`'s egress. and setup a TC redirection filter to redirect traffic from `eth0`'s ingress to `tap0_kata`'s egress,
and a second TC filter to redirect 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 Kata Containers maintains support for MACVTAP, which was an earlier implementation used in Kata.
is the default because it allows for simpler configuration, better CNI plugin compatibility, and performance With this method, Kata created a MACVTAP device to connect directly to the `eth0` device.
on par with MACVTAP. 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 has deprecated support for bridge due to lacking performance relative to TC-filter and MACVTAP.