Conversation
Previously, whenever CIDR range was extended, we removed all allocations from existing ranges, created new ranges and tried reassigning IPs to new ranges. We've already tried to reuse the same IP, however as we tried first to assign IPs to "unsatisfied" services, they could steal existing IPs from other service, resulting in reallocation of IP for already "satisfied" service, while also resulting in temporary state with two different services having the same IP. The same issue could have happened, when selector of pool was modified selecting new unsatisfied services. Note that this do not solve a case when CIDR range shrinks. In case of CIDR shrinking, IPs that would still be valid within a new range might get reallocated. Related: #40358 Signed-off-by: Marcel Zieba <marcel.zieba@isovalent.com>
8f30f68 to
0039aeb
Compare
Additionally, in case of pool spec changes, log previous and new spec. Signed-off-by: Marcel Zieba <marcel.zieba@isovalent.com>
0039aeb to
7309eba
Compare
Member
Author
|
/test |
joamaki
approved these changes
Aug 14, 2025
3 tasks
3 tasks
3 tasks
terassyi
added a commit
to cybozu-go/cilium
that referenced
this pull request
Dec 12, 2025
Signed-off-by: terashima <tomoya-terashima@cybozu.co.jp>
terassyi
added a commit
to cybozu-go/cilium
that referenced
this pull request
Dec 12, 2025
* backport cilium/pull/41122 Signed-off-by: terashima <tomoya-terashima@cybozu.co.jp> * backport cilium/pull/41147 lbipam: do not reallocate IPs on operator restart If there was a pool that was filled and had unsatisfied Services, on operator restart there was a high chance that we will reshuffle assignement of IPs for that pool. This resulted in previously safisfied services to either become unsatisfied or get a new IP. Issue is fixed by not performing any operation on services until full sync happens. After that, first we try to reuse IPs for already satisfied services and only after that we try to assign additional IPs to unsatisfied services. Additionally, add test that covers this case, simulating restart of operator. Related: cilium#40358 Signed-off-by: Marcel Zieba <marcel.zieba@isovalent.com> --------- Signed-off-by: terashima <tomoya-terashima@cybozu.co.jp> Signed-off-by: Marcel Zieba <marcel.zieba@isovalent.com> Co-authored-by: Marcel Zieba <marcel.zieba@isovalent.com>
yokaze
pushed a commit
to cybozu-go/cilium
that referenced
this pull request
Jan 30, 2026
* backport cilium/pull/41122 Signed-off-by: terashima <tomoya-terashima@cybozu.co.jp> * backport cilium/pull/41147 lbipam: do not reallocate IPs on operator restart If there was a pool that was filled and had unsatisfied Services, on operator restart there was a high chance that we will reshuffle assignement of IPs for that pool. This resulted in previously safisfied services to either become unsatisfied or get a new IP. Issue is fixed by not performing any operation on services until full sync happens. After that, first we try to reuse IPs for already satisfied services and only after that we try to assign additional IPs to unsatisfied services. Additionally, add test that covers this case, simulating restart of operator. Related: cilium#40358 Signed-off-by: Marcel Zieba <marcel.zieba@isovalent.com> --------- Signed-off-by: terashima <tomoya-terashima@cybozu.co.jp> Signed-off-by: Marcel Zieba <marcel.zieba@isovalent.com> Co-authored-by: Marcel Zieba <marcel.zieba@isovalent.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, whenever CIDR range was extended, we removed all allocations from existing ranges, created new ranges and tried reassigning IPs to new ranges. We've already tried to reuse the same IP, however as we tried first to assign IPs to "unsatisfied" services, they could steal existing IPs from other service, resulting in reallocation of IP for already "satisfied" service, while also resulting in temporary state with two different services having the same IP.
Note that this do not solve a case when CIDR range shrinks. In case of CIDR shrinking, IPs that would still be valid within a new range might get reallocated.
Related: #40358