从边缘到网格：通过 GKE Gateway 公开服务网格应用

Last reviewed 2026-05-28 UTC

本参考架构介绍了如何将 Cloud Service Mesh 与 Cloud Load Balancing 结合使用，以将服务网格中的应用公开给互联网客户端。

Cloud Service Mesh 是基于 Istio 的代管式服务网格，可为应用提供可观测的标准化安全增强型通信层。服务网格为在网格中进行通信的客户端提供了全面的通信平台。但是，仍然难以将网格外部的客户端连接到网格内托管的应用。

您可以通过多种方式向客户端公开应用，具体取决于客户端所在的位置。此参考架构适用于运行 Cloud Service Mesh 的高级从业人员，但也适用于 Google Kubernetes Engine (GKE) 上的 Istio。

网格入站流量网关

Istio 0.8 引入了网格入站流量网关。网关提供了一组专用代理，其端口会向来自服务网格外部的流量公开。这些网格入站流量代理可让您独立于应用路由行为来控制网络公开行为。

通过代理，您还可以在网格外部流量到达应用 Sidecar 之前将路由和政策应用于网格外部流量。网格入站流量定义了流量到达网格中的节点时的处理方式，但是外部组件必须定义流量如何首先到达网格。

如需管理此外部流量，您需要一个位于网格外部的负载均衡器。此参考架构使用通过 GKE Gateway 资源预配的 Google Cloud Load Balancing 自动执行部署。

对于 Google Cloud，此设置的 规范示例 是部署公共 网络负载均衡器 (L4) 的外部负载均衡服务。该负载均衡器指向 GKE 集群的 NodePort。这些 NodePort 会公开 Istio 入站流量网关 Pod，而 Pod 会将流量路由到下游网格边车代理。

架构

下图演示了此拓扑。内部专用流量的负载均衡类似于此架构，只是改为部署内部直通网络负载均衡器。

外部负载均衡器通过入站流量网关代理将外部客户端路由到网格。

上图显示将 L4 透明负载均衡与网格入站流量网关结合使用具有以下优势：

  • 该设置简化了负载均衡器的部署过程。
  • 如果集群变更、节点中断或处理中断，则负载均衡器会提供稳定的虚拟 IP 地址 (VIP)、健康检查和可靠的流量分配。
  • 所有路由规则、TLS 终结和流量政策都会在网格入站流量网关中的同一个位置处理。

GKE Gateway 和 Service

您可以通过多种方式为集群外部的客户端提供对应用的访问权限。GKE Gateway 是 Kubernetes Gateway API 的实现。GKE Gateway 会优化 Ingress 资源并对其进行改进。

将 GKE Gateway 资源部署到 GKE 集群时，Gateway 控制器会监控 Gateway API 资源，并协调 Cloud Load Balancing 资源，以实现 GKE Gateway 资源指定的网络行为。

使用 GKE Gateway 时，用于向客户端公开应用的负载均衡器的类型很大程度上取决于以下因素：

  • 客户端的状态（外部或内部）。
  • 所需的负载均衡器功能，包括与 Google Cloud Armor 安全政策集成的功能。
  • 服务网格的跨度要求。服务网格可以跨越 多个 GKE 集群，也可以包含在单个集群中。

在 GKE Gateway 中，此行为通过指定适当的 GatewayClass 来控制。

虽然 Cloud Service Mesh 的默认负载均衡器是网络负载均衡器，但此参考架构重点介绍外部应用负载均衡器 (L7)。外部应用负载均衡器提供与 Identity-Aware Proxy 和 Google Cloud Armor 等边缘服务、网址重定向和重写以及边缘代理的全球分布式网络的集成。下一部分介绍使用两层 HTTP 负载均衡的架构和优势。

Cloud 入站流量和网格入站流量

将网格外部的 L7 负载均衡与网格入站层一起部署具有明显优势，对于互联网流量而言尤其如此。即使 Cloud Service Mesh 和 Istio 入站流量网关在网格中提供了高级路由和流量管理，某些功能仍可以在网络边缘得到更好的服务。通过 Google Cloud的外部应用负载平衡器利用互联网边缘网络，较之基于网格的入站流量，可在性能、可靠性或安全性方面获得 显著的优势。这些优势如下所示：

此 L7 负载均衡的外部层称为 Cloud 入站流量，因为它是以云管理的负载平衡器为基础，而不是由网格入站流量使用的自托管代理。 Cloud 入站流量和网格 入站流量结合，可使用 Google Cloud 基础架构 和网格的互补功能。下图说明了如何将 Cloud 入站流量（通过 GKE Gateway）和网格入站流量结合使用，以充当互联网流量的两个负载均衡层。

