Design and implement a config for distributed execution setup

[yorugac]

Currently k6-operator supports only the simplest straight-forward distributed setup when 100% of execution is spread in equal chunks 100% / N to N runners. But k6 is far more versatile which is fully utilized by k6 Cloud in distribution parameter. It would be good to include this versatility into k6-operator as well.

Setup of k6-operator already allows passing all necessary options; the main caveat is in how best to configure distribution. Sample options to consider:

1. N fraction numbers

parallelism: 4
distribution: 1/3, 1/6, 1/6, 1/3

2. N percentages

parallelism: 4
distribution: 0.33, 0.17, 0.17, 0.33

3. Since number of runners can be large, more generalized approach to defining distribution may be necessary. E.g., for 30 runners with 1/60 load and 10 runners with 1/20 load:

parallelism: 40
distribution: 30:1/60, 10:1/20

4. Something else?

No matter what config option is chosen, validation will be needed for:
a) the format of distribution is sufficient, e.g. exactly N numbers
b) final distribution adds up to 1

[yorugac]

A similar proposal was recently described here: #240 (comment)

---

A few additional thoughts.

While it's possible to implement such an addition, it'd also add quite a bit of complexity into k6-operator with little new additional value. I.e. the logic for distribution is part of k6 but IIRC, that code is not meant to be used by external parties so the logic will have to be partially duplicated, hacked, etc.

From UX perspective, in k6 Cloud the distribution parameter is configured much more simpler than execution segments: it's just a percent number. distribution parameter is also targeting load zones, not individual runners as it'd have to at the level of execution segments and K6 CRD. Given the future addition of private load zones, it might make sense to consider this addition for PLZ tests instead.

Last but not least, in context of grafana/k6#140, it's likely there will appear another way to approach this issue in k6 altogether.

[pears-one]

In order to implement this, wouldn't the main changes be to https://github.com/grafana/k6-operator/blob/main/pkg/segmentation/segmentation.go ? I don't understand what logic you were talking about needing to hack?

grafana/k6#140 sounds great, but this would surely affect more about the operator than just this issue right?

[yorugac]

@evanfpearson sorry for the delay but here are the clarifications on the above 😅

In order to implement this, wouldn't the main changes be to https://github.com/grafana/k6-operator/blob/main/pkg/segmentation/segmentation.go ? I don't understand what logic you were talking about needing to hack?

Here I meant the lower-level code in k6 itself, i.e. https://github.com/grafana/k6/tree/master/lib
k6-operator should not re-implement what is already present in k6, like dynamic calculation of execution segments.

grafana/k6#140 sounds great, but this would surely affect more about the operator than just this issue right?

Yes, absolutely. There will be some changes in k6-operator but I hope we'll be able to keep them to the minimum, i.e. without impacting the core logic of controllers.
But beyond 'simple' switch to distributed mode, grafana/k6#140 might potentially open up new approaches to explore.