将NGINX Plus配置为Red Hat OCP和Kubernetes的外部负载均衡器

NGINX | 2020年7月24日

在容器编排领域，经常会遇到两个名称：RedHat OpenShift Container Platform (OCP)和Kubernetes。您可能知道，OpenShift和许多其他容器编排平台一样，底层使用Kubernetes。将外部流量路由到Kubernetes或OpenShift环境一直存在一些挑战，主要体现在两个方面：

将部署在Kubernetes内部的服务开放给外部访问。解决方案是使用Ingress控制器，例如NGINX Plus Ingress Controller。有关详细信息，请参阅我们的博客文章《Red Hat OpenShift上的NGINX Ingress Operator入门》。
在Kubernetes节点之间对流量进行负载均衡。为解决这一问题，组织通常会选择外部硬件负载均衡器、虚拟负载均衡器或云原生解决方案。不过，NGINX Plus也可用作外部负载均衡器，从而提升性能并简化技术投资。

本文重点介绍如何使用NGINX Plus以简单高效的方式解决第二个问题，并让应用开发团队能够同时管理Kubernetes内部的Ingress配置和外部负载均衡器配置。为提供一个可帮助您快速入门的参考架构，我在GitHub上创建了nginx-lb-operator项目。NGINX Load Balancer Operator（NGINX-LB-Operator）是一个基于Ansible的NGINX Controller Operator，使用Red Hat Operator Framework和SDK创建。当Kubernetes集群中添加新服务、Pod发生变化或部署扩缩容时，NGINX-LB-Operator会调用NGINX Controller的声明式API，更新外部NGINX Plus负载均衡器的配置。

请注意，NGINX-LB-Operator不在NGINX Plus或NGINX Controller支持协议的涵盖范围内。您可以在GitHub上报告错误或请求故障排除协助。

Kubernetes 与 NGINX 技术回顾

NGINX-LB-Operator依赖多项Kubernetes和NGINX技术，因此下面将简要回顾这些技术，以便大家了解相关背景。如果您已经熟悉这些技术，可以直接跳至“NGINX Load Balancer Operator”。

Kubernetes控制器和Operator

Kubernetes 是一个围绕松耦合中央 API 构建的编排平台。该 API 提供一组资源定义，并通过控制器（通常以 Pod 形式在平台内运行）监控和管理这些资源。Kubernetes API 具有可扩展性，可使用 Operator（一种控制器）扩展 Kubernetes 的功能。

控制器，Kubernetes系统的核心组成部分。控制器为特定的Kubernetes资源创建“监视”，并在各项资源发生变化时执行必要步骤，使其达到期望状态。在与客户沟通时，最常讨论的Kubernetes控制器是“Ingress控制器”。
Operator：一种自定义控制器，通过定义和使用自定义资源定义（CRD）来管理应用及其组件。

适用于Kubernetes的NGINX Ingress Controller

NGINX主要有两种Ingress控制器可供选择。由于它们在GitHub上的名称非常相似，可能不太容易区分。我们曾在一篇之前的博客文章中详细讨论过这个话题，下面快速回顾一下：

kubernetes/ingress-nginx，由Kubernetes开源社区支持和维护的Ingress控制器。为便于表述，我们将其称为“社区Ingress控制器”。不出所料，它基于NGINX Open Source，并提供由第三方Lua模块启用的附加功能，但遗憾的是，这些模块往往会影响性能。
nginxinc/kubernetes-ingress：由F5的NGINX团队维护的Ingress控制器。它有两个版本：一个适用于NGINX Open Source（专为提升速度而构建），另一个适用于NGINX Plus（同样专为提升速度而构建，但提供商业支持和更多企业级功能）。我们将它们称为“NGINX Ingress控制器（或我们的Ingress控制器）”。您可以使用标准Kubernetes Ingress资源管理这两种Ingress控制器。我们还支持注解和ConfigMap，以扩展Ingress规范所提供的有限功能，但以这种方式扩展资源并不理想。1.6.0版本及更高版本的Ingress控制器提供了更好的解决方案：自定义NGINX Ingress资源，称为VirtualServer和VirtualServerRoute。这些资源扩展了Kubernetes API，并以Kubernetes原生方式提供更多功能。NGINX Ingress资源可开放更多NGINX功能，让您能够将高级负载均衡功能与Ingress结合使用，实现蓝绿发布、金丝雀发布和断路器模式等。

有关这三种Ingress控制器选项之间主要差异的概述，请参阅我们的GitHub存储库。

NGINX Controller

NGINX Controller是我们的云无关控制平面，用于管理多个环境中的NGINX Plus实例，并利用有关性能和错误状态的重要洞察。其模块为应用交付（负载均衡）和API管理提供集中式配置管理。NGINX Controller可以管理物理、虚拟和云等多种环境中的NGINX Plus实例配置。它基于最终一致的声明式API构建，并以应用为中心，呈现应用及其组件。它可轻松对接CI/CD流水线，将基础设施与代码解耦，让开发人员专注于本职工作。

对于Kubernetes，NGINX Controller可以管理部署在前端、充当反向代理或API网关的NGINX Plus实例。但不宜使用NGINX Controller管理NGINX Plus Ingress Controller本身，因为Ingress Controller负责Kubernetes核心资源（Ingress）的控制循环，需要使用Kubernetes平台的工具进行管理，即标准Ingress资源或NGINX Ingress资源。

外部负载均衡器

NGINX Plus Ingress Controller for Kubernetes非常适合将Kubernetes内部的服务开放给外部访问，但通常还需要一个外部负载均衡层来管理进入Kubernetes节点或集群的流量。如果在公有云中运行，外部负载均衡器可以是NGINX Plus、F5 BIG-IP LTM Virtual Edition或云原生解决方案。如果部署在本地或私有云中，可以使用NGINX Plus或BIG-IP LTM设备（物理或虚拟）。听说还有其他负载均衡器可用，但我可不信😉。

在管理外部负载均衡器时，可以直接使用NGINX Controller管理外部NGINX Plus实例。其声明式API专为与CI/CD流水线集成而设计，可用于部署各个应用组件。但是，如果Ingress层可扩展、使用动态分配的Kubernetes NodePort，或者OpenShift Route可能发生变化，该怎么办？

在这类情况下，您可能希望将外部负载均衡器配置与Kubernetes状态相结合，并通过Kubernetes Operator调用NGINX Controller API。图中展示了一个示例部署，其中包含用于管理外部负载均衡器的此类Operator（NGINX-LB-Operator），并重点说明了NGINX Plus Ingress Controller与NGINX Controller之间的区别。

其中：

Ingress资源（蓝色框）：项目命名空间中定义了一个标准Ingress资源和一个NGINX VirtualServer资源。
蓝色箭头：Ingress资源在Kubernetes API中创建，并由运行在其他命名空间中的NGINX Plus Ingress Controller获取。
自定义资源（绿色框）：自定义资源是随NGINX-LB-Operator安装的CRD的实例，在项目的命名空间中定义，并由同一命名空间中运行的NGINX-LB-Operator使用。
绿色箭头：资源在API中创建，随后由NGINX-LB-Operator获取。Ingress Controller会配置在同一Pod中运行的本地NGINX Plus实例，而NGINX-LB-Operator则会对NGINX Controller进行API调用。
橙色箭头：NGINX Controller 配置外部 NGINX Plus 实例，将负载均衡到 NGINX Plus Ingress Controller。

在此拓扑中，自定义资源包含外部负载均衡器的期望状态，并将上游（工作负载组）设置为NGINX Plus Ingress Controller。NGINX-LB-Operator收集Ingress Pod的信息，将其与期望状态合并，然后发送至NGINX Controller API。

NGINX负载均衡器Operator

起初，为Kubernetes编写Operator似乎是一项艰巨的任务，但Red Hat和Kubernetes开源社区维护的Operator Framework让这项任务变得相对容易。借助Operator SDK，任何人都可以使用Go、Ansible或Helm创建Kubernetes Operator。F5已为多款产品发布Ansible集合，其中包括NGINX Controller认证集合，因此，构建一个Operator来管理外部NGINX Plus实例并与NGINX Controller对接非常简单。

