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

本文主要是介绍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链路过程中的相关流程情况流程图如下

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-LCXGRT47CYQENZGP	0.33333333349
KUBE-SEP-KJQQYC6E4EGY4UJE	0.50000000000
KUBE-SEP-4DJFF4PKJG2GTZWW	1-0.33333333349-0.50000000000=0.16666666651000006

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

$1 - K U BE - SEP - L CXGRT 47 C Y QENZGP - K U BE - SEP - K J QQ Y C 6 E 4 EG Y 4 U J E$

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 pt ab l es 规则大体上可以 = s v c 数量 * e n d p o in t 数量$

$单个 k 8 s 集群的 i pt ab l es 规则数量 = 单节点的 i pt ab l es 规则数量 * 节点数量$

由于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增加出现性能上的差异

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