1. 前置知识 四层与七层负载均衡

1.1 简介

  • 所谓四层就是基于 IP + 端口的负载均衡；
  • 七层就是基于 URL 等应用层信息的负载均衡

image.png

1.2 负载均衡器

image.png

1.3 技术原理上的区别

image.png
image.png
image.png

1.4 参考

  1.   - [**四层、七层负载均衡的区别**](https://jaminzhang.github.io/lb/L4-L7-Load-Balancer-Difference/)

2. k8s服务发现

2.1 基础概念简要理解

image.png

2.2 三种外部访问方式

image.png

2.3 内部服务通信—kube-proxy的三种模式

Kube-proxy负责将发送到Cluster IP的请求转发到后端的Pod上

2.3.1 补充概念 iptables

简单解释就是：配置一些规则，这些规则会将符合条件的请求导向到特定服务处理
参考材料：《Linux就该这么学》 可供简单学习理解
**
在早期的Linux 系统中，默认使用的是iptables 防火墙管理服务来配置防火墙。
iptables 是一款基于命令行的防火墙策略管理工具，具有大量参数，学习难度较大。好在对于日常的防火墙策略配置来讲，大家无需深入了解诸如“四表五链”的理论概念，只需要掌握常用的参数并做到灵活搭配即可，这就足以应对日常工作了。
iptables 命令可以根据流量的源地址、目的地址、传输协议、服务类型等信息进行匹配一旦匹配成功，iptables 就会根据策略规则所预设的动作来处理这些流量。另外，再次提醒一下，防火墙策略规则的匹配顺序是从上至下的，因此要把较为严格、优先级较高的策略规则放到前面，以免发生错误。

2.3.2 userspace模式

要点：

  1.   - 充当一四层负载均衡器
  2.   - pod失败可重试其他pod
  3.   - 缺点：增加两次内核与用户空间交互，效率低一些

image.png

image.png

2.3.3 iptabes模式

  1.  **要点：**
  3.   - 分配的iptables规则导致指向固定的pod，失败也不能重试其他pod
  4.   - 优点：较上面效率高一些

image.png

image.png

2.3.4 ipvs模式

要点：

  1.   - 后端server作为一个负载均衡器
  2.   - kube-proxy配置ipvs规则
  3.   - ipvs 较 iptables支持更多负载均衡算法
  4.   - kube-proxy的 ipvs 必须在操作系统中安装ipvs内核模块

image.png
image.png

2.3.5 小结

image.png

2.3.6 参考

  1.   - [**为服务网格选择入口网关**](https://www.servicemesher.com/istio-handbook/best-practices/how-to-implement-ingress-gateway.html)
  2.   - [**kubernetes 官方文档**](https://kubernetes.io/zh/docs/concepts/services-networking/service/)

3. 三种外部访问模式的原理

3.1 NodePort

要点：

  1.   - NodePort 提供服务的对外暴露的端口，供外部访问，在所有节点主机上开启
  2.   - 端口是随机的，服务重启后，端口不保证与上次一致
  3.   - 利用 kube-proxy 实现，创建 iptables 规则，将端口收到的流量直接转发到后端的pod，直接绑定 类似 Cluster IP 的 iptables 模式
  4.   - 每个服务对外暴露都会产生，一个 NodePort 端口
  5.   - 另外由于是集群形式，所以可能每个节点（主机），暴露的端口不一致，但是都指向相同的服务

image.png

image.png

3.2 LoadBalancer

要点：

  1.   - 由上面可知，每个对外暴露的服务，都会产生一个 NodePort 端口，因此服务多了，很难管理
  2.   - 另外，服务重启后，端口不保证与上次一致，因此对于客户端来说，访问很麻烦，没有固定地址
  3.   - LoadBalancer 可以解决上述问题，其是一个四层负载均衡器，就是通过 IP + Port 访问，其可提供一个稳定的端口，然后将请求转到 NodePort 上
  4.   - 因为是个集群，所以集群中对于同一服务，每台主机暴露的端口不保证一致
  5.   - 所以 一个 LoadBalancer 就相当于，指向很多个 NodePort， 但他们是同一个服务
  6.   - 所以一个服务，需要一个 LoadBalancer，需要购买，这非常昂贵

image.png

image.png

3.3 Ingress

要点：

  1.   - 由于 LoadBalancer 非常昂贵，因此 k8s 提供了一种 集群内部负载均衡模式 Ingress
  2.   - Ingress 入口网关，七层负载均衡器，需要一个七层网关来实现，如 Nginx，Envoy等
  3.   - Ingress 由于在集群内部，因此无法直接对外提供服务
  4.   - 需要配合 NodePort 和 LoadBalancer 才能提供对外的流量入口

image.png

3.3.1 按 HTTP 请求的 URL 进行路由

image.png

3.3.2 按 HTTP 请求的 Host 进行路由

image.png

3.4 三种模式结合的拓扑结构

要点：

  1.   - 外部请求首先通过 LoadBalancer 将流量分发给多个主机节点的 Nodeport
  2.   - 这个 NodePort 暴露的服务，其实就是 Ingress Controller（这是个NodePort 类型的服务）
  3.   - 之后  Ingress Controller 根据 ingress rule 进行七层分发，将请求转到对应的 Service 上，最后落在相应的 pod 上

image.png
image.png

3.4.1 实现原理图

image.png

3.5 参考

  1.   - [**为服务网格选择入口网关**](https://www.servicemesher.com/istio-handbook/best-practices/how-to-implement-ingress-gateway.html)

4 Istio

4.1 Istio Sidecar Proxy

要点：

  1.   - 部署 istio 后，服务间的通信不再通过 kube-Proxy，而是通过 Sidecar proxy
  2.   - 流程为：首先将客户端发起请求通过 iptables 规则转发给 Sidecar proxy
  3.   - 然后 Sidecar proxy 从控制面 pilot 获取服务发现信息和路由规则
  4.   - 选择一个后端的 server pod 创建链接，代理并转发 客户端的请求
  5.   - Sidecar proxy 为七层代理，kube-proxy 为四层代理
  6.   - istio 为每个 service 都注入一个 Sidecar proxy
  7.   - 控制面可以对所有的 Sidecar proxy 进行统一配置

image.png
image.png

4.2 前置知识

image.png

4.3 k8s Ingress 作为入口网关时的分析

要点：

  1.   - Ingress 不是完全适配 istio 体系，很多功能难以实现

image.png

image.png

4.4 Istio Gateway 作为入口网关

要点：

  1.   - istio Gateway 只能实现4-6层功能
  2.   - VirtualService 可配合其，实现七层路由
  3.   - Istio ingress 的配置模型为 Gateway + VirtualService，采用和 Sidecar 相同的 Envoy proxy 网关

image.png

image.png

4.5 应用对API Gateway的需求

要点：

  1.   -  此部分主要说明 istio ingress Gateway 还欠缺一些功能，同时有一些劣势
  2.   - 对于服务化应用，缺少些应用程序功能，如访问控制，声明周期管理等
  3.   - 同时 Api Gateway 需要根据不同系统进行定制
  4.   - 另外各种不同的 k8s ingress controller 和 istio ingress Gateway，缺少统一的标准，不兼容
  5.   - 这些 ingress controller 还有提供和 istio 控制面集成的能力

image.png

image.png

4.6 采用API Gateway + Sidecar Proxy作为服务网格的流量入口

要点：

  1.      - 由于API Gateway 已经具备七层网关能力
  2.      - 因此 Ingress 中的 Sidecar  只需要提供 VirtualService 的路由能力即可，因此采用Sidecar proxy
  3.      - Ingress 中 Sidecar 只接管 API Gateway 向 Mesh 内部的流量，不接管外部流向 Gateway 的流量
  4.      - 而应用 pod 中的 Sidecar 需要接管进入应用的所有流量

image.png

image.png

4.7 参考

  1.   - **[为服务网格选择入口网关](https://www.servicemesher.com/istio-handbook/best-practices/how-to-implement-ingress-gateway.html)**