Service是基于四层TCP和UDP协议转发的，而Ingress可以基于七层的HTTP和HTTPS协议转发，可以通过域名和路径做到更细粒度的划分，如下图所示:
用户请求首先到达Ingress Controller，Ingress Controller根据Ingress的路由规则，查找到对应的Service，进而通过Endpoint查询到Pod的IP地址，然后将请求转发给Pod。
简单来说，Ingress Controller是负责具体转发的组件，通过各种方式将它暴露在集群入口，外部对集群的请求流量会先到Ingress Controller，而Ingress对象是用来告诉Ingress Controller该如何转发请求，比如哪些域名哪些Path要转发到哪些服务等等。
Ingress ControllerIngress Controller并不是Kubernetes自带的组件，实际上Ingress Controller只是一个统称，用户可以选择不同的Ingress Controller实现，目前，由Kubernetes维护的Ingress Controller只有Google的GCE与Ingress Nginx两个，其他还有很多第三方维护的Ingress Controller。但是不管哪一种Ingress Controller，实现的机制都基本一致，只是在具体配置上有差异。一般来说，Ingress Controller的形式都是一个Pod，里面跑着daemon程序和反向代理程序。daemon负责不断监控集群的变化，根据Ingress对象生成配置并应用新配置到反向代理，比如Nginx Ingress就是动态生成Nginx配置，动态更新upstream，并在需要的时候重新加载应用新配置。
IngressIngress是一个API对象，和其他对象一样，通过yaml文件来配置。Ingress通过Http或Https暴露集群内部Service，给Service提供外部URL、负载均衡、SSL/TLS能力以及基于Host代理。
Ingress的部署 Deployment+LoadBalancer模式的Service如果要把Ingress部署在公有云，那可以选择这种方式。用Deployment部署Ingress Controller，创建一个type为LoadBalancer的Service关联这组Pod。大部分公有云，都会为LoadBalancer的Service自动创建一个负载均衡器，通常还绑定了公网地址。只要把域名解析指向该地址，就实现了集群服务的对外暴露。此方案确定需要在公有云上部署。
使用Deployment模式部署Ingress Controller，并创建对应的服务，但是type为NodePort。这样，Ingress就会暴露在集群节点ip的特定端口上。由于Nodeport暴露的端口是随机端口，一般会在前面再搭建一套负载均衡器来转发请求。该方式一般用于宿主机是相对固定IP地址。
缺点:
NodePort方式暴露Ingress虽然简单方便，但是NodePort多了一层转发，在请求量级很大时可能对性能会有一定影响;
请求节点会是类似:3008,其中3008是Ingress Nginx的svc暴露出来的Nodeport端口，看起来不太专业；
使用DaemonSet结合Nodeselector来部署Ingress Controller到特定的Node上，然后使用HostNetwork直接把该Pod与宿主机Node的网络打通，直接使用宿主机的80/433端口就能访问服务。这时Ingress Controller所在的Node机器就是流量入口。
优点
该方式整个请求链路最简单，性能相对NodePort减少一层转发，因此性能更好；
缺点
由于直接利用宿主机节点的网络和端口，一个Node只能部署一个Ingress Controller的pod；
关于版本问题需要注意以下几点:
本篇采用ingress-nginx v1.0.0,最新版本 v1.0.0适用于 Kubernetes 版本 v1.19+ ；
Kubernetes-v1.22+ 需要使用 ingress-nginx>=1.0，因为 networking.k8s.io/v1beta 已经移除；
Deployment+NodePort模式