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

“在 Kubernetes 中部署应用服务”这个博客系列中，我们讨论了许多客户在数字化转型中采用的模式。当数字化转型开启时，大多数企业都采用传统模式创建和部署应用（通常是单体应用），并由独立的开发和运营团队分别对这两个功能负责。随着企业转向更现代化的模式，他们开始创建基于微服务的应用并使用 DevOps 理念来部署应用，这使得传统孤岛之间的界限变得日益模糊。

虽然 DevOps 团队和应用所有者现在能够更直接地控制应用的部署、管理和交付方式，但打破壁垒通常并不能一蹴而就，而且我们认为也没有必要。相反，我们观察到职责的逻辑划分仍然适用：

网络与安全团队仍然关注企业基础架构的整体安全性、性能和可用性。他们最关心的是全局服务，而这些服务通常部署在企业基础架构的“入口”。

这些团队依赖 F5 BIG-IP 部署全局负载均衡（GSLB）、 DNS 解析、复杂的负载均衡等用例。对于 NetOps 团队，BIG‑IQ 和 NGINX Controller 能够提供最佳的指标参数和警报信息以满足需求。而对于 SecOps 团队，这两款产品也能提供可视化和安全控制用以保护企业资产并满足行业法规的监管要求。
运营团队（侧重于运营的 DevOps）根据相关业务的需求创建和管理各个应用。他们最关心自动化和 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 集群内部的功能。

为了将流量引导到 Kubernetes 集群，NetOps 团队可以将 BIGIP 用作外部负载均衡器，为他们熟悉的功能和 Overlay 网络提供支持。但就 BIGIP 本身而言，它无法跟踪 Kubernetes 集群内 Pods 的变化（例如 Pods 的数量或其 IP 地址的变化）。为了解决这个问题，我们将 F5 Container Ingress Services (CIS) 部署为集群内部的操作员（operator）。CIS 会监视 Pods 的变化，并相应地自动修改 BIGIP 系统负载均衡池中的地址。它还会查找新创建的 Ingress、Route 和自定义资源，并相应地更新 BIGIP 配置。

虽然您可以将 BIGIP 和 CIS 结合使用，直接将流量负载均衡到应用的 Pods 上；但实际上，当应用发生动态变化，从而需要Pods和工作负载做出相应调整时，NGINX Ingress Controller 才是发现并应对这些变化的理想解决方案（例如：当需要横向扩展 Application Pods 以满足需求的变化时）。

部署 NGINX Ingress Controller 的另一个优势是它将应用负载均衡的控制权转移给了负责应用本身的 DevOps 团队。它的高性能控制平面和以 DevOps 为中心的设计使其能够为快速变化的 DevOps 用例提供强大支持（例如：对多个命名空间中的 Kubernetes 服务进行就地重新配置和滚动更新）。同时，NGINX Ingress Controller 使用原生 Kubernetes API 来发现哪些 Pod 已经被扩展了。

BIG-IP 和 NGINX Ingress Controller 如何协同工作

如您所知，BIGIP 和 NGINX Ingress Controller 最初是由两个独立的公司（分别为 F5 和 NGINX）打造的。自 F5 收购 NGINX 之后，客户表示提高这两个工具之间的互操作性将简化基础架构的管理。为此，我们开发了一个新的 Kubernetes 资源：IngressLink。

IngressLink 是一个简洁的增强功能，它使用 Kubernetes CustomResourceDefinition (CRD) 来“连接”NGINX Ingress Controller 和 BIGIP。简而言之，它能够让 CIS 在 NGINX Ingress Controller Pods 发生变化时“告诉” BIGIP。有了这个信息，BIGIP 可以灵活地改变相应的负载均衡策略与之匹配。

当使用 BIGIP 对 Kubernetes 集群实施负载均衡，并使用 NGINX Ingress Controller 处理进出流量，流量的流向将会是这样的：

BIGIP 将外部流量定向到 NGINX Ingress Controller 实例。
NGINX Ingress Controller 将流量分发到集群内相应的服务。
由于 NGINX Ingress Controller 非常高效，一组稳定的实例集就可以处理大量频繁变化的 Application Pods。但是，当 NGINX Ingress Controller 本身需要横向扩展或缩减（为了应对流量激增或骤降）时，CIS 会通知 BIGIP 相关的变化（通过 IngressLink 资源），从而让 BIGIP 快速进行调整。

立即开始

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

赶快申请含 NGINX App Protect（提供 WAF 和 DoS 防护）的 NGINX Ingress Controller 30 天免费试用版吧！如果您还不是 BIGIP 用户，请在 F5.com 上选择最符合您的团队需求的试用版。