pod内部访问svc失败分析

Posted 2023-03-20

参考技术A pod 无法访问svc

环境：
3 mst 2 worker

node 双网卡

node eth0：默认路由在eth0 ，k8s管理网络，node访问svc ，pod经过node访问svc，以及pod回包给node都会经过eth0

pod eth1：pod 访问pod需要经过 eth1的网关

情况描述：

原因：kube-proxy 没有开启masquerade导致的， 不开启pod发出的包经过ipvs就不会被伪装成eth0的ip和mac，而是只替换了mac。由于ipvlan模式下，eth1网卡无法向外转发，所以走了eth0出去，即eth0发出了一个不是自己的ip也不是自己的mac的包，所以会导致出问题。

像macvlan，ipvlan，kube-ovn 多网卡场景的node，eth0是k8s管理网卡（svc依赖）必须开启该模式

对比 启用 masquerade 之后

基于kubespray 更新全伪装之后，旧的lb未生效，所以直接重建了下测试集群

首要问题pod 访问svc 概率性不通的问题：

场景1： 在kube-proxy 不启用全伪装模式的时候， 此时pod 内部访问 curl -k https://kubernetes:443/livez?verbose
小概率可成功响应，大概率失败。 而node上访问完全正常。

当kubernetes有三个后端，那么pod内部的成功率是1/3，而node成功率是100%。

原因： 由于是双网关，且无伪装。 pod访问svc后端的node需要eth0的网关，而回包是直接返回给pod。由于node回包给pod时，网关转发包的混乱，包看起来是随机发送给任何一个node的，所以小概率，pod可以收到包。

小结： 本质上是因为node访问pod，跨网关转发，这个转发是不稳定的。

开启全伪装模式之后， pod内部访问 curl -k https://kubernetes:443/livez?verbose 100%成功， 只是有首包慢的问题，localdns的缓存效果，后续请求就很快

前提： 在kube-proxy 启用全伪装模式的情况下，进行2 自建svc的测试。

一般情况下，pod创建出来，node 能否平通 pod是概率性的，但是pod可以100% ping通node
在pod ping 通node之后的一段时间内，node ping pod 也是100%可通的。 也就是在这段时间内，网关知道pod在哪里，可以准确转发。

情况1： 在node 无法ping通pod的情况下，pod 访问svc的情况是概率性的，和kube-proxy未开启全伪装的表现几乎一样

当自定义svc有两个后端， pod内部访问svc成功率是1/2， 而node成功率为0

原因：

跟踪contrack表发现

pod 内部 ping svc， 没有新的contrack条目创建。也就是就是没基于cluster ip建立连接

node 内部 ping svc，发现有新的contrack条目创建。 但是由于node ping 不同 pod，所以依旧无法访问

情况2： 在 node 可以ping 通 pod的情况下，pod 访问svc 100% 成功

保持pod 对node的ping

此时有两条icmp的记录，svc两个后端pod 保持 对 master1的ping

此时在master1 访问cluster ip 100%成功

等待 node访问的contrack记录消失，再进行 pod访问的测试

测试pod访问自定义svc

始终是1/2的成功率，但是完全没有新的contrack记录。 pod访问svc 应该没走kube-proxy。

解决方式： 移除eth1的网卡上的ip，该情况完全消失。 pod 内部访问100%成功，node访问会产生新的contrack

如果自定义 svc 只有一个pod，pod 访问 svc 始终都是成功的

可以看到eth1网卡发起的arp广播。
由于eth1作为master，是无法通往外部以及本地pod的

也就是说这张网卡，完全没有联通的功能，但是仍然会触发arp的更新。

解决方式：该网卡的ip以及路由需要移除掉，达到禁用该网卡的目的

禁用网卡时，可以看到eth1相关的arp记录全部清除

执行ip addr flush dev eth1 时，eth1的arp记录全部清除
pod 内部 访问多pod 后端的svc 也100%回复正常

参考：ipvs https://blog.dianduidian.com/post/lvs-snat%E5%8E%9F%E7%90%86%E5%88%86%E6%9E%90/