博客 | NGINX

在同一架构中部署 BIG-IP 和 NGINX Ingress Controller

NGINX-F5-horiz-black-type-RGB 的一部分
Micheál Kingston 缩略图
米歇尔·金斯顿
2021 年 11 月 15 日发布

在我们之前的博客系列《在 Kubernetes 中部署application服务》中,我们讨论了许多客户在数字化转型过程中看到的一种模式。 大多数旅程都是从创建和部署应用程序(通常是整体式)的传统模型开始的,将这两个功能的责任划分给孤立的开发和运营团队。 随着组织转向更现代的模式,他们创建基于微服务的应用程序并使用 DevOps 实践进行部署,从而模糊了传统孤岛之间的界限。

虽然 DevOps 团队和应用所有者正在更直接地控制其应用的部署、管理和交付方式,但一次性打破孤岛墙往往是不切实际的——我们也认为没有必要。 相反,我们观察到责任的合理划分仍然适用:

  • 网络和安全团队继续关注企业基础设施的整体安全性、性能和可用性。 他们最关心的是全球服务,这些服务通常部署在基础设施的“前门”。

    这些团队依靠F5 BIG-IP来实现全局服务器负载均衡(GSLB)、 DNS解析和负载均衡以及复杂的流量整形等用例。 BIG‑IQ和 NGINX 控制器[现为F5 NGINX 管理套件]以最适合 NetOps 团队的形式提供指标和警报,而对于 SecOps 团队,它们提供 SecOps 必须具备的安全性可见性和控制力,以保护组织的资产并遵守行业法规。

  • 运营团队(DevOps,重点是 Ops)根据相关业务线的要求创建和管理单个应用。 他们最关心的是自动化和 CI/CD 管道等服务,这些服务可以帮助他们更快地迭代更新的功能;此类服务通常部署在“更靠近”应用程序的地方,例如在 Kubernetes 环境中。

    这些团队依靠 NGINX 产品(例如NGINX PlusNGINX App ProtectNGINX Ingress ControllerNGINX Service Mesh)来实现托管在多个环境(包括 Kubernetes 集群)中的分布式、基于微服务的应用的负载均衡和流量整形。 用例包括 TLS 终止、基于主机的路由、URI 重写、JWT 身份验证、会话持久性、速率限制、健康检查、安全性(使用 NGINX App Protect 作为集成 WAF)等等。

Kubernetes 环境中的 NetOps 和 DevOps

NetOps 和 DevOps 团队的不同关注点体现在他们在 Kubernetes 环境中扮演的角色以及他们用来实现这些角色的工具上。 尽管有过于简单化的风险,我们可以说 NetOps 团队主要关注 Kubernetes 集群之外的基础设施和网络功能,而 DevOps 团队则关注集群内部的功能。

为了将流量引导到 Kubernetes 集群,NetOps 团队可以使用 BIG-IP 作为外部负载均衡器,以支持他们已经熟悉的覆盖网络技术的功能和范围。 然而,BIG-IP 本身无法跟踪 Kubernetes 集群内 Pod 集的变化(例如 Pod 数量或其 IP 地址的变化)。 为了解决这一限制, F5 容器入口服务(CIS)被部署为集群内部的操作员。 CIS 监视 pod 集的变化,并相应地自动修改 BIG-IP 系统的负载平衡池中的地址。 它还会寻找新的 Ingress、Route 和自定义资源的创建,并相应地更新 BIG-IP 配置。

尽管您可以结合使用 BIG‑IP 与 CIS来直接对到应用pod 的流量进行负载平衡,但实际上,NGINX Ingress Controller 是发现并跟上代表大量服务的 pod 和工作负载的动态应用变化的理想解决方案 - 例如,在水平扩展应用pod 以满足不断变化的需求水平期间。

部署 NGINX Ingress Controller 的另一个优点是它将应用负载均衡的控制权转移到负责应用本身的 DevOps 团队。 其高性能控制平面和以 DevOps 为中心的设计使其特别擅长支持跨多个命名空间的 Kubernetes 服务的快速变化的 DevOps 用例(例如就地重新配置和滚动更新)。 NGINX Ingress Controller 使用本机 Kubernetes API 来发现扩展的 Pod。

BIG-IP 和 NGINX 入口控制器如何协同工作

您可能知道,BIG-IP 和 NGINX Ingress Controller 最初是由两家独立的公司(分别是 F5 和 NGINX)设计的。 自从 F5 收购 NGINX 以来,客户告诉我们,提高两种工具之间的互操作性将简化其基础设施的管理。 作为回应,我们开发了一种称为 IngressLink 的新 Kubernetes 资源。

IngressLink 资源通过 Kubernetes CustomResourceDefinition (CRD) 简化了 NGINX Ingress Controller 与 BIG-IP 之间的“链接”。 换言之,每当 NGINX Ingress Controller pod 集合发生变化,CIS 就会通知 BIG-IP。 有了这些信息,BIG-IP 能灵活调整相关的负载均衡策略以保持同步。

通过部署 BIG‑IP 对 Kubernetes 集群进行负载均衡,并使用 NGINX Ingress Controller 处理入口和出口流量,流量流向如下:

  1. BIG‑IP 将外部流量引导至 NGINX Ingress Controller 实例。
  2. NGINX Ingress Controller 将流量分配到集群内的适当服务。
  3. 由于 NGINX Ingress Controller 非常高效,一组稳定的实例可以处理应用pod 集的频繁和大量更改。 但是,当您的 NGINX Ingress Controller 需要水平扩展或缩减(以处理流量激增和下降)时,CIS 会将变化通知 BIG-IP(通过 IngressLink 资源),使 BIG-IP 能够快速适应变化。

与 F5 Container Ingress Services 部署在同一 Kubernetes 环境中的 F5 BIG-IP 和 F5 NGINX Ingress Controller 拓扑图

入门

有关 IngressLink 资源如何运作的更多详细信息(包括部署指南),请访问F5 CloudDocs

首先申请 NGINX Ingress Controller 和 NGINX App Protect WAF 和 DoS 的30 天免费试用版。 如果您还不是 BIG‑IP 用户,请在 F5.com 上选择最适合您团队的试用版


“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息,请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”