用BGP将流量引导至集群？

NGINX | 2023年2月28日

要创建和管理稳健的Kubernetes环境，网络团队与应用团队必须顺畅协作。但两个团队的工作重点和方式通常存在较大差异，容易引发冲突，并可能造成严重后果，包括应用开发进度缓慢、部署延迟，甚至网络中断。

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

在我们的白皮书《Get Me to the Cluster》中，我们详细介绍了一种支持外部访问Kubernetes服务的解决方案，帮助网络团队和应用团队优势互补、顺畅协作。

如何公开 Kubernetes 集群中的应用

该解决方案专用于部署在本地环境的Kubernetes集群。集群节点运行在裸机或传统Linux虚拟机（VM）上，并由标准的第2层交换机和第3层路由器提供数据中心通信所需的网络连接。该解决方案不适用于云托管的Kubernetes集群，因为云提供商不允许我们控制其数据中心的核心网络，也不允许我们控制其托管Kubernetes环境中的网络。

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

在详细介绍我们的解决方案之前，先来了解一下为什么在本地部署中，其他公开Kubernetes集群内应用的标准方式并不适用：

Service：将运行相同应用的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名称，外部用户可通过该入口访问多项服务。这正是所需的功能！Ingress对象由Ingress控制器实现；在我们的解决方案中，使用的是企业级F5 NGINX Ingress Controller，它基于NGINX Plus构建。

可能出乎意料的是，该解决方案的另一个关键组件是边界网关协议（BGP），这是一种第3层路由协议。但出色的解决方案并不一定复杂！

在Get Me to the Cluster中概述的解决方案实际上包含四个组成部分：

iBGP网络：内部边界网关协议（iBGP）用于在数据中心的自治系统（AS）内交换路由信息，有助于确保网络的可靠性和可扩展性。大多数数据中心已部署iBGP，并由网络团队提供支持。
Project Calico CNI网络：Project Calico是一种开源网络解决方案，可灵活连接本地数据中心内的环境，同时对流量进行精细控制。我们使用Project Calico的CNI插件为Kubernetes集群提供网络连接，并启用BGP。这样便可控制分配给Pod的IP地址池，有助于快速发现网络问题。
基于NGINX Plus的NGINX Ingress Controller：借助NGINX Ingress Controller，可以监控Pod的服务端点IP地址，并自动重新配置上游服务列表，且不会中断流量处理。应用团队还可以利用NGINX Plus提供的其他多项企业级第7层HTTP功能，包括主动健康检查、mTLS和基于JWT的身份验证。
NGINX Plus 作为边缘反向代理，NGINX Plus 作为反向代理部署在 Kubernetes 集群边缘，为数据中心内的交换机和路由器与 Kubernetes 集群内部网络之间提供通信路径。此方案可替代 Kubernetes LoadBalancer 对象，并使用 Quagga 实现 BGP。

该图展示了解决方案架构，说明解决方案组件之间使用哪些协议进行通信，而非请求处理期间的数据交换顺序。