Skip to content

Commit 1ec6d5c

Browse files
committed
docs: Adding new section for load balancing
1 parent 6e0afd4 commit 1ec6d5c

File tree

1 file changed

+20
-0
lines changed

1 file changed

+20
-0
lines changed

website/content/docs/configuration/controller.mdx

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -224,6 +224,26 @@ kms "aead" {
224224
Boundary supports many kinds of KMS integrations. For a complete guide to all available
225225
KMS types, see our [KMS documentation](/boundary/docs/configuration/kms).
226226

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.
246+
227247
## Complete configuration example
228248

229249
```hcl

0 commit comments

Comments
 (0)