探究K8S Service内部iptables路由规则

iptables介绍

我们知道，linux系统中有route，用来和其他网络连接。如果没有它，linux就无法和外部通信了。

iptables是一系列的规则，用来对内核中的数据进行处理。没有它，linux可以正常工作，有了它，linux可以对网络中的数据的操作更加多样化，可见iptables是一个辅助角色，可以让linux的网络系统更强大。

iptables其实不是真正的防火墙，我们可以把它理解成一个客户端代理，用户通过iptables这个代理，将用户的安全设定执行到对应的"安全框架"中，这个"安全框架"才是真正的防火墙，这个框架的名字叫netfilter

netfilter才是防火墙真正的安全框架（framework），netfilter位于内核空间。

iptables其实是一个命令行工具，位于用户空间，我们用这个工具操作真正的框架。

netfilter/iptables（下文中简称为iptables）组成Linux平台下的包过滤防火墙，与大多数的Linux软件一样，这个包过滤防火墙是免费的，它可以代替昂贵的商业防火墙解决方案，完成封包过滤、封包重定向和网络地址转换（NAT）等功能。

Netfilter是Linux操作系统核心层内部的一个数据包处理模块，它具有如下功能：

网络地址转换(Network Address Translate)
数据包内容修改
数据包过滤的防火墙功能

所以说，虽然我们使用service iptables start启动iptables"服务"，但是其实准确的来说，iptables并没有一个守护进程，所以并不能算是真正意义上的服务，而应该算是内核提供的功能。

iptables基础

我们知道iptables是按照规则来办事的，我们就来说说规则（rules），规则其实就是网络管理员预定义的条件，规则一般的定义为"如果数据包头符合这样的条件，就这样处理这个数据包"。规则存储在内核空间的信息包过滤表中，这些规则分别指定了源地址、目的地址、传输协议（如TCP、UDP、ICMP）和服务类型（如HTTP、FTP和SMTP）等。当数据包与规则匹配时，iptables就根据规则所定义的方法来处理这些数据包，如接收（accept）、拒绝（reject）和丢弃（drop）等。配置iptables的主要工作就是添加、修改和删除这些规则。

当客户端访问服务器的web服务时，客户端发送报文到网卡，而tcp/ip协议栈是属于内核的一部分，所以，客户端的信息会通过内核的TCP协议传输到用户空间中的web服务中，而此时，客户端报文的目标终点为web服务所监听的套接字（IP：Port）上，当web服务需要响应客户端请求时，web服务发出的响应报文的目标终点则为客户端，这个时候，web服务所监听的IP与端口反而变成了原点，我们说过，netfilter才是真正的防火墙，它是内核的一部分，所以，如果我们想要防火墙能够达到"防火"的目的，则需要在内核中设置关卡，所有进出的报文都要通过这些关卡，经过检查后，符合放行条件的才能放行，符合阻拦条件的则需要被阻止，于是，就出现了input关卡和output关卡，而这些关卡在iptables中不被称为"关卡",而被称为"链"。

其实我们上面描述的场景并不完善，因为客户端发来的报文访问的目标地址可能并不是本机，而是其他服务器，当本机的内核支持IP_FORWARD时，我们可以将报文转发给其他服务器，所以，这个时候，我们就会提到iptables中的其他"关卡"，也就是其他"链"，他们就是 "路由前"、"转发"、"路由后"，他们的英文名是

PREROUTING、FORWARD、POSTROUTING

也就是说，当我们启用了防火墙功能时，报文需要经过如下关卡，也就是说，根据实际情况的不同，报文经过"链"可能不同。如果报文需要转发，那么报文则不会经过input链发往用户空间，而是直接在内核空间中经过forward链和postrouting链转发出去的。

根据上图，我们能够想象出某些常用场景中，报文的流向：

到本机某进程的报文：PREROUTING --> INPUT

由本机转发的报文：PREROUTING --> FORWARD --> POSTROUTING

由本机的某进程发出报文（通常为响应报文）：OUTPUT --> POSTROUTING

链(chain)的概念

