为啥争吵,吵什么?
"你到底在说什么啊,我 K8s 的 ecs 节点要访问 clb 的地址不通和本地网卡有什么关系..." 气愤语气都从电话那头传了过来,这时电话两端都沉默了。过了好一会传来地铁小姐姐甜美的播报声打断了刚刚的沉寂「乘坐地铁必须全程佩戴口罩,下一站西湖文化广场...」。
pod 需要访问 clb 的 443 的监听, 但是如果是集群内(集群内后面都指的 K8s 的节点或者 POD)访问就会出现如下报错 Connection refused:
所以就捋了一下客户链路如下:
具体现象是什么
无论是节点 node 还是 pod 里访问 192.168.1.200:443 都是不通的,但是访问 192.168.1.200:80 却是正常的。同时集群外的 ECS192.168.3.100 访问 192.168.1.200:443 和 192.168.1.200:80 都是正常的。
进一步分析看看
CLB1 的 IP192.168.1.200 被绑定到了 K8s 的 node 节点的 kube-ipvs0 网卡上,这个是一张 dummy 网卡,参考 dummy interface。由于 SVC1 是 LoadBalancer 类型的,同时复用了这个 CLB1,关联 endpoint 是 POD1192.168.1.101:80,那么就可以解释为何访问 192.168.1.200:80 是正常,是由于 kube-proxy 根据 SVC1 的配置创建 ipvs 规则同时挂载了可被访问的后端服务。而集群里访问 192.168.1.200:443 都是不通的,因为 IP 被绑定到 dummy 网卡后,就不会再出节点去访问到 CLB1,同时没有 443 对应 ipvs 规则,所以直接是拒绝的。
这个时候如果节点里没有 ipvs 规则(ipvs 优先于监听)但是又能访问通的话, 可以检查一下是否本地有监听 0.0.0.0:443 的服务,那么这个时候所有网卡 IP+443 都能通,但是访问的是本地服务,而不是真正的 CLB 后端的服务。
是否有办法解决呢
最建议的方式
最好的方式拆分, 集群内和集群外的服务分开两个 CLB 使用。
阿里云 svc 注解的方式
SVC1 使用这个注解 http://service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname,进行占位,这样就不会绑定 CLB 的 IP 到 kube-ipvs0 的网卡上,集群内访问 CLB 的 IP 就会出集群访问 CLB,但是需要注意如果监听协议为 TCP 或 UDP,集群内访问 CLB IP 时将会存在回环访问问题。详细信息,请参见客户端无法访问负载均衡 CLB[1]。
需要 CCM 版本在 v2.3.0 及以上版本才支持这个注解, 具体参考:通过 Annotation 配置传统型负载均衡 CLB [2]
demo:
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname: "${your_service_hostname}"
name: nginx-svc
namespace: default
spec:
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
type: LoadBalancer
集群内访问 ExternalTrafficPolicy 策略有影响吗?
我们都知道 K8s 的 nodeport 和 loadbalancer 模式是可以调整外部流量策略的,那么图中的「外部策略为 Local/Cluster,所有集群节点创建 IPVS 规则是有区别的」该如何解释呢, 以及集群内访问 nodePort/CLBIP 的时候会发生什么。
以下都是针对 svc 的 internalTrafficPolicy 都是 Cluster 或者缺省的情况,这个 ServiceInternalTrafficPolicy 特性在 1.22 的 K8s 中默认开启,具体参考 service-traffic-policy [3]
此处我们只讨论 ipvs TrafficPolicy Local 在 Kubernetes 从 1.22 升级到 1.24 的行为变化。
Kubernetes 1.24 IPVS 的变化
以下均以 kube-proxy 的 IPVS 模式为例:
- 当 externalTrafficPolicy 为 Cluster 模式或缺省的时候,ipvs 规则里的 nodePort/CLBIP 后端会挂载所有的 Endpoint 的 IP,这时候集群内访问会丢失源 IP,因为节点会做一层 SNAT。
- 当 externalTrafficPolicy 是 Local 的时候
- 当节点上有对应 service 的 Endpoint 的时候,ipvs 规则里的 nodePort/CLBIP 后端只挂载自己节点的 Endpoint 的 IP,集群内访问会保留源 IP。
- 当节点上没有对应 service 的 Endpoint 的时候
- 在 1.24 之前的版本是会挂空的后端的,集群内访问会拒绝。
- 在 1.24 之后的 K8s 集群里,当节点上没有对应 service 的 Endpoint 的时候,ipvs 规则里的 nodePort/CLB IP 后端会挂载所有的 Endpoint 的 IP,这时候集群内访问会丢失源 IP,因为节点会做一层 SNAT。社区调整了 Local 策略后端服务的规则挂载策略,具体参考社区 PR[4]。
https://github.com/kubernetes/kubernetes/pull/97081/commits/61085a75899a820b5eebfa71801e17423c1ca4da
集群外访问 SLB
集群外访问 SLB 的话,CCM 只会挂载 Local 类型的节点,情况跟 1.24 kubernetes 前一样,这里不做过多阐述,请见上面连接。
集群外访问 NodePort
1.24 Kubernetes 之前版本
- 访问有 Endpoint 的节点的 NodePort,可以通,可以保留源 IP
Nginx 分布在 cn-hongkong.10.0.4.174 和 cn-hongkong.10.0.2.84 节点。
从外部 10.0.3.72 节点访问有后端 pod 所在节点的 cn-hongkong.10.0.2.84 的 30479 端口,可以访问。
cn-hongkong.10.0.0.140 节点上是有相关的 IPVS 的规则的,但是只有该节点上后端 Pod IP。
通过 conntrack 表可以到,这是由于在 cn-hongkong.10.0.0.140 节点上,相关的链路被 dnat,最后是由 pod cn-hongkong.10.0.2.84 节点上的 的 nginx-7d6877d777-tzbf7 10.0.2.87 返回源,所有的相关转化都在该节点上,所以 TCP 四层建连可以成功。
- 访问没有 Endpoint 的节点的 NodePort,不能通,因为节点上没有相关的 ipvs 转发规则
从外部 10.0.3.72 节点访问无后端 pod 所在节点的 cn-hongkong.10.0.0.140 的 30479 端口,不可以访问。
查看该 cn-hongkong.10.0.0.140 节点,并没有相关的 ipvs 转发规则,所以无法进行 dnat,访问会失败。
1.24 Kubernetes 版本之后(含)
访问有 Endpoint 节点的 NodePort,可以通,可以保留源 IP
访问没有 Endpoint 节点的 NodePort:
- terway ENIIP or host 网络:不通
Nginx 分布在 cn-hongkong.10.0.2.77 和 cn-hongkong.10.0.0.171 节点。
从外部 10.0.3.72 节点访问无后端 pod 所在节点的 cn-hongkong.10.0.5.168 的 30745 端口,可以看到,访问失败。
cn-hongkong.10.0.5.168 节点上是有相关的 IPVS 的规则的,并且会把所有的后端 Pod IP 加到 IPVS 规则中。
通过 conntrack 表可以到,这是由于在 cn-hongkong.10.0.5.168 节点上,相关的链路被 dnat,最后是由 pod cn-hongkong.10.0.2.77 节点上的 nginx-79fc6bc6d-8vctc 10.0.2.78 返回源,源在接受这个链路后,会发现和自己的五元组不匹配,直接丢弃,三次握手必然失败,所以建连失败。
- flannel 网络:可以通,但是保留不了源 IP
Nginx 分布在 cn-hongkong.10.0.2.86。
从外部访问 cn-hongkong.10.0.4.176 的 31218 端口,可以访问成功。
cn-hongkong.10.0.4.176 记录了 src 是 10.0.3.72,并做了 dnat 为 172.16.160.135,期望它返回给 10.0.4.176 的 58825 端口。
后端 ep 所在节点 cn-hongkong.10.0.2.86,conntrack 表记录了 src 是 10.0.4.176,sport 是 58825。所以可以看到应用 pod 是记录的源 IP 是 10.0.4.176,丢失了源 IP。
集群内访问 SLB 或者 NodePort
1.24 Kubernetes 之前版本
- 有 Endpoint 的节点上访问,可以通,可以保留源 IP
Nginx 分布在 ap-southeast-1.192.168.100.209 和 ap-southeast-1.192.168.100.208 节点,ap-southeast-1.192.168.100.210 节点没有 Nginx pod。
从集群任意节点(本例就在 209 节点)访问有后端 pod 所在节点的 ap-southeast-1.192.168.100.209 的 NodePort 31565 端口,可以访问。
从有后端 pod 所在节点 ap-southeast-1.192.168.100.209 访问 SLB 8.222.252.252 的 80 端口,可以访问。
ap-southeast-1.192.168.100.209 节点上是有 NodePort 和 SLB 的 IPVS 的规则的,但是只有该节点上后端 Pod IP。
通过 conntrack 表可以到,这是由于在 ap-southeast-1.192.168.100.209 节点上,相关的链路被 dnat,最后是由 pod 在 ap-southeast-1.192.168.100.209 节点上的 的 nginx-7d6877d777-2wh4s 192.168.100.222 返回源,所有的相关转化都在该节点上,所以 TCP 四层建连可以成功。
- 没有 Endpoint 的节点上访问,不能通,因为节点上没有相关的 ipvs 转发规则
从集群任意节点(本例就在 210 节点)访问没有后端 pod 所在节点的 ap-southeast-1.192.168.100.210 的 NodePort 31565 端口或者 SLB,不可以访问。
也进一步证实,集群内访问关联 svc 的 SLB 不出节点,即使 SLB 有其他监听端口,访问 SLB 其他端口也会拒绝。
查看该 ap-southeast-1.192.168.100.210 节点,并没有相关的 ipvs 转发规则,所以无法进行 dnat,访问会失败。
1.24 Kubernetes 版本之后(含)
- 有 Endpoint 节点上访问,可以通,可以保留源 IP
与上文的 1.24 Kubernetes 之前版本集群内访问一致,可以参考上文描述。
- 没有 Endpoint 节点上访问:
Nginx 分布在 cn-hongkong.10.0.2.77 和 cn-hongkong.10.0.0.171 节点,所以在没有 Nginx 的 cn-hongkong.10.0.4.141 节点上测试。
分别有以下几种情况:
- terway 或后端为 hostNetwork
- 节点访问的通 NodePort(源 IP 是 ECS IP,不需要做 SNAT),无法保留源 IP
可以看到没有 Endpoint 的节点的 NodePort 110.0.4.141:30745 的 IPVS 的规则添加的 Nginx 的所有后端 POD nginx-79fc6bc6d-8vctc 10.0.2.78 和 nginx-79fc6bc6d-j587w 10.0.0.172。
集群内节点自身访问没有后端 pod 所在节点的 cn-hongkong.10.0.4.141 的 NodePort 30745/TCP 端口,可以访问。
通过 conntrack 表可以到,在 cn-hongkong.10.0.4.141 节点上,相关的链路被 dnat,最后是由后盾 Nginx pod nginx-79fc6bc6d-8vctc 10.0.2.78 返回源。
而在 nginx-79fc6bc6d-8vctc 10.0.2.78 所在的节点 cn-hongkong.10.0.2.77 上的 conntrack 表记录的是 10.04.141 访问 10.0.2.78,并期望 10.0.2.78 直接返回 10.0.4.141 的的 39530 端口。
集群内有 endpoint 节点访问没有后端 pod 所在节点的 ap-southeast-1.192.168.100.131 的 NodePort 32292 端口,不可以访问,与上文 1.24 Kubernetes 版本之后(含) 集群外访问一致,可以参考上文描述。
-
- 节点访问不通 SLB IP(源 IP 是 SLB IP,没有人做 SNAT)
可以看到没有 Endpoint 的节点的 SLB IP 的 IPVS 的规则添加的 Nginx 的所有后端 POD nginx-79fc6bc6d-8vctc 10.0.2.78 和 nginx-79fc6bc6d-j587w 10.0.0.172。
没有 Endpoint 的节点上访问 SLB 47.243.247.219,访问确是超时。
通过 conntrack 表可以到,在没有 ep 的节点访问 SLB 的 IP,可以看到期望的是后端 pod 返回给 SLB IP。而 SLB IP 在节点上已经被 kube-ipvs 虚拟占位了,所以没有做 snat,造成无法访问。
- flannel 并且后端为普通 pod,可以访问通,但是保留不了源 IP
Nginx 分布在 cn-hongkong.10.0.2.86。
在 cn-hongkong.10.0.4.176 访问 SLB 47.242.86.39 是可以访问成功的。
cn-hongkong.10.0.4.176 节点的 conntrack 表可以看到是 src 和 dst 都是 47.242.86.39,但是期望的是 nginx pod172.16.160.135 返回给 10.0.4.176 的 54988 端口,47.242.86.39 snat 成 10.0.4.176。
后端 ep 所在节点 cn-hongkong.10.0.2.86,conntrack 表记录了 src 是 10.0.4.176,sport 是 54988。所以可以看到应用 pod 是记录的源 IP 是 10.0.4.176,丢失了源 IP。文章来源:https://www.toymoban.com/news/detail-653614.html
文章来源地址https://www.toymoban.com/news/detail-653614.html
到了这里,关于一次网络不通 “争吵” 引发的思考的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!