一次网络不通“争吵”引发的思考-低调大师

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

2023-08-16 325

为啥争吵，吵什么？

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

相关链接：

[1] 客户端无法访问负载均衡CLB

https://help.aliyun.com/document_detail/55206.htm

[2] 通过Annotation配置传统型负载均衡CLB

https://www.yuque.com/r/goto?url=https%3A%2F%2Fhelp.aliyun.com%2Fzh%2Fack%2Fack-managed-and-ack-dedicated%2Fuser-guide%2Fadd-annotations-to-the-yaml-file-of-a-service-to-configure-clb-instances

[3] service-traffic-policy

https://kubernetes.io/zh-cn/docs/concepts/services-networking/service-traffic-policy/

[4] 社区PR

https://github.com/kubernetes/kubernetes/pull/97081/commits/61085a75899a820b5eebfa71801e17423c1ca4da

作者：郑明泉、余凯

点击立即免费试用云产品开启云上实践之旅！

原文链接

本文为阿里云原创内容，未经允许不得转载

微信关注我们

原文链接：https://my.oschina.net/yunqi/blog/10096664

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

电商订单履约-卖家发货演化史

1 背景订单的履约之路就是从发货开始，看似简单的发货功能，其背后却藏着许多的小秘密。发货的业务特点： B端业务，性能要求不高，因为存在批量发货的场景。发货时间比较分散，所以并发量不大。业务复杂，涉及到N种订单类型的发货，不同的订单类型有着不同的业务规则。随着公司业务的发展，订单类型的增多，没有进行抽象的发货逻辑随着迭代的推进难免会显得落后。当然，在迭代的过程中，也一直在优化，一直在演进，正所谓没有最好，只有符合当前业务现状的最合理。 2 一阶段卖家发货卖家发货在一开始的时候，有N个接口。比如，现货单个发货，现货批量发货，现货极速发货，App发货，直发发货，定制发货等。有这么多发货接口也是我们平台的业务特性决定的，现货就是卖家发货到平台，直发就是卖家发货到买家，不同的业务有不同的流程。除了接口多这个问题，另一个问题是逻辑分散，每个接口都是独立的逻辑，大量重复代码的出现极大地增加了维护的成本。比较简化的发货流程如下：参数校验一些业务校验，比如订单状态，发货冷静期等核销卖家优惠推状态机订单数据修改保存广播发货消息下发入库单订阅物流轨迹 …… 在整个流程里面，存...

2023-08-16

403

目录一、前言二、元数据简介 1、元数据定义 2、元数据分类 3、数据库元数据管理三、GaussDB数据库的元数据管理 1、GaussDB数据库的元数据管理 2、通过“SQL + 系统表/系统视图/系统函数”的方式管理（采集）元数据 1）获取表、视图及表字段等信息 2）获取定时任务信息 3）获取索引信息 4）获取存储过程、函数、触发器等信息四、小结一、前言 GaussDB是一种分布式的关系型数据库，元数据（表、列、视图、索引、存储过程等对象）是其重要的一部分。元数据是指描述数据的数据，包括数据的定义、结构、属性、关系等信息。本文以GaussDB物理数据库为主，结合元数据的概念简单介绍一下相关内容。二、元数据简介 1、元数据定义按照传统的定义，元数据（Metadata）是描述数据的数据。元数据主要记录数据库应用系统中模型的定义、各层级间的映射关系、监控数据库应用系统的数据状态及ETL的任务运行状态等。在数据库应用系统中，元数据可以帮助数据库管理员和开发人员非常方便地找到其所关心的数据，并用于指导其进行数据管理和开发工作，提高工作效率。 2、元数据分类元数据可根据不同的维度进...

2023-08-16

788

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。