Skip to content

Commit 86e60a4

Browse files
committed
OSDOCS-14356: Added bond best practices to the networking docs
1 parent 10220ca commit 86e60a4

8 files changed

+33
-24
lines changed

installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -28,6 +28,9 @@ include::modules/ipi-install-configuring-networking.adoc[leveloffset=+1]
2828
// Creating a manifest object that includes a customized `br-ex` bridge
2929
include::modules/creating-manifest-file-customized-br-ex-bridge.adoc[leveloffset=+1]
3030

31+
// Open vSwitch (OVS) bonding
32+
include::modules/nw-ovs-bonding.adoc[leveloffset=+1]
33+
3134
// Scale each machine set to compute nodes
3235
include::modules/creating-scaling-machine-sets-compute-nodes-networking.adoc[leveloffset=+2]
3336

installing/installing_bare_metal/ipi/ipi-install-post-installation-configuration.adoc

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,9 @@ include::modules/nw-enabling-a-provisioning-network-after-installation.adoc[leve
1717
// Creating a manifest object that includes a customized `br-ex` bridge
1818
include::modules/creating-manifest-file-customized-br-ex-bridge.adoc[leveloffset=+1]
1919

20+
// Open vSwitch (OVS) bonding
21+
include::modules/nw-ovs-bonding.adoc[leveloffset=+1]
22+
2023
// Services for a user-managed load balancer
2124
include::modules/nw-osp-services-external-load-balancer.adoc[leveloffset=+1]
2225

installing/installing_bare_metal/upi/installing-bare-metal-network-customizations.adoc

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -69,6 +69,9 @@ include::modules/installation-load-balancing-user-infra.adoc[leveloffset=+2]
6969
// Creating a manifest object that includes a customized `br-ex` bridge
7070
include::modules/creating-manifest-file-customized-br-ex-bridge.adoc[leveloffset=+1]
7171

72+
// Open vSwitch (OVS) bonding
73+
include::modules/nw-ovs-bonding.adoc[leveloffset=+1]
74+
7275
// Scale each machine set to compute nodes
7376
include::modules/creating-scaling-machine-sets-compute-nodes-networking.adoc[leveloffset=+2]
7477

installing/installing_bare_metal/upi/installing-bare-metal.adoc

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -90,6 +90,9 @@ include::modules/installation-load-balancing-user-infra.adoc[leveloffset=+2]
9090
// Creating a manifest object that includes a customized `br-ex` bridge
9191
include::modules/creating-manifest-file-customized-br-ex-bridge.adoc[leveloffset=+1]
9292

93+
// Open vSwitch (OVS) bonding
94+
include::modules/nw-ovs-bonding.adoc[leveloffset=+1]
95+
9396
// Scale each machine set to compute nodes
9497
include::modules/creating-scaling-machine-sets-compute-nodes-networking.adoc[leveloffset=+2]
9598

installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -84,6 +84,9 @@ include::modules/installation-load-balancing-user-infra.adoc[leveloffset=+2]
8484
// Creating a manifest object that includes a customized `br-ex` bridge
8585
include::modules/creating-manifest-file-customized-br-ex-bridge.adoc[leveloffset=+1]
8686

87+
// Open vSwitch (OVS) bonding
88+
include::modules/nw-ovs-bonding.adoc[leveloffset=+1]
89+
8790
// Scale each machine set to compute nodes
8891
include::modules/creating-scaling-machine-sets-compute-nodes-networking.adoc[leveloffset=+2]
8992

modules/installation-network-user-infra.adoc

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -87,6 +87,15 @@ endif::ibm-z[]
8787
ifndef::ibm-z[]
8888
During the initial boot, the machines require an IP address configuration that is set either through a DHCP server or statically by providing the required boot options. After a network connection is established, the machines download their Ignition config files from an HTTP or HTTPS server. The Ignition config files are then used to set the exact state of each machine. The Machine Config Operator completes more changes to the machines, such as the application of new certificates or keys, after installation.
8989

90+
Use a DHCP server for the long-term management of the machines for your cluster. Ensure that the DHCP server is configured to provide persistent IP addresses, DNS server information, and hostnames to the cluster machines. As a cluster administrator, ensure that you reserve the following IP addresses components that interact with the DHCP server:
91+
92+
* Two unique virtual IP (VIP) addresses. One VIP address for the API endpoint and one VIP address for the wildcard ingress endpoint.
93+
* One IP address for the provisioner node.
94+
* An IP address for each control plane node.
95+
* An IP address for each compute node.
96+
97+
If you have multiple network interfaces that interact with a bonded interface, reserve the same IP addresses for these multiple network interfaces so to ensure better load balancing, fault tolerance, and bandwidth capabilites for your cluster network infrastructure.
98+
9099
[NOTE]
91100
====
92101
* It is recommended to use a DHCP server for long-term management of the cluster machines. Ensure that the DHCP server is configured to provide persistent IP addresses, DNS server information, and hostnames to the cluster machines.

modules/installation-user-infra-machines-static-network.adoc

Lines changed: 8 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -287,9 +287,14 @@ ifndef::ibm-z[]
287287
[discrete]
288288
=== Bonding multiple SR-IOV network interfaces to a dual port NIC interface
289289

290-
Optional: You can bond multiple SR-IOV network interfaces to a dual port NIC interface by using the `bond=` option.
290+
As an optional configuration, you can bond multiple SR-IOV network interfaces to a dual port NIC interface by using the `bond=` option. To apply this configuration to your cluster, complete the procedure steps for each node that runs on your cluster.
291291

292-
On each node, you must perform the following tasks:
292+
[IMPORTANT]
293+
====
294+
If your network configuration includes an Open vSwitch (OVS) interface and you enabled `active-backup` bond mode, you must specify a Media Access Control (MAC) address failover. This configuration prevents node communication issues with the bonded interfaces, such as `eno1f0` and `eno2f0`.
295+
====
296+
297+
.Procedure
293298

294299
ifndef::installing-ibm-power[]
295300
. Create the SR-IOV virtual functions (VFs) following the guidance in link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_virtualization/managing-virtual-devices_configuring-and-managing-virtualization#managing-sr-iov-devices_managing-virtual-devices[Managing SR-IOV devices]. Follow the procedure in the "Attaching SR-IOV networking devices to virtual machines" section.
@@ -314,6 +319,7 @@ The following examples illustrate the syntax you must use:
314319
----
315320
bond=bond0:eno1f0,eno2f0:mode=active-backup
316321
ip=bond0:dhcp
322+
fail_over_mac=1
317323
----
318324

319325
** To configure the bonded interface to use a static IP address, enter the specific IP address you want and related information. For example:
@@ -393,12 +399,6 @@ a|Override the Ignition platform ID for the installed system.
393399
a|`--console <spec>`
394400
a|Set the kernel and bootloader console for the installed system. For more information about the format of `<spec>`, see the link:https://www.kernel.org/doc/html/latest/admin-guide/serial-console.html[Linux kernel serial console] documentation.
395401

396-
a|`--append-karg <arg>...`
397-
a|Append a default kernel argument to the installed system.
398-
399-
a|`--delete-karg <arg>...`
400-
a|Delete a default kernel argument from the installed system.
401-
402402
a|`-n`, `--copy-network`
403403
a|Copy the network configuration from the install environment.
404404

@@ -464,12 +464,6 @@ a|Specify the kernel and bootloader console for the destination system.
464464
a|`--dest-device <path>`
465465
a|Install and overwrite the specified destination device.
466466

467-
a|`--dest-karg-append <arg>`
468-
a|Add a kernel argument to each boot of the destination system.
469-
470-
a|`--dest-karg-delete <arg>`
471-
a|Delete a kernel argument from each boot of the destination system.
472-
473467
a|`--network-keyfile <path>`
474468
a|Configure networking by using the specified NetworkManager keyfile for live and destination systems.
475469

@@ -488,15 +482,6 @@ a|Apply the specified installer configuration file.
488482
a|`--live-ignition <path>`
489483
a|Merge the specified Ignition config file into a new configuration fragment for the live environment.
490484

491-
a|`--live-karg-append <arg>`
492-
a|Add a kernel argument to each boot of the live environment.
493-
494-
a|`--live-karg-delete <arg>`
495-
a|Delete a kernel argument from each boot of the live environment.
496-
497-
a|`--live-karg-replace <k=o=n>`
498-
a|Replace a kernel argument in each boot of the live environment, in the form `key=old=new`.
499-
500485
a|`-f`, `--force`
501486
a|Overwrite an existing Ignition config.
502487

modules/nw-understanding-networking-service-to-pod.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ Key concepts of service-to-pod communication include:
2828

2929
Services use selectors to identify the pods that should receive the traffic. The selectors match labels on the pods to determine which pods are part of the service. Example: A service with the selector `app: myapp` will route traffic to all pods with the label `app: myapp`.
3030

31-
Endpoints are dynamically updated to reflect the current IP addresses of the pods that match the service selector. {product-name} maintains these endpoints and ensures that the service routes traffic to the correct pods.
31+
Endpoints are dynamically updated to reflect the current IP addresses of the pods that match the service selector. {product-title} maintains these endpoints and ensures that the service routes traffic to the correct pods.
3232

3333
The communication flow refers to the sequence of steps and interactions that occur when a service in Kubernetes routes traffic to the appropriate pods. The typical communication flow for service-to-pod communication is as follows:
3434

0 commit comments

Comments
 (0)