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
Copy file name to clipboardExpand all lines: website/content/docs/configuration/controller.mdx
+20Lines changed: 20 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -224,6 +224,26 @@ kms "aead" {
224
224
Boundary supports many kinds of KMS integrations. For a complete guide to all available
225
225
KMS types, see our [KMS documentation](/boundary/docs/configuration/kms).
226
226
227
+
## Load balancing
228
+
229
+
You can configure controllers to work with a load balancer.
230
+
231
+
1. Configure a load balancer or reverse proxy in TCP mode to point directly to each controller's `cluster` address or use a round robin configuration.
232
+
1. Configure each controller's `initial_upstreams` attribute with the address of the load balancer.
233
+
The load balancer's address should not be any of the `public_cluster_addr` or `cluster` listener addresses.
234
+
1. Configure the `public_cluster_addr` attribute for each controller to be an address that the worker can use to directly connect to the controller after the initial connection through the load balancer.
235
+
236
+
In that initial connection, the worker is given the current set of controller addresses, sourced from each controller's `public_cluster_addr` if available, or that controller's `cluster` listener address, if it is not.
237
+
238
+
Alternatively, if you want to use a load balancer or reverse proxy for the `public_cluster_addr` addresses, it must be in TCP mode, and it it must only proxy from each controller's `public_cluster_addr` to that controller's `cluster` lisetner.
239
+
If you attemmpt to load balance across these addresses, it will result in connectivity issues and a failure of the built=in client-side load balancing.
240
+
241
+
You can use direct connections to `cluster` listener addresses and can make use of `public_cluster_addr` along with the workers' `initial_upstreams` attribute without any load balancer/proxy at all, as long as the workers can connect directly.
242
+
The load balancer/proxy is only useful if you:
243
+
244
+
- Want to have a more dynamic set of controller addresses so that you can add or remove controllers without having to update each worker's `initial_upstreams` attribute as they change.
245
+
- Want to have a TCP proxy in front of each `public_cluster_addr` or `cluster` listener address for other reasons, which is supported as long as you do not round robin or load balance and are willing to keep the `initial_upstreams` values in sync.
0 commit comments