Kubernetes 中反向代理的实现

K8S 集群节点实现服务反向代理的方法，目前主要有三种，即 userspace、iptables 以及 ipvs。

横向来看，节点上的网络环境，被分割成不同的网络命名空间，包括主机网络命名空间和 Pod 网络命名空间；纵向来看，每个网络命名空间包括完整的网络栈，从应用到协议栈，再到网络设备。在网络设备这一层，我们通过 cni0 虚拟网桥，组建出系统内部的一个虚拟局域网。Pod 网络通过 veth 对连接到这个虚拟局域网内。cni0 虚拟局域网通过主机路由以及网口 eth0 与外部通信。在网络协议栈这一层，我们可以通过编程 netfilter 过滤器框架，来实现集群节点的反向代理。

实现反向代理，归根结底，就是做 DNAT，即把发送给集群服务 IP 和端口的数据包，修改成发给具体容器组的 IP 和端口。参考 netfilter 过滤器框架的图，我们知道，在 netfilter 里，可以通过在 PREROUTING，OUTPUT 以及 POSTROUGING 三个位置加入 NAT 规则，来改变数据包的源地址或目的地址。

因为这里需要做的是 DNAT，即改变目的地址，这样的修改，必须在路由（ROUTING）之前发生以保证数据包可以被路由正确处理，所以实现反向代理的规则，需要被加到 PREROUTING 和 OUTPUT 两个位置。

其中，PREOURTING 的规则，用来处理从 Pod 访问服务的流量。数据包从 Pod 网络 veth 发送到 cni0 之后，进入主机协议栈，首先会经过 netfilter PREROUTING 来做处理，所以发给服务的数据包，会在这个位置做 DNAT。经过 DNAT 处理之后，数据包的目的地址变成另外一个 Pod 的地址，从而经过主机路由，转发到 eth0，发送给正确的集群节点。

而添加在 OUTPUT 这个位置的 DNAT 规则，则用来处理从主机网络发给服务的数据包，原理也是类似，即经过路由之前，修改目的地址，以方便路由转发。

netfilter

为了实现管道和过滤功能两者的解耦，netfilter 用了表这个概念。表就是 netfilter 的过滤中心，其核心功能是过滤方式的分类（表），以及每种过滤方式中，过滤规则的组织（链）。

把过滤功能和管道解耦之后，所有对数据包的处理，都变成了对表的配置。而管道上的 5 个切口，仅仅变成了流量的出入口，负责把流量发送到过滤中心，并把处理之后的流量沿着管道继续传送下去。

在表中，netfilter 把规则组织成为链。表中有针对每个管道切口的默认链，也有我们自己加入的自定义链。默认链是数据的入口，默认链可以通过跳转到自定义链来完成一些复杂的功能。这里允许增加自定义链的好处是显然的。为了完成一个复杂过滤功能，比如实现 K8S 集群节点的反向代理，我们可以使用自定义链来模块化我们规则。

自定义链

集群服务的反向代理，实际上就是利用自定义链，模块化地实现了数据包的 DNAT 转换。KUBE-SERVICE 是整个反向代理的入口链，其对应所有服务的总入口；KUBE-SVC-XXXX 链是具体某一个服务的入口链，KUBE-SERVICE 链会根据服务 IP，跳转到具体服务的 KUBE-SVC-XXXX 链；而 KUBE-SEP-XXXX 链代表着某一个具体 Pod 的地址和端口，即 endpoint，具体服务链 KUBE-SVC-XXXX 会以一定的负载均衡算法，跳转到 endpoint 链。