现在，我们想象一下，这些"关卡"在iptables中为什么被称作"链"呢？我们知道，防火墙的作用就在于对经过的报文匹配"规则"，然后执行对应的"动作"。所以，当报文经过这些关卡的时候，则必须匹配这个关卡上的规则，但是，这个关卡上可能不止有一条规则，而是有很多条规则，当我们把这些规则串到一个链条上的时候，就形成了"链",所以，我们把每一个"关卡"想象成如下图中的模样，这样来说，把他们称为"链"更为合适，每个经过这个"关卡"的报文，都要将这条"链"上的所有规则匹配一遍，如果有符合条件的规则，则执行规则对应的动作。

表(table)的概念

把具有相同功能的规则的集合叫做"表"，不同功能的规则，可以放置在不同的表中进行管理，而iptables已经定义了4种表，每种表对应了不同的功能，所有的规则都在这4种功能的范围，所以，学习iptables之前，要搞明白每种表的作用。

iptables为我们提供了如下规则的分类，或者说，iptables为我们提供了如下"表"

filter表：负责过滤功能，防火墙；内核模块：iptables_filter
nat表：network address translation，网络地址转换功能；内核模块：iptable_nat
mangle表：拆解报文，做出修改，并重新封装的功能；iptable_mangle
raw表：关闭nat表上启用的连接追踪机制；iptable_raw

也就是说，我们自定义的所有规则，都是这四种功能分类中的规则，或者说，所有规则都存在于这4张"表"中。

表链关系

但是我们需要注意的是，某些"链"中注定不会包含"某类规则"，就像某些"关卡"天生就不具备某些功能一样，比如，A"关卡"只负责打击陆地敌人，没有防空能力，B"关卡"只负责打击空中敌人，没有防御步兵的能力，C"关卡"可能比较NB，既能防空，也能防御陆地敌人，D"关卡"最屌，海陆空都能防。

那让我们来看看，每个"关卡"都有哪些能力，或者说，让我们看看每个"链"上的规则都存在于哪些"表"中。

我们还是以图为例，先看看prerouting"链"上的规则都存在于哪些表中。

这幅图是什么意思呢，它的意思是说，prerouting"链"只拥有nat表、raw表和mangle表所对应的功能，所以，prerouting中的规则只能存放于nat表、raw表和mangle表中。

那么，根据上述思路，我们来总结一下，每个"关卡"都拥有什么功能，

或者说，每个"链"中的规则都存在于哪些"表"中。

链	可以包含链规则的表
PREROUTING	raw表，mangle表，nat表
INPUT	mangle表，filter表，（centos7中还有nat表，centos6中没有）
FORWARD	mangle表，filter表
OUTPUT	raw表mangle表，nat表，filter表
POSTROUTING	mangle表，nat表

但是，我们在实际的使用过程中，往往是通过"表"作为操作入口，对规则进行定义的，之所以按照上述过程介绍iptables，是因为从"关卡"的角度更容易从入门的角度理解，但是为了以便在实际使用的时候，更加顺畅的理解它们，此处我们还要将各"表"与"链"的关系罗列出来，

表（功能）<--> 链（钩子）：

raw 表中的规则可以被哪些链使用：PREROUTING，OUTPUT
mangle 表中的规则可以被哪些链使用：PREROUTING，INPUT，FORWARD，OUTPUT，POSTROUTING
nat 表中的规则可以被哪些链使用：PREROUTING，OUTPUT，POSTROUTING（centos7中还有INPUT，centos6中没有）
filter 表中的规则可以被哪些链使用：INPUT，FORWARD，OUTPUT

其实我们还需要注意一点，因为数据包经过一个"链"的时候，会将当前链的所有规则都匹配一遍，但是匹配时总归要有顺序，我们应该一条一条的去匹配，而且我们说过，相同功能类型的规则会汇聚在一张"表"中，那么，哪些"表"中的规则会放在"链"的最前面执行呢，这时候就需要有一个优先级的问题，我们还拿prerouting"链"做图示。

prerouting链中的规则存放于三张表中，而这三张表中的规则执行的优先级如下：

raw --> mangle --> nat

但是我们知道，iptables为我们定义了4张"表",当他们处于同一条"链"时，执行的优先级如下。

优先级次序（由高而低）：

raw --> mangle --> nat --> filter

但是我们前面说过，某些链天生就不能使用某些表中的规则，所以，4张表中的规则处于同一条链的目前只有output链，它就是传说中海陆空都能防守的关卡（功能都可以实现）。

为了更方便的管理，我们还可以在某个表里面创建自定义链，将针对某个应用程序所设置的规则放置在这个自定义链中，但是自定义链接不能直接使用，只能被某个默认的链当做动作去调用才能起作用，我们可以这样想象，自定义链就是一段比较"短"的链子，这条"短"链子上的规则都是针对某个应用程序制定的，但是这条短的链子并不能直接使用，而是需要"焊接"在iptables默认定义链子上，才能被IPtables使用，这就是为什么默认定义的"链"需要把"自定义链"当做"动作"去引用的原因。这是后话，后面再聊，在实际使用时我们即可更加的明白。

数据经过防火墙流程

结合上述所有的描述，我们可以将数据包通过防火墙的流程总结为下图：

规则的概念

规则（rule）：根据指定的匹配条件来尝试匹配每个流经此处的报文，一旦匹配成功，则由规则后面指定的处理动作进行处理；

规则由匹配条件和处理动作组成。

匹配条件
- 通用匹配（协议、IP）
  - 协议匹配：-p 协议名
    地址匹配：-s 源地址、-d 目的地址
    接口匹配：-i 入站网卡 -o 出站网卡
- 隐含匹配（端口，icmp类型）
  - 端口匹配：--sport 源端口 --dport 目的端口
    ICMP类型 --icmp-type ICMP类型
- 显示匹配（-m扩展模块）
  - 多端口匹配
    - -m mutiport --sport 源端口列表
    - -m mutiport --dport 目的端口列表
  - IP范围匹配
    - -m iprange --src-range IP范围
  - MAC地址匹配
    - -m mac --mac-source MAC地址
  - 状态匹配
    - -m state --state 连接状态
  - 时间匹配
    - -m time --timestart 开始时间 --timestop 结束时间
处理动作
- 处理动作在iptables中被称为target（这样说并不准确，我们暂且这样称呼），动作也可以分为基本动作和扩展动作。
- 此处列出一些常用的动作，之后的文章会对它们进行详细的示例与总结：
  - ACCEPT：允许数据包通过。
  - DROP：直接丢弃数据包，不给任何回应信息，这时候客户端会感觉自己的请求泥牛入海了，过了超时时间才会有反应。
  - REJECT：拒绝数据包通过，必要时会给数据发送端一个响应的信息，客户端刚请求就会收到拒绝的信息。
  - SNAT：源地址转换，解决内网用户用同一个公网地址上网的问题。
  - MASQUERADE：是SNAT的一种特殊形式，适用于动态的、临时会变的ip上。
  - DNAT：目标地址转换。
  - REDIRECT：在本机做端口映射。

LOG：在/var/log/messages文件中记录日志信息，然后将数据包传递给下一条规则，也就是说除了记录以外不对数据包做任何其他操作，仍然让下一条规则去匹配。

具体规则实践部分可见下面文章：

防火墙

K8S Service内部iptables路由规则

K8s Service 会为每个 Pod 都设置一个它自己的 IP，并为一组 Pod 提供一个统一的 DNS 域名，还可以提供在它们间做负载均衡的能力。这篇文章会对 kube-proxy 的 iptables 模式内部的机制做一个验证。大体上涉及的内容如下：

集群环境：

kubernetes 1.23
flannel iptables vxlan模式

为便于讲解，我们先创建如下应用及Service服务：

kubectl create deployment nginx-web-1 --image=nginx
kubectl expose deployment nginx-web-1 --name=nginx-svc --port=80 --target-port=80

Service Route（服务路由）

如下可知，通过nginx-web-1服务可实际访问到后端pod：svc：10.101.245.66访问到 pod：10.244.2.13

Service服务分配的CLUSTER-IP以及监听的端口均虚拟的，即在K8S集群节点上执行ip a与netstat -an命令均无法找到，其实际上，IP与Port是由iptables配置在每K8S节点上的。在节点上执行如下命令可找到此Service相关的iptables配置。

我们先用 iptables-save 打印出所有的规则，筛选出和 nginx-svc service 相关的规则，规则有这么几类：

这里遇到了一些问题，如果遇到非正常显示的iptables（--to-destination :0 ，目前我的iptables版本过低：v1.4.x导致，正常应该为--to-destination IP:PORT，这里我们升级到 v1.8.7，参考链接：https://blog.51cto.com/liruilong/6236491）

重新尝试下:

