mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
760a5a2ca1
trying xref fix topics map rebase modularizes benefits for mulit nwt docs Addresses Suryas comments Commit three
254 lines
16 KiB
Plaintext
254 lines
16 KiB
Plaintext
:_mod-docs-content-type: ASSEMBLY
|
|
[id="virt-networking"]
|
|
= Networking overview
|
|
include::_attributes/common-attributes.adoc[]
|
|
:context: virt-networking-overview
|
|
|
|
toc::[]
|
|
|
|
{VirtProductName} provides advanced networking functionality by using custom resources and plugins. Virtual machines (VMs) are integrated with {product-title} networking and its ecosystem.
|
|
|
|
[NOTE]
|
|
====
|
|
You cannot run {VirtProductName} on a single-stack IPv6 cluster.
|
|
====
|
|
|
|
The following figure illustrates the typical network setup of {VirtProductName}. Other configurations are also possible.
|
|
|
|
.{VirtProductName} networking overview
|
|
image::318_OpenShift_Virtualization_Networking_0423.png[{VirtProductName} networking architecture]
|
|
|
|
image:darkcircle-1.png[20,20] Pods and VMs run on the same network infrastructure which allows you to easily connect your containerized and virtualized workloads.
|
|
|
|
image:darkcircle-2.png[20,20] You can connect VMs to the default pod network and to any number of secondary networks.
|
|
|
|
image:darkcircle-3.png[20,20] The default pod network provides connectivity between all its members, service abstraction, IP management, micro segmentation, and other functionality.
|
|
|
|
image:darkcircle-4.png[20,20] Multus is a "meta" CNI plugin that enables a pod or virtual machine to connect to additional network interfaces by using other compatible CNI plugins.
|
|
|
|
image:darkcircle-5.png[20,20] The default pod network is overlay-based, tunneled through the underlying machine network.
|
|
|
|
image:darkcircle-6.png[20,20] The machine network can be defined over a selected set of network interface controllers (NICs).
|
|
|
|
image:darkcircle-7.png[20,20] Secondary VM networks are typically bridged directly to a physical network, with or without VLAN encapsulation. It is also possible to create virtual overlay networks for secondary networks.
|
|
|
|
[NOTE]
|
|
====
|
|
Connecting VMs directly to the underlay network is not supported on {product-rosa}.
|
|
====
|
|
|
|
image:darkcircle-8.png[20,20] Secondary VM networks can be defined on dedicated set of NICs, as shown in Figure 1, or they can use the machine network.
|
|
|
|
include::modules/virt-networking-glossary.adoc[leveloffset=+1]
|
|
|
|
|
|
[id="default-network-config"]
|
|
== Using the default pod network
|
|
|
|
xref:../../virt/vm_networking/virt-connecting-vm-to-default-pod-network.adoc#virt-connecting-vm-to-default-pod-network[Connecting a virtual machine to the default pod network]::
|
|
|
|
Each VM is connected by default to the default internal pod network. You can add or remove network interfaces by editing the VM specification.
|
|
|
|
xref:../../virt/vm_networking/virt-exposing-vm-with-service.adoc#virt-exposing-vm-with-service[Exposing a virtual machine as a service]::
|
|
|
|
// Hiding from ROSA/OSD until OSDOCS-3691 is merged
|
|
ifndef::openshift-rosa,openshift-dedicated[]
|
|
You can expose a VM within the cluster or outside the cluster by creating a `Service` object. For on-premise clusters, you can configure a load balancing service by using the MetalLB Operator. You can xref:../../networking/networking_operators/metallb-operator/metallb-operator-install.adoc#metallb-operator-install_metallb-operator-install[install the MetalLB Operator] by using the {product-title} web console or the CLI.
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
// Hiding from ROSA/OSD until OSDOCS-3691 is merged
|
|
ifdef::openshift-rosa,openshift-dedicated[]
|
|
You can expose a VM within the cluster or outside the cluster by creating a `Service` object.
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
[id="secondary-network-config"]
|
|
== Configuring VM secondary network interfaces
|
|
|
|
ifndef::openshift-rosa,openshift-dedicated[]
|
|
You can connect a virtual machine to a secondary network by using Linux bridge, SR-IOV and OVN-Kubernetes CNI plugins. You can list multiple secondary networks and interfaces in the VM specification. It is not required to specify the primary pod network in the VM specification when connecting to a secondary network interface.
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
ifdef::openshift-rosa,openshift-dedicated[]
|
|
You can connect a virtual machine to a secondary network by using an OVN-Kubernetes Container Network Interface (CNI) plugin. It is not required to specify the primary pod network in the VM specification when connecting to a secondary network interface.
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
|
|
xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[Connecting a virtual machine to an OVN-Kubernetes secondary network]::
|
|
|
|
ifdef::openshift-rosa,openshift-dedicated[]
|
|
You can connect a VM to an Open Virtual Network (OVN)-Kubernetes secondary network. {VirtProductName} supports the `layer2` topology for OVN-Kubernetes.
|
|
+
|
|
--
|
|
A `layer2` topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes CNI plugin uses the Geneve (Generic Network Virtualization Encapsulation) protocol to create an overlay network between nodes. You can use this overlay network to connect VMs on different nodes, without having to configure any additional physical networking infrastructure.
|
|
--
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
ifndef::openshift-rosa,openshift-dedicated[]
|
|
You can connect a VM to an OVN-Kubernetes secondary network. {VirtProductName} supports the `layer2` and `localnet` topologies for OVN-Kubernetes. The `localnet` topology is the recommended way of exposing VMs to the underlying physical network, with or without VLAN encapsulation.
|
|
+
|
|
--
|
|
* A `layer2` topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes CNI plugin uses the Geneve (Generic Network Virtualization Encapsulation) protocol to create an overlay network between nodes. You can use this overlay network to connect VMs on different nodes, without having to configure any additional physical networking infrastructure.
|
|
|
|
* A `localnet` topology connects the secondary network to the physical underlay. This enables both east-west cluster traffic and access to services running outside the cluster, but it requires additional configuration of the underlying Open vSwitch (OVS) system on cluster nodes.
|
|
--
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
// Updated the xref to the correct ID
|
|
|
|
To configure an OVN-Kubernetes secondary network and attach a VM to that network, perform the following steps:
|
|
|
|
. xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#creating-ovn-nad_virt-connecting-vm-to-ovn-secondary-network[Configure an OVN-Kubernetes secondary network] by creating a network attachment definition (NAD).
|
|
ifndef::openshift-rosa,openshift-dedicated[]
|
|
+
|
|
[NOTE]
|
|
====
|
|
For `localnet` topology, you must xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-ovnk.adoc#configuration-localnet-switched-topology_configuring-additional-network-ovnk[configure an OVS bridge] by creating a `NodeNetworkConfigurationPolicy` object before creating the NAD.
|
|
====
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
. xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#attaching-vm-to-ovn-secondary-nw[Connect the VM to the OVN-Kubernetes secondary network] by adding the network details to the VM specification.
|
|
|
|
// Hiding from ROSA/OSD as SR-IOV not supported
|
|
ifndef::openshift-rosa,openshift-dedicated[]
|
|
xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#virt-connecting-vm-to-sriov[Connecting a virtual machine to an SR-IOV network]::
|
|
|
|
You can use Single Root I/O Virtualization (SR-IOV) network devices with additional networks on your {product-title} cluster installed on bare metal or Red Hat OpenStack Platform (RHOSP) infrastructure for applications that require high bandwidth or low latency.
|
|
+
|
|
You must xref:../../networking/networking_operators/sr-iov-operator/installing-sriov-operator.adoc#installing-sriov-operator[install the SR-IOV Network Operator] on your cluster to manage SR-IOV network devices and network attachments.
|
|
+
|
|
You can connect a VM to an SR-IOV network by performing the following steps:
|
|
|
|
. xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#nw-sriov-configuring-device_virt-connecting-vm-to-sriov[Configure an SR-IOV network device] by creating a `SriovNetworkNodePolicy` CRD.
|
|
. xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#nw-sriov-network-attachment_virt-connecting-vm-to-sriov[Configure an SR-IOV network] by creating an `SriovNetwork` object.
|
|
. xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#virt-attaching-vm-to-sriov-network_virt-connecting-vm-to-sriov[Connect the VM to the SR-IOV network] by including the network details in the VM configuration.
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
|
|
// Hiding from ROSA/OSD as Linux Bridge not supported
|
|
ifndef::openshift-rosa,openshift-dedicated[]
|
|
xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-connecting-vm-to-linux-bridge[Connecting a virtual machine to a Linux bridge network]::
|
|
|
|
xref:../../networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc#k8s-nmstate-about-the-k8s-nmstate-operator[Install the Kubernetes NMState Operator] to configure Linux bridges, VLANs, and bonding for your secondary networks. The OVN-Kubernetes `localnet` topology is the recommended way of connecting a VM to the underlying physical network, but {VirtProductName} also supports Linux bridge networks.
|
|
+
|
|
[NOTE]
|
|
====
|
|
You cannot directly attach to the default machine network when using Linux bridge networks.
|
|
====
|
|
+
|
|
You can create a Linux bridge network and attach a VM to the network by performing the following steps:
|
|
|
|
. xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-creating-linux-bridge-nncp_virt-connecting-vm-to-linux-bridge[Configure a Linux bridge network device] by creating a `NodeNetworkConfigurationPolicy` custom resource definition (CRD).
|
|
. xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#creating-linux-bridge-nad[Configure a Linux bridge network] by creating a `NetworkAttachmentDefinition` CRD.
|
|
. xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#configuring-vm-network-interface[Connect the VM to the Linux bridge network] by including the network details in the VM configuration.
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
|
|
//ROSA/OSD supports hot plugging with bridge binding and layer2 OVN-Kubernetes topology
|
|
xref:../../virt/vm_networking/virt-hot-plugging-network-interfaces.adoc#virt-hot-plugging-network-interfaces[Hot plugging secondary network interfaces]::
|
|
|
|
ifndef::openshift-rosa,openshift-dedicated[]
|
|
You can add or remove secondary network interfaces without stopping your VM. {VirtProductName} supports hot plugging and hot unplugging for secondary interfaces that use bridge binding and the VirtIO device driver. {VirtProductName} also supports hot plugging secondary interfaces that use the SR-IOV binding.
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
ifdef::openshift-rosa,openshift-dedicated[]
|
|
You can add or remove secondary network interfaces without stopping your VM. {VirtProductName} supports hot plugging and hot unplugging for secondary interfaces that use bridge binding and the OVN-Kubernetes `layer2` topology.
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
|
|
// Hiding in ROSA/OSD as not supported
|
|
ifndef::openshift-rosa,openshift-dedicated[]
|
|
xref:../../virt/vm_networking/virt-using-dpdk-with-sriov.adoc#virt-using-dpdk-with-sriov[Using DPDK with SR-IOV]::
|
|
|
|
The Data Plane Development Kit (DPDK) provides a set of libraries and drivers for fast packet processing. You can configure clusters and VMs to run DPDK workloads over SR-IOV networks.
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
ifndef::openshift-rosa,openshift-dedicated[]
|
|
xref:../../virt/vm_networking/virt-dedicated-network-live-migration.adoc#virt-dedicated-network-live-migration[Configuring a dedicated network for live migration]::
|
|
|
|
You can configure a dedicated xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-connecting-vm-to-linux-bridge[Multus network] for live migration. A dedicated network minimizes the effects of network saturation on tenant workloads during live migration.
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
// Hiding in ROSA/OSD as not supported Tech Preview
|
|
ifndef::openshift-rosa,openshift-dedicated[]
|
|
xref:../../virt/vm_networking/virt-accessing-vm-secondary-network-fqdn.adoc#virt-accessing-vm-secondary-network-fqdn[Accessing a virtual machine by using the cluster FQDN]::
|
|
|
|
You can access a VM that is attached to a secondary network interface from outside the cluster by using its fully qualified domain name (FQDN).
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
xref:../../virt/vm_networking/virt-configuring-viewing-ips-for-vms.adoc#virt-configuring-viewing-ips-for-vms[Configuring and viewing IP addresses]::
|
|
|
|
You can configure an IP address of a secondary network interface when you create a VM. The IP address is provisioned with cloud-init. You can view the IP address of a VM by using the {product-title} web console or the command line. The network information is collected by the QEMU guest agent.
|
|
|
|
// Hiding from ROSA/OSD as Linux Bridge is not supported
|
|
ifndef::openshift-rosa,openshift-dedicated[]
|
|
[id="comparing-bridge-localnet"]
|
|
=== Comparing Linux bridge CNI and OVN-Kubernetes localnet topology
|
|
|
|
The following table provides a comparison of features available when using the Linux bridge CNI compared to the `localnet` topology for an OVN-Kubernetes plugin:
|
|
|
|
.Linux bridge CNI compared to an OVN-Kubernetes localnet topology
|
|
[cols="1,1,1",options="header"]
|
|
|===
|
|
|Feature
|
|
|Available on Linux bridge CNI
|
|
|Available on OVN-Kubernetes localnet
|
|
|
|
|Layer 2 access to the underlay native network
|
|
|Only on secondary network interface controllers (NICs)
|
|
|Yes
|
|
|
|
|Layer 2 access to underlay VLANs
|
|
|Yes
|
|
|Yes
|
|
|
|
|Network policies
|
|
|No
|
|
|Yes
|
|
|
|
|Managed IP pools
|
|
|No
|
|
|Yes
|
|
|
|
|MAC spoof filtering
|
|
|Yes
|
|
|Yes
|
|
|
|
|===
|
|
endif::openshift-rosa,openshift-dedicated[]
|
|
|
|
|
|
[id="service-mesh-integration"]
|
|
== Integrating with OpenShift Service Mesh
|
|
xref:../../virt/vm_networking/virt-connecting-vm-to-service-mesh.adoc#virt-connecting-vm-to-service-mesh[Connecting a virtual machine to a service mesh]::
|
|
|
|
{VirtProductName} is integrated with OpenShift Service Mesh. You can monitor, visualize, and control traffic between pods and virtual machines.
|
|
|
|
[id="managing-mac-address-pools"]
|
|
== Managing MAC address pools
|
|
xref:../../virt/vm_networking/virt-using-mac-address-pool-for-vms.adoc#virt-using-mac-address-pool-for-vms[Managing MAC address pools for network interfaces]::
|
|
|
|
The KubeMacPool component allocates MAC addresses for VM network interfaces from a shared MAC address pool. This ensures that each network interface is assigned a unique MAC address. A virtual machine instance created from that VM retains the assigned MAC address across reboots.
|
|
|
|
[id="vm-ssh-access"]
|
|
== Configuring SSH access
|
|
xref:../../virt/virtual_machines/virt-accessing-vm-ssh.adoc#virt-accessing-vm-ssh[Configuring SSH access to virtual machines]::
|
|
|
|
You can configure SSH access to VMs by using the following methods:
|
|
|
|
* xref:../../virt/virtual_machines/virt-accessing-vm-ssh.adoc#using-virtctl-ssh_virt-accessing-vm-ssh[`virtctl ssh` command]
|
|
+
|
|
You create an SSH key pair, add the public key to a VM, and connect to the VM by running the `virtctl ssh` command with the private key.
|
|
+
|
|
You can add public SSH keys to {op-system-base-full} 9 VMs at runtime or at first boot to VMs with guest operating systems that can be configured by using a cloud-init data source.
|
|
|
|
* xref:../../virt/virtual_machines/virt-accessing-vm-ssh.adoc#virt-using-virtctl-port-forward-command_virt-accessing-vm-ssh[`virtctl port-forward` command]
|
|
+
|
|
You add the `virtctl port-foward` command to your `.ssh/config` file and connect to the VM by using OpenSSH.
|
|
|
|
* xref:../../virt/virtual_machines/virt-accessing-vm-ssh.adoc#using-services-ssh_virt-accessing-vm-ssh[Service]
|
|
+
|
|
You create a service, associate the service with the VM, and connect to the IP address and port exposed by the service.
|
|
|
|
* xref:../../virt/virtual_machines/virt-accessing-vm-ssh.adoc#using-secondary-networks-ssh_virt-accessing-vm-ssh[Secondary network]
|
|
+
|
|
You configure a secondary network, attach a VM to the secondary network interface, and connect to its allocated IP address.
|