一次网络不通 “争吵” 引发的思考

这篇具有很好参考价值的文章主要介绍了一次网络不通 “争吵” 引发的思考。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

为啥争吵,吵什么?

"你到底在说什么啊,我 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

到了这里,关于一次网络不通 “争吵” 引发的思考的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • ChatGPT引发的人机交互发展历程与升级思考

    ChatGPT自从去年12月火爆以来一直热度不减,最近正好研读了科技之巅,书中详细阐述了人机交互、人工智能、算力算法等技术的发展历史,本文主要围绕ChatGPT引发的人机交互方面的思考。 在讨论人机交互之前,首先需要说明的一点,目前计算机发展的结果已经从原来作为科

    2023年04月24日
    浏览(54)
  • 一个vuepress配置问题,引发的js递归算法思考

    这两天在尝试用语雀+ vuepress + github 搭建个人博客。 小破站地址 :王天的 web 进阶之路 语雀作为编辑器,发布文档推送 github,再自动打包部署,大概流程如下。 我使用的 elog 插件批量导出语雀文档。 elog 采用的配置是所有文章平铺导出,没有按照语雀知识库目录生成 m

    2024年02月08日
    浏览(42)
  • 周星驰进军web3引发怎样的思考?

    谁能想到,向来低调的 周星驰 首次注册社交账号,竟是为了发布一条招人信息,挑选的还不是新片男女主角,而是Web3人才,一脚跨界到了互联网科技领域。 从年初就开始爆火的概念——Web3,到底是什么?能给我们带来什么?周星驰可能会往哪个方向创业? 要理解Web3,可能

    2023年04月08日
    浏览(46)
  • 由黑塞(Hessian)矩阵引发的关于正定矩阵的思考

    最近看论文,发现论文中有通过黑塞(Hessian)矩阵提高电驱系统稳定性的应用。所以本篇主要从Hessian矩阵的性质出发,对其中正定矩阵的判定所引发的想法进行记录。 (其实看论文出现黑塞很惊奇,因为前不久刚读了作家黑塞的《德米安:彷徨少年时》,所以在这一领域的黑塞

    2024年02月06日
    浏览(50)
  • 这问题巧了,SpringMVC 不同参数处理机制引发的思考

    这个问题非常有趣,不是SpringMVC 的问题,是实际开发中混合使用了两种请求方式暴露出来的。 功能模块中,提供两个 Http 服务。一个是列表查询(application/json 请求),一个是列表导出(表单请求)。运行环境发现个问题:MVC model 新添加的属性,类似的 Http 请求,一个有值

    2024年02月11日
    浏览(43)
  • 由面试题“Redis是否为单线程”引发的思考

    博主 默语带您 Go to New World. ✍ 个人主页—— 默语 的博客👦🏻 《java 面试题大全》 《java 专栏》 🍩惟余辈才疏学浅,临摹之作或有不妥之处,还请读者海涵指正。☕🍭 《MYSQL从入门到精通》数据库是开发者必会基础之一~ 🪁 吾期望此文有资助于尔,即使粗浅难及深广,亦

    2024年04月16日
    浏览(37)
  • 由 Array.includes 函数引发对引用数据类型的思考

    `` 数组的includes方法在日常的编程中比较常用到,其作用就是判断某一数据是否在数组中,通常来说,数组中的数据如果是数字,布尔值,或者字符串的话,都是能够进行判断的 例如: 如果是对象的话,那么会有一个有趣的现象发生 arr.includes({ age: 11, name: \\\'bob\\\'}) 这行,inclu

    2024年02月09日
    浏览(62)
  • 编程示例:概率论的问题——囚犯生存概率引发的循环思考

    适用于无编程经验的初学者,目的是提供一个编程的思路。 有一个囚犯,国王打算处决他,但仁慈的国王给了他一个生还的机会。 现在摆在他面前有两个瓶子,一个里面装了50个白球,一个装了50个 黑球,这个囚犯有一个机会可以随便怎样重新分配这些球到两个瓶子 中(当

    2024年02月03日
    浏览(50)
  • 由select for update锁等待问题引发的深入思考

    关于 MySQL 的加锁机制,其实十分复杂,不同的隔离级别,是否是主键或索引,锁的粒度等等。很多工作了很多年的 MySQL DBA 也不能把各种加锁场景一一讲清楚。有时候一个简单的锁等待场景都值得深入研究,大家更多的是知其然而不知其所以然。本文介绍的是一个很常见的锁

    2024年03月09日
    浏览(38)
  • Unity由“鼠标点不准物体”引发的Camera的相关思考

            前段一个同事在使用Unity开发时遇到一个奇怪的问题,使用左键点击发射射线的方式选择物体,总是选不准,尤其是小的物体,鼠标点击到物体上,有时能选上,有时选不上,偶尔点击到物体旁边反而能选上,于是他让我帮看看咋回事。我第一个想法是也许代码写

    2024年02月03日
    浏览(37)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包