Skip to content

Commit 8ff33e0

Browse files
author
Shikha Jhala
committed
CNV-52855: UDN localnet
1 parent af7e305 commit 8ff33e0

10 files changed

+267
-45
lines changed

‎_topic_maps/_topic_map.yml‎

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4791,6 +4791,8 @@ Topics:
47914791
File: virt-connecting-vm-to-default-pod-network
47924792
- Name: Connecting a VM to a primary user-defined network
47934793
File: virt-connecting-vm-to-primary-udn
4794+
- Name: Connecting a VM to a secondary localnet user-defined network
4795+
File: virt-connecting-vm-to-secondary-udn
47944796
- Name: Exposing a VM by using a service
47954797
File: virt-exposing-vm-with-service
47964798
- Name: Accessing a VM by using its internal FQDN
@@ -4801,7 +4803,7 @@ Topics:
48014803
File: virt-connecting-vm-to-sriov
48024804
- Name: Using DPDK with SR-IOV
48034805
File: virt-using-dpdk-with-sriov
4804-
- Name: Connecting a VM to an OVN-Kubernetes secondary network
4806+
- Name: Connecting a VM to an OVN-Kubernetes layer 2 secondary network
48054807
File: virt-connecting-vm-to-ovn-secondary-network
48064808
- Name: Hot plugging secondary network interfaces
48074809
File: virt-hot-plugging-network-interfaces

‎modules/virt-attaching-vm-to-secondary-udn.adoc‎

Lines changed: 58 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,58 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/vm_networking/virt-connecting-vm-to-secondary-udn.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="virt-attaching-vm-to-secondary-udn_{context}"]
7+
= Attaching a virtual machine to secondary user-defined networks by using the CLI
8+
9+
You can connect a virtual machine (VM) to multiple secondary cluster-scoped user-defined networks (CUDNs) by configuring the interface binding.
10+
11+
.Prerequisites
12+
* You have installed the {oc-first}.
13+
14+
.Procedure
15+
. Edit the `VirtualMachine` manifest to add the CUDN interface details, as in the following example:
16+
+
17+
.Example `VirtualMachine` manifest
18+
[source,yaml]
19+
----
20+
apiVersion: kubevirt.io/v1
21+
kind: VirtualMachine
22+
metadata:
23+
name: example-vm
24+
namespace: my-namespace # <1>
25+
spec:
26+
template:
27+
spec:
28+
domain:
29+
devices:
30+
interfaces:
31+
- name: secondary_localnet # <2>
32+
bridge: {}
33+
machine:
34+
type: ""
35+
resources:
36+
requests:
37+
memory: 2048M
38+
networks:
39+
- name: secondary_localnet # <3>
40+
multus:
41+
networkName: <localnet_cudn_name> # <4>
42+
# ...
43+
----
44+
<1> The namespace in which the VM is located. This value must match a namespace that is associated with the secondary CUDN.
45+
<2> The name of the secondary user-defined network interface.
46+
<3> The name of the network. This must match the value of the `spec.template.spec.domain.devices.interfaces.name` field.
47+
<4> The name of the localnet `ClusterUserDefinedNetwork` object that you previously created.
48+
49+
. Apply the `VirtualMachine` manifest by running the following command:
50+
+
51+
[source,terminal]
52+
----
53+
$ oc apply -f <filename>.yaml
54+
----
55+
+
56+
where:
57+
58+
<filename>:: Specifies the name of your `VirtualMachine` manifest YAML file.

‎modules/virt-creating-a-primary-cluster-udn.adoc‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@ spec:
4141
<3> Specifies the type of selector. In this example, the `matchExpressions` selector selects objects that have the label `kubernetes.io/metadata.name` with the value `red-namespace` or `blue-namespace`.
4242
<4> Specifies the type of operator. Possible values are `In`, `NotIn`, and `Exists`.
4343
<5> Specifies the topological configuration of the network. The required value is `Layer2`. A `Layer2` topology creates a logical switch that is shared by all nodes.
44-
<6> Specifies if the UDN is primary or secondary. {VirtProductName} only supports the `Primary` role. This means that the UDN acts as the primary network for the VM and all default traffic passes through this network.
44+
<6> Specifies whether the UDN is primary or secondary. The `Primary` role means that the UDN acts as the primary network for the VM and all default traffic passes through this network.
4545

4646
. Apply the `ClusterUserDefinedNetwork` manifest by running the following command:
4747
+

