-
Notifications
You must be signed in to change notification settings - Fork 104
test(e2e): add ZRS PV multi-zone scheduling test #1318
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
base: tallaxes/e2e/storage
Are you sure you want to change the base?
Conversation
- add test validating pod with ZRS PV schedules correctly in zone 2 - add SupportsZones() method to skip test in non-zonal regions - add EventuallyExpectPVCBound() helper function - integrate zone provider in test environment
60e8a55 to
9e6cb45
Compare
9e6cb45 to
6b393df
Compare
| sigs.k8s.io/karpenter v1.6.2 | ||
| ) | ||
|
|
||
| replace sigs.k8s.io/karpenter => github.com/tallaxes/karpenter-core v0.0.0-20251221063144-7863910ee631 |
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.
Dont forget to remove before merge.
| // considers ALL PV node affinity terms (not just the first), we intentionally | ||
| // schedule the pod in zone 2. Without the sigs.k8s.io/karpenter fix, this would fail | ||
| // because the scheduler only looked at the first zone. | ||
| zone2 := utils.MakeAKSLabelZoneFromARMZone(env.Region, zones[1]) |
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.
Is it guaranteed that zones is always either len 0 or len 2? It can't be len 1?
If it's length 1, we'd get here and panic
Description
Add an integration test that validates Karpenter correctly schedules pods with ZRS (Zone Redundant Storage) persistent volumes when the pod targets a specific zone.
This test validates the fix in kubernetes-sigs/karpenter#2743 which ensures Karpenter considers ALL PV node affinity terms during scheduling, not just the first one. ZRS disks are accessible in all zones of a region, so the PV node affinity includes multiple zone terms. Without the fix, pods targeting zone 2 would fail because only the first zone term was considered.
Changes:
VolumeBindingImmediateStorageClassEventuallyExpectPVCBound()helper functionHow was this change tested?
Does this change impact docs?
Release Note