此参考架构在 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 或 Gateway 控制器（HAProxy 或 NGINX 运算符）监控 Kubernetes 资源，例如
Ingress、Gateway和HTTPRoute - 数据平面：根据观察到的资源，控制器会动态更新底层代理，这些代理会根据基于 SNI 的主机路由规则和 TLS 终结执行实际流量路由。
- 后端服务：
- 容器化 Pod：作为标准 Deployment 进行管理，并通过常规 Kubernetes Service 公开。
- 外部虚拟机：通过无头 Kubernetes Service 和包含虚拟机直接 IP 的自定义端点（或
EndpointSlice）集成到集群中
- 制品管理：代理和应用的所有映像都通过本地 Harbor Registry 提供，以确保在经过网闸隔离的环境中正常运行
核心概念和技术
该架构采用两层负载均衡模式，将 GDC 的内置 L4 负载均衡器与部署在 Kubernetes 中的客户管理 L7 网关相结合。关键组件包括：
- 客户端：发起 HTTPS 请求以与应用交互的实体。
- GDC 标准集群：GDC 提供了一种内置方式来创建 Kubernetes Vanilla 集群。在此解决方案中，集群将托管 L7 负载均衡器及其控制器，以及外部虚拟机的工作负载和无头服务
- GDC L4 负载均衡器：内置 L4 负载均衡器，用作入口点，将 TCP/443 流量直接分发到运行 Ingress 或 Gateway 控制器的 Kubernetes Pod。
- Ingress 和 Gateway 控制器：在标准集群中运行的 HAProxy 或 NGINX 运算符。对于 Nginx，它们会监控 Gateway API 资源（例如
Gateway和HTTPRoute），并动态更新底层代理。对于 HAProxy，它们会监控Ingress资源并动态更新底层代理。- HAProxy Ingress 控制器：一种适用于 Kubernetes 的 Ingress 控制器，它利用 HAProxy 作为反向代理和第 7 层负载均衡器，同时还处理 TLS 终结。
- Nginx Gateway Fabric：使用 NGINX 作为数据平面的 Gateway API 实现。
- Ingress 和 Gateway（使用 HTTPRoute）：标准化的 Kubernetes 资源，用于定义物理监听端口 (443) 以及基于 SNI 的主机路由规则（采用 TLS 终结）。
- 容器化工作负载 (Pod)：使用常规 Kubernetes
Service在内部公开的标准 Kubernetes Deployment。 - 基于虚拟机的工作负载（外部）：托管在项目网络上的外部虚拟机上的工作负载，通过无头 Kubernetes
Service和包含虚拟机直接 IP 的自定义端点向代理公开。 - Harbor Registry：一个私有 Container Registry，用于在经过网闸隔离的环境中存储和提供代理和应用映像。
Ingress API 与 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 注册表已正确配置，可在经过网闸隔离的环境中存储和提供代理和应用映像。
- 原生入口点：假设流量首先到达内置的 GDC L4 负载均衡器，然后由该负载均衡器将流量分配到 L7 代理。
限制条件
- 客户管理的解决方案：GDC 中没有受管理且有 SLA 支持的 L7 服务；此实现完全由客户自行管理。
- 仅限标准集群：共享用户集群不在范围内，因为 Ingress 和 Gateway Controller 部署需要高权限。
- API 成熟度：虽然 NGINX 使用现代 Gateway API，但 HAProxy 仅限于 Ingress API，因为其 Gateway API 集成尚未被视为成熟。
- 经过网闸隔离的维护：所有容器映像都必须在本地 Harbor 注册表中手动升级和管理。
- 社区版：该架构专为 Nginx 和 HAProxy 的开源社区版而设计。企业版可能可以运行，但尚未经过明确测试。
- 运营所有权：客户必须自行管理第三方控制器的伸缩、高可用性和修补。
- 支持范围：Google 支持仅涵盖底层 GDC 基础设施；HAProxy 或 NGINX 软件本身的问题由客户或供应商负责。
- API 废弃：Ingress API（用于 HAProxy）已被 Kubernetes 社区冻结功能，这可能会限制未来的路由功能。
许可
- 社区版：该架构专为开源社区版（通常为 Apache 2.0 或类似版本）而设计，这些版本可免费使用，但由客户管理。
- 企业采购：商业许可（例如 NGINX Plus 或 HAProxy Enterprise）的采购和管理由客户自行负责。