kube-proxy

四层与七层

1、四层负载均衡(例如nginx中直接配置stream,如下)

stream {
	upstream k3s {
		least_conn;
		server 10.0.2.0:6443  max_fails=3 fail_timeout=5s;
		server 10.0.2.6:6443  max_fails=3 fail_timeout=5s;
	}
	server {
	   listen 6443;
	   proxy_pass k3s;
	}
}

0、负载均衡器用 ip+port 接收请求，再直接转发到后端对应服务上
1、四层负载均衡仅能转发TCP/IP协议、UDP协议、通常用来转发端口，如：tcp/22、udp/53；
2、四层负载均衡可以用来解决七层负载均衡端口限制问题；（七层负载均衡最大使用65535个端口号）
3、四层负载均衡可以解决七层负载均衡高可用问题；（多台后端七层负载均衡能同事的使用）
4、四层的转发效率比七层的高得多，但仅支持tcp/ip协议，不支持http和https协议；
5、通常大并发场景通常会选择使用在七层负载前面增加四层负载均衡。

2、七层负载均衡(例如nginx中配置location,然后proxy_pass http://xxx)

能写更多的转发规则
负载均衡器根据虚拟的 url 或主机名来接收请求，经过处理后再转向相应的后端服务上；
七层负载均衡需要建立两次 TCP 连接，
client 到 LB，LB根据消息中的内容( 比如 URL 或者 cookie 中的信息 )来做出负载均衡的决定；
然后，建立 LB 到 server 的连接。
负载均衡设备需要先代理最终的服务器和客户端建立 TCP 连接后，才可能接收到客户端发送的真正应用层内容的报文，
然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
具有七层负载均衡功能的设备通常也被称为反向代理服务器。

K8s 的内部服务发现是基于 DNS 解析实现的，
默认解析到一个稳定虚拟 IP （Service），该虚拟 IP 再通过 kube_proxy 将流量均衡到后端 Pods 上。
（ Pod 的 IP 可能会随着 Pod 的重建而变动，但 Service 的 IP 是稳定的）
kube-proxy 是 k8s 原生组件，主要通过 NodePort 方式暴露服务。
NodePort 方式是什么呢？
k8s 能保证在任意 Pod 挂掉时自动启动一个新的，甚至是动态扩容，这就意味着 Pod IP 是会动态变化的；
因此这个 Pod IP 你不适合暴露出去，
而 Service 可以以标签的形式选定一组带有指定标签的 Pod，并监控和自动负载这些 Pod IP；
因此对外只暴露 Service IP 就行了；
这就是 NodePort 模式，即在每个节点 node 上起一个端口，然后转发到内部 Pod IP 上。
上面提到的这个稳定虚拟 IP 就是一个 ClusterIP 类型的 Service，
这个 Service 会根据 kube-proxy 的代理模式的不同，有不同的性能表现：

1、userspace 模式

v1.0及之前版本的默认模式；
在 userspace 模式下，service 的请求会先从用户空间进入内核 iptables，然后再回到用户空间，
由 kube-proxy 完成后端 Endpoints 的选择和代理工作，这样流量从用户空间进出内核带来的性能损耗是不可接受的。

请求到达 iptables 时会进入内核，而 kube-proxy 监听是在用户态,
这样请求就形成了从用户态到内核态再返回到用户态的传递过程, 降低了服务性能。

因此，userspace 性能差。

2、iptables 模式

v1.1 版本中开始增加了 iptables mode，并在 v1.2 版本中正式取代 userspace 成为默认模式；

通过 Iptables 实现一个四层 TCP NAT ；
kube_proxy 只负责创建 iptables 的 nat 规则，不负责流量转发。

这种基于 iptables 的负载均衡，虽然操作起来比较简单，但是当集群规模大导致 iptables rules 多起来的时候，
这种基于 iptables 的负载均衡的性能就比较差了。

当添加一个 service 的时候，
iptables 命令行工具需要从内核中读取当前所有的 service 列表，
然后编辑列表，
最后再将新的列表传入内核。
假如要添加 N 个 service，复杂度为 O(N^2) 。

在转发面上，
所有 service ip 地址组成了一个 list，
每一个报文都需要查找这个 list，命中后才能执行规则。
假如一个 ip 在 list 末尾，需遍历 N 次。复杂度为 O(N/2)。

iptables 模式虽然克服了 userspace 那种内核态–用户态之间反复传递的缺陷，
但是在集群规模大的情况下，iptables rules 过多会导致性能显著下降。

因此，iptables 性能勉强适中。而且仅支持rr负载策略

3、ipvs 模式

在 1.8 以上的版本中，kube-proxy 组件增加了 ipvs 模式；

ipvs 基于 NAT 实现，不创建反向代理, 也不创建 iptables 规则，通过 netlink 创建规则；
而 netlink 通过 hashtable 组织 service，其控制面和转发面的性能都是 O(1) 的，而且直接工作在内核态，因此在性能上比 userspace 和 iptables 都更优秀。

因此，ipvs 可谓是性能与负载均衡兼得。且支持更多负载策略
详情可参考： ipvs-based-in-cluster-load-balancing

支持的调度算法

1. 轮叫调度 rr
这种算法是最简单的，就是按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点就是简单。轮询算法假设所有的服务器处理请求的能力都是一样的，调度器会将所有的请求平均分配给每个真实服务器，不管后端 RS 配置和处理能力，非常均衡地分发下去。

2. 加权轮叫 wrr
这种算法比 rr 的算法多了一个权重的概念，可以给 RS 设置权重，权重越高，那么分发的请求数越多，权重的取值范围 0 – 100。主要是对rr算法的一种优化和补充， LVS 会考虑每台服务器的性能，并给每台服务器添加要给权值，如果服务器A的权值为1，服务器B的权值为2，则调度到服务器B的请求会是服务器A的2倍。权值越高的服务器，处理的请求越多。

3. 最少链接 lc
这个算法会根据后端 RS 的连接数来决定把请求分发给谁，比如 RS1 连接数比 RS2 连接数少，那么请求就优先发给 RS1

4. 加权最少链接 wlc
这个算法比 lc 多了一个权重的概念。

5. 基于局部性的最少连接调度算法 lblc
这个算法是请求数据包的目标 IP 地址的一种调度算法，该算法先根据请求的目标 IP 地址寻找最近的该目标 IP 地址所有使用的服务器，如果这台服务器依然可用，并且有能力处理该请求，调度器会尽量选择相同的服务器，否则会继续选择其它可行的服务器

6. 复杂的基于局部性最少的连接算法 lblcr
记录的不是要给目标 IP 与一台服务器之间的连接记录，它会维护一个目标 IP 到一组服务器之间的映射关系，防止单点服务器负载过高。

7. 目标地址散列调度算法 dh
该算法是根据目标 IP 地址通过散列函数将目标 IP 与服务器建立映射关系，出现服务器不可用或负载过高的情况下，发往该目标 IP 的请求会固定发给该服务器。

8. 源地址散列调度算法 sh
与目标地址散列调度算法类似，但它是根据源地址散列算法进行静态分配固定的服务器资源。