Ingress Controller 选型指南（第 1 部分）：明确需求

NGINX | 2021年9月08日

编者按：本文是一个共10篇的系列文章之一：

还可以免费下载包含全套博客文章的电子书：《推动Kubernetes从测试走向生产》。

组织刚开始试用Kubernetes时，往往不会过多考虑如何选择Ingress控制器。他们可能认为所有Ingress控制器都大同小异，为了快速启动并运行，最简单的做法就是沿用所选Kubernetes框架的默认Ingress控制器。事实上，在测试或低流量生产环境中，几乎任何Ingress控制器都能满足需求。但随着规模扩大，Ingress控制器的选择会变得更加重要。这是因为Ingress控制器不仅能提供将流量从A点转发到B点的基本功能，还能提供更多功能。

从高级流量管理、可观测性到内置安全功能，Ingress控制器可以成为Kubernetes技术栈中功能强大的工具之一。事实上，F5 NGINX认为，它是任何生产级Kubernetes部署的基础。但许多开发人员和平台运维团队并未充分认识到Ingress控制器的强大功能，也不了解选择无法扩展的控制器会带来什么后果。如果Ingress控制器无法良好扩展或保护复杂环境，Kubernetes就可能难以从测试阶段投入生产。本系列博客将介绍Ingress控制器的基础知识，并说明如何明智选择，满足当前及未来的功能和安全需求。

什么是Ingress Controller？

Ingress控制器是一种专用负载均衡器，用于管理进入Kubernetes集群的第4层和第7层流量，也可能管理从集群传出的流量。为便于统一理解，下面列出了NGINX使用的术语（这些术语与行业通用术语基本一致）：

入站流量：进入Kubernetes集群的流量
出站流量：离开Kubernetes集群的流量
南北向流量，即进入和离开Kubernetes集群的流量（也称为“入站和出站流量”）
东西向流量：Kubernetes集群内各服务之间传输的流量（也称为“服务到服务流量”）
服务网格：一种用于路由和保护服务间流量的流量管理工具

为什么需要Ingress Controller？

默认情况下，外部网络无法访问在Kubernetes Pod（容器）中运行的应用程序，只有Kubernetes集群内的其他Pod可以访问。Kubernetes内置了一个用于HTTP负载均衡的配置对象，称为“Ingress”。该对象定义了Kubernetes集群外部的实体如何连接到由一个或多个Kubernetes服务表示的Pod。

需要允许外部访问Kubernetes服务时，应创建Ingress资源，以定义连接规则，包括URI路径、后端服务名称及其他信息。但Ingress资源本身并不起作用。必须使用Kubernetes API部署并配置Ingress控制器应用程序，以实施Ingress资源中定义的规则。

Ingress控制器有何作用？

接收来自Kubernetes环境外部的流量，并可对其进行修改（整形），然后将其分发到该环境内运行的Pod。Ingress控制器取代默认的kube-proxy流量分发模型，提供更多控制功能，类似于非Kubernetes环境中的应用交付控制器（ADC）和反向代理所提供的功能。
监控服务中的各个Pod，确保智能路由，并防止请求被“黑洞化”。
实施出口规则，通过双向TLS（mTLS）增强安全性，或将特定Pod的出站流量限制为仅可访问指定的外部服务。

选择Ingress控制器时，很容易先从功能列表入手，但最终选出的Ingress控制器可能功能出色，却无法满足业务需求。更合适的做法是，务必考察影响Ingress控制器能否为团队和应用发挥良好作用的两个要素：用例（它将解决哪些问题）和资源投入（您将如何为此“买单”）。本博客余下部分将介绍这两个主题。

您希望Ingress Controller解决哪些问题？

Ingress控制器的核心用例是流量管理，因此通常需要它处理以下一种或多种常见用例：

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

但没必要满足于功能单一的工具，因为大多数Ingress控制器不仅能管理流量。使用Ingress控制器解决多个问题，不仅可以缩减技术栈的规模和复杂性，还能将非功能性需求从应用卸载到Ingress控制器。下面介绍4种非传统的Ingress控制器用例，帮助提高Kubernetes部署的安全性、敏捷性和可扩展性，同时更高效地利用资源。

监控与可见性

缺乏对Kubernetes集群的可见性是生产环境面临的主要挑战之一，会增加故障排除和提升韧性的难度。Ingress控制器在Kubernetes集群边缘运行，并处理所有流量，因此非常适合提供相关数据，帮助排查甚至避免两个常见问题：应用运行缓慢，以及Kubernetes集群或平台资源耗尽。要通过Ingress控制器提高可见性，需要：

实时提供指标，以便诊断“当前”发生的情况
能够将指标导出到Prometheus和Grafana等常用可观测性工具。这些工具可绘制指标值随时间的变化，帮助预测流量激增及其他趋势

API网关

除非需要在Kubernetes中处理请求和响应，否则Ingress控制器很可能也可充当API网关。根据其功能集，Ingress控制器或许能够提供核心API网关功能，包括TLS终止、客户端身份验证、速率限制、精细化访问控制，以及第4层至第7层的请求路由。

身份验证和单点登录

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

通过使用OpenID Connect（OIDC）实施单点登录（SSO），让用户能够使用一套凭据登录多个应用。
无需在每个应用中构建身份验证功能，让开发人员能够专注于应用的业务逻辑。

Web应用防火墙集成

这并不是说Ingress控制器可以充当Web应用防火墙（WAF），而是说WAF可以与Ingress控制器整合。虽然WAF可以部署在Kubernetes内部和外部的多个位置，但对大多数组织而言，将其部署在与Ingress控制器相同的Pod中通常更为高效且有效。当安全策略由SecOps或DevSecOps负责，并且需要按服务或URI实施精细化策略时，此用例非常适用。这意味着可以使用Kubernetes API定义策略，并将其与服务关联。此外，Ingress控制器的基于角色的访问控制（RBAC）功能可支持SecOps按侦听器实施策略，同时由DevOps用户按Ingress资源设置策略。

如何为Ingress控制器配置资源？

每种Ingress控制器都有成本……即使是免费的开源控制器也不例外（您可能听过“免费领养的小狗也需要付出成本”这种说法）。有些成本可以按可预测的金额列入预算，而另一些成本则取决于团队需要花多少时间来应对所选Ingress控制器带来的后果，例如复杂性增加、缺乏可移植性等。为Ingress控制器编制预算时，需要同时考虑时间和资金成本。

为时间成本编制预算

与固定成本项目相比，编制人员预算可能要困难得多，尤其是在为不熟悉领域的项目配置人员时。需要考虑以下问题：

由谁负责配置和管理Ingress控制器？这是他们的全职工作内容（例如，作为贵公司平台运维团队的成员），还是他们作为开发人员承担的额外职责？
能否安排员工参加正式培训？还是说，该工具必须足够简单，让员工能够在工作中快速轻松地掌握？
每当需要新功能时，是否可以安排员工自行摸索，或在出现问题时投入大量时间进行故障排除？还是需要他们创造其他业务价值？

关于Kubernetes工具所有权的说明

我们观察到，业界正逐渐将工具及其所有权统一归入NetOps团队的职责范围。虽然这对简化技术栈和提升安全性大有帮助，但我们主张根据团队目标，审慎地配置重复工具。由NetOps团队管理边界工具（如外部负载均衡器）是合理的，因为该团队关注的是更广泛的平台；而DevOps团队最关心的是部署在应用代码附近的服务，需要比NetOps工具更高的敏捷性和更精细的控制。包括Ingress控制器在内的Kubernetes工具由DevOps团队选择，更有可能取得良好成效。但这并不意味着必须让开发人员完全自由地选择工具！在Kubernetes内部，对工具进行一定程度的严格标准化仍是良好实践。

资本成本预算

组织初次试用Kubernetes时，通常不会为工具或支持预留太多预算。如果有足够的人力资源，能够切实支持需要投入更多精力维护的Ingress控制器，那么一开始不安排资金预算也未尝不可。但随着对Kubernetes的投入增加，工具的功能可能会逐渐难以满足需求，或者您可能希望团队专注于其他优先事项。此时，付费采用更易用、更稳定且具备企业级功能和支持的工具，往往更为合适。

准备为Ingress控制器付费时，请注意许可模式非常重要。按照Kubernetes之外的传统定价模式，Ingress控制器通常按“实例”或“Ingress代理”收费。虽然这些模式在Kubernetes的某些用例中仍然适用，但如果改为按“集群”许可Ingress控制器，费用将取决于应用租户，而不是“代理数量”。

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

刚开始使用Kubernetes？请选择按集群许可。
如果缺乏Kubernetes使用经验，就很难准确预测所需的Ingress控制器实例数量。如果必须确定实例数量，可能会低估需求，导致难以实现目标；也可能会高估需求，浪费本可用于Kubernetes项目其他部分的资金。为“小型集群”协商一个相对较低的固定价格，有助于提高成功的可能性。
需要扩展Kubernetes？请选择按集群许可。
几乎无法预测需要扩展或缩减Kubernetes资源的幅度和频率（突增和回落）。按实例定价会迫使团队设置任意阈值，以免超出许可上限。采用按集群许可后，无需跟踪各个Ingress容器；具体取决于供应商（如NGINX），资源突增可能无需额外付费。
高级部署或静态部署？选择按实例许可。
如果您非常熟悉Kubernetes，清楚知道将如何使用Ingress控制器，并且计划在每个集群中仅使用少量Ingress代理，也不需要该工具可能附带的任何捆绑服务，那么按实例定价会是一个不错的选择。