Cloud Ingress 充当通过 VPC 网络到网格的外部流量的网关。

在上图的拓扑中，Cloud 入站流量层从服务网格外部获取流量，并将该流量定向到网格入站流量层。然后，网格入站流量层会将流量定向到网格托管的应用后端。

Cloud 和网格入站流量拓扑

本部分介绍了每个入站流量层一起使用时可实现的互补性角色。这些角色不是具体的规则，而是利用每一层优点的指导原则。这种模式可能会有变体版本，具体取决于您的使用场景。

  • Cloud Ingress：与网格 Ingress 搭配使用时，Cloud Ingress 层最适合用于边缘安全和全球负载均衡。由于 Cloud Ingress 层在边缘与 DDoS 保护、云防火墙、身份验证和加密产品集成在一起，因此这个层擅长在网格外部运行这些服务。路由逻辑在这个层通常很简单，但是对于多集群和多区域环境而言，逻辑可能会更复杂。由于面向互联网的负载均衡器的关键功能，Cloud Ingress 层可能由基础架构团队管理，该团队对应用在互联网上的公开和保护方式具有独占控制权。较之开发者驱动的基础架构，此控制机制会降低此层的灵活性和动态性，因此如果考虑使用此控制机制，则可能会影响您要向谁提供对此层的管理员权限以及以何种方式提供。
  • 网格 Ingress：与 Cloud Ingress 搭配使用时，网格 Ingress 层提供靠近应用的灵活路由。由于具有这种灵活性，对于复杂路由逻辑和应用级别的可见性，网格入站流量比 Cloud Ingress 更好。入站流量层之间的分隔还使应用所有者能更容易地直接控制此层，而不会影响其他团队。为了在通过 L4 负载均衡器而不是 L7 负载均衡器公开服务网格应用时帮助保护应用，您应在网格内部的网格入站流量层终结客户端 TLS。

运行状况检查

使用 L7 负载均衡的两层所带来的一种复杂性是健康检查。您必须配置每个负载均衡器以检查下一层的运行状况，确保它可以接收流量。下图中的拓扑结构显示了 Cloud Ingress 如何检查网格入站流量代理的运行状况，而网格又如何反过来检查应用后端的运行状况。

Cloud Ingress 会检查网格入站流量的运行状况，网格入站流量会检查应用后端的运行状况。

上述拓扑有以下注意事项：

  • Cloud 入站流量：在此参考架构中，通过 Gateway 配置 Google Cloud 负载均衡器，以检查 网格入站流量代理在所公开健康检查端口上的健康状况。如果网格代理 关闭，或者集群、网格或 区域不可用，则 Google Cloud 负载均衡器会检测到此情况，并且不会将流量发送到网格 代理。
  • 网格入站流量 ：在网格应用中，您可以直接对后端执行健康检查，以便可以在本地执行负载均衡和流量管理。

安全

上述拓扑还涉及多个安全要素。最关键的要素之一是如何配置加密和部署证书。GKE 网关集成了 Google 管理的证书。 您可以参阅 Gateway 定义中的 Certificate Manager CertificateMap。互联网客户端对公共证书进行身份验证，并作为 Virtual Private Cloud (VPC) 中的第一个跃点连接到外部负载均衡器。

Google Front End (GFE) 和网格入站流量代理之间的下一个跃点会默认加密。GFE 与其后端之间的网络级加密会自动应用。但是，如果您的安全要求规定平台所有者保留加密密钥的所有权，则可以选择在集群网关 (GFE) 和网格入站流量（Envoy 代理实例）之间启用具有 TLS 加密的 HTTP/2。为此路径启用具有 TLS 加密的 HTTP/2 后， 您可以使用自签名证书或公共证书来加密流量，因为 GFE 不会对其进行身份验证 。相关 部署指南中演示了此额外的加密层 。为防止证书被错误处理，请勿在其他地方使用公共负载均衡器的公共证书。相反，我们建议您在服务网格中使用单独的证书。 如果您想将 HTTP/2 用于 GFE 到网格的连接，但不需要自己的 加密，则可以使用 H2C。

如果服务网格强制执行 TLS，则将对 Sidecar 代理之间的所有流量以及网格入站流量进行加密。下图说明了从客户端到 Google Cloud 负载均衡器、从负载 均衡器到网格入站流量代理以及从入站流量代理到 Sidecar 代理的 HTTPS 加密。

在网格外部使用代管式证书实现安全，而在网格内部使用内部证书实现安全。

费用优化

在本文档中，您将使用 Google Cloud 的以下收费组件：

Deployment

如需部署此架构，请参阅从边缘到网格：通过 GKE Gateway 部署服务网格应用。

后续步骤