lua 多条件_ingress控制器那么多，到底该选哪一个？累觉不爱。

在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

写在最后

每个控制器都有自己的优缺点，在选型的时候除了参考上面的标准外，还应考虑：

• 技术人员的技术栈、维护能力
• 公司业务的真实诉求

适合公司的才是最好的，一切不是为了用而用，而是因为需要而用。

参考链接：

• https://kubedex.com/ingress/
• https://juejin.cn/post/6844904064895942663
• https://zhuanlan.zhihu.com/p/87735361