我使用Operator SDK创建了NGINX负载均衡器Operator，即NGINX-LB-Operator。该Operator可按命名空间或集群范围部署，并监视若干自定义资源。这些自定义资源直接映射到NGINX Controller对象（证书、网关、应用和组件），因此可在Kubernetes中直接呈现NGINX Controller的以应用为中心的模型。NGINX-LB-Operator会获取在Kubernetes中配置的自定义资源，然后在NGINX Controller中创建对应的资源。

借助NGINX-LB-Operator，可以使用NGINX Controller的声明式API管理外部NGINX Plus实例的配置。由于该外部实例由NGINX Controller管理，还可获得监控和警报功能，以及NGINX Controller提供的深入应用洞察。

此图说明了以下内容：

在项目命名空间中创建自定义资源，这些资源将发送到Kubernetes API。
NGINX-LB-Operator 检测到新配置的资源，并从 Ingress 命名空间中的 Ingress 控制器收集组件的期望状态和部署信息。
系统会将您的定义与Ingress控制器当前状态合并为配置，并发送到NGINX Controller。
配置将下发到请求的NGINX Plus实例，NGINX Controller随即开始收集新应用的指标。

详细的部署说明和示例应用已发布在GitHub上。如果您不喜欢角色扮演，或者只想查看精简版，请立即前往。

部署示例

那我们来进行角色扮演。我扮演Susan，您可以扮演Dave。

作为Dave，你在自己最喜欢的虚构企业集团中负责一条业务线。你紧跟年轻人的潮流，时刻掌握最新动态，因此将所有应用和微服务部署在OpenShift上，并使用NGINX Plus Ingress Controller for Kubernetes处理Ingress。所有应用均以OpenShift项目（命名空间）的形式部署，而NGINX Plus Ingress Controller则在其专用的Ingress命名空间中运行。

默认Ingress规范提供的功能一直无法令您满意，而且您始终觉得ConfigMap和Annotation用起来不够便捷。因此，当NGINX宣布NGINX Plus Ingress Controller将开始支持自己的CRD时，您非常高兴。如今，应用开发人员使用VirtualServer和VirtualServerRoutes资源来管理应用向NGINX Plus Ingress Controller的部署，并在OpenShift中配置内部路由和错误处理。

有时甚至还需要公开非 HTTP 服务，这要归功于 NGINX Plus Ingress Controller 同样支持的 TransportServer 自定义资源。开发人员可以在自己的项目命名空间中定义这些自定义资源，NGINX Plus Ingress Controller 随后会获取并立即应用它们。这很方便，但您也希望能同样轻松地管理 OpenShift 集群边缘的外部网络负载均衡器。每次需要扩展 Ingress 层时，都会让您头疼不已。

周六晚上，本该去舞厅尽情跳舞，可昨天又不得不扩展Ingress层，结果现在腰酸背痛。叮！一阵烟雾中，仙女教母Susan现身了。

“你好，Dave，”她说道。

“你是谁？看看你把我的波斯地毯弄成什么样了，”你回答道。

Susan没有理会你的态度，继续向你介绍现已在GitHub上提供的NGINX-LB-Operator。她解释说，可以在OpenShift边缘部署NGINX Plus集群，并使用NGINX Controller从以应用为中心的角度对其进行管理，从而创建自定义资源，定义NGINX Plus负载均衡器的配置方式。

NGINX-LB-Operator会监视这些资源，并利用这些资源将以应用为中心的配置发送到NGINX Controller。随后，NGINX Controller会生成所需的NGINX Plus配置，并将其推送到外部NGINX Plus负载均衡器。

最终用户可以立即访问您的应用，而您可以控制需要修改外部NGINX Plus负载均衡器的变更！

NGINX Controller从外部NGINX Plus负载均衡器收集指标，并继续以熟悉的应用为中心的视角呈现这些指标。下次扩展NGINX Plus Ingress层时，NGINX-LB-Operator会自动更新NGINX Controller和外部NGINX Plus负载均衡器，无需再费力维护！

结论

Kubernetes是一个用于管理容器化应用的平台。NGINX Controller提供以应用为中心的模型，用于理解和管理应用负载均衡。NGINX-LB-Operator将二者结合，让您能够端到端管理整个技术栈，无需担心任何底层基础设施。前往GitHub，了解有关NGINX-LB-Operator的更多技术信息，并查看完整的示例演练。

了解有关F5解决方案的更多信息：