为什么登录虚拟机VNC界面会间歇性出现Dead loop on virtual device gw_11cbf51a, fix it urgently？

问题现象

VPC网络模式的集群，登录虚拟机出现 Dead loop on virtual device gw_11cbf51a, fix it urgently，如图：

原因定位

VPC网络模式的集群采用了linux开源社区的ipvlan模块实现容器网络通信，这一日志打印与ipvlan的设计实现有关，ipvlan L2E模式它优先进行二层转发，再进行三层转发。

场景还原：

假定有业务Pod A，它持续对外提供服务，不断被同节点访问收发报文，通过本机k8s service经过容器gw接口进行访问，或者同属本节点的Pod间直接互相访问。在升级、缩容，或者其他原因导致的退出场景，容器A已停止运行，对应的网络资源被回收。此时同节点的报文仍持续尝试在往容器A的IP发送报文。内核中的ipvlan模块首先尝试根据目的IP来二层转发这些报文，但是由于Pod A已无法找到该IP所属的网卡，ipvlan模块判断它有可能是个外部报文，因此尝试进行三层转发，根据路由规则匹配上了gw口，因此gw口又收到此报文，再经由ipvlan模块转发，如此循环。内核中的dev_queue_xmit函数检测到重复进入发包过程达10次，报文被丢弃同时打印该日志。

发起访问端的在报文丢失后一般会进行几次退避重试，因此在这种场景下会连续打印几次条日志，直到发起访问端的容器内ARP老化或业务自身终止访问。

跨节点容器间通信，由于目的IP及源IP不属于同个节点级专属子网（注意此子网与VPC子网概念不同），报文不会重复走到此业务流程因此，不会触发此问题。

同集群不同节点间的Pod通过Cluster模式的NodePort来访问除外，它会被SNAT成被访问端容器gw接口的IP，因此也有可能触发此日志打印。

问题影响

被访问端容器正常运行时不会有影响。容器被销毁时，有一定影响，但影响较小，重复进入发包过程10次，然后被丢包，这个过程在内核中处理十分迅速，对性能影响可以忽略。

对于ARP老化或业务自身不再重试，或新容器会被拉起，容器service服务报文经过kubeproxy重定向到新业务。

开源现状

目前开源社区ipvlan L2E模式仍存在此问题，已向开源社区反馈，待确认更优方案。

解决方法

打印Dead loop问题本身无需解决。

但推荐服务Pod使用优雅退出，在业务真正终止服务前，优先将Pod设置为删除中的状态，待业务处理完毕请求后再退出。