k8s的svc流量通过iptables和ipvs转发到pod的流程解析

2024-02-24 16:20
文章标签 云原生 流程 转发 解析 k8s 流量 iptables pod svc ipvs

本文主要是介绍k8s的svc流量通过iptables和ipvs转发到pod的流程解析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

  • 1. k8s的svc流量转发
    • 1.1 service 说明
    • 1.2 endpoints说明
    • 1.3 pod 说明
    • 1.4 svc流量转发的主要工作
  • 2. iptables规则解析
    • 2.1 svc涉及的iptables链流程说明
    • 2.2 svc涉及的iptables规则实例
      • 2.2.1 KUBE-SERVICES规则链
      • 2.2.2 KUBE-SVC-EFPSQH5654KMWHJ5规则链
      • 2.2.3 KUBE-SEP-LCXGRT47CYQENZGP规则链
      • 2.2.4 KUBE-FW-EFPSQH5654KMWHJ5规则链
      • 2.2.5 KUBE-XLB-EFPSQH5654KMWHJ5规则链
      • 2.2.6 KUBE-XLB-EFPSQH5654KMWHJ5规则链
    • 2.3 iptables转发链路总结
  • 3. ipvs规则解析
    • 3.1 ipvs工作原理
    • 3.2 ipvs支持的负载均衡算法
    • 3.3 svc涉及的ipvs链流程说明
  • 4. 疑问和思考
    • 4.1 KUBE-MARK-MASQ规则说明
    • 4.2 KUBE-MARK-DROP规则说明
    • 4.3 使用iptables规则有什么问题？
    • 4.4 iptables和ipvs两者的优劣势如何？
  • 5. 参考文档

在常用的k8s环境中，通常会通过iptables将流量进行负载均衡、snat、dnat等操作，从而流量转发到pod或者外部的服务。本文重点介绍iptables是如何进行流量转发的以及相关转发的iptables和ipvs解析。

1. k8s的svc流量转发

1.1 service 说明

service只是一个抽象概念，在逻辑上将一组pod（功能相同）给抽象出来一个统一入口。可以将他简单理解为做了一个服务的负载均衡。我们知道pod在重新部署之后ip会改变，所以一般会通过service来访问pod。core-dns会给service分配一个内部的虚拟ip（节点上根本查询不到这个ip，ping是不通的，具体是怎么访问到的继续往下看），因此内部服务可以通过这个ip或者是serviceName来访问到pod的服务。

service提供的常用type：

  • ClusterIP，也是默认方式。Service会分配一个集群内部的固定虚拟IP，实现集群内通过该IP来对POD进行访问。这个又有两类，上面说到的最普通的Service，ClusterIP还有一种是Headless Service，这种形式不会分配IP也不会通过kube-proxy做反向代理或者负载均衡，而是通过DNS提供稳定的网络ID来访问，DNS会将headless service的后端直接解析为POD的IP列表，这种主要是共StatefulSet类型使用。
  • NodePort，这种类型的Service是除了使用ClusterIP的功能外还会映射一个宿主机随机端口到service上，这样集群外部可以通过宿主机IP+随机端口来访问。这样得保证每一个node节点的该端口都可用才行，直接使用任意node节点的ip+端口就能直接访问pod。
  • HostPort，他这个和nodeport的区别是，只在某一个node节点打开端口。
    LoadBalancer：和nodePort类似，不过除了使用ClusterIP和NodePort之外还会向使用的公有云申请一个负载均衡器，从而实现集群外部通过LB来访问服务。这个主要是依托云lb。
  • ExternalName：是Service的一种特例，此模式主要面对运行在集群外部的服务，通过它可以将外部服务映射到k8s集群，具备k8s内服务的一些特性，来为集群内部提供服务
apiVersion: v1
kind: Service
metadata:namespace: appname: eureka-serverlabels:name: eureka-server
spec:type: NodePort ##这个位置来指定service的类型selector:app: eureka-serverports:- port: 80targetPort: 9101nodePort: 31101

1.2 endpoints说明

endpoints也是k8s的一个资源，我们在创建service的时候如果我们设置了selector选中了需要关联的pod，那么就会创建一个与service同名的endpoints。他是用来记录service对应pod的访问地址。

[root@aliyun168-37 nginx]# kubectl get endpoints nginx-svc -n test
NAME        ENDPOINTS                                         AGE
nginx-svc   10.244.4.139:80,10.244.4.140:80,10.244.4.141:80   18m

1.3 pod 说明

Kubernetes（简称K8s）中的Pod是最小的可部署单元，它是一组相关容器的集合。一个Pod可以包含一个或多个容器，这些容器共享相同的资源（如网络和存储）。Pod提供了一种逻辑上独立的环境，使得应用可以在自己的虚拟空间中运行。

Service、Endpoint 和 Pod 的关系（下图）
在这里插入图片描述

1.4 svc流量转发的主要工作

Kubernetes服务（svc）能够感知Pod的变化是通过kube-proxy实现的，kube-proxy会监视Kubernetes API中的服务和端点对象，并根据Pod的变化来更新服务的endpoint信息，并进行流量转发。

总的说来，k8s的流量从svc转发到pod，一般来说需要做2个事情

  • 流量负载均衡
  • 包过滤，并针对来源ip、目的ip进行nat转换

如上2个功能需求，

  • 通过iptables规则都能够实现，并且iptables规则主要集中在流量负载均衡上
  • ipvs只能实现负载均衡部分，包过滤和nat转换需要iptables规则来实现，但是相关的iptables规则数量很少

2. iptables规则解析

集群内调用service，通常采用如下方式

  • 集群内POD调用service，通常是使用Cluster IP。
  • 集群内发起调用，通过cluster ip访问到service。
  • 集群外发起调用，通过nodeport访问到service。

整体的转发流程图如下
在这里插入图片描述
node节点的iptables是由kube-proxy生成的，kube-proxy只修改了filter和nat表，它对iptables的链进行了扩充，自定义了KUBE-SERVICES，KUBE-NODEPORTS，KUBE-POSTROUTING，KUBE-MARK-MASQ和KUBE-MARK-DROP五个链，并主要通过为 KUBE-SERVICES链（附着在PREROUTING和OUTPUT）增加rule来配制traffic routing 规则

2.1 svc涉及的iptables链流程说明

svc涉及的iptables链路过程中的相关流程情况流程图如下
destination:172.30.5.207
destination:172.30.5.207
destination:172.30.5.207
destination:
destination:
loadbalancer的IP在节点上截获后转给service
内部流量/PREROUTING
KUBE-SERVICES
外部流量/OUTPUT
KUBE-MARK-MASQ
KUBE-SVC-M42ZCW2EYUCRBVAF
KUBE-SEP-EA7TYKWK2S6G4PQR
KUBE-SEP-ZJI36FVTROQF5MX7
KUBE-FW-M42ZCW2EYUCRBVAF
KUBE-XLB-M42ZCW2EYUCRBVAF
KUBE-SVC-M42ZCW2EYUCRBVAF

2.2 svc涉及的iptables规则实例

我们将针对一个iptables规则进行解析。

# 获取svc的
kubectl get svc -nkube-system -owide |grep kubernetes-lb kube-system                                kubernetes-lb                                                     LoadBalancer   192.168.11.23    172.29.163.9            6443:31714/TCP                                                                                                                                                                                                            2y47d   cluster.infra.tce.io/component=kube-apiserver,component=kube-apiserver

# 获取svc后段的pod
kubectl get pods -n kube-system -owide |grep kube-apiserverkube-system                                kube-apiserver-172.33.0.11                                          1/1     Running                      7          247d    172.33.0.11      172.33.0.11    <none>           <none>
kube-system                                kube-apiserver-172.33.0.25                                          1/1     Running                      1          247d    172.33.0.25      172.33.0.25    <none>           <none>
kube-system                                kube-apiserver-172.33.0.30                                          1/1     Running                      0          247d    172.33.0.30      172.33.0.30    <none>           <none>

