You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* See xref:../../../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring] for more information about the Telemetry service
* See xref:../../../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring] for more information about the Telemetry service
* See xref:../../../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring] for more information about the Telemetry service
Copy file name to clipboardExpand all lines: modules/installation-launching-installer.adoc
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -311,7 +311,7 @@ ifdef::vsphere[]
311
311
+
312
312
[IMPORTANT]
313
313
====
314
-
You do not need to specify API and Ingress static addresses for your installation program. If you choose this configuration, you must take additional actions to define network targets that accept an IP address from each referenced vSphere subnet. See the section "Configuring an external load balancer".
314
+
You do not need to specify API and Ingress static addresses for your installation program. If you choose this configuration, you must take additional actions to define network targets that accept an IP address from each referenced vSphere subnet. See the section "Configuring a user-managed load balancer".
Configure an external load balancer in {rh-openstack-first} to use your own load balancer, resolve external networking needs, or scale beyond what the default {product-title} load balancer can provide.
to use an external load balancer in place of the default load balancer.
25
+
to use a user-managed load balancer in place of the default load balancer.
32
26
33
27
[IMPORTANT]
34
28
====
35
-
Before you configure an external load balancer, ensure that you read the "Services for an external load balancer" section.
29
+
Before you configure a user-managed load balancer, ensure that you read the "Services for a user-managed load balancer" section.
36
30
====
37
31
38
-
Read the following prerequisites that apply to the service that you want to configure for your external load balancer.
32
+
Read the following prerequisites that apply to the service that you want to configure for your user-managed load balancer.
39
33
40
34
[NOTE]
41
35
====
42
-
MetalLB, that runs on a cluster, functions as an external load balancer.
36
+
MetalLB, which runs on a cluster, functions as a user-managed load balancer.
43
37
====
44
38
45
39
.OpenShift API prerequisites
@@ -64,7 +58,7 @@ MetalLB, that runs on a cluster, functions as an external load balancer.
64
58
65
59
You can configure most load balancers by setting health check URLs that determine if a service is available or unavailable. {product-title} provides these health checks for the OpenShift API, Machine Configuration API, and Ingress Controller backend services.
66
60
67
-
The following examples demonstrate health check specifications for the previously listed backend services:
61
+
The following examples show health check specifications for the previously listed backend services:
68
62
69
63
.Example of a Kubernetes API health check specification
70
64
@@ -157,7 +151,7 @@ listen my-cluster-apps-80
157
151
# ...
158
152
----
159
153
160
-
. Use the `curl` CLI command to verify that the external load balancer and its resources are operational:
154
+
. Use the `curl` CLI command to verify that the user-managed load balancer and its resources are operational:
161
155
+
162
156
.. Verify that the cluster machine configuration API is accessible to the Kubernetes API server resource, by running the following command and observing the response:
163
157
+
@@ -239,7 +233,7 @@ set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; p
239
233
cache-control: private
240
234
----
241
235
242
-
. Configure the DNS records for your cluster to target the front-end IP addresses of the external load balancer. You must update records to your DNS server for the cluster API and applications over the load balancer.
236
+
. Configure the DNS records for your cluster to target the front-end IP addresses of the user-managed load balancer. You must update records to your DNS server for the cluster API and applications over the load balancer.
243
237
+
244
238
.Examples of modified DNS records
245
239
+
@@ -260,7 +254,30 @@ A record pointing to Load Balancer Front End
260
254
DNS propagation might take some time for each DNS record to become available. Ensure that each DNS record propagates before validating each record.
261
255
====
262
256
263
-
. Use the `curl` CLI command to verify that the external load balancer and DNS record configuration are operational:
257
+
ifdef::bare-metal[]
258
+
. For your {product-title} cluster to use the user-managed load balancer, you must specify the following configuration in your cluster's `install-config.yaml` file:
259
+
+
260
+
[source,yaml]
261
+
----
262
+
# ...
263
+
platform:
264
+
baremetal:
265
+
loadBalancer:
266
+
type: UserManaged <1>
267
+
apiVIPs:
268
+
- <api_ip> <2>
269
+
ingressVIPs:
270
+
- <ingress_ip> <3>
271
+
# ...
272
+
----
273
+
<1> Set `UserManaged` for the `type` parameter to specify a user-managed load balancer for your cluster. The parameter defaults to `OpenShiftManagedDefault`, which denotes the default internal load balancer. For services defined in an `openshift-kni-infra` namespace, a user-managed load balancer can deploy the `coredns` service to pods in your cluster but ignores `keepalived` and `haproxy` services.
274
+
<2> Required parameter when you specify a user-managed load balancer. Specify the user-managed load balancer's public IP address, so that the Kubernetes API can communicate with the user-managed load balancer.
275
+
<3> Required parameter when you specify a user-managed load balancer. Specify the user-managed load balancer's public IP address, so that the user-managed load balancer can manage ingress traffic for your cluster.
276
+
endif::bare-metal[]
277
+
278
+
.Verification
279
+
280
+
. Use the `curl` CLI command to verify that the user-managed load balancer and DNS record configuration are operational:
264
281
+
265
282
.. Verify that you can access the cluster API, by running the following command and observing the output:
266
283
+
@@ -352,15 +369,6 @@ set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; p
to use an external load balancer in place of the default load balancer.
21
+
to use a user-managed load balancer in place of the default load balancer.
32
22
33
23
[IMPORTANT]
34
24
====
35
-
Configuring an external load balancer depends on your vendor's load balancer.
25
+
Configuring a user-managed load balancer depends on your vendor's load balancer.
36
26
37
27
The information and examples in this section are for guideline purposes only. Consult the vendor documentation for more specific information about the vendor's load balancer.
38
28
====
39
29
40
-
Red Hat supports the following services for an external load balancer:
30
+
Red Hat supports the following services for a user-managed load balancer:
41
31
42
32
* Ingress Controller
43
33
* OpenShift API
44
34
* OpenShift MachineConfig API
45
35
46
-
You can choose whether you want to configure one or all of these services for an external load balancer. Configuring only the Ingress Controller service is a common configuration option. To better understand each service, view the following diagrams:
36
+
You can choose whether you want to configure one or all of these services for a user-managed load balancer. Configuring only the Ingress Controller service is a common configuration option. To better understand each service, view the following diagrams:
47
37
48
38
.Example network workflow that shows an Ingress Controller operating in an {product-title} environment
49
39
image::external-load-balancer-default.png[An image that shows an example network workflow of an Ingress Controller operating in an {product-title} environment.]
@@ -54,7 +44,7 @@ image::external-load-balancer-openshift-api.png[An image that shows an example n
54
44
.Example network workflow that shows an OpenShift MachineConfig API operating in an {product-title} environment
55
45
image::external-load-balancer-machine-config-api.png[An image that shows an example network workflow of an OpenShift MachineConfig API operating in an {product-title} environment.]
56
46
57
-
The following configuration options are supported for external load balancers:
47
+
The following configuration options are supported for user-managed load balancers:
58
48
59
49
* Use a node selector to map the Ingress Controller to a specific set of nodes. You must assign a static IP address to each node in this set, or configure each node to receive the same IP address from the Dynamic Host Configuration Protocol (DHCP). Infrastructure nodes commonly receive this type of configuration.
60
50
@@ -65,25 +55,12 @@ The following configuration options are supported for external load balancers:
65
55
You can list all IP addresses that exist in a network by checking the machine config pool's resources.
66
56
====
67
57
68
-
Before you configure an external load balancer for your {product-title} cluster, consider the following information:
58
+
Before you configure a user-managed load balancer for your {product-title} cluster, consider the following information:
69
59
70
60
* For a front-end IP address, you can use the same IP address for the front-end IP address, the Ingress Controller's load balancer, and API load balancer. Check the vendor's documentation for this capability.
71
61
72
-
* For a back-end IP address, ensure that an IP address for an {product-title} control plane node does not change during the lifetime of the external load balancer. You can achieve this by completing one of the following actions:
62
+
* For a back-end IP address, ensure that an IP address for an {product-title} control plane node does not change during the lifetime of the user-managed load balancer. You can achieve this by completing one of the following actions:
73
63
** Assign a static IP address to each control plane node.
74
64
** Configure each node to receive the same IP address from the DHCP every time the node requests a DHCP lease. Depending on the vendor, the DHCP lease might be in the form of an IP reservation or a static DHCP assignment.
75
65
76
-
* Manually define each node that runs the Ingress Controller in the external load balancer for the Ingress Controller back-end service. For example, if the Ingress Controller moves to an undefined node, a connection outage can occur.
* Manually define each node that runs the Ingress Controller in the user-managed load balancer for the Ingress Controller back-end service. For example, if the Ingress Controller moves to an undefined node, a connection outage can occur.
0 commit comments