一次容器网络不通"争吵"引发的思考-阿里云开发者社区

一次容器网络不通"争吵"引发的思考

2023-08-16 186

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

公网NAT网关，每月750个小时 15CU

应用型负载均衡 ALB，每月750个小时 15LCU

传统型负载均衡 CLB，每月750个小时 15LCU

简介： 为啥争吵，吵什么？"你到底在说什么啊，我k8s的ecs节点要访问clb的地址不通和本地网卡有什么关系..." 气愤语气都从电话那头传了过来，这时电话两端都沉默了。过了好一会传来地铁小姐姐甜美的播报声打断了刚刚的沉寂「乘坐地铁必须全程佩戴口罩，下一站西湖文化广场...」。pod需要访问clb的443的监听，但是如果是集群内（集群内后面都指的k8s的节点或者POD）访问就会出现如

为啥争吵，吵什么？

"你到底在说什么啊，我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 使用这个注解 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname，进行占位，这样就不会绑定CLB的IP到kube-ipvs0的网卡上，集群内访问CLB的IP就会出集群访问CLB，但是需要注意如果监听协议为TCP或UDP，集群内访问CLB IP时将会存在回环访问问题。详细信息，请参见客户端无法访问负载均衡CLB。

需要CCM版本在 v2.3.0及以上版本才支持这个注解，具体参考：通过Annotation配置传统型负载均衡CLB

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

具体到阿里云容器在不同网络CNI情况下的数据链路，可以参考下面的文章系列一：全景剖析阿里云容器网络数据链路（一）—— Flannel

系列二：全景剖析阿里云容器网络数据链路（二）—— Terway ENI

系列三：全景剖析阿里云容器网络数据链路（三）—— Terway ENIIP

系列四：全景剖析阿里云容器网络数据链路（四）—— Terway IPVLAN+EBPF

系列五：全景剖析阿里云容器网络数据链路（五）—— Terway ENI-Trunking

系列六：全景剖析阿里云容器网络数据链路（六）—— ASM Istio

此处我们只讨论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 。

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四层建连可以成功。