KUBE-NODEPORTS，这类规则用来将发送到 NodePort 的报文转到 KUBE-SVC-*（本次尚未配置，可以配置NodePort观察）
KUBE-SERVICES：是识别目标地址为 ClusterIP(10.101.245.66)，命中的报文转到 KUBE-SVC-* 做处理
KUBE-SVC 的作用是做负载均衡，将请求分配到 KUBE-SEP 中
KUBE-SEP 通过 DNAT 替换目标地址为 Pod IP，转发到具体的 POD 中

本案例线路分析：其整个过程可以简单描述为以下过程：

PREROUTING --> KUBE-SERVICES --> KUBE-SVC-XXX --> KUBE-SEP-XXX

当通过Service服务IP：10.101.245.66:80访问时，匹配第3条规则链（KUBE-SERVICES）后，跳转到第5条子链（KUBE-SVC-…）上；
第5条子链做简单注释后，继而跳转到第1、2规则链（KUBE-SEP-…）上；
当源Pod通过Service访问自身时，匹配第1条规则，继而跳转到KUBE-MARK-MASQ链中；
匹配到第2条规则，此时通过DNAT被重定向到后端Pod：10.244.2.13:80。

SNAT：KUBE-MARK-MASQ规则：

前面我们提到 KUBE 系列的规则经常看到 -j KUBE-MARK-MASQ，和它相关的规则有这些：

-A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000
-A KUBE-POSTROUTING -m mark ! --mark 0x4000/0x4000 -j RETURN
-A KUBE-POSTROUTING -j MARK --set-xmark 0x4000/0x0
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -j MASQUERADE

首先 KUBE-MARK-MASQ 的作用是把报文打上 0x4000/0x4000 的标记，在 KUBE-POSTROUTING 时，如果报文中包含这个标记，会执行 -j MASQUERADE 操作，而这个操作的作用就是做源地址转换（SNAT）。那 SNAT 是什么，为什么要做 SNAT 呢？

如果没有 SNAT，被转发到 POD 的请求返回时，会尝试把请求直接返回给 Client，我们知道一个 TCP 连接的依据是(src_ip, src_port, dst_ip, dst_port)，现在client 在等待 eIP/NP 返回的报文，等到的却是 pod IP 的返回，client 不认这个报文。换句话说，经过 proxy 的流量都正常情况下都应该原路返回才能工作。

本案例规则中有两条规则出现KUBE-MARK-MASQ，如果没有这两条规则则会出现下面问题：

回包问题：当服务在集群内部的Pod上运行时，回包需要经过NAT处理，以确保返回流量能够正确回到发起请求的主机。如果没有这个SNAT规则，返回的数据包可能无法正确路由到请求的主机，导致连接问题。
网络地址转换问题： KUBE-SVC-HL5LMXD5JFHQZ6LN规则中的 -j KUBE-MARK-MASQ 用于对集群外的请求进行SNAT。这是为了确保流量离开集群时，其源地址被更改为集群节点的地址。如果没有这个规则，集群外的网络可能无法正确识别和响应来自集群内部服务的请求。

KUBE-SERVICES规则是在哪个表中的哪个链上呢？

如果详细分析iptables规则，执行iptables-save命令可发现nat的PREROUTING与OUTPUT链中均有KUBE-SERVICES规则链，且处于第一顺位。

iptables-save | grep -C 100 *nat

在Kubernetes中，有时候我们需要确保从外部访问服务时和从内部服务发起请求时都能够正确地到达目标。为了实现这个目标，防火墙规则被设置在两个地方：

入站规则（PREROUTING链）： 这是处理从外部进入Kubernetes集群的数据包的地方。当有人从外部访问你的服务时，防火墙规则会确保这些数据包被正确地引导到目标服务。
出站规则（OUTPUT链）： 这是处理从Kubernetes集群中的服务发出的请求的地方。当你的服务需要与其他服务通信时，防火墙规则会确保这些请求被正确地引导到目标服务。

通过在这两个地方设置规则，Kubernetes可以确保服务在内外部的通信都能够正常工作，而不仅仅是一方面。这对于服务发现和代理等功能是非常重要的。

Kubernetes使用PREROUTING和OUTPUT链上的规则是为了处理不同方向上的数据包。这两个链分别负责入站和出站的数据包处理：

