Regrading the limit interface, let me check I think this is worked on (i.e. nice interface that should be pushed in the next few days). Let me get back to you on this one.

How will imposing an instance limit , prevent or allow --order-fairness feature for example, which exists when running in clearml-agent version compared to k8s_glue_example version ?

A bit of background on how the glue works:
It pulls jobs from the clearml queue, then it prepares a k8s job, and launches the k8s jobs on the cluster.
By default it will just pull any job on the queue and push it into the k8s, which means the k8s is responsible for order (which it has no actual priority/order).
In the limit mode (i.e. ports mode or any other limitation), the glue will Not pull jobs from the clearml queue of the current number of running jobs in the k8s reached a limit. This means that the priority of the jobs is guaranteed (as they are not pulled from the queue), assuming all any k8s job will be "immediately" launched (as opposed to pending on the k8s pod limitation)
Make sense ?