mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
54 lines
3.4 KiB
Plaintext
54 lines
3.4 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 configuration of primary interface MTU settings, OVN gateway modes 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.
|
|
* EgressIP
|
|
** EgressIP failover time depends on the `reachabilityTotalTimeoutSeconds` parameter in the `Network` CR.
|
|
This parameter determines the frequency of probes used to detect when the selected egress node is unreachable.
|
|
The recommended value of this parameter is `1` second.
|
|
** When EgressIP is configured with multiple egress nodes, the failover time is expected to be on the order of seconds or longer.
|
|
** On nodes with additional network interfaces EgressIP traffic will egress through the interface on which the EgressIP address has been assigned.
|
|
See the "Configuring an egress IP address".
|
|
* 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 managed by kernel routing table using the `routingViaHost` option.
|
|
Appropriate static routes must be configured in the host.
|
|
|