k8s爬坑集锦[网络问题]-服务无法访问
一，前情提要：
集群中有3个节点(1个master, 2个node)，部署的业务服务为NodePort类型，通过nodeip:port访问业务的时候发现，一个nodeIP不通，另外两个不通
HOST_1=192.168.86.188 --master
HOST_2=192.168.86.189
HOST_3=192.168.86.190
188上查看：---NOK
# curl http://192.168.86.188:30038/targets
# curl http://192.168.86.188:30038/targets
189， 190上查看：---OK
# curl http://192.168.86.189:30038/targets ---ok
二，定位过程：
0. 业务的pod和服务信息，业务pod实际的调度节点为host189, pod/容器IP为10.244.2.6
# kubectl get svc -nprometheus NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE prometheus ClusterIP 10.96.167.153 <none> 9090/TCP 138m prometheus-nodeport NodePort 10.109.216.20 <none> 9090:30038/TCP 138m ---服务ip地址 # kubectl get pods -nprometheus -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE prometheus-0 2/2 Running 0 143m 10.244.2.6 host189 <none>
1.查看各节点中iptables中的规则
1)host188上，即问题节点上 [root@host188 ~]## iptables -t nat -L KUBE-NODEPORTS KUBE-MARK-MASQ tcp -- anywhere anywhere /* prometheus/prometheus-nodeport:http */ tcp dpt:30038 KUBE-SVC-SO4PW3GA7SPS7IHM tcp -- anywhere anywhere /* prometheus/prometheus-nodeport:http */ tcp dpt:30038 Chain KUBE-SVC-SO4PW3GA7SPS7IHM (2 references) target prot opt source destination KUBE-SEP-5GEH5OENN4FETTOQ all -- anywhere anywhere Chain KUBE-SEP-5GEH5OENN4FETTOQ (1 references) target prot opt source destination KUBE-MARK-MASQ all -- 10.244.2.6 anywhere DNAT tcp -- anywhere anywhere tcp to:10.244.2.6:9090
【解析】: 如果目的地址是30038的，则首先，打上做MASQ的mark, 然后进行MASQ即将其进行目的地址转化，即交给SVC链(代表集群level的服务)
然后，SVC链会做分流，然后选择一个SEP链(代表一个enpoint)，在这里就是交给唯一的pod，地址正是10.244.2.6:9090，
最后，进入路由表进行路由匹配
附: # iptables -t nat -S 和 #iptables -t nat -L
二者还是有区别的，前者信息能更完整一些，所以推荐二者结合使用
2. 路由方面的追踪
[root@host188 ~]# route -n ----问题节点上的路由表 Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.86.1 0.0.0.0 UG 0 0 0 ens160 10.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0 10.244.1.0 10.244.1.0 255.255.255.0 UG 0 0 0 flannel.1 ###去往宿主机是190上的路由,ok的 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 ens160 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 192.168.86.0 0.0.0.0 255.255.255.0 U 0 0 0 ens160
[root@host190 ~]# route -n ----标准节点上的路由表 Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.86.1 0.0.0.0 UG 0 0 0 ens160 10.244.0.0 10.244.0.0 255.255.255.0 UG 0 0 0 flannel.1 ###去往宿主机188上的pods的网段路由 10.244.1.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0 10.244.2.0 10.244.2.0 255.255.255.0 UG 0 0 0 flannel.1 ###去往189宿主机上pods的网段路由 10.244.57.0 0.0.0.0 255.255.255.192 U 0 0 0 * 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 ens160 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 192.168.86.0 0.0.0.0 255.255.255.0 U 0 0 0 ens160
【解析】:可以看到188上的路由表中没有2.0网段的路由，即去190节点上的pod的路由，而目标pod正好是部署在了190节点上。那么路由是谁来添加的？
根据k8s的网络原理(flannel)知道，k8s为集群中的每个节点分配一个子网段，然后记录在etcd中，flannel通过读取etcd的信息(不一定是直接读取，可能是借助api server)得到各个其他节点上分配的子网段信息, 然后向路由表中添加路由信息: 能够到达其他pod的路由信息。由此我们知道，出现问题可能有两个方向: 1)etcd信息损毁; 2)flannel添加路由失败。
wxy碎碎念：
实际上在开始查看路由表的时候，188节点上，使用ip route命令是没有该网段信息，而用route -n命令是可以看到2.0信息，但是其Iface对应的值是*，并不是应该的flannel.1
然后删除这条路由失败，提示NO Process...,但后来发现是掩码不对，之后我们会说
3. 检查etcd的信息
HOST_1=192.168.86.188 HOST_2=192.168.86.189 HOST_3=192.168.86.190 ENDPOINTS=$HOST_1:2379,$HOST_2:2379,$HOST_3:2379 TLS_CERT=" --cacert=/etc/etcd/pki/ca.pem --cert=/etc/etcd/pki/client.pem --key=/etc/etcd/pki/client-key.pem" # docker exec etcd /bin/sh -c "export ETCDCTL_API=3 && etcdctl --endpoints=$ENDPOINTS $TLS_CERT get /registry/minions/linuxtest1a7a" /registry/minions/host189 结果: ...以下信息为flannel的子网段信息和对应的public ip(host的地址)... "flannel.alpha.coreos.com/public-ip 192.168.86.189bB 10.244.2.0/24 ¿! ....
【解析】: 查看了所有节点的信息，发现子网段以及对应的public ip都是存在且正确的，所以说明问题不在etcd身上。(wxy：因为重启过etcd, 所以实际上一直担心是他的问题，这下稍稍放心了)
4. flannel方面的问题
1) 首先，检查下路由表关于flannel接口方面的信息，如下是查看interface的邻居，这些都是通过arp来发现的
[root@host188 ~]## ip neigh show dev flannel.1 ###问题节点上，只发现了190一个neighbor 10.244.1.0 lladdr 76:50:75:23:dd:f8 PERMANENT [root@host189 ~]# ip neigh show dev flannel.1 ###ok节点1: 有发现两个neighbor 10.244.1.0 lladdr 76:50:75:23:dd:f8 PERMANENT 10.244.0.0 lladdr 5a:d6:46:ab:ea:17 PERMANENT [root@host188 net.d]# bridge fdb show flannel.1 ###问题节点上的，转发表信息 01:00:5e:00:00:01 dev ens160 self permanent 01:00:5e:00:00:01 dev docker0 self permanent b6:88:ae:4a:ac:42 dev docker0 vlan 1 master docker0 permanent 76:50:75:23:dd:f8 dev flannel.1 dst 192.168.86.190 self permanent ------------ [root@host190 ~]# ip neigh show dev flannel.1 ###ok节点2: 也有发现两个neighbor 10.244.2.0 lladdr 92:e7:b6:4e:e5:73 PERMANENT 10.244.0.0 lladdr 5a:d6:46:ab:ea:17 PERMANENT
【解析】: 这其实是再一次印证了路由缺失的问题，因为如上是arp信息，正是因为路由的不存在，导致了对应的neighbor的缺失，所以还是要看看flannel的问题
2) 然后，flannel插件的检查，发现其运行日志有报出路由添加失败，至此直接原因找到
# kubectl logs -f -nkube-system kube-flannel-ds-fvj6h I1028 01:59:01.891322 1 main.go:475] Determining IP address of default interface ----会有删除操作? I1028 01:59:01.891599 1 main.go:488] Using interface with name ens160 and address 192.168.86.188 I1028 01:59:01.891622 1 main.go:505] Defaulting external address to interface address (192.168.86.188) I1028 01:59:01.996901 1 kube.go:131] Waiting 10m0s for node controller to sync I1028 01:59:01.996901 1 kube.go:294] Starting kube subnet manager I1028 01:59:02.997083 1 kube.go:138] Node controller sync successful I1028 01:59:02.997115 1 main.go:235] Created subnet manager: Kubernetes Subnet Manager - host188 I1028 01:59:02.997131 1 main.go:238] Installing signal handlers I1028 01:59:02.997229 1 main.go:353] Found network config - Backend type: vxlan I1028 01:59:02.997297 1 vxlan.go:120] VXLAN config: VNI=1 Port=0 GBP=false DirectRouting=false I1028 01:59:02.997619 1 main.go:300] Wrote subnet file to /run/flannel/subnet.env I1028 01:59:02.997630 1 main.go:304] Running backend. I1028 01:59:02.997636 1 main.go:322] Waiting for all goroutines to exit I1028 01:59:02.997650 1 vxlan_network.go:60] watching for new subnet leases E1028 01:59:02.997781 1 vxlan_network.go:158] failed to add vxlanRoute (10.244.2.0/24 -> 10.244.2.0): invalid argument ###关键：flannel报出路由添加失败
3)进一步的，为为了验证flannel对路由的影响，我修改了DaemonSet，添加了亲和性，让问题节点188上不能被调度flannel，如下
修改DaemonSet的亲和性, 让这个节点不启动flannel进程，查看路由信息是否会删除 spec: revisionHistoryLimit: 10 selector: matchLabels: app: flannel tier: node template: metadata: creationTimestamp: null labels: app: flannel tier: node spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: NotIn values: - host188 # kubectl logs -f -nkube-system kube-flannel-ds-fvj6h ... I1028 01:59:02.997650 1 vxlan_network.go:60] watching for new subnet leases E1028 01:59:02.997781 1 vxlan_network.go:158] failed to add vxlanRoute (10.244.2.0/24 -> 10.244.2.0): invalid argument I1028 05:31:48.554667 1 main.go:337] shutdownHandler sent cancel signal... E1028 05:31:48.554782 1 vxlan_network.go:183] DelARP failed: no such file or directory E1028 05:31:48.554812 1 vxlan_network.go:187] DelFDB failed: no such file or directory E1028 05:31:48.554835 1 vxlan_network.go:191] failed to delete vxlanRoute (10.244.2.0/24 -> 10.244.2.0): no such process
【解析】: 也就是说，flannel在销毁的时候，是会尝试销毁相关的路由条目，但是为什么会删除失败呢，而且还是no such process，很明显这是内核报出的错误
而flannel程序本身不可能有问题，肯定是内核此时的状态，不允许flannel删除，为什么呢？在仔细看了下路由表，发现路由表中该条路由的掩码并不是24位，
这是哪里的进程残留下来的路由条目么？其实此时就有了蛛丝马迹，是由残留存在了...
再结合网络上的一些博客有提到：flannel报出 invalid argument，有可能是和接口地址冲突了, 再加上此时的这条残留，突然觉得是不是忽略了什么
附: 删除路由操作
# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ..10.244.2.0 0.0.0.0 255.255.255.192 U 0 0 0 * ----就是你 手动删除： ip route del 10.244.2.0/24 --not ok # ip route del 10.244.2.0/255.255.255.192 --ok，删除成功 # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.86.1 0.0.0.0 UG 0 0 0 ens160 10.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 ens160 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 192.168.86.0 0.0.0.0 255.255.255.0 U 0 0 0 ens160
4) 接口信息全面检查
# ifconfig -a ###注意要有个参数a, 才能发现这条信息，查看了别的设备，虽然也有这个接口，但是网段都是非冲突的，如下 [root@host188 etc]# ifconfig -a .... tunl0: flags=128<NOARP> mtu 1440 inet 10.244.2.0 netmask 255.255.255.255 ###这个网段，刚好是当前集群网络中使用的，所以导致发生了冲突 tunnel txqueuelen 1000 (IPIP Tunnel) RX packets 9552860 bytes 9661438904 (8.9 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 10309373 bytes 2978060504 (2.7 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@host189 ~]# ifconfig -a ... tunl0: flags=128<NOARP> mtu 1440 inet 10.244.188.0 netmask 255.255.255.255 tunnel txqueuelen 1000 (IPIP Tunnel) RX packets 11031772 bytes 8680651091 (8.0 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 10557451 bytes 9723264443 (9.0 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@host190 ~]# ifconfig -a ... tunl0: flags=128<NOARP> mtu 1440 inet 10.244.57.0 netmask 255.255.255.255 tunnel txqueuelen 1000 (IPIP Tunnel) RX packets 720412 bytes 48975635 (46.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 701770 bytes 5701518725 (5.3 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
【解析】: 经过和ll确认，IPIP Tunnel是k8s 1.18版本中，calico类型的网络中使用的，并不是当前的，而这个测试环境会经常k8s 1.18切换安装，所以有了这样的残留。
三，问题解决
[root@host188 etc]# ifconfig tunl0 down [root@host188 etc]# ip tunnel del tunl0 delete tunnel "tunl0" failed: Operation not permitted [root@host188 etc]# ip tunnel show tunl0: ip/ip remote any local any ttl inherit nopmtudisc [root@host188 etc]# lsmod Module Size Used by ... ipip 13465 0 ---ipip模块的存在让tunl0无法删除 [root@host188 etc]# rmmod ipip ----卸载内核模块 [root@host188 etc]# ip tunnel show ---此时删除成功
[root@host188 etc]# route -n ---至此，路由信息正确添加进来了 Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.86.1 0.0.0.0 UG 0 0 0 ens160 10.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0 10.244.1.0 10.244.1.0 255.255.255.0 UG 0 0 0 flannel.1 10.244.2.0 10.244.2.0 255.255.255.0 UG 0 0 0 flannel.1 ----有了 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 ens160 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 192.168.86.0 0.0.0.0 255.255.255.0 U 0 0 0 ens160
最后的最后，重新加载ipip模块
# modprobe ipip # lsmod Module Size Used by ipip 13465 0
#此时tunl0也自动被创建，但并未申请ip tunl0: flags=128<NOARP> mtu 1480 tunnel txqueuelen 1000 (IPIP Tunnel) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
============================================END=========================================================================