‎modules/virt-creating-a-primary-udn.adoc‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -36,7 +36,7 @@ spec:
3636
<1> Specifies the name of the `UserDefinedNetwork` custom resource.
3737
<2> Specifies the namespace in which the VM is located. The namespace must have the `k8s.ovn.org/primary-user-defined-network` label. The namespace must not be `default`, an `openshift-*` namespace, or match any global namespaces that are defined by the Cluster Network Operator (CNO).
3838
<3> Specifies the topological configuration of the network. The required value is `Layer2`. A `Layer2` topology creates a logical switch that is shared by all nodes.
39-
<4> Specifies if the UDN is primary or secondary. {VirtProductName} only supports the `Primary` role. This means that the UDN acts as the primary network for the VM and all default traffic passes through this network.
39+
<4> Specifies whether the UDN is primary or secondary. The `Primary` role means that the UDN acts as the primary network for the VM and all default traffic passes through this network.
4040
<5> Specifies that virtual workloads have consistent IP addresses across reboots and migration. The `spec.layer2.subnets` field is required when `ipam.lifecycle: Persistent` is specified.
4141

4242
. Apply the `UserDefinedNetwork` manifest by running the following command:

‎modules/virt-creating-secondary-localnet-udn.adoc‎

Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/vm_networking/virt-connecting-vm-to-secondary-udn.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="virt-creating-secondary-localnet-udn_{context}"]
7+
= Creating a user-defined-network for localnet topology by using the CLI
8+
9+
You can create a secondary cluster-scoped user-defined-network (CUDN) for the localnet network topology by using the CLI.
10+
11+
.Prerequisites
12+
* You are logged in to the cluster as a user with `cluster-admin` privileges.
13+
* You have installed the {oc-first}.
14+
* You installed the Kubernetes NMState Operator.
15+
16+
.Procedure
17+
. Create a `NodeNetworkConfigurationPolicy` object to map the OVN-Kubernetes secondary network to an Open vSwitch (OVS) bridge:
18+
+
19+
.Example `NodeNetworkConfigurationPolicy` manifest
20+
[source,yaml]
21+
----
22+
apiVersion: nmstate.io/v1
23+
kind: NodeNetworkConfigurationPolicy
24+
metadata:
25+
name: mapping # <1>
26+
spec:
27+
nodeSelector:
28+
node-role.kubernetes.io/worker: '' # <2>
29+
desiredState:
30+
ovn:
31+
bridge-mappings:
32+
- localnet: tenantblue # <3>
33+
bridge: br-ex # <4>
34+
state: present # <5>
35+
----
36+
<1> The name of the configuration object.
37+
<2> Specifies the nodes to which the node network configuration policy is applied. The recommended node selector value is `node-role.kubernetes.io/worker: ''`.
38+
<3> The name of the additional network from which traffic is forwarded to the OVS bridge. This attribute must match the value of the `spec.network.localnet.physicalNetworkName` field of the `ClusterUserDefinedNetwork` object that defines the OVN-Kubernetes additional network. This example uses the name `tenantblue`.
39+
<4> The name of the OVS bridge on the node. This value is required if the `state` attribute is `present` or not specified.
40+
<5> The state of the mapping. Must be either `present` to add the mapping or `absent` to remove the mapping. The default value is `present`.
41+
+
42+
[IMPORTANT]
43+
====
44+
{VirtProductName} does not support Linux bridge bonding modes 0, 5, and 6. For more information, see link:https://access.redhat.com/solutions/67546[Which bonding modes work when used with a bridge that virtual machine guests or containers connect to?].
45+
====
46+
47+
. Apply the `NodeNetworkConfigurationPolicy` manifest by running the following command:
48+
+
49+
[source,terminal]
50+
----
51+
$ oc apply -f <filename>.yaml
52+
----
53+
+
54+
where:
55+
56+
<filename>:: Specifies the name of your `NodeNetworkConfigurationPolicy` manifest YAML file.
57+
58+
. Create a `ClusterUserDefinedNetwork` object to create a localnet secondary network:
59+
+
60+
.Example `ClusterUserDefinedNetwork` manifest
61+
[source,yaml]
62+
----
63+
apiVersion: k8s.ovn.org/v1
64+
kind: ClusterUserDefinedNetwork
65+
metadata:
66+
name: cudn-localnet # <1>
67+
spec:
68+
namespaceSelector: # <2>
69+
matchExpressions: # <3>
70+
- key: kubernetes.io/metadata.name
71+
operator: In # <4>
72+
values: ["red", "blue"]
73+
network:
74+
topology: Localnet # <5>
75+
localnet:
76+
role: Secondary # <6>
77+
physicalNetworkName: tenantblue # <7>
78+
ipam:
79+
mode: Disabled # <8>
80+
# ...
81+
----
82+
<1> The name of the `ClusterUserDefinedNetwork` custom resource.
83+
<2> The set of namespaces that the cluster UDN applies to. The namespace selector must not point to the following values: `default`; an `openshift-*` namespace; or any global namespaces that are defined by the Cluster Network Operator (CNO).
84+
<3> The type of selector. In this example, the `matchExpressions` selector selects objects that have the label `kubernetes.io/metadata.name` with the value `red` or `blue`.
85+
<4> The type of operator. Possible values are `In`, `NotIn`, and `Exists`.
86+
<5> The topological configuration of the network. A `Localnet` topology connects the logical network to the physical underlay.
87+
<6> Specifies whether the UDN is primary or secondary. The required value is `Secondary` for `topology: Localnet`.
88+
<7> The name of the OVN-Kubernetes bridge mapping that is configured on the node. This value must match the `spec.desiredState.ovn.bridge-mappings.localnet` field in the `NodeNetworkConfigurationPolicy` manifest that you previously created. This ensures that you are bridging to the intended segment of your physical network.
89+
<8> Specifies whether IP address management (IPAM) is enabled or disabled. The required value is `Disabled`. {VirtProductName} does not support configuring IPAM for virtual machines.
90+
91+
. Apply the `ClusterUserDefinedNetwork` manifest by running the following command:
92+
+
93+
[source,terminal]
94+
----
95+
$ oc apply -f <filename>.yaml
96+
----
97+
+
98+
where:
99+
100+
<filename>:: Specifies the name of your `ClusterUserDefinedNetwork` manifest YAML file.
101+
102+

