The controller automatically finds workers under available controllers

Boundary
1

Hello, I found that if the ‘A’ instance only starts the controller and another ‘B’ instance starts the controller and worker, then the client accesses the ‘A’ controller and will find the workers of the ‘B’ instance during session connection. I’m curious about how this is achieved?

production
production1780×1640 115 KB

Of course, the official architecture diagram also indicates the dotted line relationship between controllers.

Thanks

2 
TCP Target Options:

  -default-port=<string>
      The default port to set on the target.

  -session-connection-limit=<string>
      The maximum number of connections allowed for a session. -1 means
      unlimited.

  -session-max-seconds=<string>
      The maximum lifetime of the session, including all connections. Can be
      specified as an integer number of seconds or a duration string.

  -worker-filter=<string>
      A boolean expression to filter which workers can handle sessions for
      this target.

Well, now I see that the document has a description of the filter worker. https://www.boundaryproject.io/docs/concepts/filtering/worker-tags
and https://learn.hashicorp.com/tutorials/boundary/target-aware-workers

3

To elaborate a bit, the worker and controller threads are completely separate logically even if they’re running as part of the same process on the same host. Workers will be checking in with one or more controllers (depending on their configuration) to notify that they can accept authorized client connections, and controllers all have access to the same database.

I believe the way this works is that as soon as a worker checks in with any controller, that controller will write info about that worker in the DB, and other controllers will then be aware of its existence as soon as they read those changes from the database even if the workers never connect to that controller. I think as a best practice workers should be configured to be aware of all controllers but I don’t think it’s strictly necessary.

1 Like
4

It’s actually a bit the other way around: when a worker connects to any controller (using the initial addresses from the controllers field in the worker block), it starts heartbeating status to the controller. In the response to that heartbeat, the controller tells the worker about any other controllers in the cluster. The worker then opens connections to any controllers it doesn’t currently have connections to.

This is done for redundancy and load balancing; in this way you can scale up or down the number of controllers without worrying about workers losing their ability to perform their functions.

3 Likes