use of the Kubernetes-recommended app.kubernetes.io/name label

[pclalv]

one of my goals in labeling my k8s resources is to label according to the Kubernetes docs' recommended labels page. so, any instance of an app named myapp gets the label app.kubernetes.io/name: myapp. let's say that I run two prod instances of myapp, named myapp-prod0 and myapp-prod1, which are each associated with a Deployment of the same name. those Deployments get the more specific (relative to app.kubernetes.io/instance) labels app.kubernetes.io/instance: myapp-prod0 and app.kubernetes.io/instance: myapp-prod1, respectively, in addition to app.kubernetes.io/name: myapp. this seems to agree with the recommended labels doc. for simplicity's sake, we can ignore the other labels (both the recommended labels, and whatever other labels my resources have).

let's say that both instances are hooked up for Flagger Canary. in that case, Flagger generates primary Deployments myapp-prod0-primary and myapp-prod1-primary, which both have only the selector app.kubernetes.io/name: myapp-primary as the value for .spec.selector.matchLabels. this has implications for how Flagger's primary Deployments and primary Service select their pods - namely, the Deployment and Service for myapp-prod0-primary select pods belonging to myapp-prod1-primary, and just the same the Deployment and Service for myapp-prod1-primary select pods belonging to myapp-prod0-primary. this is a mess, unfortunately, and it precludes me from safely running multiple Flagger Canary-enabled instances of my apps alongside one another and labeled according to the Kubernetes docs' recommendations. it occurs to me that this issue might be less severe if Flagger copied the entire set of labels to its canary resources, rather than just of one of app, name, or app.kubernetes.io/name, although this really depends on the particular labels and values.

if I want to run multiple instances of myapp, ad label them according to the recommended labels, then I have these choices:

• don't use Flagger.
• don't run multiple instances of the same app all hooked up to Flagger. this seems reasonable, but it's not always a good option - consider my staging cluster, which runs 'primary' instances of staging apps. the primary staging instance of myapp has Flagger Canary configured, to match prod - now, say I want to play with the Flagger configuration for myapp without disrupting the primary staging instance - I would like for the easiest way to do this to be to run an independent instance of myapp alongside the primary staging instance.
• violate the recommendation by setting app.kubernetes.io/app to some more-specific value, say myapp-prod0, so that Flagger's primary resources can use ``app.kubernetes.io/app: myapp-prod0-primary` to select their resources more specifically.
• set selectorLabels to some label that Flagger can safely use. if I still choose to use Flagger, then I'm thinking that I'll go with a label like mycompany.com/flagger-canary-selector, so that Flagger can use that and not interfere with my labeling. this is the approach that I think I'll go with, and I do find it useful that this feature exists - however, it still bothers me that Flagger disregards all of the other labels that I care about in creating its primary resources (update: I think I found the solution to this problem, the include-label-prefix option).

as far as I can tell, Flagger's choice to append -primary to the value of app.kubernetes.io/name deviates from the recommended labels doc. it seems to me that Flagger could instead append -primary to the value of app.kubernetes.io/instance, and that would be more in-line with the recommended labels; I would prefer if Flagger didn't alter my labels at all, and merely added a label like canary.flagger.app/primary: true.

honestly, I'm not satisfied with what I've observed of Flagger's labeling. however, I'm open to changing my mind, or at least learning what reasons there may be for Flagger behaving differently than I expect it to and respecting those reasons. with that said, why does Flagger use a recommend label (app.kubernetes.io/app) in a way that's inconsistent with how it's recommended to be used?

[aryan9600]

You can pass the --selector-labels flag to Flagger and specify which labels should be used as selector labels. From https://docs.flagger.app/usage/how-it-works#canary-target:

In addition to app, Flagger supports name and app.kubernetes.io/name selectors. If you use a different convention you can specify your label with the -selector-labels=my-app-label command flag in the Flagger deployment manifest under containers args or by setting --set selectorLabels=my-app-label when installing Flagger with Helm.

[pclalv]

hi @aryan9600 , thanks for taking a look. I understand that --selector-labels can be a flexible workaround. I'm still wondering as to why Flagger is using this label in a way that seems to conflict with the intended use of the label.

[AliakseiVenski]

I hit into this problem as well. I tried to set selectorLabels in values files, but my custom selector label isn't being copied to primary from canary deployment spec. @aryan9600 where should I pass --selector-labels to flagger? I'm installing it with helm chart.