feat: add option to add additional custom pod labels

[patrick-vonsteht]

What this PR does / why we need it:
This PR adds the option to configure additional custom pod labels for all pods created by the controller deployment.

This makes it possible to use the controller in environments that require the use of certain labels on all pods, e.g. for governance reasons. One concrete example would be the requirement to label each pod with the cost center that pays for it.

The PR adds an additionalPodLabels parameter, which is a pattern that is used by many helm charts to solve this issue.

To configure the additional labels, you need to do the following:
(A) For the helm chart deployment, add to your values.yaml:

deploy:
  additionalPodLabels:
    foo: bar
runtimeConfig:
  manager:
    additionalPodLabels:
      foo: bar

(B) For the manifest deployment, edit your manifest:

• Add the label to the eraser-controller-manager pod template
• Add to the contents of the eraser-manager-config config map:

manager:
  additionalPodLabels:
    foo: bar

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
None. This PR proposes this feature.

Special notes for your reviewer:
Thank you for looking at this. I'm looking forward to your feedback and hope we can add this feature to the controller.

[pmengelbert]

@patrick-vonsteht Thanks for the PR! I'll take a look today

[pmengelbert]

You will also need to run make manifests. This will generate the staging manifest and helm chart under manifest_staging.

[ashnamehrotra]

@patrick-vonsteht the api changes lgtm, thanks! we will also need to change the controller code to set the labels if they are present in the config (https://github.com/eraser-dev/eraser/blob/main/controllers/imagecollector/imagecollector_controller.go#L326) before creating the ImageJob.

[patrick-vonsteht]

@ashnamehrotra thank you for the hint, I'll take a look at that.

[patrick-vonsteht]

@ashnamehrotra I have extended the code to add the additional labels also to the ImageJob PodTemplateSpec.

[patrick-vonsteht]

Looks like all the tests are successful, except the vulnerability scan. But the vulnerabilities are unrelated to my changes, because I didn't change any dependencies. How should I proceed with this?

[ashnamehrotra]

since we are also setting this in the imagejob_controller we can get rid of the functionality here

[patrick-vonsteht]

I have removed it.

[ashnamehrotra]

same here, we don't need to set it here since its done in the imagejob_controller already

[patrick-vonsteht]

I have removed it.

[ashnamehrotra]

why do we need additionalPodLabels here?

[patrick-vonsteht]

The goal is to be able to set additionalPodLabels on every pod. So we have to handle two parts:
1.) The pod labels for the eraser-controller-manager pod. We define these in deploy.additionalPodLabels, because they are used during the deployment of the controller.
2.) The pod labels for the pods that the controller creates at runtime. We define these in runtimeConfig.manager.additionalPodLabels, because they are used during runtime of the controller.

[ashnamehrotra]

got it, thanks for clarifying!

[ashnamehrotra]

Looks like all the tests are successful, except the vulnerability scan. But the vulnerabilities are unrelated to my changes, because I didn't change any dependencies. How should I proceed with this?

I can put up a separate PR to update that vulnerability.

[sozercan]

fixable vulns should already be addressed with #1002. trivy didn't had a release at the time with a fix so we can't fix that yet. vuln check is meant to be informative, and not blocking so we can ignore that for this pr specifically.

[ashnamehrotra]

LGTM, thank you!

[pmengelbert]

LGTM, thanks!