mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
44 lines
3.0 KiB
Plaintext
44 lines
3.0 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
|
|
|
|
:_mod-docs-content-type: REFERENCE
|
|
[id="telco-core-cluster-network-operator_{context}"]
|
|
= Cluster Network Operator
|
|
|
|
New in this release::
|
|
* No reference design updates in this release
|
|
|
|
Description::
|
|
+
|
|
--
|
|
The Cluster Network Operator (CNO) deploys and manages the cluster network components including the default OVN-Kubernetes network plugin during cluster installation. The CNO allows for configuring primary interface MTU settings, OVN gateway configurations to use node routing tables for pod egress, and additional secondary networks such as MACVLAN.
|
|
|
|
In support of network traffic separation, multiple network interfaces are configured through the CNO.
|
|
Traffic steering to these interfaces is configured through static routes applied by using the NMState Operator. To ensure that pod traffic is properly routed, OVN-K is configured with the `routingViaHost` option enabled. This setting uses the kernel routing table and the applied static routes rather than OVN for pod egress traffic.
|
|
|
|
The Whereabouts CNI plugin is used to provide dynamic IPv4 and IPv6 addressing for additional pod network interfaces without the use of a DHCP server.
|
|
--
|
|
|
|
Limits and requirements::
|
|
* OVN-Kubernetes is required for IPv6 support.
|
|
* Large MTU cluster support requires connected network equipment to be set to the same or larger value.
|
|
MTU size up to 8900 is supported.
|
|
//https://issues.redhat.com/browse/CNF-10593
|
|
* MACVLAN and IPVLAN cannot co-locate on the same main interface due to their reliance on the same underlying kernel mechanism, specifically the `rx_handler`.
|
|
This handler allows a third-party module to process incoming packets before the host processes them, and only one such handler can be registered per network interface.
|
|
Since both MACVLAN and IPVLAN need to register their own `rx_handler` to function, they conflict and cannot coexist on the same interface.
|
|
Review the source code for more details:
|
|
** https://elixir.bootlin.com/linux/v6.10.2/source/drivers/net/ipvlan/ipvlan_main.c#L82[linux/v6.10.2/source/drivers/net/ipvlan/ipvlan_main.c#L82]
|
|
** https://elixir.bootlin.com/linux/v6.10.2/source/drivers/net/macvlan.c#L1260[linux/v6.10.2/source/drivers/net/macvlan.c#L1260]
|
|
* Alternative NIC configurations include splitting the shared NIC into multiple NICs or using a single dual-port NIC, though they have not been tested and validated.
|
|
* Clusters with single-stack IP configuration are not validated.
|
|
* The `reachabilityTotalTimeoutSeconds` parameter in the `Network` CR configures the `EgressIP` node reachability check total timeout in seconds.
|
|
The recommended value is `1` second.
|
|
* Pod-level SR-IOV bonding mode must be set to `active-backup` and a value in `miimon` must be set (`100` is recommended).
|
|
|
|
Engineering considerations::
|
|
* Pod egress traffic is handled by kernel routing table using the `routingViaHost` option.
|
|
Appropriate static routes must be configured in the host.
|
|
|