openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

OSDOCS-16863-3: CQA for MetalLB Ingress and Route Configuration

Browse Source
This commit is contained in:
dfitzmau
2026-01-19 12:04:12 +00:00
committed by openshift-cherrypick-robot
parent 13b17a931a
commit 37571d2fd3
10 changed files with 278 additions and 278 deletions
Download Patch File Download Diff File Expand all files Collapse all files

155
networking/ingress_load_balancing/metallb/metallb-configure-services.adoc
View File

@@ -6,158 +6,15 @@ include::_attributes/common-attributes.adoc[]
toc::[]
As a cluster administrator, when you add a service of type `LoadBalancer`, you can control how MetalLB assigns an IP address.
[role="_abstract"]
To ensure predictable network endpoints, control how MetalLB assigns IP addresses to services of type `LoadBalancer`. Requesting specific addresses or pools ensures that your applications receive valid IP assignments that align with your specific network addressing plan.
// Request a specific IP address
[id="request-specific-ip-address_{context}"]
== Request a specific IP address
include::modules/request-specific-ip-address.adoc[leveloffset=+1]
Like some other load-balancer implementations, MetalLB accepts the `spec.loadBalancerIP` field in the service specification.
include::modules/request-ip-address-from-pool.adoc[leveloffset=+1]
If the requested IP address is within a range from any address pool, MetalLB assigns the requested IP address.
If the requested IP address is not within any range, MetalLB reports a warning.
include::modules/accept-any-ip-address.adoc[leveloffset=+1]
.Example service YAML for a specific IP address
[source,yaml]
----
apiVersion: v1
kind: Service
metadata:
name: <service_name>
annotations:
metallb.io/address-pool: <address_pool_name>
spec:
selector:
<label_key>: <label_value>
ports:
- port: 8080
targetPort: 8080
protocol: TCP
type: LoadBalancer
loadBalancerIP: <ip_address>
----
include::modules/share-specific-ip-address.adoc[leveloffset=+1]
If MetalLB cannot assign the requested IP address, the `EXTERNAL-IP` for the service reports `<pending>` and running `oc describe service <service_name>` includes an event like the following example.
.Example event when MetalLB cannot assign a requested IP address
[source,terminal]
----
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning AllocationFailed 3m16s metallb-controller Failed to allocate IP for "default/invalid-request": "4.3.2.1" is not allowed in config
----
[id="request-ip-address-from-pool_{context}"]
== Request an IP address from a specific pool
To assign an IP address from a specific range, but you are not concerned with the specific IP address, then you can use the `metallb.io/address-pool` annotation to request an IP address from the specified address pool.
.Example service YAML for an IP address from a specific pool
[source,yaml]
----
apiVersion: v1
kind: Service
metadata:
name: <service_name>
annotations:
metallb.io/address-pool: <address_pool_name>
spec:
selector:
<label_key>: <label_value>
ports:
- port: 8080
targetPort: 8080
protocol: TCP
type: LoadBalancer
----
If the address pool that you specify for `<address_pool_name>` does not exist, MetalLB attempts to assign an IP address from any pool that permits automatic assignment.
[id="accept-any-ip-address_{context}"]
== Accept any IP address
By default, address pools are configured to permit automatic assignment.
MetalLB assigns an IP address from these address pools.
To accept any IP address from any pool that is configured for automatic assignment, no special annotation or configuration is required.
.Example service YAML for accepting any IP address
[source,yaml]
----
apiVersion: v1
kind: Service
metadata:
name: <service_name>
spec:
selector:
<label_key>: <label_value>
ports:
- port: 8080
targetPort: 8080
protocol: TCP
type: LoadBalancer
----
[id="share-specific-ip-address_{context}"]
== Share a specific IP address
By default, services do not share IP addresses.
However, if you need to colocate services on a single IP address, you can enable selective IP sharing by adding the `metallb.io/allow-shared-ip` annotation to the services.
[source,yaml]
----
apiVersion: v1
kind: Service
metadata:
name: service-http
annotations:
metallb.io/address-pool: doc-example
metallb.io/allow-shared-ip: "web-server-svc" <1>
spec:
ports:
- name: http
port: 80 <2>
protocol: TCP
targetPort: 8080
selector:
<label_key>: <label_value> <3>
type: LoadBalancer
loadBalancerIP: 172.31.249.7 <4>
---
apiVersion: v1
kind: Service
metadata:
name: service-https
annotations:
metallb.io/address-pool: doc-example
metallb.io/allow-shared-ip: "web-server-svc"
spec:
ports:
- name: https
port: 443
protocol: TCP
targetPort: 8080
selector:
<label_key>: <label_value>
type: LoadBalancer
loadBalancerIP: 172.31.249.7
----
<1> Specify the same value for the `metallb.io/allow-shared-ip` annotation. This value is referred to as the _sharing key_.
<2> Specify different port numbers for the services.
<3> Specify identical pod selectors if you must specify `externalTrafficPolicy: local` so the services send traffic to the same set of pods. If you use the `cluster` external traffic policy, then the pod selectors do not need to be identical.
<4> Optional: If you specify the three preceding items, MetalLB might colocate the services on the same IP address. To ensure that services share an IP address, specify the IP address to share.
By default, Kubernetes does not allow multiprotocol load balancer services.
This limitation would normally make it impossible to run a service like DNS that needs to listen on both TCP and UDP.
To work around this limitation of Kubernetes with MetalLB, create two services:
* For one service, specify TCP and for the second service, specify UDP.
* In both services, specify the same pod selector.
* Specify the same sharing key and `spec.loadBalancerIP` value to colocate the TCP and UDP services on the same IP address.
// Configuring a service with MetalLB
include::modules/nw-metallb-configure-svc.adoc[leveloffset=+1]

11
networking/ingress_load_balancing/metallb/metallb-frr-k8s.adoc
View File

@@ -6,17 +6,18 @@ include::_attributes/common-attributes.adoc[]
toc::[]
FRRouting (FRR) is a free, open source internet routing protocol suite for Linux and UNIX platforms.
`FRR-K8s` is a Kubernetes based DaemonSet that exposes a subset of the `FRR` API in a Kubernetes-compliant manner.
As a cluster administrator, you can use the `FRRConfiguration` custom resource (CR) to access some of the FRR services not provided by MetalLB, for example, receiving routes.
`MetalLB` generates the `FRR-K8s` configuration corresponding to the MetalLB configuration applied.
[role="_abstract"]
To access advanced routing services not natively provided by MetalLB, configure the `FRRConfiguration` custom resource (CR). Defining the CR exposes specific FRRouting (FRR) capabilities and extends the routing functionality of your cluster beyond standard MetalLB advertisements.
FRRouting (FRR) is a free, open-source internet routing protocol suite for Linux and UNIX platforms. `FRR-K8s` is a Kubernetes-based DaemonSet that exposes a subset of the `FRR` API in a Kubernetes-compliant manner. `MetalLB` generates the `FRR-K8s` configuration corresponding to the MetalLB configuration applied.
image::695_OpenShift_MetalLB_FRRK8s_integration_0624.png[MetalLB integration with FRR]
[WARNING]
====
When configuring Virtual Route Forwarding (VRF) users must change their VRFs to a table ID lower than 1000 as higher than 1000 is reserved for {product-title}.
When configuring Virtual Route Forwarding (VRF), you must change the VRFs to a table ID lower than `1000` as higher than `1000` is reserved for {product-title}.
====
// FRR configurations
include::modules/nw-metallb-frr-configurations.adoc[leveloffset=+1]