ESmith
02/21/2025, 11:59 AMMarvin
02/21/2025, 11:59 AMbackgroundService from the actual server can be considered a better practice in some cases. It allows for more granular control over the components, which can be useful for scaling and resource allocation. However, the Helm chart does not currently allow specifying the number of replicas for the backgroundService. This could be due to design decisions or limitations in the current implementation.
There are no open issues in the Prefect Helm repository regarding this, so it's unclear if this is an oversight or a deliberate choice. If scaling the backgroundService is crucial for your deployment, you might consider contributing to the Prefect Helm repository or opening an issue to discuss this feature.
For more details on deploying with Helm, you can refer to the Prefect Kubernetes deployment guide.ESmith
02/21/2025, 12:00 PMMarvin
02/21/2025, 12:00 PMbackgroundService running with the server itself and your server has 2 replicas, the backgroundService will indeed run on each server replica. This effectively means that the backgroundService is running in a form of "high availability" (HA), as each replica of the server will also have a corresponding instance of the backgroundService.
However, it's important to note that running multiple instances of the backgroundService does not necessarily mean they are coordinated or load-balanced in the way typical HA setups are. You should ensure that the services are designed to handle concurrent operations without issues.
For more detailed architecture considerations, reviewing the specific functionality of the backgroundService in your Prefect setup would be advisable.Mitch Nielsen
02/21/2025, 3:58 PM