feat: add hydra option to create separate admin and public deploys

[terev]

Add an option to the Hydra chart separateAdminAndPublicDeploys, when enabled creates separate deployment objects for the admin and public components. In addition, if auto-scaling is enabled, separate HPA objects will be created.

Related Issue or Design Document

I was unable to find any related issues, and don't have a design document.

Checklist

• I have read the contributing guidelines and signed the CLA.
• I have referenced an issue containing the design document if my change introduces a new feature.
• I have read the security policy.
• I confirm that this pull request does not address a security vulnerability.
  If this pull request addresses a security vulnerability,
  I confirm that I got approval (please contact [email protected]) from the maintainers to push the changes.
• I have added tests that prove my fix is effective or that my feature works.
• I have added the necessary documentation within the code base (if appropriate).

Further comments

The motivation for this change was to enable creating an Istio RequestAuthentication policy which applies to only the admin component (since it doesnt have its own auth). In addition, this change makes it possible to scale, configure, and route the admin and public components separately.

[Demonsthere]

Hi there!
This is an interesting feature request, I can see the reasoning behind it, and it possibly would make sense to create such a distributed system for other applications as well 🤔.
However, I think it might be a better idea to make it more verbose, and follow the same path as https://github.com/grafana/helm-charts/tree/main/charts and create a separate hydra-distributed chart, as opposed to keeping it bundled in a single package, wdyt?

[terev]

@Demonsthere Are there any concerns with the additional complexity required to update two charts for Hydra if we fork this one into a new chart? My concern is if there's multiple different charts it gets complicated to keep them all maintained. Maybe we could modularize this chart such that portions can be reused in the distributed version?

[terev]

@Demonsthere If it wasn't clear, I'm totally open to doing this. Just looking for guidance to do it in a maintainable way.

[Demonsthere]

Yeah, sorry it was just a busy week 😅
I think i am more in favour of a distributed chart, then overcomplicating the current one, as we would have to prepare options like different requests/hpa for each deployment :)

[terev]

@Demonsthere No worries, thanks for the response, no rush.

Configuring the two deployments differently is actually supported in my current implementation by using the new deployment.admin and deployment.public options. These options act as overrides on top of the defaults specified in the deployment object.

But totally fair, definitely don't want to overcomplicate the chart. I can try making a separate chart.