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

NGINX | 2021年11月15日

在之前的系列博客在 Kubernetes 中部署应用服务中，我们探讨了许多客户在数字化转型过程中采用的一种模式。大多数转型之旅都始于传统的应用创建和部署模式（通常是单体应用），由相互隔离的开发团队和运维团队分别负责这两项工作。随着组织转向更现代的模式，他们开始创建基于微服务的应用，并采用 DevOps 实践进行部署，从而淡化传统团队之间的界限。

虽然DevOps团队和应用所有者正更直接地掌控应用的部署、管理和交付方式，但一次性打破所有团队壁垒通常并不现实，我们也认为没有必要这样做。相反，我们发现，合理的职责划分仍然适用：

网络和安全团队继续关注企业基础设施的整体安全性、性能和可用性。他们最关注通常部署在基础设施“入口”处的全局服务。这些团队依靠F5 BIG-IP支持以下用例：全局服务器负载均衡（GSLB）、DNS解析和负载均衡，以及高级流量整形。BIG‑IQ和NGINX Controller［现为F5 NGINX Management Suite］以最适合NetOps团队的形式提供指标和警报；同时为SecOps团队提供其保护组织资产和遵守行业法规所必需的安全可见性和控制能力。
运维团队（侧重运维的DevOps团队）根据相关业务线的需求创建和管理各个应用。他们最关注自动化和CI/CD流水线等服务，这些服务有助于更快地迭代更新后的功能；此类服务通常部署在更“靠近”应用的位置，例如Kubernetes环境中。这些团队依靠NGINX Plus、NGINX App Protect、NGINX Ingress Controller和NGINX Service Mesh等NGINX产品，为托管在包括Kubernetes集群在内的多个环境中的分布式微服务应用提供负载均衡和流量整形。用例包括TLS终止、基于主机的路由、URI重写、JWT身份验证、会话持久性、速率限制、运行状况检查、安全防护（将NGINX App Protect用作集成式WAF）等。

Kubernetes环境中的NetOps和DevOps

NetOps和DevOps团队关注的重点不同，这体现在他们在Kubernetes环境中承担的角色以及履行这些职责所使用的工具上。尽管这种说法可能过于简化，但可以认为，NetOps团队主要关注Kubernetes集群外部的基础设施和网络功能，而DevOps团队主要关注集群内部的这些功能。

为了将流量导入Kubernetes集群，NetOps团队可以使用BIG‑IP作为外部负载均衡器。BIG‑IP支持他们熟悉的各种功能和覆盖网络技术。不过，BIG‑IP本身无法跟踪Kubernetes集群内Pod集合的变化（例如Pod数量或其IP地址的变化）。为解决这一限制，可将F5 Container Ingress Services（CIS）作为Operator部署在集群内。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 Ingress Controller如何协同工作

您可能知道，BIG‑IP和NGINX Ingress Controller最初分别由两家公司（F5和NGINX）设计。F5收购NGINX后，客户向我们反馈，提升这两款工具之间的互操作性有助于简化基础设施管理。为此，我们开发了一种名为IngressLink的新Kubernetes资源。

IngressLink资源是一项简单的增强功能，它使用Kubernetes的自定义资源定义（CRD）将NGINX Ingress Controller与BIG‑IP“连接”起来。简而言之，每当NGINX Ingress Controller Pod集合发生变化时，CIS都能将这一变化“告知”BIG‑IP。BIG‑IP可根据这些信息灵活调整相应的负载均衡策略。

部署BIG‑IP为Kubernetes集群提供负载均衡，并由NGINX Ingress Controller处理入站和出站流量后，流量流向如下：

BIG‑IP将外部流量定向到NGINX Ingress Controller实例。
NGINX Ingress Controller将流量分发到集群内的相应服务。
由于NGINX Ingress Controller效率出色，一组稳定的实例即可应对应用Pod集合频繁且大幅的变化。但当NGINX Ingress Controller需要横向扩容或缩容（以应对流量激增或下降）时，CIS会通过IngressLink资源将这些变化通知BIG‑IP，使BIG‑IP能够快速适应变化。