当为特定应用程序启动 Kubernetes 集群时，您需要了解应用程序本身、业务和开发人员对该资源的贡献。 有了这些信息，您就可以开始做出架构决策，特别是选择特定的 Ingress 控制器，目前此类控制器的数量已经很多了。 为了获得可用选项的基本概念，而无需阅读大量文章/文档等，我们准备了此概述，包括主要（生产就绪）Ingress 控制器。
我们希望它能帮助同事选择架构解决方案——至少它将成为获得更详细信息和实际实验的起点。 之前，我们在网上研究了其他类似的材料，奇怪的是，没有找到一个或多或少完整的、最重要的是结构化的评论。 那么让我们来填补这个空白吧！
标准
原则上，为了进行比较并获得任何有用的结果，您不仅需要了解主题领域，还需要有一个用于设置研究向量的特定标准列表。 在不假装分析使用 Ingress / Kubernetes 的所有可能情况的情况下，我们试图强调控制器的最一般要求 - 做好准备，在任何情况下，您都必须单独研究所有细节和细节。
但我将从那些已经变得如此熟悉以至于在所有解决方案中实现但未被考虑的特征开始：
- 服务的动态发现（service discovery）；
- SSL 终止；
- 使用网络套接字。
现在来说说对比点：
支持的协议
基本选择标准之一。 您的软件可能无法在标准 HTTP 上运行，或者可能需要同时在多个协议上运行。 如果您的情况是非标准的，请务必考虑此因素，以便以后不必重新配置集群。 对于所有控制器，支持的协议列表各不相同。
以软件为核心
该控制器所基于的应用程序有多种变体。 流行的有 nginx、traefik、haproxy、envoy。 在一般情况下，它可能对流量的接收和传输方式没有太大影响，但了解“幕后”的潜在细微差别和特征总是有用的。
流量路由
可以根据什么来决定特定服务的流量方向？ 通常这些是主机和路径，但还有其他可能性。
集群内的命名空间
命名空间（namespace）——在 Kubernetes 中逻辑分割资源的能力（例如，舞台上、生产上等）。 每个命名空间中必须单独安装 Ingress 控制器（然后它可以引导流量 仅 到该空间的吊舱）。 还有一些（以及它们的明显大多数）在整个集群中全局工作 - 其中流量被定向到集群的任何 Pod，无论命名空间如何。
上游样本
如何将流量引导至应用程序、服务的健康实例？ 有主动和被动检查、重试、断路器的选项 （有关更多详细信息，请参见，例如， )、自己的健康检查实现（自定义健康检查）等。 如果您对可用性和及时从平衡中删除失败的服务有很高的要求，那么这是一个非常重要的参数。
平衡算法
有很多选择：从传统的 到异国情调 ，以及诸如 .
认证
控制器支持哪些授权方案？ Basic、digest、oauth、external-auth - 我认为这些选项应该很熟悉。 如果有许多开发者（和/或只是私有）循环通过 Ingress 访问，这是一个重要的标准。
流量分布
控制器是否支持金丝雀部署（canary）、A/B测试、流量镜像（mirroring/shadowing）等常用的流量分配机制？ 对于需要精确的流量管理来进行高效测试、离线调试产品错误（或以最小的损失）、流量分析等的应用程序来说，这是一个非常痛苦的话题。
付费订阅
控制器是否有付费选项，具有高级功能和/或技术支持？
图形用户界面（Web UI）
是否有任何 GUI 来管理控制器配置？ 主要是为了“方便”和/或需要对 Ingress 的配置进行一些更改，但使用“原始”模板很不方便。 如果开发人员想要对动态流量进行一些实验，它可能会很有用。
JWT 验证
存在内置的 JSON Web 令牌验证，用于用户对最终应用程序的授权和验证。
配置定制的可能性
模板可扩展性是指拥有允许您将自己的指令、标志等添加到标准配置模板的机制。
基本的DDOS防护机制
简单的速率限制算法或更复杂的基于地址、白名单、国家/地区等的流量过滤选项。
请求跟踪
能够监视、跟踪和调试从 Ingress 到特定服务/Pod 的请求，最好也是在服务/Pod 之间进行请求。
WAF
Поддержка .
控制器
控制者名单的形成基于 и 。 由于特异性或流行率低（发展早期），我们将其中一些排除在审查之外。 其余的将在下面讨论。 让我们从解决方案的一般描述开始，然后使用汇总表。
来自 Kubernetes 的入口
网址：
许可证：Apache 2.0
这是 Kubernetes 的官方控制器，由社区开发。 从名字上可以明显看出，它是基于 nginx 的，并辅以一组不同的 Lua 插件，用于实现附加功能。 由于 nginx 本身的受欢迎程度以及用作控制器时对其进行的最小修改，对于普通工程师（具有 Web 经验）来说，此选项可能是最简单且最容易配置的。
NGINX Inc. 的 Ingress
网址：
许可证：Apache 2.0
nginx 开发者的官方产品。 有一个基于的付费版本 。 主要思想是高度的稳定性、持续的向后兼容性、没有任何无关的模块以及宣称的速度提高（与官方控制器相比），这是由于拒绝 Lua 而实现的。
免费版本显着减少，甚至与官方控制器相比（由于缺少相同的 Lua 模块）。 同时，付费版还具有相当广泛的附加功能：实时指标、JWT 验证、主动健康检查等。 相对于 NGINX Ingress 的一个重要优势是完全支持 TCP / UDP 流量（社区版本也是如此！）。 减 - 流量分配功能虽然“对开发者来说是最优先考虑的”，但实施起来还需要时间。
金刚入口
网址：
许可证：Apache 2.0
Kong Inc. 开发的产品有两个版本：商业版和免费版。 基于nginx，扩展了大量Lua模块。
最初，它专注于处理和路由 API 请求，即作为一个 API 网关，但目前它已经成为一个成熟的 Ingress 控制器。 主要优点：许多附加模块（包括来自第三方开发人员的模块）易于安装和配置，并在其帮助下实现了广泛的附加功能。 然而，内置函数已经提供了许多可能性。 作业配置是使用 CRD 资源完成的。
该产品的一个重要功能 - 在同一轮廓内工作（而不是跨命名空间）是一个有争议的话题：对于某些人来说，这似乎是一个缺点（您必须为每个轮廓生成实体），而对于某些人来说，这是一个功能（乙о更高级别的隔离，如如果一个控制器损坏，则问题仅限于电路）。
特拉菲克
网址：
许可证：麻省理工学院
最初创建的代理是为了处理微服务及其动态环境的请求路由。 因此，有许多有用的功能：无需重新启动即可更新配置、支持大量平衡方法、Web 界面、指标转发、支持各种协议、REST API、金丝雀版本等等。 另一个不错的功能是对 Let's Encrypt 证书的开箱即用支持。 缺点是为了组织高可用性（HA），控制器需要安装并连接自己的 KV 存储。
HAProxy的
网址：
许可证：Apache 2.0
HAProxy 长期以来一直被称为代理和流量平衡器。 作为 Kubernetes 集群的一部分，它提供“软”配置更新（不丢失流量）、基于 DNS 的服务发现、使用 API 的动态配置。 通过替换 CM 来完全自定义配置模板以及在其中使用 Sprig 库函数的能力可能很有吸引力。 一般来说，该解决方案的主要重点是高速、优化和资源消耗效率。 该控制器的优点是支持创纪录数量的不同平衡方法。
航海家
网址：
许可证：Apache 2.0
基于HAproxy控制器，其定位为通用解决方案，支持大量提供商的广泛功能。 提供了在 L7 和 L4 上平衡流量的机会，并且平衡 TCP L4 流量作为一个整体可以称为该解决方案的关键功能之一。
轮廓
网址：
许可证：Apache 2.0
该解决方案不仅基于 Envoy：它是由 共同 与这个流行代理的作者。 一个重要的功能是能够使用 IngressRoute CRD 资源单独控制 Ingress 资源。 对于拥有多个使用同一集群的开发团队的组织来说，这有助于最大限度地提高相邻循环中流量的安全性，并在更改 Ingress 资源时保护它们免受错误的影响。
它还提供了一组扩展的平衡方法（有请求镜像、自动重复、限制请求速率等等）、对流量和故障的详细监控。 也许对于某些人来说，缺乏对粘性会话的支持将是一个重大缺点（尽管工作 ).
Istio Ingress
网址：
许可证：Apache 2.0
全面的服务网格解决方案，不仅是管理外部传入流量的入口控制器，而且还控制集群内的所有流量。 在底层，Envoy 被用作每个服务的 sidecar 代理。 本质上，这是一个“无所不能”的大联合体，其主要思想是最大限度的可管理性、可扩展性、安全性和透明度。 有了它，您可以微调流量路由、服务之间的访问授权、平衡、监控、金丝雀发布等等。 在系列文章中阅读有关 Istio 的更多信息““。
大使
网址：
许可证：Apache 2.0
另一种基于 Envoy 的解决方案。 它有免费版和商业版。 它的定位是“完全原生于 Kubernetes”，从而带来了相应的优势（与 K8s 集群的方法和实体紧密集成）。
比较表
因此，本文的高潮是这张巨大的表格：
可以点击查看更近的视图，也可以采用以下格式 .
综合
本文的目的是让您更全面地了解（但绝不是详尽无遗！）在您的特定情况下应该做出什么选择。 像往常一样，每个控制器都有自己的优点和缺点......
Kubernetes 的经典 Ingress 因其可用性和验证性良好，功能足够丰富——一般情况下，它应该“足够养眼”。 但是，如果对稳定性、功能水平和开发水平有更高的要求，您应该关注带有 NGINX Plus 和付费订阅的 Ingress。 Kong 拥有最丰富的插件集（以及相应的它们提供的机会），而在付费版本中，插件数量甚至更多。 它有足够的机会充当 API 网关、基于 CRD 资源的动态配置以及基本 Kubernetes 服务。
随着对平衡和授权方法的要求不断增加，请查看 Traefik 和 HAProxy。 这些都是开源项目，经过多年的验证，非常稳定并且正在积极发展。 Contour 已经推出几年了，但它看起来仍然太年轻，并且只在 Envoy 之上添加了基本功能。 如果应用程序前面有 WAF 存在/嵌入的要求，则应注意来自 Kubernetes 或 HAProxy 的相同 Ingress。
功能最丰富的是基于 Envoy 构建的产品，尤其是 Istio。 它似乎是一个“无所不能”的综合解决方案，然而，这也意味着配置/启动/管理的准入门槛比其他解决方案要高得多。
我们选择并仍然使用 Kubernetes 的 Ingress 作为标准控制器，它可以满足 80-90% 的需求。 它非常可靠，易于配置和扩展。 一般来说，在没有特定要求的情况下，它应该适合大多数集群/应用程序。 同样通用且相对简单的产品中，可以推荐Traefik和HAProxy。
PS
另请阅读我们的博客：
- “回到 Istio 的微服务”： , , ;
- «“;
- «“。
来源： habr.com