【翻译】选择入口控制器的指南，第一部分：确定你的要求

作者：Jenn Gile 10月20日，2021年

特邀文章，原载于NGINX博客，作者为F5产品营销经理Jenn Gile

这是我们关于如何选择Kubernetes Ingress控制器系列的第一篇博文。

• 选择Ingress控制器的指南，第一部分：确定你的要求（这篇文章）
• 选择Ingress控制器的指南，第2部分：风险和未来保护
• 选择Ingress控制器指南，第3部分：开源与默认与商业
• 选择Ingress控制器指南，第4部分：NGINX Ingress控制器选项

当企业第一次开始尝试使用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吊舱（容器）中的应用程序不能从外部网络访问，而只能从Kubernetes集群中的其他吊舱访问。Kubernetes有一个用于HTTP负载均衡的内置配置对象，称为Ingress，它定义了Kubernetes集群外的实体如何连接到由一个或多个Kubernetes服务代表的pod。

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

一个Ingress控制器是做什么的？

• 接受来自Kubernetes环境外的流量，对其进行潜在的修改（塑造），并将其分配给环境内运行的pod。Ingress控制器取代了默认的kube-proxy流量分配模式，为你提供额外的控制，如应用交付控制器（ADC）和反向代理在非Kubernetes环境中提供的控制。
• 监视服务的各个pod，保证智能路由，防止请求被 "黑洞"。
• 实施出口规则，以加强相互TLS（mTLS）的安全性，或限制从某些豆荚到特定外部服务的外发流量。

当选择Ingress控制器的时候，从功能列表开始是很诱人的，但你最终可能会得到一个具有奇妙功能的Ingress控制器，但不能满足你的业务需求。相反，请确保探索影响Ingress控制器对你的团队和你的应用程序的作用的两个因素：用例（它将解决什么问题）和资源（你将如何为它 "付费"）。我们将在本博客的其余部分介绍这两个主题。

你希望Ingress控制器解决什么问题？

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)，使用户能够用一组凭证登录到多个应用程序。
• 消除了在每个应用程序中建立认证功能的需要，使你的开发人员能够专注于他们应用程序的业务逻辑。

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工具更多的灵活性和更精细的控制。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控制器如何扩展。我们将在第二部分讨论这些话题。