Preserve loadBalancerClass on Service updates

[diversario]

Issue

#3617

Description

See the linked issue for the observed problem.

This PR enables service mutator to run on updates to service objects (the UPDATE operation needs to be added to the webhook configuration for this to work).

Update mutator will only act on service objects that have spec.loadBalancerClass set to a non-empty value. When this is true, the incoming (updated) Service object will be updated to have the same spec.loadBalancerClass as the existing Service object.

Considering that spec.loadBalancerClass, once set, cannot be unset or modified, this change prevents unexpected validation errors in cases of UPDATE operation with Service object that omits the spec.loadBalancerClass field. This is the case for helm rollback --force, described in the linked issue, as well as for kubectl replace command.

Documentation may need to be updated depending on the outcome of aws/eks-charts#1063 - that PR changes some chart values that are being referenced in the docs.

Testing

This change was tested using the helm chart built from #3653.

For testing, I had MWC with no UPDATE operation first (as it is currently configured), then I enabled it in the chart.

Tested by creating a Service via kubectl apply, updating it via kubectl apply, and then replacing it via kubectl replace. kubectl replace previously would fail with validation error due to attempt to modify spec.loadBalancerClass. No longer fails.

I submitted Service manifests with and without the spec.loadBalancerClass field.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Checklist

• Added tests that cover your change (if possible)
• Added/modified documentation as required (such as the README.md, or the docs directory)
• Manually tested
• Made sure the title of the PR is a good description that can go into the release notes

BONUS POINTS checklist: complete for good vibes and maybe prizes?! 🤯

• Backfilled missing tests for code in same general area 🎉
• Refactored something and made the world a better place 🌟

[k8s-ci-robot]

Welcome @diversario!

It looks like this is your first PR to kubernetes-sigs/aws-load-balancer-controller 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/aws-load-balancer-controller has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @diversario. Thanks for your PR.

I'm waiting for a kubernetes-sigs 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.

[oliviassss]

I was just thinking some corner cases - would this change cause some issue when this field in the newSvc is intended to be nil or ""?

[diversario]

Since this handler is for updates to an existing service only, there's a couple of reasons the field would be missing/empty:

1. User is updating the service object via patch, submitting only modified fields. In this case, tacking the LBC field onto the update is a noop, and there's no change in behavior.
2. User is updating the service object via put (this is the kubectl replace) and omits the field. The normal response would be an error, as the field is immutable.
   With this handler, the error does not occur as we putting the field back. This is a change in behavior.
   Whether this change is unexpected - I think it is not, because presumably user has enabled the webhook, is aware of the webhook effects, and expects LB Services in their cluster to be managed by AWS LBC. So this change, then, just prevents the user from running into an error (and this is the entire reason behind this PR because our deployment tooling - Helm - runs into this very error).
   Importantly, because the handler inspects the existing Service, it will only touch service that are known to be managed by AWS LBC, and not something else.

[oliviassss]

/ok-to-test

[oliviassss]

@diversario, thanks for the contribution. I'm good with the changes, can you please add the manual tests you've done in the PR descriptions?
/lgtm

[shraddhabang]

/lgtm

[diversario]

@diversario, thanks for the contribution. I'm good with the changes, can you please add the manual tests you've done in the PR descriptions? /lgtm

Updated description.

[oliviassss]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: diversario, oliviassss

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:

• OWNERS [oliviassss]

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