-
Notifications
You must be signed in to change notification settings - Fork 275
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
node-ip rke2 flag isn't always passed to kubelet #4759
Comments
RKE2 and the kubelet should use the same logic to select the node IP if it is not specified. We should be using the same Kubernetes utility function to determine the IP. Can you provide more information on what specifically you're seeing? |
I'll try to be more specific : In our organization, the VMs have 2 NICs (its mandatory). The first (ens160) has an ip which start with '172.*'. The second (ens192) has an ip which start with '10.*'. If rke2 run without its 'node-ip' flag, kubelet register itself with the '172.*' ip, the wrong one. It seem that rke2 (in fact k3s) use this function to define the default ip : https://github.com/kubernetes/apimachinery/blob/v0.28.2/pkg/util/net/interface.go#L366. I tried to find the function used by kubelet but in vain. I can just see that kubelet always take the ip from the first valid NIC. |
Hmm. @manuelbuil @rbrtbnfgl do y'all have any ideas on what might be going on here? I don't think that we should be unconditionally adding a node-ip flag to the kubelet, but the behavior observed here does seem odd. Can you show the output of |
That's a bit odd. If |
The line https://github.com/k3s-io/k3s/blob/550dd0578f79882e1a78d8468fdbefa95faa145c/pkg/daemons/agent/agent_linux.go#L126 test if the rke2 In the logs, kubelet doesn't have the node-ip flag. And in the @brandond I'll post the |
So in your case Kubelet isn't selecting the default IP of the node. |
In all the case I tested, kubelet always take the IP from the first valid NIC. It seems kubelet doesn't check the default route (I say that just from testing, I didn't managed to find the logic in the kubelet code). |
According to the ISSP of my organisation, I had to replace lots of informations with 'xxx'. I this is enough for you. |
New test on our infrastructure : We still can't confirm with the kubelet code the logic behind this behaviour, Maybe you can do it? @brandond, @rbrtbnfgl : Can you confirm that override |
yes. Passing |
@rbrtbnfgl So there's no impact on k3s/rke2 side if we bypass its logic? |
no |
Nice :) Can we keep the issue open? Until rke2/k3s use the same logic as kubelet when choosing the IP for registering? |
I think i found the logic behind kubelet : https://github.com/kubernetes/kubernetes/blob/82bca6304b5365f7df2627ad2a6fb3d4539bf36f/pkg/kubelet/nodestatus/setters.go#L189 And my tests seem to confirm this behaviour. In our infrastructure, the DNS lookup from the node name always reply with the 172 ip. @rbrtbnfgl Is it possible on rke2/k3s side to mimic this logic? |
yes. Probably we should always pass the |
Validated on Version:-$ rke2 version v1.28.3-rc2+rke2r1 (0d0d0e4879fdf95254461e3a49224f75d7b2dc3d)
Environment DetailsInfrastructure Node(s) CPU architecture, OS, and Version: Cluster Configuration: Steps to validate the fix
Reproduction Issue:
Validation Results:
|
Environmental Info:
RKE2 Version:
rke2 version v1.25.9+rke2r1 (842d05e)
Node(s) CPU architecture, OS, and Version:
Linux XXX 5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023 x86_64 x86_64 x86 64 GNU/Linux
Cluster Configuration:
For the demo, I just build a 1master + 1worker cluster
Describe the bug:
When passing 'node-ip' flag to rke2, kubelet doesn't get its 'node-ip' flag.
Steps To Reproduce:
Build a 2 nodes cluster based on the following template :
Expected behavior:
rke2 'node-ip' flag must be passed to kubelet 'node-ip flag.
Actual behavior:
In this specfic case, kubelet start without 'node-ip' flag, and register itself in the cluster with the ens160 ip.
Additional context / logs:
I think it's because :
I bypass this bug by setting 'kubelet-arg["node-ip"]' instead of using the flag 'node-ip'. Is this a good idea?
The text was updated successfully, but these errors were encountered: