在为特定应用程序启动Kubernetes集群时，您应该了解应用程序本身，业务和开发人员对该资源提出哪些要求。 如果您掌握了这些信息，则可以开始进行体系结构决策，尤其是选择一个特定的Ingress控制器，如今该控制器已经大量使用。 为了在不学习大量文章/文档等的情况下获得可用选项的基本概念，我们通过在其中包含主要的（生产就绪的）Ingress控制器来准备此评论。
我们希望它能帮助同事选择架构解决方案-至少它将成为更详细的信息和实际实验的起点。 以前，我们研究了网络上的其他类似材料，但奇怪的是，没有找到一个或多或少完整的，而且最重要的是结构化的评论。 因此，填补这一空白！
标准
为了原则上进行比较并获得有用的结果，您不仅需要了解主题领域，还需要了解确定研究载体的特定标准列表。 在不假装分析使用Ingress / Kubernetes的所有可能情况的情况下，我们试图强调对控制器的最一般要求-准备好在任何情况下都必须分别研究所有细节。
但是，我将从熟悉的特性开始，以至于在所有决策中都实现了这些特性，而这些特性并未被考虑：
- 动态服务发现（服务发现）；
- SSL终止；
- 使用websockets。
现在介绍比较点：
支持的协议
选择的基本标准之一。 您的软件可能无法在标准HTTP上运行，或者可能需要同时在许多协议上运行。 如果您的情况不符合标准，请确保考虑到此因素，以便以后不必重新配置群集。 对于所有控制器，支持的协议列表各不相同。
基于软件
控制器基于几个应用程序选项。 最受欢迎的是nginx，traefik，haproxy，envoy。 在一般情况下，它可能不会影响流量的接收和传输方式，但是了解“幕后”的潜在细微差别和特征总是有用的。
交通路线
根据什么我们可以决定流量到特定服务的方向？ 这通常是主机和路径，但是还有其他功能。
集群命名空间
命名空间（namespace）-逻辑上拆分Kubernetes中的资源的能力（例如，舞台，生产等）。 必须在每个命名空间中分别设置Ingress控制器（然后它
只能将流量定向到该空间的Pod）。 并且有一些（及其绝大多数）在整个集群上全局工作-在其中，流量被定向到集群的任何Pod，而与命名空间无关。
上游样品
流量如何定向到健康的应用程序，服务实例？ 有一些选项，包括主动和被动检查，重试，断路器
（有关更多详细信息，请参见有关Istio的文章 ，请参阅它们） ，自定义运行状况检查实现等。 如果您对可访问性有很高的要求，并且需要及时从天平中撤出失败的服务，则此参数非常重要。
平衡算法
有很多选择：从传统
的轮询到
rdp-cookies之类的异国情调，以及诸如
粘性会话之类的一些功能。
认证方式
控制器支持哪些授权方案？ 基本，摘要，oauth，外部身份验证-我认为这些选项应该很熟悉。 如果您为通过Ingress访问的开发人员（和/或仅是封闭的）使用大量电路，则这是一个重要标准。
流量分配
控制器是否支持诸如金丝雀推出，A / B测试，流量镜像（镜像/阴影）之类的常用流量分配机制？ 对于需要精确而准确的流量管理以进行生产测试，调试非战斗中（或损失最小）的产品错误，流量分析等的应用程序，这是一个非常痛苦的主题。
付费订阅
控制器是否有付费选项，具有高级功能和/或技术支持？
图形用户界面（Web UI）
是否有任何图形界面来控制控制器的配置？ 基本上，对于“方便”和/或需要对Ingress的配置进行一些更改的人，但是使用“原始”模板很不方便。 如果开发人员想即时进行流量实验，它可能会派上用场。
JWT验证
Web令牌的内置JSON验证的存在，用于最终应用程序的授权和用户验证。
配置自定义功能
模板的可扩展性，具有在标准配置模板中添加其自身指令，标志等的机制
基本的DDOS保护机制
简单的速率限制算法或更复杂的选项，用于根据地址，白名单，国家/地区等过滤流量。
要求追踪
可以观察，跟踪和调试从Ingress到特定服务/容器的请求，并且理想情况下也可以在服务/容器之间进行观察，跟踪和调试。
WAF
支持
应用程序防火墙 。
入口控制器
控制器列表基于
Kubernetes官方文档和
此表 。 由于它们的特异性或低患病率（开发的早期阶段），我们将其中一些排除在审查之外。 其余的讨论如下。 我们从解决方案的一般描述开始，然后再从数据透视表开始。
Kubernetes的入口
网站： github.com/kubernetes/ingress-nginx许可证：Apache 2.0这是由社区开发的Kubernetes的官方控制者。 从名称上可以明显看出，它基于nginx，并由用于实现附加功能的一组不同的Lua插件进行了补充。 由于nginx本身很受欢迎，并且在用作控制器时对其进行了最小的修改，因此该选项可能是最简单，最易懂的配置一般工程师（具有Web经验）。
NGINX Inc的入口
网站： github.com/nginxinc/kubernetes-ingress许可证：Apache 2.0Nginx开发人员的官方产品。 它具有基于
NGINX Plus的付费版本。 主要思想是高水平的稳定性，持续的向后兼容性，不存在任何无关的模块以及由于拒绝Lua而实现的声明的提高的速度（与官方控制器相比）。
免费版本已大大减少，甚至与官方控制器相比也是如此（由于缺少相同的Lua模块）。 同时付费具有相当广泛的附加功能：实时指标，JWT验证，活动的运行状况检查等等。 与NGINX Ingress相比，一个重要的优势是完全支持TCP / UDP流量（在社区版本中也是如此！）。 缺点是
缺少流量分配功能，但是“分配给开发人员的优先级最高”，但是实现起来需要时间。
孔入口
网站： github.com/Kong/kubernetes-ingress-controller许可证：Apache 2.0Kong Inc.开发的产品 有两个版本：商业版和免费版。 它基于nginx，其功能由Lua上的大量模块扩展。
最初，它专注于处理和路由API请求，即 类似于API网关，但目前它已成为功能完善的Ingress控制器。 主要优点：许多易于安装和配置的附加模块（包括来自第三方开发人员的模块），并具有多种附加功能。 但是，内置功能已经提供了许多功能。 使用CRD资源完成工作配置。
该产品的一项重要功能-在同一电路中工作（而不是使用交叉命名间隔）是一个有争议的主题：对于某些情况来说，这似乎是一个缺点（您必须为每个电路产生实体），而对于某些人来说，这是一个功能（更高的隔离度，因为如果一个控制器损坏，则问题仅限于一个电路。
特拉菲克
网站： github.com/containous/traefik执照：麻省理工学院最初创建的代理是用于微服务请求及其动态环境的路由。 因此，有许多有用的功能：无需重新启动即可完全更新配置，支持大量的平衡方法，Web界面，转发指标，支持各种协议，REST API，canary版本等等。 开箱即用的“让我们加密证书”也是一项不错的功能。 缺点是对于组织高可用性（HA），控制器将需要安装并连接其自己的KV存储。
HAProxy
网站： github.com/jcmoraisjr/haproxy-ingress许可证：Apache 2.0HAProxy长期以来一直被称为代理和流量平衡器。 作为Kubernetes集群的一部分，它提供了“软”配置更新（不丢失流量），基于DNS的服务发现，使用API的动态配置。 通过替换CM'a来完全自定义配置模板以及在其中使用Sprig库功能的可能性可能会变得有吸引力。 通常，解决方案的主要重点是高速，其乐观性和消耗资源的效率。 控制器的优点是支持创纪录数量的不同平衡方法。
航海家
网站： github.com/appscode/voyager许可证：Apache 2.0基于HAproxy的控制器，它被定位为一种通用解决方案，可支持众多提供商的广泛功能。 提出了在L7和L4上平衡流量的机会，并且总体上平衡TCP L4流量可以称为解决方案的关键功能之一。
等高线
网站： github.com/heptio/contour许可证：Apache 2.0Envoy不仅奠定了该解决方案的基础：它是与该流行代理的作者
共同开发的。 一个重要功能是能够使用IngressRoute CRD资源拆分Ingress资源管理。 对于拥有多个开发团队且使用单个集群的组织，这有助于最大化相邻电路中流量的安全性，并在更改Ingress资源时保护它们免受错误的影响。
它还提供了一组扩展的平衡方法（具有请求的镜像，自动重试，对请求速率的限制等等），详细的流量和故障监视。 也许对于某些人来说，缺少对粘性会议的支持将是一个重大缺点（尽管工作
已经在进行中 ）。
Isstio入口
网站： istio.io/docs/tasks/traffic-management/ingress许可证：Apache 2.0全面的服务网格解决方案，它不仅是一个Ingress控制器，它可以控制来自外部的传入流量，还可以控制群集中的所有流量。 在引擎盖下，Envoy用作每种服务的辅助代理。 从本质上讲，这是一个“可以做任何事情”的大型组合，其主要思想是最大程度地提高可管理性，可扩展性，安全性和透明度。 借助它，您可以微调流量的路由，服务之间的访问授权，平衡，监视，金丝雀发布等。 在“
带Istio的微服务”系列文章中阅读有关Istio的更多信息。
大使
网站： github.com/datawire/ambassador许可证：Apache 2.0基于Envoy的另一种解决方案。 具有免费和商业版本。 它被定位为“ Kubernetes完全原生”，这带来了相应的优势（与K8s集群的方法和实体紧密集成）。
比较表
因此，本文的高潮就是这个巨大的表格：
单击该按钮可进行更详细的查看，并且还提供
Google表格格式。
总结一下
本文的目的是对您的特定情况下的选择提供更完整的理解（但是，绝对不是详尽的！）。 像往常一样，每个控制器都有自己的优点和缺点...
经典的Kubernetes Ingress具有可访问性和可靠性，并且功能十分丰富-总的来说，它应该“足够吸引人”。 但是，如果对稳定性，功能级别和开发的要求不断提高，则值得关注带有NGINX Plus和付费订阅的Ingress。 Kong拥有丰富的插件集（以及相应的插件提供的功能），在付费版本中甚至有更多的插件。 它有足够的机会充当API网关，基于CRD资源以及基本的Kubernetes服务进行动态配置。
随着对平衡和授权方法要求的提高，请查看Traefik和HAProxy。 这些是开源项目，经过多年的验证，非常稳定且正在积极开发中。 Contour已经存在了两年，但它看起来仍然太年轻，仅在Envoy之上添加了基本功能。 如果在应用程序之前存在WAF或嵌入WAF的要求，则应注意来自Kubernetes或HAProxy的同一Ingress。
功能最丰富的是基于Envoy（尤其是Istio）构建的产品。 这似乎是一个“无所不能”的复杂解决方案，但是，这也意味着配置/启动/管理的入门门槛比其他解决方案要高得多。
我们选择并仍然使用满足80-90％需求的Kubernetes Ingress作为标准控制器。 它相当可靠，易于配置和扩展。 通常，在没有特定要求的情况下，它应适合大多数群集/应用程序。 在相同的多功能产品和相对简单的产品中，可以推荐Traefik和HAProxy。
聚苯乙烯
另请参阅我们的博客：