在Kubernetes中,service IP和Pod IP主要供集群内部访问使用,对于集群外部是不可见的。

如果要从集群外部访问,常用是的以下3种方式。

(1)通过NodePort方式

如下图:
image.png
我们忽略具体的实现细节,通过NodePort的方式会在所有的Node节点上映射一个端口,端口范围默认是30000-32767。然后用户通过任意主机+映射端口来访问集群内部。

这种方式的优点是实现方式比较简单,缺点是如果映射的端口太多不好管理,每一个端口只能提供一种服务,还有以此生成的iptables规则也很多。

(2)通过LoadBalancer方式

如下图:
image.png
从图种可以看到Load Balancer服务暴露服务非常直接,直接把服务暴露到Internet,通往指定端口的流量都会被转发到对于的服务,它没有过滤条件、没有规则等。

这种方式最大的缺点就是每个LoadBalancer都需要一个固定的IP,而且更多情况下是需要云产商的支持。

(3)通过Ingress方式

如下图:
image.png
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开源后有非常多的功能,但是缺少落地案例,没有相关的文档指引大家如何使用这些功能。

下面附一张对比图:
12.1、Ingress选型 - 图4

图片来自腾讯云社区分享
_
这里还有一个更全的对比方案:https://docs.google.com/spreadsheets/d/1DnsHtdHbxjvHmxvlu7VhzWcWgLAn_Mc5L1WlhLDA__k/edit#gid=0

写在最后

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

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

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

参考链接: