引言
Kube Proxy 是 Kubernetes 生态的核心组件之一，主要负责处理访问 Service 的流量（包括通过 Cluster IP 以及 Node Port），自动将 Client 对 Kubernetes Service 的请求代理到正确的 Pod 或 Node 后端。截止 1.18 版本，Kube Proxy 能够支持的运行模式有 4 种，其平台支持情况如下表：
| Mode | Linux | Windows |
|---|---|---|
| userspace | Y | Y |
| iptables | Y | N |
| ipvs | Y | N |
| kernelspace | N | Y |
注意：userspace 模式在实现上其实细分为 Linux 的 userspace 和 Windows 平台的 winuserspace，工作原理基本一致。之所以分两套实现，笔者以为主要是 Linux 的 userspace 实现仍部分依赖了 Linux 内核的 iptables 功能，而 Windows 平台由于没有 iptables 支持，所以使用了另外的机制（将 ClusterIP 绑定到网卡) 单独实现了一番。
userspace 模式
在 userspace 模式下，kube-proxy 通过监听 K8s apiserver 获取关于 Service 和 Endpoint 的变化信息，在内存中维护一份从ClusterIP:Port 到后端 Endpoints 的映射关系，通过反向代理的形式，将收到的数据包转发给后端，并将后端返回的应答报文转发给客户端。该模式下，kube-proxy 会为每个 Service （每种协议，每个 Service IP，每个 Service Port）在宿主机上创建一个 Socket 套接字（监听端口随机）用于接收和转发 client 的请求。默认条件下，kube-proxy 采用 round-robin 算法从后端 Endpoint 列表中选择一个响应请求。
[root@machine ~]# kubectl get svc --all-namespaces
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8d
kube-system kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 8d
[root@machine ~]# netstat -apn | grep kube-proxy
tcp6 0 0 :::39748 :::* LISTEN 21092/kube-proxy
tcp6 0 0 :::46122 :::* LISTEN 21092/kube-proxy
tcp6 0 0 :::10256 :::* LISTEN 21092/kube-proxy
tcp6 0 0 :::43892 :::* LISTEN 21092/kube-proxy
正如我们看到的，kube-proxy 会根据 Service IP（包括 CLUSTER-IP 和 EXTERNAL-IP）、协议以及端口号确定一个 Socket，在宿主机上打开一个监听端口。客户端访问 Service 的流量会被分别路由到对应的 Socket 监听端口得到处理。Service 到 Socket 的重定向路由，在 Linux 平台采用 iptables 实现（在 Windows 平台通过将 Service ClusterIP 绑定到网卡实现）。
Linux iptables 根据目的 Service 定向到指定的 Socket 监听端口的规则示意：
[root@machine ~]# iptables -t nat -S
-A KUBE-PORTALS-CONTAINER -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https" -m tcp --dport 443 -j REDIRECT --to-ports 46122
-A KUBE-PORTALS-HOST -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https" -m tcp --dport 443 -j DNAT --to-destination 192.168.137.139:46122
userspace 模式工作原理示意：
iptables 模式
在 iptables 模式下，kube-proxy 依然需要通过监听 K8s apiserver 获取关于 Service 和 Endpoint 的变化信息。不过与 userspace 模式不同的是，kube-proxy 不再为每个 Service 创建反向代理（也就是无需创建 Socket 监听），而是通过安装 iptables 规则，捕获访问 Service ClusterIP:Port 的流量，直接重定向到指定的 Endpoints 后端。默认条件下，kube-proxy 会 随机 从后端 Endpoint 列表中选择一个响应请求。ipatbles 模式与 userspace 模式的不同之处在于，数据包的转发不再通过 kube-proxy 在用户空间通过反向代理来做，而是基于 iptables/netfilter 在内核空间直接转发，避免了数据的来回拷贝，因此在性能上具有很大优势，而且也避免了大量宿主机端口被占用的问题。
但是将数据转发完全交给 iptables 来做也有个缺点，就是一旦选择的后端没有响应，连接就会直接失败了，而不会像 userspace 模式那样，反向代理可以支持自动重新选择后端重试，算是失去了一定的重试灵活性。不过，官方建议使用 Readiness 探针来解决这个问题，一旦检测到后端故障，就自动将其移出 Endpoint 列表，避免请求被代理到存在问题的后端。
[root@machine ~]# iptables -t nat -S
-A KUBE-SEP-XVJ25MO2MX75T34R -s 192.168.137.139/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-XVJ25MO2MX75T34R -p tcp -m tcp -j DNAT --to-destination 192.168.137.139:6443
-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-SVC-NPX46M4PTMTKRN6Y
-A KUBE-SERVICES -m comment --comment "kubernetes service nodeports; NOTE: this must be the last rule in this chain" -m addrtype --dst-type LOCAL -j KUBE-NODEPORTS
-A KUBE-SVC-NPX46M4PTMTKRN6Y -j KUBE-SEP-XVJ25MO2MX75T34R
正如上面 iptables 规则列出的，访问 10.96.0.1 443 端口的流量会被交由 KUBE-SVC-NPX46M4PTMTKRN6Y 处理，KUBE-SVC-NPX46M4PTMTKRN6Y 继而跳转到 KUBE-SEP-XVJ25MO2MX75T34R，最终 DNAT 到目的 Node 的 6443 端口，这正是 kubernetes apiserver 的监听地址。因此，iptables 模式下，完全通过 iptables 自身就实现了流量转发，不需要为每个 Service 打开 Socket 监听端口了。注意，这里最上边那条是 DNAT 的配对策略，DNAT 的回包需要做 UN-DNAT（即 SNAT/MASQ)。
iptables 模式工作原理示意：
ipvs 模式
在 ipvs 模式下，kube-proxy 通过监听 K8s apiserver 获取关于 Service 和 Endpoint 的变化信息，然后调用 netlink 接口创建 ipvs 规则，并周期性地同步 Kubernetes Service/Endpoint 与 ipvs 规则，保证状态匹配。当客户端请求 Service 时，ipvs 会将流量重定向到指定的后端。
ipvs 相比 iptables 的优势在于通过 hash table 实现了 O(1) 时间复杂度的规则匹配。当 Service 和 Endpoint 的数量急剧增加时，iptables 的匹配表项会变得十分庞大，而其采用的顺序匹配模式会严重影响其性能。相反，ipvs 无论在小规模集群还是大规模集群，都拥有几乎相同的性能表现，因此相比其他代理模式，能提供更高的网络吞吐量，更能满足大规模集群扩展性和高性能的需要。同时，ipvs 支持对后端的健康检查和连接重试，可靠性相比 iptables 更佳。此外，ipvs 模式还为用户提供了多种负载均衡策略以供选择，例如：
- rr: round-robin (轮询，
默认采用) - lc: least connection （最少连接数）
- dh: destination hashing （根据目的哈希）
- sh: source hashing （根据源哈希）
- sed: shortest expected delay （最小延迟）
- nq: never queue （不排队等待，有空闲 Server 直接分配给空闲 Server 处理，否则通过 sed 策略处理）
ipvs 仍然使用 iptables 实现对数据包的过滤、SNAT 或 MASQ，但使用 ipset 来存储需要执行 MASQ 或 DROP 的源地址和目的地址，从而保证在大量 Service 存在的情况下，iptables 表项数量仍能维持在常数级。
通过 ipvsadm、ipset 工具可以查看 Service ClisterIP:Port 到后端 Pod/Node 映射关系。
[root@machine ~]# iptables -t nat -S
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A KUBE-SERVICES -m set --match-set KUBE-CLUSTER-IP dst,dst -j ACCEPT
[root@machine ~]# ip addr show dev kube-ipvs0
68: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
link/ether fe:04:6f:5a:01:3e brd ff:ff:ff:ff:ff:ff
inet 10.96.0.10/32 brd 10.96.0.10 scope global kube-ipvs0
valid_lft forever preferred_lft forever
inet 10.96.0.1/32 brd 10.96.0.1 scope global kube-ipvs0
valid_lft forever preferred_lft forever
[root@machine ~]# ipset list
Name: KUBE-CLUSTER-IP
Type: hash:ip,port
Revision: 2
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16656
References: 2
Members:
10.96.0.10,tcp:53
10.96.0.10,tcp:9153
10.96.0.10,udp:53
10.96.0.1,tcp:443
[root@machine ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.96.0.1:443 rr
-> 192.168.137.139:6443 Masq 1 1 0
TCP 10.96.0.10:53 rr
-> 10.80.1.233:53 Masq 1 0 0
TCP 10.96.0.10:9153 rr
-> 10.80.1.233:9153 Masq 1 0 0
UDP 10.96.0.10:53 rr
-> 10.80.1.233:53 Masq 1 0 0
如上所示的，首先系统通过 iptables 允许访问 KUBE-CLUSTER-IP ipset 的流量进入，并通过在虚拟网卡 kube-ipvs0 上配置 VIP 的方式，告诉内核识别 VIP 为本机 IP，从而走 iptables 的 INPUT 链，继而通过 IP Virtual Server 找到 Real Server 提供服务。
注意：由于 KUBE-CLUSTER-IP 的类型为 hash:ip,port，在 --match-set KUBE-CLUSTER-IP dst,dst 匹配规则中，第一个 dst 表示将 set 中的 IP 作为目的地址，第二个 dst 表示将 set 中的 Port 作为目的端口。
ipvs 模式工作原理示意：
kernelspace 模式
kernelspace 也可以说是 winkernel 模式，因为它只应用于 Windows 平台。在 winkernel 模式下，kube-proxy 通过监听 K8s apiserver 获取关于 Service 和 Endpoint 的变化信息，然后通过 HNS (Host Network Service) 接口直接配置 Windows 内核的 LoadBalancer 以及 Endpoint ，实现基于 winkernel 的 Kubernetes Service 代理服务。
winkernel 模式相对 winuserspace 模式的改进与 iptables 模式相对 userspace 模式的改进类似，即避免了主动创建大量的 Socket 监听，也免去了频繁且低效的用户态-内核态数据拷贝，直接通过配置系统的 LoadBalancer 和 Endpoint 实现代理，性能上具有明显优势。
winkernel 模式工作原理示意：
附加：设置会话保持
在以上几种模式中，客户端对 Service ClusterIP:Port 的访问都被透明代理到合适的后端，客户端不会感知到 Kubernetes、Service 或是 Pod。默认条件下，代理后端认为每次请求都是独立的，会分别按照策略选择后端进行响应。如果你希望来自同一个客户端的请求每次都被同一个后端响应（即会话保持），可以通过设置 Kubernetes Service 的 service.spec.sessionAffinity 字段为 “ClientIP”，保证同一 Client 对 Service 的请求被定向转发到同一 Endpoint（其内部其实是通过一个 Map 结构记录了 Client 与 Endpoint 的对应关系）。同时，你还可以通过设置 service.spec.sessionAffinityConfig.clientIP.timeoutSeconds 字段定义会话保持的最长时间，默认是 3 小时。
