Error "no default routes found" when using Air-gap installation #1144
Comments
|
after add |
|
gz#12542 |
|
Would love to hear some feedback from the dev team. It seems like a bit of a hole in the airgap install instructions if you cannot setup K3S in an environment that does not have a default route. |
|
The default route requirement actually stems down to a bunch of downstream components; for example, you need a default route to enable cluster networking with Flannel, as otherwise, traffic won't pass through iptables etc. The default route doesn't necessarily need to be functional, but is necessary to be in place. |
|
This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 180 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions. |
|
This is still an open issue |
|
As noted above, this is a limitation of Kubernetes components upstream from K3s. At this time, it is required that you have a default route configured on your node. If your environment does not actually have anywhere to send traffic to, you can at the very least configure a dummy interface with a low-priority default route; something along the lines of: ip link add dummy0 type dummy
ip link set dummy0 up
ip addr add 169.254.255.255/32 dev dummy0
ip route add default via 169.254.255.255 dev dummy0 metric 1000 |
|
I don't know if I've done something wrong and I need to start over but when I try these commands, the final command fails with:
I'm running these commands while attached to no network, just entering them into the console. |
|
maybe alter that to ip link add dummy0 type dummy
ip link set dummy0 up
ip addr add 169.254.255.254/31 dev dummy0
ip route add default via 169.254.255.255 dev dummy0 metric 1000You may have to play with it a bit - I haven't tested this myself recently. |
|
We saw a similar issue to this today while doing some airgap testing. Full steps:
This appeared to work, but logs were looping with metrics-server errors: Also,
|
|
Following modification of work-around worked for me:
Also, for coredns, any 127.0.0.x entries should be commented out in /etc/resolv.conf and instead
should be added. |
|
This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 180 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions. |
dereknola
added
the
kind/documentation
|
Closing as documentation issue has been addressed. |
|
I find
hello, We saw a similar issue to this.But follow that step can not solve the problem.As I setted the dummy route and then restart k3s, it failed to start k3s and report a fatal message "unable to select an IP from default routes." default via 169.254.255.255 dev dummy0 metric 1000 And after I checked the source code of k3s and k8s , I found when k3s want to get hostname and ip, it will use func ChooseHostInterface() in "k8s.io/apimachinery/pkg/util/net" package and in this package it will detect the default route and check the ip by func IsGlobalUnicast() in net package, but now IsGlobalUnicast() will return false when using 169.xx.xx.xx.So I think maybe the change of func IsGlobalUnicast() that make the dummy route not work. Is there any other way to solve this problem? |
|
@x-coder-L you could chose a different address range for your dummy interface? I don't recall having issues with that address range in the past but it is possible that upstream has changed their utility code and it now will not auto-detect the dummy interface when using that range. |
|
@brandond Thanks your apply. Sure, using other different address range for dummy interface is ok. But we still want to use a invalid IP address to avoid IP conflict, so are there some better way to avoid the "no default routes found" problem? And maybe the example for dummy route in airgap need to update? |
@brandond is it worth updating the documentation here if |
|
yeah, we should update the docs to suggest a different range. |
|
I ran into the above with an RKE2 air-gapped agent, so used this IP instead (reserved for examples and documents per https://en.wikipedia.org/wiki/Reserved_IP_addresses so should be safe to use in general): |
Version:
v1.0.0
Describe the bug
errors when using Air-gap installing.
FATA[2019-11-28T09:04:09.931286843+08:00] apiserver exited: unable to find suitable network address.error='no default routes found in "/proc/net/route" or "/proc/net/ipv6_route"'. Try to set the AdvertiseAddress directly or provide a valid BindAddress to fix this
To Reproduce
Expected behavior
The K3s server should be started
Actual behavior
failed with error “no default routes found”
Additional context
The text was updated successfully, but these errors were encountered: