Base pod & service labels not copied to canary and primary

[AshDerTest]

Describe the bug

Flagger primary and canary pods and services do not carry over the base pod and service custom labels, into the flagger-created resources but keep the annotations.

It would be advantageous to have more control over this in some form (in the Canary definition),

If the intention is to add additional labels from a flagger perspective this should be appendedand only have additive, and non-destructive abilties to the labels and selectors.

To Reproduce

Expected behavior

All base pod and service labels and annotations to be carried over to the primary and canary resources created. Or Labels should be able to be defined in the Canary definition

Additional context

• Flagger version: 1.25.0
• Kubernetes version: v1.25.5
• Service Mesh provider: n/a
• Ingress provider: traefik

[clux]

Yeah, something like this would be good to provide for at least the created Service and Deployment resource.

The recommended kubernetes labels are difficult to use as native flagger selectorLabels because appending -primary to them has negative consequences for existing alerts, service registries, so having flagger copy labels like app.kubernetes.io/name and the common shorthand app feels like a good minimum to be able to do if they exist.

Blanket copy might be less sane given stuff like app.kubernetes.io/version that should ideally differ between the primary and canary. Maybe some kind of whitelist for labels makes sense?

[aryan9600]

You can use the --include-label-prefix flag for this. For example if you start Flagger with --selector-labels=name and --include-label-prefix=app.kubernetes.io/name,app.kubernetes.io/component, then the primary deployment will have the labels: name: podinfo-primary, app.kubernetes.io/name: podinfo, app.kubernetes.io/component: podinfo.

Note that the default value of --selector-labels is app,name,app.kubernetes.io/name and the comma separated list is more of an ordered enum. By ordered enum, I mean that the first label in the list thats found in the canary Deployment ends up getting -primary appended to its value for the primary Deployment and the other labels in the list are not considered.

[clux]

Thanks @aryan9600 that works great for the main Deployment object created. It doesn't seem to get added to the created Sevice objects though.

[stefanprodan]

For Kubernetes Services see https://fluxcd.io/flagger/usage/how-it-works/#canary-service

[clux]

Ah, perfect. That should do it. Thank you! EDIT: yep, this sorted everything on my end.

[Multiply]

Is there are good way to copy the app.kubernetes.io/version from canary deployment -> canary service, and primary deployment -> primary service, other than manually setting them on the Canary directly?

If I set them on the canary directly they seem to be added right away to the service, however, if it fails to roll out, it seems they stay as the "new" version, even though it's incorrect.

Looking at the code, I can't see an easy way to achieve this right now.

[dogzzdogzz]

We also need our custom labels and annotations being copied for the KEDA scaledObject or all *-primary resources for our custom validation or mutation