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

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

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

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

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

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

  这些团队依靠 NGINX 产品（例如NGINX Plus 、 NGINX App Protect 、 NGINX Ingress Controller和NGINX 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 能够快速适应变化。

入门

有关 IngressLink 资源如何运作的更多详细信息（包括部署指南），请访问F5 CloudDocs 。

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