k6.spec.separate also applies affinity to starter-pod

[cmergenthaler]

Brief summary

Hi,

it seems that when separating runners to different nodes, the starter-pod is also been scheduled on its own node. Is this intended?

k6-operator version or image

0.0.8

K6 YAML

apiVersion: k6.io/v1alpha1
kind: K6
metadata:
name: k6-test
spec:
parallelism: 2
separate: true

Other environment details (if applicable)

No response

Steps to reproduce the problem

Deploy k6 CRD with separate=true

Expected behaviour

AntiAffinity should only affect runner-pods not initializer and starter

Actual behaviour

AntiAffinity is applied to runner and starter pods

[yorugac]

To answer the question, separate is not anti-affinity: it is a shortcut option specific to k6-operator only while Kubernetes options affinity and anti-affinity can be defined as well. separate also overrides Kubernetes affinity option if it is defined. We probably should make that more explicit in the docs 🤔

That said, this is more a matter of agreement on the UX. separate option was added even before initializer pod appeared. However, both starter and initializer are rather short-living pods and are not acting as load generators, so it is reasonable to assume that a user of the operator probably cares only about runners' execution being spread out without using two additional nodes.

So I agree that this change would be an improvement 👍 Thanks for opening the issue and working on it @cmergenthaler!