选择入口控制器的指南，第 1 部分： 确定您的需求

编辑– 这篇文章是10 篇系列文章的一部分：

1. 使用生产级 Kubernetes 降低复杂性
2. 如何通过高级流量管理提高 Kubernetes 的弹性
3. 如何提高 Kubernetes 中的可见性
4. 使用流量管理工具保护 Kubernetes 的六种方法
5. 选择入口控制器的指南，第 1 部分： 确定您的需求（本帖）
6. 选择入口控制器的指南，第 2 部分： 风险与未来保障
7. 选择入口控制器的指南，第 3 部分： 开源与…… 默认与…… 商业的
8. 选择入口控制器的指南，第 4 部分： NGINX 入口控制器选项
9. 如何选择服务网格
10. 在动态 Kubernetes 云环境中对 NGINX Ingress 控制器进行性能测试

您还可以下载完整的博客作为免费的电子书 -将 Kubernetes 从测试带到生产。

当组织首次开始尝试使用 Kubernetes 时，他们通常不会花太多心思考虑Ingress 控制器的选择。 他们可能认为所有的 Ingress 控制器都是一样的，为了快速启动和运行，最简单的方法是坚持使用他们选择的 Kubernetes 框架的默认 Ingress 控制器。 事实上，几乎任何 Ingress 控制器都适用于测试或小批量生产环境。 但随着规模的扩大，Ingress 控制器的选择变得更加重要。 这是因为 Ingress 控制器可以提供的不仅仅是将流量从 A 点移动到 B 点的基本功能。

从高级流量管理到可视性再到内置安全性，Ingress 控制器可以成为 Kubernetes 堆栈中最强大的工具之一。 事实上，在 F5 NGINX 我们认为它是任何生产级 Kubernetes部署的基础。 但是许多开发人员和平台运营团队并没有意识到 Ingress 控制器的全部功能，或者选择一个无法扩展的控制器的后果。 选择不能很好扩展或保护复杂环境的 Ingress 控制器可能会阻止 Kubernetes 脱离测试并投入生产。 在这个博客系列中，我们旨在让您了解 Ingress 控制器的基础知识，以及如何做出明智的选择，提供您现在和将来所需的功能和安全性。

什么是 Ingress 控制器？

Ingress 控制器是一种专门的负载均衡器，用于管理进入 Kubernetes 集群的第 4 层和第 7 层流量，以及可能离开集群的流量。 为了让我们达成共识，以下是我们在 NGINX 使用的术语（并且它们在整个行业中大致相同）：

• 入口流量——进入 Kubernetes 集群的流量
• 出口流量——离开 Kubernetes 集群的流量
• 南北流量——进入和离开 Kubernetes 集群的流量（也称为入口出口流量）
• 东西向流量——Kubernetes 集群内服务之间的流量（也称为服务到服务流量）
• 服务网格——用于路由和保护服务到服务流量的流量管理工具

为什么需要入口控制器？

默认情况下，Kubernetes pod（容器）中运行的应用无法从外部网络访问，而只能从 Kubernetes 集群内的其他 pod 访问。 Kubernetes 有一个用于 HTTP 负载均衡的内置配置对象，称为Ingress ，它定义了 Kubernetes 集群之外的实体如何连接到一个或多个 Kubernetes 服务所代表的 pod。

当你需要为你的 Kubernetes 服务提供外部访问时，你可以创建一个Ingress 资源来定义连接规则，包括 URI 路径、支持服务名称和其他信息。 然而，Ingress 资源本身并不执行任何操作。 您必须部署和配置 Ingress 控制器应用（使用 Kubernetes API）来实现 Ingress 资源中定义的规则。

入口控制器起什么作用？

• 接受来自 Kubernetes 环境外部的流量，可能对其进行修改（塑造），并将其分发到环境内部运行的 pod。 Ingress 控制器取代了默认的kube-proxy流量分配模型，为您提供了额外的控制，类似于应用交付控制器 (ADC) 和反向代理在非 Kubernetes 环境中提供的控制。
• 监控服务的各个 pod，保证智能路由并防止请求被“黑洞”。
• 实施出站规则以通过相互 TLS（mTLS）增强安全性或限制从某些 pod 到特定外部服务的传出流量。

在选择 Ingress 控制器时，您可能很想从功能列表开始，但最终可能会选择具有出色功能但不能满足您的业务需求的 Ingress 控制器。 相反，一定要探索影响 Ingress 控制器为您的团队和应用程序运行效果的两个因素：用例（它将解决哪些问题）和资源（您将如何“支付”它）。 我们将在本博客的其余部分讨论这两个主题。

您希望 Ingress Controller 解决什么问题？

Ingress 控制器的核心用例是流量管理，因此您可能希望 Ingress 控制器处理以下一个或多个常见用例：

• 负载平衡（HTTP2、HTTP/HTTPS、SSL/TLS 终止、TCP/UDP、WebSocket、gRPC）
• 流量控制（速率限制、断路、主动健康检查）
• 流量分割（调试路由、A/B 测试、金丝雀部署、蓝绿部署）

但没有理由满足于“一招鲜”——大多数 Ingress 控制器能做的不仅仅是管理流量。 通过使用 Ingress 控制器解决多个问题，您不仅可以减少堆栈的大小和复杂性，还可以将非功能性需求从应用程序转移到 Ingress 控制器。 让我们看一下四种非传统 Ingress 控制器用例，它们可以帮助您的 Kubernetes 部署更加安全、灵活、可扩展，同时更有效地利用您的资源。

监控和可见性

缺乏对 Kubernetes 集群的可见性是生产环境中最大的挑战之一，导致故障排除和恢复能力困难。 由于 Ingress 控制器在 Kubernetes 集群的边缘运行并接触每一点流量，因此它们可以很好地提供数据来帮助您解决（甚至避免）两个常见问题：应用程序运行缓慢和 Kubernetes 集群或平台中的资源耗尽。 为了使 Ingress 控制器提高可见性，它需要：

• 提供实时指标，以便您能够诊断“当前”正在发生的事情
• 能够将指标导出到流行的可视化工具（如 Prometheus 和 Grafana），这些工具可以绘制随时间变化的值，以帮助您预测流量激增和其他趋势

API 网关

除非您希望在 Kubernetes 中执行请求响应操作，否则 Ingress 控制器很可能可以兼作您的 API 网关。 根据其功能集，Ingress 控制器可能能够提供核心 API 网关功能，包括 TLS 终止、客户端身份验证、速率限制、细粒度访问控制以及第 4 层到第 7 层的请求路由。

身份验证和单点登录

将登录凭据从 Kubernetes 服务卸载到 Ingress 控制器可以解决两个问题。

• 通过使用 OpenID Connect (OIDC) 实现单点登录 (SSO)，用户可以使用一组凭据登录多个应用程序。
• 无需在每个应用中构建身份验证功能，让您的开发人员专注于其应用程序的业务逻辑。

Webapplication防火墙集成

并不是说 Ingress 控制器可以充当 Web应用防火墙 (WAF)，而是 WAF 可以与 Ingress 控制器合并。 尽管 WAF 可以在 Kubernetes 内部和外部的许多地方部署，但对于大多数组织而言，最有效的位置是与 Ingress 控制器位于同一 pod 中。 当安全策略受 SecOps 或 DevSecOps 指导，并且需要细粒度、每个服务或每个 URI 的方法时，此用例是完美的。 这意味着您可以使用 Kubernetes API 来定义策略并将其与服务关联。 此外，Ingress 控制器的基于角色的访问控制 (RBAC) 功能可以使 SecOps 按照侦听器强制执行策略，而 DevOps 用户则按照 Ingress 资源设置策略。

您将如何为入口控制器提供资源？

每个 Ingress 控制器都是有成本的...即使是免费和开源的控制器（也许你听过“像小狗一样免费”这句话）。 一些成本可以分配为预算中的可预测金额，而其他成本则取决于您的团队需要花费多少时间来处理选择哪种 Ingress 控制器所带来的后果（复杂性增加、缺乏可移植性等）。 让我们看看在为 Ingress 控制器制定预算时需要考虑的成本——时间和金钱。

时间成本预算

编制员工预算比编制固定成本项目预算要困难得多，尤其是当您试图在陌生的领域为项目提供资源时。 你需要问以下问题：

• 谁将配置和管理 Ingress 控制器？ 这是他们的全职工作的一部分吗（例如，作为平台运营团队的成员）还是他们将其作为额外的责任（作为开发人员）？
• 您能抽出时间让员工接受正规培训吗？ 或者该工具必须足够简单，以便在工作中快速轻松地学习？
• 您是否准备好让员工在需要新功能时对其进行修修补补，或者在出现问题时花费大量时间进行故障排除？ 或者您需要他们来提供其他商业价值？

关于 Kubernetes 工具所有权的说明

我们观察到业界有一种趋势，即将工具和所有权整合到 NetOps 团队的管辖范围内。 虽然这在很大程度上可以简化您的堆栈并提高安全性，但我们主张根据团队目标深思熟虑地复制工具。 让 NetOps 团队管理外围工具（如外部负载均衡器）是有意义的，因为他们专注于更广泛的平台，但 DevOps 团队最关心部署在应用程序代码附近的服务，并且需要比 NetOps 工具更高的灵活性和更细粒度的控制。 Kubernetes 工具（包括 Ingress 控制器）在被 DevOps 选中时最有可能获得成功。 这并不是说您必须授予开发人员完全的选择工具的自由！ Kubernetes中一些工具的严格标准化仍然是一种最佳实践。

资本成本预算

当组织首次尝试使用 Kubernetes 时，他们通常不会在工具或支持上投入太多预算。 如果您拥有人力资源来真正支持需要更多“手动指导”的 Ingress 控制器，那么一开始不需要任何资金预算也是可以的。 但是随着您对 Kubernetes 的投资增加，您可能会发现自己受到该工具功能的限制，或者希望让您的团队专注于其他优先事项。 这时候，人们就会倾向于购买更易于使用、更稳定、具有企业功能和支持的工具。

当您准备购买 Ingress 控制器时，请注意许可模式很重要。 根据 Kubernetes 之外的传统定价模型，Ingress 控制器的定价通常是“按实例”或“按 Ingress 代理”。 虽然在 Kubernetes 中这仍然有意义，但以“每个集群”为基础许可 Ingress 控制器意味着您根据应用租户而不是“代理数量”付费。

以下是我们针对不同场景的建议：

• 刚接触 Kubernetes？ 选择每个集群许可。
  当您对 Kubernetes 不熟悉时，很难准确预测所需的 Ingress 控制器实例的数量。 如果被迫选择一些实例，您可能会低估——从而难以实现您的目标——或者高估并浪费资金，而这些资金本可以花在 Kubernetes 项目的其他部分。 为“小集群”协商一个相对较低的固定价格会增加成功的机会。
• 扩展 Kubernetes？ 选择每个集群许可。
  几乎不可能预测需要以多大程度和频率扩大或缩小 Kubernetes 资源（爆发和崩溃）。 按实例定价迫使您的团队施加任意阈值以保持在许可上限之内。 使用每个集群许可，您不必跟踪单个 Ingress 容器，并且根据供应商（例如 NGINX）的不同，可能包含突发功能而无需支付额外费用。
• 高级部署还是静态部署？ 选择按实例许可。
  如果您对 Kubernetes 足够了解，确切知道如何使用 Ingress 控制器，并且计划在每个集群中使用少量的 Ingress 代理，而且您不需要该工具可能附带的任何捆绑服务，那么按实例定价是一个不错的选择。

下一步： 风险承受能力和未来保障

现在您已经了解了您的需求，下一步是作为一个团队决定您对 Ingress 控制器可能引入的风险的容忍度，并确定随着 Kubernetes 部署的扩大，您需要如何扩展 Ingress 控制器。 我们将在第二部分讨论这些主题。