#  获取对应iptables情况
iptables-save |egrep "kubernetes-lb|KUBE-XLB-EFPSQH5654KMWHJ5|KUBE-SEP-LCXGRT47CYQENZGP|KUBE-SVC-EFPSQH5654KMWHJ5|KUBE-SEP-KJQQYC6E4EGY4UJE|KUBE-SEP-4DJFF4PKJG2GTZWW":KUBE-SEP-4DJFF4PKJG2GTZWW - [0:0]
:KUBE-SEP-KJQQYC6E4EGY4UJE - [0:0]
:KUBE-SEP-LCXGRT47CYQENZGP - [0:0]
:KUBE-SVC-EFPSQH5654KMWHJ5 - [0:0]
:KUBE-XLB-EFPSQH5654KMWHJ5 - [0:0]
-A KUBE-FW-EFPSQH5654KMWHJ5 -m comment --comment "kube-system/kubernetes-lb: loadbalancer IP" -j KUBE-XLB-EFPSQH5654KMWHJ5
-A KUBE-FW-EFPSQH5654KMWHJ5 -m comment --comment "kube-system/kubernetes-lb: loadbalancer IP" -j KUBE-MARK-DROP
-A KUBE-NODEPORTS -s 127.0.0.0/8 -p tcp -m comment --comment "kube-system/kubernetes-lb:" -m tcp --dport 31714 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-system/kubernetes-lb:" -m tcp --dport 31714 -j KUBE-XLB-EFPSQH5654KMWHJ5
-A KUBE-SEP-4DJFF4PKJG2GTZWW -s 172.33.0.30/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-4DJFF4PKJG2GTZWW -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent
-A KUBE-SEP-KJQQYC6E4EGY4UJE -s 172.33.0.25/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-KJQQYC6E4EGY4UJE -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent
-A KUBE-SEP-LCXGRT47CYQENZGP -s 172.33.0.11/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-LCXGRT47CYQENZGP -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent
-A KUBE-SERVICES ! -s 172.16.21.0/24 -d 192.168.11.23/32 -p tcp -m comment --comment "kube-system/kubernetes-lb: cluster IP" -m tcp --dport 6443 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 192.168.11.23/32 -p tcp -m comment --comment "kube-system/kubernetes-lb: cluster IP" -m tcp --dport 6443 -j KUBE-SVC-EFPSQH5654KMWHJ5
-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-LCXGRT47CYQENZGP
-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-KJQQYC6E4EGY4UJE
-A KUBE-SVC-EFPSQH5654KMWHJ5 -j KUBE-SEP-4DJFF4PKJG2GTZWW
-A KUBE-XLB-EFPSQH5654KMWHJ5 -s 172.16.21.0/24 -m comment --comment "Redirect pods trying to reach external loadbalancer VIP to clusterIP" -j KUBE-SVC-EFPSQH5654KMWHJ5
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "masquerade LOCAL traffic for kube-system/kubernetes-lb: LB IP" -m addrtype --src-type LOCAL -j KUBE-MARK-MASQ
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "route LOCAL traffic for kube-system/kubernetes-lb: LB IP to service chain" -m addrtype --src-type LOCAL -j KUBE-SVC-EFPSQH5654KMWHJ5
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "Balancing rule 0 for kube-system/kubernetes-lb:" -j KUBE-SEP-LCXGRT47CYQENZGP

2.2.1 KUBE-SERVICES规则链

# 将访问svc的流量访问打标记，后续流量进出节点时进行NAT转换
-A KUBE-SERVICES ! -s 172.16.21.0/24 -d 192.168.11.23/32 -p tcp -m comment --comment "kube-system/kubernetes-lb: cluster IP" -m tcp --dport 6443 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 192.168.11.23/32 -p tcp -m comment --comment "kube-system/kubernetes-lb: cluster IP" -m tcp --dport 6443 -j KUBE-SVC-EFPSQH5654KMWHJ5

访问192.168.11.23/32:6443的流量跳转到KUBE-SVC-EFPSQH5654KMWHJ5链路进行处理。

