通过K8s七层负载了解Ingress和Ingress Controller

接触k8s之前都了解哪些负载均衡方案？

四层负载(传输层,tcp)：lvs(软件层面)、f5(硬件层面) 

缺点：对网络依赖较大，负载智能化方面没有 7 层负载好（比如不支持对 url 个性化负载），F5 硬件性能很高但成本也高，需要人民币几十万，对于小公司就望而却步了。

常见的七层负载均衡(应用层,http)：nginx、apache

优点：对网络依赖少，负载智能方案多（比如可根据不同的 url 进行负载）

在k8s中为什么要做负载均衡？

Pod 漂移问题

Kubernetes 具有强大的副本控制能力，能保证在任意副本（Pod）挂掉时自动从其他机器启动一个新的，还可以动态扩容等。通俗地说，这个 Pod 可能在任何时刻出现在任何节点上，也可能在任何时刻死在任何节点上；那么自然随着 Pod 的创建和销毁，Pod IP 肯定会动态变化；那么如何把这个动态的Pod IP 暴露出去？这里借助于 Kubernetes 的 Service 机制，Service 可以以标签的形式选定一组带有指定标签的 Pod，并监控和自动负载他们的 Pod IP，那么我们向外暴露只暴露 Service IP 就行了；这就是 NodePort 模式：即在每个节点上开起一个端口，然后转发到内部 Pod IP 上。

使用Service做四层负载均衡

在 kubernetes 中，Pod 是有生命周期的，如果 Pod 重启 IP 很有可能会发生变化。

如果我们的服务都是将 Pod 的 IP 地址写死，Pod 的挂掉或者重启，和刚才重启的 pod 相关联的其他服务将会找不到它所关联的 Pod

为了解决这个问题，在 kubernetes 中定义了 service 资源对象，Service 定义了一个服务访问的入口，客户端通过这个入口即可访问服务背后的应用集群实例，service 是一组 Pod 的逻辑集合，这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector 实现的。

我们通过Service负载访问k8s内部应用都时候数据包走向是这样呢？

此时数据流向如下

客户端请求-> node节点的ip:端口->service的ip:端口->pod的ip:端口

案例如nacos集群的1-2步骤创建

1、创建负载nacos-headless

2、创建nacos pod通过selector label app name与负载关联绑定

端口管理问题

采用 service 的 NodePort 方式暴露服务面临的问题是，服务一旦多起来，NodePort 在每个节点上开启的端口会及其庞大，而且难以维护。

四层负载均衡和七层负载均衡对比分析

1）四层的负载均衡就是基于 IP+端口的负载均衡：在三层负载均衡的基础上，通过发布三层的 IP 地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行 NAT 处理，转发至后台服务器，并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。

2）七层的负载均衡就是基于虚拟的 URL 或主机 IP 的负载均衡：在四层负载均衡的基础上（没有四层是绝对不可能有七层），再考虑应用层的特征，比如同一个 Web 服务器的负载均衡，除了根据 VIP加 80 端口辨别是否需要处理的流量，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。

举个例子，如果你的 Web 服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。 

Ingress 和 Ingress Controller 深度解读 

为什么要使用 k8s 原生的 Ingress controller 做七层负载均衡？

Ingress 官网定义：Ingress 可以把进入到集群内部的请求转发到集群中的一些服务上，从而可以把服务映射到集群外部。

Ingress 能把集群内 Service 配置成外网能够访问的 URL，流量负载均衡，提供基于域名访问的虚拟主机等。

Ingress 简单的理解就是你原来需要改 Nginx 配置，然后配置各种域名对应哪个 Service，现在把这个动作抽象出来，变成一个 Ingress 对象，你可以用 yaml 创建，每次不要去改 Nginx 了，直接改yaml 然后创建/更新就行了；

那么问题来了：”Nginx 该怎么处理？”

Ingress Controller 这东西就是解决 “Nginx 的处理方式” 的；

Ingress Controller 通过与Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取他，按照他自己模板生成一段 Nginx 配置，再写到 Ingress Controller Nginx 里，最后 reload 一下

工作流程如下：

实际上 Ingress 也是 Kubernetes API 的标准资源类型之一，它其实就是一组基于 DNS 名称（host）或 URL 路径把请求转发到指定的 Service 资源的规则

用于将集群外部的请求流量转发到集群内部完成的服务发布。我们需要明白的是，Ingress 资源自身不能进行“流量穿透”，仅仅是一组规则的集合，这些集合规则还需要其他功能的辅助，比如监听某套接字，然后根据这些规则的匹配进行路由转发，这些能够为 Ingress 资源监听套接字并将流量转发的组件就是 Ingress Controller。

注：Ingress 控制器不同于 Deployment 控制器的是，Ingress 控制器不直接运行为 kubecontroller-manager 的一部分，它仅仅是 Kubernetes 集群的一个附件，类似于 CoreDNS，需要在集群上单独部署。

Ingress Controller 介绍

Ingress Controller 是一个七层负载均衡调度器，客户端的请求先到达这个七层负载均衡调度器，由七层负载均衡器在反向代理到后端 pod，常见的七层负载均衡器有 nginx、traefik，以我们熟悉的nginx 为例，假如请求到达 nginx，会通过 upstream 反向代理到后端 pod 应用，但是后端 pod 的 ip 地址是一直在变化的，因此在后端 pod 前需要加一个 service，这个 service 只是起到分组的作用，那么我们 upstream 只需要填写 service 地址即可。

Ingress 和 Ingress Controller 总结

Ingress Controller 可以理解为控制器，它通过不断的跟 Kubernetes API 交互，实时获取后端Service、Pod 的变化，比如新增、删除等，结合 Ingress 定义的规则生成配置，然后动态更新上边的Nginx 或者 trafik 负载均衡器，并刷新使配置生效，来达到服务自动发现的作用。

Ingress 则是定义规则，通过它定义某个域名的请求过来之后转发到集群中指定的 Service。它可以通过 Yaml 文件定义，可以给一个或多个 Service 定义一个或多个 Ingress 规则。

使用 Ingress Controller 代理 k8s 内部应用的流程

（1）部署 Ingress controller，我们 ingress controller 使用的是 nginx

（2）创建 Pod 应用，可以通过控制器创建 pod

（3）创建 Service，用来分组 pod

（4）创建 Ingress http，测试通过 http 访问应用

（5）创建 Ingress https，测试通过 https 访问应用

案例如创建nacos集群章节

1、创建nacos-headless负载（一个Service用于暴漏ip端口，此处是通过集群内部转发所以不需要暴露nodeport端口给集群外访问）

2、创建nacos pod(通过selector label app name与负载绑定)

3、创建nginx-ingress负载(一个Service,是ingress-controller负载，用于暴漏nodeport端口到node给外部浏览器访问并转发到到下面的nginx-ingress-controller)

3、创建nginx-ingress-controller相当于nginx的作用用于转发调度(是个pod)

4、创建ingress(用于配置规则刷新到nginx-ingress-controller的nginx.conf中)

6、创建的coredns用于pod间通信(该步骤与本章节无关)

然后nacos请求最终实际转发路径：

1、访问Ingress rule配置的域名:端口。--->

2、nginx-Ingress-controller(暴漏端口到node给步骤1访问最终映射映射到80，通过Ingress配置的规则进行转发到对应的Service负载)。-->

3、nacos负载(Service nacos-headless)-->

4、转发到最终的pod

http://nacos.local.com:8481/nacos