PREROUTING链： 该链处理数据包在到达目标系统之前的阶段。在Kubernetes中，这意味着处理进入集群的数据包。当服务的访问请求进入集群时，PREROUTING链上的规则能够捕获这些数据包并进行相应的处理，例如进行目标地址和端口的转发。
OUTPUT链： 该链处理从本地系统发出的数据包。在Kubernetes中，这意味着处理本地系统中的服务发起的请求。当本地的服务需要与其他服务通信时，OUTPUT链上的规则能够捕获这些数据包并进行相应的处理，例如进行目标地址和端口的转发。

通过在这两个链上分别匹配service规则，Kubernetes能够确保对于集群内外的数据包，都能够正确地进行服务发现和代理。这种灵活性允许Kubernetes在处理入站和出站的数据包时应用不同的规则，以支持服务的动态扩展和管理。

那防火墙出规则为什么不设置在POSROUTING链上，而是OUTPUT链上呢？

在Kubernetes中，防火墙规则通常不直接设置在POSTROUTING链上，而是在OUTPUT链上进行设置，这涉及到数据包处理的不同阶段和需求：

OUTPUT链： 这是在数据包离开本地系统之前处理的地方。当本地的服务发起请求时，这些请求经过OUTPUT链。在Kubernetes中，这些规则通常用于处理本地服务发起的请求，例如服务发现、代理和转发。
POSTROUTING链： 这是在数据包即将离开系统时进行处理的地方。它适用于出站数据包的最后一道处理，可以在数据包离开系统之前进行一些最终的修改。在Kubernetes中，POSTROUTING链通常用于进行NAT(Network Address Translation)，以确保数据包离开系统时，源地址和端口等信息被修改成期望的形式。

在Kubernetes中，OUTPUT链更适合处理服务发起的请求，因为它可以在数据包离开系统之前进行必要的地址转换和代理操作。POSTROUTING链通常用于更底层的网络配置，而在Kubernetes中，这些底层的网络配置已经由CNI(Container Network Interface)插件或者其他网络层面的工具来完成。因此，更高层次的服务发现和代理通常在OUTPUT链上进行处理。

由此可知，当通过Service访问应用时，流量经由nat表中的PREROUTING规则链处理后，跳转到KUBE-SERVICES子链，而此链包含了对具体Service处理的规则。访问10.101.245.66:80将被跳转到KUBE-SEP-…子规则链中。

下面理清楚列出每条规则顺序并最后分析：

第一条规则：
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES

注释：
-A PREROUTING: 这部分指定了这个规则将被添加到 iptables 的 PREROUTING 链中。PREROUTING 链用于对进入网络栈的数据包进行修改，通常在数据包到达目标系统之前。

-m comment --comment "kubernetes service portals": -m comment 模块用于添加注释，以提供对规则目的的说明。在这里，注释是 "kubernetes service portals"，表示这个规则用于处理 Kubernetes 服务门户。在iptables中，注释规则的作用是为了提供对规则的说明、描述或者备注信息，以便管理员或其他团队成员能够更容易地理解和维护防火墙规则集。注释可以帮助解释规则的目的、来源、目标等信息，提高规则集的可读性和可维护性。

-j KUBE-SERVICES: 这部分指定了数据包应该跳转到 KUBE-SERVICES 链。这个链很可能是由 Kubernetes 网络插件（如Flannel、Calico等）创建的，用于处理服务端口的网络地址转发。

总的来说，PREROUTING 链用于在流量进入路由决策之前处理。这条规则的目的是匹配流量并将其重定向到 KUBE-SERVICES 链，这个链可能包含了与 Kubernetes 服务相关的进一步规则。


第二条规则：
-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
这是一个在 iptables 的 OUTPUT 链上的规则。OUTPUT 链用于处理本地生成的流量。这条规则的目的是匹配本地生成的流量并将其重定向到 KUBE-SERVICES 链，这个链同样可能包含了与 Kubernetes 服务相关的规则。

第三条规则：
-A KUBE-SVC-HL5LMXD5JFHQZ6LN ! -s 10.244.0.0/16 -d 10.101.245.66/32 -p tcp -m comment --comment "default/nginx-svc cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
这是一个 KUBE-SVC-HL5LMXD5JFHQZ6LN 链的规则，用于标记目标地址为 10.101.245.66、目标端口为 80 的 TCP 数据包，但源地址不在 10.244.0.0/16 网段内（不交给cni0，跨节点流量），以进行地址伪装（MASQ）。这是为了确保在数据包离开节点时，其源地址被更改为集群节点的地址，源地址得到伪装，以保护真实的服务节点信息。流量离开集群时，如果没有这个规则，集群外的网络可能无法正确识别和响应来自集群内部服务的请求。

