Merge pull request #39068 from mikemckiernan/feat-metallb-l2-nodesel

OSDOCS-2681: nodesel and new algo

Author: mikemckiernan

modules/nw-metallb-installing-operator-cli.adoc

@@ -108,10 +108,10 @@ $ oc get installplan -n metallb-system
 ----
 +
 .Example output
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
 NAME            CSV                                   APPROVAL    APPROVED
-install-wzg94   metallb-operator.4.9.0-nnnnnnnnnnnn   Automatic   true
+install-wzg94   metallb-operator.{product-version}.0-nnnnnnnnnnnn   Automatic   true
 ----
 
 . To verify that the Operator is installed, enter the following command:
@@ -123,9 +123,9 @@ $ oc get clusterserviceversion -n metallb-system \
 ----
 +
 .Example output
-[source,terminal]
+[source,terminal,subs="attributes+"]
 ----
 Name                                  Phase
-metallb-operator.4.9.0-nnnnnnnnnnnn   Succeeded
+metallb-operator.{product-version}.0-nnnnnnnnnnnn   Succeeded
 ----
 

modules/nw-metallb-operator-limit-speaker-to-nodes.adoc

@@ -0,0 +1,33 @@
+// Module included in the following assemblies:
+//
+// * networking/metallb/metallb-operator-install.adoc
+
+[id="nw-metallb-operator-limit-speaker-to-nodes_{context}"]
+= Limit speaker pods to specific nodes
+
+By default, when you start MetalLB with the MetalLB Operator, the Operator starts an instance of a `speaker` pod on each node in the cluster.
+Only the nodes with a `speaker` pod can advertise a load balancer IP address.
+You can configure the `MetalLB` custom resource with a node selector to specify which nodes run the `speaker` pods.
+
+The most common reason to limit the `speaker` pods to specific nodes is to ensure that only nodes with network interfaces on specific networks advertise load balancer IP addresses.
+Only the nodes with a running `speaker` pod are advertised as destinations of the load balancer IP address.
+
+If you limit the `speaker` pods to specific nodes and specify `local` for the external traffic policy of a service, then you must ensure that the application pods for the service are deployed to the same nodes.
+
+.Example configuration to limit speaker pods to worker nodes
+[source,yaml]
+----
+apiVersion: metallb.io/v1beta1
+kind: MetalLB
+metadata:
+  name: metallb
+  namespace: metallb-system
+spec:
+  nodeSelector:  <.>
+    node-role.kubernetes.io/worker: ""
+----
+<.> The example configuration specifies to assign the speaker pods to worker nodes, but you can specify labels that you assigned to nodes or any valid node selector.
+
+After you apply a manifest with the `spec.nodeSelector` field, you can check the number of pods that the Operator deployed with the `oc get daemonset -n metallb-system speaker` command.
+Similarly, you can display the nodes that match your labels with a command like `oc get nodes -l node-role.kubernetes.io/worker=`.
+

modules/nw-metallb-software-components.adoc

@@ -1,3 +1,7 @@
+// Module included in the following assemblies:
+//
+// * networking/metallb/about-metallb.adoc
+
 [id="nw-metallb-software-components_{context}"]
 = MetalLB software components
 
@@ -12,14 +16,18 @@ The Operator starts the deployment and a single pod.
 When you add a service of type `LoadBalancer`, Kubernetes uses the `controller` to allocate an IP address from an address pool.
 
 `speaker`::
-The Operator starts a daemon set with one `speaker` pod for each node in your cluster.
+The Operator starts a daemon set for `speaker` pods.
+By default, a pod is started on each node in your cluster.
+You can limit the pods to specific nodes by specifying a node selector in the `MetalLB` custom resource when you start MetalLB.
 +
-For layer 2 mode, after the `controller` allocates an IP address for the service, each `speaker` pod determines if it is on the same node as an endpoint for the service.
-An algorithm that involves hashing the node name and the service name is used to select a single `speaker` pod to announce the load balancer IP address.
+For layer 2 mode, after the `controller` allocates an IP address for the service, the `speaker` pods use an algorithm to determine which `speaker` pod on which node will announce the load balancer IP address.
+The algorithm involves hashing the node name and the load balancer IP address.
+See the section about external traffic policy for more information.
 // IETF treats protocol names as proper nouns.
 The `speaker` uses Address Resolution Protocol (ARP) to announce IPv4 addresses and Neighbor Discovery Protocol (NDP) to announce IPv6 addresses.
 +
 Requests for the load balancer IP address are routed to the node with the `speaker` that announces the IP address.
 After the node receives the packets, the service proxy routes the packets to an endpoint for the service.
 The endpoint can be on the same node in the optimal case, or it can be on another node.
 The service proxy chooses an endpoint each time a connection is established.
+

networking/metallb/metallb-operator-install.adoc

@@ -26,6 +26,13 @@ include::modules/nw-metallb-installing-operator-cli.adoc[leveloffset=+1]
 // Starting MetalLB on your cluster
 include::modules/nw-metallb-operator-initial-config.adoc[leveloffset=+1]
 
+// Limit speaker pods to specific nodes
+include::modules/nw-metallb-operator-limit-speaker-to-nodes.adoc[leveloffset=+2]
+
+.Additional resources
+
+* For more information about node selectors, see xref:../../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-scheduler-node-selectors[Placing pods on specific nodes using node selectors].
+
 [id="next-steps_{context}"]
 == Next steps