-
Notifications
You must be signed in to change notification settings - Fork 58
Description
Hello,
we are seeing quite strange and (at least for me) hard to debug issue when a Kuberetes node gets into a state where any pod running on it cannot reach any other pods withing the cluster including pods running on the very same node.
We have a node being in this situation right now, so I can provide any debug output if needed (the node is cordened from Kubernetes and all production pods are drained from it).
Let me describe our setup first:
root@ip-10-110-174-111:~# /opt/cni/bin/cni-ipvlan-vpc-k8s-tool eniif
iface mac id subnet subnet_cidr secgrps vpc ips
eth0 0a:2a:d3:92:7e:8c eni-018ae0468fdf10781 subnet-0e238589d27216701 10.110.174.0/25 [sg-0ccda037d02911c59] vpc-0f1dab3aaf561ddba [10.110.174.111]
eth1 0a:b5:1f:03:d1:d6 eni-0f5769f94c79afb21 subnet-0004ceb2afd7e3ba7 100.96.224.0/19 [sg-0ccda037d02911c59] vpc-0f1dab3aaf561ddba [100.96.236.178 100.96.235.253 100.96.255.154 100.96.248.69 100.96.254.43 100.96.253.184 100.96.234.151 100.96.254.206 100.96.244.19 100.96.230.47 100.96.251.97 100.96.239.70 100.96.228.204 100.96.236.91 100.96.225.8]
eth2 0a:e2:0f:b4:49:4c eni-0aba7b11eb2077b50 subnet-0004ceb2afd7e3ba7 100.96.224.0/19 [sg-0ccda037d02911c59] vpc-0f1dab3aaf561ddba [100.96.254.118 100.96.247.76 100.96.233.85 100.96.228.225 100.96.255.230 100.96.227.61 100.96.230.198 100.96.247.0 100.96.236.129 100.96.255.57 100.96.236.8]
We only have two pods running on the node now:
fluentd-loggly-hb9lf 1/1 Running 0 228d 100.96.236.178 ip-10-110-174-111.eu-central-1.compute.internal
jhorky-shell 1/1 Running 0 21m 100.96.254.43 ip-10-110-174-111.eu-central-1.compute.internal
The pods can't see each other even though they are in the same (/19) subnet and running on the same node:
bash-5.0# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UNKNOWN group default
link/ether 0a:b5:1f:03:d1:d6 brd ff:ff:ff:ff:ff:ff
inet 100.96.254.43/19 brd 100.96.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::8b5:1fff:fe03:d1d6/64 scope link dadfailed tentative
valid_lft forever preferred_lft forever
4: veth0@if114: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 0a:70:58:d2:9d:d6 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::870:58ff:fed2:9dd6/64 scope link
valid_lft forever preferred_lft forever
bash-5.0# ping 100.96.236.178
PING 100.96.236.178 (100.96.236.178) 56(84) bytes of data.
From 100.96.254.43 icmp_seq=1 Destination Host Unreachable
From 100.96.254.43 icmp_seq=2 Destination Host Unreachable
From 100.96.254.43 icmp_seq=3 Destination Host Unreachable
In a tcpdump (running with -i any) on the compute node, I see these ARP requests but no replies:
15:36:09.107512 ARP, Request who-has 100.96.236.178 tell 100.96.254.43, length 28
15:36:10.129829 ARP, Request who-has 100.96.236.178 tell 100.96.254.43, length 28
15:36:11.153879 ARP, Request who-has 100.96.236.178 tell 100.96.254.43, length 28
15:36:12.177949 ARP, Request who-has 100.96.236.178 tell 100.96.254.43, length 28
15:36:13.201804 ARP, Request who-has 100.96.236.178 tell 100.96.254.43, length 28
When trying to ping the other way around, the situation is very different:
The ping works:
PING 100.96.254.43 (100.96.254.43) 56(84) bytes of data.
64 bytes from 100.96.254.43: icmp_seq=1 ttl=64 time=0.168 ms
64 bytes from 100.96.254.43: icmp_seq=2 ttl=64 time=0.051 ms
The tcpdump running on the "debug jhorky" docker shows: just this (no ICMP messages?!?):
15:57:22.065934 ARP, Request who-has 100.96.254.43 tell 100.96.236.178, length 28
15:57:22.066041 ARP, Reply 100.96.254.43 is-at 0a:b5:1f:03:d1:d6, length 28
The tcpdump running on the compute node doesn't show any icmp as well:
15:57:16.241711 ARP, Request who-has 100.96.236.178 tell 10.110.174.111, length 28
15:57:16.241732 ARP, Reply 100.96.236.178 is-at d2:5d:eb:14:bf:f1, length 28
Anyway, right now, I have no idea what more to look at.
Once again, the node is in this state, so I can provide any output needed.
Any help much appreciated.