Ingress Controller 选型指南，第一部分：确定需求

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

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

首次使用 Kubernetes 的企业通常不会在 Ingress controller 的选择上花太多心思。他们可能认为 Ingress Controller 都大同小异，并且为了快速启动和运行，最方便的就是直接使用当前 Kubernetes 框架默认的 Ingress Controller。的确，几乎任何 Ingress Controller 在测试环境或小规模生产环境中都表现尚可。但随着业务集群规模的不断扩大，您对 Ingress Controller 的选择将变得愈发重要。这是因为 Ingress Controller 不仅限于提供将流量从 A 点移动到 B 点的基本功能。

通过提供高级流量管理、可视化及内置的安全防护，Ingress Controller 可以成为 Kubernetes 堆栈中最强大的工具之一。事实上，F5 NGINX 认为它是任何生产级 Kubernetes 部署的基础。但是，许多开发人员和平台运营团队都没有认识到 Ingress Controller 的全部功能，也没有意识到选择一个无法扩展的控制器所带来的后果。如果您选择的 Ingress Controller 无法有效地扩展或无法保护复杂的环境，那么您的 Kubernetes 可能无法从测试环境顺利进入生产环境。在本系列博文中，我们将向您介绍 Ingress Controller 的基础知识，以及如何明智地选择符合当今和未来的功能与安全性需求的控制器。

什么是 Ingress Controller？

Ingress Controller 是一种专用的负载均衡，用于管理进出 Kubernetes 集群的四层和七层流量。明确这一点后，我们来看看 NGINX 使用的术语（与业界所用术语基本相同）：

• 入向流量（Ingress traffic） – 进入 Kubernetes 集群的流量
• 出向流量（Egress traffic） – 离开 Kubernetes 集群的流量
• 南北向流量（North‑south traffic） – 进出 Kubernetes 集群的流量（也称为“入向到出向的流量”）
• 东西向流量（East‑west traffic） – 在 Kubernetes 集群内的服务之间移动的流量（也称为“从服务到服务的流量”）
• 服务网格（Service mesh） – 一种针对服务到服务的流量进行路由和保护的流量管理工具

为什么需要 Ingress Controller？

默认情况下，Kubernetes pod（容器）中运行的应用无法通过外部网络来访问，只能通过 Kubernetes 集群内的其他 pod 访问。Kubernetes 有一个用于 HTTP 负载均衡的内置配置对象，叫做 Ingress。不同的 pod 可能由一个或多个 Kubernetes service 代表，而 Ingress 则定义了 Kubernetes 集群外部的实体连接这些 pod 的方式。

当您需要向外部提供对 Kubernetes service 的访问时，您可以创建一个 Ingress 资源来定义连接规则，包括 URI 路径、后端 service 名称及其他信息。然而，Ingress 资源本身不执行任何操作。您必须通过部署和配置 Ingress Controller 应用（使用 Kubernetes API）来实施在 Ingress 资源中定义的规则。

Ingress Controller 有何作用？

• Ingress Controller 会接受来自 Kubernetes 环境外部的流量，可能对其进行修改（整形）并将其分发到在 Kubernetes 环境内部运行的 pod。它取代了默认的 kube-proxy 流量分发模式，为您提供了额外的控制——就像是应用交付控制器（ADCs）和反向代理在非 Kubernetes 环境中所提供的那类控制。
• 监控服务的各个 pod，确保智能路由，防止请求“迷路（black‑holed）”。
• 实施出向规则，通过双向 TLS（mTLS）增强安全性，或限制从某些 pod 流向特定外部服务的出站流量。

在选择 Ingress Controller 时，很多人可能会先看功能。但这很容易导致最终选择的 Ingress Controller 徒有花哨的功能，却不能满足实际的业务需求。因此，您必须要了解影响您的团队和应用能否有效使用 Ingress Controller 的两个要素：用例（要解决的问题）和资源（投入的成本）。接下来我们将重点讨论这两个主题。

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

Ingress Controller 的核心用例是流量管理，因此您可能想要 Ingress Controller 处理以下一个或多个常见用例：

• 负载均衡（HTTP2、HTTP/HTTPS、SSL/TLS 卸载、TCP/UDP、WebSocket、gRPC）
• 流量控制（速率限制、断路、主动健康检查）
• 流量分流（调试路由、A/B 测试、灰度部署、蓝绿部署）

但是大多数 Ingress Controller 可以做的不仅仅是管理流量，所以我们没必要仅盯着这一项功能。Ingress Controller 能够解决多种问题，不仅可以帮助您减少堆栈的规模和复杂性，而且还可以将非功能需求从应用卸载到 Ingress Controller 上。我们来看看四个非传统的 Ingress Controller 用例，它们可以帮助您提高 Kubernetes 部署的安全性、敏捷性和可扩展性以及资源的利用率。

监控和可视化

Kubernetes 集群可视性的缺乏是生产环境面临的最大挑战之一，因为这增加了故障排除和恢复的难度。由于 Ingress Controller 在 Kubernetes 集群的边缘运行并处理所有流量，它们能够很好地提供一些数据来帮助您解决（甚至避免）两个常见的问题：Kubernetes 集群或平台中的应用运行缓慢和资源耗尽问题。为了提高可视化，Ingress Controller 需要：

• 实时提供指标，以便您可以“即时”诊断当下出现的问题
• 能够将指标导出到常用的可视化工具（例如 Prometheus 和 Grafana），绘制随时间变化的数值，以帮助您预测流量激增及其他趋势

API 网关

除非您希望在 Kubernetes 中执行请求‑响应操作，否则 Ingress Controller 很可能会兼作您的 API 网关。Ingress Controller 能够提供核心 API 网关功能，包括 TLS 终止、客户端身份验证、速率限制、细粒度访问控制以及四至七层的请求路由，具体取决于它的功能特性。

身份验证和单点登录

通过将登录凭征的身份验证从 Kubernetes 服务卸载到 Ingress Controller，您可以解决两个问题：

• 实施采用 OpenID Connect（OIDC）的单点登录（SSO），允许用户使用一组凭证登录多个应用。
• 消除为每个应用构建身份验证功能的需求，让您的开发人员可以专注于应用的业务逻辑。

Web 应用防火墙集成

准确地说，并不是 Ingress Controller 可以充当 Web 应用防火墙（WAF），而是 Ingress Controller 可以和 WAF 集成。尽管 WAF 可以部署在 Kubernetes 内外的许多地方，但对于大多数企业而言，最高效且最有效的部署位置是 Ingress Controller 所在的 pod。此用例非常适合安全策略由 SecOps 或 DevSecOps 指导的情况，也适合需要细粒度、按服务或按 URL 进行防护的案例。这意味着您可以使用 Kubernetes API 来定义策略并将它们与服务相关联。此外，Ingress Controller 基于角色的访问控制（RBAC）功能支持 SecOps 按监听器实施策略，并支持 DevOps 用户为每个 Ingress 资源设置策略。

如何为 Ingress Controller 分配资源？

每个 Ingress Controller 都会产生成本，即使那些免费的开源控制器也不例外（您可能听说过这个比喻：“就像养一只免费的小狗一样”）。有些成本是预算中可预测的成本，有些成本则取决于您的团队需要花费多少时间来处理您所选的 Ingress Controller 带来的一系列问题（更多的复杂性、缺乏可移植性等问题）。我们来看看在确定 Ingress Controller 预算时需要考虑的成本：时间和资金。

时间成本预算

确定人员预算可能比确定固定的项目成本更难，尤其是当您尝试为不熟悉的领域分配项目资源。您需要思考几个问题：

• 谁负责配置和管理 Ingress Controller？这是他们的专职工作（例如作为平台运营团队的成员）还是兼任的职责（作为开发人员）？
• 您的员工是否有时间接受正规培训？或者您是否要求工具必须简单易学，以便快速轻松地用于工作？
• 您是否准备好让员工在需要新功能时进行修补，或者在出现问题时花大量时间进行解决？或者您是否需要他们来提供其他业务价值？

关于 Kubernetes 工具所有权的说明

我们观察到业界有一种趋势，即在 NetOps 团队的领域内整合工具和所有权。虽然这有助于简化堆栈和提高安全性，但我们提倡根据团队目标考虑选择的工具。NetOps 团队专注于更广泛的平台，因此让他们管理周边工具（如外部负载均衡器）合情合理，而 DevOps 团队最关心靠近应用代码部署的服务，并且需要比 NetOps 工具更高的敏捷性和更细粒度的控制。所以 DevOps 选择 Kubernetes 工具（包括 Ingress Controller）最有可能取得成功。但是这并不是说您必须完全放手让开发人员自由选择工具！Kubernetes 中一些严苛的工具标准化要求依然是最佳实践。

资本成本预算

首次使用 Kubernetes 的企业通常不会在工具或支持上投入太多预算。如果您拥有足够的人力资源来支持需要更多“人工操作”的 Ingress Controller，那么初期可以不考虑资本成本预算。但随着 Kubernetes 投资的增加，您可能会发现工具的功能不够用，或者想要将团队划拨到其他优先事项。这时，大家开始购买更易于使用、更稳定且具有企业级功能和支持的工具来进行扩展。

请注意，到了花钱这一步，许可模式就变的很重要。Ingress Controller 采用的是不同于 Kubernetes 的传统定价模式，通常“按实例”或“按 Ingress 代理”定价。有时也可考虑“按集群”付费，这意味着您将根据应用租赁而不是“代理数量”购买 Ingress Controller 许可。

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

• Kubernetes 新手? 选择按集群许可。
  如果您缺乏 Kubernetes 使用经验，便很难准确预测您需要的 Ingress Controller 实例的数量。如果非要选“按实例”的话，那么您可能会低估实例数量，从而难以实现目标；或高估实例数量，浪费了本可以在 Kubernetes 项目的其他部分发挥作用的资金。为“小集群”争取一个相对较低的固定价格将会增加您成功的机会。
• 正打算扩展 Kubernetes 集群？选择按集群许可。
  您可能很难预测 Kubernetes 资源（激增和骤减）的调整规模和频率。在按实例模式下，您的团队必须要设定任意阈值，确保不超出许可上限。而在按集群许可中，您不需要跟踪各个 Ingress 容器，并且取决于厂商（例如 NGINX），即使流量激增您也可能无需额外付费。
• 高级部署或静态部署？选择按实例许可。
  如果您对 Kubernetes 足够精通，准确地知道将如何使用 Ingress Controller 和在每个集群中使用几个 Ingress 代理，并且不需要Ingress Controller可能附带的任何捆绑服务，那么按实例模式可能是一个不错的选择。

下一步行动：风险承受能力和未来需求洞察

现在您已经了解了自己的需求，接下来是判断整个团队对 Ingress Controller 的风险承受能力，并弄清楚随着 Kubernetes 部署的增长，您需要如何扩展 Ingress Controller。我们会在即将发布的第二部分中讨论这些主题。