-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
pkg/node: omit the generated spec.ipam.podCIDRs when running with some IPAM modes #23048
Conversation
thanks for the PR @mvisonneau! looks like the checkpatch test is failing because the commit title is too long. Mind amending that to shorten it a bit? I'll kick off the rest of the test suite |
/test |
2b801b2
to
49371a5
Compare
Thanks for the review @thorn3r! I updated the commit message. |
49371a5
to
99f841b
Compare
/test Job 'Cilium-PR-K8s-1.25-kernel-4.19' hit: #22019 (94.82% similarity) |
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! seems like we hit an already tracked flake
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.
Thank you! I think this should close #9409
99f841b
to
14898a0
Compare
Commit 608dbb8acfd7c6ebeac4204589ccd98beaa459e3 does not contain "Signed-off-by". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
Code changes LGTM! I'm not familiar with cilium CI workflows, looks like the checkpatch test fails with the current commit title, and maybe we should remove the second commit.
|
Currently, when using Cilium with AWS ENI, Azure & AlibabaCloud methods. A random podCIDR block is being generated when the CiliumNode is created although is not being leveraged. ```yaml [...] spec: ipam: podCIDRs: - 10.194.0.0/16 # << this one pool: 172.16.5.192: resource: eni-0f2cda9c5fe02382b 172.16.5.193: resource: eni-0f2cda9c5fe02382b 172.16.5.194: resource: eni-0f2cda9c5fe02382b ``` To avoid operators confusion and make it easier to troubleshoot, I felt it could be interesting propose this change which omits the generation of this CIDR block. ```yaml [...] spec: ipam: pool: 172.16.5.192: resource: eni-0f2cda9c5fe02382b 172.16.5.193: resource: eni-0f2cda9c5fe02382b 172.16.5.194: resource: eni-0f2cda9c5fe02382b ``` Signed-off-by: Maxime VISONNEAU <maxime.visonneau@gmail.com>
608dbb8
to
5ff3d72
Compare
👋 thanks for the review @jaffcheng. Not sure how this merge commit ended up there, I removed it and also shorten the message of the relevant one! |
@@ -423,6 +425,12 @@ func AutoComplete() error { | |||
|
|||
InitDefaultPrefix(option.Config.DirectRoutingDevice) |
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.
@mvisonneau I'm a bit lost about how this work, could you share more on that? I assume the cidr is generated in InitDefaultPrefix
, but it's not skipped.
https://github.com/cilium/cilium/pull/23048/files#diff-9143180298a1f5ba5dc10fd98d87945d1381ef45b7347a639f85e13e84285ca2L424
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.
absolutely, I did not find it useful to skip the InitDefaultPrefix
function call during my tests. I assumed that the allocation was happening later (L633 &/or L644).
As we return early (L431) it seems to be sufficient. Not sure about the impact of moving the return logic before the InitDefaultPrefix
call but happy to try it out if you want/prefer.
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 clarifying.
Looks like there are two places calling InitDefaultPrefix
:
Line 426 in 5ff3d72
InitDefaultPrefix(option.Config.DirectRoutingDevice) |
cilium/daemon/cmd/daemon_main.go
Line 1404 in 5ff3d72
node.InitDefaultPrefix(option.Config.DirectRoutingDevice) |
I tried the patch in Alibabacloud mode and found that I have to skip both
InitDefaultPrefix
calls to omit the podCIDR. Not sure if there are some differences between ENI mode.
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 the PR. I don't quite understand why any of these changes are needed. Shouldn't it be as simple as detecting which IPAM mode we need to skip updating the podCIDR field for during the CiliumNode creation? I'd expect such a change to be here.
@mvisonneau Do you plan to continue on this PR? |
I was yes, I apologize as I haven't been able to prioritize it yet. Feel free to update or make progress onto if necessary though! |
This pull request has been automatically marked as stale because it |
@mvisonneau ping? 🙂 |
Thanks for the contribution. I've marked the PR as draft while the feedback is addressed. When the PR is ready for review, you can indicate this by clicking the "Ready for review" button at the bottom of the page. |
My apologies, I am going to put my head back onto it and will keep you posted! |
This pull request has been automatically marked as stale because it |
I have pushed a PR that implements Chris' suggestion to not announce the podCIDR for now: #26663 Long term however, I think we do want to fully get rid of the code that auto-generates the podCIDR for all IPAM modes. It's not used by any IPAM mode, so let's just remove that. |
This pull request has been automatically marked as stale because it |
@mvisonneau Any update? |
This pull request has been automatically marked as stale because it |
Looks like the related issue is fixed by #26663 ? |
Yes, that PR fixed the issue for ENI. There is still more work around the use of pod CIDRs in IPAM modes that don't have them (c.f. #27018), but the issue addressed by this PR should be fixed now. @mvisonneau I'm closing this PR as "obsolete". Please feel free to re-open or ping me if you feel otherwise. |
Apologies, I had messed up with my email notifications! 🙈 Amazing, thanks, I'll try it out but at first sight it does indeed seem to supersedes it 👍 |
Currently, when using Cilium with IPAM in AWS ENI, Azure & AlibabaCloud methods. A random podCIDR block is being generated when the CiliumNode is created although is not being leveraged.
To avoid operators confusion and make it easier to troubleshoot, I felt it could be interesting propose this change which omits the generation of this CIDR block.
Fixes #9409