Hpa

[nowjean]

Proposed changes

Write a clear and concise description that helps reviewers understand the purpose and impact of your changes. Use the
following format:

Problem: I want NGF to work with a HorizontalPodAutoscaler

Solution: Add HPA for deployement

Testing: Describe any testing that you did.
I've deployed my AKS cluster and checked hpa working correctly.

Closes #3447

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

Release notes

If this PR introduces a change that affects users and needs to be mentioned in the release notes,
please add a brief note that summarizes the change.

[nginx-bot]

Hi @nowjean! Welcome to the project! 🎉

Thanks for opening this pull request!
Be sure to check out our Contributing Guidelines while you wait for someone on the team to review this.

[github-actions]

✅ All required contributors have signed the F5 CLA for this PR. Thank you!
_{Posted by the CLA Assistant Lite bot.}

[nowjean]

I have hereby read the F5 CLA and agree to its terms

[salonichf5]

Thank you for you contribution to the project. Please run make generate-all from root directory to auto generate schema files.

[salonichf5]

nit: add one-line descriptions for these fields, similar to how it's done for the others, to improve readability for users.

[nowjean]

I've added comments!

[nowjean]

Thank you for you contribution to the project. Please run make generate-all from root directory to auto generate schema files.

I’ve completed 'make generate-all'. Could you please review my PR?

[sjberman]

So this only affects the control plane, correct? We probably want to support this for the nginx data plane as well (seems like that would be the more beneficial use case).

In order to configure deployment options for the data plane, it requires a bit more work, specifically in our APIs and the code itself. The NginxProxy CRD holds the deployment configuration for the nginx data plane, which the control plane uses to configure the data plane when deploying it.

Here is a simple example of how we add a new field to the API to allow for configuring these types of deployment fields: #3319.

[sjberman]

I'd also love a more descriptive PR title, as well as a release note in the description so we can include this feature in our release notes :)

[nowjean]

@sjberman Yes, this PR only affects the control plane. Can we also implement HPA for the data plane?

AFAIK, the data plane Deployment is created by the NginxProxy CRD, and its name depends on the Gateway's name parameter. This means we can't assume a fixed name in values.yaml.

HPA only applies to Deployments with a fixed name, like:

scaleTargetRef:
  apiVersion: apps/v1
  kind: Deployment
  name: my-app

So, I think we can't implement HPA via the Helm chart, especially since data plane and control plane pods are now separated in 2.0.
Do you have any suggestions or recommended approaches for enabling HPA on the data plane?

[sjberman]

@nowjean I updated my comment with a description on how it can be implemented on the data plane side. Glad we're on the same page :)

[salonichf5]

Thank you for you contribution to the project. Please run make generate-all from root directory to auto generate schema files.

I’ve completed 'make generate-all'. Could you please review my PR?

Will manual test this PR for both control plane and data plane when we have all the changes :)