Source kube-rbac-proxy configs from values

[maxbrunet]

Description

This started off from "I want to easily configure the resources of any kube-rbac-proxy" and end by "we can do the full config for kube-rbac-proxy in values like everything else".

No manifest changes.

Type of change

What type of changes does your code introduce to the kube-prometheus? Put an x in the box that apply.

• [ ] CHANGE (fix or feature that would cause existing functionality to not work as expected)
• [ ] FEATURE (non-breaking change which adds functionality)
• [ ] BUGFIX (non-breaking change which fixes an issue)
• [x] ENHANCEMENT (non-breaking change which improves existing functionality)
• [ ] NONE (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

Changelog entry

- Source kube-rbac-proxy configs from values

[maxbrunet]

I would also like to know the use-case of surfacing parameters like secureListenAddress or upstream.

I do not have a use-case at the moment, my idea is to keep it simple and have the whole config in defaults and let the user decide whatever they want to use the fields or not. We could also do something like:

local kubeRbacProxy = krp({
  name: 'kube-rbac-proxy',
  upstream: 'http://127.0.0.1:8080/',
  secureListenAddress: ':8443',
  ports: [
    { name: 'https', containerPort: 8443 },
  ],
  image: defaults.kubeRbacProxyImage,
} po._config.kubeRbacProxy),

But it only looks like an extra layer of defaults.

[maxbrunet]

This is conflicting with #1477 for reasons mentioned in #1500 (comment).

Are referring to this specific sentence? Meaning you have not yet decided on a location to ease configuration of kube-rbac-proxy?:

We could put the kube-rbac-proxy definition into defaults.containers list though, but this would still be problematic from UX pov.

What would be the next step to move forward with either of these 2 issues?

FYI something that is important to me is making sure all pods use Guaranteed QoS (limits = requests)