kubernetes之Ingress工作原理
一.kubernetes集群外部访问的方式
在kubernetes集群中，如果外部的应用需要访问集群内部的服务，可以通过NodePort Service、LoadBalancer Service、Ingress来实现。
- NodePort Service
这里实际在集群的每个节点上都暴露一个端口，然后将这个端口映射到某个具体的Service来实现。端口范围限制(0~65535)，但是由于安全(kubernetes集群默认关闭防火墙)和易用性方面来看，存在一定的风险。只能适用小规模服务的集群。 - LoadBalancer Service
适用于云平台，有局限性。 - Ingress
在kubernetes集群中，Service和Pod的IP仅在集群内部访问，如果外部应用需要访问集群内的服务，集群外部请求转发到service在节点上暴露的NodePort上，然后由kube-proxy组件将其转发给相关的Pod。而Ingress就是为集群集群的请求提供路由规则的集合，简单来讲就是提供外部访问集群的入口，将外部的HTTP或HTTPS请求转发到集群内部的Service上。
二.Ingress具体介绍
- Service是后端真实服务的抽象，一个Service可以负载多个相同的后端服务。
- Ingress是反向代理规则，用于规定HTTP或HTTPS请求应该被转发到哪个Service上，例如可以根据请求中配置的不同Host和Url路径让请求负载到不同的Service上。
- Ingress Controller就是一个反向代理程序，它负责解析Ingress的反向代理规则，如果Ingress有增删改的变动，所有的Ingress Controller都会及时更新自己相应的转发规则，当Ingress Controller收到请求后就会根据这些规则将请求转发到对应的Service。
Ingress Controller收到请求，匹配Ingress转发规则，匹配到了就转发到后端Service，而Service可能代表的后端Pod有多个，选出一个转发到那个Pod，最终由那个Pod处理请求。
三.Ingress-nginx组成
1）反向代理负载均衡器：通过接受并按照Ingress定义的规则进行转发，常用的有nginx，haproxy，traefik等。
2）ingress-nginx-controller：监听kube-apiserver，同居用户编写的ingress规则(用户编写的ingress的yaml文件)，动态的去更改nginx服务的配置文件，并且reload重载使其生效，此过程是自动的。
3）ingress：将nginx的配置抽象成一个Ingress对象，当用户每添加一个新的服务，只需要编写一个新的yaml文件即可。
四.Ingress-nginx工具原理
1）ingress controller通过和kubernetes的api进行交互，动态的去感知集群中ingress的规则变化。
2）读取ingress的规则，按照自定义的规则(规则就是写的哪个域名对应的哪个service)，生成一段nginx的配置。
3）配置写入到nginx-ingress-controller的Pod里面。这个Ingress Controller的Pod里面运行着一个nginx服务，控制器会把生成的nginx配置写入到/etc/nginx/nginx.conf文件中。
4）写入配置后，会reload一下使配置生效，以此达到分配和动态更新的问题。
五.Ingress-nginx解决了哪些问题
1）动态配置服务
如果按照传统方式，当新增加一个服务时，我们可能需要在流量入口加一个反向代理指向我们新的服务，而使用ingress，只需要配置好ingress，当服务启动时，会自动注册到ingress当中，不需要额外的操作。
2）减少不必要的端口暴露
kubernetes部署时，默认是关闭防火墙的，服务会以nodeport方式映射出去，这样对于宿主机来说是非常的不安全的，而ingress可以避免这个问题，只需要将ingress自身服务映射出去，就可代理后端所有的服务，则后端服务不需要映射出去。
注意：配置DNS解析时，需要将域名解析到Ingress控制器的IP地址上。可以通过修改域名的DNS记录来实现，将域名解析到Ingress控制器的IP地址上。