2.2.2 KUBE-SVC-EFPSQH5654KMWHJ5规则链

-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-LCXGRT47CYQENZGP
-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-KJQQYC6E4EGY4UJE
-A KUBE-SVC-EFPSQH5654KMWHJ5 -j KUBE-SEP-4DJFF4PKJG2GTZWW

将流量进行负载均衡，给各个规则连分配权重

规则链权重
KUBE-SEP-LCXGRT47CYQENZGP0.33333333349
KUBE-SEP-KJQQYC6E4EGY4UJE0.50000000000
KUBE-SEP-4DJFF4PKJG2GTZWW1-0.33333333349-0.50000000000=0.16666666651000006

其中KUBE-SEP-4DJFF4PKJG2GTZWW不需要设置probability，因为可以计算出来

1 − K U B E − S E P − L C X G R T 47 C Y Q E N Z G P − K U B E − S E P − K J Q Q Y C 6 E 4 E G Y 4 U J E 1- KUBE-SEP-LCXGRT47CYQENZGP - KUBE-SEP-KJQQYC6E4EGY4UJE 1−KUBE−SEP−LCXGRT47CYQENZGP−KUBE−SEP−KJQQYC6E4EGY4UJE

2.2.3 KUBE-SEP-LCXGRT47CYQENZGP规则链

# 第1条规则：Pod通过Service访问自身时匹配，此规则仅作标记（MARK）处理；
-A KUBE-SEP-4DJFF4PKJG2GTZWW -s 172.33.0.30/32 -j KUBE-MARK-MASQ
# 第2条规则：通过DNAT重定向到后端Pod实例上，至此，通过Service最终将流量导向到后端实例上；
-A KUBE-SEP-4DJFF4PKJG2GTZWW -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent
-A KUBE-SEP-KJQQYC6E4EGY4UJE -s 172.33.0.25/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-KJQQYC6E4EGY4UJE -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent
-A KUBE-SEP-LCXGRT47CYQENZGP -s 172.33.0.11/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-LCXGRT47CYQENZGP -p tcp -m tcp -j DNAT --to-destination :0 --persistent --to-destination :0 --persistent --to-destination 0.0.0.0 --persistent

按照KUBE-SVC-EFPSQH5654KMWHJ5配置的负载均衡相关的权重，将相关流量转发到后段的pod，完成流量转发和负载均衡。

2.2.4 KUBE-FW-EFPSQH5654KMWHJ5规则链

-A KUBE-FW-EFPSQH5654KMWHJ5 -m comment --comment "kube-system/kubernetes-lb: loadbalancer IP" -j KUBE-XLB-EFPSQH5654KMWHJ5
-A KUBE-FW-EFPSQH5654KMWHJ5 -m comment --comment "kube-system/kubernetes-lb: loadbalancer IP" -j KUBE-MARK-DROP

KUBE-MARK-DROP设置标记的报文则会在KUBE_FIREWALL中全部丢弃

2.2.5 KUBE-XLB-EFPSQH5654KMWHJ5规则链

-A KUBE-XLB-EFPSQH5654KMWHJ5 -s 172.16.21.0/24 -m comment --comment "Redirect pods trying to reach external loadbalancer VIP to clusterIP" -j KUBE-SVC-EFPSQH5654KMWHJ5
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "masquerade LOCAL traffic for kube-system/kubernetes-lb: LB IP" -m addrtype --src-type LOCAL -j KUBE-MARK-MASQ
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "route LOCAL traffic for kube-system/kubernetes-lb: LB IP to service chain" -m addrtype --src-type LOCAL -j KUBE-SVC-EFPSQH5654KMWHJ5
-A KUBE-XLB-EFPSQH5654KMWHJ5 -m comment --comment "Balancing rule 0 for kube-system/kubernetes-lb:" -j KUBE-SEP-LCXGRT47CYQENZGP

2.2.6 KUBE-XLB-EFPSQH5654KMWHJ5规则链

在KUBE-XLB后，loadbalancer的IP在节点上截获后转给service

-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-LCXGRT47CYQENZGP
-A KUBE-SVC-EFPSQH5654KMWHJ5 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-KJQQYC6E4EGY4UJE
-A KUBE-SVC-EFPSQH5654KMWHJ5 -j KUBE-SEP-4DJFF4PKJG2GTZWW

由此完成了流量转发。

2.3 iptables转发链路总结

  • 可以发现当流量在本机节点/pod进出时，需要进行流量的过滤和通过KUBE-MARK-MASQ进行流量打标，从而进行NAT转换。
  • 通过KUBE-SVC-EFPSQH5654KMWHJ5和KUBE-SEP-LCXGRT47CYQENZGP进行流量的负载均衡和转发，当svc和pod很多时，iptables相关的转发规则会很多
    单个节点的 i p t a b l e s 规则大体上可以 = s v c 数量 ∗ e n d p o i n t 数量 单个节点的iptables规则大体上可以=svc数量*endpoint数量 单个节点的iptables规则大体上可以=svc数量∗endpoint数量

单个 k 8 s 集群的 i p t a b l e s 规则数量 = 单节点的 i p t a b l e s 规则数量 ∗ 节点数量 单个k8s集群的iptables规则数量=单节点的iptables规则数量*节点数量 单个k8s集群的iptables规则数量=单节点的iptables规则数量∗节点数量

  • 由于iptables规则通过list类型数据结构进行管理，执行时间O(n)，当svc和node节点数量很多时，iptables规则过多时，新规则的查询和创建会越来越慢

3. ipvs规则解析

在 IPVS 模式下，kube-proxy监视Kubernetes服务和端点，调用 netlink 接口创建 IPVS 规则， 并定期将 IPVS 规则与 Kubernetes 服务和端点同步。访问服务时，IPVS 将流量定向到后端Pod之一。IPVS代理模式基于类似于 iptables 模式的 netfilter 挂钩函数， 但是使用哈希表作为基础数据结构，执行时间O(1)，并且在内核空间中工作。这意味着，与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。

3.1 ipvs工作原理

IPVS 模式的工作原理，其实跟 iptables 模式类似。当我们创建了前面的 Service 之后，kube-proxy 首先会在宿主机上创建一个虚拟网卡（叫作：kube-ipvs0），并为它分配 Service VIP 作为 IP 地址。接下来，kube-proxy 就会通过 Linux 的 IPVS 模块，为这个 IP 地址设置三个 IPVS 虚拟主机，并设置这三个虚拟主机之间使用轮询模式 (rr) 来作为负载均衡策略。拓扑图如下所示拓扑图：
在这里插入图片描述

查看绑定的虚拟网卡

# ip addr...73：kube-ipvs0：<BROADCAST,NOARP>  mtu 1500 qdisc noop state DOWN qlen 1000link/ether  1a:ce:f5:5f:c1:4d brd ff:ff:ff:ff:ff:ffinet 10.0.1.175/32  scope global kube-ipvs0valid_lft forever  preferred_lft forever

查看内部的转发规则

# ipvsadm -lnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags->  RemoteAddress:Port           Forward  Weight ActiveConn InActConn     TCP  10.102.128.4:80 rr->  10.244.3.6:9376    Masq    1       0          0         ->  10.244.1.7:9376    Masq    1       0          0->  10.244.2.3:9376    Masq    1       0          0

3.2 ipvs支持的负载均衡算法

  • rr：轮询调度
  • lc：最小连接数
  • dh：目标地址散列
  • sh：源地址散列
  • sed：最短期望延迟
  • nq：最少队列

3.3 svc涉及的ipvs链流程说明

  • 使用ipvs进行负载均衡和流量转发时，相对于iptables来说，svc的流量转发流程整体上跟使用iptables是一致的。
  • 差别是ipvs代替了iptables的KUBE-SVC-EFPSQH5654KMWHJ5和KUBE-SEP-LCXGRT47CYQENZGP进行流量的负载均衡和转发
  • 针对流量过滤和NAT，还是基于iptables实现，但是这样的辅助性的规则数量有限，不会造成性能瓶颈

