Closed yakneens closed 5 years ago
Weave Net takes the addresses to connect to from Kubernetes. It does not specify the interface to connect from. That will be determined by the host routing rules.
However you seem to have a deeper problem:
IP allocation was seeded by different peers (received: [4a:ba:4c:fa:5c:b3(tracker)], ours: [6a:6c:c9:b5:18:8a(getter-test)]), retry: 2019-01-27 17:00:44.356836268 +0000 UTC m=+6152.062472741
Under this condition you will never have a fully-connected network. Did you start those nodes at different times, or try to disconnect from one network and connect to another?
You can try to recover as described here
Thanks for your response @bboreham. I was able to follow the instructions at the link you sent and after deleting the /var/lib/weave/weave-netdata.db at the master node and deleting the weave pod on the same node, it was able to peer with the rest of the nodes. I still have some concerns that weave is confused about which IP address to use (or is maybe inconsistent). After the recovery process I see the following on the node that ended up orphaned:
[root@tracker weave]# weave status connections
-> 192.168.0.72:6783 established fastdp 6a:6c:c9:b5:18:8a(getter-test) mtu=1376
-> 192.168.0.61:6783 established fastdp e2:fd:43:23:90:d2(worker-3) mtu=1376
-> 10.35.104.5:6783 failed cannot connect to ourself, retry: never
whereas on another node:
[root@worker-3 var]# weave status connections
<- 192.168.0.15:33471 established fastdp 4a:ba:4c:fa:5c:b3(tracker) mtu=1376
-> 192.168.0.72:6783 established fastdp 6a:6c:c9:b5:18:8a(getter-test) mtu=1376
-> 10.35.104.5:6783 failed Multiple connections to 4a:ba:4c:fa:5c:b3(tracker) added to e2:fd:43:23:90:d2(worker-3), retry: 2019-01-28 09:20:01.186284464 +0000 UTC m=+64908.891920940
-> 192.168.0.61:6783 failed cannot connect to ourself, retry: never
so, to me it looks like on the first node weave is still trying to talk to itself at the IP address 10.35.104.5 which is on the wrong interface (eth1 on that node, rather than the correct eth0 where the IP is 192.168.0.15). With that in mind, I don't quite understand your first comment about how weave figures out what IP address to use for communication. Would you mind clarifying a bit how this works? Assume that VMs have multiple networks (as in my example), and only one of these is set up for the VMs to be able communicate to each other. In my scenario it's the one with IP range 192.168.0.15/24 that ends up on eth0 on the VMs. The other networks are there to expose some NFS shares to the VMs and are not set up for VM-to-VM communication. I installed weave following the Kubernetes guide at (https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/). The only custom settings that I applied were the kubeadm config settings as follows:
[root@tracker initial]# cat kubeadm_config_map.yaml
apiVersion: kubeadm.k8s.io/v1beta1
kind: InitConfiguration
nodeRegistration:
kubeletExtraArgs:
cloud-provider: "openstack"
cloud-config: "/etc/kubernetes/cloud.conf"
---
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: v1.13.0
apiServer:
extraArgs:
cloud-provider: "openstack"
cloud-config: "/etc/kubernetes/cloud.conf"
extraVolumes:
- name: cloud
hostPath: "/etc/kubernetes/cloud.conf"
mountPath: "/etc/kubernetes/cloud.conf"
controllerManager:
extraArgs:
cloud-provider: "openstack"
cloud-config: "/etc/kubernetes/cloud.conf"
extraVolumes:
- name: cloud
hostPath: "/etc/kubernetes/cloud.conf"
mountPath: "/etc/kubernetes/cloud.conf"
networking:
dnsDomain: cluster.local
podSubnet: 10.32.0.0/16
and correspondingly I installed weave using
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')&env.IPALLOC_RANGE=10.32.0.0/16"
How does weave in this case decide which IP address the node should advertise itself on for peering? It looks like for my master node it chose an IP on eth1, whereas on the other nodes it chose IPs on eth0, leading to the issue I described.
Thank you for any insights.
How does weave in this case decide which IP address the node should advertise itself on for peering?
There is no "advertise" as such; it happens indirectly.
-host
on the command-line (default blank, meaning all addresses)--no-discovery
.It is expected that some addresses will turn out to map to the same node as other addresses, also expected that one node cannot figure this out (e.g. because of NAT) without trying them.
weave status peers
will print the complete map as known by one node.
Thanks, so point number 2 seems a bit opaque to me still. Is there a particular API call that weave makes to k8s to get a list of IP addresses to connect out to? Is there any way to control which IP addresses end up on the list? For instance, I just added another node to my cluster and things seem to have gotten messy again.
[root@tracker redis]# weave status peers
4a:ba:4c:fa:5c:b3(tracker)
-> 192.168.0.72:6783 6a:6c:c9:b5:18:8a(getter-test) established
-> 192.168.0.61:6783 e2:fd:43:23:90:d2(worker-3) established
<- 10.35.104.51:37637 ee:4f:3a:09:e0:ea(worker-2) established
6a:6c:c9:b5:18:8a(getter-test)
<- 192.168.0.61:49580 e2:fd:43:23:90:d2(worker-3) established
<- 192.168.0.15:42008 4a:ba:4c:fa:5c:b3(tracker) established
<- 192.168.0.10:58046 ee:4f:3a:09:e0:ea(worker-2) established
e2:fd:43:23:90:d2(worker-3)
-> 192.168.0.10:6783 ee:4f:3a:09:e0:ea(worker-2) established
<- 192.168.0.15:33471 4a:ba:4c:fa:5c:b3(tracker) established
-> 192.168.0.72:6783 6a:6c:c9:b5:18:8a(getter-test) established
ee:4f:3a:09:e0:ea(worker-2)
-> 10.35.104.5:6783 4a:ba:4c:fa:5c:b3(tracker) established
-> 192.168.0.72:6783 6a:6c:c9:b5:18:8a(getter-test) established
<- 192.168.0.61:33543 e2:fd:43:23:90:d2(worker-3) established
My interpretation of this is that the tracker node thinks that worker-2 (the new node) is on 10.35.104.51 whereas worker-3 thinks worker-2 is on 192.168.0.10. worker-2 thinks tracker is on 10.35.104.5 whereas worker-3 thinks tracker is on 192.168.0.15.
If I look at the routing tables I see the following:
[root@tracker redis]# ip route
default via 192.168.0.1 dev eth0
10.32.0.0/16 dev weave proto kernel scope link src 10.32.64.0
10.35.104.0/24 dev eth1 proto kernel scope link src 10.35.104.5
10.35.105.0/24 dev eth2 proto kernel scope link src 10.35.105.10
10.35.110.0/24 dev eth3 proto kernel scope link src 10.35.110.13
169.254.169.254 via 192.168.0.1 dev eth0 proto static
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.15
blackhole 192.169.45.0/26 proto bird
[root@worker-2 lib]# ip route
default via 192.168.0.1 dev eth0
10.32.0.0/16 dev weave proto kernel scope link src 10.32.160.0
10.35.104.0/24 dev eth1 proto kernel scope link src 10.35.104.51
10.35.105.0/24 dev eth2 proto kernel scope link src 10.35.105.45
10.35.110.0/24 dev eth3 proto kernel scope link src 10.35.110.52
169.254.169.254 via 192.168.0.1 dev eth0 proto static
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.10
blackhole 192.169.2.0/24 proto bird
192.169.3.0/24 via 10.35.110.62 dev eth3 proto bird
Doesn't this mean that everything should try to route through the 192.168.0.15/24 network? I don't quite understand how to get weave to use the network I want or stop using the networks I don't want. Thanks again.
--
is there a particular API call that weave makes to k8s to get a list of IP addresses to connect out to?
Yes, it's the same as what you should see from kubectl get nodes -o wide
Doesn't this mean that everything should try to route through the 192.168.0.15/24 network?
Your routing tables give many options depending on the destination; a different src
address will be used according to the rules.
So kubectl get nodes -o wide
returns:
[root@tracker redis]# kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
getter-test Ready <none> 20h v1.13.2 192.168.0.72 <none> CentOS Linux 7 (Core) 3.10.0-693.5.2.el7.x86_64 docker://18.9.1
tracker Ready master 21h v1.13.2 192.168.0.15 <none> CentOS Linux 7 (Core) 3.10.0-693.5.2.el7.x86_64 docker://18.9.1
worker-2 Ready <none> 93m v1.13.2 192.168.0.10 <none> CentOS Linux 7 (Core) 3.10.0-693.5.2.el7.x86_64 docker://18.9.1
worker-3 Ready <none> 20h v1.13.2 192.168.0.61 <none> CentOS Linux 7 (Core) 3.10.0-693.5.2.el7.x86_64 docker://18.9.1
all IPs are on the 192.168.0.0/24 subnet, yet weave somehow ends up with addresses from the 10.35.104.5/24 subnet on some nodes.
Actually we can see it going wrong on startup in the logs you posted:
master:
INFO: 2019/01/27 13:47:19.143236 Launch detected - using supplied peer list: [10.35.104.5]
worker-3:
INFO: 2019/01/27 15:18:13.573258 Launch detected - using supplied peer list: [192.168.0.72 10.35.104.5 192.168.0.61]
This "supplied peer list" comes from the call in the kube-utils
program I pointed at earlier.
If you restart those Weave Net pods (you can just kubectl delete
one and it will be recreated) do they have the same "supplied peer list" ?
If so, can you do kubectl get nodes -o yaml
- see if there is something in the detail that is different from the -o wide
version?
You can double-check the result - kubectl exec
into a Weave Net pod and run /home/weave/kube-utils
So, indeed, the yaml version shows that the master node lists several IP addresses, while the other nodes only show one. Where is this info populated from?
- apiVersion: v1
kind: Node
metadata:
annotations:
kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
node.alpha.kubernetes.io/ttl: "0"
volumes.kubernetes.io/controller-managed-attach-detach: "true"
creationTimestamp: "2019-01-27T13:42:40Z"
labels:
beta.kubernetes.io/arch: amd64
beta.kubernetes.io/instance-type: "16"
beta.kubernetes.io/os: linux
failure-domain.beta.kubernetes.io/zone: AZ_1
kubernetes.io/hostname: tracker
node-role.kubernetes.io/master: ""
name: tracker
resourceVersion: "128914"
selfLink: /api/v1/nodes/tracker
uid: 6a623f7a-2239-11e9-a615-fa163e9a84ea
spec:
podCIDR: 10.32.0.0/24
providerID: openstack:///9abff20f-9775-44fd-8778-ce5d66c48082
status:
addresses:
- address: 192.168.0.15
type: InternalIP
- address: 10.35.105.10
type: InternalIP
- address: 10.35.110.13
type: InternalIP
- address: 10.35.104.5
type: InternalIP
allocatable:
cpu: "8"
ephemeral-storage: "19316953466"
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 32678824Ki
pods: "110"
capacity:
cpu: "8"
ephemeral-storage: 20960236Ki
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 32781224Ki
pods: "110"
conditions:
- lastHeartbeatTime: "2019-01-28T08:59:17Z"
lastTransitionTime: "2019-01-28T08:59:17Z"
message: Weave pod has set this
reason: WeaveIsUp
status: "False"
type: NetworkUnavailable
- lastHeartbeatTime: "2019-01-28T12:12:59Z"
lastTransitionTime: "2019-01-28T11:50:08Z"
message: kubelet has sufficient memory available
reason: KubeletHasSufficientMemory
status: "False"
type: MemoryPressure
- lastHeartbeatTime: "2019-01-28T12:12:59Z"
lastTransitionTime: "2019-01-28T11:50:08Z"
message: kubelet has no disk pressure
reason: KubeletHasNoDiskPressure
status: "False"
type: DiskPressure
- lastHeartbeatTime: "2019-01-28T12:12:59Z"
lastTransitionTime: "2019-01-28T11:50:08Z"
message: kubelet has sufficient PID available
reason: KubeletHasSufficientPID
status: "False"
type: PIDPressure
- lastHeartbeatTime: "2019-01-28T12:12:59Z"
lastTransitionTime: "2019-01-28T11:50:08Z"
message: kubelet is posting ready status
reason: KubeletReady
status: "True"
type: Ready
- lastHeartbeatTime: "2019-01-27T13:42:40Z"
lastTransitionTime: "2019-01-27T13:43:57Z"
message: Kubelet never posted node status.
reason: NodeStatusNeverUpdated
status: Unknown
type: OutOfDisk
daemonEndpoints:
kubeletEndpoint:
Port: 10250
...
nodeInfo:
architecture: amd64
bootID: f4c58653-d452-4101-94eb-2d490da88e09
containerRuntimeVersion: docker://18.9.1
kernelVersion: 3.10.0-693.5.2.el7.x86_64
kubeProxyVersion: v1.13.2
kubeletVersion: v1.13.2
machineID: ea4bb35ac7b55a78c3c4fb8cdb4b7f65
operatingSystem: linux
osImage: CentOS Linux 7 (Core)
systemUUID: 9ABFF20F-9775-44FD-8778-CE5D66C48082
kube-utils
on master
/home/weave # /home/weave/kube-utils
192.168.0.43
192.168.0.72
192.168.0.9
10.35.104.5
192.168.0.10
192.168.0.61
That list stays the same after restarting the pod. But weave status peers
seems to return the correct addresses everywhere now (compare to the output in my previous message).
[root@worker-3 var]# weave status peers
4a:ba:4c:fa:5c:b3(tracker)
-> 192.168.0.61:6783 e2:fd:43:23:90:d2(worker-3) established
-> 192.168.0.72:6783 6a:6c:c9:b5:18:8a(getter-test) established
-> 192.168.0.9:6783 32:16:2e:7f:ea:3a(salt-master) established
-> 192.168.0.10:6783 ee:4f:3a:09:e0:ea(worker-2) established
6a:6c:c9:b5:18:8a(getter-test)
<- 192.168.0.10:58046 ee:4f:3a:09:e0:ea(worker-2) established
-> 192.168.0.9:6783 32:16:2e:7f:ea:3a(salt-master) established
<- 192.168.0.61:49580 e2:fd:43:23:90:d2(worker-3) established
<- 192.168.0.15:48676 4a:ba:4c:fa:5c:b3(tracker) established
ee:4f:3a:09:e0:ea(worker-2)
<- 192.168.0.9:60403 32:16:2e:7f:ea:3a(salt-master) established
<- 192.168.0.15:54916 4a:ba:4c:fa:5c:b3(tracker) established
-> 192.168.0.72:6783 6a:6c:c9:b5:18:8a(getter-test) established
<- 192.168.0.61:33543 e2:fd:43:23:90:d2(worker-3) established
32:16:2e:7f:ea:3a(salt-master)
-> 192.168.0.61:6783 e2:fd:43:23:90:d2(worker-3) established
-> 192.168.0.10:6783 ee:4f:3a:09:e0:ea(worker-2) established
<- 192.168.0.72:57506 6a:6c:c9:b5:18:8a(getter-test) established
<- 192.168.0.15:50695 4a:ba:4c:fa:5c:b3(tracker) established
e2:fd:43:23:90:d2(worker-3)
<- 192.168.0.15:49219 4a:ba:4c:fa:5c:b3(tracker) established
-> 192.168.0.72:6783 6a:6c:c9:b5:18:8a(getter-test) established
-> 192.168.0.10:6783 ee:4f:3a:09:e0:ea(worker-2) established
<- 192.168.0.9:35252 32:16:2e:7f:ea:3a(salt-master) established
Where is this info populated from?
Not something I know off the top of my head. Looking at https://github.com/kubernetes/kubernetes/issues/44702, it seems it may come from the cloud-provider (OpenStack?) or from the command-line to kubelet (--node-ip
).
Maybe you could ask in the Kubernetes Slack?
Created an issue at k8s repo - https://github.com/kubernetes/kubernetes/issues/73407
@llevar Can we close this issue? Multiple addresses must be coming from openstack cloud provider as noted earlier.
Weave Net takes the addresses to connect to from Kubernetes. It does not specify the interface to connect from. That will be determined by the host routing rules.
However you seem to have a deeper problem:
IP allocation was seeded by different peers (received: [4a:ba:4c:fa:5c:b3(tracker)], ours: [6a:6c:c9:b5:18:8a(getter-test)]), retry: 2019-01-27 17:00:44.356836268 +0000 UTC m=+6152.062472741
Under this condition you will never have a fully-connected network. Did you start those nodes at different times, or try to disconnect from one network and connect to another?
You can try to recover as described here
Thank you so much!
Weave Net takes the addresses to connect to from Kubernetes. It does not specify the interface to connect from. That will be determined by the host routing rules.
However you seem to have a deeper problem:
IP allocation was seeded by different peers (received: [4a:ba:4c:fa:5c:b3(tracker)], ours: [6a:6c:c9:b5:18:8a(getter-test)]), retry: 2019-01-27 17:00:44.356836268 +0000 UTC m=+6152.062472741
Under this condition you will never have a fully-connected network. Did you start those nodes at different times, or try to disconnect from one network and connect to another?
You can try to recover as described here
This fix doesn't seem to work for me. I have tried deleting the /var/lib/weave db file and restarting the node, but the same error persists. Which nodes specifically in this error should be restarted?
2020-01-20T12:39:27.551980486Z INFO: 2020/01/20 12:39:27.551692 ->[172.20.33.66:34547|a2:c6:1f:d4:5b:95(nodew00424.nonprod.company.com)]: connection shutting down due to error: IP allocation was seeded by different peers (received: [16:c0:ca:ad:e4:62 1e:75:c6:8c:ea:73 7a:d3:c8:59:b6:f1], ours: [22:03:ad:09:70:b5(nodei00402.nonprod.company.com) 7e:a3:30:e9:2a:cc(nodei00404.nonprod.company.com) a2:9f:2f:6e:e1:86(nodei00403.nonprod.company.com) a2:9f:d5:6e:9c:c3(nodew00401.nonprod.company.com)])
The first node in the error message seems to be a random node, the bottom 4 recur in every error. I have tried deleting the /lib/var/weave data for those and restarting the vm but it continues
@dstrimble please open a separate issue. Original issue was opened for different problem.
@dstrimble please open a separate issue. Original issue was opened for different problem.
https://github.com/weaveworks/weave/issues/3757 Done, thank you.
What you expected to happen?
Created kubernetes cluster of 1 master and 2 nodes on Openstack using kubeadm and weave as the network. All VMs have multiple network interfaces, i.e. -
Expecting all nodes to be joined in a single network.
What happened?
Weave does not seem to select the same interface on all nodes, resulting in a failure to peer. On two nodes weave seems to have selected eth0 (which is desired) and the two nodes ended up peered:
But on the master node interface eth3 seems to have been selected, resulting the master not peering with other nodes.
As a result cross-node communication is broken and pods end up getting assigned with conflicting IPs.
How to reproduce it?
Anything else we need to know?
Kubeadm config
Versions:
Logs:
weave log on master node
Logs on node
Network: