Kubernetes Ingress Controller 概览


本文比较了目前市面上主流的Kubernetes Ingress Controller,并列出了选择一个适合的方案需要考量的因素。

尽管Kubernetes早在2014年6月就发布了第一个版本,但读者可能会惊讶地发现都迭代到Kubernetes v1.18版本了,Kubernetes Ingress API仍处于beta版本。自2016年初(Kubernetes v1.2)进入beta迭代以来,Ingress API一直都非常注重可移植性,并且始终保持轻量。在去年的KubeCon North America 2019上,IBM的Christopher Luciano和Google的Bowei Du在“Evolving the Kubernetes Ingress APIs to GA and Beyond”上作了详细介绍,Ingress API进行了多项改进(例如,更好的路径匹配,新的IngressClass资源定义,主机名通配符)。随着Ingress API在v1.19中逐步升级到GA,笔者对市面上较常见的Ingress Controller进行了全面的比较,并给出了在选择解决方案时的要注意的关键事项。

免责声明本文是是基于个人经验,公开信息和博客文章的总结。并没有完整列出市面上所有Ingress Controller。另外,由于技术发展迅速,本文的信息可能会过时。如果您发现任何不正确的地方,请在文后发表评论,笔者会尽快进行更新。

Ingress vs. Ingress Controller

在深入各种Ingress Controller之前,我们先快速回顾一下Kubernetes Ingress的概念以及Ingress Controller的作用。为了暴露业务应用给外部访问,Kubernetes提供了三种服务类型:
  • ClusterIP:为方便应用在集群内通信创建的IP
  • NodePort:为应用在每个工作节点上映射一个固定端口,以将集群外的调用路由到集群内的应用上
  • LoadBalancer:创建外部负载均衡器以将外部请求路由到集群内服务


Ingress有别于Kubernetes Service,它主要用于将服务公开给外部请求。与LoadBalancer或NodePort相比,Ingress的优势在于可以将路由规则合并到单个资源中,从而暴露多个业务应用。严格来说,Ingress是定义流量路由规则(例如,负载均衡,SSL卸载,基于路径的路由,网络协议)的API对象,而Ingress Controller是负责处理这些规则变化的组件。
1.png

Ingress Controller

Kubernetes项目官方目前维护了GLBC(GCE L7 Balancer)和ingress-nginx控制器。除非你在像GKE这样的环境中安装集群(默认情况下集成安装GLBC),一般来说需要单独安装Ingress Controller。本文会比较市面上常见的选项,先着重介绍特定云服务商的Ingress Controller,然后探讨其他开源的方案。

云服务商提供的 Ingress Controller

目前三个主流的云服务商都积极支持和维护与自家的负载均衡器产品兼容的Ingress Controller:


使用特定云服务商的Ingress Controller的优势,主要体现在可以比较容易地与服务商的其他云服务产品集成。例如,GCE Ingress Controller支持Cloud IAP for Google Kubernetes Engine,一键启用身份识别代理,从而保护Kubernetes内部应用程序(如Vault,Prometheus,Grafana,请参阅此处的监控设置教程)。ALB Ingress Controller在默认情况下会创建一个Application Load Balancer(与用于其他开源Ingress Controller的Network Load Balancer类似),并且可与Route 53,Cognito和AWS WAF可以很好地集成。同样,如果用户使用了Azure Pipelines在Azure上管理DevOps流程,则AKS Application Gateway Ingress Controller非常适用于Azure CI/CD工作流。

另一方面,如果用户采用混合或多云部署环境,则使用下文列出的开源的Ingress Controller解决方案,会比在不同云环境中维护多个不同的Ingress Controller要容易。除AKS AGIC外,其他两家都不支持跨命名空间Ingress,这就意味着必须为每个命名空间创建一个新的GCE Ingress或ALB Ingress。如果集群中有多个不同的租户且包含了多个命名空间,那Ingress资源(即外部L7负载平衡器)加上静态IP就是一笔不菲的开销。最后一点,由于这些Ingress在创建时会涉及到全局(或多区域)的负载均衡器(尤其是在GKE中)变更,往往附带了更严格的健康状态检查逻辑,因此创建和更新这些Ingress资源耗时更长。

总体而言,Azure上的AGIC,AWS上的ALB和GKE上的GLBC/GCE提供了出色的性能,原生的L7路由以及与自家其他云产品的良好集成。GLBC在GKE上是开箱即用的,因此,如果用户只是在寻找HTTP/S路由解决方案,这是个不错的第一选择。

开源的Ingress Controller

除了特定于云服务商的入口控制器外,Kubernetes网站还维护了一个常用的第三方解决方案列表:
  • Ambassador:基于Envoy的API网关,开源版有社区维护,商业版则由Datawire提供支持
  • Voyager:来自AppsCode的基于HAProxy的Ingress Controller
  • Contour:来自VMWare旗下Heptio公司,基于Envoy的Ingress Controller
  • Gloo:基于Envoy的API网关, solo.io提供企业支持
  • Citrix:服务于MPX,VPX and CPX ADC产品的Ingress Controller
  • F5:提供F5的BIG-IP Container Ingress服务的Ingress Controller
  • HAProxy:社区驱动的HAProxy Ingress Controller ,同时由HAProxy Tech提供企业支持
  • Istio:适用于启用了Istio的Ingress网关
  • Kong:基于Nginx的API网关, 由KongHQ提供社区和企业支持
  • NGINX:官方的NGINX和NGINX Plus Ingress Controller
  • Skipper:来自Zalando的路由和反向代理控制器
  • TraefikContainous提供商业支持的http方向代理控制器


根据CNCF Survey 2019的调查,在市场份额方面,Nginx和HAProxy在2019年继续保持领先地位,Envoy超过F5排名第三。目前尚不清楚该调查是否按将Ingress底层的实现技术分组(例如,Ambassador,Contour和Gloo都归属于Envoy实现),但随着Istio的普及率进一步提升,Envoy可能会成为Ingress Controller事实上的首选。
2.png

在下文中,笔者把列表中Ingress Controller根据底层实现技术(Nginx,HAProxy,Envoy等)分组介绍,并根据个人经验或其他博客文章的点评,提出一些想法。

基于NGINX实现的Ingress Controller

ingress-nginx

这是唯一一个由Kubernetes团队维护的开源Ingress Controller,底层是NGINX。得益于官方背书,它同时具备HTTP/S路由和SSL卸载的功能,是目前最受欢迎的方案之一。由于其在业内被广泛采用,ingress-nginx的配置和相关工具(例如cert-manager和external-dns)可参考文档非常多。

如果用户不需要复杂的功能,希望使用一款简单的反向代理,那么ingress-nginx是一个安全靠谱的选项。另外,如果用户需要更高性能的表现或是额外的附加功能(例如JWT验证,OpenTracing),也可以考虑改用NGINX官方维护的Ingress Controller。最后,使用ngress-nginx的默认配置,在集群规模变大之后可能会带来性能问题,因此用户应该花些心思研究NGINX如何正确设置(请参阅Eric Liu的文章,深入了解ingress-nginx。)

NGINX & NGINX Plus Ingress Controller

这是NGINX公司(现属F5)的官方Ingress Controller,支持开源和商业(NGINX Plus)两种版本。在Github链接上详细记录了Nginxinc/kubernetes-ingress和Kubernetes/ingress-nginx之间的差异。

如您所料,免费版本缺少一些关键特性(例如端点的动态配置),因为它没包含Lua插件。付费版本NGINX Plus则提供基于了cookies会话持久性,主动健康检查,JWT身份验证(OpenID SSO),实时监视和高可用。如果用户原先就有丰富的NGINX使用经验,可以很轻松地过渡到Kubernetes的场景。

Kong

Kong以作为API网关而被大多数开发者所熟知,被用于处理和路由API请求。近年来,Kong也在逐渐丰富其功能,例如原生的gRPC支持,请求/响应转换,身份验证。同时也是一款Ingress解决方案,提供了对负载均衡器的主动健康检查。与ingress-nginx不同,Kong坚持不实现跨命名空间的Ingress Controller,并指出特权提升(privilege escalation)在某些场景下会成为被攻击的目标。笔者早在一年前为GCE上的集群寻找ingress替代方案时,就拜读过Bouwe Ceunen的“为什么要从Traefik切换到Kong”这篇文章,但到目前还没有亲自实践过Kong。

基于HAProxy实现的Ingress Controller

HAProxy Ingress

HAProxy和NGINX类似,是一款早于Kubernetes问世的,久经考验的TCP/HTTP反向代理解决方案。因此,如果配置各种负载均衡策略是首要考量因素,那HAProxy Ingress作为一个行之有效的高性能解决方案,是个不错的选择。作为集群的Ingress Controller,HAProxy Ingress通过API提供动态配置更新,以避免HAProxy对静态配置文件的依赖。

Voyager

Voyager是另一款带有企业支持的基于HAProxy的Ingress Controller,其官方网站上着重强调了HTTP/TCP的L4和L7负载均衡的特性,以及可以与LetsEncrypt和AWS Certificate Manager的SSL方案无缝集成。

基于Envoy实现的Ingress Controller

Istio Ingress

Istio大量使用Envoy代理来中转服务网格内的所有流量。如果用户已经在集群中使用Istio作为服务网格解决方案,则使用默认的Istio Ingress/Gateway最有意义。它提供了流量路由,可观察性,安全性和部署模型,可与现有Istio结构和服务实现了最佳集成。但是,Istio并不是轻量级的方案,学习曲线很大,因此,如果用户只是想使用Envoy代理的特性,以下方案可以优先考虑。

Ambassador

从技术上讲,Ambassador是Kubernetes Ingress支持的API网关和L7负载均衡器。不过它特性更完备:支持各种协议(gRPC,HTTP/2,TCP,WebSockets),安全性(自动HTTPS,速率限制,自定义过滤器),高可用性(粘性会话,断路器)甚至是与Knative Serverless无缝集成。它基于Envoy,但可以与Istio以外的其他服务网格解决方案(例如Consul,Linkerd)很好兼容。benchmark results的博客上发布了Ambassador的基准测试结果,与NGINX和HAProxy相比的,其性能还是不错的,尽管已经有好几个月没有更新了。

Contour

Contour是最早使用自定义资源定义(CRD)来扩展Kubernetes Ingress API功能的Ingress控制器之一。 CRD(HTTPProxy——由IngressRoute重命名而来)主要解决了原生Kubernetes Ingress API在多租户环境中的局限性。如今,IngressRoute已在Kubernetes v1.18 +中被正式定义,Contour的原先方案可能会与Kubernetes的总体演进方向很好地融合在一起。

Gloo

Gloo通过提供所谓的“功能级路由”而与其他基于Envoy的Ingress Controller有所不同。这意味着Gloo充当Ingress和API网关时,不仅可以将流量路由到微服务,还可以路由到Serverless 服务(例如AWS Lambda,Google Cloud Functions,OpenFaaS,Knative)。它还对传统/混合架构的应用程序提供了出色的支持,在这些应用程序中,流量必须调用内部API(REST,SOAP,XML)或与消息队列进行交互(例如NATS,AMQP)。

其他

Skipper

Skipper是HTTP路由器和反向代理,其起源于2015年的Project Mosaic。其最初的设计目标是作为依赖于静态配置文件的NGINX和HAProxy的替代方案,并实现新特性支持,例如金丝雀或蓝绿色部署以及流量镜像等。作为“旧”项目,上面提到的其他Ingress Controller已经支持许多Skipper之前提出的功能。但是,由于Skipper专注于HTTP路由,因此精简了其他负载均衡器实现的许多功能(例如SSL终止,自动证书轮换,WAF集成),并可与AWS ALB很好地集成。对于那些希望迁移到Kubernetes的AWS用户而言,Skipper是一个值得考虑的选项。

Traefik

最后来谈谈Traefik,这是一个用Go编写的特性完备的HTTP反向代理和负载均衡器。 Traefik最初是为解决微服务的流量路由问题而编写的,以支持全自动和实时动态更新配置路由。因此,它支持包括Kubernetes在内一系列基础设施平台(Docker,Docker Swarm,Marathon,Consul等,Rancher,Amazon ECS)。Traefik支持HTTP/2,gRPC和WebSocket,以及多种负载均衡算法和断路器。

最初吸引我使用Traefik的原因是,它对Let's Encrypt开箱即用的集成,有界面精美的Web UI,将Traefik的运行状况和性能可视化,而这无需将指标收集到Prometheus或Datadog(尽管也支持这些集成)。 Traefik v2版本(于2019年11月发布)新增了对TCP的支持,以及SNI路由,金丝雀部署,流量镜像和IngressRoute CRD等新特性。

有关快速入门指南,请查阅Traefik v2 on Kubernetes

如何选择

市场的可供选择的方案很多,用户如何选择一款合适的Ingress Controller?一般来说,用户如果需要简单易上手的解决方案,那ingress-nginx会是个靠谱同时也是最主流的选择之一。如果考虑将Istio用作服务网格,则Istio Ingress会是不二之选;其他情况,则可以尝试基于Envoy的解决方案,能和Consul或Linkerd比较好协同。就个人而言,我将Traefik和云服务商的Ingress解决方案结合使用,这种方案可以降低延迟,方便全球/多区域部署。笔者还没有尝试过Gloo,但是随着容器和Serverless更进一步集成,它的路由功能似乎颇有吸引力。

其他考量因素:
  • 协议支持:用户是否需要TCP/UDP或是gRPC集成。
  • 企业支持:用户是否需要企业支持以保证核心系统的稳定运行。
  • 高级功能:用户是否需要定制化的需求,如轻量级的解决方案,或是金丝雀部署或断路器。
  • API网关:用户是否需要某些API网关功能(例如速率限制)还是一款单纯的Kubernetes Ingress 解决方案。


如果您需要更详细的对比详情,可以查看Kubedex上的比较表或Flant工程师的博客


原文链接:Kubernetes Ingress Controller Overview (翻译:梁斌)

0 个评论

要回复文章请先登录注册