k8s 如何实现负载均衡？
文章目录
一、四层与七层
1、四层负载均衡
负载均衡器用 ip+port 接收请求，再直接转发到后端对应服务上；
工作在传输层 ；
客户端和服务器之间建立一次TCP连接，而负载均衡设备只是起到一个类似路由器的转发动作。
2、七层负载均衡
负载均衡器根据 虚拟的 url 或主机名 来接收请求，经过处理后再转向相应的后端服务上；
工作在应用层 ；
七层负载均衡需要建立两次 TCP 连接，
client 到 LB，LB根据消息中的内容( 比如 URL 或者 cookie 中的信息 )来做出负载均衡的决定；
然后，建立 LB 到 server 的连接。
负载均衡设备需要先代理最终的服务器和客户端建立 TCP 连接后，才可能接收到客户端发送的真正应用层内容的报文，
然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
具有七层负载均衡功能的设备通常也被称为反向代理服务器。
二、四层负载均衡实现：kube-proxy
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 的选择和代理工作，这样流量从用户空间进出内核带来的性能损耗是不可接受的。
userspace 模式工作流程如下图：
请求到达 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 模式工作流程如下图：
iptables 模式虽然克服了 userspace 那种 内核态–用户态 之间反复传递的缺陷，
但是在集群规模大的情况下，iptables rules 过多会导致性能显著下降。
因此，iptables 性能勉强适中 。
3、ipvs 模式
在 1.8 以上的版本中，kube-proxy 组件增加了 ipvs 模式；
ipvs 基于 NAT 实现，不创建反向代理, 也不创建 iptables 规则，通过 netlink 创建规则；
而 netlink 通过 hashtable 组织 service，其控制面和转发面的性能都是 O(1) 的，而且直接工作在内核态，因此在性能上比 userspace 和 iptables 都更优秀。
ipvs 模式工作流程如下图：
因此，ipvs 可谓是性能与负载均衡兼得。
另外，
ipvs 还可通过 --ipvs-scheduler 指定负载均衡算法，有多种算法可选，
详情可参考： ipvs-based-in-cluster-load-balancing
kube-proxy 的代理模式，可通过指定 --proxy-mode 参数来配置。
四层这种负载均衡方式存在缺陷：
Service可能有很多，如果每个都绑定一个 node 主机端口的话，主机则需要开放外围的端口进行服务调用，管理上会比较混乱。
比较优雅的方式是通过一个外部的负载均衡器，比如 nginx ，绑定固定的端口比如80，然后根据域名/服务名向后面的Service ip转发，
但是这里对问题在于：
当有新服务加入的时候如何修改 Nginx 配置？ 手动改或者 Rolling Update Nginx Pod 都是不现实的。
对于这个问题， k8s 给出的七层解决方案是 Ingress。
三、七层负载均衡实现： Ingress
Ingress 是 k8s 的一种资源对象，
该对象允许外部访问 k8s 服务， 通过创建规则集合来配置访问权限，这些规则定义了哪些入站连接可以访问哪些服务；
Ingress 仅支持 HTTP 和 HTTPS 协议；
ingress 可配置用于提供外部可访问的服务 url、负载均衡流量、SSL终端和提供虚拟主机名配置。
ingress 的工作流程如下；
ingress-controller 是实现反向代理和负载均衡的程序，
通过监听 Ingress 这个 api 对象里的配置规则并转化成 Nginx 的配置 , 然后对外部提供服务
Ingress 对于上面提到的 “如何修改 Nginx 配置” 这个问题的解决方案是：
把 “修改 Nginx 配置各种域名对应哪个 Service ” 这些动作抽象为一个 Ingress 对象，
然后直接改 yml 创建/更新就行了，不用再修改 nginx 。
而 ingress-controller 通过与 k8s API 交互，动态感知集群中 Ingress 规则的变化并读取它，
然后按照模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后再 reload 一下生效。
大概的访问路径如下：
用户访问 --> LB --> ingress-nginx-service --> ingressController-ingress-nginx-pod --> ingress字段中调用的后端pod
注意后端 pod 的 service 只提供 pod 归类，
归类后 ingress 会将此 service 中的后端 pod 信息提取出来，
然后动态注入到 ingress-nginx-pod 中的 ingress 字段中，
如此，后端 pod 就能被调用了。
参考文档：