Switch AdmissionReview from v1beta1 to v1

[adriananeci]

This PR updates AdmissionReview from v1beta1 to v1. In V1, the UID field is mandatory and should be copied from the request.uid sent to the webhook based on https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#response

No other notable changes between AdmissionReview v1beta1 and v1. AdmissionReview v1 is available since k8s v1.16.

[k8s-ci-robot]

Welcome @adriananeci!

It looks like this is your first PR to kubernetes/autoscaler 🎉. 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/autoscaler 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. 😃

[adriananeci]

/assign @krzysied

[jbartosik]

Thank you.

I have some questions about migration:

1. Can we drop dependency on v1beta1 admission API?
2. If I have an existing cluster, with VPA webhook created using v1beta1 admission API and switch to VPA using v1 admission API what will happen? Will we overwrite the existing webhook? Will we have 2 webhooks?
3. What will happen if I need to rollback VPA to an older version? So I'll switch from VPA using v1 admission API to older VPA using v1beta1 admission API?

[adriananeci]

1. Can we drop dependency on v1beta1 admission API?

Yes, just removed v1beta1 dependency

2. If I have an existing cluster, with VPA webhook created using v1beta1 admission API and switch to VPA using v1 admission API what will happen? Will we overwrite the existing webhook? Will we have 2 webhooks?

Tested it on a kind cluster and the old webhook will be replaced with the new one having

- admissionReviewVersions:
    - v1

3. What will happen if I need to rollback VPA to an older version? So I'll switch from VPA using v1 admission API to older VPA using v1beta1 admission API?

Everything should go smooth since the MutatingWebhookConfiguration will be recreated with admissionReviewVersions set to v1beta1.

Validated it on a kind cluster:

• deploy VPA using ./hack/vpa-up.sh.
• deploy the hamster example(k apply -f examples/hamster.yaml) and validate the vpa object status

❯ k get vpa
NAME          MODE   CPU    MEM       PROVIDED   AGE
hamster-vpa   Auto   587m   262144k   True       23m

• build a new admission-controller image with changes from this PR using

make build-in-docker-amd64 docker-build-amd64 REGISTRY=test TAG=test

• loaded the new image into the kind cluster using

kind load docker-image test/vpa-admission-controller-amd64:test --name test-cluster

• edit the vpa-admission-controller deployment and swap the official image with the freshly built one
• check the vpa-webhook-config mutatingwebhookconfiguration object and its admissionReviewVersions value

k get mutatingwebhookconfigurations.admissionregistration.k8s.io -oyaml

• edit the vpa-admission-controller deployment and switch back to the official image(k8s.gcr.io/autoscaling/vpa-admission-controller:0.9.2)
• re-validate everything is working as expected(webhook config, vpa components logs, vpa object, etc)

[jbartosik]

Thank you for the answering quickly. This PR mostly looks good to me but I have a few small requests.

Please:

• fix commit message AdmissionReviw misses letter 'e' and
• squash commits,
• sync (I think with Send UID too in AdmissionReview response #4538 merged I think there will be a small conflict to resolve).

[adriananeci]

Rebased from master, squashed commits and fixed commit message

[jbartosik]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: adriananeci, jbartosik

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:

• vertical-pod-autoscaler/OWNERS [jbartosik]

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