K8S问题排查

　　问题背景
　　K8S集群中修改calico的网络为vxlan模式后，发现部分service在节点上无法访问（实际上是延迟访问，延迟时间稳定在1min3s左右）。〔rootnode2〕timecurlshttp：10。96。91。255real1m3。136suser0m0。005ssys0m0。005s原因分析
　　先确认问题范围，在环境上找多个service依次测试发现，如果调用service的节点和实际pod不在同一个节点上，则出现延迟，否则请求正常。也就是说跨节点的访问才有问题。而直接用service对应的podIP访问，也不存在问题，猜测问题可能出在service转pod的过程。
　　再确认基本环境，OS、K8S、calico等基础环境没有发生任何变化，仅仅是把calico的网络模式从BGP改为了vxlan，但是这个改动改变了集群内service及pod的请求路径，也即所有的容器请求需要走节点上新增的calico。vxlan接口封装一下。网络模式修改前没有问题，修改后必现，之后切回BGP模式问题就消失了，说明问题可能跟新增的calico。vxlan接口有关系。
　　先看下环境情况，并触发service请求：验证环境：node2（10。10。72。11）node1（10。10。72。10）验证方法：node2上curlservice：10。96。91。255node1上pod：166。166。166。168：8082〔rootnode2〕ipaddr10：vxlan。calico：BROADCAST，MULTICAST，UP，LOWERUPmtu1410qdiscnoqueuestateUNKNOWNgroupdefaultlinkether66：2d：bf：44：a6：8bbrdff：ff：ff：ff：ff：ffinet166。166。104。1032brd166。166。104。10scopeglobalvxlan。calicovalidlftforeverpreferredlftforever〔rootnode1〕ipaddr15：vxlan。calico：BROADCAST，MULTICAST，UP，LOWERUPmtu1410qdiscnoqueuestateUNKNOWNgroupdefaultlinkether66：f9：37：c3：7e：94brdff：ff：ff：ff：ff：ffinet166。166。166。17532brd166。166。166。175scopeglobalvxlan。calicovalidlftforeverpreferredlftforever〔rootnode2〕timecurlhttp：10。96。91。255
　　在node1的主机网卡上抓包看看封装后的请求是否已到达：〔rootnode1〕tcpdumpnvvieth0host10。10。72。11andudptcpdump：listeningoneth0，linktypeEN10MB（Ethernet），capturesize262144bytes07：19：42。730996IP（tos0x0，ttl64，id6470，offset0，flags〔none〕，protoUDP（17），length110）10。10。72。11。nimvdrshell10。10。72。10。4789：〔badudpcksum0xffff0x3af0！〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl64，id39190，offset0，flags〔DF〕，protoTCP（6），length60）166。166。104。10。35632166。166。166。168。uscli：Flags〔S〕，cksum0xe556（correct），seq3025623348，win29200，options〔mss1460，sackOK，TSval101892130ecr0，nop，wscale7〕，length007：19：43。733741IP（tos0x0，ttl64，id6804，offset0，flags〔none〕，protoUDP（17），length110）10。10。72。11。nimvdrshell10。10。72。10。4789：〔badudpcksum0xffff0x3af0！〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl64，id39191，offset0，flags〔DF〕，protoTCP（6），length60）166。166。104。10。35632166。166。166。168。uscli：Flags〔S〕，cksum0xe16b（correct），seq3025623348，win29200，options〔mss1460，sackOK，TSval101893133ecr0，nop，wscale7〕，length007：19：45。736729IP（tos0x0，ttl64，id7403，offset0，flags〔none〕，protoUDP（17），length110）10。10。72。11。nimvdrshell10。10。72。10。4789：〔badudpcksum0xffff0x3af0！〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl64，id39192，offset0，flags〔DF〕，protoTCP（6），length60）166。166。104。10。35632166。166。166。168。uscli：Flags〔S〕，cksum0xd998（correct），seq3025623348，win29200，options〔mss1460，sackOK，TSval101895136ecr0，nop，wscale7〕，length007：19：49。744801IP（tos0x0，ttl64，id9648，offset0，flags〔none〕，protoUDP（17），length110）10。10。72。11。nimvdrshell10。10。72。10。4789：〔badudpcksum0xffff0x3af0！〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl64，id39193，offset0，flags〔DF〕，protoTCP（6），length60）166。166。104。10。35632166。166。166。168。uscli：Flags〔S〕，cksum0xc9f0（correct），seq3025623348，win29200，options〔mss1460，sackOK，TSval101899144ecr0，nop，wscale7〕，length007：19：57。768735IP（tos0x0，ttl64，id12853，offset0，flags〔none〕，protoUDP（17），length110）10。10。72。11。nimvdrshell10。10。72。10。4789：〔badudpcksum0xffff0x3af0！〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl64，id39194，offset0，flags〔DF〕，protoTCP（6），length60）166。166。104。10。35632166。166。166。168。uscli：Flags〔S〕，cksum0xaa98（correct），seq3025623348，win29200，options〔mss1460，sackOK，TSval101907168ecr0，nop，wscale7〕，length007：20：05。087057IP（tos0x0，ttl64，id8479，offset0，flags〔none〕，protoUDP（17），length164）10。10。72。10。3456510。10。72。11。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id3425，offset0，flags〔DF〕，protoUDP（17），length114）166。166。166。168。57850166。166。104。6。domain：〔udpsumok〕10121AAAA？influxdbnginxservice。kubesystem。svc。kubesystem。svc。cluster。local。（86）07：20：05。087076IP（tos0x0，ttl64，id54475，offset0，flags〔none〕，protoUDP（17），length164）10。10。72。10。5184110。10。72。11。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id3424，offset0，flags〔DF〕，protoUDP（17），length114）166。166。166。168。57984166。166。104。6。domain：〔udpsumok〕20020A？influxdbnginxservice。kubesystem。svc。kubesystem。svc。cluster。local。（86）07：20：05。087671IP（tos0x0，ttl64，id13540，offset0，flags〔none〕，protoUDP（17），length257）10。10。72。11。6039510。10。72。10。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id19190，offset0，flags〔DF〕，protoUDP（17），length207）166。166。104。6。domain166。166。166。168。57850：〔udpsumok〕10121NXDomainq：AAAA？influxdbnginxservice。kubesystem。svc。kubesystem。svc。cluster。local。010ns：cluster。local。SOAns。dns。cluster。local。hostmaster。cluster。local。164763321872001800864005（179）07：20：05。087702IP（tos0x0，ttl64，id13541，offset0，flags〔none〕，protoUDP（17），length257）10。10。72。11。4857110。10。72。10。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id19191，offset0，flags〔DF〕，protoUDP（17），length207）166。166。104。6。domain166。166。166。168。57984：〔udpsumok〕20020NXDomainq：A？influxdbnginxservice。kubesystem。svc。kubesystem。svc。cluster。local。010ns：cluster。local。SOAns。dns。cluster。local。hostmaster。cluster。local。164763321872001800864005（179）07：20：05。088801IP（tos0x0，ttl64，id8480，offset0，flags〔none〕，protoUDP（17），length152）10。10。72。10。5578010。10。72。11。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id3427，offset0，flags〔DF〕，protoUDP（17），length102）166。166。166。168。56015166。166。104。6。domain：〔udpsumok〕19167AAAA？influxdbnginxservice。kubesystem。svc。svc。cluster。local。（74）07：20：05。089048IP（tos0x0，ttl64，id13542，offset0，flags〔none〕，protoUDP（17），length245）10。10。72。11。5015110。10。72。10。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id19192，offset0，flags〔DF〕，protoUDP（17），length195）166。166。104。6。domain166。166。166。168。56015：〔udpsumok〕19167NXDomainq：AAAA？influxdbnginxservice。kubesystem。svc。svc。cluster。local。010ns：cluster。local。SOAns。dns。cluster。local。hostmaster。cluster。local。164763321872001800864005（167）07：20：05。089212IP（tos0x0，ttl64，id8481，offset0，flags〔none〕，protoUDP（17），length148）10。10。72。10。5027210。10。72。11。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id3430，offset0，flags〔DF〕，protoUDP（17），length98）166。166。166。168。54926166。166。104。6。domain：〔udpsumok〕40948A？influxdbnginxservice。kubesystem。svc。cluster。local。（70）07：20：05。089403IP（tos0x0，ttl64，id13543，offset0，flags〔none〕，protoUDP（17），length241）10。10。72。11。5988210。10。72。10。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id19193，offset0，flags〔DF〕，protoUDP（17），length191）166。166。104。6。domain166。166。166。168。54926：〔udpsumok〕40948NXDomainq：A？influxdbnginxservice。kubesystem。svc。cluster。local。010ns：cluster。local。SOAns。dns。cluster。local。hostmaster。cluster。local。164763321872001800864005（163）07：20：05。089524IP（tos0x0，ttl64，id8482，offset0，flags〔none〕，protoUDP（17），length134）10。10。72。10。5896410。10。72。11。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id3431，offset0，flags〔DF〕，protoUDP（17），length84）166。166。166。168。50263166。166。104。6。domain：〔udpsumok〕18815A？influxdbnginxservice。kubesystem。svc。（56）07：20：05。089681IP（tos0x0，ttl64，id13544，offset0，flags〔none〕，protoUDP（17），length134）10。10。72。11。5187410。10。72。10。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id19194，offset0，flags〔DF〕，protoUDP（17），length84）166。166。104。6。domain166。166。166。168。50263：〔udpsumok〕18815ServFailq：A？influxdbnginxservice。kubesystem。svc。000（56）07：20：05。089706IP（tos0x0，ttl64，id8483，offset0，flags〔none〕，protoUDP（17），length134）10。10。72。10。5989110。10。72。11。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id3433，offset0，flags〔DF〕，protoUDP（17），length84）166。166。166。168。49202166。166。104。6。domain：〔udpsumok〕58612AAAA？influxdbnginxservice。kubesystem。svc。（56）07：20：05。089859IP（tos0x0，ttl64，id13545，offset0，flags〔none〕，protoUDP（17），length134）10。10。72。11。4414610。10。72。10。4789：〔nocksum〕VXLAN，flags〔I〕（0x08），vni4096IP（tos0x0，ttl63，id19195，offset0，flags〔DF〕，protoUDP（17），length84）166。166。104。6。domain166。166。166。168。49202：〔udpsumok〕58612ServFailq：AAAA？influxdbnginxservice。kubesystem。svc。000（56）
　　从抓包结果看，出现一个可疑点：前几个报文中提示badudpcksum0xffff，请求通的最后几个报文提示的是nocksum。
　　根据这个错误信息，搜索发现是个已知bug，相关的详细定位可以参考〔1〕〔3〕，这里就不细说了。大概原因如下所述：内核中存在一个和VXLAN处理有关的缺陷，该缺陷会导致ChecksumOffloading不能正确完成。这个缺陷仅仅在很边缘的场景下才会表现出来。
　　在VXLAN的UDP头被NAT过的前提下，如果：
　　VXLAN设备禁用（这是RFC的建议）了UDPChecksum
　　VXLAN设备启用了TxChecksumOffloading
　　就会导致生成错误的UDPChecksum。
　　从资料〔1〕看，K8S的v1。18。5版本已经修复了这个问题，但我的问题是在v1。21。0上发现的，所以不确定只升级K8S是否可以解决该问题，或者升级后还需要额外配置什么？
　　从资料〔3〕和〔4〕看，calico在v3。20。0版本做了修改：在kernelsv5。7时也禁用了calico。vxlan接口的Offloading功能。
　　本地临时禁用并验证：〔rootnode2〕ethtooloffloadvxlan。calicorxofftxoffActualchanges：rxchecksumming：offtxchecksumming：offtxchecksumipgeneric：offtcpsegmentationoffload：offtxtcpsegmentation：off〔requestedon〕txtcpecnsegmentation：off〔requestedon〕txtcp6segmentation：off〔requestedon〕txtcpmangleidsegmentation：off〔requestedon〕udpfragmentationoffload：off〔requestedon〕〔rootnode2〕timecurlhttp：10。96。91。255real0m0。009suser0m0。002ssys0m0。007s
　　请求恢复正常。解决方案临时解决：ethtooloffloadvxlan。calicorxofftxoff永久解决：升级calicov3。20。0或升级内核到5。6。13，5。4。41，4。19。123，4。14。181，单独升级K8Sv1。18。5版本待确认是否能解决参考资料https：blog。gmem。ccnodeport63sdelayduetokernelissuehttps：cloudnative。toblogkubernetes117vxlan63sdelayhttps：bowser1704。github。iopostsvxlanbughttps：github。comprojectcalicocalicoissues3145https：github。comprojectcalicofelixpull2811files