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

在容器编排领域，我们经常会遇到两个名字： RedHat OpenShift 容器平台 (OCP) 和 Kubernetes。 您可能知道，OpenShift 底层使用 Kubernetes，许多其他容器编排平台也是如此。 将外部流量路由到 Kubernetes 或 OpenShift 环境始终有些困难，主要体现在两个方面：

• 将 Kubernetes 内部部署的服务暴露给外界。 解决方案是像NGINX Plus Ingress Controller这样的 Ingress 控制器。 您可以在我们的博客《在 Red Hat OpenShift 上开始使用 NGINX Ingress Operator》中阅读有关它的更多信息。
• 在 Kubernetes 节点之间平衡流量负载。 为了解决这个问题，组织通常选择外部硬件或虚拟负载均衡器或云原生解决方案。 但是， NGINX Plus也可以用作外部负载均衡器，提高性能并简化您的技术投资。

在这篇博客中，我将重点介绍如何使用 NGINX Plus 以简单、高效的方式解决第二个问题，并使您的 App Dev 团队能够同时管理 Kubernetes 内部的 Ingress 配置和外部的外部负载均衡器配置。 作为帮助您入门的参考架构，我在 GitHub 中创建了nginx-lb-operator项目 - NGINX 负载均衡器操作员（ NGINX-LB-Operator ）是一个基于 Ansible 的NGINX 控制器操作员，使用Red Hat Operator Framework和 SDK 创建。 NGINX-LB-Operator驱动 NGINX Controller 的声明性 API，以便在 Kubernetes 集群中添加新服务、Pod 更改或部署扩展时更新外部 NGINX Plus 负载均衡器的配置。

请注意， NGINX-LB-Operator不受 NGINX Plus 或 NGINX Controller 支持协议的约束。 您可以在GitHub上报告错误或请求故障排除帮助。

Kubernetes 和 NGINX 技术——回顾

NGINX-LB-Operator依赖于许多 Kubernetes 和 NGINX 技术，因此我提供了一个快速回顾，以便让我们都达成共识。 如果你已经熟悉它们，请随意跳到NGINX 负载均衡器操作员。

Kubernetes 控制器和操作员

Kubernetes 是一个围绕松散耦合的中央 API 构建的编排平台。该 API 提供了一系列资源定义，以及用于监控和管理这些资源的控制器（通常在平台内以 Pod 形式运行）。 Kubernetes API是可扩展的，并且可以使用Operators（一种Controller）来扩展Kubernetes的功能。

• 控制器—— Kubernetes 系统的核心部分。 它们为特定的 Kubernetes 资源创建“监视”，并执行必要的步骤以在每个资源发生变化时达到所需的状态。 在客户对话中，讨论最多的 Kubernetes 控制器是“Ingress Controller”。
• 操作员- 自定义控制器，定义并使用自定义资源定义 (CRD) 来管理应用及其组件。

适用于 Kubernetes 的 NGINX 入口控制器

NGINX 有两个主要的 Ingress 控制器选项，由于 GitHub 中的名称非常相似，因此区分它们可能会有点混乱。 我们在之前的博客中详细讨论过这个话题，这里我们简单回顾一下：

• kubernetes/ingress-nginx – Kubernetes 开源社区支持和维护的 Ingress 控制器。 为了方便使用，我们将其称为“社区的 Ingress 控制器”。 毫不奇怪，它基于 NGINX 开源。 它提供了由第三方 Lua 模块启用的附加功能，但不幸的是，这些功能往往会损害性能。

• nginxinc/kubernetes-ingress – 由 F5 的 NGINX 团队维护的 Ingress 控制器。 有两个版本：一个用于 NGINX 开源版本（专为速度而构建），另一个用于 NGINX Plus 版本（也专为速度而构建，但提供商业支持并具有额外的企业级功能）。 我们称之为“NGINX（或我们的）Ingress 控制器”。

  您可以使用标准 Kubernetes Ingress 资源管理我们的两个 Ingress 控制器。 我们还支持Annotations和ConfigMaps来扩展 Ingress 规范提供的有限功能，但以这种方式扩展资源并不理想。

  我们的 Ingress 控制器版本 1.6.0及更高版本包含一个更好的解决方案：称为VirtualServer 和 VirtualServerRoute的自定义NGINX Ingress 资源，它们扩展了 Kubernetes API 并以 Kubernetes 原生方式提供附加功能。 NGINX Ingress 资源公开了更多的 NGINX 功能，使您能够使用 Ingress 的高级负载均衡功能、实现蓝绿和金丝雀发布以及断路器模式等。

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

NGINX 控制器

NGINX 控制器是我们与云无关的控制平面，用于管理多个环境中的 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虚拟版或云原生解决方案。 如果您在本地或私有云中部署，则可以使用 NGINX Plus 或BIG-IP LTM （物理或虚拟）设备。 有人告诉我还有其他可用的负载均衡器，但我不相信。

在管理外部负载均衡器时，您可以直接使用 NGINX 控制器管理外部 NGINX Plus 实例。 它的声明性 API 旨在与您的 CI/CD 管道交互，您可以使用它部署每个应用组件。 但是，如果您的 Ingress 层是可扩展的，您使用动态分配的 Kubernetes NodePorts ，或者您的OpenShift Routes可能会发生变化，该怎么办？

在这种情况下，您可能希望将外部负载均衡器配置与 Kubernetes 状态合并，并通过 Kubernetes Operator 驱动 NGINX Controller API。 该图展示了一个示例部署，其中包括一个用于管理外部负载均衡器的操作符（ 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获取。 与配置在同一 Pod 中运行的本地 NGINX Plus 实例的 Ingress Controller 不同， NGINX-LB-Operator对 NGINX Controller 进行 API 调用。
• 橙色箭头– NGINX 控制器配置外部 NGINX Plus 实例以将负载平衡到 NGINX Plus Ingress Controller 上。

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

NGINX 负载均衡器操作员

为 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 负载均衡器操作员NGINX-LB-Operator ，它可以与命名空间或集群范围一起部署，并监视少量自定义资源。 自定义资源直接映射到 NGINX Controller 对象（证书、网关、应用和组件），因此直接在 Kubernetes 中表示 NGINX Controller 的应用为中心的模型。 Kubernetes 中配置的自定义资源由NGINX-LB-Operator获取，然后在 NGINX Controller 中创建等效资源。

NGINX-LB-Operator可让您使用 NGINX Controller 的声明式 API 管理外部 NGINX Plus 实例的配置。由于 NGINX Controller 正在管理外部实例，因此您可以获得监控和警报的额外好处，以及 NGINX Controller 提供的深入应用洞察。

下图说明了如何：

1. 您可以在项目命名空间中创建自定义资源，并将其发送到 Kubernetes API。
2. NGINX-LB-Operator查看新配置的资源，并从 Ingress 命名空间中的 Ingress 控制器收集组件的所需状态和部署信息。
3. 根据您的定义和 Ingress 控制器的当前状态合并的配置将发送到 NGINX 控制器。
4. 配置被传送到请求的 NGINX Plus 实例，然后 NGINX Controller 开始收集新应用的指标。

GitHub上提供了详细的部署说明和示例应用。 如果您不喜欢角色扮演，或者您来这里是为了 TL;DR 版本，那么请立即前往那里。

示例部署

让我们角色扮演吧。 我扮演苏珊，你扮演戴夫。

作为戴夫，您在您最喜欢的虚拟企业集团中经营一条业务线。 您与孩子们在一起，把握脉搏，等等，所以您在 OpenShift 上部署了所有的应用和微服务，对于 Ingress，您使用了 Kubernetes 的 NGINX Plus Ingress Controller。 您的所有应用都作为 OpenShift 项目（命名空间）部署，并且 NGINX Plus Ingress Controller 在其自己的 Ingress 命名空间中运行。

您从来没有对默认 Ingress 规范中提供的功能感到满意，并且总是认为 ConfigMaps 和 Annotations 有点笨重。 这就是为什么当 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 都会继续向你介绍现在可以在 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 控制器从外部 NGINX Plus 负载均衡器收集指标，并从您已经享受的相同应用中心视角向您呈现这些指标。 下次您扩展 NGINX Plus Ingress 层时，NGINX-LB-Operator 会自动为您更新 NGINX Controller 和外部 NGINX Plus 负载均衡器。 不再有背痛！

结论

Kubernetes 是一个为管理容器化应用而构建的平台。 NGINX 控制器提供了一个以应用为中心的模型，用于思考和管理应用负载均衡。 NGINX-LB-Operator 将两者结合起来，使您能够端到端管理整个堆栈，而无需担心任何底层基础设施。 请前往GitHub获取有关NGINX-LB-Operator 的更多技术信息和完整的示例演练。

详细了解我们的解决方案：

• 申请免费试用NGINX Controller
• 联系我们讨论您的用例
• 获取适用于 OpenShift 的NGINX Ingress Operator
• 注册参加讲师指导的课程