k8s 对外服务之 Ingress（七层代理）

一    Ingress 简介 理论方面

1， k8s service 作用

对集群内部：

它不断跟踪pod的变化，更新endpoint中对应pod的对象，提供了ip不断变化的pod的服务发现机制

 对集群外部：

对集群外部，他类似负载均衡器，可以在集群内外部对pod进行访问。

2，外部的应用能够访问集群内的服务   的方法

●NodePort：将service暴露在节点网络上，NodePort背后就是Kube-Proxy，Kube-Proxy是沟通service网络、Pod网络和节点网络的桥梁。
测试环境使用还行，当有几十上百的服务在集群中运行时，NodePort的端口管理就是个灾难。因为每个端口只能是一种服务，端口范围只能是 30000-32767。

●LoadBalancer：通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置 Service 的场景。受限于云平台，且通常在云平台部署LoadBalancer还需要额外的费用。
在service提交后，Kubernetes就会调用CloudProvider在公有云上为你创建一个负载均衡服务，并且把被代理的Pod的IP地址配置给负载均衡服务做后端。

●externalIPs：service允许为其分配外部IP，如果外部IP路由到集群中一个或多个Node上，Service会被暴露给这些externalIPs。通过外部IP进入到集群的流量，将会被路由到Service的Endpoint上。 

●Ingress：只需一个或者少量的公网IP和LB，即可同时将多个HTTP服务暴露到外网，七层反向代理。
可以简单理解为service的service，它其实就是一组基于域名和URL路径，把用户的请求转发到一个或多个service的规则。
 

在 Kubernetes (k8s) 中，NodePort, LoadBalancer, externalIPs, 和 Ingress 都是用来暴露服务到集群外部的不同方法，各自有其特定的使用场景和特点：

NodePort

• 概念：NodePort 服务会在集群中每个节点上打开一个特定的端口，并将这个端口上的流量转发到 Service 的 backend pod 上。它是 Kubernetes 内置的最简单的一种服务暴露方式。           nodeport 简单粗暴理解就是 把容器端口映射 真机端口 再通过 kube-proxy 的 pod 处理流量
• 使用场景：适用于测试环境或小规模部署，不需要复杂的负载均衡设置，只需要直接通过节点 IP 和 NodePort 访问服务。
• 区别：相对简单，但不够灵活，随着服务数量增加，管理众多端口变得困难。

LoadBalancer

• 概念：LoadBalancer 类型的服务会利用云提供商的负载均衡器（如 AWS ELB、GCP LB 等），自动创建一个外部负载均衡器，并将流量分发到集群中的节点。
• 使用场景：适用于生产环境，需要高可用性和自动扩展的服务。尤其适合需要云提供商负载均衡支持的场景。
• 区别：提供了更高级的流量管理和负载均衡功能，但依赖于云提供商支持，可能产生额外费用。

externalIPs

• 概念：通过 externalIPs 字段，可以在 Service 定义中直接指定一个或多个外部 IP 地址，集群会将这些 IP 地址绑定到 Service 上，从而允许外部流量直接通过这些 IP 访问服务                            externalIPs 简单粗暴理解 就是把想要通过的ip 开小灶告诉service
• 使用场景：适用  于已有外部负载均衡器或具有固定公网 IP 的情况，希望直接利用这些资源来路由流量到 Service。
• 区别：提供了灵活性，允许使用自定义的外部 IP，但配置和管理外部负载均衡器的责任在于用户。

Ingress

• 概念：Ingress 是一种更高级的流量路由规则集合，它根据 HTTP/HTTPS 路径或主机头等规则，将外部请求路由到集群内的不同服务。通常背后需要一个 Ingress Controller（如 Nginx Ingress Controller）来实现实际的路由逻辑。
• 使用场景：适用于微服务架构，特别是当有多个服务需要对外暴露，并且需要基于 URL 路径或主机名进行路由时。
• 区别：提供了一层七层（应用层）的路由，支持复杂的路由规则，如路径基于的路由、TLS 终端等，非常适合现代微服务架构。  ingress 简单粗暴理解 就是 有个nginx 的pod（实际是ingress controller） 做七层反向代理

总结

• 选择依据：选择哪种暴露方式取决于服务的需求、部署环境以及对可扩展性、安全性、成本控制的要求。对于简单的服务或测试环境，NodePort 或 externalIPs 可能足够；而对于生产环境、复杂路由需求或需要云提供商支持的高可用服务，则倾向于使用 LoadBalancer 或 Ingress。

3,  Ingress 组成

3.1   Ingress

●ingress：  nginx配置文件
ingress是一个API对象，通过yaml文件来配置，ingress对象的作用是定义请求如何转发到service的规则，可以理解为配置模板。
ingress通过http或https暴露集群内部service，给service提供外部URL、负载均衡、SSL/TLS以及基于域名的反向代理。ingress要依靠 ingress-controller 来具体实现以上功能。
 

3.2  ingress-controller

●ingress-controller：    当做反向代理或者说是转发器
ingress-controller是具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发。
ingress-controller并不是k8s自带的组件，实际上ingress-controller只是一个统称，用户可以选择不同的ingress-controller实现，目前，由k8s维护的ingress-controller只有google云的GCE与ingress-nginx两个，其他还有很多第三方维护的ingress-controller，具体可以参考官方文档。但是不管哪一种ingress-controller，实现的机制都大同小异，只是在具体配置上有差异。
一般来说，ingress-controller的形式都是一个pod，里面跑着daemon程序和反向代理程序。daemon负责不断监控集群的变化，根据 ingress对象生成配置并应用新配置到反向代理，比如ingress-nginx就是动态生成nginx配置，动态更新upstream，并在需要的时候reload程序应用新配置。为了方便，后面的例子都以k8s官方维护的ingress-nginx为例。

Ingress-Nginx github 地址：https://github.com/kubernetes/ingress-nginx
Ingress-Nginx 官方网站：https://kubernetes.github.io/ingress-nginx/
 

总结：

ingress-controller才是负责具体转发的组件，通过各种方式将它暴露在集群入口，外部对集群的请求流量会先到 ingress-controller， 而ingress对象是用来告诉ingress-controller该如何转发请求，比如哪些域名、哪些URL要转发到哪些service等等。
 

4，  Ingress 工作原理

（1）ingress-controller通过和 kubernetes APIServer 交互，动态的去感知集群中ingress规则变化，
（2）然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置，
（3）再写到nginx-ingress-controller的pod里，这个ingress-controller的pod里运行着一