From 86834388a184801f56819b6de946bbb63b169437 Mon Sep 17 00:00:00 2001 From: dfitzmau Date: Wed, 23 Apr 2025 14:20:59 +0100 Subject: [PATCH] OCPBUGS-55288: Added note about bonded interface and node IP address issues --- ...faces-in-the-install-config.yaml-file.adoc | 31 +++++++++---------- ...lishing-communication-between-subnets.adoc | 7 ++++- 2 files changed, 21 insertions(+), 17 deletions(-) diff --git a/modules/ipi-install-configuring-host-network-interfaces-in-the-install-config.yaml-file.adoc b/modules/ipi-install-configuring-host-network-interfaces-in-the-install-config.yaml-file.adoc index be0bb72bb00d..4c4d5beef87b 100644 --- a/modules/ipi-install-configuring-host-network-interfaces-in-the-install-config.yaml-file.adoc +++ b/modules/ipi-install-configuring-host-network-interfaces-in-the-install-config.yaml-file.adoc @@ -6,7 +6,7 @@ [id="configuring-host-network-interfaces-in-the-install-config-yaml-file_{context}"] = Optional: Configuring host network interfaces -Before installation, you can set the `networkConfig` configuration setting in the `install-config.yaml` file to configure host network interfaces using NMState. +Before installation, you can set the `networkConfig` configuration setting in the `install-config.yaml` file to use NMState to configure host network interfaces. The most common use case for this functionality is to specify a static IP address on the bare-metal network, but you can also configure other networks such as a storage network. This functionality supports other NMState features such as VLAN, VXLAN, bridges, bonds, routes, MTU, and DNS resolver settings. @@ -17,36 +17,35 @@ The most common use case for this functionality is to specify a static IP addres .Procedure -. Optional: Consider testing the NMState syntax with `nmstatectl gc` before including it in the `install-config.yaml` file, because the installer will not check the NMState YAML syntax. +. Optional: Consider testing the NMState syntax with `nmstatectl gc` before including the syntax in the `install-config.yaml` file, because the installation program does not check the NMState YAML syntax. + [NOTE] ==== -Errors in the YAML syntax might result in a failure to apply the network configuration. Additionally, maintaining the validated YAML syntax is useful when applying changes using Kubernetes NMState after deployment or when expanding the cluster. +Errors in the YAML syntax might result in a failure to apply the network configuration. Additionally, maintaining the validated YAML syntax is useful when applying changes by using Kubernetes NMState after deployment or when expanding the cluster. ==== - .. Create an NMState YAML file: + [source,yaml] ---- -interfaces: -- name: <1> +interfaces: <1> +- name: type: ethernet state: up ipv4: address: - - ip: <1> + - ip: prefix-length: 24 enabled: true dns-resolver: config: server: - - <1> + - routes: config: - destination: 0.0.0.0/0 - next-hop-address: <1> - next-hop-interface: <1> + next-hop-address: + next-hop-interface: ---- + <1> Replace ``, ``, ``, `` and `` with appropriate values. @@ -77,24 +76,24 @@ Replace `` with the configuration file name. rootDeviceHints: deviceName: "/dev/sda" networkConfig: <1> - interfaces: - - name: <2> + interfaces: <2> + - name: type: ethernet state: up ipv4: address: - - ip: <2> + - ip: prefix-length: 24 enabled: true dns-resolver: config: server: - - <2> + - routes: config: - destination: 0.0.0.0/0 - next-hop-address: <2> - next-hop-interface: <2> + next-hop-address: + next-hop-interface: ---- <1> Add the NMState YAML syntax to configure the host interfaces. <2> Replace ``, ``, ``, `` and `` with appropriate values. diff --git a/modules/ipi-install-establishing-communication-between-subnets.adoc b/modules/ipi-install-establishing-communication-between-subnets.adoc index 8dd2d4df5ffa..84bc8e7e61fc 100644 --- a/modules/ipi-install-establishing-communication-between-subnets.adoc +++ b/modules/ipi-install-establishing-communication-between-subnets.adoc @@ -8,7 +8,12 @@ In a typical {product-title} cluster setup, all nodes, including the control plane and compute nodes, reside in the same network. However, for edge computing scenarios, it can be beneficial to locate compute nodes closer to the edge. This often involves using different network segments or subnets for the remote nodes than the subnet used by the control plane and local compute nodes. Such a setup can reduce latency for the edge and allow for enhanced scalability. -Before installing {product-title}, you must configure the network properly to ensure that the edge subnets containing the remote nodes can reach the subnet containing the control plane nodes and receive traffic from the control plane too. +Before installing {product-title}, you must configure the network properly to ensure that the edge subnets containing the remote nodes can reach the subnet containing the control plane nodes and receive traffic from the control plane too. + +[IMPORTANT] +==== +During cluster installation, assign permanent IP addresses to nodes in the network configuration of the `install-config.yaml` configuration file. If you do not do this, nodes might get assigned a temporary IP address that can impact how traffic reaches the nodes. For example, if a node has a temporary IP address assigned to it and you configured a bonded interface for a node, the bonded interface might receive a different IP address. +==== You can run control plane nodes in the same subnet or multiple subnets by configuring a user-managed load balancer in place of the default load balancer. With a multiple subnet environment, you can reduce the risk of your {product-title} cluster from failing because of a hardware failure or a network outage. For more information, see "Services for a user-managed load balancer" and "Configuring a user-managed load balancer".