Ingress Controller 选型指南（第 2 部分）：风险与面向未来的规划

NGINX | 2021年9月13日

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

借助生产级Kubernetes降低复杂性
如何通过高级流量管理提升Kubernetes的韧性
如何提高Kubernetes中的可观测性
使用流量管理工具保护Kubernetes的六种方法
Ingress Controller 选型指南（第 1 部分）：明确需求
Ingress Controller选择指南（第2部分）：风险与面向未来的规划（本文）
Ingress Controller 选择指南，第 3 部分：开源、默认与商业方案对比
Ingress Controller选择指南，第4部分：NGINX Ingress Controller选项
如何选择服务网格
在动态Kubernetes云环境中对NGINX Ingress Controller进行性能测试

还可以免费下载包含完整系列博客的电子书《推动Kubernetes从测试走向生产》。

在选择Ingress控制器指南的第1部分中，我们介绍了如何确定需求。但现在还不是测试产品的时候！本文将说明选错Ingress控制器如何拖慢发布速度，甚至导致客户流失。与任何工具一样，Ingress控制器也可能带来风险，并影响未来的可扩展性。下面来看看如何排除那些可能弊大于利的选项。

Ingress控制器的风险

为Kubernetes引入流量管理工具时，需要考虑三类具体风险：复杂性、延迟和安全性。这些问题往往相互关联；一旦出现其中一个，其他问题也可能随之出现。Ingress控制器可能会引入上述任何一种风险，贵组织需要判断这些风险是否可以接受。如今，消费者的选择很容易改变，因此，即使功能很有吸引力，任何导致数字体验不佳的问题也可能难以接受。

复杂性：是否违背了微服务架构的初衷？

优秀的Kubernetes工具应符合微服务架构的目标：轻量且设计简洁。虽然可以在遵循这些原则的同时开发功能非常丰富的Ingress控制器，但实际情况并非总是如此。有些设计人员加入过多功能，或使用复杂的脚本来附加底层引擎原生不支持的功能，导致Ingress控制器不必要地复杂。

这为什么很重要？在Kubernetes中，过于复杂的工具可能会降低应用性能，并限制部署的横向扩展能力。通常可以通过占用空间来判断Ingress控制器是否过于复杂：占用空间越大，工具就越复杂。

延迟：Ingress Controller是否会拖慢应用？

Ingress Controller可能会因资源使用、错误和超时而增加延迟。请检查静态和动态部署中增加的延迟，并根据内部要求排除会导致延迟超出可接受范围的选项。要详细了解重新配置会如何影响应用速度，请参阅我们博客中的《动态Kubernetes云环境中的NGINX Ingress Controller性能测试》。

安全性：Ingress Controller是否会为黑客打开方便之门？

如今，互联网中普遍存在常见漏洞与披露（CVE）。Ingress控制器提供商交付CVE补丁所需的时间，可能直接影响系统能否避免遭到入侵。根据贵组织的风险承受能力，可以考虑排除需要数天以上（最多数周）才能提供补丁的解决方案。

除了CVE之外，某些Ingress控制器还可能带来另一种潜在漏洞。假设您在一家在线零售商工作，需要他人协助排查开源Ingress控制器的配置问题。由于无法获得商业支持，您便将问题发布到Stack Overflow等论坛。有人主动提供帮助，并希望查看Ingress控制器及其他Kubernetes组件的配置文件和日志文件，以查找问题。迫于尽快解决问题的压力，您分享了这些文件。

这位“热心人”帮您解决了问题，但6个月后，您发现发生了数据泄露，客户记录中的信用卡号已被盗。糟糕的是，您分享的文件中包含了被用于入侵应用的信息。这种情况说明了组织选择付费支持的一个主要原因：付费支持可确保信息保密。

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

OpenResty是基于NGINX Open Source构建的Web平台，集成了LuaJIT、Lua脚本和第三方NGINX模块，以扩展NGINX Open Source的功能。基于OpenResty构建的Ingress控制器有多种。我们认为，与基于NGINX Open Source和NGINX Plus构建的Ingress控制器相比，这些控制器可能会带来两项额外风险：

超时：如前所述，OpenResty使用Lua脚本实现高级功能，类似于我们基于商业版NGINX Plus的Ingress Controller所提供的功能。动态重新配置就是其中之一。它无需遵循NGINX Open Source中一项会降低可用性的要求，即服务端点发生变化时必须重新加载NGINX配置。为了通过OpenResty实现动态重新配置，Lua处理程序会选择将请求路由到哪个上游服务，因此无需重新加载NGINX配置。但是，Lua必须持续检查后端是否发生变化，这会消耗资源。传入请求的处理时间会延长，导致部分请求停滞，从而增加超时的可能性。随着用户和服务数量增加，每秒传入请求数与Lua可处理请求数之间的差距会呈指数级扩大，进而导致延迟、复杂性和成本上升。阅读动态Kubernetes云环境中的NGINX Ingress Controller性能测试，了解Lua可能增加多少延迟。
CVE补丁延迟：与NGINX的Ingress Controller相比，基于OpenResty等工具（而这些工具又基于NGINX Open Source）的Ingress Controller必然需要更长时间才能获得CVE补丁。正如我们在使用NGINX Plus快速轻松地缓解安全漏洞中详细说明的那样，当NGINX中发现CVE时，作为供应商，我们通常会在CVE公开披露前收到通知。因此，我们可以在CVE公布后立即发布NGINX Open Source和NGINX Plus补丁。基于NGINX Open Source的技术可能要到CVE公布时才会获悉相关信息。根据我们的经验，OpenResty补丁的发布时间明显晚于我们的补丁，例如最近有一次晚了4个月。基于OpenResty的Ingress Controller还需要更长时间才能获得补丁，这让恶意攻击者有充分的机会利用该漏洞。

让Ingress Controller从容应对未来需求

即使您刚开始尝试使用Kubernetes，也很可能希望有朝一日将其投入生产。随着时间的推移，您在以下四个主要方面的需求可能会不断增长：基础设施、安全、支持和多租户。

基础设施：是否会在混合云或多云环境中使用Kubernetes？

组织很少会完全且长期只采用一种环境。更常见的情况是，组织同时采用本地环境和云环境，其中可能包括私有云、公有云、混合云和多云。（要深入了解这些环境之间的区别，请阅读《多云与混合云有何区别？》。）

正如本系列第 1 部分所述，选择每种环境的默认工具看似很方便，但默认Ingress控制器存在许多特有问题。我们将在本系列第 3 部分介绍其所有弊端，但与面向未来最相关的问题是供应商锁定，即无法在所有环境中使用特定于某个云的Ingress控制器。使用默认的云专用工具会影响扩展能力，因为最终只剩下以下两个并不理想的选择：

设法让现有云环境满足所有需求
在每个新环境中，为Ingress控制器重写所有配置，包括负载均衡和安全配置！

第一种方案通常会因业务原因而不可行；第二种方案也很棘手，因为它会导致工具泛滥、引入新的安全漏洞，并增加员工的学习难度。第三种方案效率更高，即从一开始就选择与基础设施无关的Ingress控制器，以便在所有环境中使用同一工具。

在基础设施方面，还需要考虑另一个因素：认证。以Red Hat OpenShift Container Platform（OCP）为例。如果您是OCP用户，可能已经知道Red Hat Marketplace为OCP提供经过认证的Operator，其中包括NGINX Ingress Operator。Red Hat的认证标准可让您放心使用，因为该工具能够与您的部署配合使用，甚至还可能包含Red Hat与供应商提供的联合支持。许多组织出于安全性和稳定性考虑，要求使用经过认证的工具。因此，即使目前仅处于测试阶段，也应考虑贵公司对生产环境的要求。

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

仅靠边界安全来保护应用和客户的时代已经过去。将包括身份验证和授权在内的安全措施部署在应用附近，可以更好地保护Kubernetes应用。随着越来越多的组织要求实施端到端加密，并在Kubernetes中采用零信任网络模型，未来可能需要使用服务网格。

这一切与Ingress控制器有什么关系？关系很大！从成本和效率两方面来看，在Ingress入口点集中实施安全措施（身份验证、授权、DoS防护和Web应用防火墙）都非常合理。虽然大多数服务网格都可以与大多数Ingress控制器集成，但集成方式至关重要。选择符合安全策略的Ingress控制器，有助于避免应用开发过程中出现棘手问题。

阅读《在不牺牲速度的情况下保护云原生应用》，详细了解云原生应用交付面临的风险；阅读《在Kubernetes中部署应用服务，第2部分》，进一步了解决定安全工具适宜部署位置的因素。

支持：您能在多大程度上“独自应对”？

当团队刚开始试用Kubernetes时，无论是社区支持还是企业支持，通常都不是首要考虑因素。如果团队有充足时间自行制定解决方案和变通方法，这并无不妥；但进入生产环境后，这种做法难以持续。即使目前不需要支持，也建议选择可在未来添加支持的Ingress控制器，或选择提供经济型支持级别且可随规模扩大而升级的Ingress控制器。

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

故事开始时，只有一个团队和一个应用……每个故事不都是这样开场的吗？接下来，这个团队通常会成功开发出自己的Kubernetes应用，进而推动组织在Kubernetes上运行更多服务。当然，服务越多，团队越多，复杂性也越高。

为尽可能提高效率，组织会采用多租户模式，并使用一种Kubernetes模型。该模型既支持业务流程所要求的访问和隔离，又能提供运维人员所需的合理管理机制和控制能力。某些Ingress控制器可通过多种功能和概念帮助划分这些集群，包括多个Ingress、Ingress类、命名空间，以及支持设置基于角色的访问控制（RBAC）的作用域资源。