第四条规则：
-A KUBE-SERVICES -d 10.101.245.66/32 -p tcp -m comment --comment "default/nginx-svc cluster IP" -m tcp --dport 80 -j KUBE-SVC-HL5LMXD5JFHQZ6LN
这是一个 KUBE-SERVICES 链的规则，用于将目标地址为 10.101.245.66（nginx-svc地址）、目标端口为 80 的 TCP 数据包重定向到 KUBE-SVC-HL5LMXD5JFHQZ6LN 链。这条规则的执行顺序与上一条规则是有逻辑关系的。首先，上一条规则标记了 MASQUERADE 流量，然后这条规则根据这个标记将流量定向到相应的 Service Endpoint。如果你交换这两条规则的顺序，就可能导致流量在被标记之前就被定向，或者定向到了不正确的地方，从而破坏了预期的网络行为。

第五条规则：
-A KUBE-SVC-HL5LMXD5JFHQZ6LN -m comment --comment "default/nginx-svc" -j KUBE-SEP-VNK6I6TFQ6F6B3VL
这是一个 KUBE-SVC-HL5LMXD5JFHQZ6LN 链的规则，将匹配 "default/nginx-svc" 注释的数据包重定向到 KUBE-SEP-VNK6I6TFQ6F6B3VL 链。此链用于匹配源地址在10.244.0.0/16 网段内的数据包，因为只需要交给本地cni0网卡处理即可

第六条规则：
-A KUBE-SEP-VNK6I6TFQ6F6B3VL -s 10.244.2.13/32 -m comment --comment "default/nginx-svc" -j KUBE-MARK-MASQ
这是一个 KUBE-SEP-VNK6I6TFQ6F6B3VL 链的规则，用于标记源地址为 10.244.2.13（pod自身访问） 的数据包，以进行地址伪装（MASQ）。用于标记流出 Service Endpoint 的流量，并进行 SNAT。如果没有添加自身访问规则，Pod 自身访问服务时的流量就只会匹配到 DNAT 规则，而可能会绕过 MASQUERADE 操作。这可能导致返回流量无法正确返回到 Pod，因为它的源 IP 地址可能是 本身 Pod 的 IP 地址，而不是经过 MASQUERADE 处理的节点 IP 地址。通过添加自身访问规则，确保了 Pod 自身访问服务的流量也经过了 MASQUERADE 操作。这有助于保持网络的一致性，使得所有流量都经过相似的处理路径。

第七条规则：
-A KUBE-SEP-VNK6I6TFQ6F6B3VL -p tcp -m comment --comment "default/nginx-svc" -m tcp -j DNAT --to-destination 10.244.2.13:80
这是一个 KUBE-SEP-VNK6I6TFQ6F6B3VL 链的规则，用于将 TCP 数据包目标地址和端口重定向到 10.244.2.13:80，用于进行 DNAT。

Loadbalance（负载均衡）

执行如下命令将Deployment扩展为3个Pod后，继而再观察Service负载均衡方面的技术或问题。

kubectl scale deploy/nginx-web-1 --replicas=3

如何做负载均衡？这部分是比较纯粹的 iptables 知识

首先：iptables 对于规则的解析是严格顺序的，所以如果只是单纯列出两个条目，则会永远命中第一条：

-A KUBE-SVC-S -j KUBE-SEP-A
-A KUBE-SVC-S -j KUBE-SEP-B

于是，我们需要第一条规则在某些条件下不命中。这样 iptables 就有机会执行后面的规则。iptables 提供了两种方法，第一种是有随机数：

-A KUBE-SVC-S -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-B

这条规则在执行时，iptables 会随机生成一个数，并以 probability 的概率命中当前规则。换句话说，第一条命中的概率是 p，则第二条规则就是 1-p。如果有 3 个副本，则会类似下面这样的规则，大家可以计算下最后三个 Pod 是不是平均分配：

-A KUBE-SVC-S --mode random --probability 0.33333333349 -j KUBE-SEP-A
-A KUBE-SVC-S --mode random --probability 0.50000000000 -j KUBE-SEP-B
-A KUBE-SVC-S -j KUBE-SEP-C

