Ignore deployment template's replicas if KEDA is enabled

[amirschw]

What this PR does / why we need it:

Ignore the value of controller.replicaCount if KEDA is enabled. Otherwise, Helm 3 will set the replicas back to this value on every upgrade. This is already the case when autoscaling with HPA is enabled (done in helm/charts#19189).

More details (from helm/charts#19008):

Helm 3's 3-way strategic merge strategy is a huge improvement, and is the correct way to go. However it uncovered that one use case for the incorrect behavior in Helm 2 actually had a nice outcome: HPA-scaled replicas were untouched on helm upgrade, whereas Helm 3 now sets the replicas back to the values/template-defined number of replicas.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• CVE Report (Scanner found CVE and adding report)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation only

Which issue/s this PR fixes

How Has This Been Tested?

Only when autoscaling and KEDA are disabled, the deployment's replicas field is set.

~ $ helm template ~/repos/ingress-nginx/charts/ingress-nginx --set controller.autoscaling.enabled=true  --set controller.keda.enabled=false -s templates/controller-deployment.yaml | grep "replicas:"
~ $ helm template ~/repos/ingress-nginx/charts/ingress-nginx --set controller.autoscaling.enabled=false --set controller.keda.enabled=true  -s templates/controller-deployment.yaml | grep "replicas:"
~ $ helm template ~/repos/ingress-nginx/charts/ingress-nginx --set controller.autoscaling.enabled=false --set controller.keda.enabled=false -s templates/controller-deployment.yaml | grep "replicas:"
  replicas: 1

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have added unit and/or e2e tests to cover my changes.
• All new and existing tests passed.
• Added Release Notes.

Does my pull request need a release note?

Any user-visible or operator-visible change qualifies for a release note. This could be a:

• CLI change
• API change
• UI change
• configuration schema change
• behavioral change
• change in non-functional attributes such as efficiency or availability, availability of a new platform
• a warning about a deprecation
• fix of a previous Known Issue
• fix of a vulnerability (CVE)

No release notes are required for changes to the following:

• Tests
• Build infrastructure
• Fixes for unreleased bugs

For more tips on writing good release notes, check out the Release Notes Handbook

Helm: Ignore deployment template's replicas if `controller.keda.enabled`

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

Hi @amirschw. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[amirschw]

@ChiefAlexander @cpanato would you be able to review this XS pull request? 😄

[strongjz]

/assign @strongjz

[longwuyuan]

@amirschw thanks for the PR.

You can help out even more, if you do things like ;

• Kindly add more descriptive text in description of the PR, that introduces the context with linked references to kubernetes.io docs
• Kindly use make dev-env described here https://kubernetes.github.io/ingress-nginx/developer-guide/getting-started/#local-build to create an environment with your changes. That way you can add kubectl describe ... outputs to show the changed key:value pairs in objects
• You can use the same environment as above and run partial "focussed" e2e- tests like described here https://kubernetes.github.io/ingress-nginx/developer-guide/getting-started/#testing. That way there can be data here to prove that the changes are good to go

Thank you

[longwuyuan]

I forgot to to mention. In addition to some more description and the live state example with your changes, you could also explore adding to the e2e tests because the current e2e-tests could involve HPA. And if tests don't consider HPA then it could be a good idea to have tests with HPA.

Thanks

[sudermanjr]

@amirschw @longwuyuan are there plans to resolve the comments and get this merged?

[strongjz]

/lgtm
/cherry-pick release-1.8

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amirschw, strongjz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• charts/ingress-nginx/OWNERS [strongjz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment