深入理解 Kubernetes 网络模型：自己实现 kube-proxy 的功能

本文译自 Cracking kubernetes node proxy (aka kube-proxy)。

Kubernetes 中有几种类型的代理。其中有 node proxier 或 kube-proxy，它在每个节点上反映 Kubernetes API 中定义的服务，可以跨一组后端执行简单的 TCP/UDP/SCTP 流转发 [1]。

为了更好地理解节点代理模型，在这篇文章中，我们将用不同的方法设计和实现我们自己版本的 kube-proxy; 尽管这些只是 toy-proxy，但从透明流量拦截、转发、负载均衡等方面来说，它们的工作方式与 K8S 集群中运行的普通 kube-proxy 基本相同。

通过我们的 toy-proxy 程序，非 K8S 节点（不在 K8S 集群中）上的应用程序（无论是宿主本地应用程序，还是在 VM/容器中运行的应用程序）也可以通过 ClusterIP 访问 K8S 服务 – 注意，在 kubernetes 的设计中，ClusterIP 只能在 K8S 集群节点中访问（在某种意义上，我们的 toy-proxy 程序将非 K8S 节点变成了 K8S 节点）。

背景知识

了解 Linux 内核中的流量拦截和代理需要具备以下背景知识。

Netfilter

Netfilter 是 Linux 内核内部的包过滤和处理框架。如果你不熟悉 Iptables 和 Netfilter 体系结构，请参阅 A Deep Dive into Iptables and Netfilter Architecture

一些要点：

主机上的所有数据包都将通过 netfilter 框架
在 netfilter 框架中有 5 个钩子点：PRE_ROUTING, INPUT, FORWARD, OUTPUT, POST_ROUTING
命令行工具 iptables 可用于动态地将规则插入到钩子点中
可以通过组合各种 iptables 规则来操作数据包（接受/重定向/删除/修改，等等）

The 5 hook points in netfilter framework 此外，这 5 个钩子点还可以与内核的其他网络设施，如内核路由子系统进行协同工作。

此外，在每个钩子点中，规则被组织到具有预定义优先级的不同链中。为了按目的管理链，链被进一步组织到表中。现在有 5 个表：

filter：做正常的过滤，如接受，拒绝/删，跳
nat：网络地址转换，包括 SNAT（源 nat) 和 DNAT（目的 nat)
mangle：修改包属性，例如 TTL
raw：最早的处理点，连接跟踪前的特殊处理 (conntrack 或 CT，也包含在上图中，但这不是链）
security：本文未涉及

将表/链添加到上图中，我们可以得到更详细的视图：

iptables table/chains inside hook points

VIP 与负载均衡 (LB)

虚拟 IP (IP) 将所有后端 IP 隐藏给客户端/用户，因此客户端/用户总是与 VIP 的后端服务通信，而不需要关心 VIP 后面有多少实例。

VIP 总是伴随着负载均衡，因为它需要在不同的后端之间分配流量。

VIP and load balancing

Cross-host 网络模型

主机 A 上的实例（容器、VM 等）如何与主机 B 上的另一个实例通信？有很多解决方案：

直接路由：BGP 等
隧道：VxLAN, IPIP, GRE 等
NAT：例如 docker 的桥接网络模式
其它方式

节点代理模型

在 kubernetes 中，你可以将应用程序定义为 Service。Service 是一种抽象，它定义了一组 pod 的逻辑集和访问它们的策略。

Service 类型

K8S 中定义了 4 种 Service 类型：

ClusterIP：通过 VIP 访问 Service，但该 VIP 只能在此集群内访问
NodePort：通过 NodeIP:NodePort 访问 Service，这意味着该端口将暴露在集群内的所有节点上
ExternalIP：与 ClusterIP 相同，但是这个 VIP 可以从这个集群之外访问
LoadBalancer

这篇文章将关注 ClusterIP，但是其他三种类型在流量拦截和转发方面的底层实现非常相似。

节点代理

一个 Service 有一个 VIP（本文中的 ClusterIP）和多个端点（后端 pod）。每个 pod 或节点都可以通过 VIP 直接访问应用程序。要做到这一点，节点代理程序需要在每个节点上运行，它应该能够透明地拦截到任何 ClusterIP:Port[注解 1] 的流量，并将它们重定向到一个或多个后端 pod。

Kubernetes proxier model

注解 1：

对 ClusterIP 的一个常见误解是，ClusterIP 是可访问的——它们不是通过定义访问的。如果 ping 一个 ClusterIP，可能会发现它不可访问。

根据定义，<Protocol,ClusterIP,Port> 元组独特地定义了一个服务（因此也定义了一个拦截规则）。例如，如果一个服务被定义为 <tcp,10.7.0.100,80>，那么代理只处理 tcp:10.7.0.100:80 的流量，其他流量，例如。tcp:10.7.0.100:8080, udp:10.7.0.100:80 将不会被代理。因此，也无法访问 ClusterIP（ICMP 流量）。

但是，如果你使用的是带有 IPVS 模式的 kube-proxy，那么确实可以通过 ping 访问 ClusterIP。这是因为 IPVS 模式实现比定义所需要的做得更多。你将在下面几节中看到不同之处。

节点代理的角色：反向代理

想想节点代理的作用，在 K8S 网络模型中，它实际上是一个反向代理，也就是说，在每个节点上，它将：

将所有后端 pod 隐藏到客户端
过滤所有出口流量（对后端的请求）

对于 ingress traffic，它什么也不做。

性能问题

如果我们在主机上有一个应用程序，并且在 K8S 集群中有 1K 个服务，那么我们永远无法猜测该应用程序在下一时刻将访问哪个服务（这里忽略网络策略）。因此，为了让应用程序能够访问所有服务，我们必须为节点上的所有服务应用所有代理规则。将这个想法推广到整个集群，这意味着：

所有服务的代理规则应该应用于整个集群中的所有节点。

在某种意义上，这是一个完全分布式的代理模型，因为任何节点都拥有集群的所有规则。

当集群变大时，这会导致严重的性能问题，因为每个节点上可能有数十万条规则 [6,7]。

测试环境

集群拓扑和测试环境

我们将使用以下环境进行测试：

一个 k8s 集群
- 一个 master 节点
- 一个 node 节点
- 网络解决方案：直接路由（PodIP 可直接路由）
一个非 k8s 节点，但是它可以到达工作节点和 Pod（得益于直接路由网络方案）

test env

我们将在工作节点上部署 pod，并从 test 节点通过 ClusterIP 访问 pod 中的应用程序。

创建一个 Service

创建一个简单的 Statefulset，其中包括一个 Service，该 Service 将有一个或多个后端 pod:

# see appendix for webapp.yaml
$ kubectl create -f webapp.yaml

$ kubectl get svc -o wide webapp
NAME     TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE     SELECTOR
webapp   ClusterIP   10.7.111.132   <none>        80/TCP    2m11s   app=webapp

$ kubectl get pod -o wide | grep webapp
webapp-0    2/2     Running   0    2m12s 10.5.41.204    node1    <none>  <none>

应用程序在带有 tcp 协议的 80 端口上运行。

可达性测试

首先访问 PodIP+Port:

$ curl 10.5.41.204:80
<!DOCTYPE html>
...
</html>

成功的！然后用 ClusterIP 替换 PodIP 再试一次：

$ curl 10.7.111.132:80
^C

正如所料，它是不可访问的！

在下一节中，我们将研究如何使用不同的方法使 ClusterIP 可访问。

实现：通过 userspace socket 实现 proxy

中间人模型

最容易理解的实现是在此主机上的通信路径中插入我们的 toy-proxy 作为中间人：对于从本地客户端到 ClusterIP:Port 的每个连接，我们拦截该连接并将其分割为两个单独的连接:

本地客户端和 toy-proxy 之间的连接
连接 toy-proxy 和后端 pod

实现此目的的最简单方法是在用户空间中实现它：

监听资源：启动一个守护进程，监听 K8S apiserver、监视服务 (ClusterIP) 和端点 (Pod) 的变化
代理通信：对于从本地客户端到服务 (ClusterIP) 的每个连接请求，通过充当中间人来拦截请求
动态应用代理规则：对于任何 Service/Endpoint 更新，相应地更改 toy-proxy 连接设置

对于我们上面的测试应用 webapp，数据流程如下图：

userspace-proxier

POC 实现

让我们来看看上图的概念验证实现。

代码

以下代码省略了一些错误处理代码，便于阅读：

func main() {
	clusterIP := "10.7.111.132"
	podIP := "10.5.41.204"
	port := 80
	proto := "tcp"

	addRedirectRules(clusterIP, port, proto)
	createProxy(podIP, port, proto)
}

func addRedirectRules(clusterIP string, port int, proto string) error {
	p := strconv.Itoa(port)
	cmd := exec.Command("iptables", "-t", "nat", "-A", "OUTPUT", "-p", "tcp",
		"-d", clusterIP, "--dport", p, "-j", "REDIRECT", "--to-port", p)
	return cmd.Run()
}

func createProxy(podIP string, port int, proto string) {
	host := ""
	listener, err := net.Listen(proto, net.JoinHostPort(host, strconv.Itoa(port)))

	for {
		inConn, err := listener.Accept()
		outConn, err := net.Dial(proto, net.JoinHostPort(podIP, strconv.Itoa(port)))

		go func(in, out *net.TCPConn) {
			var wg sync.WaitGroup
			wg.Add(2)
			fmt.Printf("Proxying %v <-> %v <-> %v <-> %v\n",
				in.RemoteAddr(), in.LocalAddr(), out.LocalAddr(), out.RemoteAddr())
			go copyBytes(in, out, &wg)
			go copyBytes(out, in, &wg)
			wg.Wait()
		}(inConn.(*net.TCPConn), outConn.(*net.TCPConn))
	}

	listener.Close()
}

func copyBytes(dst, src *net.TCPConn, wg *sync.WaitGroup) {
	defer wg.Done()
	if _, err := io.Copy(dst, src); err != nil {
		if !strings.HasSuffix(err.Error(), "use of closed network connection") {
			fmt.Printf("io.Copy error: %v", err)
		}
	}
	dst.Close()
	src.Close()
}

一些解释

traffic 拦截

我们想拦截所有发往 ClusterIP:Port 的流量，但是在这个节点上任何设备都没有配置ClusterIP，因此我们无法执行诸如 listen（ClusterIP，Port）之类的操作，那么我们如何才能拦截呢？答案是：使用iptables/netfilter 提供的 REDIRECT 能力。

以下命令会将所有发往 ClusterIP:Port 的流量定向到 localhost:Port：

$ sudo iptables -t nat -A OUTPUT -p tcp -d $CLUSTER_IP --dport $PORT -j REDIRECT --to-port $PORT

如果你现在不能理解这一点，不要害怕。稍后我们将讨论这个问题。

通过下面命令的输出来验证这一点：

$ iptables -t nat -L -n
...
Chain OUTPUT (policy ACCEPT)
target     prot opt source      destination
REDIRECT   tcp  --  0.0.0.0/0   10.7.111.132         tcp dpt:80 redir ports 80

在代码中，函数 addRedirectRules() 包装了上述过程。

创建 proxy

函数 createProxy() 创建用户空间代理，并执行双向转发。

可达性测试

编译代码并执行二进制文件：

$ go build toy-proxy-userspace.go
$ sudo ./toy-proxy-userspace

现在测试访问：

$ curl $CLUSTER_IP:$PORT
<!DOCTYPE html>
...
</html>

成功！我们的代理传达的信息是：

$ sudo ./toy-proxy-userspace
Creating proxy between <host ip>:53912 <-> 127.0.0.1:80 <-> <host ip>:40194 <-> 10.5.41.204:80

表示，对于原 <host ip>:53912 <-> 10.7.111.132:80 的连接请求，将其拆分为两个连接：

<host ip>:53912 <-> 127.0.0.1:80
<host ip>:40194 <-> 10.5.41.204:80

删除这条规则：

$ iptables -t nat -L -n --line-numbers
...
Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
2    REDIRECT   tcp  --  0.0.0.0/0   10.7.111.132         tcp dpt:80 redir ports 80

# iptables -t nat -D OUTPUT <num>
$ iptables -t nat -D OUTPUT 2

或者删除（刷新）所有规则，如果你把 iptabels 弄的一团糟的情况下：

$ iptables -t nat -F # delete all rules
$ iptables -t nat -X # delete all custom chains

改进

在这个 toy-proxy 实现中，我们拦截了 ClusterIP:80 到 localhost:80，但是如果该主机上的本机应用程序也想使用 localhost:80 怎么办？此外，如果多个服务都公开 80 端口会怎样？显然，我们需要区分这些应用程序或服务。解决这个问题的正确方法是：为每个代理分配一个未使用的临时端口 TmpPort，拦截 ClusterIP:Port 到 local:TmpPort。例如，app1 使用 10001, app2 使用 10002。

其次，上面的代码只处理一个后端，如果有多个后端 pod 怎么办？因此，我们需要通过负载均衡算法将请求分发到不同的后端 pod。

userspace-proxier-2

优缺点

这种方法非常容易理解和实现，但是，它的性能会很差，因为它必须在两端以及内核和用户空间内存之间复制字节。

我们没有在这上面花太多时间，如果你感兴趣，可以在这里查看用户空间 kube-proxy 的简单实现。

接下来，让我们看看实现这个任务的另一种方法。

实现：通过 iptables 实现 proxy

用户空间代理程序的主要瓶颈来自内核-用户空间切换和数据复制。如果我们可以完全在内核空间中实现代理，它将在性能上大大提高，从而击败用户空间的代理。iptables 可用于实现这一目标。

在开始之前，让我们首先弄清楚在执行 curl ClusterIP:Port 时的流量路径，然后研究如何使用 iptables 规则使其可访问。

Host -> ClusterIP（单一后端）

ClusterIP 不存在于任何网络设备上，所以为了让我们的数据包最终到达后端 Pod，我们需要将 ClusterIP 转换为 PodIP（可路由），即：

条件：匹配 dst=ClusterIP,proto=tcp,dport=80 的数据包
操作：将数据包的 IP 报头中的 dst=ClusterIP 替换为 dst=PodIP

用网络术语来说，这是一个网络地址转换 (NAT) 过程。

在哪里做 DNAT

通过 curl 查看出口数据包路径（下图展示了数据流向过程）：

host-to-clusterip-dnat

<curl process> -> raw -> CT -> mangle -> dnat -> filter -> security -> snat -> <ROUTING> -> mangle -> snat -> NIC

很明显，在 OUTPUT 钩中只有一个 dnat（链），我们可以在其中进行 DNAT。

让我们看看我们将如何进行黑客入侵。

检查当前的 NAT 规则

NAT 规则被组织到 nat 表中。检查 nat 表中的当前规则：

# -t <table>
# -L list rules
# -n numeric output
$ iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)

Chain INPUT (policy ACCEPT)

Chain OUTPUT (policy ACCEPT)
DOCKER     all  --  0.0.0.0/0    !127.0.0.0/8   ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)

输出显示除了与 DOCKER 相关的规则外，没有其他规则。这些 DOCKER 规则是 DOCKER 在安装时插入的，但它们不会影响我们在这篇文章中的实验。所以我们忽略它们。

增加 DNAT 规则

为了便于查看，我们不会用 go 代码包装 iptables 命令，而是直接显示命令本身。

注意：在继续之前，请确保删除了在上一节中添加的所有规则。

确认目前无法访问 ClusterIP：

$ curl $CLUSTER_IP:$PORT
^C

现在添加我们的出口 NAT 规则：

$ cat ENV
CLUSTER_IP=10.7.111.132
POD_IP=10.5.41.204
PORT=80
PROTO=tcp

# -p               <protocol>
# -A               add rule
# --dport          <dst port>
# -d               <dst ip>
# -j               jump to
# --to-destination <ip>:<port>
$ iptables -t nat -A OUTPUT -p $PROTO --dport $PORT -d $CLUSTER_IP -j DNAT --to-destination $POD_IP:$PORT

再次检查规则表：

$ iptables -t nat -L -n

Chain OUTPUT (policy ACCEPT)
target     prot opt source      destination
DNAT       tcp  --  0.0.0.0/0   10.7.111.132   tcp dpt:80 to:10.5.41.204:80

我们可以看到规则已经被添加。

测试可达性

现在再一次访问：

$ curl $CLUSTER_IP:$PORT
<!DOCTYPE html>
...
</html>

就是这样！访问成功。

但是等等！我们期望出口的交通应该是正确的，但我们没有添加任何 NAT 规则的入口路径，怎么可能交通是正常的两个方向？事实证明，当你为一个方向添加一个 NAT 规则时，Linux 内核会自动为另一个方向添加保留规则！这与 conntrack (CT，连接跟踪）模块协同工作。

host-to-clusterip-dnat-ct

清理

删除这些规则：

$ iptables -t nat -L -n --line-numbers
...
Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
2    DNAT       tcp  --  0.0.0.0/0   10.7.111.132   tcp dpt:80 to:10.5.41.204:80

# iptables -t <table> -D <chain> <num>
$ iptables -t nat -D OUTPUT 2

Host -> ClusterIP （多个后端）

在上一节中，我们展示了如何使用一个后端 Pod 执行 NAT。现在让我们看看多后端情况。

注意：在继续之前，请确保删除了在上一节中添加的所有规则。

伸缩 webapp

首先扩大我们的服务到 2 个后端 pod:

$ kubectl scale sts webapp --replicas=2
statefulset.apps/webapp scaled

$ kubectl get pod -o wide | grep webapp
webapp-0   2/2     Running   0   1h24m   10.5.41.204    node1    <none> <none>
webapp-1   2/2     Running   0   11s     10.5.41.5      node1    <none> <none>

通过负载平衡添加 DNAT 规则

我们需要 iptables 中的 statistic 模块以概率的方式将请求分发到后端 pod，这样才能达到负载均衡的效果：

# -m <module>
$ iptables -t nat -A OUTPUT -p $PROTO --dport $PORT -d $CLUSTER_IP \
    -m statistic --mode random --probability 0.5  \
    -j DNAT --to-destination $POD1_IP:$PORT
$ iptables -t nat -A OUTPUT -p $PROTO --dport $PORT -d $CLUSTER_IP \
    -m statistic --mode random --probability 1.0  \
    -j DNAT --to-destination $POD2_IP:$PORT

上面的命令指定在两个 pod 之间随机分配请求，每个都有 50% 的概率。

现在检查这些规则：

$ iptables -t nat -L -n
...
Chain OUTPUT (policy ACCEPT)
target  prot opt source      destination
DNAT    tcp  --  0.0.0.0/0   10.7.111.132  tcp dpt:80 statistic mode random probability 0.50000000000 to:10.5.41.204:80
DNAT    tcp  --  0.0.0.0/0   10.7.111.132  tcp dpt:80 statistic mode random probability 1.00000000000 to:10.5.41.5:80

host-to-clusterip-lb-ct

验证

现在，我们来验证下负载均衡是否生效。我们发出 8 个请求，并捕获到这个主机通信的真实 PodIPs:

在测试节点上打开一个 shell:

$ for i in {1..8}; do curl $CLUSTER_IP:$PORT 2>&1 >/dev/null; sleep 1; done

测试节点上的另一个 shell 窗口：

$ tcpdump -nn -i eth0 port $PORT | grep "GET /"
10.21.0.7.48306 > 10.5.41.5.80:   ... HTTP: GET / HTTP/1.1
10.21.0.7.48308 > 10.5.41.204.80: ... HTTP: GET / HTTP/1.1
10.21.0.7.48310 > 10.5.41.204.80: ... HTTP: GET / HTTP/1.1
10.21.0.7.48312 > 10.5.41.5.80:   ... HTTP: GET / HTTP/1.1
10.21.0.7.48314 > 10.5.41.5.80:   ... HTTP: GET / HTTP/1.1
10.21.0.7.48316 > 10.5.41.204.80: ... HTTP: GET / HTTP/1.1
10.21.0.7.48318 > 10.5.41.5.80:   ... HTTP: GET / HTTP/1.1
10.21.0.7.48320 > 10.5.41.204.80: ... HTTP: GET / HTTP/1.1

在 Pod1 中有 4 次，在 Pod2 中有 4 次，每个 pod 有 50%，这正是我们所期望的。

清理

$ iptables -t nat -L -n --line-numbers
...
Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
2    DNAT    tcp  --  0.0.0.0/0   10.7.111.132  tcp dpt:80 statistic mode random probability 0.50000000000 to:10.5.41.204:80
3    DNAT    tcp  --  0.0.0.0/0   10.7.111.132  tcp dpt:80 statistic mode random probability 1.00000000000 to:10.5.41.5:80

$ iptables -t nat -D OUTPUT 2
$ iptables -t nat -D OUTPUT 3

Pod (app A) -> ClusterIP (app B)

如果想通过 hostA 上的 Pod A 通过 ClusterIP 访问 Pod B，B 的 Pod 驻留在 hostB 上，我们应该做什么？

实际上，这与 Host -> ClusterIP 情况非常相似，但是有一点需要注意：在执行 NAT 之后，源节点 (hostA) 需要将包发送到目的地 Pod 所在的正确目的地节点 (hostB)。根据不同的跨主机网络解决方案，这有很大不同：

对于直接路由的情况下，主机只是发送数据包。对应的有这些解决方案：
- calico + bird
- cilium + kube-router（Cilium BGP 的默认解决方案）
- cilium + bird（实际上这只是我们的测试环境网络解决方案）
对于隧道的情况，每个主机上必须有一个代理，它在 DNAT 之后执行 encap，在 SNAT 之前执行 decap。这些解决方案包括：
- calico + VxLAN 模式
- flannel + IPIP 模式
- flannel + VxLAN 模式
- cilium + VxLAN 模式
像 aws 的 ENI 模式：类似于直接路由，但不需要 BGP 代理
- cilium + ENI 模式

下图展示了隧道的情况：

tunneling

代理与隧道相关的职责包括：

同步所有节点之间的隧道信息，例如描述哪个实例在哪个节点上的信息
在 DNAT 之后对 pod 流量执行封装：对于所有的出口流量，例如来自 hostA 的 dst=<PodIP>，其中 PodIP 在 hostB 上，通过添加另一个头来封装数据包，例如 VxLAN 头，其中封装头有 src=hostA_IP,dst=hostB_IP
在 SNAT 之前对 Pod 流量执行解封装：解封装每个入口封装的数据包：删除外层（例如 VxLAN 标头）

同时，主机需要决定：

哪些数据包应该交给解码器（pod 流量），哪些不应该（例如主机流量）
哪些包应该封装（pod 流量），哪些不应该（例如主机流量）

重新构造 iptables 规则

注意：在继续之前，请确保删除了在上一节中添加的所有规则。

当你有大量的 Service 时，每个节点上的 iptables 规则将相当复杂，因此你需要进行一些结构化工作来组织这些规则。

在本节中，我们将在 nat 表中创建几个专用的 iptables 链，具体如下：

链 KUBE-SERVICES：拦截 nat 表的输出链中所有到此链的出口流量，如果它们被指定为 ClusterIP，则执行 DNAT
链 KUBE-SVC-WEBAPP：如果 dst、proto 和 port 匹配，则拦截该链 KUBE-SERVICES 中的所有流量
链 KUBE-SEP-WEBAPP1：拦截 50% 的流量在 KUBE-SVC-WEBAPP 到这里
链 KUBE-SEP-WEBAPP2：拦截 50% 的流量在 KUBE-SVC-WEBAPP 到这里

DNAT 路径现在为：

OUTPUT -> KUBE-SERVICES -> KUBE-SVC-WEBAPP --> KUBE-SEP-WEBAPP1
                                         \
                                          \--> KUBE-SEP-WEBAPP2

如果你有多个 Service，DNAT 路径如下：

OUTPUT -> KUBE-SERVICES -> KUBE-SVC-A --> KUBE-SEP-A1
                      |              \--> KUBE-SEP-A2
                      |
                      |--> KUBE-SVC-B --> KUBE-SEP-B1
                      |              \--> KUBE-SEP-B2
                      |
                      |--> KUBE-SVC-C --> KUBE-SEP-C1
                                     \--> KUBE-SEP-C2

iptables 命令：

$ cat add-dnat-structured.sh
source ../ENV

set -x

KUBE_SVCS="KUBE-SERVICES"        # chain that serves as kubernetes service portal
SVC_WEBAPP="KUBE-SVC-WEBAPP"     # chain that serves as DNAT entrypoint for webapp
WEBAPP_EP1="KUBE-SEP-WEBAPP1"    # chain that performs dnat to pod1
WEBAPP_EP2="KUBE-SEP-WEBAPP2"    # chain that performs dnat to pod2

# OUTPUT -> KUBE-SERVICES
sudo iptables -t nat -N $KUBE_SVCS
sudo iptables -t nat -A OUTPUT -p all -s 0.0.0.0/0 -d 0.0.0.0/0 -j $KUBE_SVCS

# KUBE-SERVICES -> KUBE-SVC-WEBAPP
sudo iptables -t nat -N $SVC_WEBAPP
sudo iptables -t nat -A $KUBE_SVCS -p $PROTO -s 0.0.0.0/0 -d $CLUSTER_IP --dport $PORT -j $SVC_WEBAPP

# KUBE-SVC-WEBAPP -> KUBE-SEP-WEBAPP*
sudo iptables -t nat -N $WEBAPP_EP1
sudo iptables -t nat -N $WEBAPP_EP2
sudo iptables -t nat -A $WEBAPP_EP1 -p $PROTO -s 0.0.0.0/0 -d 0.0.0.0/0 --dport $PORT -j DNAT --to-destination $POD1_IP:$PORT
sudo iptables -t nat -A $WEBAPP_EP2 -p $PROTO -s 0.0.0.0/0 -d 0.0.0.0/0 --dport $PORT -j DNAT --to-destination $POD2_IP:$PORT
sudo iptables -t nat -A $SVC_WEBAPP -p $PROTO -s 0.0.0.0/0 -d 0.0.0.0/0 -m statistic --mode random --probability 0.5  -j $WEBAPP_EP1
sudo iptables -t nat -A $SVC_WEBAPP -p $PROTO -s 0.0.0.0/0 -d 0.0.0.0/0 -m statistic --mode random --probability 1.0  -j $WEBAPP_EP2

现在测试我们设计：

$ ./add-dnat-structured.sh
++ KUBE_SVCS=KUBE-SERVICES
++ SVC_WEBAPP=KUBE-SVC-WEBAPP
++ WEBAPP_EP1=KUBE-SEP-WEBAPP1
++ WEBAPP_EP2=KUBE-SEP-WEBAPP2
++ sudo iptables -t nat -N KUBE-SERVICES
++ sudo iptables -t nat -A OUTPUT -p all -s 0.0.0.0/0 -d 0.0.0.0/0 -j KUBE-SERVICES
++ sudo iptables -t nat -N KUBE-SVC-WEBAPP
++ sudo iptables -t nat -A KUBE-SERVICES -p tcp -s 0.0.0.0/0 -d 10.7.111.132 --dport 80 -j KUBE-SVC-WEBAPP
++ sudo iptables -t nat -N KUBE-SEP-WEBAPP1
++ sudo iptables -t nat -N KUBE-SEP-WEBAPP2
++ sudo iptables -t nat -A KUBE-SEP-WEBAPP1 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 80 -j DNAT --to-destination 10.5.41.204:80
++ sudo iptables -t nat -A KUBE-SEP-WEBAPP2 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 80 -j DNAT --to-destination 10.5.41.5:80
++ sudo iptables -t nat -A KUBE-SVC-WEBAPP -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 -m statistic --mode random --probability 0.5 -j KUBE-SEP-WEBAPP1
++ sudo iptables -t nat -A KUBE-SVC-WEBAPP -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 -m statistic --mode random --probability 1.0 -j KUBE-SEP-WEBAPP2

检查这些规则：

$ sudo iptables -t nat -L -n
...
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  0.0.0.0/0            0.0.0.0/0

Chain KUBE-SEP-WEBAPP1 (1 references)
target     prot opt source               destination
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 to:10.5.41.204:80

Chain KUBE-SEP-WEBAPP2 (1 references)
target     prot opt source               destination
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 to:10.5.41.5:80

Chain KUBE-SERVICES (1 references)
target     prot opt source               destination
KUBE-SVC-WEBAPP  tcp  --  0.0.0.0/0            10.7.111.132         tcp dpt:80

Chain KUBE-SVC-WEBAPP (1 references)
target     prot opt source               destination
KUBE-SEP-WEBAPP1  tcp  --  0.0.0.0/0            0.0.0.0/0            statistic mode random probability 0.50000000000
KUBE-SEP-WEBAPP2  tcp  --  0.0.0.0/0            0.0.0.0/0            statistic mode random probability 1.00000000000

$ curl $CLUSTER_IP:$PORT
<!DOCTYPE html>
...
</html>

成功！

如果你将上面的输出与普通的 kube-proxy 规则进行比较，这两个规则是非常相似的，下面是从启用 kube-proxy 的节点提取的：

Chain OUTPUT (policy ACCEPT)
target         prot opt source               destination
KUBE-SERVICES  all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes service portals */

Chain KUBE-SERVICES (2 references)
target                     prot opt source               destination
KUBE-SVC-YK2SNH4V42VSDWIJ  tcp  --  0.0.0.0/0            10.7.22.18           /* default/nginx:web cluster IP */ tcp dpt:80

Chain KUBE-SVC-YK2SNH4V42VSDWIJ (1 references)
target                     prot opt source               destination
KUBE-SEP-GL2BLSI2B4ICU6WH  all  --  0.0.0.0/0            0.0.0.0/0            /* default/nginx:web */ statistic mode random probability 0.33332999982
KUBE-SEP-AIRRSG3CIF42U3PX  all  --  0.0.0.0/0            0.0.0.0/0            /* default/nginx:web */

Chain KUBE-SEP-GL2BLSI2B4ICU6WH (1 references)
target          prot opt source               destination
DNAT            tcp  --  0.0.0.0/0            0.0.0.0/0            /* default/nginx:web */ tcp to:10.244.3.181:80

Chain KUBE-SEP-AIRRSG3CIF42U3PX (1 references)
target          prot opt source               destination
DNAT            tcp  --  0.0.0.0/0            0.0.0.0/0            /* default/nginx:web */ tcp to:10.244.3.182:80

进一步重新构造 iptables 规则

TODO：为来自集群外部的流量添加规则。

实现：通过 ipvs 实现 proxy

虽然基于 iptables 的代理在性能上优于基于用户空间的代理，但在集群服务过多的情况下也会导致性能严重下降 [6,7]。

本质上，这是因为 iptables 判决是基于链的，它是一个复杂度为 O(n) 的线性算法。iptables 的一个好的替代方案是 IPVS——内核中的 L4 负载均衡器，它在底层使用 ipset（哈希实现），因此复杂度为 O(1)。

让我们看看如何使用 ipvs 实现相同的目标。

注意：在继续之前，请确保删除了在上一节中添加的所有规则。

安装 IPVS

$ yum install -y ipvsadm

# -l  list load balancing status
# -n  numeric output
$ ipvsadm -ln
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

默认无规则

增加虚拟/真正的 services

使用 ipvs 实现负载均衡：

# -A/--add-service           add service
# -t/--tcp-service <address> VIP + Port
# -s <method>                scheduling-method
# -r/--real-server <address> real backend IP + Port
# -m                         masquerading (NAT)
$ ipvsadm -A -t $CLUSTER_IP:$PORT -s rr
$ ipvsadm -a -t $CLUSTER_IP:$PORT -r $POD1_IP -m
$ ipvsadm -a -t $CLUSTER_IP:$PORT -r $POD2_IP -m

或者使用我的脚本：

$ ./ipvs-add-server.sh
Adding virtual server CLUSTER_IP:PORT=10.7.111.132:80 ...
Adding real servers ...
10.7.111.132:80 -> 10.5.41.204
10.7.111.132:80 -> 10.5.41.5
Done

再次检查状态：

$ ipvsadm -ln
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.7.111.132:80 rr
  -> 10.5.41.5:80                 Masq    1      0          0
  -> 10.5.41.204:80               Masq    1      0          0

一些解释：

对于所有发往 10.7.111.132:80 的流量，将负载均衡到 10.5.41.5:80 和 10.5.41.204:80
使用轮询 (rr) 算法实现负载均衡
两个后端，每个后端的权重为 1（各 50％）
使用 MASQ（增强型 SNAT）在 VIP 和 RealIP 之间进行流量转发

验证

$ for i in {1..8}; do curl $CLUSTER_IP:$PORT 2>&1 >/dev/null; sleep 1; done

$ tcpdump -nn -i eth0 port $PORT | grep "HTTP: GET"
IP 10.21.0.7.49556 > 10.5.41.204.80: ... HTTP: GET / HTTP/1.1
IP 10.21.0.7.49558 > 10.5.41.5.80  : ... HTTP: GET / HTTP/1.1
IP 10.21.0.7.49560 > 10.5.41.204.80: ... HTTP: GET / HTTP/1.1
IP 10.21.0.7.49562 > 10.5.41.5.80  : ... HTTP: GET / HTTP/1.1
IP 10.21.0.7.49566 > 10.5.41.204.80: ... HTTP: GET / HTTP/1.1
IP 10.21.0.7.49568 > 10.5.41.5.80  : ... HTTP: GET / HTTP/1.1
IP 10.21.0.7.49570 > 10.5.41.204.80: ... HTTP: GET / HTTP/1.1
IP 10.21.0.7.49572 > 10.5.41.5.80  : ... HTTP: GET / HTTP/1.1

完美！

清理

$ ./ipvs-del-server.sh
Deleting real servers ...
10.7.111.132:80 -> 10.5.41.204
10.7.111.132:80 -> 10.5.41.5
Deleting virtual server CLUSTER_IP:PORT=10.7.111.132:80 ...
Done

实现：通过 bpf 实现 proxy

这也是一个 O(1) 代理，但是与 IPVS 相比具有更高的性能。

让我们看看如何在不到 100 行 C 代码中使用 eBPF 实现代理功能。

先决条件

如果你有足够的时间和兴趣来阅读 eBPF/BPF，可以考虑阅读 Cilium: BPF and XDP Reference Guide，它对开发人员来说是一个完美的 BPF 文档。

实现

让我们看看出口部分的基本概念：

对于所有流量，匹配 dst=CLUSTER_IP && proto==TCP && dport==80
更改目标 IP：CLUSTER_IP -> POD_IP
更新 IP 和 TCP 报头中的校验和文件（否则我们的数据包将被丢弃）

__section("egress")
int tc_egress(struct __sk_buff *skb)
{
    const __be32 cluster_ip = 0x846F070A; // 10.7.111.132
    const __be32 pod_ip = 0x0529050A;     // 10.5.41.5

    const int l3_off = ETH_HLEN;    // IP header offset
    const int l4_off = l3_off + 20; // TCP header offset: l3_off + sizeof(struct iphdr)
    __be32 sum;                     // IP checksum

    void *data = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;
    if (data_end < data + l4_off) { // not our packet
        return TC_ACT_OK;
    }

    struct iphdr *ip4 = (struct iphdr *)(data + l3_off);
    if (ip4->daddr != cluster_ip || ip4->protocol != IPPROTO_TCP /* || tcp->dport == 80 */) {
        return TC_ACT_OK;
    }

    // DNAT: cluster_ip -> pod_ip, then update L3 and L4 checksum
    sum = csum_diff((void *)&ip4->daddr, 4, (void *)&pod_ip, 4, 0);
    skb_store_bytes(skb, l3_off + offsetof(struct iphdr, daddr), (void *)&pod_ip, 4, 0);
    l3_csum_replace(skb, l3_off + offsetof(struct iphdr, check), 0, sum, 0);
	l4_csum_replace(skb, l4_off + offsetof(struct tcphdr, check), 0, sum, BPF_F_PSEUDO_HDR);

    return TC_ACT_OK;
}

对于入口部分，非常类似于出口代码：

__section("ingress")
int tc_ingress(struct __sk_buff *skb)
{
    const __be32 cluster_ip = 0x846F070A; // 10.7.111.132
    const __be32 pod_ip = 0x0529050A;     // 10.5.41.5

    const int l3_off = ETH_HLEN;    // IP header offset
    const int l4_off = l3_off + 20; // TCP header offset: l3_off + sizeof(struct iphdr)
    __be32 sum;                     // IP checksum

    void *data = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;
    if (data_end < data + l4_off) { // not our packet
        return TC_ACT_OK;
    }

    struct iphdr *ip4 = (struct iphdr *)(data + l3_off);
    if (ip4->saddr != pod_ip || ip4->protocol != IPPROTO_TCP /* || tcp->dport == 80 */) {
        return TC_ACT_OK;
    }

    // SNAT: pod_ip -> cluster_ip, then update L3 and L4 header
    sum = csum_diff((void *)&ip4->saddr, 4, (void *)&cluster_ip, 4, 0);
    skb_store_bytes(skb, l3_off + offsetof(struct iphdr, saddr), (void *)&cluster_ip, 4, 0);
    l3_csum_replace(skb, l3_off + offsetof(struct iphdr, check), 0, sum, 0);
	l4_csum_replace(skb, l4_off + offsetof(struct tcphdr, check), 0, sum, BPF_F_PSEUDO_HDR);

    return TC_ACT_OK;
}

char __license[] __section("license") = "GPL";

编译并加载到内核中

现在使用我的小脚本编译和加载到内核：

$ ./compile-and-load.sh
...
++ sudo tc filter show dev eth0 egress
filter protocol all pref 49152 bpf chain 0
filter protocol all pref 49152 bpf chain 0 handle 0x1 toy-proxy-bpf.o:[egress] direct-action not_in_hw id 18 tag f5f39a21730006aa jited

++ sudo tc filter show dev eth0 ingress
filter protocol all pref 49152 bpf chain 0
filter protocol all pref 49152 bpf chain 0 handle 0x1 toy-proxy-bpf.o:[ingress] direct-action not_in_hw id 19 tag b41159c5873bcbc9 jited

脚本是这样的：

$ cat compile-and-load.sh
set -x

NIC=eth0

# compile c code into bpf code
clang -O2 -Wall -c toy-proxy-bpf.c -target bpf -o toy-proxy-bpf.o

# add tc queuing discipline (egress and ingress buffer)
sudo tc qdisc del dev $NIC clsact 2>&1 >/dev/null
sudo tc qdisc add dev $NIC clsact

# load bpf code into the tc egress and ingress hook respectively
sudo tc filter add dev $NIC egress bpf da obj toy-proxy-bpf.o sec egress
sudo tc filter add dev $NIC ingress bpf da obj toy-proxy-bpf.o sec ingress

# show info
sudo tc filter show dev $NIC egress
sudo tc filter show dev $NIC ingress

验证

$ curl $CLUSTER_IP:$PORT
<!DOCTYPE html>
...
</html>

完美！

清理

$ sudo tc qdisc del dev $NIC clsact 2>&1 >/dev/null

总结

在这篇文章中，我们用不同的方法手工实现了 kube-proxy 的核心功能。希望你现在对 kubernetes 节点代理有了更好的理解，以及关于网络的其他一些配置。

在这篇文章中使用的代码和脚本：这里。

参考文献

附录

webapp.yaml:

apiVersion: v1
kind: Service
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  ports:
  - port: 80
    name: web
  selector:
    app: webapp
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: webapp
spec:
  serviceName: "webapp"
  replicas: 1
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      # affinity:
      #   nodeAffinity:
      #     requiredDuringSchedulingIgnoredDuringExecution:
      #       nodeSelectorTerms:
      #       - matchExpressions:
      #         - key: kubernetes.io/hostname
      #           operator: In
      #           values:
      #           - node1
      tolerations:
      - effect: NoSchedule
        key: smoke
        operator: Equal
        value: test
      containers:
      - name: webapp
        image: nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web