今天早上6点多，突然收到很多HTTP访问异常率高的报警，立刻登录grafana一看，发现又一个被很多项目依赖的关键项目异常率超过30%，平均响应时间达到十几秒，异常请求状态码全部为504，并且异常全部集中在一个ingress实例上。先从管理平台上将这台ingress下线，并保留现场，将业务恢复了再排查问题。
我们的网络方案采用的是flannel，用的vxlan模式，并开启了Directrouting。开启Directrouting后，flannel会检测节点是否属于同一网络，如果在统一网络，则通过添加静态路由的方式让pod之间通信(类似host-gw模式)，如果不在统一网络，在通过vxlan方式通信。
业务恢复之后，开始排查ingress日志。发现ingress的一直在报upstream timed out的异常，在这台主机上ping后端pod 的ip，发现也确实不通。然后查看当前ingrss所在节点的路由表，发现静态路由全部消失了，重启flannel之后，静态理由就都被重新添加回来了。
可是路由表为什么会丢失呢？开始排查系统日志，发现在故障开始的哪个时间，宿主机网络自动重启了。
Sep 6 06:17:28 KUBE-NODE52 dbus-daemon[1710]: [system] Reloaded configuration
Sep 6 06:17:28 KUBE-NODE52 systemd-networkd-wait-online[23826]: Event loop failed: Connection timed out
Sep 6 06:17:28 KUBE-NODE52 apt-helper[23814]: E: Sub-process /lib/systemd/systemd-networkd-wait-online returned an error code (1)
Sep 6 06:17:28 KUBE-NODE52 systemd[1]: apt-daily.service: Control process exited, code=exited status=100
Sep 6 06:17:28 KUBE-NODE52 systemd[1]: apt-daily.service: Failed with result 'exit-code'.
Sep 6 06:17:28 KUBE-NODE52 systemd[1]: Failed to start Daily apt download activities.
Sep 6 06:17:29 KUBE-NODE52 systemd[1]: Reexecuting.
Sep 6 06:17:29 KUBE-NODE52 kernel: [652810.873448] systemd: 25 output lines suppressed due to ratelimiting
Sep 6 06:17:29 KUBE-NODE52 kernel: [652810.879238] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
Sep 6 06:17:29 KUBE-NODE52 kernel: [652810.900052] systemd[1]: Detected architecture x86-64.
Sep 6 06:17:29 KUBE-NODE52 systemd[1]: Stopping Network Service...
Sep 6 06:17:29 KUBE-NODE52 systemd-timesyncd[1477]: Network configuration changed, trying to establish connection.
Sep 6 06:17:29 KUBE-NODE52 systemd[1]: Stopped Network Service.
Sep 6 06:17:29 KUBE-NODE52 systemd[1]: Starting Network Service...
Sep 6 06:17:29 KUBE-NODE52 systemd-networkd[800]: eno2: Gained IPv6LL
Sep 6 06:17:29 KUBE-NODE52 systemd-networkd[800]: eno1: Gained IPv6LL
Sep 6 06:17:29 KUBE-NODE52 systemd-networkd[800]: Enumeration completed
Sep 6 06:17:29 KUBE-NODE52 systemd[1]: Started Network Service.
Sep 6 06:17:29 KUBE-NODE52 systemd-networkd[800]: veth979b116: Link is not managed by us
Sep 6 06:17:29 KUBE-NODE52 systemd-networkd[800]: veth2cd4ffe: Link is not managed by us
Sep 6 06:17:29 KUBE-NODE52 systemd-networkd[800]: veth183ec5a: Link is not managed by us
Sep 6 06:17:29 KUBE-NODE52 systemd-networkd[800]: eno1: Link is not managed by us
重启网卡，flannel添加的这样静态路由会全部消失，导致pod之间网络异常。系统日志显示，在网卡重启前，只有一个systemd-networkd-wait-online服务报超时异常,/lib/systemd/systemd-networkd-wait-online 是一个命令，它会检测当前的网络配置，在没有完全配置完成前，会一直block住，直到超时。
但当我手动执行网卡重启时的那些任务，比如systemd-networkd-wait-online，apt-helper(apt-daily.service) 等，都不会产生网卡重启。
先不考虑网卡重启的原因，因为有时会修改网络配置，人为触发网络重启，所以，必须解决这个问题。方法有三个：
1、关闭vxlan的Directrouting 特性
2、写一个守护进程，重启网卡就重启flannel
3、放弃flannel方案，采用性能更好的Calico
参考：
https://github.com/coreos/flannel/issues/1070，
性能对比：
https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-10gbit-s-network-36475925a560
http://machinezone.github.io/research/networking-solutions-for-kubernetes/
网友评论