因此ipvs模式下，实际上是 ipvs负载均衡 + iptables过滤和NAT，实现svc的流量转发整体流程

4. 疑问和思考

4.1 KUBE-MARK-MASQ规则说明

KUBE-MARK-MASQ的作用是确保Kubernetes集群中的流量在转发到外部网络时可以正确地进行NAT处理，并提供网络隔离、安全性、负载均衡和故障转移等功能。

  • 首先 KUBE-MARK-MASQ 的作用是把报文打上 0x4000/0x4000 的标记，在 KUBE-POSTROUTING 时，如果报文中包含这个标记，会执行 -j MASQUERADE 操作，而这个操作的作用就是做源地址转换（SNAT）。
  • Kubernetes集群中的每个节点上都有一个名为KUBE-MARK-MASQ的iptables规则。当流量进入节点时，该规则将被应用于这些流量，将源IP地址和源端口替换为节点的IP地址和随机端口。这样可以确保流量在从集群中的任何节点转发到外部网络时，都具有相同的源IP地址和端口。

4.2 KUBE-MARK-DROP规则说明

KUBE-MARK-DROP设置标记的报文则会在KUBE_FIREWALL中全部丢弃

4.3 使用iptables规则有什么问题？

iptables规则通过list类型数据结构进行管理，执行时间O(n)，当svc和node节点数量很多时，iptables规则过多时，新规则的查询和创建会越来越慢，并引发性能问题

  • 规则顺序匹配延迟大
  • 访问 service 时需要遍历每条链知道匹配，时间复杂度 O(N)，当规则数增加时，匹配时间也增加。
  • 规则更新延迟大
  • iptables 规则更新不是增量式的，每更新一条规则，都会把全部规则加载刷新一遍。
  • 规则数大时，会出现 kernel lock
  • svc 数增加到 5000 时，会频繁出现 Another app is currently holding the xtables lock. Stopped waiting after 5s， 导致规则更新延迟变大，kube-proxy 定期同步时也会因为 超时导致 CrashLoopBackOff。

4.4 iptables和ipvs两者的优劣势如何？

  • iptables和ipvs均是基于内核的netfilter进行流量转发，虽然实现方式上又差异，ipvs将相关操作转移到内核台进行，在性能上优于iptables，但是差别并不大，因此整体上认为性能上是相近的
  • 在集群中不超过1000个服务的时候，iptables 和 ipvs 并无太大的差异。而且由于iptables 与网络策略实现的良好兼容性，iptables 是个非常好的选择
  • 如果svc和节点数量持续增加，svc数量超过5000后，ipvs和iptables的性能差异开始显现出来，并且随着svc增加iptables的性能越来越差，而ipvs并不会随着svc增加出现性能上的差异

出现这样的差异，最主要的原因是

  • iptables使用list类型作为基础数据结构，执行时间O(n)
  • ipvs使用哈希表作为基础数据结构，执行时间O(1)

两者的性能压测情况，可以参考 对比 iptables 和 ipvs 的性能差异
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

5. 参考文档

  • 分析k8s service生成的iptables规则数量
  • 理解kubernetes的service流量转发链路
  • 对比 iptables 和 ipvs 的性能差异

这篇关于k8s的svc流量通过iptables和ipvs转发到pod的流程解析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

原文地址:
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.chinasem.cn/article/742669。

相关文章

C#代码实现解析WTGPS和BD数据

C#代码实现解析WTGPS和BD数据

《C#代码实现解析WTGPS和BD数据》在现代的导航与定位应用中,准确解析GPS和北斗（BD）等卫星定位数据至关重要,本文将使用C#语言实现解析WTGPS和BD数据,需要的可以了解下... 目录一、代码结构概览1. 核心解析方法2. 位置信息解析3. 经纬度转换方法4. 日期和时间戳解析5. 辅助方法二、L
阅读更多...
Mybatis Plus JSqlParser解析sql语句及JSqlParser安装步骤

