郑州网站搭建的公司,知名品牌策划设计公司,做拍客哪个网站好,推广手段和渠道有哪些文章目录 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-L… 文章目录 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节点上根本查询不到这个ipping是不通的具体是怎么访问到的继续往下看因此内部服务可以通过这个ip或者是serviceName来访问到pod的服务。
service提供的常用type
ClusterIP也是默认方式。Service会分配一个集群内部的固定虚拟IP实现集群内通过该IP来对POD进行访问。这个又有两类上面说到的最普通的ServiceClusterIP还有一种是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: 311011.2 endpoints说明
endpoints也是k8s的一个资源我们在创建service的时候如果我们设置了selector选中了需要关联的pod那么就会创建一个与service同名的endpoints。他是用来记录service对应pod的访问地址。
[rootaliyun168-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 18m1.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-SERVICESKUBE-NODEPORTSKUBE-POSTROUTINGKUBE-MARK-MASQ和KUBE-MARK-DROP五个链并主要通过为 KUBE-SERVICES链附着在PREROUTING和OUTPUT增加rule来配制traffic routing 规则
2.1 svc涉及的iptables链流程说明
svc涉及的iptables链路过程中的相关流程情况流程图如下 #mermaid-svg-T53m7l0X30rVLHdL {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-T53m7l0X30rVLHdL .error-icon{fill:#552222;}#mermaid-svg-T53m7l0X30rVLHdL .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-T53m7l0X30rVLHdL .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-T53m7l0X30rVLHdL .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-T53m7l0X30rVLHdL .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-T53m7l0X30rVLHdL .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-T53m7l0X30rVLHdL .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-T53m7l0X30rVLHdL .marker{fill:#333333;stroke:#333333;}#mermaid-svg-T53m7l0X30rVLHdL .marker.cross{stroke:#333333;}#mermaid-svg-T53m7l0X30rVLHdL svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-T53m7l0X30rVLHdL .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-T53m7l0X30rVLHdL .cluster-label text{fill:#333;}#mermaid-svg-T53m7l0X30rVLHdL .cluster-label span{color:#333;}#mermaid-svg-T53m7l0X30rVLHdL .label text,#mermaid-svg-T53m7l0X30rVLHdL span{fill:#333;color:#333;}#mermaid-svg-T53m7l0X30rVLHdL .node rect,#mermaid-svg-T53m7l0X30rVLHdL .node circle,#mermaid-svg-T53m7l0X30rVLHdL .node ellipse,#mermaid-svg-T53m7l0X30rVLHdL .node polygon,#mermaid-svg-T53m7l0X30rVLHdL .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-T53m7l0X30rVLHdL .node .label{text-align:center;}#mermaid-svg-T53m7l0X30rVLHdL .node.clickable{cursor:pointer;}#mermaid-svg-T53m7l0X30rVLHdL .arrowheadPath{fill:#333333;}#mermaid-svg-T53m7l0X30rVLHdL .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-T53m7l0X30rVLHdL .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-T53m7l0X30rVLHdL .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-T53m7l0X30rVLHdL .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-T53m7l0X30rVLHdL .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-T53m7l0X30rVLHdL .cluster text{fill:#333;}#mermaid-svg-T53m7l0X30rVLHdL .cluster span{color:#333;}#mermaid-svg-T53m7l0X30rVLHdL div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-T53m7l0X30rVLHdL :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 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/componentkube-apiserver,componentkube-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-LCXGRT47CYQENZGP2.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.33333333349KUBE-SEP-KJQQYC6E4EGY4UJE0.50000000000KUBE-SEP-4DJFF4PKJG2GTZWW1-0.33333333349-0.500000000000.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-DROPKUBE-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-LCXGRT47CYQENZGP2.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...73kube-ipvs0BROADCAST,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 (size4096)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 03.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 locksvc 数增加到 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 的性能差异
