Kubernetes的Ingress控制器比较
翻译：https://medium.com/flant-com/comparing-ingress-controllers-for-kubernetes-9b397483b46b
注意：此比较是受kubedex.com文章的启发，该文章一直缺少我们需要的一些实际数据。请检查它以及本文结尾处列出的其他有用链接。
标准
为了进行高质量的比较并获得有用的结果，你必须对主题有一个很好的了解，但这还不是全部。你还需要一套特定的条件来设置研究载体。我们不假装分析所有可能的Kubernetes Ingress/API网关/服务网格用例，但尝试强调控制器的最常见要求。要成功完成你自己的案例，还必须研究每种情况的所有细节和特殊性。
让我们从非常普遍的功能入手，以至于所有解决方案都已实现了这些功能，因此不予考虑：
- 开源（我们只是不想在K8s堆栈的这一级别上拥有其他选项）；
- 动态服务发现；
- SSL终止；
- 对WebSocket的支持。
现在，我们要进行比较：
支持的协议
这是做出选择的基本参数。常规的HTTP(S)代理足以满足您的软件要求吗？还是通过gRPC，HTTP/2.0工作？也许它还需要TCP（带有SNI）或UDP？如果您的场景是非标准的，请确保进行了仔细考虑，以免以后再配置集群。每个控制器都有其自己的一组受支持的协议。
依赖（基础软件）
控制器的核心可以有几种类型的应用程序。最受欢迎的是NGINX，Traefik，HAProxy，Envoy。通常，选择可能不会严重影响您的流量处理方式，但是了解“潜在用户”的潜在特征和习惯总是很有用的。
流量路由
将流量路由到特定服务的决定的依据是什么？通常，可以使用主机和路径，但是还有其他可能性。匹配这些值是否也支持RegEx（正则表达式）？
命名空间限制
命名空间提供了一种逻辑上分离Kubernetes中资源的方法（例如，在生产，暂存等之间）。必须在每个名称空间中分别安装Ingress控制器（它们仅允许流量进入属于该名称空间的Pod）。并且有一些（实际上是绝大多数）在整个集群中全局运行。在这种情况下，流量可以去往任何Pod，而不管其名称空间如何。
上游探针
您如何将流量定向到应用程序及其服务的正常实例？有主动和被动检查，重试，熔断器，自定义运行状况检查等解决方案。如果对可用性有严格的要求并迅速从负载平衡中删除失败的服务，则这是一个非常重要的参数。
负载均衡算法
在这里，我们有很多选择，从传统的轮询到rdp-cookie等非常规的选择。粘性会话在此类别中也很常见。
认证方式
控制器支持哪些授权方案？基本，摘要，OAuth，外部身份验证...我想，你已经知道它们。如果我们为开发人员使用许多环境（层）和/或仅通过Ingress访问的私有层，则这是一个重要参数。
流量分发
控制器是否支持常用的流量分配机制，如金丝雀部署，A / B测试，镜像/阴影？对于需要精确和仔细的流量管理以进行富有成效的测试，调试生产错误且影响最小，流量分析等的应用程序，这是一个非常敏感的主题。
付费订阅
控制器是否有带扩展功能和/或技术支持的付费版本？
图形用户界面（Web UI）
有没有用于控制器配置的图形界面？对于那些希望使用便利和/或需要对Ingress的配置进行一些更改，而又希望避免使用“原始”模板的用户而言，这一点很重要。如果开发人员想“即时”测试流量，它也很有用。
JWT验证
是否有内置的JSON Web令牌验证，用于对最终应用程序的用户进行验证和验证？
定制配置
在具有允许您将自己的指令，标志等添加到标准配置模板的机制的意义上，模板具有可扩展性。
基本的DDOS保护机制
基本速率限制算法或基于地址，白名单，国家/地区等的流量过滤的更复杂的变体。
请求跟踪
能够通过OpenTracing或其他选项监视，跟踪和调试从Ingress到特定服务/容器（最好在服务/容器之间）的请求。
WAF
支持Web应用程序防火墙。
Ingress控制器
控制器列表已从Kubernetes官方文档开始，并扩展了其他知名选项。但是，由于特定的性质或较低的知名度/开发的早期阶段，其中的一些被排除在外。其余内容在下面进行了检查。我们将从总体描述开始，并在最后提供摘要表。
Kubernetes Ingress控制器
- github.com/kubernetes/ingress-nginx
- 语言实现：Go/Lua（而Nginx用C编写）
- 许可证：Apache 2.0
Kubernetes的“官方”控制器。它是由社区开发的。您可能会从名称中猜到，它基于nginx Web服务器，并补充了一组用于实现额外功能的Lua插件。
由于NGINX的普及以及在用作控制器时对其进行的最小改动，对于处理K8的普通工程师来说，它可能是最简单，最直接的选择。
NGINX Ingress控制器
- github.com/nginxinc/kubernetes-ingress
- 语言实现：Go/Python
- 许可证：Apache 2.0
这是NGINX开发人员的官方产品，该产品也具有基于NGINX Plus的商业版本。NGINX控制器具有很高的稳定性，持续的向后兼容性，没有任何第三方模块，并且由于消除了Lua代码而保证了较高的速度（与官方控制器相比）。
即使与官方控制器相比，免费软件版本也受到很大限制（由于缺少上述Lua模块）。同时，付费版本具有相当广泛的附加功能：实时指标，JWT验证，活动的运行状况检查等。与NGINX Ingress相比，重要的优势是对TCP / UDP流量的全面支持（在社区版本中也是如此！）。主要缺点是缺乏交通分配功能，尽管这项工作似乎正在进行中。
Kong
- github.com/Kong/kubernetes-ingress-controller
- 语言实现：Go
- 许可证：Apache 2.0
Kong Ingress由Kong Inc开发，并且有两个版本：商业版本和免费版本。Kong Ingress建立在NGINX之上，并增加了扩展其功能的Lua模块。
最初，它作为API网关专注于API请求的处理和路由。但是，到目前为止，它已成为成熟的Ingress控制器。它的主要优点是易于安装和配置的大量其他模块/插件（包括来自第三方开发人员的模块/插件）。它为多种附加功能开辟了道路。附带地，内置功能已经提供了许多可能性。使用CRD执行配置。
Kong的一个重要功能是它只能在一个环境中运行（而不是支持跨命名空间）。这是一个颇具争议的话题：有些人认为它是一个缺点（必须为每个环境生成实例），而另一些人则认为它是一项特殊功能（较高的隔离度，因此一个控制器的故障影响仅限于其环境） ）。
Traefik
- github.com/containous/traefik
- 语言实现：Go
- 许可证：MIT
最初，此代理是为微服务请求及其动态环境的路由而创建的，因此具有许多有用的功能：连续更新配置（不重新启动），支持多种负载平衡算法，Web UI，指标导出，支持各种协议，REST API，Canary版本等。开箱即用的“让我们加密证书”支持是另一个不错的功能。主要缺点是，为了组织控制器的高可用性，您必须安装并连接其自己的KV存储器。
虽然许多不错的新功能（包括带有SNI的TCP / SSL，金丝雀部署和流量镜像/阴影，改进的Web UI）已经在Traefik v2.0的新版本（19年9月）中发布，但其中一些功能（例如WAF支持）已经发布还在讨论中。
19年9月，引入了来自同一开发商的另一种服务网格解决方案。它被称为Maesh，建在Traefik的顶部。
HAProxy
- github.com/jcmoraisjr/haproxy-ingress
- 语言实现：Go（而HAProxy用C编写）
- 许可证：Apache 2.0
HAProxy是众所周知的代理服务器和负载平衡器。作为Kubernetes集群的一部分，它提供了“软”配置更新（无流量丢失），基于DNS的服务发现，通过API的动态配置。HAProxy还支持完全自定义配置文件模板（通过替换ConfigMap）以及在其中使用Spring Boot函数。通常，开发人员将重点放在已消耗资源的高速，优化和效率上。HAProxy的优点之一是大量受支持的平衡算法。
值得一提的是，在最近的（June'19）v2.0版本中出现了许多新功能，并且即将推出的v2.1有望具有更多的新功能（包括OpenTracing支持）。
Voyager
- github.com/appscode/voyager
- 语言实现：Go
- 许可证：Apache 2.0
Voyager基于HAProxy，并作为通用解决方案提供，适合大量提供商使用。它的显着特点包括L7和L4流量均衡。通过一切手段，航海者TCP L4流量平衡可能被称为该解决方案的主要特点之一。
虽然完整的HTTP / 2和GRPC协议的支持已经在今年早些时候出现（与V9.0.0版本），为支持证书管理的（支持让的加密证书）可能是从那时起集成在航海最新的突出特点。
Contour
- github.com/heptio/contour
- 语言实现：Go
- 许可证：Apache 2.0
Contour不仅基于Envoy，而且还与该流行代理的作者共同开发。通过特殊的CRD（称为IngressRoute的新API）管理Ingress资源的能力是其特殊功能。对于具有多个开发团队并发使用一个集群的组织，这有助于保护相邻环境中的流量并保护它们免受Ingress资源更改时产生的错误的影响。
它还提供了一组扩展的平衡算法（镜像，自动重复，限制请求率等等），详细的流量和故障监控。对于某些人来说，也许缺少对粘性会议的支持将是一个严重的缺陷（朝这个方向的持续努力已经走了很长一段路）。
Istio
- istio.io/docs/tasks/traffic-management/ingress
- 语言实现：转到
- 许可证：Apache 2.0
Istio是IBM，Google和Lyft（Envoy的原始作者）的联合项目，它是一个全面的服务网格解决方案。它不仅可以管理所有传入的外部流量（作为Ingress控制器），还可以控制集群内部的所有流量。在幕后，Istio将Envoy用作每种服务的辅助代理。从本质上讲，它是一个可以执行几乎所有操作的大型处理器。其中心思想是最大程度的控制，可扩展性，安全性和透明性。
借助Istio Ingress，您可以微调流量路由，服务之间的访问授权，平衡，监控，金丝雀发布等。
这里是学习Istio的精彩介绍：“ 使用Istio返回微服务 ”。
Ambassador
- github.com/datawire/ambassador
- 语言实现：Python
- 许可证：Apache 2.0
大使是另一个基于特使的解决方案。它有免费和商业版本。大使被描述为“微服务的Kubernetes原生API网关”，它带来了相应的好处-例如与K8s原语的紧密集成。它具有Ingress控制器所期望的功能，也可以与各种服务网格解决方案（Consul，Linkerd，Istio）一起使用。
顺便说一下，大使工程师最近发布了他们的基准测试结果，比较了Envoy（如Ambassador Pro），HAProxy和NGINX（如社区的官方Kubernetes Ingress）的性能。
Gloo
- github.com/solo-io/gloo
- 实施于：Go
- 许可证：Apache 2.0
Gloo是在Envoy之上构建的新软件（于18年3月发布），被称为“功能网关”，因为其作者坚持认为“网关应从功能而非服务中构建API 。”其“功能级路由”的意思是它可用于为后端为微服务，无服务器功能和/或旧版应用程序实现的混合应用程序路由流量。
Gloo具有可插拔的体系结构，可提供您可能期望的大多数功能，但是其中一些功能仅在其商业版本（Gloo Enterprise）中可用。它的文档说明了如何轻松地将它与Linkerd＆Istio等服务网格解决方案集成。
Skipper
- github.com/zalando/skipper
- 语言实现：Go
- 许可证：Apache 2.0
Skipper是HTTP路由器和反向代理，因此不支持多种协议（例如，添加gRPC时没有热情）。从技术上讲，它使用Endpoints API（而不是Kubernetes Services）将流量路由到Pod。它的巨大优势是通过其丰富的过滤器集可以创建，更新和删除所有HTTP数据的高级HTTP路由功能。船长的路由规则可以在不停机的情况下进行更新。正如Skipper的作者所言，它可以很好地与其他解决方案一起使用，例如提供其他功能的AWS ELB（与其他Ingress解决方案相比）。
这是 Skipper与它的作者（Zalando）制作的其他Kubernetes Ingress控制器的比较。
其他注意事项
在这里有Traefik和Istio时，您可能会注意到缺少另一个流行的服务网格解决方案-Linkerd。不列出的原因如下：
为简单起见，Linkerd不提供其自己的入口控制器。相反，Linkerd旨在与您选择的入口控制器一起使用。
比较表
本文的结尾是这个巨大的摘要表：
您可以单击它以进行更详细的查看。该表还提供Google表格格式。
摘要
本文的目的是提供对每种特定情况下可以完成的操作的更完整的理解（尽管一点也不详尽！）。通常，每个控制器都有其优点和缺点。
Kubernetes官方Ingress易于使用，成熟，并提供了足以满足大多数情况的出色功能。如果对可靠性和功能实现的质量有很高的要求，则应注意基于NGINX Plus的Ingress商业版本。Kong拥有最丰富的插件集（以及它们提供的机会），并且在其商业版本中提供了更多功能，它还拥有基于自定义资源的动态配置。
看看Traefik和HAProxy的如果有增加了平衡和授权方法的要求。它们是开源项目，多年来证明了自己的功能，非常稳定且不断发展。Contour已经存在了两年，但它看起来仍然很年轻，并且主要具有Envoy之上的基本功能。如果您需要在应用程序前面安装WAF，请注意Kubernetes或HAProxy使用的旧Ingress。
基于Envoy的产品具有最丰富的功能集（尤其是Istio）。这是一个复杂的解决方案，“几乎可以做任何事。”顺便说一句，这意味着需要更广泛的相关经验来配置/运行/操作它们。在某些其他情况下（Gloo），其许多功能可能仅在付费版本中提供。如果您的应用程序需要高级或经常更改的HTTP路由表，那么Skipper可能是一个很好的解决方案。
如果我们谈论什么全球K8S社区选择的发展趋势，Istio和Traefik的优势是显而易见的 - 甚至是“官方” Kubernetes入口是明显落后的时候，我们比较的GitHub星（25000+，几乎对20000小于6000相应）。Kong Ingress和HAProxy Ingress位于相对数量最少的恒星（小于1000）。
其他要参考的文章/评论
如果您选择Ingress解决方案，以下是一些其他文章可能会有用：
- 入口由kubedex -一个漂亮的表（用简短的文字）比较NGINX入口，香港，Traefik，HAProxy的，航海家，轮廓，大使，Istio入口，GLOO独奏（我们已经使用此表来选择我们的比较选项） ;
- 按第5层划分的服务网格格局—通过众多参数（包括受支持的协议，多集群和多租户功能，Prometheus和跟踪集成）比较了大量的服务网格（以表格形式显示）（约有30个！）；
- 我的Kubernetes环境最适合的入口控制器是什么？（由TFiR 撰写于19年5 月） -NGINX Ingress（来自社区和NGINX Inc），Envoy，Kong，Google Cloud和AWS解决方案，Citrix Ingress的文字比较；
- Cayent的Kubernetes顶级入口控制器比较（19年9月） – Kong，Traefik，HAProxy，Istio Ingress，Nginx和大使的简短文本比较；
- Kubernetes入口控制器：如何选择合适的控制器：ITNEXT的第1部分 -Nginx入口控制器与AWS ALB入口控制器的相当深入的文字比较。
转自：https://zhuanlan.zhihu.com/p/87735361