In order to build a fair and balanced scheduler (see platform-mesh/backlog#333), we need during scheduling the ability to roughly know the number of logicalclusters scheduled on all shards.
To be refined:
Option A)
Include this data in the shard object (e.g. statusfield) as we fetch these for all scheduling anyway. Potentially the simplest solution, however this would mean we constantly update the shard object and write it to etcd.
Option B)
Allow shards to fetch the number from the metrics endpoint. I am still undecided if it is a good idea to mix the metrics domain with core functionality
Option C)
Implement a new endpoint on shards which gives out this number, which is only accessible for other shards via their shard-to-shard auth certificate.
Option D)
Frontproxy already keeps track of information on logicalclusters and the shards they are scheduled on. By having the scheduling component inside or close to frontproxy we could directly access that information. Has the advantage that the FP is already stateless.
// TODO research how existing Kubernetes scheduling retrieves this information
In order to build a fair and balanced scheduler (see platform-mesh/backlog#333), we need during scheduling the ability to roughly know the number of logicalclusters scheduled on all shards.
To be refined:
Option A)
Include this data in the shard object (e.g. statusfield) as we fetch these for all scheduling anyway. Potentially the simplest solution, however this would mean we constantly update the shard object and write it to etcd.
Option B)
Allow shards to fetch the number from the metrics endpoint. I am still undecided if it is a good idea to mix the metrics domain with core functionality
Option C)
Implement a new endpoint on shards which gives out this number, which is only accessible for other shards via their shard-to-shard auth certificate.
Option D)
Frontproxy already keeps track of information on logicalclusters and the shards they are scheduled on. By having the scheduling component inside or close to frontproxy we could directly access that information. Has the advantage that the FP is already stateless.
// TODO research how existing Kubernetes scheduling retrieves this information