博客 | NGINX

通过 BGP 将我带入集群?

NGINX-F5-horiz-black-type-RGB 的一部分
Chris Akker 缩略图
克里斯·阿克
2023 年 2 月 28 日发布

创建和管理强大的 Kubernetes 环境需要网络和application团队之间的顺畅协作。 但他们的优先事项和工作风格通常有很大差异,从而导致冲突并可能造成严重后果——应用程序开发缓慢、部署延迟,甚至网络停机。

只有两个团队朝着共同的目标努力并取得成功,才能确保当今的现代应用能够按时交付并具有适当的安全性和可扩展性。 那么,如何利用每个团队的技能和专业知识,同时帮助他们协同工作?

在我们的白皮书《进入集群》中,我们详细介绍了实现对 Kubernetes 服务的外部访问的解决方案,该解决方案使网络和application团队能够结合他们的优势而不会发生冲突。

如何在 Kubernetes 集群中公开应用程序

该解决方案专门适用于在本地托管的 Kubernetes 集群,其中节点在裸机或传统 Linux 虚拟机 (VM) 上运行,标准第 2 层交换机和第 3 层路由器为数据中心的通信提供网络。 它不能扩展到云托管的 Kubernetes 集群,因为云提供商不允许我们控制其数据中心的核心网络或其管理的 Kubernetes 环境中的网络。

本地托管的 Kubernetes 集群图,其中节点和标准第 2 层交换机以及第 3 层路由器为数据中心内的通信提供网络。

在讨论解决方案的具体细节之前,让我们先回顾一下为什么在 Kubernetes 集群中公开应用的其他标准方式不适用于本地部署:

  • 服务——将运行相同应用程序的 pod 组合在一起。 这对于内部pod 到 pod 的通信非常有用,但仅在集群内部可见,因此它无助于向外部公开应用程序。
  • NodePort – 在集群中的每个节点上打开特定端口,并将流量转发到相应的应用程序。虽然这允许外部用户访问服务,但这并不理想,因为配置是静态的,您必须使用高编号的 TCP 端口(而不是众所周知的较低端口号),并与其他应用程序协调端口号。 您也无法在不同的应用程序之间共享通用的 TCP 端口。
  • LoadBalancer——使用每个节点上的 NodePort 定义创建从外部世界到 Kubernetes 节点的网络路径。 它非常适合云托管的 Kubernetes,因为 AWS、Google Cloud Platform、Microsoft Azure 和大多数其他云提供商都支持它,将其作为一项易于配置的功能,运行良好并为服务提供所需的公共 IP 地址和匹配的 DNS A记录。 不幸的是,本地集群没有等效的解决方案。

允许外部用户访问本地 Kubernetes 集群

这给我们留下了 Kubernetes Ingress 对象,它是专门为从集群外部用户流向集群内部 pod 的流量(南北流量)而设计的。 Ingress 为集群创建一个外部 HTTP/HTTPS 入口点 - 一个单一的 IP 地址或 DNS 名称,外部用户可以通过该 IP 地址或 DNS 名称访问多个服务。 这正是所需要的! Ingress 对象由 Ingress 控制器实现 - 在我们的解决方案中是基于NGINX Plus 的企业级F5 NGINX Ingress 控制器

您可能会感到惊讶,该解决方案的另一个关键组件是边界网关协议(BGP),一种第 3 层路由协议。 但一个好的解决方案不一定很复杂!

《Get Me to the Cluster》中概述的解决方案实际上有四个组件:

  1. iBGP 网络– 内部 BGP (iBGP) 用于在数据中心的自治系统 (AS) 内交换路由信息,有助于确保网络的可靠性和可扩展性。iBGP 已在大多数数据中心部署并得到网络团队的支持。
  2. Project Calico CNI 网络- Project Calico是一种开源网络解决方案,可以灵活地连接本地数据中心的环境,同时对流量进行细粒度的控制。 我们使用 Project Calico 的 CNI 插件在 Kubernetes 集群中进行网络连接,并启用了 BGP。 这使您可以控制为 pod 分配的 IP 地址池,从而有助于快速识别任何网络问题。
  3. 基于 NGINX Plus 的 NGINX Ingress Controller – 使用 NGINX Ingress Controller,您可以监视 pod 的服务端点 IP 地址,并自动重新配置上游服务列表,而不会中断流量处理。 application团队还可以利用 NGINX Plus 中的许多其他企业级第 7 层 HTTP 功能,包括主动健康检查、mTLS 和基于 JWT 的身份验证。
  4. NGINX Plus 作为边缘的反向代理- NGINX Plus 作为 Kubernetes 集群边缘的反向代理,在数据中心的交换机和路由器与 Kubernetes 集群的内部网络之间提供路径。 它可替代 Kubernetes LoadBalancer 对象并使用 Quagga 实现 BGP。

该图说明了解决方案架构,指出了解决方案组件用于通信的协议,而不是在请求处理过程中交换数据的顺序。

说明解决方案架构的图表,指明解决方案组件使用哪些协议进行通信

免费下载白皮书

通过共同实施具有明确定义组件的解决方案,网络和application团队可以轻松提供最佳性能和可靠性。

我们的解决方案使用现代网络工具、协议和现有架构。 由于它的设计成本低廉,并且易于实施、管理和支持,它增加了便利性并在您的团队之间架起了桥梁。

要查看代码的实际运行并逐步了解如何部署我们的解决方案,请免费下载Get Me to the Cluster


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