设计基于 Google Kubernetes 引擎 (GKE) 运行的企业应用程序的一个关键部分是考虑其客户端将如何访问您的应用程序。这可能只是简单地对集群外公开应用程序，以供其他内部客户端使用，也可能涉及来自全球公开客户端的流量路由至您的应用程序。

您应当怎么做取决于很多因素。客户端是来自互联网还是来自内部网络？应用程序使用哪些网络协议？应用程序是托管在单一区域或者集群中，还是全球化部署？确定使用哪个解决方案来公开您的应用程序需要在一些关键方面考虑您的应用程序需求。不应当孤立地对这些需求进行评估 —— 而应当全面审视它们，从而确定最适合的网络解决方案来公开您的应用程序。

我们将全面介绍在 GKE 中公开应用程序时应当考虑的不同因素，详解这些因素会如何影响应用程序公开，并且重点阐述针对不同的需求将使用哪个最适合的网络解决方案。假设您已经熟悉 Kubernetes 的相关概念（例如，Deployment、Service 和 Ingress 资源），我们将区分不同的公开方法 —— 从内部、外部到多集群等。

了解应用程序的公开

向外部客户端公开应用程序涉及三个关键要素，这些要素共同作用，使得流量路由到您的应用程序：

前端：负载均衡器前端定义了作用域，在作用域中，客户端可以访问并向负载均衡器发送流量。这是监听流量的网络位置 —— 一个网络，网络中的一个特定区域或子网、网络中的一个或多个 IP、端口、特定协议以及为建立安全连接所提供的 TLS 证书。
路由和负载均衡：路由和负载均衡定义流量被处理和被路由的方式。可基于参数（例如，协议、HTTP 消息头和 HTTP 路径）将流量路由至服务。根据您所使用的负载均衡器，可跨多个可用区或者区域对流量进行均衡，从而为您的客户提供更低的延迟和更高的弹性。
后端：可以通过端点类型、应用程序平台以及后端服务发现集成的方式来定义后端。特定应用程序环境（例如，GKE ）依靠服务发现集成的辅助，随着 GKE 端点的健康状况动态更新负载均衡器后端。

下图针对两种不同类型的流量（外部和内部流量）说明了这些概念。外部 HTTP 负载均衡器通过遍及世界各地的数百个 Google 接入点 (PoP) 监听公共互联网中的流量。在对流量进行负载均衡以发送至 Google 数据中心中的后端之前，这个全球性的前端允许在靠近客户端的边缘终止流量。此处所介绍的内部 HTTP 负载均衡器会在您的 VPC 网络范围内进行监听，允许在内部进行私有通信。这些不同的负载均衡器特性使它们适用于不同的应用程序用例。

通过 Ingress 和 Service 控制器实现 GKE 负载均衡

要在 GKE 集群外部公开应用程序，GKE 提供了内置的 GKE Ingress 控制器和 GKE Service 控制器，这两个控制器可帮助GKE 用户部署 Google Cloud 负载均衡器 (GCLB)。这使用的是和虚拟机相同的负载均衡基础架构，所不同的是，其生命周期是完全自动化的，并由 GKE 控制。GKE 网络控制器通过固有的、符合 Ingress 和 Service API 标准的高级接口，提供了容器原生 Pod IP 负载均衡。

下图显示了 GKE 网络控制器如何自动创建负载均衡器：一位基础架构或应用程序的管理员针对其 GKE 集群部署一份声明式清单。Ingress 和 Service 控制器会对 GKE 联网资源（例如，Ingress 或者 MultiClusterIngress 对象）进行监控，并且基于清单部署 Cloud 负载均衡器（以及 IP 寻址、防火墙规则等）。控制器基于环境和流量变化对负载均衡器和后端进行持续管理。因此，GKE 负载均衡成为了一个的动态且自维持的负载均衡器，具备了简单的面向开发人员的接口。

影响应用程序公开的因素

有许多因素将影响您在 GKE 中公开应用程序的方法的选择。有一些核心因素是您决策树的“根基”所在，并且将有助于缩小网络解决方案的范围。这些因素包括客户端网络、协议和应用程序区域性。

客户端网络指的是客户端可访问应用程序的网络。这会影响您的负载均衡器前端应当进行监听的位置。例如，客户端可能位于与应用程序相同的 GKE 集群中。在这种情况下，它们会从集群网络中访问您的应用程序，允许它们使用 Kubernetes 原生的 ClusterIP 负载均衡。客户端也可能是Google Cloud内部网络客户端，从同一个VPC或者通过Google Cloud Interconnect 连接的私有数据中心的客户端访问您的应用程序。客户端也可能是外部的，从公共互联网访问您的应用程序。不同类型的网络决定了不同的负载均衡拓扑。

协议是您的客户端与应用程序“沟通”的语言。语音、游戏和低延迟应用程序通常直接基于 TCP 或者 UDP 协议进行通信，需要有 L4 粒度控制的负载均衡器。其他应用程序使用 HTTP、HTTPS、gRPC 或者HTTP2 进行通信，并且需要确切支持这些协议的负载均衡器。协议需求进一步定义了哪类应用程序公开方法是最适合的。

应用程序区域性指您的应用程序跨一个以上 GCP 区域或 GKE 集群分布的程度。托管单一实例的应用程序，和托管一个主从实例且跨两个独立 GKE 集群的应用程序相比，有不同的需求。托管一个跨五个 GKE 集群且跨地域分布的应用程序，则需要负载均衡器支持多集群和多区域感知的能力，以便将工作负载靠近最终用户“放置”，从而实现低延迟。

可能还有以下未涵盖的其他将影响网络设计的因素 —— 例如，延迟要求、源 IP 地址保留或者高带宽。此列表并非详尽无遗，但应当能够帮助您缩小您的解决方案选择范围，并且加深您对在不同需求之间进行权衡的理解。

通过 Ingress 和 Service 公开应用程序

幸运的是，GKE 的一整套原生Ingress 和 Service 控制器使应用程序公开无缝、安全并且默认即为生产准备就绪。这些网络控制器与 GCLB 紧密集成，允许 Kubernetes 原生接口部署GCLB，并且将流量负载均衡到容器 IP。下表对 GKE Ingress 和 Service 服务类型进行了细分并且详细介绍了其主要特点。要更详细地了解所有 GKE 和 Anthos Ingress 功能的对比，请参见 Ingress 特性

有许多原生选项，从协议、网络接入和区域角度看，所有选项均具有不同的能力。下一节按照以上所讨论的因素对这些联网解决方案进行归类。

客户端网络

GKE 中的负载均衡器可大致分为内部和外部负载均衡器。内部指 VPC 网络，这是一种不可直接从互联网访问的内部私有网络。外部指公共互联网。请注意，ClusterIP Service 是属于一个 GKE 集群的内部，因此，与 VPC 网络相比，它们限定于更小的网络。

*GKE 公共集群为每个 GKE 节点提供公共和私有 IP，因此，支持从内部和外部访问 NodePort Service。

协议

负载均衡器通常被归类为 L4 （基于端口和协议的网络信息进行路由流量），或者 L7 （能够感知客户端会话的应用程序信息）。GKE的负载均衡器也可被归类为 L4 和 L7，具体协议支持如下表所示。

应用程序区域性

GKE 负载均衡解决方案的区域性可细分为两个方面：

后端作用域（或者集群作用域）指负载均衡器是否能够跨多个 GKE 集群向后端发送流量。Ingress for Anthos（或者 Multi-cluster Ingress）能够公开为单一的 VIP，使来自不同集群和不同 Google Cloud 区域的流量直接抵达 pod 。
前端作用域指负载均衡器IP 是在单个区域内还是跨多个区域进行监听。所有外部负载均衡器均在互联网中监听，因此，本质上是多区域的，但一些内部负载均衡器仅在单一区域中监听。

下表详细列出了跨这两个维度的 GKE 负载均衡解决方案。

尽管这些并未涵盖应用程序联网的每个方面，详细了解以上每个因素有助于剖析哪个解决方案最适合您的应用程序。大部分的 GKE 环境托管许多不同类型的应用程序，所有应用程序都有独特的需求，因此，您可能会在任何特定集群中使用不止一种类型的应用程序。要了解有关它们功能的详细信息，请参考以下一些资源：

适用于 GKE 应用程序公开的其他解决方案

Kubernetes 生态系统十分庞大，上述解决方案并非是适用于公开应用程序的唯一解决方案。以下解决方案也可能是对原生GKE 负载均衡器可行的替代或补充。

集群内 Ingress

集群内 Ingress 指在 Kubernetes 集群内部托管其 Ingress代理的 Ingress 控制器。这不同于 Cloud Ingress 控制器，Cloud Ingress 控制器单独于 Kubernetes 集群，托管和管理其负载均衡基础架构。这些第三方解决方案通常由集群 Operator 自行部署和管理。istio-ingressgateway 和 nginx-ingress 是两个常用的且开源的集群内 Ingress 控制器的示例。集群内 Ingress 控制器通常遵循 kubernetes Ingress 规范，并且提供多种功能和易用性。开源解决方案可能需要更紧密的管理和更高的技术专业知识，不过，如果它们可以提供您的应用程序所需要的特定功能，可能会满足您的需求。还有一个由 Enterprise Ingress 解决方案构成的庞大的生态系统，这一生态系统以开源社区为核心构建，可提供高级的功能和企业支持。

独立的 NEG

GKE Ingress 和 Service 控制器提供部署 Google Cloud 负载均衡的自动、声明式和 Kubernetes 原生方法。还有一些以人工方式为 GKE 后端部署负载均衡器的有效用例，例如，对负载均衡器进行直接和更细粒度的控制，或者在容器和虚拟机后端之间进行负载均衡。网络端点组 (NEG) 支持动态更新 Pod 后端 IP，同时也允许通过 Google Cloud API 以人工方式部署负载均衡器的前端。这提供了对负载均衡器最大和直接的控制，同时保留了由 GKE 集群控制的动态后端。

服务网格

服务网格通过集中控制平面提供客户端负载均衡。Istio 项目为 Kubernetes 引入了 L7 服务网格以进行内部通信，服务网格生态系统在范围和能力方面已经快速扩展。Traffic Director 和 Anthos Service Mesh 增强了这种能力，跨 GKE 集群、跨区域以及在容器和 VM 之间实现内部流量的负载均衡。这模糊了内部负载均衡（东西流量）和应用程序公开（南北流量）之间的界限。凭借现代化服务网格控制平面所具有的灵活性和广度，比以往任何时候都更有可能将客户端和服务器部署到同一服务网格作用域中。对于没有自己的 Sidecar 代理的客户端，上述 GKE Ingress 和 Service 解决方案一般会部署中间代理负载均衡器。不过，如果客户端和服务器位于同一网格中，可通过网格而非中间代理负载均衡处理传统的应用程序公开。

GKE 随时为您服务

根据您的用例，Google Cloud 支持许多将 GKE 应用程序作为一个服务进行公开的不同方法。我们希望让您明确的一点是， GKE 能够提供针对您的各种容器用例最全面的支持。如果本文帮助您更好地了解了如何设计应用程序访问，请随时分享，以便您也可以帮助其他人理解。

创作场景

GKE 最佳实践：通过 Ingress 和 Service 公开 GKE 应用程序