podAntiAffinity rewrite

[pasztorl]

Is your feature request related to a problem?

For example if i create a statefulset in the host cluster and add:

    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: app.kubernetes.io/instance
                operator: In
                values:
                  - test
          topologyKey: kubernetes.io/hostname

then I add the same statefulset on the vcluster environment the pods will not schedule because of the app.kubernetes.io/instance will be the same and the previous statefulset use all available nodes in the example.

Which solution do you suggest?

I"m not sure what can be broken if vlcuster rewrite this label in the statefulset everywhere.. just asking this is something that vcluster plan to handle in the future? or it will stay as a limitation?

Which alternative solutions exist?

No response

Additional context

No response

[cbron]

then I add the same statefulset on the vcluster environment the pods will not schedule because of the app.kubernetes.io/instance will be the same

Can you give an example of what you are seeing here. What the name of the original stateful set is in the host, and the one syncing from the virtual cluster ?

if vlcuster rewrite this label in the statefulset

Sorry I’m confused. Why do you want to rewrite the label ? Wouldn’t it make more sense to rewrite the name of the stateful set ?

[pasztorl]

sorry, i trying to be more precise, so i created a mariadb cluster crd called "test" in the host kubernetes.
The operator created the statefulset called "test"and podAntiaffinity looks the same as in my first post.

Then i created a vcluster, installed mariadb operator inside, then created the same mariadb cluster called "test".
In this case inside the vcluster podAntiaffinity will be the same. Since there is no rewrite on the pods podAntiaffinity, the vcluster created the pods in the host cluster with the same podAntiaffinity. That means the pods created by by vcluster can't run on the nodes which already have pods with the same app.kubernetes.io/instance name.

Yes, of course I can add another name to the mariadb crd installed on the vcluster. The main reason why i posted this issue is that in the current vcluster workflow it seems the user need to take care of this, so vcluster does not manage the potential conflicting antiaffinity rules.

To resolve this, it is a solution if vcluster rewrite the app.kubernetes.io/instance and app.kubernetes.io/name and also the podAntiaffinity rules by extending it with vlcuster name and namespace but i not sure about this is the right thing.
What do you think?

Why it can be useful? With this approach user can run multiple vclusters with inside the same installments, so testing applications is easier. In my example I need to call mariadb an another name to avoid the conflict, but in this case the service name will also change so i need to apply different configuration for the applications if i run it multiple test environments.

I can place a mutation webhook to the host kubernetes to "fix" this, but in this case can you inform about what will vcluster do if the created pod have modified app.kubernetes.io/instance, app.kubernetes.io/name and podAntiaffinity rules?