问题表现：
环境 kube-ovn 1.7 underlay vlan，未启用安全组
- 该集群有 17 个node，但是有一个node上的pod 无法和其他node上的pod直通
排除node路由配置的问题:
该节点和其他节点的路由没有任何区别:
image.png
image.png
两个pod在同一个underlay vlan 网络，且路由配置一致，无缺失，
image.png
image.png
-
抓包看了下，发现包已经进来到node上，但是没有回包，进pod内抓包看下，是否pod内收到了包
image.png
image.png
可以看到pod内部有回包，应该是pod把包发到ovs网桥上后，网桥丢包了。
到公网又没问题。
- 证实pod内部到指定ip的流量确实出不去，但是到公网的流量都是ok的
image.png
image.png
- 感觉包无故在pod网卡到ovs 网桥 之间被丢掉了，继续定位
ovs-dpctl dump-flows -m | grep drop
看看是不是被流表 drop 了
感觉异常节点的node上的流表，和正常节点没啥区别
image.png
大概率不是流表的问题
- 查下安全组的数量
image.png
ansible all -i inventory/env-inner-prod-on-prem/inventory.ini -m shell -a "/usr/sbin/iptables-save | wc -l"
虽然出现流表不一致的情况，但是大佬说underlay模式不受主机iptables影响，所以应该也不是这里的问题。
可以确定不是iptables的问题，已经手动将iptables清空。
- 只能用跟踪模式跟踪下目标节点上的pod出来的流量，看是在哪个环节丢包
参考这份文档可以深入理解下ovn逻辑流表的作用，ovn-trace，以及 ovs-appctl ofproto/trace br-int 的使用场景。 https://www.cnblogs.com/YaoDD/p/7489141.html
首先建立两个概念： openflow 即物理流表， 通过手动逐条配置openflow 层次的流表，可以实现复杂的网络功能，比如arp，dhcp。 但是由于这种方式过于底层，且无法分布式交换机-集中式管理，所以提出了ovn，ovn-controller，为了抽象聚合多条openflow流表对应的网络功能，抽象出了ovn 逻辑流表。
那么相应的trace这种工具，跟踪的就是“流表”的match 和 action。既然有两种流表，那么就有两种跟踪工具。
1. openflow ovs-appctl ofproto/trace
2. ovn logic flow （ovn-nbctl show） ovn-trace
6.1 先说下 ovs-appctl ofproto/trace 这个ovs本身支持的工具，该工具可以说是面向openflow的流跟踪工具，如果已经确认丢包发生在node上，那么基于该工具可以跟踪对应的node上ovs 数据面的实际转发情况, tracing tool to know what is happening with packets as they go through the data plane processing.
详情参考: https://docs.openvswitch.org/en/latest/topics/tracing/
6.2 ovn-trace 是一个面向逻辑流表的一个跟踪工具，可以在逻辑上跟踪整个链路，确保的只是逻辑上的结果。也有些情况下，逻辑上完全正确，但是实际有问题的情况，这种情况一般都是抽象对应的聚合openflow的流表不正确的问题。这种bug往往需要@ovs官方来改。
下面直接基于openflow的跟踪工具来跟踪:
ovs-appctl ofproto/trace br-int in_port=d82debb51461_c,tcp,nw_src=10.120.36.139,nw_dst=10.120.36.210 -generate
ovs-appctl ofproto/trace br-int in_port=d82debb51461_c,tcp,nw_src=10.120.36.139,nw_dst=114.114.114.114 -generate
7. 对照下正常节点和异常节点的流表
image.png
8. 基于kube-ovn ko trace 跟踪下，但是kube-ovn 1.7 underlay 模式pod没在ns下，无法基于ko来搞
可能还是要看看，ko怎么兼容无ns的情况
image.png
网友评论