Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

适用于应用负载均衡器的 GKE Ingress

Autopilot Standard

本页面简要介绍了适用于应用负载平衡器的 Google Kubernetes Engine (GKE) Ingress，并说明了 Ingress 控制器如何预配应用负载平衡器，以将应用公开给来自 VPC 网络内部或外部的 HTTP(S) 流量。

本页面是了解 GKE Ingress 功能的主要入口点。如需更详细地了解底层网络架构、流量路由模式和安全实现，请参阅关于 GKE Ingress 路由和安全。

本页面假定您了解以下内容：

本页面适用于为组织设计和架构网络以及安装、配置和支持网络设备的网络专家。如需详细了解我们在Google Cloud 内容中提及的常见角色和示例任务，请参阅常见的 GKE 用户角色和任务。

概览

GKE 提供了一个名为 GKE Ingress 的内置托管式 Ingress 控制器。当您在 GKE 中创建 Ingress 资源时，控制器会自动配置 HTTPS 负载均衡器，以允许 HTTP 或 HTTPS 流量到达您的服务。Ingress 控制器会根据 Ingress 清单和关联的 Service 对象中指定的规则，配置负载平衡器并将流量路由到集群中运行的应用。

一个 Ingress 对象与一个或多个 Service 对象相关联，而这些 Service 对象又与一组 Pod 相关联。如需详细了解 Ingress 如何使用 Service 公开应用，请参阅服务网络概览。

如需使用 Ingress，您必须启用 HTTP 负载均衡插件。GKE 集群默认启用此插件；您不得将其停用。

Kubernetes Service 与 Google Cloud 后端服务的区别

Kubernetes Service 对象和Google Cloud 后端服务对象具有相似但不同的用途。虽然它们密切相关，但这种关系并不总是一对一的。

GKE Ingress 控制器充当这两个概念之间的转换器。创建 Ingress 资源时，控制器会预配Google Cloud 负载均衡器。然后，控制器会为 Ingress 清单中引用的每个唯一 (service.name, service.port) 组合创建一个专用Google Cloud 后端服务。

例如，一个 Ingress 清单可能具有相同的 Kubernetes 服务名称，但对于两个单独的 host 或 path 规则，它指向不同的 service.port。在这种情况下，GKE Ingress 控制器会创建两个单独的后端服务。因此，一个 Kubernetes Service 对象可能与多个 Google Cloud 后端服务相关。

适用于外部和内部流量的 Ingress

GKE Ingress 资源有两种类型：

适用于外部应用负载平衡器的 Ingress 会部署传统应用负载平衡器。作为可扩缩的代管式负载均衡资源池，这种面向互联网的负载均衡器在全球范围内部署到整个 Google 边缘网络。了解如何设置和使用适用于外部应用负载平衡器的 Ingress。
适用于内部应用负载平衡器的 Ingress 会部署内部应用负载平衡器。这些内部应用负载均衡器由在您的 GKE 集群外部但在您的 VPC 网络内的 Envoy 代理系统提供支持。了解如何设置和使用适用于内部应用负载平衡器的 Ingress。

外部应用负载平衡器所需的网络环境

外部应用负载平衡器是一种托管的全球分布式系统，使用部署在 Google 边缘网络中的 Google Front End (GFE) 代理。这些代理不位于您的 VPC 网络中。当客户端向负载均衡器的外部 IP 地址发送请求时，请求会通过 Google 的任播网络路由到最近的 GFE。GFE 会终止用户流量（包括 TLS，如果已配置），然后将流量转发到 GKE 集群中的后端 Pod。

为了使此流程正常运行，GKE Ingress 控制器会自动创建防火墙规则，以允许来自 GFE 和Google Cloud健康检查系统的流量到达您的 Pod。这些规则允许来自 Google 已知 IP 地址范围（130.211.0.0/22 和 35.191.0.0/16）的流量。

外部应用负载平衡器的工作原理如下：

客户端向负载均衡器的转发规则的 IP 地址和端口发送请求。
请求会路由到 Google 全球网络中的 Google Front End (GFE) 代理。此代理会终止客户端的网络连接。
GFE 代理会将请求转发到 GKE 集群中相应的后端 Pod 端点（具体取决于负载均衡器的网址映射和后端服务）。

与内部应用负载平衡器不同，外部应用负载平衡器不需要在 VPC 网络中配置代理专用子网。

内部应用负载均衡器所需的网络环境

内部应用负载均衡器为您的网络提供了一个代理池。代理会根据网址映射、BackendService 的会话亲和性以及每个后端 NEG 的平衡模式等因素，评估每个 HTTP(S) 请求的去向。

一个区域的内部应用负载均衡器使用 VPC 网络中该区域的代理专用子网为 Google Cloud创建的每个代理分配内部 IP 地址。

默认情况下，分配给负载均衡器的转发规则的 IP 地址来自 GKE 分配的节点的子网范围，而不是来自代理专用子网。您还可以在创建转发规则时为转发规则手动指定来自任何子网的 IP 地址。

下图提供了上一段描述的内部应用负载均衡器的流量概览。

内部应用负载均衡器的工作原理如下：

客户端连接到负载均衡器的转发规则的 IP 地址和端口。
代理接收并终止客户端的网络连接。
代理建立与 NEG 中相应端点 (pod) 的连接（由负载均衡器的网址映射和后端服务确定）。

每个代理监听由相应负载平衡器的转发规则指定的 IP 地址和端口。从代理发送到端点的每个数据包的来源 IP 地址是从代理专用子网分配给该代理的内部 IP 地址。

GKE Ingress 控制器行为

GKE Ingress 控制器是否处理 Ingress 取决于 kubernetes.io/ingress.class 注解的值：

`kubernetes.io/ingress.class` 值	`ingressClassName` 值	GKE Ingress 控制器行为
未设置	未设置	处理 Ingress 清单并创建外部应用负载均衡器。
未设置	任意值	不执行任何操作。如果部署了第三方 Ingress 控制器，它可以处理 Ingress 清单。
`gce`	任意值。此字段会被忽略。	处理 Ingress 清单并创建外部应用负载均衡器。
`gce-internal`	任意值。此字段会被忽略。	处理 Ingress 清单并创建内部应用负载均衡器。
设置为 `gce` 和 `gce-internal` 以外的值	任意值	不执行任何操作。如果部署了第三方 Ingress 控制器，它可以处理 Ingress 清单。

`kubernetes.io/ingress.class` 注解弃用

虽然 kubernetes.io/ingress.class 注解在 Kubernetes 中已弃用，但 GKE 会继续使用此注解。您必须使用此注解来标识 Ingress 类。

应用配置时，您可能会遇到弃用警告。此警告指出相应注解已被弃用，并指示您改用 ingressClassName 字段。您可以放心地忽略此警告，因为 GKE Ingress 会继续完全依赖 kubernetes.io/ingress.class 注解。

Ingress 与 Compute Engine 资源的映射

GKE Ingress 控制器会根据集群中部署的 Ingress 资源来部署和管理 Compute Engine 负载均衡器资源。Compute Engine 资源的映射取决于 Ingress 资源的结构。

以下清单描述了一个 Ingress：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

此 Ingress 清单指示 GKE 创建以下 Compute Engine 资源：

转发规则和 IP 地址。
允许针对负载均衡器健康检查的流量和来自 Google Front End 或 Envoy 代理的应用流量的 Compute Engine 防火墙规则。
目标 HTTP 代理和目标 HTTPS 代理（如果您配置了 TLS）。
具有一个引用单个路径匹配器的路径规则的网址映射。该路径匹配器有两个路径规则，一个针对 /*，另一个针对 /discounted。每个路径规则均映射到一个唯一的后端服务。
包含作为端点的每个 Service 的 Pod IP 地址列表的 NEG。这些 NEG 是基于 my-discounted-products 和 my-products Service 创建的。

负载均衡方法

GKE 支持容器原生负载均衡和实例组。

容器原生负载均衡

容器原生负载均衡是指直接将负载均衡到 GKE 中的 Pod 端点。容器原生负载均衡使用类型为 GCE_VM_IP_PORT 的网络端点组 (NEG)，其中端点是 Pod 的 IP 地址。

容器原生负载均衡始终用于内部 GKE Ingress，并且对于外部 Ingress 是可选的。Ingress 控制器会创建负载均衡器，包括虚拟 IP 地址、转发规则、健康检查和防火墙规则。

容器原生负载均衡支持基于 Pod 的会话亲和性。

当满足下述所有条件时，GKE 会自动启用容器原生负载均衡：

集群是 VPC 原生集群。
集群不使用共享 VPC 网络。
集群不使用 GKE 网络政策。
集群已启用 HttpLoadBalancing 插件。 GKE 集群默认启用了 HttpLoadBalancing 插件：您不得将其停用。

当 GKE 启用容器原生负载均衡时，系统会自动为服务添加 cloud.google.com/neg: '{"ingress": true}' 注释。此注解会触发创建镜像 Pod IP 的 NEG，从而让 Compute Engine 负载平衡器直接与 Pod 通信。

对于 NEG 不是默认设置的集群，我们强烈建议使用容器原生负载均衡，但必须按 Service 明确启用。

为了提高灵活性，您还可以创建独立的 NEG。在这种情况下，您负责创建和管理负载均衡器的所有方面。

优势

通过使用 NEG，容器原生负载均衡可提供性能更高、更稳定的网络：

提升了网络性能：如果没有容器原生负载均衡，流量将传输到节点实例组，然后依赖于 kube-proxy 配置的 iptables 规则路由到目标 Pod。借助容器原生负载均衡，流量会直接负载均衡到 Pod，无需通过虚拟机 IP 和节点上的 kube-proxy 网络进行路由。此流程可消除额外的网络跃点，并缩短延迟时间、提高吞吐量。

增强型健康检查：系统会实现 Pod 就绪性门控，以便从负载均衡器的角度确定 Pod 的运行状况，而不是仅仅依赖于集群内运行状况探测。借助此关键功能，负载均衡器可以感知 Pod 生命周期事件（启动、丢失等），从而提高流量稳定性。如需详细了解如何使用 Pod 就绪性门控来确定 Pod 健康状况，请参阅 Pod 就绪性。

提高可见性：利用容器原生负载均衡，您可以了解从应用负载平衡器直接到每个 Pod 的延迟时间。由于延迟不再在节点 IP 级层进行汇总，因此可以更轻松地在 NEG 级层排查服务问题。

支持 Cloud Service Mesh：使用 Cloud Service Mesh（ Google Cloud专为服务网格打造的全代管式式流量控制平面）需要 NEG 数据模型。

容器原生负载平衡器的限制

GKE 上通过 Ingress 实现的容器原生负载均衡器具有以下限制：

容器原生负载平衡器不支持外部直通式网络负载平衡器。
您不得手动更改或更新 GKE 创建的应用负载均衡器的配置。您所做的任何更改都会被 GKE 覆盖。

容器原生负载均衡器的价格

您需要为在本指南中创建的 Ingress 预配的应用负载均衡器付费。如需了解负载均衡器的价格，请参阅 Cloud Load Balancing 价格页面上的负载均衡和转发规则。

实例组

使用实例组时，Compute Engine 负载均衡器会将流量发送到作为后端的虚拟机 IP 地址。在虚拟机上运行共用同一个主机接口的容器时，存在以下限制：

这会产生负载均衡的两个跃点：一个跃点是从负载均衡器到虚拟机 NodePort，另一个跃点是通过 kube-proxy 路由到 Pod IP 地址（可能位于其他虚拟机）。
额外的跃点会增加延迟时间，并使流量路径更加复杂。
Compute Engine 负载均衡器无法直接查看 Pod，导致流量平衡不理想。
虚拟机或 Pod 丢失等环境事件更有可能因双流量跃点而导致流量间歇性丢失。

外部 Ingress 和基于路由的集群

如果您将基于路由的集群与外部 Ingress 搭配使用，则 GKE Ingress 控制器无法使用 GCE_VM_IP_PORT 网络端点组 (NEG) 实现容器原生负载均衡。Ingress 控制器使用非代管式实例组后端，其中包含所有节点池中的所有节点。如果 LoadBalancer Service 也使用这些非代管式实例组，则可能会导致与单个负载均衡实例组限制相关的问题。

在 VPC 原生集群中创建的一些较早的外部 Ingress 对象可能会在其创建的每个外部应用负载均衡器的后端服务上使用实例组后端。这与内部 Ingress 无关，因为内部 Ingress 资源始终使用 GCE_VM_IP_PORT NEG 并且需要 VPC 原生集群。

如需了解如何使用排查外部 Ingress 的 502 错误，请参阅外部 Ingress 生成 HTTP 502 错误。

GKE Ingress 控制器的限制

GKE Ingress 不支持由 Certificate Manager 管理的证书。如需使用由 Certificate Manager 管理的证书，请使用 Gateway API。
使用 NEG 的集群中，Ingress 对账时间可能会受到 Ingress 数量的影响。例如，具有 20 个 Ingress 的集群（每个集群包含 20 个不同的 NEG 后端）可能导致超过 30 分钟的延迟时间，以便协调 Ingress 更改。由于所需的 NEG 数量增加，会对区域性集群产生特别影响。
网址映射配额适用。
适用 Compute Engine 资源配额。
如果您没有将 NEG 与 GKE Ingress 控制器搭配使用，则 GKE 集群最多只能有 1,000 个节点。使用 NEG 部署服务时，GKE 节点数量没有限制。通过 Ingress 公开的任何非 NEG Service 都无法在超过 1,000 个节点的集群上正常运行。
如需使 GKE Ingress 控制器使用 readinessProbes 作为健康检查，在创建 Ingress 时必须存在 Ingress 的 Pod。如果您的副本调节至 0，则系统会应用默认的健康检查。如需了解详情，请参阅此关于健康检查的 GitHub 问题评论。
在 Ingress 创建完成后，更改 Pod 的 readinessProbe 不会对其造成影响。
外部应用负载均衡器可在全球各处的地理位置终止 TLS，从而最大程度减少客户端与负载均衡器之间的延迟时间。如果您需要控制 TLS 终止的地理位置，应改用通过类型为 LoadBalancer 的 GKE Service 公开的自定义 Ingress 控制器，并终止位于所需地区的后端上的 TLS。
不支持将多个 Ingress 资源合并到单个 Google Cloud 负载均衡器中。
您必须为您的应用停用双向 TLS，因为它不支持外部应用负载均衡器。
Ingress 只能为其前端公开 HTTP 端口 80 和 443。