Merge pull request #48549 from xenolinux/event-logs

BZ2039509: Adds the instruction to read the pod logs

Author: michaelryanpeter

modules/nw-metallb-software-components.adoc

@@ -5,31 +5,28 @@
 [id="nw-metallb-software-components_{context}"]
 = MetalLB software components
 
-When you install the MetalLB Operator, the `metallb-operator-controller-manager` deployment starts a pod.
-The pod is the implementation of the Operator.
-The pod monitors for changes to all the relevant resources.
+When you install the MetalLB Operator, the `metallb-operator-controller-manager` deployment starts a pod. The pod is the implementation of the Operator. The pod monitors for changes to all the relevant resources.
 
 When the Operator starts an instance of MetalLB, it starts a `controller` deployment and a `speaker` daemon set.
 
 `controller`::
-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.
+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.
+In case of a service failure, verify you have the following entry in your `controller` pod logs:
++
+.Example output
+[source,terminal]
+----
+"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller
+----
 
 `speaker`::
-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.
+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. If the `controller` allocated the IP address to the service and service is still unavailable, read the `speaker` pod logs. If the `speaker` pod is unavailable, run the `oc describe pod -n` command.
 +
 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.
+The algorithm involves hashing the node name and the load balancer IP address. For more information, see "MetalLB and external traffic policy".
 // 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.
 
-For BGP mode, after the `controller` allocates an IP address for the service, each `speaker` pod advertises the load balancer IP address with its BGP peers.
-You can configure which nodes start BGP sessions with BGP peers.
+For Border Gateway Protocol (BGP) mode, after the `controller` allocates an IP address for the service, each `speaker` pod advertises the load balancer IP address with its BGP peers. You can configure which nodes start BGP sessions with BGP peers.
 
-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.
+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.