Support different labeling for canary and primary deployments

[tetsundo]

Describe the feature

Hi, I was wondering if there is a function to set different labels for canary and primary objects as per this proposed solution(#1032). I have a different problem than this, but the proposed solution was the same. Unfortunately, the final update(#1092 ) wasn't what I was looking for.

I want to set different labels for canary and primary deployment to distinguish between those traffic. In the current implementation, the primary object will be copied from the canary object with same labels after a canary analysis to promote the new version. There is no way to set different labels for primary objects.

Proposed solution

I want flagger to allow labels override on the primary deployment. As proposed in the other previous request(#1032), this would be a change to be the canary spec in a form similar to how service overrides work today.

  deployment:
    primary:
      annotations:
        key1: value1
      labels:
        key1: value1

[pclalv]

I was disappointed to discover that Flagger totally mangles my pod labels when it creates the -primary resources.

I was further disappointed to discover that Flagger's default behavior is to mangle the app.kubernetes.io/name label in a way that's inconsistent with the recommendations from the official k8s docs. in particular, Flagger's behavior is to append -primary to the value of that label, resulting in, for example, app.kubernetes.io/name: mysql-primary. it seems to me that it would be more consistent with the documentation to append -primary to the app.kubernetes.io/instance label (for example, app.kubernetes.io/instance: mysql-abcxyz-primary).

ultimately I would really like for Flagger to not mess with my labels at all, or i. I think that the most conservative labeling strategy that flagger could take would be to copy labels and selectors verbatim and transform them very specifically by adding a label like canary.flagger.io/primary: true or something. with this approach, my original labels would select both the canary and primary and resources, and then I could further select the primary only or canary only with the canary.flagger.io/primary label.

it would be a nice to have more control over this, or to be able to trust Flagger to make only additive, non-destructive changes to my sets of labels and selectors.

[eloo]

Hi, just stumbled of this issue while working with Kyverno and here we see another use case for specific canary/primary labels. As we want for example to not background check our canaries.. we are mostly interesting in checking the primaries with our Kyverno policies. Using labels here to exclude the canaries would be the best solution for our use case.

[AshDerTest]

Hi

Just wanted to find out of there was any update to the above, as we are attempting to achieve a similar outcome. I require the labels from my initial pod to be carried over into the primary and canary pods

[pizzqc]

Is there a way to statically specify the labels we want in the deployment generated by Flagger for now? (i.e.: *-primary)

Our use-case is a label we need for the backstage kubernetes plugin that requires a label matching its selector. For example: backstage.io/kubernetes-id: greeter-service. The issue we are having now is that the only deployment that keeps the label properly is the one defined in our initial deployment (i.e.: the canary one) leaving the deployment *-primary with none of our labels.

I found there was some extra stuff added to the canary spec allowing us to configure the apex, primary and canary labels for kind=service that are managed by Flagger... maybe something similar for kind=deployments? (ref: https://github.com/fluxcd/flagger/pull/538)