Allow singleton services to have multiple instances per node bypassing placement constraint
Currently, if you try to span multiple instances of a singleton service that is greater than your cluster node count, you will face placement constraint warning and will have only the number of instances running with an warning in your cluster.
The Orchestration process should ignore the Replica Exclusion Placement Constraint to allow multiple singleton services running at same node without workaround it by using partitions.
Makes no sense to have this constraint, as the stateless we probably are not worried about losing data if the node goes down. It should have better handling for this in case your number of instances is bigger than your node count.
I would expect to:
When my cluster have 5 nodes, and my singleton service has 15 instances, to have 3 instances of each service per node.
Avi Mualem commented
This is an elementary requirement for as modern orchestrator solution.
At the end of the day, we are aiming to utilize hardware in the most efficient manner and when it comes to stateless services its totally realistic to spawn more than one instance per node in order to increase throughput.
Daniel Droke commented
This feature is a must have of any container orchestrator. Being able to densely populate service instances on same nodes is far superior over scaling nodes themselves. Scaling nodes is painfully slow, and for on-demand response times to a work queue stacking up with messages, it just isn't feasible. Being able to densely populate service instances on a node would greatly increase the ability to exercise all resources of a node.
Jared Prather commented
I would like to see this as well.
Use case: Scaling up and down a stateless service which is processing messages off of service bus via the service bus client.