另外一种模式是 round-robin，但是 kubernetes 的 iptables 模式不支持。为什么在iptables中使用随机数方式而不是round-robin方式，这涉及到设计和性能考虑。

简单性： 随机数分发的方法相对简单，而且在实现上不需要维护太多的状态信息。相比之下，round-robin算法需要追踪每个服务的状态和连接数，这可能导致更复杂的实现和更高的性能开销。
避免连接积聚： 使用随机数方式可以避免连接在某些服务上积聚的问题。在round-robin中，如果某个服务上的连接数较多，新的连接仍然会被分发到该服务，可能导致不均衡的情况。而使用随机数，连接有机会被分发到其他服务，减轻了这种情况的影响。
动态性： 随机数方式更适用于动态环境，其中服务的数量和状态可能会经常变化。在这种情况下，round-robin可能需要更频繁的调整，而随机数方式相对更为灵活。
性能： 随机数方式在某些情况下可能表现更好，特别是在服务数量较大的情况下。round-robin可能导致更多的连接状态维护和更复杂的算法，从而影响性能。

再次dump防火墙规则，发现Service经由iptables的statistic模块，以random方式均衡的分发流量，也即负载均衡模式为轮训。

存在3条DNAT与KUBE-MARK-MASQ规则，分别对应3个后端Pod实地址；
KUBE-SERVICES链中存在3条子链，除最后一条KUBE-SVC-…子链外，其余子链使用模块statistic的random模式做流量分割或负载均衡：第1条KUBE-SVC-…应用33%流量，第2条KUBE-SVC-…规则应用剩余的50%流量，第3条KUBE-SVC-…规则应用最后的流量，来实现流量均衡。

Session Affinity（会话保持）

如下所示，调整Service服务，打开会话保持功能，并设置会话保持期限为3小时（PS：若不设置，则默认是3小时）：

# kubectl edit svc nginx-svc
...
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800
...

继续观察iptables实现，发现在原有基础上，iptables规则中添加了recent模块，此模块被用于会话保持功能，故kube-proxy通过在iptables中结合statistic与recent模块，实现了Service的轮训负载均衡与会话保持功能。

通过Service服务访问应用，封包进入KUBE-SERVICES规则链，并跳转到KUBE-SVC-…子链中；
在KUBE-SVC-SNP…子链中，recent位于statistic模块前，故而，有如下情况出现：
- 当客户端第一次访问Service时，KUBE-SVC-…子链中的规则（-m recent –rcheck –seconds 10800 –reap …–rsource）池中未记录客户端地址，故封包匹配失败，从而封包被后续的statistic模块规则处理后，均衡分发到KUBE-SEP-…子链中，此链中使用recent模块的–set参数将客户源地址记录到规则池后，DNAT到实际后端实例上；
- KUBE-SVC-…子链中recent模块配置了源地址记录期限，若客户端3（–seconds 10800 –reap）小时内未访问服务，则recent规则池中的客户端记录将被移除，此时客户端再次访问Service就如同第一次访问Service一样；
- 当客户端在3小时内再次访问Service时，匹配KUBE-SVC-…子链中的recent模块规则后，跳转到KUBE-SEP子链，其规则中recent模块–set参数将更新规则池中的Record TTL，而后DNAT到实际后端实例上；

总结:
K8S中的Service服务可提供负载均衡及会话保持功能，其通过Linux内核netfilter模块来配置iptables实现，网络封包在内核中流转，且规则匹配很少，故效率非常高；而Service负载均衡分发比较薄弱，其通过statistic的random规则实现轮训分发，无法实现复杂的如最小链接分发方式，鉴于此，K8S 1.9后续版本调整了kube-proxy服务，其可通过ipvs实现Service负载均衡功能。

DNS访问service方式

K8s 会为 Service 创建一个 DNS 域名，格式为 <svc>.<namespace>.svc.<cluster-domain>，例如我们创建的 nginx-svc Service 则会有 nginx-svc.default.svc.cluster.local域名。

这里的 10.96.0.10 是 kube-dns service 的 cluster IP
文件中配置了多个 search 域，因此我们写 spring-test 或 spring-test.default 或 spring-test.default.svc 都是可以解析的，另外注意解析后的 IP 也不是具体哪个 POD 的地址，而是为 Service 创建的虚拟地址 ClusterIP。

发布者：LJH，转发请注明出处：https://www.ljh.cool/39959.html