mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
42 lines
3.0 KiB
Plaintext
42 lines
3.0 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * networking/metallb/about-metallb.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="nw-metallb-software-components_{context}"]
|
|
= MetalLB software components
|
|
|
|
[role="_abstract"]
|
|
In {product-title}, you get external IPs for LoadBalancer services from two MetalLB components. The controller assigns IPs from address pools, and the speaker advertises them via layer 2 or BGP.
|
|
|
|
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.
|
|
|
|
[NOTE]
|
|
====
|
|
You can configure deployment specifications in the MetalLB custom resource to manage how `controller` and `speaker` pods deploy and run in your cluster. For more information about these deployment specifications, see the _Additional resources_ section.
|
|
====
|
|
|
|
`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.
|
|
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. 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. 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 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.
|