---

前言

本文通过实际查看iptables规则表确认Pod数量、Service数量、节点数量和iptables规则数量的对应计算关系
仅简单描述分析过程，未描述原理，后续再补充

---

提示：以下是本篇文章正文内容，以下计算方式可供参考

一、分析过程

1.集群内调用service

集群内POD调用service，通常是使用Cluster IP。
集群内发起调用，通过cluster ip访问到service。
集群外发起调用，通过nodeport访问到service。
现在我们登录到任意node，因为k8s会把完整的iptables规则下发到每一个node。

2.cluster ip工作原理

调用方是某个node上面的某个POD，它向cluster ip 192.168.0.208发起调用，所以走的是OUTPUT链。

iptables要做的事情，就是识别dst（目标IP）192.168.0.208的包，把dst改写成某一个Endpoints的IP地址（这个service背后对应2个endpoints）。

3. 从output链开始看

iptables -t nat -nvL OUTPUT

可以看到KUBE-SERVICES链

4. 查看KUBE-SERVICES规则链

iptables -t nat -nvL KUBE-SERVICES |grep nginx-web

上述2条规则是顺序执行的：

• 第1条规则匹配发往Cluster IP 10.43.142.140的流量，跳转到了KUBE-MARK-MASQ链进一步处理，其作用就是打了一个MARK
• 第2条规则匹配发往Cluster IP 10.43.142.140的流量，跳转到了KUBE-SVC-G3OM5DSD2HHDMN6U链进一步处理，

5. 下一步查看KUBE-SVC规则链

iptables -t nat -nvL KUBE-SVC-NKMXGPDRPTPBYCFR

第2条规则对发往Cluster IP的流量要做dst IP改写到具体的一个Endpoints上面

由于现在这种情况是一个pod对应一个service ，所以该条规则链应用概率是100%，如果出现两个pod对应一个service则会出现两条规则链，各占50%的概率，而这2条链分别对应各自endpoints的DNAT规则：

6. 下一步查看endpoints的DNAT

iptables -t nat -nvL KUBE-SEP-BEZQY5746EOCOLRD

• 第1条规则：Pod通过Service访问自身时匹配，此规则仅作标记（MARK）处理；
• 第2条规则：通过DNAT重定向到后端Pod实例上，至此，通过Service最终将流量导向到后端实例上；

简析流程如下：

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

二、 实验过程的截图，可参照此流程做链路规则分析

1. pod与service数量1-2

2. pod与service数量2-2

总结

通过改变不同pod和service数量，得到的规则数量如下表

pod数量	service数量	output链	KUBE-SERVICES	KUBE-SVC	KUBE-SEP
1	1	1	2	1	2
2	1	1	2	2	4
1	2	1	4	2	4
2	2	1	4	4	8
3	2	1	4	6	12
n	m	1	2m	nm	2nm

注意一：node节点数量的影响可以直接按node数量来做乘积。因为 k8s会把完整的iptables规则下发到每一个node

注意二：上表最下方的iptables规则数量的规律算法，仅在一般情况（参照下面的分析过程）可供参考，具体情况具体对待！