Ingress Controller 选型指南，第三部分：开源、默认和商用版本能力对比

编者按 —— 本文是以下系列博文中的一篇（共十篇）：

您还可以免费下载整套博文集结成的电子书：《Kubernetes：从测试到生产》。

恭喜您！读完本系列博文的第一部分和第二部分后，您差不多就可以开始选择 Ingress controller 了。我们来回顾一下往期的内容：

• 第一部分讨论了如何确定您在性能、预算、用例、架构和所有权方面的需求。
• 第二部分讨论了 Ingress Controller 选择不当可能会引发的风险，并概述了您可以前瞻性地选择的几个关键领域。

Ingress Controller 分为三类：开源、默认和商用。它们各有各的用例，您需要在选择之前先明确自己的短期和长期需求。本文将会介绍每个类别的优缺点。

开源 Ingress Controller

虽然有些开源 Ingress Controller 有专门的工程团队，但多数都是由社区的用户和志愿者开发人员来维护。目前最流行的两个开源 Ingress Controller 都是基于 NGINX 构建的，其中一个是由 Kubernetes 社区维护的、另外一个是由核心 NGINX 工程团队主导并开源的。有关基于 NGINX 的 Ingress Controller 的进一步比较，请参阅本系列博文第 4 部分。

• 优点：
  • 免费使用，社区驱动 – 许多企业和机构选择开源项目不仅是因为其无与伦比的价格（免费！），而且还在于他们更喜欢社区开发的技术。
  • 功能迭代快 – 这类 Ingress Controller 更有可能走在功能创新的最前沿。
• 缺点（开源项目普遍存在的问题）：
  • 成本（时间） – 它们缺乏易于设置和扩展的“开箱即用”工具，所以您最终会花时间在定制化和解决方法上，以满足您的特定需求。
  • 风险 – 可能缺乏稳定性、安全性和可靠性（原因在于重视功能发布速度和贡献者的志愿性质）。CVE（通用漏洞披露）漏洞的补丁可能永远不会出现，或者可能在 CVE 公开披露数月后才出现，这会给黑客攻击您的 Ingress Controller 创造很长的时间窗口。
  • 很少或者没有支持服务 – 出现问题时多数需要自己解决，最多查查文档资料。如果遇到自己无法解决的问题，则很难甚至根本无法获得帮助——留给您唯一的选择就是在社区论坛上晒出自己的问题，寄望于社区的其他成员能够费心回应并且知道某种解决办法。
• 总结：由于有文档、上手快且免费，首次试水 Kubernetes 的企业和机构通常会选择开源 Ingress Controller。这在起步阶段、测试环境或小批量生产环境中是一种不错的选择。

默认的 Ingress Controller

虽然许多默认的 Ingress Controller 也基于开源技术构建，但它们由提供完整 Kubernetes 平台（并且通常提供管理支持）的公司开发和维护，因此我们单独拿出来介绍。公有云 Ingress Controller、Rancher 和红帽 OpenShift 路由器都属于这一类。

• 优点：
  • 免费或低成本 – 低廉的价格是这类产品非常有吸引力的一个宣传点。它们已经集成到平台中，对新手来说是当之无愧的省时神器。
  • 可靠且有支持 – 它们由专门的工程团队来维护，比社区维护的 Ingress Controller 更可靠一些。它们通常自带或额外销售商业支持。
• 缺点：
  • 基础架构锁定 – 默认的 Ingress Controller 受基础架构的限制，您无法在云平台之间迁移它们或它们的配置。这意味着每个部署环境都需要不同的 Ingress Controller，这将会导致工具蔓延，增加团队的学习难度，并使 Ingress Controller 更加难以保护。
  • 基本功能 – 它们通常缺乏大规模部署所需的高级流量管理和安全功能。
  • 不可预测的成本（时间和金钱） – 虽然初始成本为零或很低，但其成本可能会随着应用的成长而急剧攀升且不可预测。您可能需要花费时间将 Ingress Controller 最小功能集中缺少的功能构建到您的应用程序中，更别说每次更新都伴随着回归测试。有些默认工具还有一个缺点：随着应用变得越来越流行，起初看似不起眼的吞吐量费用将会让您的云账单大幅增加。
• 总结： 对于刚接触 Kubernetes 并使用托管平台（例如亚马逊 Elastic Kubernetes Service（EKS）、Google Kubernetes Engine（GKE）、微软 Azure Kubernetes Service（AKS）、Rancher、红帽 OpenShift Container Platform）的团队来说，默认的 Ingress Controller 是一种比较受欢迎的选择。随着应用的成熟和团队的壮大，组织通常会将企业级 Ingress Controller 添加到其堆栈中，而不是替换默认工具。

商用 Ingress Controller

商用 Ingress Controller 是旨在支持大型生产部署的许可商品。基于 NGINX Plus 的 F5 NGINX Ingress Controller 就是一个典型的例子，我们将在第 4 部分详细讨论。

• 优点：
  • 功能丰富 – 商用 Ingress Controller 包含丰富、强大的功能，能够为大型部署环境提供高级流量管理和可扩展性。它们可能还会集成其他生产级产品，例如 WAF 或服务网格。
  • 可扩展性 – 企业和机构发现这类产品可以节省时间，因为它们往往有更多“开箱即用”的功能，不需要自定义和变通。它们可以轻松添加到自动化流水线中，以支撑基础架构按需扩展。
  • 可靠且有支持服务 – 商用产品的主要优势之一是良好的稳定性，这意味着每个版本发布都经过了广泛的测试，并定期进行软件更新并安全补丁发布。商用产品一般会提供各个级别的全面商业支持，如果您遇到严重问题，通常几分钟或几小时内就能获得保密帮助。
• 缺点：
  • 开发略慢 – 由于稳定性是商用 Ingress Controller 的重要考虑因素，它们的功能发布速度可能比开源竞品稍微慢一些。
  • 成本（金钱） – 商用产品有一个不得不面对的现实：收费。如果企业和机构开发周期长，现金回流慢，那么除非这种情况得以改变，否则成本对他们而言就是交易路上的绊脚石。
• 总结：随着企业和机构的扩展，根据团队和应用的复杂性来选择 Ingress Controller 变得愈发重要。一旦组织上呈现高度复杂性，商用 Ingress Controller 就变得有意义，因为它可以降低管理复杂性并加快新产品功能的上市速度。

下一步行动：评估您的选择

到了这个阶段，您就可以划掉一些不符合需求的选项，只锁定一部分 Ingress Controller 了。

在研究 Ingress Controller 的过程中，您可能会注意到许多选择都是基于 NGINX 的。有关基于 NGINX 的 Ingress Controller 选择的概述，请阅读本系列最后一篇博文：Ingress Controller 选型指南，第四部分：NGINX Ingress Controller 选项。