选择入口控制器的指南，第 2 部分： 风险与未来保障

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

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

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

在我们选择Ingress 控制器的指南的第 1 部分中，我们解释了如何确定您的要求。 但现在还没有到测试产品的时候！ 在这篇文章中，我们解释了错误的 Ingress 控制器如何减慢您的发布速度，甚至让您失去客户。 与任何工具一样，Ingress 控制器可能会引入风险并影响未来的可扩展性。 让我们看看如何消除那些可能弊大于利的选择。

Ingress 控制器风险

引入 Kubernetes 流量管理工具时，应考虑三个特定风险：复杂性、延迟和安全性。 这些问题往往交织在一起；当一个问题出现时，你很可能会看到其他问题。 每一个都可以由 Ingress 控制器引入，并且由您的组织来决定风险是否可以容忍。 如今的消费者变化无常，任何导致糟糕数字体验的事物都可能是不可接受的，尽管它具有引人注目的功能。

复杂性——它是否违背了微服务架构的目的？

最好的 Kubernetes 工具是那些满足微服务架构目标的工具：轻量级和设计简单。 可以开发一个遵循这些原则的功能非常丰富的 Ingress 控制器，但这并不总是常态。 一些设计师添加了太多功能或使用复杂的脚本来添加底层引擎所不具备的功能，导致 Ingress 控制器变得非常复杂。

这为什么重要？ 在 Kubernetes 中，过于复杂的工具可能会对应用程序性能产生负面影响，并限制您水平扩展部署的能力。 通常，您可以通过其大小来识别过于复杂的 Ingress 控制器：占用空间越大，工具越复杂。

延迟 – 入口控制器是否会减慢你的应用程序速度？

入口控制器可能会因资源使用、错误和超时而增加延迟。 查看静态和动态部署中增加的延迟，并根据您的内部要求消除引入不可接受的延迟的选项。 有关重新配置如何影响应用程序速度的更多详细信息，请参阅我们博客上的在动态 Kubernetes 云环境中对 NGINX Ingress 控制器进行性能测试。

安全性——入口控制器会给黑客打开大门吗？

常见漏洞和暴露 (CVE) 在当今的互联网上猖獗，而您的 Ingress 控制器提供商提供 CVE 补丁所需的时间可能是安全和漏洞之间的区别。 根据您组织的风险承受能力，您可能希望消除需要几天（或最多几周）才能提供补丁的解决方案。

除了 CVE 之外，一些 Ingress 控制器还会让您面临另一个潜在的漏洞。 考虑这种场景：您在一家在线零售商工作，需要帮助解决开源 Ingress 控制器的配置问题。 由于没有商业支持，因此您可以将问题发布到 Stack Overflow 等论坛。 有人提供帮助，并想在 Ingress 控制器和其他 Kubernetes 组件的配置和日志文件中查找问题。 由于感受到尽快解决问题的压力，您共享了文件。

“好心人”帮助您解决了问题，但六个月后您发现了漏洞——您的客户记录中的信用卡号被盗了。 哎呀。 事实证明，您共享的文件包含用于渗透您应用程序的信息。这种情况说明了组织选择付费支持的主要原因之一：它可以保证机密性。

关于基于 OpenResty 的 Ingress 控制器的说明

OpenResty 是一个基于 NGINX 开源构建的 Web 平台，它结合了 LuaJIT、Lua 脚本和第三方 NGINX 模块来扩展 NGINX 开源中的功能。 反过来，有多个基于 OpenResty 构建的 Ingress 控制器，我们认为与基于 NGINX Open Source 和 NGINX Plus 的 Ingress 控制器相比，这些 Ingress 控制器可能会增加两个风险：

• 超时- 如上所述，OpenResty 使用 Lua 脚本来实现高级功能，例如我们基于商业 NGINX Plus 的Ingress Controller 中的功能。 其中一个功能是动态重新配置，它消除了降低可用性的 NGINX 开源要求 - 即当服务端点发生变化时必须重新加载 NGINX 配置。 为了使用 OpenResty 实现动态重新配置，Lua 处理程序会选择将请求路由到哪个上游服务，从而无需重新加载 NGINX 配置。

  然而，Lua 必须不断检查后端的变化，这会消耗资源。 传入的请求需要更长的时间来处理，导致某些请求停滞，从而增加了超时的可能性。 随着用户和服务的增多，每秒传入请求的数量与 Lua 可以处理的数量之间的差距会呈指数级扩大。 其后果是延迟、复杂性和更高的成本。

  阅读在动态 Kubernetes 云环境中测试 NGINX Ingress 控制器的性能，了解 Lua 可以增加多少延迟。

• CVE 修补延迟——与 NGINX 的 Ingress 控制器相比，CVE 的补丁不可避免地需要更长时间才能显示在基于 OpenResty 等工具的 Ingress 控制器中，而这些工具又基于 NGINX 开源。 正如我们在使用 NGINX Plus 快速轻松地缓解安全漏洞中所详细概述的那样，当发现 NGINX 中的 CVE 时，作为供应商的我们通常会在 CVE 公开披露之前得到通知。 这样我们就能在 CVE 公布后立即发布针对 NGINX Open Source 和 NGINX Plus 的补丁。

  基于 NGINX 开源的技术可能直到那时才会了解 CVE，并且根据我们的经验，OpenResty 补丁比我们的补丁落后很多——最近的一个案例中，甚至落后了四个月。 基于 OpenResty 的 Ingress 控制器的修补不可避免地需要更多时间，这为不良行为者提供了充足的机会来利用该漏洞。

面向未来的 Ingress 控制器

即使您刚刚开始涉足 Kubernetes，也很有可能有一天希望将其投入生产。 您的需求可能会随着时间的推移而增长的四个主要领域是：基础设施、安全、支持和多租户。

基础设施——您会在混合云或多云环境中使用 Kubernetes 吗？

一个组织很少会完全且永久地致力于一种类型的环境。 更常见的是，组织将本地和云端混合使用，其中可以包括私有云、公共云、混合云和多云。 （要深入了解这些环境的区别，请阅读多云和混合云之间有什么区别？ ）

正如我们在本系列第 1 部分中提到的那样，选择每个环境默认的工具很诱人，但默认 Ingress 控制器存在许多特定问题。 我们将在本系列的第 3 部分中介绍所有缺点，但与未来保障最相关的问题是供应商锁定 - 您不能在所有环境中使用特定于云的 Ingress 控制器。 使用默认的云专用工具会影响您的扩展能力，因为您只剩下两个没有吸引力的替代方案：

1. 尝试让现有的云满足你的所有需求
2. 重写所有配置 — — 不仅是负载均衡，还有安全性！— — 针对每个新环境中的 Ingress 控制器

虽然第一种选择往往因为商业原因而不可行，但第二种选择也很棘手，因为它会导致工具蔓延、带来新的安全漏洞，并要求您的员工攀登陡峭的学习曲线。 第三种也是最有效的替代方案是从一开始就选择与基础设施无关的 Ingress 控制器，这样您就可以在所有环境中使用相同的工具。

说到基础设施，还有另一个因素需要考虑：认证。 我们以 Red Hat OpenShift Container Platform (OCP) 为例。 如果您是 OCP 用户，那么您可能已经知道 Red Hat Marketplace 为 OCP 提供认证运营商，包括NGINX Ingress Operator 。 Red Hat 的认证标准意味着您可以放心，该工具适用于您的部署，甚至可以包括 Red Hat 和供应商的联合支持。 出于安全性和稳定性原因，许多组织都要求使用经过认证的工具，因此即使您现在只是在测试，也应该牢记公司对生产环境的要求。

安全性——如何从内部保护 Kubernetes？

仅靠周边安全就足以保障应用程序和客户安全的日子已经一去不复返了。 当安全性（包括身份验证和授权）接近应用程序时，Kubernetes 应用程序可以得到最好的保护。 随着组织越来越多地要求端到端加密并在 Kubernetes 中采用零信任网络模型，服务网格可能会成为您的未来。

所有这些和你的 Ingress 控制器有什么关系？ 很多！ 从成本和效率的角度来看，在 Ingress 点集中安全性（身份验证、授权、DoS 保护、Web应用防火墙）非常有意义。 虽然大多数服务网格可以与大多数 Ingress 控制器集成，但它们如何集成非常重要。 与您的安全策略相一致的 Ingress 控制器可以避免您在整个应用程序开发过程中出现大麻烦。

阅读《在不损失速度的情况下保护云原生应用》了解有关云原生应用交付风险的更多详细信息，并阅读《在 Kubernetes 中部署application服务（第 2 部分）》以了解有关决定安全工具最佳位置的因素的更多信息。

支持——您能承受多大的“独立”？

当团队刚刚尝试使用 Kubernetes 时，支持（无论是来自社区还是公司）通常并不是最高优先级。 如果您的团队有足够的时间来提出自己的解决方案和解决方法，那么这是可以的，但当您转向生产时，这是不可持续的。 即使您今天不需要支持，选择一个允许您在将来添加支持的 Ingress 控制器也是明智之举 - 或者具有可以在扩展时升级的廉价支持层。

多租户——多个团队和应用程序如何安全地共享容器环境？

一开始，只有一个团队和一个应用程序……每个故事不都是这样开始的吗？ 故事经常会这样发展：一个团队成功开发了自己的一个 Kubernetes 应用程序，并带领组织在 Kubernetes 上运行更多的服务。 当然，更多服务=更多团队=更多复杂性。

为了实现最高效率，组织采用多租户并采用 Kubernetes 模型，该模型支持其业务流程要求的访问和隔离，同时还提供其运营商所需的理智和控制。 一些 Ingress 控制器可以通过许多功能和概念帮助您划分这些集群：支持设置基于角色的访问控制（RBAC）的多个入口、类、命名空间和范围资源。

下一步： 缩小选项范围

现在您已经考虑了您的需求、风险承受能力和未来保障，您已经拥有足够的信息来开始缩小非常广泛的 Ingress 控制器领域。 按类别细分该字段可以帮助您快速完成此步骤。 在本系列文章的第三部分中，我们将探讨三种不同类别的 Ingress 控制器，包括每种控制器的优缺点。