成绩配景
为懂得决节点上恳求局部service耽误63s成绩[1],咱们常设把OS的版本换成了Redhat 8.4(内核版本4.18.0-305),在VMware上欧易交易所虚出3节点集群后安排跨三层情况掉败,提醒Harbor安排掉败。
起因剖析
阐明:间隔定位这个成绩曾经有一段时光了,实在终极也没完整定位出基本起因,以是事先也不收拾记载定位进程,这里就简略描写一下,做个记载。
经由过程检查Harbor的日记,发明安排掉败的起因是安康检讨掉败,由于Harbor的podIp:port恳求在跨三层下超时,抓包发明恳求经由vxlan.calico时止于SYN_SENT报文;
实测发明,该情况上不只是Harbor的podIp:port恳求超时,其余pod效劳的恳求经由跨三层的收集也同样存在成绩,阐明是一个个性成绩,而且pod网段的七层如http恳求受影响,4层的icmp恳求不受影响);
持续经由过程抓包确认,podIp:port的恳求曾经发送到节点网卡上,但跨三层对真个节点不收到。以是,能够消除主机上的iptables跟路由的影响。现实上,也确切跟踪了iptables的恳求进程,确认欧易交易所恳求不被抛弃;
综上,开端猜忌恳求被跨三层收集的旁边装备(如交流机、路由器)抛弃了,之后相干共事在交流机上抓包,发明ping包能够抓到,但http恳求仍然抓不到,阐明交流机侧也不收到报文,成绩起因进一步减少,可能情形有:
- 出口网卡抛弃;
- 出网卡后,入交流机之前抛弃;
经由过程ehtool -s xxx下令统计较虚机网卡报文信息,不发明抛弃情形,阐明成绩不在虚机的出网卡;
对于VMware抛弃报文的情形,找到一些材料[2-6],比方混淆形式,mms设置都市有影响:
1) 经由过程ping下令指定报文长度,发明跨网段顺次ping一下pod的ip均前往畸形,确认不是mms成绩;
ping -s 1000 17欧易交易所7.177.x.x
ping -s 1472 177.177.x.x
ping -s 1500 177.177.x.x
2) 经由过程常设修正网卡为混淆形式,测试成绩仍然存在;
进一步在效劳器物理网卡上抓包(登录esxi后盾,应用pktcap-uw –uplink VMnicX –dir 2 -o result.pcap,此中vmnicX表现虚构造联的下行口物理网卡, dir欧易交易所 2表现同时抓取双向恳求), 仍然是ping包能够抓到,但http恳求仍然抓不到,阐明效劳器物理网卡上也不收到报文;
最后,丢包范畴减少到VMare下的虚机机恳求出网卡后,到效劳器物理网卡前 ,这旁边波及到虚构化的完成,详细另有什么处置就不明白了,最后改为应用物理效劳器安排;
处理计划
常设改用物理效劳器安排跨三层集群胜利,假如要应用欧易交易所VMware虚机安排,还须要持续排查根因。
参考材料
- https://lyyao09.github.io/2022/03/19/k8s/K8S%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5-Calico%E7%9A%84Vxla欧易交易所n%E6%A8%A1%E5%BC%8F%E4%B8%8B%E8%8A%82%E7%82%B9%E5%8F%91%E8%B5%B7K8s%20Service%E8%AF%B7%E6%B1%82%E5%BB%B6%E8%BF%9F/
- https://kb.vmware.com/s/article/2113783
- https://kb.vmware.com/s/article/52936
- https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.3/troubleshooting/GUID-4E4A9468-1F2B-44E1-A474-AA048A88BF1E.html
- https://communities.vmware.com/t5/vCloud-Networking-and-Security/No-SYN-ACK-reply-from-VM-on-virtual-wire-VXLAN/td-p/376545
- https://kb.vmware.com/s/article/2051814?lang=zh_CN
还没有评论,来说两句吧...