此参考架构在 Google Distributed Cloud (GDC) 气隙环境中提供客户管理的第 7 层负载均衡解决方案。通过在 GDC
标准集群上部署 HAProxy Kubernetes Ingress 或 NGINX Gateway Fabric 等热门开源控制器，客户可以无缝地将 L7
流量路由到混合环境。此架构使用 TLS 终止
(Ingress / HTTPRoute)，根据
服务器名称指示
(SNI) 将流量路由到内置容器化 Pod 和托管在外部
虚拟机上的应用。
特性和功能
- 高级第 7 层路由： 支持基于主机的路由、基于路径的路由和高级流量管理，例如基于标头的匹配和流量加权。
- 集中式 TLS 管理： 提供集中式 TLS 管理和终止。
- 混合环境支持： 无缝地将 L7 流量路由到内置容器化 Pod 和托管在外部虚拟机上的应用。
- 灵活的控制器选项： 提供现代 NGINX Gateway Fabric（使用 Gateway API）或成熟的 HAProxy Ingress 控制器供您选择。
- 气隙环境就绪： 与 Harbor Registry 集成，可在私有断开连接的环境中存储和提供代理和应用映像。
- 复杂的流量拆分： 为现代应用交付启用高级流量分配策略。
架构原则
- 双层负载均衡模式： 此架构将 GDC 的内置 L4 负载平衡器（作为入口点）与部署在 Kubernetes 中的客户管理的 L7 网关相结合。
- 面向角色的分离： 它遵循一种设计，通过特定资源（例如
GatewayClass、Gateway和HTTPRoute或Ingress）将基础架构提供商、集群运营商和开发者之间的职责分开。 - 过渡到现代标准： 该架构优先使用 Gateway API 来实现现代路由功能，同时在需要特定控制器的稳定性时，仍支持旧版 Ingress API。
- 客户管理的灵活性： 通过部署自行管理的控制器，客户可以控制 GDC 管理的 L4 均衡器本身未提供的 L7 功能和配置。
- 工作负载位置的抽象： 该架构通过 Kubernetes Service 抽象（标准或无头）一致地处理容器化工作负载和基于虚拟机的工作负载。
概念架构
逻辑架构
逻辑架构由多个功能组件协同工作，将外部流量路由到内部或外部后端：
- Ingress/网关入口点： 客户端 启动 HTTPS 请求，这些请求首先到达 GDC L4 负载平衡器。此内置均衡器充当入口点，并将 TCP/443 流量分配给 L7 负载平衡器。
- 控制平面： Ingress 或网关控制器（HAProxy 或 NGINX 运算符）监控 Kubernetes 资源，例如
Ingress、Gateway和HTTPRoute - 数据平面： 控制器根据观察到的资源动态更新底层代理，这些代理根据基于 SNI 的主机路由规则和 TLS 终止执行实际的流量路由。
- 后端服务：
- 容器化 Pod： 作为标准部署进行管理，并使用常规 Kubernetes Service 公开。
- 外部虚拟机： 通过无头 Kubernetes Service 和包含虚拟机直接 IP 的自定义端点（或
EndpointSlice）集成到集群中
- 工件管理： 所有代理和应用映像都从本地 Harbor Registry 提供，以确保在气隙环境中的功能
核心概念和技术
该架构使用双层负载均衡模式，将 GDC 的内置 L4 负载平衡器与部署在 Kubernetes 中的客户管理的 L7 网关相结合。关键组件包括：
- 客户端： 启动 HTTPS 请求以与应用互动的实体。
- GDC 标准集群： GDC 提供了一种内置方式来创建 Kubernetes Vanilla 集群。在此解决方案中，集群将托管 L7 LB 及其控制器，以及外部虚拟机的工作负载和无头服务
- GDC L4 负载平衡器： 内置 L4 负载平衡器充当入口点，将 TCP/443 流量直接分配给运行 Ingress 或网关控制器的 Kubernetes Pod。
- Ingress 和网关控制器： 在标准集群中运行的 HAProxy 或 NGINX 运算符。对于 Nginx，它们会监控 Gateway API 资源（例如
Gateway和HTTPRoute），并动态更新底层代理。 对于 HAProxy，它们会监控Ingress资源并动态更新底层代理。- HAProxy Ingress 控制器：适用于 Kubernetes 的 Ingress 控制器，它使用 HAProxy 作为反向 代理和第 7 层负载均衡器，同时处理 TLS 终结。
- Nginx Gateway Fabric： 使用 NGINX 作为数据平面的 Gateway API 实现。
- Ingress 和网关（使用 HTTPRoute）： 标准化的 Kubernetes 资源，用于定义物理监听端口 (443) 和基于 SNI 的主机路由规则以及 TLS 终止。
- 容器化工作负载 (Pod)： 使用常规 Kubernetes
Service在内部公开的标准 Kubernetes 部署。 - 基于虚拟机的工作负载（外部）： 托管在项目网络中的外部虚拟机上的工作负载，通过无头 Kubernetes
Service和包含虚拟机直接 IP 的自定义端点公开给代理。 - Harbor Registry： 一个私有容器注册表，用于在气隙环境中存储和提供代理和应用映像。
Ingress 与 Gateway API
Kubernetes 网络环境正在从旧版 Ingress API 过渡到现代 Gateway API。了解这两者之间的差异对于为工作负载选择合适的架构至关重要。
Ingress API： 从历史上看，Ingress 一直是管理对 HTTP 服务的外部访问的标准。它提供基于主机和基于路径的路由，但其设计相对简单，并且在不依赖于供应商特定注解的情况下，缺乏对高级流量管理（例如，基于标头的匹配或流量加权）的内置支持。 重要的是，Ingress API 现在被 功能冻结 由 Kubernetes 社区 (Ingress 限制 和 Kubernetes 网络的发展) 视为。
Gateway API： Gateway API 通常被称为 Ingress 的 V2，是一组自定义资源定义 (CRD)，可为服务网络提供更强大且可扩展的模型。它旨在 面向角色，将基础架构 提供商 (
GatewayClass)、集群运营商 (Gateway) 和开发者 (HTTPRoute/TLSRoute) 之间的职责分开（GKE 中的 Gateway API）。 这种分离可以实现更精细的控制和更好的多租户支持。
在此 GDC 网闸隔离配置解决方案中，我们特意为两个特色控制器选择了不同的 API：
- NGINX (Gateway API)： 对于 NGINX 实现，我们使用 NGINX
Gateway Fabric ，它是 Gateway
API 的成熟内置实现。通过利用 Gateway API for NGINX，客户可以受益于 API 中内置的现代标准和高级路由功能（例如
HTTPRoute）。 - HAProxy (Ingress API)： 虽然 Gateway API 是战略方向，但我们在本指南中为 HAProxy 选择的是 Ingress API 。 这是因为 HAProxy 的 Gateway API 集成被认为 不够成熟。通过使用成熟的 HAProxy Ingress 控制器，我们确保为偏好 HAProxy 的客户提供稳定可靠的 L7 解决方案，同时仍提供通往现代 L7 功能的路径。
前提和限制
前提
- 基础架构就绪： 部署假定 GDC 气隙环境 1.15.x 标准集群可用。
- 本地注册表： 假定本地 Harbor Registry 已正确配置，可在气隙环境中存储和提供代理和应用映像。
- 原生入口点： 假定流量首先到达内置 GDC L4 负载平衡器，然后该均衡器将流量分配给 L7 代理。
限制
- 客户管理的解决方案： GDC 中没有受 SLA 支持的托管 L7 服务；此实现完全由客户自行管理。
- 仅限标准集群： 由于部署 Ingress 和网关控制器需要较高的权限，因此共享用户集群不在范围内。
- API 成熟度： 虽然 NGINX 使用现代 Gateway API，但 HAProxy 仅限于 Ingress API，因为其 Gateway API 集成尚未被视为成熟。
- 气隙维护： 所有容器映像都必须在本地 Harbor 注册表中手动提升和管理。
- 社区版： 该架构专为 Nginx 和 HAProxy 的开源社区版而设计。企业版可能适用，但尚未经过明确测试。
- 运营所有权：客户必须自行管理第三方控制器的伸缩、高可用性和补丁。
- 支持范围： Google 支持仅涵盖底层 GDC 基础架构；HAProxy 或 NGINX 软件本身的问题由客户或供应商负责。
- API 过时： Kubernetes 社区冻结了 Ingress API（用于 HAProxy），这可能会限制未来的路由功能。
许可
- 社区版： 该架构专为开源社区版（通常为 Apache 2.0 或类似版本）而设计，这些版本可免费使用，但由客户管理。
- 企业采购： 商业许可（例如 NGINX Plus 或 HAProxy Enterprise）的采购和管理完全由客户负责。