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

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

1. 生产级 Kubernetes 助您降低复杂性
2. 如何通过高级流量管理提高 Kubernetes 的弹性
3. 如何提高 Kubernetes 环境的可视性
4. 使用流量管理工具保护 Kubernetes 的六种方法
5. Ingress Controller 选型指南，第一部分：确定需求
6. Ingress Controller 选型指南，第二部分：评估风险和技术前瞻性
7. Ingress Controller 选型指南，第三部分：开源、默认和商用版本能力对比（本文）
8. Ingress Controller 选型指南，第四部分：NGINX Ingress Controller 选项
9. 如何选择 Service Mesh
10. NGINX Ingress Controller 在动态 Kubernetes 云环境中的性能测试

您还可以免费下载整套博文集结成的电子书：《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 选项。