K8S Ingress 和 Service的作用

文章目录

• • • • 一、四层与七层
      • • 1、四层负载均衡
        • 2、七层负载均衡
      • 二、四层负载均衡实现：kube-proxy
      • • 1、userspace 模式
        • 2、iptables 模式
        • 3、ipvs 模式
      • 三、七层负载均衡实现： Ingress

一、四层与七层

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 就能被调用了。

Kubernetes中的Ingress和Service都是用于构建和管理应用程序的网络服务的重要组件，两者的作用不同。

• Service: 是Kubernetes中一个抽象的概念，用于定义一组Pod的访问方式和网络访问规则。Service通常用于在内部网络中提供可靠的负载均衡机制，如将服务映射到固定的端口。

具体而言，Service可以将Pod集合作为一个整体来对外提供服务，使用Service的Cluster IP作为虚拟IP地址。当客户端访问此IP时，Kubernetes的Service负载均衡器将流量转发到与此Service相关联的Pod集合中的任意Pod。Service可以使用不同的负载均衡算法，如轮询和IP哈希等，可以与Kubernetes DNS服务结合使用，并通过标签选择器和端口映射提供丰富的筛选和路由选项。

• Ingress: 是一种Kubernetes资源对象，用于从集群外部公开HTTP和HTTPS路由，以便在单个IP上托管多个域。Ingress充当入口控制器，允许网络流量从外部进入集群，并将其路由到正确的Service上。

Ingress与Service之间的关系是，Ingress控制器将HTTP/HTTPS流量路由到正确的Pods/Services，而Service则负责在Kubernetes集群中负载均衡流量。Ingress允许用户以URL路径或主机名为基础定义和路由HTTP和HTTPS流量，允许HTTP和HTTPS在同一IP和端口上进行处理，从而简化了网络架构。

总之，Service主要用于在内部网络中提供负载均衡和访问规则，而Ingress则用于将外部网络流量路由到适当的Service和Pod上，使得在Kubernetes集群中公开应用程序成为可能。

这两者，可以理解为一个是七层的代理 一个是四层的？

可以这样理解，Ingress 和 Service 都提供了一种在 Kubernetes 中管理网络通信的方法，不同的是它们控制和管理网络流量的层次不同。

• Service 控制和管理四层（传输层）的网络流量，主要依靠负载均衡器在多个Pod之间分发请求，使用 IP 和端口来处理网络流量。Service 的负载均衡器只能识别传输层的网络信息，如IP地址和端口号，无法处理应用程序层（七层）的请求。

• Ingress 控制和管理七层（应用层）的网络流量，通过一个 API 对象，将流量路由到正确的 Pod 和 Service 上。Ingress 可以根据应用程序层协议（http/https）、请求头、请求类型、URL路径等条件来处理网络流量。

因此，可以将Service理解为一个四层的代理，可以在一定程度上进行负载均衡；而Ingress则是一个七层的代理，可以更加精细地控制和管理网络流量，支持更多的路由规则和流量控制策略，从而使得在Kubernetes中更加灵活和可扩展的发布和管理应用程序。

Service 有哪些实现方式呢？

在Kubernetes中，Service有多种实现方式。根据Service的类型不同，它们各自提供了不同的负载均衡策略和网络访问方式，可以选择最合适的实现方式来满足不同的需求。

以下是常见的Service类型：

• ClusterIP：这是默认的Service类型。ClusterIP类型的Service为Pods提供了内部集群中的稳定连接。它使用 Kubernetes内部DNS解析来负载均衡服务后端的Pods，通过内部Cluster IP提供唯一固定的虚拟IP地址，从而在集群内提供了稳定、可靠的服务发现和负载均衡。

• NodePort：此类型的Service会将外部流量转发到ClusterIP上，通常使用NodePort类型的Service来暴露外部服务。NodePort将Pod暴露在每个节点的IP地址和一个使用静态端口的外部IP地址上，创建NodePort Service后，Kubernetes会为 Service分配一个端口，通过访问指定的hostIP和NodePort可以直接访问服务。

• LoadBalancer：这种类型的Service适用于云平台中将某个服务暴露出来，由云服务商根据配置自动创建并配置负载均衡器。通过此方式，外部流量可以被平衡到集群内的各个节点(Workers)中，Kubernetes会调用云平台的负载均衡器API，并在云端创建负载均衡器，这些负载均衡器会自动路由到集群中的服务。

• ExternalName：此类型的Service节点会将所有流量直接转发到某个预定义的外部服务。通常情况下，在集群内使用ExternalName Service类型，将某个外部服务作为集群内部服务的别名来使用，使得内部服务使用起来更加方便和简单。

综上所述，Service提供了多种不同的实现方式，可以根据应用程序和网络策略的不同需求，灵活选择适合的Service类型来提供稳定和可靠的网络连接，以支持应用程序在Kubernetes中的顺畅运行。

Ingress 有哪些实现方式？

在Kubernetes中，Ingress控制器有多种实现方式，每种实现方式都针对不同的使用场景和需求，提供了不同的路由和负载均衡功能。

以下是常见的Ingress控制器实现方式：

• Nginx Ingress Controller：Nginx是一种常见的Web服务器和反向代理服务器，并广泛用于生产环境中的Web应用程序中。Kubernetes社区提供了一个基于Nginx反向代理服务器的Ingress控制器，即Nginx Ingress Controller。Nginx Ingress Controller可以通过配置文件来指定路由规则，还可以使用Nginx的HTTP模块来提供负载均衡功能。

• Istio Ingress Controller：Istio是一个流行的服务网格解决方案，在Kubernetes上提供了丰富的网络和负载均衡功能，其中包括通过Envoy代理来提供高效的Ingress控制器功能。Istio Ingress Controller可以通过定义路由规则和流量管理规则来帮助应用程序管理入口流量，同时支持使用TLS加密和认证来保护应用程序的安全性。

• Traefik Ingress Controller：Traefik是另一个广受欢迎的开源反向代理和负载均衡器，也提供了Ingress控制器的实现方式。Traefik Ingress Controller使用负载均衡算法来均衡入口流量，并可以通过简单的配置文件来定义路由规则和流量管理规则。Traefik还提供了可视化界面以及自动SSL证书管理等功能，使得它成为了开发人员和运维人员的首选。

本文链接：https://www.cnblogs.com/Skybiubiu/p/17325021.html

版权声明：本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。