-
Notifications
You must be signed in to change notification settings - Fork 450
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
[GEP-20] Zone pinning for shoots on multi-zonal seeds 📌 #6579
[GEP-20] Zone pinning for shoots on multi-zonal seeds 📌 #6579
Conversation
c0f146a
to
e70fe64
Compare
/hold This PR will be transferred into draft mode as long as I'm working on the improvement. |
e70fe64
to
793fd20
Compare
793fd20
to
9fd0d28
Compare
Update: The PR is ready for review now. |
/assign |
/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.
I added some small comments and have two general questions where I don't know enough about the context to answer them by myself 😄
When I see a shoot starting up etcd-main
and etcd-events
are starting at the same time on different nodes.
a) When there is no zone pinning annotation yet, couldn't it happen, that these etcd nodes would be in located in different zones? If this could happen, their volumes would be in different zones and couldn't be pinned to the same zone anymore right?
b) How about the migration scenario when introducing zone pinning. There are other control-plane components like loki and prometheus which use PVCs. Could it be possible that their volumes are located in different zones and could not be attached anymore when zone pinning was activated?
pkg/resourcemanager/webhook/podschedulername/podschedulername_suite_test.go
Outdated
Show resolved
Hide resolved
After etcd is ready we assume that at least one pod with a volume has been scheduled. This is the earliest point in time when we can "pin" the zone, i.e. all remaining volumes also reside in that zone and for the future it needs to be assured that all pods (esp. the ones with volumes) are scheduled there.
For non-HA or single-zonal HA shoot clusters, control-plane pods should be scheduled into a single zone only to avoid any cross zonal traffic.
cdda796
to
2e63c6a
Compare
2e63c6a
to
1254ae5
Compare
Thanks for your feedback @rfranzke and @oliver-goetz. I addressed all your comments, open is still #6579 (comment). PTAL. |
Just to double-check: This is likely no problem because the |
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 comments @timuthy!
test/integration/resourcemanager/podzoneaffinity/podzoneaffinity_test.go
Show resolved
Hide resolved
test/integration/resourcemanager/podzoneaffinity/podzoneaffinity_test.go
Outdated
Show resolved
Hide resolved
test/integration/resourcemanager/podzoneaffinity/podzoneaffinity_test.go
Outdated
Show resolved
Hide resolved
test/integration/resourcemanager/podzoneaffinity/podzoneaffinity_test.go
Outdated
Show resolved
Hide resolved
Yes, that's mostly right. We planned to enable automatic labeling for ManagedSeeds because there we have information about workers. |
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.
Cool @timuthy, thanks for also cleaning up the other webhook test suites!
/approve @oliver-goetz Do you also want to have another look? |
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.
There is one small thing left.
pkg/operation/botanist/namespaces.go
Outdated
delete(namespace.Labels, v1beta1constants.ShootControlPlaneEnforceZone) | ||
if zonePinningRequired(b.Shoot.GetInfo(), b.Seed.GetInfo()) && !metav1.HasLabel(namespace.ObjectMeta, v1beta1constants.ShootControlPlaneEnforceZone) { | ||
metav1.SetMetaDataLabel(&namespace.ObjectMeta, v1beta1constants.ShootControlPlaneEnforceZone, "") | ||
} |
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.
delete(namespace.Labels, v1beta1constants.ShootControlPlaneEnforceZone) | |
if zonePinningRequired(b.Shoot.GetInfo(), b.Seed.GetInfo()) && !metav1.HasLabel(namespace.ObjectMeta, v1beta1constants.ShootControlPlaneEnforceZone) { | |
metav1.SetMetaDataLabel(&namespace.ObjectMeta, v1beta1constants.ShootControlPlaneEnforceZone, "") | |
} | |
if !zonePinningRequired(b.Shoot.GetInfo(), b.Seed.GetInfo()) { | |
delete(namespace.Labels, v1beta1constants.ShootControlPlaneEnforceZone) | |
} else if !metav1.HasLabel(namespace.ObjectMeta, v1beta1constants.ShootControlPlaneEnforceZone) { | |
metav1.SetMetaDataLabel(&namespace.ObjectMeta, v1beta1constants.ShootControlPlaneEnforceZone, "") | |
} |
Otherwise, the label would be changed back and forth during reconciliation, if enforce zone is activated.
This function would set its value to ""
, but AddZoneInformationToSeedNamespace
would add a zone value again later.
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.
Nice catch @oliver-goetz. I fixed it, PTAL.
8d6ba8e
to
84569c2
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.
/lgtm
🚀
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: oliver-goetz, rfranzke 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 |
How to categorize this PR?
/area control-plane
/area high-availability
/kind enhancement
What this PR does / why we need it:
This PR adds the zone pinning requirement discussed by GEP-20, ref.
In essence it does the following:
non-HA
orsingle-zonal
shoots if it's responsible for amulti-zonal
seed (seed which has worker across availability zones).pod-zone-affinity
webhook in GRM adds a zone-aware affinity term for such control-plane pods so that those will be scheduled into a single zone only.etcd
was deployed successfully, it's assumed that at least one stateful pod was scheduled. Gardenlet then extracts the zone information from that pod/node.nodeAffinity
to "pin" pods to a specific zone. It is especially important to schedule pods to the original zone when shoots are being woken up from hibernation.Which issue(s) this PR fixes:
Fixes partially #6529
Release note: