在Kubernetes中，service IP和Pod IP主要供集群内部访问使用，对于集群外部是不可见的。
如果要从集群外部访问，常用是的以下3种方式。
（1）通过NodePort方式
如下图：
我们忽略具体的实现细节，通过NodePort的方式会在所有的Node节点上映射一个端口，端口范围默认是30000-32767。然后用户通过
任意主机+映射端口
来访问集群内部。
这种方式的优点是实现方式比较简单，缺点是如果映射的端口太多不好管理，每一个端口只能提供一种服务，还有以此生成的iptables规则也很多。
（2）通过LoadBalancer方式
如下图：
从图种可以看到Load Balancer服务暴露服务非常直接，直接把服务暴露到Internet，通往指定端口的流量都会被转发到对于的服务，它没有过滤条件、没有规则等。
这种方式最大的缺点就是每个LoadBalancer都需要一个固定的IP，而且更多情况下是需要云产商的支持。
（3）通过Ingress方式
如下图：
Ingress本身不提供服务，它依赖Ingress Controller，Ingress Controller以Pod的形式部署在Kubernetes集群内，实质上我们无法从外面直接访问，依然要将其暴露出来，暴露方式有几种：
-
通过NodePort形式暴露，前面需接一个负载均衡
-
通过LoadBalancer形式暴露，云产商默认就是这种方式
-
直接在Pod中使用hostport，前面需接一个负载均衡
ingress的实现方式更智能、更友好，相对的配置就略微复杂，它一个IP可以暴露多个应用，支持同域名不同uri，支持证书等功能。
目前Ingress暴露集群内服务的行内公认最好的方式，不过由于其重要地位，世面上有非常多的Ingres Controller，常见的有：
-
Kubernetes Ingress
-
Nginx Ingress
-
Kong Ingress
-
Traefik Ingress
-
HAProxy Ingress
-
Istio Ingress
-
APISIX Ingress
除了上面列举的这些，还有非常多的Ingress Controller，面对如此多的Ingress Controller，我们该如何选择呢？参考的标准是什么？
一般情况下可以从以下几个维度进行判断：
-
支持的协议：是否支持除HTTP(S)之外的协议
-
路由的规则：有哪些转发规则，是否支持正则
-
部署策略：是否支持ab部署、金丝雀部署、蓝绿部署等
-
upstream探针：通过什么机制判定应用程序正常与否，是否有主动和被动检查，重试，熔断器，自定义运行状况检查等解决方案
-
负载均衡算法：支持哪些负载均衡算法，Hash、会话保持、RR、WRR等
-
鉴权方式：支持哪些授权方案？基本，摘要，OAuth，外部身份验证等
-
DDoS防护能力：是否支持基本的限速、白名单等
-
全链路跟踪：能否正常接入全链路监控
-
JWT验证：是否有内置的JSON Web令牌验证，用于对最终应用程序的用户进行验证和验证
-
图像界面：是否需要图形界面
-
定制扩展性：是否方便扩展
下面分别对上述的Ingress Controller做简要介绍。
Kubernetes Ingress
github.com/kubernetes/ingress-nginx
Kubernetes Ingress的官方推荐的Ingress控制器，它基于nginx Web服务器，并补充了一组用于实现额外功能的Lua插件。
由于Nginx的普及使用，在将应用迁移到K8S后，该Ingress控制器是最容易上手的控制器，而且学习成本相对较低，如果你对控制器的能力要求不高，建议使用。
不过当配置文件太多的时候，Reload是很慢的，而且虽然可用插件很多，但插件扩展能力非常弱。
Nginx Ingress
github.com/nginxinc/kubernetes-ingress
Nginx Ingress是NGINX开发的官方版本，它基于NGINX Plus商业版本，NGINX控制器具有很高的稳定性，持续的向后兼容性，没有任何第三方模块，并且由于消除了Lua代码而保证了较高的速度（与官方控制器相比）。
相比官方控制器，它支持TCP/UDP的流量转发，付费版有很广泛的附加功能，主要缺点就是缺失了鉴权方式、流量调度等其他功能。
Kong Ingress
github.com/Kong/kubernetes-ingress-controller
Kong Ingress建立在NGINX之上，并增加了扩展其功能的Lua模块。
kong在之前是专注于API网关，现在已经成为了成熟的Ingress控制器，相较于官方控制器，在路由匹配规则、upstream探针、鉴权上做了提升，并且支持大量的模块插件，并且便与配置。
它提供了一些 API、服务的定义，可以抽象成 Kubernetes 的 CRD，通过Kubernetes Ingress 配置便可完成同步状态至 Kong 集群。
Traefik Ingress
github.com/containous/traefik
traefik Ingress是一个功能很全面的Ingress，官方称其为：Traefik is an Edge Router that makes publishing your services a fun and easy experience.
它具有许多有用的功能：连续更新配置（不重新启动），支持多种负载平衡算法，Web UI，指标导出，支持各种协议，REST API，Canary版本等。开箱即用的“Let's Encrypt”支持是另一个不错的功能。而且在2.0版本已经支持了TCP / SSL，金丝雀部署和流量镜像/阴影等功能，社区非常活跃。
Istio Ingress
istio.io/docs/tasks/traffic-management/ingress
Istio是IBM，Google和Lyft（Envoy的原始作者）的联合项目，它是一个全面的服务网格解决方案。它不仅可以管理所有传入的外部流量（作为Ingress控制器），还可以控制集群内部的所有流量。在幕后，Istio将Envoy用作每种服务的辅助代理。从本质上讲，它是一个可以执行几乎所有操作的大型处理器。其中心思想是最大程度的控制，可扩展性，安全性和透明性。
借助Istio Ingress，您可以微调流量路由，服务之间的访问授权，平衡，监控，金丝雀发布等.
不过社区现在更推荐使用Ingress Gateways。
HAProxy Ingress
github.com/jcmoraisjr/haproxy-ingress
HAProxy作为王牌的负载均衡器，在众多控制器中最大的优势还在负载均衡上。
它提供了“软”配置更新（无流量丢失），基于DNS的服务发现，通过API的动态配置。
HAProxy还支持完全自定义配置文件模板（通过替换ConfigMap）以及在其中使用Spring Boot函数。
APISIX Ingress
github.com/api7/ingress-controller
ApiSix Ingress是一个新兴的Ingress Controller，它主要对标Kong Ingress。
它具有非常强大的路由能力、灵活的插件拓展能力，在性能上表现也非常优秀。同时，它的缺点也非常明显，尽管APISIX开源后有非常多的功能，但是缺少落地案例，没有相关的文档指引大家如何使用这些功能。
下面附一张对比图：
这里还有一个更全的对比方案：
https://docs.google.com/spreadsheets/d/1DnsHtdHbxjvHmxvlu7VhzWcWgLAn_Mc5L1WlhLDA__k/edit#gid=0
写在最后
每个控制器都有自己的优缺点，在选型的时候除了参考上面的标准外，还应考虑：
适合公司的才是最好的，一切不是为了用而用，而是因为需要而用。
