Adding Kubernetes recommended labels to resources

[Cottonglow]

The intent behind this PR is to open a discussion and decide on what labels we want to add, the values we want and which resources they should be on (It is recommended to apply the labels on every resource object - https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/).

I picked the labels that seemed reasonable to me and the values that made sense. (Eg app.kubernetes.io/instance doesn't feel like it would fit in and app.kubernetes.io/managed-by makes more sense for the helm charts)

Some concerns/questions:

• I have is the version label as this is hardcoded into the yaml files. This will get annoying when releasing newer version. If anyone has a proposal, that would be great! This will be addressed in Automate update of KEDA version in the code and yaml files during each release #580
• Also I hardcoded the version for now in the .go files as I am not familiar enough with Go to substitute it! Happy for anyone to add a commit to change this. Fixed
• I've not been able to add a label to service/keda-operator-metrics as the operator-sdk doesn't let you pass in labels, so the other way of doing it, is to potentially update it with the labels you want. Although I haven't figured out how yet.

Checklist

• A PR is opened to update the labels in the helm repository - Add recommended kubernetes labels to helm chart charts#21
• Update Release Pipeline documentation
• keda-operator-metrics-apiserver pod keeps failing for some reason - This seemed to have been something locally. Deleting and restoring files worked.
• Add labels to service/keda-operator-metrics - I will leave this as is for now

Fixes #536

[msftclas]

All CLA requirements met.

[balchua]

@Cottonglow
For Go, there is a package version which you can use. You may want to import github.com/kedacore/keda/version and the use it like version.Version.

[zroubalik]

Would be great to add a script and Makefile target to change the version in these files before release, so we avoid manual work and possible typos/mistakes.

[balchua]

Using ldflags might help here.
Something like this in the Makefile

go build -ldflags="-X 'github.com/kedacore/keda/version.Version=$GIT_VERSION'" .

[balchua]

GIT_VERSION is already defined in the Makefile, will it be usable? Instead of manually defining it?

[zroubalik]

Would be great to add a script and Makefile target to change the version in these files before release, so we avoid manual work and possible typos/mistakes.

#580

[Cottonglow]

@balchua GIT_VERSION outputs the commit hash for me, which I didn't think we would want, eg 373f40a

[Cottonglow]

Would be great to add a script and Makefile target to change the version in these files before release, so we avoid manual work and possible typos/mistakes.
#580

@zroubalik I didn't realise there was a separate issue for this and completed most of the work to substitute the values in the .yaml files... I can open a separate PR for the .yaml ones but leave the version.go one in here? Happy to take it out too.

[zroubalik]

@zroubalik I didn't realise there was a separate issue for this and completed most of the work to substitute the values in the .yaml files... I can open a separate PR for the .yaml ones but leave the version.go one in here? Happy to take it out too.

@Cottonglow that's fine, you can keep the things you have already done in this PR and if you are willing to work on the rest, you can open another PR with outstanding issues :) Thanks!

[zroubalik]

LGTM

[tomkerkhove]

Thanks @Cottonglow !