‎modules/virt-creating-secondary-udn-namespace.adoc‎

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/vm_networking/virt-connecting-vm-to-secondary-udn.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="virt-creating-secondary-udn-namespace_{context}"]
7+
= Creating a namespace for secondary user-defined networks by using the CLI
8+
9+
You can create a namespace to be used with an existing secondary cluster-scoped user-defined network (CUDN) by using the CLI.
10+
11+
.Prerequisites
12+
* You are logged in to the cluster as a user with `cluster-admin` permissions.
13+
* You have installed the {oc-first}.
14+
15+
16+
.Procedure
17+
. Create a `Namespace` object similar to the following example:
18+
+
19+
.Example `Namespace` manifest
20+
[source,yaml]
21+
----
22+
apiVersion: v1
23+
kind: Namespace
24+
metadata:
25+
name: cudn_namespace
26+
# ...
27+
----
28+
29+
. Apply the `Namespace` manifest by running the following command:
30+
+
31+
[source, terminal]
32+
----
33+
oc apply -f <filename>.yaml
34+
----
35+
+
36+
where:
37+
38+
<filename>:: Specifies the name of your `Namespace` manifest YAML file.

‎virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc‎

Lines changed: 17 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
:_mod-docs-content-type: ASSEMBLY
22
[id="virt-connecting-vm-to-ovn-secondary-network"]
3-
= Connecting a virtual machine to an OVN-Kubernetes secondary network
3+
= Connecting a virtual machine to an OVN-Kubernetes layer 2 secondary network
44
include::_attributes/common-attributes.adoc[]
55
:context: virt-connecting-vm-to-ovn-secondary-network
66

@@ -13,35 +13,26 @@ A `layer2` topology connects workloads by a cluster-wide logical switch. The OVN
1313
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
1414

1515
ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
16-
You can connect a virtual machine (VM) to an OVN-Kubernetes secondary network. {VirtProductName} supports the `layer2` and `localnet` topologies for OVN-Kubernetes.
16+
You can connect a virtual machine (VM) to an OVN-Kubernetes `layer2` secondary network by using the CLI.
1717

18-
* A `layer2` topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes Container Network Interface (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.
19-
20-
* 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.
18+
A `layer2` topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes Container Network Interface (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.
2119

2220
[NOTE]
2321
====
24-
An OVN-Kubernetes secondary network is compatible with the xref:../../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#compatibility-with-multi-network-policy_configuring-additional-network[multi-network policy API] which provides the `MultiNetworkPolicy` custom resource definition (CRD) to control traffic flow to and from VMs. You can use the `ipBlock` attribute to define network policy ingress and egress rules for specific CIDR blocks.
22+
An OVN-Kubernetes secondary network is compatible with the xref:../../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#compatibility-with-multi-network-policy_configuring-additional-network[multi-network policy API] which provides the `MultiNetworkPolicy` custom resource definition (CRD) to control traffic flow to and from VMs. You must use the `ipBlock` attribute to define network policy ingress and egress rules for specific CIDR blocks. You cannot use pod or namespace selectors for virtualization workloads.
2523
====
2624
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
2725

28-
To configure an OVN-Kubernetes secondary network and attach a VM to that network, perform the following steps:
26+
To configure an OVN-Kubernetes `layer2` secondary network and attach a VM to that network, perform the following steps:
2927

30-
. xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[Configure an OVN-Kubernetes secondary network] by creating a network attachment definition (NAD).
31-
ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
32-
+
33-
[NOTE]
34-
====
35-
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.
36-
====
37-
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
28+
. xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[Configure an OVN-Kubernetes layer 2 secondary network].
3829

39-
. 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.
30+
. 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 layer 2 secondary network].
4031

4132
[id="creating-ovn-nad_{context}"]
42-
== Creating an OVN-Kubernetes NAD
33+
== Creating an OVN-Kubernetes layer 2 NAD
4334

44-
You can create an OVN-Kubernetes network attachment definition (NAD) by using the {product-title} web console or the CLI.
35+
You can create an OVN-Kubernetes network attachment definition (NAD) for the layer 2 network topology by using the {product-title} web console or the CLI.
4536

4637
[NOTE]
4738
====
@@ -50,20 +41,20 @@ Configuring IP address management (IPAM) by specifying the `spec.config.ipam.sub
5041

5142
include::modules/virt-creating-layer2-nad-cli.adoc[leveloffset=+2]
5243

53-
ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
54-
include::modules/virt-creating-localnet-nad-cli.adoc[leveloffset=+2]
55-
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
44+
//ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
45+
//include::modules/virt-creating-localnet-nad-cli.adoc[leveloffset=+2]
46+
//endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
5647

5748
include::modules/virt-creating-nad-l2-overlay-console.adoc[leveloffset=+2]
5849

59-
ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
60-
include::modules/virt-creating-nad-localnet-console.adoc[leveloffset=+2]
61-
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
50+
//ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
51+
//include::modules/virt-creating-nad-localnet-console.adoc[leveloffset=+2]
52+
//endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
6253

6354
[id="attaching-vm-to-ovn-secondary-nw"]
64-
== Attaching a virtual machine to the OVN-Kubernetes secondary network
55+
== Attaching a virtual machine to the OVN-Kubernetes layer 2 secondary network
6556

66-
You can attach a virtual machine (VM) to the OVN-Kubernetes secondary network interface by using the {product-title} web console or the CLI.
57+
You can attach a virtual machine (VM) to the OVN-Kubernetes layer 2 secondary network interface by using the {product-title} web console or the CLI.
6758

6859
include::modules/virt-attaching-vm-to-ovn-secondary-nw-cli.adoc[leveloffset=+2]
6960

‎virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc‎

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -28,10 +28,6 @@ You must consider the following limitations before implementing a primary UDN:
2828
* You cannot use headless services to access a VM.
2929
* You cannot define readiness and liveness probes to configure VM health checks.
3030
31-
[NOTE]
32-
====
33-
{VirtProductName} currently does not support secondary user-defined networks.
34-
====
3531
3632
[id="creating-primary-udn-web_{context}"]
3733
== Creating a primary user-defined network by using the web console

‎virt/vm_networking/virt-connecting-vm-to-secondary-udn.adoc‎

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
:_mod-docs-content-type: ASSEMBLY
2+
[id="virt-connecting-vm-to-secondary-udn"]
3+
= Connecting a virtual machine to a secondary localnet user-defined network
4+
include::_attributes/common-attributes.adoc[]
5+
:context: virt-connecting-vm-to-secondary-udn
6+
7+
toc::[]
8+
9+
You can connect a virtual machine (VM) to an OVN-Kubernetes localnet secondary network by using the CLI. Cluster administrators can use the `ClusterUserDefinedNetwork` (CUDN) custom resource definition (CRD) to create a shared OVN-Kubernetes network across multiple namespaces.
10+
11+
An OVN-Kubernetes secondary network is compatible with the xref:../../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#compatibility-with-multi-network-policy_configuring-additional-network[multi-network policy API] which provides the `MultiNetworkPolicy` custom resource definition (CRD) to control traffic flow to and from VMs.
12+
13+
[IMPORTANT]
14+
====
15+
You must use the `ipBlock` attribute to define network policy ingress and egress rules for specific CIDR blocks. Using pod or namespace selector policy peers is not supported.
16+
====
17+
18+
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.
19+
20+
include::modules/virt-creating-secondary-localnet-udn.adoc[leveloffset=+1]
21+
22+
include::modules/virt-creating-secondary-udn-namespace.adoc[leveloffset=+1]
23+
24+
include::modules/virt-attaching-vm-to-secondary-udn.adoc[leveloffset=+1]
25+
26+
[role="_additional-resources"]
27+
[id="additional-resources_{context}"]
28+
== Additional resources
29+
* xref:../../networking/multiple_networks/primary_networks/about-user-defined-networks.adoc#about-cudn_about-user-defined-networks[About the `ClusterUserDefinedNetwork` CR]

0 commit comments

Comments
 (0)