mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
71 lines
3.7 KiB
Plaintext
71 lines
3.7 KiB
Plaintext
:_mod-docs-content-type: ASSEMBLY
|
|
[id="understanding-user-defined-networks"]
|
|
= Understanding user-defined networks
|
|
include::_attributes/common-attributes.adoc[]
|
|
:context: understanding-user-defined-networks
|
|
|
|
toc::[]
|
|
|
|
:featurename: `UserDefinedNetwork`
|
|
include::snippets/technology-preview.adoc[]
|
|
|
|
The OVN-Kubernetes CNI plugin supports `layer2`, `layer3`, and `localnet` topologies for secondary pod networks. However, for the primary network, or the main network that all pods are attached to, only a `layer3` topology is supported. This allows for network models where all pods in the cluster were part of the same global `layer3` network, but restricts the ability to customize primary network configurations.
|
|
|
|
With user-defined networks, cluster administrators and users are offered highly customizable network configuration options that provide users with the ability to define their own network topologies, ensure network isolation, manage IP addressing for the workloads, and leverage advanced networking features. User-defined networks help enhance networking flexibility, security, and performance.
|
|
|
|
User-defined networks provide the following benefits:
|
|
|
|
. Enhanced network isolation
|
|
+
|
|
* **Tenant isolation**: Namespaces can have their own isolated primary network, similar to how tenants are isolated in {rh-openstack-first}. This improves security by reducing the risk of cross-tenant traffic.
|
|
|
|
. Network flexibility
|
|
+
|
|
* **Layer 2 and layer 3 support**: Cluster administrators can configure primary networks as layer 2 or layer 3 network types. This provides the flexibility of a secondary network to the primary network.
|
|
|
|
. Simplified network management
|
|
+
|
|
* **Reduced network configuration complexity**: With user-defined networks, the need for complex network policies are eliminated because isolation can be achieved by grouping workloads in different networks.
|
|
|
|
. Advanced capabilities
|
|
+
|
|
* **Consistent and selectable IP addressing**: Users can specify and reuse IP subnets across different namespaces and clusters, providing a consistent networking environment.
|
|
+
|
|
* **Support for multiple networks**: The user-defined networking feature allows administrators to connect multiple namespaces to a single network, or to create distinct networks for different sets of namespaces.
|
|
|
|
. Simplification of application migration from {rh-openstack-first}
|
|
+
|
|
* **Network parity**: With user-defined networking, the migration of applications from OpenStack to {product-title} is simplified by providing similar network isolation and configuration options.
|
|
|
|
// Looks like this may be out for 4.17, but in for 4.18 as of 8/19/24
|
|
//. Ingress and egress support
|
|
//+
|
|
//* **Support for ingress and egress traffic**: Cluster ingress and egress traffic is supported for both primary and secondary networks.
|
|
//* **Support for ingress and egress features**: User-defined networks support support the following ingress and egress features:
|
|
//+
|
|
//** EgressQoS
|
|
//** EgressService
|
|
//** EgressIP
|
|
//** Load balancer and NodePort services, as well as services with external IPs.
|
|
|
|
//Limitations that users should consider for UDN.
|
|
include::modules/nw-udn-limitations.adoc[leveloffset=+1]
|
|
|
|
//Best practices for using UDN.
|
|
include::modules/nw-udn-best-practices.adoc[leveloffset=+1]
|
|
|
|
//How to implement the UDN API on a cluster.
|
|
include::modules/nw-udn-cr.adoc[leveloffset=+1]
|
|
|
|
//Explanation of optional config details
|
|
include::modules/nw-udn-additional-config-details.adoc[leveloffset=+1]
|
|
|
|
//Support matrix for UDN
|
|
//include::modules
|
|
|
|
//Examples for Layer2 and Layer3
|
|
//include::modules/nw-udn-examples.adoc[leveloffset=+2]
|
|
|
|
//[role="_additional-resources"]
|
|
//== Additional resources
|
|
// * xr3f../virtual docs that point to live migration of vms for 4.18's GA. |