-
Notifications
You must be signed in to change notification settings - Fork 525
[GEP-28] Deploy gardener-resource-manager
and extension controllers (in bootstrap mode)
#11853
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
Conversation
/assign |
3da5071
to
252920f
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.
Great progress. Thanks a lot.
The changes look very good already. I have only few comments/questions.
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: 556ce0f82bde3d23822340b7c5a38fa3a24d7619
|
/test pull-gardener-e2e-kind-gardenadm |
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: 8de0ae3f0a83fd817c52e44f2f237d33a7f1bfc1
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ScheererJ 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 |
/lgtm |
This way, we can easily execute `kubectl` commands in the machine pods without explicitly pointing to the admin kubeconfig file.
This results in a more convenient use (the only use-case for this static token kubeconfig are the autonomous shoot clusters, and here we usually operate in the `kube-system` namespace, i.e., with this change, we can simply do `kubectl get pods` and see all pods in `kube-system`).
This includes - priority classes - read-only clusterrole + clusterrolebindings (for viewers) - some network policies - KCM service accounts - shoot-info config map
- only consider injecting garden kubeconfig when "bootstrap" flag is disabled - prevent nil pointer exceptions by checking explicitly if ingress domain is set - change rolling update strategy for extension deployments to `Recreate` (to avoid host port conflicts) - set `KUBERNETES_SERVICE_HOST` env var to `localhost` (extensions get deployed before kube-proxy, so the default kubernetes cluster IP does not work yet)
- disable coredns deployment (we don't need it in `gardenadm` scenarios) - do not depend on garden `cluster.Cluster` object (this is only needed for shoot control plane migration at the moment) - inject correct image ref built via skaffold into `ControllerDeployment`
- the list of ControllerRegistrations/ControllerDeployments can be quite long (later, this can be downloaded from an existing Gardener system via `gardenadm discover`, i.e., there can be a lot of extension) - we should only deploy those we really need
Otherwise, the `kubelet` might fail for a while to create the mirror pods for the static pods because a webhook might not be available yet. Since the webhooks are anyways not needed for the mirror pods, we don't want them to be called in the first place.
/lgtm |
LGTM label has been added. Git tree hash: 46c5f8973a199f1d2f786667d3b99e964502f509
|
- With gardener@f9f6a46 (part of gardener#11853) we only skipped static pods during the bootstrap phase. However, we actually never want GRM webhooks to react on static pod creations, even if we are beyond the bootstrap phase. Otherwise, the kubelet might fail to create mirror pods for control plane components if the GRM webhook is unavailable. This can lead to undesired behaviour.
- With gardener@f9f6a46 (part of gardener#11853) we only skipped static pods during the bootstrap phase. However, we actually never want GRM webhooks to react on static pod creations, even if we are beyond the bootstrap phase. Otherwise, the kubelet might fail to create mirror pods for control plane components if the GRM webhook is unavailable. This can lead to undesired behaviour.
- With gardener@f9f6a46 (part of gardener#11853) we only skipped static pods during the bootstrap phase. However, we actually never want GRM webhooks to react on static pod creations, even if we are beyond the bootstrap phase. Otherwise, the kubelet might fail to create mirror pods for control plane components if the GRM webhook is unavailable. This can lead to undesired behaviour.
- With gardener@f9f6a46 (part of gardener#11853) we only skipped static pods during the bootstrap phase. However, we actually never want GRM webhooks to react on static pod creations, even if we are beyond the bootstrap phase. Otherwise, the kubelet might fail to create mirror pods for control plane components if the GRM webhook is unavailable. This can lead to undesired behaviour.
- With gardener@f9f6a46 (part of gardener#11853) we only skipped static pods during the bootstrap phase. However, we actually never want GRM webhooks to react on static pod creations, even if we are beyond the bootstrap phase. Otherwise, the kubelet might fail to create mirror pods for control plane components if the GRM webhook is unavailable. This can lead to undesired behaviour.
- With gardener@f9f6a46 (part of gardener#11853) we only skipped static pods during the bootstrap phase. However, we actually never want GRM webhooks to react on static pod creations, even if we are beyond the bootstrap phase. Otherwise, the kubelet might fail to create mirror pods for control plane components if the GRM webhook is unavailable. This can lead to undesired behaviour.
…d` (#12038) * Deploy `etcd-druid` CRDs * Deploy `etcd-druid` * Static pod translator: Remove service account names This is not allowed for mirror pods * Static pod translator: Translate STS volume claim templates We just mount a path from the host instead. * Prepare bootstrap etcd - change names from `etcd-<role>-0` to `etcd-bootstrap-<role>` to make it more clear when `kubectl get pod` - use the same data directory that etcd managed by etcd-druid would use later (it shall just take over the existing data dir) * GRM pod-creation webhooks always skip static pods - With f9f6a46 (part of #11853) we only skipped static pods during the bootstrap phase. However, we actually never want GRM webhooks to react on static pod creations, even if we are beyond the bootstrap phase. Otherwise, the kubelet might fail to create mirror pods for control plane components if the GRM webhook is unavailable. This can lead to undesired behaviour. * Bootstrap etcd must use same version as etcd-druid - Otherwise, we might get issues when etcd-druid takes over etcd management later - Review this commit with `git diff -w` (ignoring whitespaces) - `yq` seems to enforce indentation, so let's live with it Output: $ go generate ./imagevector/imagevector.go containers.go Cloning etcd-druid... Found etcd-wrapper tag: v0.4.4 Cloning etcd-wrapper at tag v0.4.4... Found etcd version string: v0.0.0-20240911181550-c123b3ea3db3 Extracted commit hash: c123b3ea3db3 Cloning etcd repo to resolve tag... Resolved etcd tag: v3.4.34 Updating containers.yaml with etcd v3.4.34 tag charts.go
How to categorize this PR?
/area ipcei
/kind enhancement
What this PR does / why we need it:
This PR is the next increment for
gardenadm init
. It deploysgardener-resource-manager
, the seed/shoot system components (which mostly arePriorityClass
es, and the extension controllers in bootstrap mode).Result:
Which issue(s) this PR fixes:
Part of #2906
Special notes for your reviewer:
/cc @ScheererJ
Release note: