一、需求背景
固定对外提供服务采用了NodePort方式映射并固定了30001端口,但是，该端口默认范围是30000~32767，并且我们的web服务一般都是80、443端口对外，因此我们产生了如下几点需求和疑问：
1、如果想暴露80、443端口，可以修改k8s apiserver的参数将端口设置为80~xxxx，但是不推荐这样做，因为k8s在一些场景需求的时候会自动在端口范围内生成一个端口使用，如果我们的端口访问包含了常用端口，可能会给其他本地服务带来麻烦。
2、如果你的系统服务增多，需要暴露更多的web服务的时候，那么也同样需要设置固定更多的NodePort端口，为了避免端口冲突你还要对使用的端口进行整理维护。
3、一个系统对外暴露的端口增多，就好比我们的园区开了更多的门一样，任何一个门有安全问题，都会导致整个园区产生安全风险，我们的系统同样如此。
4、还有一个最重要的是，我们是web服务，怎么能少了https证书呢。所以依然需要在增加一个独立的nginx、traefik等组件来配置证书。
针对如上问题，我们总是需要一个方向代理服务的。既然需要单独管理维护一个，不如用 k8s 为了提供了的ingress控制器方案，完美解决问题。
二、主要组件关系
Ingress是为了弥补nodeport不足而生的，nodeport存在不足：一个端口只能一个服务使用，端口需要提前规划，只支持4层负载均衡。
Ingress 公开了从集群外部到集群内部服务的HTTP和HTTPS路由的规则集合，而具体实现流量路由是由Ingress Controller负责。
Service： 后端真实服务的抽象，一个 Service 可以代表多个相同的后端服务，向下对应多个 Pod。
Ingress： 反向代理规则，用来规定 HTTP/S 请求应该被转发到哪个 Service 上，根据根据请求中不同的 Host 和 url 路径让请求落到不同的 Service 上。
Ingress Controller： 它是一个反向代理程序，也是一个具体的 Pod，它负责解析 Ingress 的反向代理规则，如果 Ingress 有增删改的变动，所有的 Ingress Controller 都会及时更新自己相应的转发规则，当 Ingress Controller 收到请求后就会根据这些规则将请求转发到对应的 Service。
Kubernetes 并没有自带 Ingress Controller，它只是一种标准，具体实现有多种，需要自己单独安装，常用的是 Nginx Ingress Controller 和 Traefik Ingress Controller。 所以 Ingress 是一种转发规则的抽象，Ingress Controller 的实现需要根据这些 Ingress 规则来将请求转发到对应的 Service
使用 Ingress 时一般会有三个组件:
- 反向代理负载均衡器
- Ingress Controller
- Ingress
1.反向代理负载均衡器
反向代理负载均衡器很简单，说白了就是 nginx、apache 什么的；在集群中反向代理负载均衡器可以自由部署，可以使用 Replication Controller、Deployment、DaemonSet 等等
2.Ingress Controller
Ingress Controller 实质上可以理解为是个监视器，Ingress Controller 通过不断地跟 kubernetes API 打交道，实时的感知后端 service、pod 等变化，比如新增和减少 pod，service 增加与减少等；当得到这些变化信息后，Ingress Controller 再结合下文的 Ingress 生成配置，然后更新反向代理负载均衡器，并刷新其配置，达到服务发现的作用
3.Ingress
Ingress 简单理解就是个规则定义；比如说某个域名对应某个 service，即当某个域名的请求进来时转发给某个 service;这个规则将与 Ingress Controller 结合，然后 Ingress Controller 将其动态写入到负载均衡器配置中，从而实现整体的服务发现和负载均衡
Ingress Controller工作流程
Ingress Contronler通过于k8s API交互，动态去感知集群中Ingress 规则变化，然后读取它按照自定义规则，规则就是写明哪个域名对应哪个service ，生成一段nginx配资后，应用到管理Nginx服务， 然后热加载生效，从而达到Nginx负载均衡器配置及动态更新问题。
ingress-controller流程： 客户端->LB(公网)-> Ingress Controller(nginx) -> 分布在各pod节点
nodeport流程：客户端->LB(公网)->Service(nodeport)--> Ingress Controller(nginx) -> 分布在各pod节点
请求进来被负载均衡器拦截，比如 nginx，然后 Ingress Controller 通过跟 Ingress 交互得知某个域名对应哪个 service，再通过跟 kubernetes API 交互得知 service 地址等信息；综合以后生成配置文件实时写入负载均衡器，然后负载均衡器 reload 该规则便可实现服务发现，即动态映射
Ingress Controller 的存在就是为了能跟 kubernetes 交互，又能写 nginx 配置，还能 reload 它，这是一种折中方案；
traefik 天生就是提供了对 kubernetes 的支持，也就是说 traefik 本身就能跟 kubernetes API 交互，感知后端变化，因此可以得知: 在使用 traefik 时，Ingress Controller 已经无卵用了
小结论
ingress、service、pod、secret 都必须要在同一个 namespace 中，对 ingress-controller 的 namespace 没有要求。