kubernetes高级面试：kube-proxy ipvs模式下，还啥还需要iptables

这个面试题，主要是针对一些高级运维工程师，一般情况下只有在大集群里面才会使用到ipvs替换iptables，但这里的替换并不完整。为了说清楚这个问题，我们先看一下传统的 lvs 的NAT模式。

(1). 当用户请求到达 Director Server，此时请求的数据报文会先到内核空间的 PREROUTING 链。 此时报文的源 IP 为 CIP，目标 IP 为 VIP
(2). PREROUTING 检查发现数据包的目标 IP 是本机IP，将数据包送至 INPUT 链
(3). IPVS 比对数据包请求的服务是否为集群服务，若是，修改数据包的目标 IP 地址为后端服务器 IP，然后将数据包发至 POSTROUTING 链。 此时报文的源 IP 为 CIP，目标 IP 为 RIP
(4). POSTROUTING 链通过选路，将数据包发送给 Real Server
(5). Real Server 发现目标地址为自己的 IP，开始构建响应报文发回给 Director Server。 此时报文的源 IP 为 RIP，目标 IP 为 CIP
(6). Director Server 在响应客户端前，此时会将源 IP 地址修改为自己的 VIP 地址，然后响应给客户端。 此时报文的源 IP 为 VIP，目标 IP 为 CIP

在第6步的时候，隐含了一个前提条件就是，Real Server必须将自己的网关设置成 Director Server，否者数据回包的时候根本不会经过 Director Server 。为了解决这个问题，部分公司增强了 lvs NAT模式，在第 4 步的时候加上了 SNAT，将源IP 地址改成 Director Server ，这样数据包就可以正常回到 Director Server 了，既做 DNAT 也做 SNAT 这种模式被称为full NAT。但开源了lvs 是没有实现的。

回到正题，k8s里面不可能将所有Pod的网关都设置成唯一固定的ipvs地址，所以kube-proxy 使用iptables就是为了弥补这个SNAT，执行SNAT操作，这样Pod就可以正常回包了。除此之外，如果用户使用了network policy，也是需要通过iptables的 filter 包过滤功能，Drop掉某些访问流量。

总结起来，使用iptables主要是支持service 时候执行 SNAT 以及支持 network policy.