Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Affinity rules with app.kubernetes.io/name labels #648

Closed
Apollorion opened this issue Jul 14, 2020 · 1 comment · Fixed by #788
Closed

Affinity rules with app.kubernetes.io/name labels #648

Apollorion opened this issue Jul 14, 2020 · 1 comment · Fixed by #788
Labels
help wanted Extra attention is needed kind/feature Feature request

Comments

@Apollorion
Copy link

Apollorion commented Jul 14, 2020

If I have a deployment that has this affinity rule:

  requiredDuringSchedulingIgnoredDuringExecution:
  - labelSelector:
      matchExpressions:                                                                                                                                                         
      - key: app.kubernetes.io/name
        operator: In
        values:
        - my-awesome-pod
    topologyKey: kubernetes.io/hostname

Flagger does not modify that value to include -primary when it updates the primary deployment. So the affinity rule only applies to the canaried deployment. Alternatively, I can also update the rule to include -primary in it. In this case, the rules only apply to the primary and not the canaried deployment.

I've thought about utilizing a different label, one that would be the same across both the canary and the primary.
The downside here is that if I have 10 pods in the deployment, it would require me to temporarily have 20 nodes because of the topologyKey since I would have 10 canaried pods and 10 primary pods.

What I'm really looking for is a way to set up something like this:

node1: my-awesome-pod, my-awesome-pod-primary 
node2: my-awesome-pod, my-awesome-pod-primary 
node3: my-awesome-pod, my-awesome-pod-primary 

instead of:

node1: my-awesome-pod, my-awesome-pod, my-awesome-pod-primary 
node2: my-awesome-pod, my-awesome-pod-primary 
node3: my-awesome-pod-primary

A suggestion would be to have Flagger parse affinity rules and add -primary to primary pods if the app.kubernetes.io/name key is found. But I wasn't sure if there was a better, simpler, way to do this.

@Apollorion Apollorion changed the title Affinity Rules with app.kubernetes.io/name labels Affinity rules with app.kubernetes.io/name labels Jul 14, 2020
@stefanprodan stefanprodan added the kind/feature Feature request label Jul 15, 2020
@stefanprodan
Copy link
Member

I think Flagger could parse the rules, extract the ones that match the label selector (can be one of app, name, app.kubernetes.io/name or something else configured at startup with --selector-labels) and append the -primary to the value. The problem is that you can have more than one value, in this case Flagger should skip the replace and log that it did so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed kind/feature Feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants