K8s 工程师必懂的 10 种 Ingress 控制器

vlambda
2021-01-29

K8s 工程师必懂的 10 种 Ingress 控制器

今年 2 月，社区曾推送了一篇文章：《》。但当时只介绍了两种解决方案。为了帮助读者对 Ingress Controler 建立更完整的认识，今天，社区对现下流行的十种方案做了具体介绍。

翻译：bot（才云）

技术校对：星空下的文仔（才云）

为特定的应用部署 Kubernetes 集群时，我们通常需要实现来自应用程序本身、业务和开发人员的需求。了解这些后，我们就可以进行架构选择，并为 Kubernetes 选择合适的 Ingress 控制器。

为了方便工程师高效选用合适的 Ingress 控制器，本文对业内的 Ingress 控制器做了整理和功能梳理，最后总结成一篇综述。借助这篇文章，希望读者能找到一个好的起点，然后开始自己的实践。

K8s 工程师必懂的 10 种 Ingress 控制器

K8sMeetup

选择标准

为了进行客观对比并得到有用的结果，首先我们需要一套特定的标准来确定研究方向。注意，以下评测并不能涵盖所有 Kubernetes Ingress、API 网关、服务网格用例，但会尽可能覆盖常见要求。如果读者希望把评测结果用于自己的案例，建议结合自己的实践再研究一下细节和特殊性。

首先是一些非常普遍的功能，所有解决方案都已实现了它们，所以你不需要对它们过多关注：

开源；
动态服务发现；
SSL 终止；
对 WebSocket 的支持。

支持的协议

这就像是工程师选择 Ingress 控制器时的基本“参数”。常规的 HTTP(S) 代理能够满足软件要求吗？还是需要通过 gRPC、HTTP/2.0？或是需要 TCP（带有 SNI）、UDP？如果你的情况不是特别常规，建议仔细考虑这些问题，防止以后需要重新配置集群。每个控制器都有自己的一组受支持的协议。

基于（基础软件）

控制器的核心可以有几种类型的应用程序，比如最受欢迎的 NGINX、Traefik、HAProxy 和 Envoy 等。通常情况下，这些选择不会对你的流量处理方式产生巨大影响，但是了解“底层”的潜在特性和习惯总是有用的。

流量路由

将流量路由到特定服务的决策依据是什么？通常你可以用 host 和 path，但也有其他的可能性。匹配这些值是否也支持 RegEx（正则表达式）？

命名空间限制

命名空间提供了一种逻辑上分离 Kubernetes 中资源的方法。有些 Ingress 控制器必须被装在不同的命名空间中，它们的作用是仅允许流量进入属于该命名空间的 Pod。而大多数 Ingress 控制器是针对整个集群进行全局操作的，在这种情况下，流量可以到达任何 Pod，而无需考虑其命名空间。

上游探针

如何将流量定向到应用程序及其服务的正常实例？通常你有主动和被动检查、重试、断路器、自定义运行状况检查等解决方案。如果你对可用性有严格的要求，并希望迅速从负载均衡中删除失败的服务，这个功能非常重要。

负载均衡算法

对于负载均衡我们有很多选择，从传统的 round-robin 到非传统的 rdp-cookie。粘滞会话（Sticky Sessions）在这里也很常见。

认证方式

控制器支持哪些认证方式？Basic、digest、OAuth、external auth……如果你为开发人员使用了许多环境（层），或仅通过 Ingress 访问的私有层，这是个值得注意的功能。

流量分配

控制器是否支持常用的流量分配机制，如金丝雀部署、A/B 测试、镜像？对于需要精确流量管理、高效测试、最小影响进行错误调试、流量管理的应用来说，这个功能非常敏感。

付费订阅

控制器是否有带扩展功能或技术支持的付费版本？

图形用户界面（Web UI）

有用于控制器配置的图形界面吗？这个功能对于那些喜欢简单方便，或是需要对 Ingress 配置做一些更改的人很有用。如果开发人员希望“即时”测试流量，它也非常有用。

JWT 验证

是否有内置的 JSON Web 令牌验证，用于对最终应用程序的用户进行验证和确认？

定制配置

模板是否具备可扩展性，允许你将自己的指令、参数等添加到标准配置模板上？

基本的 DDOS 保护机制

请求跟踪

能够通过 OpenTracing 或其他选项监视、跟踪、调试从 Ingress 到特定服务、Pod（最好是在服务和 Pod 之间）的请求。

WAF

支持 Web 应用程序防火墙。

K8sMeetup

Ingress 控制器

这一节将从 Kubernetes 官方控制器开始，逐渐扩展到其他广为人知的 Ingress 控制器。

Kubernetes Ingress Controller

github.com/kubernetes/ingress-nginx

实现：Go/Lua（nginx 是用 C 写的）

许可证：Apache 2.0

Kubernetes 的“官方”控制器（之所以称为官方，是想把它区别于 NGINX 公司的控制器）。这是社区开发的控制器，它基于 nginx Web 服务器，并补充了一组用于实现额外功能的 Lua 插件。

由于 NGINX 十分流行，再加上把它用作控制器时所需的修改较少，它对于 K8s 普通工程师来说，可能是最简单和最直接的选择。

NGINX Ingress Controller

github.com/nginxinc/kubernetes-ingress

实现：Go

许可证：Apache 2.0

这是 NGINX 公司开发的官方产品，它也有一个基于 NGINX Plus 的商业版。 NGINX 的控制器具有很高的稳定性、持续的向后兼容性，且没有任何第三方模块。

由于消除了 Lua 代码，和官方控制器相比，它保证了较高的速度，但也因此受到较大限制。相较之下，它的付费版本有更广泛的附加功能，如实时指标、JWT 验证、主动健康检查等。

NGINX Ingress 重要的优势是对 TCP/UDP 流量的全面支持，最主要缺点是缺乏流量分配功能。

Kong Ingress

github.com/Kong/kubernetes-ingress-controller

实现：Go

许可证：Apache 2.0

Kong Ingress 由 Kong Inc 开发，有两个版本：商业版和免费版。它基于 NGINX 构建，并增加了扩展其功能的 Lua 模块。

最初，Kong Ingress 主要用作 API 网关，用于 API 请求的处理和路由。现在，它已经成为成熟的 Ingress 控制器，主要优点是拥有大量易于安装和配置的附加模块、插件（包括第三方插件）。它开启了控制器具备大量附加功能的先河，其内置函数也提供了许多可能性。 Kong Ingress 配置是用 CRD 执行的。

Kong Ingress 的一个重要特性是它只能在一个环境中运行（而不支持跨命名空间）。这是一个颇有争议的话题：有些人认为这是一个缺点，因为必须为每个环境生成实例；而另一些人认为这是一个特殊特性，因为它是更高级别的隔离，控制器故障的影响仅限于其所在的环境。

Traefik

github.com/containous/traefik

实现：Go

许可证：MIT

最初，这个代理是为微服务请求及其动态环境的路由而创建的，因此具有许多有用的功能：连续更新配置（不重新启动）、支持多种负载均衡算法、Web UI、指标导出、对各种服务的支持协议、REST API、Canary 版本等。

支持开箱即用的 Let's Encrypt 是它的另一个不错的功能，但它的主要缺点也很明显，就是为了控制器的高可用性，你必须安装并连接其 Key-value store。

在 2019 年 9 月发布的 Traefik v2.0 中，虽然它增加许多不错的新功能，如带有 SNI 的 TCP/SSL、金丝雀部署、流量镜像/shadowing 和经过改进的 Web UI，但一些功能（如 WAF 支持）还在策划讨论中。

与新版本同期推出的还有一个名叫 Maesh 的服务网格，它建在 Traefik 之上。

HAProxy Ingress

github.com/jcmoraisjr/haproxy-ingress

实现：Go（HAProxy 是用 C 写的）

许可证：Apache 2.0

HAProxy 是众所周知的代理服务器和负载均衡器。作为 Kubernetes 集群的一部分，它提供了“软”配置更新（无流量损失）、基于 DNS 的服务发现和通过 API 进行动态配置。 HAProxy 还支持完全自定义配置文件模板（通过替换 ConfigMap）以及在其中使用 Spring Boot 函数。

通常，工程师会把重点放在已消耗资源的高速、优化和效率上。而 HAProxy 的优点之一正是支持大量负载均衡算法。值得一提的是，在今年 6 月发布的 v2.0 中，HAProxy 增加了许多新功能，其即将推出的 v2.1 有望带来更多新功能（包括 OpenTracing 支持）。

Voyager

github.com/appscode/voyager

实现：Go

许可证：Apache 2.0

Voyager 基于 HAProxy，并作为一个通用的解决方案提供给大量供应商。它最具代表性的功能包括 L7 和 L4 上的流量负载均衡，其中，TCP L4 流量负载均衡称得上是该解决方案最关键的功能之一。

在今年早些时候，尽管 Voyager 在 v9.0.0 中推出了对 HTTP/2 和 gRPC 协议的全面支持，但总的来看，对证书管理（Let's Encrypt 证书）的支持仍是 Voyager 集成的最突出的新功能。

Contour

github.com/heptio/contour

实现：Go

许可证：Apache 2.0

Contour 和 Envoy 由同一个作者开发，它基于 Envoy。它最特别的功能是可以通过 CRD（IngressRoute）管理 Ingress 资源，对于多团队需要同时使用一个集群的组织来说，这有助于保护相邻环境中的流量，使它们免受 Ingress 资源更改的影响。

它还提供了一组扩展的负载均衡算法（镜像、自动重复、限制请求率等），以及详细的流量和故障监控。对某些工程师而言，它不支持粘滞会话可能是一个严重缺陷。

Istio Ingress

istio.io/docs/tasks/traffic-management/ingress

实现：Go

许可证：Apache 2.0

Istio 是 IBM、Google 和 Lyft 的联合开发项目，它是一个全面的服务网格解决方案——不仅可以管理所有传入的外部流量（作为 Ingress 控制器），还可以控制集群内部的所有流量。

Istio 将 Envoy 用作每种服务的辅助代理。从本质上讲，它是一个可以执行几乎所有操作的大型处理器，其中心思想是最大程度的控制、可扩展性、安全性和透明性。

通过 Istio Ingress，你可以对流量路由、服务之间的访问授权、均衡、监控、金丝雀发布等进行优化。

Ambassador

github.com/datawire/ambassador

实现：Python

许可证：Apache 2.0

Ambassador 也是一个基于 Envoy 的解决方案，它有免费版和商业版两个版本。

Ambassador 被称为“Kubernetes 原生 API 微服务网关” ，它与 K8s 原语紧密集成，拥有你所期望的从 Ingress controller 获得的功能包，它还可以与各种服务网格解决方案，如 Linkerd、Istio 等一起使用。

顺便提一下，Ambassador 博客日前发布了一份基准测试结果，比较了 Envoy、HAProxy 和 NGINX 的基础性能。

Gloo

github.com/solo-io/gloo

实现：Go

许可证：Apache 2.0

Gloo 是在 Envoy 之上构建的新软件（于 2018 年 3 月发布），由于它的作者坚持认为“网关应该从功能而不是服务中构建 API”，它也被称为“功能网关”。其“功能级路由”的意思是它可以为后端实现是微服务、无服务器功能和遗留应用的混合应用路由流量。

由于拥有可插拔的体系结构，Gloo 提供了工程师期望的大部分功能，但是其中一些功能仅在其商业版本（Gloo Enterprise）中可用。

Skipper

github.com/zalando/skipper

实现：Go

许可证：Apache 2.0

Skipper 是 HTTP 路由器和反向代理，因此不支持各种协议。从技术上讲，它使用 Endpoints API（而不是 Kubernetes Services）将流量路由到 Pod。它的优点在于其丰富的过滤器集所提供的高级 HTTP 路由功能，工程师可以借此创建、更新和删除所有 HTTP 数据。

Skipper 的路由规则可以在不停机的情况下更新。正如它的作者所述，Skipper 可以很好地与其他解决方案一起使用，比如 AWS ELB。

其他

文章介绍了 Traefik 和 Istio，却没有详细介绍另一个流行的服务网格解决方案 Linkerd。这是为什么呢？

为简单起见，Linkerd 没有提供自己的 Ingress 控制器，而是旨在和工程师选用的控制器兼容使用。