-
Notifications
You must be signed in to change notification settings - Fork 502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[operator] Extend operatorv1alpha1.VirtualCluster
with API for future kube-apiserver
deployment
#7693
[operator] Extend operatorv1alpha1.VirtualCluster
with API for future kube-apiserver
deployment
#7693
Conversation
operatorv1alpha1.VirtualCluster
with API for kube-apiserver
configurationoperatorv1alpha1.VirtualCluster
with API for Kubernetes version and kube-apiserver
configuration
/assign |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Looks good overall.
I have just a few questions.
de66f0a
to
779f76b
Compare
operatorv1alpha1.VirtualCluster
with API for Kubernetes version and kube-apiserver
configurationoperatorv1alpha1.VirtualCluster
with API for future kube-apiserver
deployment
@ScheererJ Thanks for your review, I've answered comments and addressed the feedback with 6cb480a. I've also added two more commits which expose the DNS and networking section with configuration fields required for the future deployment of the API server, cc @timuthy (I forgot about them initially). |
779f76b
to
98c17f5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for addressing my questions.
I have a few ones about the added DNS/networking parts.
98c17f5
to
1186d37
Compare
OK, next round @ScheererJ :) I've addressed your feedback in the last commit. There are two more new commits:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot. Looks good to me.
/lgtm |
LGTM label has been added. Git tree hash: 31f17d15b625b1ef4a543ec257d1af8f2052e973
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice 🚀
This will be called from the operator in the future
`.import-restrictions` file copied from https://github.com/gardener/gardener/blob/master/pkg/apis/core/validation/.import-restrictions
This commit also enhances the webhook controllers to reconcile multiple webhook configs in the source cluster (now that `gardener-operator` no longer only serves a validating webhook but also a defaulting webhook).
Without this commit, the certificate management reconciler can race with the code that updates the webhook configurations. Since both is started at the same time, it might happen that the reconciler is faster with updating the CA bundle in all webhooks (ref https://github.com/gardener/gardener/blob/5abed1bfedd6f2188e5dcec9af161d1b5c286236/extensions/pkg/webhook/certificates/reconciler.go#L169-L174), and afterwards the code removes the CA bundle again.
1186d37
to
17020e2
Compare
@rfranzke: The following test failed, say
Full PR test history. Your PR dashboard. Command help for this repository. 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. I understand the commands that are listed here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
LGTM label has been added. Git tree hash: aaa4e80c79cd2f23a2659e7e43cdf3d954530864
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: timuthy 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:
Approvers can indicate their approval by writing |
…re `kube-apiserver` deployment (gardener#7693) * Copy example API from `Shoot` example YAML file * Add kubeconfig secret reference for admission plugins * Add configuration for TLS SNI * Add configuration for resources to be stored in `etcd-events` * Add configuration options for {audit,auth{n,z}} webhooks * Export common validation and defaulting code This will be called from the operator in the future * Validation for new fields `.import-restrictions` file copied from https://github.com/gardener/gardener/blob/master/pkg/apis/core/validation/.import-restrictions * Defaulting for new fields This commit also enhances the webhook controllers to reconcile multiple webhook configs in the source cluster (now that `gardener-operator` no longer only serves a validating webhook but also a defaulting webhook). * Run `make generate` * Fix race causing CA bundles to be removed from webhook configs Without this commit, the certificate management reconciler can race with the code that updates the webhook configurations. Since both is started at the same time, it might happen that the reconciler is faster with updating the CA bundle in all webhooks (ref https://github.com/gardener/gardener/blob/5abed1bfedd6f2188e5dcec9af161d1b5c286236/extensions/pkg/webhook/certificates/reconciler.go#L169-L174), and afterwards the code removes the CA bundle again. * Address PR review feedback * Add DNS and networking fields to `Garden` * [make generate] * Do not overwrite inlined config in defaulting webhook * Validate Kubernetes version against supported versions * Address PR review feedback * Address PR review feedback
How to categorize this PR?
/area usability
/kind enhancement
What this PR does / why we need it:
This PR extends the
Garden
API with configuration options for the virtual cluster for thekube-apiserver
.gardener-operator
still does not deploykube-apiserver
, though this will be supported by the upcoming releases.The API reuses the vast majority of the existing types as well as validation/defaulting code already present for
Shoot
s. For the fields ofgardencorev1beta1.KubeAPIServerConfig
that are now exposed via theGarden
, validation and defaulting happens via the webhook instead of via CRD validation/defaulting to prevent duplicating the logic. As a result, a new mutating webhook has been introduced which performs the defaulting.For the fields that are not part of
gardencorev1beta1.KubeAPIServerConfig
but only ofoperatorv1alpha1.KubeAPIServerConfig
, the validation/defaulting is done as part of the CRD validation/defaulting (just like it was done before for other fields).Which issue(s) this PR fixes:
Part of #7016
Special notes for your reviewer:
/cc @ScheererJ @timuthy @oliver-goetz
Release note: