mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
70 lines
4.7 KiB
Plaintext
70 lines
4.7 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * microshift_networking/microshift-cni-multus.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="microshift-multus-intro_{context}"]
|
|
= Secondary networks in {microshift-short}
|
|
|
|
[role="_abstract"]
|
|
Using the {microshift-short} Multus CNI plugin, you can add additional interfaces to pods from other networks. With this configuration, you have flexibility when you configure pods that deliver network functionality, such as switching or routing.
|
|
|
|
During node installation, the _default_ pod network is configured with default values unless you customize the configuration. The default network handles all ordinary network traffic for the node.
|
|
|
|
[id="microshift-supported-additional-networks_{context}"]
|
|
== Supported secondary networks for network isolation
|
|
|
|
The following secondary networks are supported in {microshift-short} {product-version}:
|
|
|
|
* Bridge: Allows pods on the same host to communicate with each other and the host.
|
|
|
|
* IPVLAN: Allows pods on a host to communicate with other hosts.
|
|
** This is similar to a MACVLAN-based secondary network.
|
|
** Each pod shares the same MAC address as the parent physical network interface, unlike a MACVLAN-based secondary network.
|
|
|
|
* MACVLAN: Allows pods on a host to communicate with other hosts and the pods on those other hosts by using a physical network interface. Each pod that is attached to a MACVLAN-based secondary network is provided with a unique MAC address.
|
|
|
|
[NOTE]
|
|
====
|
|
Setting network policies for secondary networks is not supported.
|
|
====
|
|
|
|
[id="microshift-additional-network-use-cases_{context}"]
|
|
== Use case: Secondary networks for network isolation
|
|
|
|
You can use an secondary network in situations where network isolation is needed, including control plane and data plane separation. For example, you can configure an secondary interface if you want pods to access a network on the host and also communicate with devices deployed to the edge. These edge devices might be on an isolated operator network or are periodically disconnected.
|
|
|
|
Isolating network traffic is useful for the following performance and security reasons:
|
|
|
|
Performance:: You can send traffic on two different planes to manage the amount of traffic on each plane.
|
|
Security:: You can send sensitive traffic onto a network plane that is managed specifically for security considerations, and you can separate private data that must not be shared between tenants or customers.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
The Multus CNI plugin is deployed when the {microshift-short} service starts up. Therefore, a host restart is required if the `microshift-multus` RPM package is added after {microshift-short} has started. Restarting ensures that all containers are re-created with Multus annotations.
|
|
====
|
|
|
|
[id="microshift-additional-network-how-implemented_{context}"]
|
|
== How secondary networks are implemented
|
|
|
|
All of the pods in the node still use the node-wide default network to maintain connectivity across the node. Every pod has an `eth0` interface that is attached to the node-wide pod network.
|
|
|
|
* You can view the interfaces for a pod by using the `oc get pod <pod_name> -o=jsonpath='{ .metadata.annotations.k8s\.v1\.cni\.cncf\.io/network-status }'` command.
|
|
* If you add secondary network interfaces that use the {microshift-short} Multus CNI, they are named `net1`, `net2`, ..., `netN`.
|
|
* The CNI configuration is created when the {microshift-short} Multus DaemonSet starts. This configuration is autogenerated and includes the primary CNI that is the default delegate. For {microshift-short}, the default CNI is OVN-Kubernetes.
|
|
|
|
[id="microshift-additional-network-how-attached-pods_{context}"]
|
|
== How to attach secondary networks to pods
|
|
|
|
To attach secondary network interfaces to a pod, you must create and apply configurations that define how the interfaces are attached.
|
|
|
|
* You must configure any secondary networks you want to use. Because of individual differences in networks, no default configuration is provided.
|
|
* You must apply YAML manifest to specify each interface by using a `NetworkAttachmentDefinition` custom resource (CR). A configuration inside each of these CRs defines how that interface is created.
|
|
* CRI-O must be configured to use Multus. A default configuration is included in the `microshift-multus` RPM.
|
|
** If the Multus CNI is installed on an existing {microshift-short} instance, the host must be restarted.
|
|
** If the Multus CNI is installed alongside {microshift-short}, you can add CRs and pods and then start the {microshift-short} service. Restarting the host in this scenario is not needed.
|
|
|
|
[id="microshift-config-examples-additional-networks_{context}"]
|
|
== Configurations for secondary network types
|
|
The specific configuration fields for secondary networks is described in the following sections.
|