Mybatis Plus JSqlParser解析sql语句及JSqlParser安装步骤

《MybatisPlusJSqlParser解析sql语句及JSqlParser安装步骤》JSqlParser是一个用于解析SQL语句的Java库,它可以将SQL语句解析为一个Java对象树,允许... 目录【一】jsqlParser 是什么【二】JSqlParser 的安装步骤【三】使用场景【1】sql语
阅读更多...
SpringBoot整合Sa-Token实现RBAC权限模型的过程解析

SpringBoot整合Sa-Token实现RBAC权限模型的过程解析

《SpringBoot整合Sa-Token实现RBAC权限模型的过程解析》：本文主要介绍SpringBoot整合Sa-Token实现RBAC权限模型的过程解析,本文给大家介绍的非常详细,对大家的学... 目录前言一、基础概念1.1 RBAC模型核心概念1.2 Sa-Token核心功能1.3 环境准备二、表结
阅读更多...
spring-gateway filters添加自定义过滤器实现流程分析(可插拔)

spring-gateway filters添加自定义过滤器实现流程分析(可插拔)

《spring-gatewayfilters添加自定义过滤器实现流程分析(可插拔)》：本文主要介绍spring-gatewayfilters添加自定义过滤器实现流程分析(可插拔),本文通过实例图... 目录需求背景需求拆解设计流程及作用域逻辑处理代码逻辑需求背景公司要求，通过公司网络代理访问的请求需要做请
阅读更多...
Java 关键字transient与注解@Transient的区别用途解析

Java 关键字transient与注解@Transient的区别用途解析

《Java关键字transient与注解@Transient的区别用途解析》在Java中,transient是一个关键字,用于声明一个字段不会被序列化,这篇文章给大家介绍了Java关键字transi... 在Java中，transient 是一个关键字，用于声明一个字段不会被序列化。当一个对象被序列化时，被
阅读更多...
使用JavaConfig配置Spring的流程步骤

使用JavaConfig配置Spring的流程步骤

《使用JavaConfig配置Spring的流程步骤》JavaConfig是Spring框架提供的一种基于Java的配置方式,它通过使用@Configuration注解标记的类来替代传统的XML配置文... 目录一、什么是 JavaConfig？1. 核心注解2. 与 XML 配置的对比二、JavaConf
阅读更多...
Java JSQLParser解析SQL的使用指南

Java JSQLParser解析SQL的使用指南

《JavaJSQLParser解析SQL的使用指南》JSQLParser是一个Java语言的SQL语句解析工具,可以将SQL语句解析成为Java类的层次结构,还支持改写SQL,下面我们就来看看它的具... 目录一、引言二、jsQLParser常见类2.1 Class Diagram2.2 Statement
阅读更多...
python进行while遍历的常见错误解析

python进行while遍历的常见错误解析

《python进行while遍历的常见错误解析》在Python中选择合适的遍历方式需要综合考虑可读性、性能和具体需求,本文就来和大家讲解一下python中while遍历常见错误以及所有遍历方法的优缺点... 目录一、超出数组范围问题分析错误复现解决方法关键区别二、continue使用问题分析正确写法关键点三
阅读更多...
使用Java实现Navicat密码的加密与解密的代码解析

使用Java实现Navicat密码的加密与解密的代码解析

《使用Java实现Navicat密码的加密与解密的代码解析》：本文主要介绍使用Java实现Navicat密码的加密与解密,通过本文,我们了解了如何利用Java语言实现对Navicat保存的数据库密... 目录一、背景介绍二、环境准备三、代码解析四、核心代码展示五、总结在日常开发过程中，我们有时需要处理各种软
阅读更多...
Python多进程、多线程、协程典型示例解析(最新推荐)

Python多进程、多线程、协程典型示例解析(最新推荐)

《Python多进程、多线程、协程典型示例解析(最新推荐)》：本文主要介绍Python多进程、多线程、协程典型示例解析(最新推荐),本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定... 目录一、multiprocessing（多进程）1. 模块简介2. 案例详解：并行计算平方和3. 实现逻
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2