Ingress Controller 选型指南，第二部分：评估风险和技术前瞻性

发表于2021-11-01 10:59

浏览 1.5k

原文作者：Jenn Gile - Manager, Product Marketing
原文链接：Ingress Controller 选型指南，第二部分：评估风险和技术前瞻性
转载来源：NGINX 中文官网

NGINX 唯一中文官方社区，尽在 nginx.org.cn

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

生产级 Kubernetes 助您降低复杂性
如何通过高级流量管理提高 Kubernetes 的弹性
如何提高 Kubernetes 环境的可视性
使用流量管理工具保护 Kubernetes 的六种方法
Ingress Controller 选型指南，第一部分：确定需求
Ingress Controller 选型指南，第二部分：评估风险和技术前瞻性（本文）
Ingress Controller 选型指南，第三部分：开源、默认和商用版本能力对比
Ingress Controller 选型指南，第四部分：NGINX Ingress Controller 选项
如何选择 Service Mesh
NGINX Ingress Controller 在动态 Kubernetes 云环境中的性能测试

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

欢迎阅读 Ingress Controller 选购指南系列博文的第二部分。您现在已经确定了需求，但还不是测试产品的时候！在本部分博文中，我们将向大家说明为何不合适的 Ingress Controller 将会降低您的发布速度，甚至对客户造成损失。同其他工具一样，Ingress Controller 也存在着风险并可能影响未来的可扩展性。下面我们来看看如何避免做出弊大于利的选择。

Ingress Controller 的风险

在选择 Kubernetes 流量管理工具时，您应考虑三个特定风险：复杂性、延迟和安全性。这些风险盘根错节，往往牵一发而动全身。Ingress Controller 可能会引发其中的任何一个问题，能否容忍这些风险就要看企业自己的选择了。现在的消费者都很“薄情”，只要感到数字体验不好，那么无论功能多么强大，他们也会一去不回头。

复杂性 —— Ingress Controller 是否与微服务架构的目标背道而驰？

能够满足微服务架构目标（设计简单、轻量化）的工具才是一款好的 Kubernetes 工具。开发一种功能丰富且遵循这些原则的 Ingress Controller是有可能的，但并不是所有时候都能如愿。设计人员有时会添加过多的功能，或使用复杂脚本来扩展底层引擎的非原生功能，导致 Ingress Controller 因不必要的复杂性而臃肿不堪。

为什么必须要降低复杂性？在 Kubernetes 中，过于复杂的工具不仅会影响应用性能，而且还会限制您横向扩展部署的能力。我们通常可以通过大小来看复杂性：Ingress Controller 占用空间越大就意味着其越复杂。

延迟 —— Ingress Controller 是否会减缓应用速度？

Ingress Controller 可能会因资源使用、错误和超时而增加延迟。您需要了解静态和动态部署中因Ingress Controller而增加的延迟，并根据您的内部需求消除导致延迟过长的相关选项。想要深入了解重新配置会如何影响应用速度，请阅读我们的博文：《在动态 Kubernetes 云环境中测试 NGINX Ingress Controller 的性能》。

安全性 —— Ingress Controller 是否为黑客提供了可乘之机？

在当今的互联网中，通用漏洞披露 (CVE) 在如今的互联网中十分猖獗，Ingress Controller 提供商提供 CVE 补丁的速度决定了 Ingress Controller 的安全性能。根据企业的风险承受能力，您可能想要弃用补丁发布时间超过几天（或最多几周）的解决方案。

除了 CVE 中的漏洞之外，一些 Ingress Controller 还会存在另一个潜在漏洞。假设您为一家在线零售商工作，您的开源 Ingress Controller 的配置出现了问题，亟需别人的帮助。由于没有购买商业支持服务，您将问题发布到了 Stack Overflow 等论坛。有人向您伸出了援手，他想要看一下是否是 Ingress Controller 及其他 Kubernetes 组件的配置和日志文件出现了问题。迫于尽快解决问题的压力，您共享了文件。

这个“好心人”帮您解决了问题，但六个月后公司遭到入侵了，客户记录里的信用卡号码被盗了。这是怎么回事？原来是您共享的文件中包含一些信息，被居心叵测的攻击者用来入侵应用了。这也恰好反映了企业选择购买支持服务的主要原因之一：它能保证机密性。

关于基于 OpenResty 的 Ingress Controller 的说明

OpenResty 是一个基于 NGINX 开源软件构建的 Web 平台，它包含了 LuaJIT、Lua 脚本和第三方 NGINX 模块，可扩展 NGINX 开源软件的功能。市面上有几种 Ingress Controller 是基于 OpenResty 构建的，我们认为与我们基于 NGINX 开源软件和 NGINX Plus 构建的 Ingress Controller 相比，它们可能会额外带来两个风险：

超时 —— 如上文所述，OpenResty 使用 Lua 脚本来实现高级功能，就像基于商用 NGINX Plus 的 Ingress Controller 中的功能一样。其中一项功能是动态重新配置，这消除了 NGINX 开源软件中原本会降低可用性的一项要求，即当服务端点发生变化时必须重新加载 NGINX 配置。为了使 OpenResty 能够实现动态重新配置，Lua handler 需要选择将请求路由到哪个上行服务，从而消除重新加载 NGINX 配置的需要。

但是，Lua 必须持续检查后端的变更情况，十分消耗资源。处理入站请求的时间延长，导致部分请求被搁置，从而增加了超时的可能性。随着用户和服务规模的不断扩大，每秒入站请求的数量与 Lua 可以处理的请求数量之间的差距呈指数级扩大，最终导致延迟、复杂性和成本的增加。

CVE 补丁延迟 —— 由于 OpenResty 实际上是基于 NGINX 开源软件的，与 NGINX 团队自己开发的 Ingress Controller 相比，CVE 补丁推送到基于 OpenResty 等工具的 Ingress Controller 中的时间更长，这一点无法避免。当在 NGINX 中发现 CVE 漏洞时，我们作为厂商通常会在 CVE 公开披露之前得到通知。因此，我们能够在 CVE 发布后立即发布 NGINX 开源软件和 NGINX Plus 的补丁。

在此之前，使用 NGINX 开源软件的技术群体可能不会知晓这个 CVE 漏洞的存在。根据我们的经验，OpenResty 补丁的发布时间比我们晚得多（最近一次晚了四个月）。基于 OpenResty 的 Ingress Controller 的补丁发布时间不可避免的更滞后，这为攻击者提供了可乘之机。

面向未来的 Ingress Controller

即使您只是刚开始使用 Kubernetes，您可能也希望有朝一日将其投入生产。随着时间的推移，您在基础架构、安全性、技术支持和多租户等四个主要领域的需求可能会有所增长。

基础架构 —— 您是否会在混合或多云环境中使用 Kubernetes？

很少有企业会一直完全使用一种环境，反而是本地和云端的混合环境更为常见。这种环境一般包含私有云、公有云、混合云和多云。

我们在本系列博文第一部分中提到过，企业一般会选择每种环境默认的工具，但默认的 Ingress Controller 本身存在许多问题。我们将在本系列博文的第三部分讨论这样做的所有弊端，但与前瞻性最有关系的问题是厂商锁定，即您无法在所有环境中使用特定云厂商的 Ingress Controller。使用默认的特定云工具将会影响您的扩展能力，因为您只有两个毫无吸引力的替代方案：

尝试让现有的云满足所有需求
在每个新环境中重写 Ingress Controller 的所有配置，不仅包括负载均衡，而且还包括安全防护！

第一种方案出于商业原因通常不可行，第二种同样也很棘手，因为它会导致工具无序蔓延、引发新的安全漏洞，并需要员工学习大量新知识。第三种，也是最有效的替代方案，就是从一开始就选择一种独立于基础架构的 Ingress Controller，以便在所有环境中使用相同的工具。

涉及到基础架构，我们还要考虑认证这个因素。我们以红帽 OpenShift 容器平台 (OCP) 为例。如果您是 OCP 用户，那么您可能已经知道 Red Hat Marketplace 为 OCP 提供认证的operator，其中包括 NGINX Ingress Operator。红帽认证标准意味着该工具适用于您的部署环境，甚至红帽与厂商联合提供支持，从而让您高枕无忧。出于安全性和稳定性的原因，许多企业都要求使用经过认证的工具，因此即使您目前只处于测试阶段，牢记公司的生产环境要求也是有好处的。

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

仅靠边界安全就足以保护应用与客户安全的日子已经成为过去式。现在，只有在靠近 Kubernetes 应用的地方实施安全防护（包括身份验证和授权），才能为其提供最强大的保护。随着越来越多的企业在 Kubernetes 中强制采用端到端加密方法和零信任网络模型，服务网格可能将会成为您未来计划的一部分。

所有这些又与 Ingress Controller 有什么关系呢？关系很大！成本和效率的角度来看，在 Ingress 中集中管理安全防护措施（身份验证、授权、DoS 防护、Web 应用防火墙）具有重要意义。虽然大多数服务网格能够与大多数 Ingress Controller 集成，但它们的集成方式很重要。符合您的安全策略的 Ingress Controller 可防止您在应用开发过程中遇到重大问题。

支持 —— 您“自力更生”的能力有多强？

对于只是试用 Kubernetes 的团队来说，无论是来自社区或是公司的支持通常都不是最重要的。因为如果您的团队时间充足，就能够制定自己的解决方案和应变方法。但进入生产环境后，这就行不通了。即使您现在不需要支持，您可以明智地选择一种允许您在未来添加支持的 Ingress Controller，或者选择一种价格经济并且可以随着您的扩展而升级的支持。

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

企业发展之初，很多都只有一个团队和一个应用。随着这个团队成功开发出一个 Kubernetes 应用，企业开始在 Kubernetes 上运行更多服务。当然，更多的服务意味着更多的团队以及更高的复杂性。

为了最大限度地提高效率，企业采用多租户和 Kubernetes 模型，以支持业务流程所需的访问和隔离，同时提供运营商所需的安全性和控制力。一些 Ingress Controller 可以通过多种功能和概念帮助您划分这些集群，其中包括支持设置基于角色的访问控制 (RBAC) 的多个入口（ingress）、类（class）、命名空间（namespace）和限定资源（scoped resources）。