-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
"link has incompatible addresses" after restarting Flannel k8s pod #1060
Comments
Flannel version: v0.10.0 |
same setup as @b3nw. Only difference is I'm using HypriotOS 1.9.0 on Raspberry Pi 3 B+ |
Got this same thing on hypriotos 1.10.0-rc2 on a raspberry Pi 3 B+ |
@mr-sour My config is same as yours and have same the results. I'm glad at least that |
seeing the same issue with flannel
|
Same issue from applying https://raw.githubusercontent.com/coreos/flannel/master/Documentation/k8s-manifests/kube-flannel-rbac.yml on a small bramble (two RPi 4s). I noticed that there are two pods, after deleting the flannel.1 network, the first one starts without problems, the second one is entering a crash loop (with the same error). Has someone else two "kube-flannel-ds-arm-xxxx" pods? Maybe that's the problem? |
Still an issue with Hypriot v1.11.1 + K8s 1.16.1 + Flannel 0.11.0 |
@markus-seidl I can confirm, have two.
|
@markus-seidl @mkuchenbecker It is normal to have an instance on each node.
Manually deleting the link on the node and deleting the pod, as other have suggested, seems to be the resolution. |
same issue on k8s v1.16.11 ,flannel:v0.11.0 I0802 12:34:12.140814 1 vxlan.go:120] VXLAN config: VNI=1 Port=0 GBP=false DirectRouting=false |
I got the same issue, any progress on resolving this problem. |
I had same issue when power went down and then tried to get nodes back... The trick with removing the link actually helps. |
Currently flannel interface ip addresses are checked on startup when using vxlan and ipip backends. If multiple addresses are found, startup fails fatally. If only one address is found and is not the currently leased one, it will be assumed that it comes from a previous lease and be removed. This criteria seems arbitrary both in how it is done and in its timing. It may cause failures in situations where it might not be strictly necessary like for example if the node is running a dhcp client that is assigning link local addresses to all interfaces. It also might fail at flannel unexpected restarts which are completly unrelated to the external event that caused the unexpected modification in the flannel interface. This patch proposes to concern and check only ip address within the flannel network and takes the simple approach to ignore any other ip addresses assuming these would pose no problem on flannel operation. A discarded but more agressive alternative would be to remove all addresses that are not the currently leased one. Fixes flannel-io#1060 Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Currently flannel interface ip addresses are checked on startup when using vxlan and ipip backends. If multiple addresses are found, startup fails fatally. If only one address is found and is not the currently leased one, it will be assumed that it comes from a previous lease and be removed. This criteria seems arbitrary both in how it is done and in its timing. It may cause failures in situations where it might not be strictly necessary like for example if the node is running a dhcp client that is assigning link local addresses to all interfaces. It also might fail at flannel unexpected restarts which are completly unrelated to the external event that caused the unexpected modification in the flannel interface. This patch proposes to concern and check only ip address within the flannel network and takes the simple approach to ignore any other ip addresses assuming these would pose no problem on flannel operation. A discarded but more agressive alternative would be to remove all addresses that are not the currently leased one. Fixes flannel-io#1060 Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Currently flannel interface ip addresses are checked on startup when using vxlan and ipip backends. If multiple addresses are found, startup fails fatally. If only one address is found and is not the currently leased one, it will be assumed that it comes from a previous lease and be removed. This criteria seems arbitrary both in how it is done and in its timing. It may cause failures in situations where it might not be strictly necessary like for example if the node is running a dhcp client that is assigning link local addresses to all interfaces. It also might fail at flannel unexpected restarts which are completly unrelated to the external event that caused the unexpected modification in the flannel interface. This patch proposes to concern and check only ip address within the flannel network and takes the simple approach to ignore any other ip addresses assuming these would pose no problem on flannel operation. A discarded but more agressive alternative would be to remove all addresses that are not the currently leased one. Fixes flannel-io#1060 Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Currently flannel interface ip addresses are checked on startup when using vxlan and ipip backends. If multiple addresses are found, startup fails fatally. If only one address is found and is not the currently leased one, it will be assumed that it comes from a previous lease and be removed. This criteria seems arbitrary both in how it is done and in its timing. It may cause failures in situations where it might not be strictly necessary like for example if the node is running a dhcp client that is assigning link local addresses to all interfaces. It also might fail at flannel unexpected restarts which are completly unrelated to the external event that caused the unexpected modification in the flannel interface. This patch proposes to concern and check only ip address within the flannel network and takes the simple approach to ignore any other ip addresses assuming these would pose no problem on flannel operation. A discarded but more agressive alternative would be to remove all addresses that are not the currently leased one. Fixes flannel-io#1060 Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Currently flannel interface ip addresses are checked on startup when using vxlan and ipip backends. If multiple addresses are found, startup fails fatally. If only one address is found and is not the currently leased one, it will be assumed that it comes from a previous lease and be removed. This criteria seems arbitrary both in how it is done and in its timing. It may cause failures in situations where it might not be strictly necessary like for example if the node is running a dhcp client that is assigning link local addresses to all interfaces. It also might fail at flannel unexpected restarts which are completly unrelated to the external event that caused the unexpected modification in the flannel interface. This patch proposes to concern and check only ip address within the flannel network and takes the simple approach to ignore any other ip addresses assuming these would pose no problem on flannel operation. A discarded but more agressive alternative would be to remove all addresses that are not the currently leased one. Fixes flannel-io#1060 Signed-off-by: Jaime Caamaño Ruiz <[email protected]> (cherry picked from commit 33a2fac)
* vxlan: Generate MAC address before creating a link systemd 242+ assigns MAC addresses for all virtual devices which don't have the address assigned already. That resulted in systemd overriding MAC addresses of flannel.* interfaces. The fix which prevents systemd from setting the address is to define the concrete MAC address when creating the link. Fixes: flannel-io#1155 Ref: k3s-io/k3s#4188 Signed-off-by: Michal Rostecki <[email protected]> (cherry picked from commit 0198d5d) * Concern only about flannel ip addresses Currently flannel interface ip addresses are checked on startup when using vxlan and ipip backends. If multiple addresses are found, startup fails fatally. If only one address is found and is not the currently leased one, it will be assumed that it comes from a previous lease and be removed. This criteria seems arbitrary both in how it is done and in its timing. It may cause failures in situations where it might not be strictly necessary like for example if the node is running a dhcp client that is assigning link local addresses to all interfaces. It also might fail at flannel unexpected restarts which are completly unrelated to the external event that caused the unexpected modification in the flannel interface. This patch proposes to concern and check only ip address within the flannel network and takes the simple approach to ignore any other ip addresses assuming these would pose no problem on flannel operation. A discarded but more agressive alternative would be to remove all addresses that are not the currently leased one. Fixes flannel-io#1060 Signed-off-by: Jaime Caamaño Ruiz <[email protected]> (cherry picked from commit 33a2fac) * Fix flannel hang if lease expired (cherry picked from commit 78035d0) * subnets: move forward the cursor to skip illegal subnet This PR fixs an issue when flannel gets illegal subnet event in watching leases, it doesn't move forward the etcd cursor and will stuck in the same invalid event forever. (cherry picked from commit 1a1b6f1) * fix cherry-pick glitches and test failures * disable udp backend tests since we don't actually have the udp backend in our fork Co-authored-by: Michal Rostecki <[email protected]> Co-authored-by: Jaime Caamaño Ruiz <[email protected]> Co-authored-by: Chun Chen <[email protected]> Co-authored-by: huangxuesen <[email protected]>
Flannel pod starts successfully if
flannel.1
link doesn't exist. But runningkubectl delete pod kube-flannel-...
leaves theflannel.1
link and the subsequently created pod will fail to start with the following error:This is on a raspberry pi 3 B+, so the arm architecture may be a factor.
Expected Behavior
Recreating the flannel pod should succeed even if
flannel.1
link exists.Current Behavior
Flannel pod goes into CrashLoopBackoff after the pod is recreated. To allow the pod to start successfully, SSH onto the worker and run
sudo ip link delete flannel.1
. Recreating the pod will then start successfully.Possible Solution
?
Steps to Reproduce (for bugs)
kubectl delete pod kube-flannel-...
Context
About once a week my flannel pods enter this state, possibly due to a crash or restart of the pod, and I have to manually SSH in to delete the flannel link on each affected node.
Related issue: #883
Your Environment
The text was updated successfully, but these errors were encountered: