GKE Ingress 路由和安全性简介

Autopilot Standard

本页面介绍了 GKE Ingress 的核心功能和网络架构，具体包括：保护从客户端到负载均衡器以及到应用 Pod 的连接；管理多个后端服务之间的复杂路由；以及了解如何在集群内协调负载均衡器健康状况检查。

本页面以 GKE Ingress 概览中介绍的基础概念为基础。如需查看使用 FrontendConfig 和 BackendConfig 等自定义资源的分步说明和实现示例，请参阅为 GKE 应用配置 Ingress 功能。

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

通过 HTTPS 保护入站流量

GKE Ingress 可确保客户端与应用负载均衡器之间以及负载均衡器与应用 Pod 之间的流量安全。

在客户端和负载均衡器之间配置 TLS

HTTP(S) 负载平衡器充当客户端和应用之间的代理。如果您想要接受来自客户端的 HTTPS 请求，则负载均衡器必须具有证书，这样才能向客户端证明其身份。负载均衡器还必须具有私钥才能完成 HTTPS 握手。

当负载均衡器接受来自客户端的 HTTPS 请求时，客户端与负载均衡器之间的流量使用 TLS 进行加密。但是，负载均衡器可终止 TLS 加密，并将未加密的请求转发给应用。如需了解详情，请参阅配置负载均衡器与应用之间的加密。

提供 SSL 证书的方法

您可以使用以下方法向 HTTP(S) 负载均衡器提供 SSL 证书：

由 Google 管理的证书：这些证书是 Google 为您的域名预配、续订和管理的网域验证 (DV) 证书。这些证书并不代表您的个人或组织身份。 Google 管理的证书最多支持 100 个非通配符网域。如需了解详情，请参阅使用 Google 管理的证书。
与 Google Cloud共享的自行管理证书：您可以在 Google Cloud 项目中预配自己的 SSL 证书并创建证书资源。然后，您可以在 Ingress 上的注解中列出该证书资源，以创建使用该证书的 HTTP(S) 负载均衡器。如需了解详情，请参阅使用预共享证书。
使用 Kubernetes Secret 的自行管理证书：您可以预配自己的 SSL 证书并创建一个 Secret 来保存该证书。然后，您可以在 Ingress 清单的 tls 字段中引用该 Secret，以创建 HTTP(S) 负载均衡器。如需了解详情，请参阅使用 Kubernetes Secret。

使用多个证书处理 HTTPS 流量

您可以将应用负载平衡器配置为最多向客户端提供 15 个 TLS 证书。如果您需要通过多个主机名提供内容，而每个主机名都需要不同的证书（例如，为 your-store.example 和 your-experimental-store.example 分别使用不同的证书），则必须使用多个证书。您可以在 Ingress 清单中指定这些多个证书。

证书选择和优先级

为了确定要向客户端提供哪个证书，负载均衡器使用服务器名称指示 (SNI)。

如果客户端使用 SNI，或者使用的域名与某个可用证书中的公用名 (CN) 相匹配，则负载均衡器会使用 CN 与客户端请求的主机名最匹配的证书。
如果客户端不支持 SNI，或者所请求的域名与任何可用证书的 CN 不匹配，则负载均衡器会使用 Ingress 清单中列出的第一个证书作为默认证书。负载均衡器根据以下规则选择此证书：
- 对于 tls 块中列出的 Secret：主证书是 tls 块中的第一个 Secret。
- 对于 pre-shared-cert 注解中的预共享证书：主证书是注解中列出的第一个证书。
- 对于 managed-certificates 注解中的 Google 管理的证书：所有受管理的证书均按名称的字母顺序排序。主证书是此字母顺序列表中的第一个证书。如需将特定证书设置为主证书，您必须相应地命名 ManagedCertificate 对象，以控制排序顺序。例如，如需将 my-default-cert 设为比 another-cert 更重要的主证书，您可以将它们分别命名为 0-my-default-cert 和 1-another-cert。

当负载均衡器通过不同的 GKE 方法呈现多个证书时，预共享证书优先于 Ingress tls 代码块中列出的 Secret。

下图展示了负载均衡器根据请求中使用的域名将流量发送到不同后端：

显示多个 SSL 证书使用 Ingress 系统的示意图

证书轮替最佳做法

如果要轮替 Secret 或预共享证书的内容，请遵循以下最佳实践：

使用其他名称创建包含新证书数据的新 Secret 或预共享证书。更新您的 Ingress 以使用新的证书资源。
如果您不想中断流量，则可以从 Ingress 中移除旧资源，预配名称相同但内容不同的新资源，然后将其重新关联到 Ingress。

为避免自行管理证书轮替，请使用 Google 管理的 SSL 证书。

强制仅使用 HTTPS 流量

如果您希望客户端和 HTTP(S) 负载均衡器之间的所有流量都使用 HTTPS，则可以通过在 Ingress 清单中添加 kubernetes.io/ingress.allow-http 注解并将值设置为 "false" 来停用 HTTP。如需了解详情，请参阅停用 HTTP。

配置负载均衡器与应用之间的加密

本部分介绍了如何保护从负载均衡器到应用 Pod 的连接。

启用 HTTPS 或 HTTP/2 后端协议

外部应用负载平衡器充当客户端和 GKE 应用之间的代理。虽然客户端可以使用 HTTPS（用于加密）和各种协议（HTTP/1.1 或 HTTP/2）连接到负载均衡器，但从负载均衡器到后端 Pod 的连接默认使用未加密的 HTTP/1.1。

如果您的应用能够处理更高级的配置，您可以手动更新外部应用负载平衡器，以使用：

HTTP/2：如果您的 Pod 支持，则可优化性能。
HTTPS (TLS)：用于强制对负载平衡器代理与 Pod 之间的流量进行端到端加密。

您可以使用 Kubernetes Service 清单中的 cloud.google.com/app-protocols 注解来控制用于后端连接的协议（HTTP 或 HTTPS）和 HTTP 版本（HTTP/1.1 或 HTTP/2）。除非您使用容器原生负载均衡，否则此 Service 清单必须包含 type: NodePort。如果您使用容器原生负载均衡，请使用 type: ClusterIP。

HTTPS 负载均衡器的静态 IP 地址

为外部应用负载平衡器创建 Ingress 对象时，您需要获取稳定的外部 IP 地址，客户端可以使用该 IP 地址访问您的 Service，进而访问您正在运行的容器。IP 地址是稳定的，因为它在 Ingress 对象的生存期内持续有效。如果您删除您的 Ingress 并从同一清单文件创建新的 Ingress，则无法保证您会获取相同的外部 IP 地址。

如果您希望获取永久的 IP 地址，即使在删除 Ingress 并创建新的 Ingress 后该 IP 地址仍然保持不变，则必须预留全球静态外部 IP 地址。然后，在您的 Ingress 清单中添加注释，并在其中提供预留的静态 IP 地址的名称。如果您修改现有 Ingress 以使用静态 IP 地址而不是临时 IP 地址，则 GKE 可能会在 GKE 重新创建负载均衡器的转发规则时更改负载均衡器的 IP 地址。

路由流量

GKE Ingress 使用网址映射来定义如何将传入的请求路由到特定的后端服务。您可以根据主机名、网址路径或两者的组合来配置路由规则，以便通过单个负载均衡器管理多个应用的流量。

多个后端服务

每个外部应用负载均衡器或内部应用负载均衡器都使用单个网址映射，该网址映射会引用一个或多个后端服务。一个后端服务对应于 Ingress 引用的每个 Service。

例如，您可以配置负载均衡器，以根据网址路径将请求路由到不同的后端服务。发送到 your-store.example 的请求可路由到显示全价商品的后端服务，而发送到 your-store.example/discounted 的请求可路由到显示打折商品的后端服务。

您还可以将负载均衡器配置为根据主机名路由请求。发送到 your-store.example 的请求可转到一个后端服务，而发送到 your-experimental-store.example 的请求可转到另一个后端服务。

在 GKE 集群中，您可以通过创建 Kubernetes Ingress 对象来创建和配置 HTTP(S) 负载均衡器。一个 Ingress 对象必须与一个或多个 Service 对象相关联，每个 Service 对象与一组 Pod 相关联。

如果您要为同一主机配置具有多个后端的 GKE Ingress，则必须有一个包含单个主机和多个路径的规则。否则，GKE Ingress 控制器只会预配一个后端服务

以下是名为 my-ingress 的 Ingress 的清单：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
 rules:
  - host: your-store.example
    http:
      paths:
      - path: /products
        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 Ingress 控制器会根据该 Ingress 及关联 Service 中的信息创建并配置外部应用负载均衡器或内部应用负载均衡器。此外，负载均衡器会获取稳定的 IP 地址，您可以将该 IP 地址与域名关联。

在上述示例中，假设您已将负载均衡器的 IP 地址与域名 your-store.example 关联。当客户端向 your-store.example/products 发送请求时，请求将路由到端口 60000 上名为 my-products 的 Kubernetes 服务。当客户端向 your-store.example/discounted 发送请求时，请求将路由到端口 80 上名为 my-discounted-products 的 Kubernetes Service。

Ingress 的 path 字段唯一支持的通配符是 * 字符。* 字符必须紧跟在正斜线 (/) 之后，并且必须是格式中的最后一个字符。例如，/*、/foo/*、/foo/bar/* 是有效格式，但 *、/foo/bar*、/foo/*/bar 不是有效格式。

较具体的格式优先于不太具体的格式。如果您同时拥有 /foo/* 和 /foo/bar/*，则选择 /foo/bar/bat 来匹配 /foo/bar/*。

如需详细了解路径限制和格式匹配，请参阅网址映射文档。

my-products Service 的清单可能如下所示：

apiVersion: v1
kind: Service
metadata:
  name: my-products
spec:
  type: NodePort
  selector:
    app: products
    department: sales
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

请注意上述清单中的以下内容：

spec.type 字段取决于您使用的负载均衡方法：
- 如果您使用容器原生负载均衡，请使用 type: ClusterIP。
- 如果您使用实例组，请使用 type: NodePort。
selector 字段指示同时具有 app: products 标签和 department: sales 标签的任何 Pod 都是该 Service 的成员。
当请求到达端口 60000 上的 Service 时，请求将被路由到 TCP 端口 50000 上的其中一个成员 Pod。
每个成员 Pod 必须有一个侦听 TCP 端口 50000 的容器。

my-discounted-products Service 的清单可能如下所示：

apiVersion: v1
kind: Service
metadata:
  name: my-discounted-products
spec:
  type: NodePort
  selector:
    app: discounted-products
    department: sales
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

请注意上述清单中的以下内容：

selector 字段指示同时具有 app: discounted-products 标签和 department: sales 标签的任何 Pod 都是该 Service 的成员。
当请求到达端口 80 上的 Service 时，请求将被路由到 TCP 端口 8080 上的其中一个成员 Pod。
每个成员 Pod 必须有一个侦听 TCP 端口 8080 的容器。

默认后端

您可以通过在 Ingress 清单中提供 spec.defaultBackend 字段来为 Ingress 指定默认后端。这将处理与 rules 字段中定义的路径不匹配的任何请求。例如，在以下 Ingress 中，与 /discounted 不匹配的任何请求都将发送到端口 60001 上名为 my-products 的 Service。

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

如果未指定默认后端，则 GKE 会提供返回 404 的默认后端。这是在 kube-system 命名空间中的集群上创建的 default-http-backend NodePort 服务。

404 HTTP 响应类似于以下内容：

response 404 (backend NotFound), service rules for the path non-existent

如需设置具有自定义默认后端的 GKE Ingress，请参阅具有自定义默认后端的 GKE Ingress。

健康检查

当您使用默认 Ingress 控制器通过 Ingress 公开一个或多个 Service 时，GKE 会创建传统应用负载均衡器或内部应用负载均衡器。这两种负载均衡器均支持单个网址映射上的多个后端服务。每个后端服务都对应一个 Kubernetes Service，并且每个后端服务必须引用Google Cloud 健康检查。此健康检查与 Kubernetes 活跃性探测或就绪性探测不同，因为健康检查在集群外部实现。

负载均衡器健康检查按后端服务来指定。虽然可以对负载均衡器的所有后端服务使用相同的健康检查，但并非为整个负载均衡器（在 Ingress 对象本身中）指定健康检查引用。

GKE 会根据以下方法之一创建健康检查：

BackendConfig CRD：自定义资源定义 (CRD)，可让您精确控制 Service 与负载均衡器的交互方式。借助 BackendConfig CRD，您可以为与相应后端服务关联的健康检查指定自定义设置。这些自定义设置可让您更灵活地控制由 Ingress 创建的传统应用负载均衡器和内部应用负载均衡器的健康检查。
就绪性探测：一种诊断检查，用于确定 Pod 中的容器是否已准备好处理流量。GKE Ingress 控制器会根据 Service 使用中的 Pod 所使用的就绪性探测，为该 Service 的后端服务创建健康检查。您可以从就绪性探测定义中派生健康检查参数，例如路径、端口和协议。
默认值：没有为就绪性探测配置 BackendConfig CRD 或定义属性时使用的参数。

最佳实践：

使用 BackendConfig CRD 可最大限度地控制负载均衡器健康检查设置。

GKE 采用以下过程为与 Kubernetes Service 对应的每个后端服务创建健康检查：

如果该 Service 引用包含 healthCheck 信息的 BackendConfig CRD，则 GKE 会使用该 CRD 来创建健康检查。GKE Enterprise Ingress 控制器和 GKE Ingress 控制器都支持以这种方式创建健康检查。
如果该 Service 不引用 BackendConfig CRD：
- 如果服务 Pod 使用的 Pod 模板具有其就绪性探测特性可解读为健康检查参数的容器，则 GKE 可推断健康检查的部分或全部参数。如需了解实现详情，请参阅来自就绪性探测的参数；如需查看可用于创建健康检查参数的特性列表，请参阅默认参数和推断的参数。只有 GKE Ingress 控制器支持从就绪性探测推断参数。
- 如果该 Service 的服务 Pod 的 Pod 模板没有其就绪性探测特性可解读为健康检查参数的容器，则使用默认值来创建健康检查。GKE Enterprise Ingress 控制器和 GKE Ingress 控制器都只能使用默认值来创建健康检查。

默认参数和推断的参数

如果您没有使用 BackendConfig CRD为相应的 Service 指定健康检查参数，则系统会使用以下参数。

健康检查参数	默认值	可推断的值
协议	HTTP	如果存在于 Service 注释 `cloud.google.com/app-protocols` 中
请求路径	`/`	如果存在于服务 Pod 的 `spec` 中： `containers[].readinessProbe.httpGet.path`
请求主机标头	`Host: backend-ip-address`	如果存在于服务 Pod 的 `spec` 中： `containers[].readinessProbe.httpGet.httpHeaders`
预期响应	HTTP 200 (OK)	HTTP 200 (OK) 不可更改
检查时间间隔	对于容器原生负载均衡：15 秒对于实例组：60 秒	如果存在于服务 Pod 的 `spec` 中：对于容器原生负载均衡： `containers[].readinessProbe.periodSeconds` 对于实例组： `containers[].readinessProbe.periodSeconds + 60 seconds`
检查超时	5 秒	如果存在于服务 Pod 的 `spec` 中： `containers[].readinessProbe.timeoutSeconds`
运行状况良好判断阈值	1	1 不可更改
运行状况不佳判断阈值	对于容器原生负载均衡：2 对于实例组：10	与默认值相同：对于容器原生负载均衡：2 对于实例组：10
端口指定	对于容器原生负载均衡：Service 的 `port` 对于实例组：Service 的 `nodePort`	只要满足以下所有条件，健康检查探测就会发送到 `spec.containers[].readinessProbe.httpGet.port` 指定的端口号：就绪性探测的端口号必须与服务 Pod 的 `containers[].spec.ports.containerPort` 匹配服务 Pod 的 `containerPort` 与 Service 的 `targetPort` 匹配 Ingress 服务后端端口规范引用了 Service 的 `spec.ports[]` 的有效端口。这可以通过以下两种方法完成： Ingress 中的 `spec.rules[].http.paths[].backend.service.port.name` 与相应 Service 中定义的 `spec.ports[].name` 匹配 Ingress 中的 `spec.rules[].http.paths[].backend.service.port.number` 与相应 Service 中定义的 `spec.ports[].port` 匹配
目的地 IP 地址	对于容器原生负载均衡：Pod 的 IP 地址对于实例组：节点的 IP 地址	与默认值相同：对于容器原生负载均衡：Pod 的 IP 地址对于实例组：节点的 IP 地址

来自就绪性探测的参数

GKE 为 Service 的后端服务创建健康检查后，GKE 可以从该 Service 的服务 Pod 所使用的一个容器的就绪性探测中复制某些参数。仅 GKE Ingress 控制器支持此选项。

系统会列出可解读为健康检查参数的受支持就绪性探测特性以及默认参数和推断的参数中的默认值。默认值用于就绪性探测中未指定的任何特性，或者在完全未指定就绪性探测时使用。

如果您的 Service 的服务 Pod 包含多个容器，或者如果您使用的是 GKE Enterprise Ingress 控制器，则应使用 BackendConfig CRD 来定义健康检查参数。如需了解详情，请参阅何时改用 BackendConfig CRD。

何时改用 `BackendConfig` CRD

在以下情况下，您应该通过为 Service 创建 BackendConfig CRD 来显式定义后端服务的运行状态检查参数，而不是依赖于来自 Pod 就绪性探测的参数。

如果您使用的是 GKE Enterprise：GKE Enterprise Ingress 控制器不支持从服务 Pod 的就绪性探测中获取健康检查参数。Anthos Ingress 控制器只能使用隐式参数或按 BackendConfig CRD 所定义的创建健康检查。
如果您在服务 Pod 中有多个容器：GKE 无法选择特定容器的就绪探针，从中推断健康检查参数。因为每个容器都可以有自己的就绪探针，并且因为就绪探针不是容器的必需参数，所以您应该通过引用相应 Service 上的 BackendConfig CRD 来定义相应后端服务的健康检查。
如果您需要控制负载均衡器的健康检查使用的端口：只有在就绪性探测的 containers[].readinessProbe.httpGet.port 与 Ingress spec.rules[].http.paths[].backend.servicePort 中引用的 Service 的服务端口匹配时，GKE 才将该端口用于后端服务的健康检查。

来自 `BackendConfig` CRD 的参数

您可以使用相应 Service 引用的 BackendConfig CRD 的 healthCheck 参数指定后端服务的健康检查参数。这使您获得更大的灵活性，并且能更大程度地控制由 Ingress 创建的传统应用负载均衡器或内部应用负载均衡器的健康检查。如需了解 GKE 版本兼容性，请参阅 Ingress 配置。

以下示例 BackendConfig CRD 在其 spec.healthCheck 特性中定义了健康检查协议（类型）、请求路径、端口和检查时间间隔：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    checkIntervalSec: 15
    port: 15020
    type: HTTPS
    requestPath: /healthz

如需在配置 BackendConfig 健康检查时配置所有可用字段，请使用自定义健康检查配置示例。

如需设置具有自定义 HTTP 健康检查的 GKE Ingress，请参阅具有自定义 HTTP 健康检查的 GKE Ingress。

Pod 就绪性

使用上述任一方法配置负载均衡器的健康检查后，GKE Ingress 控制器会使用后端端点的健康状况来确定 Pod 就绪情况，这对于管理滚动更新和整体流量稳定性至关重要。

对于相关 Pod，相应的 Ingress 控制器会管理一个类型为 cloud.google.com/load-balancer-neg-ready 的就绪性门控。Ingress 控制器会轮询负载均衡器的健康检查状态，其中包括 NEG 中所有端点的健康状况。如果负载均衡器的健康检查状态指示，特定 Pod 对应的端点运行正常，Ingress 控制器就会将 Pod 就绪性门控的值设置为True。然后，在每个节点上运行的 kubelet 会计算 Pod 的有效就绪性，同时考虑此就绪性门控的值以及 Pod 的就绪性探测结果（如果定义了就绪性探测）。

通过 Ingress 使用容器原生负载均衡时，系统会自动启用 Pod 就绪性门控。

就绪性门控可以控制滚动更新的速率。启动滚动更新后，在 GKE 创建新 Pod 时，每个新 Pod 的端点都会添加到 NEG。如果从负载均衡器的角度来看，端点运行状况良好，则 Ingress 控制器会将就绪性门控设置为 True。在 GKE 移除旧 Pod 之前，新创建的 Pod 必须至少通过其就绪性门控检查。这样可以确保该 Pod 的对应端点已经通过了负载均衡器的健康检查，并且后端容量得以维持。

如果 Pod 的就绪性门控因为容器映像已损坏或者负载均衡器健康检查配置有误而从未指示 Pod 已准备就绪，则负载均衡器不会将流量定向到新 Pod。如果在发布更新的 Deployment 时发生此类故障，则发布操作会在尝试创建一个新 Pod 后停止，这是因为该 Pod 的就绪性门控状态从未变为 True。如需了解如何检测和解决此问题，请参阅“问题排查”部分。

如果没有容器原生负载均衡和就绪性门控，则在将 Pod 标记为准备就绪之前，GKE 无法检测负载均衡器端点是否健康。在以前的 Kubernetes 版本中，您可以通过指定延迟时间段（Deployment 规范中的 minReadySeconds）来控制系统移除和替换 Pod 的速率。

如果满足以下任一条件，则 GKE 会将 Pod 的 cloud.google.com/load-balancer-neg-ready 的值设置为 True：

Pod 的 IP 地址都不是 GKE 控制平面管理的 GCE_VM_IP_PORT NEG 中的端点。
Pod 的一个或多个 IP 地址是 GKE 控制平面管理的 GCE_VM_IP_PORT NEG 中的端点。NEG 已连接到后端服务。后端服务的负载均衡器健康检查成功。
Pod 的一个或多个 IP 地址是 GKE 控制平面管理的 GCE_VM_IP_PORT NEG 中的端点。NEG 已连接到后端服务。后端服务的负载均衡器健康检查超时。
一个或多个 Pod IP 地址是一个或多个 GCE_VM_IP_PORT NEG 中的端点。所有 NEG 都不会附加到后端服务。没有可用的负载均衡器健康检查数据。

对 WebSocket 的支持

使用外部应用负载均衡器时，WebSocket 协议无需进行任何配置即可运行。

如果您打算使用 WebSocket 协议，您可能需要使用大于默认值 30 秒的超时值。对于通过Google Cloud 外部应用负载均衡器发送的 WebSocket 流量，后端服务超时被解释为 WebSocket 连接可以保持打开状态（无论是否空闲）的最长时间。

如需为后端服务设置超时值，请参阅后端响应超时。

高级网络场景

GKE Ingress 支持高级网络配置，例如跨项目共享网络资源和使用自定义 Ingress 控制器。

共享 VPC

共享 VPC 支持 Ingress 和 MultiClusterIngress 资源，但它们需要进行一些额外的准备。

Ingress 控制器在 GKE 控制平面上运行，并使用集群项目的 GKE 服务账号对 Google Cloud 进行 API 调用。默认情况下，位于共享 VPC 服务项目中的集群使用共享 VPC 网络时，Ingress 控制器无法使用该服务项目的 GKE 服务账号在宿主项目中创建和更新入站允许防火墙规则。

您可以向服务项目的 GKE 服务账号授予在宿主项目中创建和管理 VPC 防火墙规则的权限。通过授予这些权限，GKE 可以为以下各项创建入站允许防火墙规则：

外部应用负载均衡器用于外部 Ingress 的 Google Front End (GFE) 代理和健康检查系统。如需了解详情，请参阅外部应用负载均衡器概览。
内部 Ingress 使用的内部应用负载均衡器的健康检查系统。

注意：无论您是否使用共享 VPC，如果您的集群使用内部 Ingress，都必须手动创建入站允许防火墙规则以允许来自集群的 VPC 网络和区域中的代理专用子网的流量。需要手动创建这些规则，因为 GKE Ingress 控制器无法创建入站允许防火墙规则来允许内部应用负载均衡器的代理专用子网的流量。如需了解详情，请参阅适用于内部应用负载平衡器的 Ingress 中所需的网络环境。

从宿主项目手动预配防火墙规则

如果您的安全政策仅允许从宿主项目管理防火墙，则您可以手动预配这些防火墙规则。在共享 VPC 中部署 Ingress 时，Ingress 资源事件会提供您为了提供访问权限而必须添加的特定防火墙规则。

如需手动预配规则，请执行以下操作：

查看 Ingress 资源事件：

kubectl describe ingress INGRESS_NAME

将 INGRESS_NAME 替换为您的 Ingress 名称。

您应该会看到类似于以下示例的输出：

Events:
Type    Reason  Age                    From                     Message
----    ------  ----                   ----                     -------
Normal  Sync    9m34s (x237 over 38h)  loadbalancer-controller  Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`

Message 列中会显示建议的必需防火墙规则。

从宿主项目复制并应用建议的防火墙规则。通过应用规则，您可从负载均衡器和Google Cloud 健康检查工具访问 Pod。

注意：不同类型的 Ingress 需要不同的规则。即使您使用自己的自定义入站防火墙规则来允许流量，GKE 也可能会显示防火墙规则警告。在这种情况下，您可以忽略该警告。

为 Ingress 控制器提供管理宿主项目防火墙规则的权限

如果您希望服务项目中的 GKE 集群在宿主项目中创建和管理防火墙资源，则必须使用以下策略之一向服务项目的 GKE 服务账号授予适当的 IAM 权限：

向服务项目的 GKE 服务账号授予对宿主项目的 Compute Security Admin 角色。以下示例演示了此策略。
如需更精细的方法，请创建一个仅提供以下权限的自定义 IAM 角色：compute.networks.updatePolicy、compute.firewalls.list、compute.firewalls.get、compute.firewalls.create、compute.firewalls.update、compute.firewalls.delete 和 compute.subnetworks.list。为服务项目的 GKE 服务账号授予对宿主项目的自定义角色。

如果多个服务项目中包含集群，则必须选择一项策略，并为每个服务项目的 GKE 服务账号重复执行此策略。

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

替换以下内容：

HOST_PROJECT_ID：共享 VPC 宿主项目的 ID。
SERVICE_PROJECT_NUMBER：包含集群的服务项目的编号。

使用自定义 Ingress 控制器

您可以通过停用 HttpLoadBalancing 插件来运行自定义 Ingress 控制器。这可以防止 GKE Ingress 控制器处理 Ingress 资源。

如果您想运行启用了 HttpLoadBalancing 插件的自定义 Ingress 控制器，例如使用子集和 Private Service Connect 等功能，您可以使用以下方法之一：

在 Ingress 清单中，设置 kubernetes.io/ingress.class 注释。运行所有 GKE 版本的集群都支持此配置。
配置 ingressClassName 字段。
配置默认 Ingress 类。

您必须确保 spec.ingressClassName 不会被任何进程意外覆盖。将 spec.IngressClassName 从有效值更改为空字符串 ("") 的更新操作会促使 GKE Ingress 控制器处理 Ingress。

配置 `ingressClassName` 字段

您可以通过在 Ingress 清单中设置 ingressClassName 字段来使用自定义 Ingress 控制器。以下清单描述了一个用于指定 cilium Ingress 控制器的 Ingress：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: cafe-ingress
spec:
 ingressClassName: cilium
 tls:
 - hosts:
   - cafe.example.com
   secretName: cafe-secret
 rules:
 - host: cafe.example.com

配置默认 Ingress 类

如需为集群中的所有 Ingress 资源配置默认 Ingress 类，您可以创建 IngressClass 资源，并将注释 ingressclass.kubernetes.io/is-default-class 设置为 true：

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: gce
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-gce

GKE Ingress 控制器行为摘要

对于运行 GKE 1.18 及更高版本的集群，GKE Ingress 控制器是否处理 Ingress 取决于 Ingress 清单中 kubernetes.io/ingress.class 注解和 ingressClassName 字段的值。如需了解详情，请参阅 GKE Ingress 控制器行为。

Ingress 配置的模板

在 GKE 网络配方中，您可以在 Ingress 部分下找到 GKE 针对许多常见 Ingress 使用场景提供的模板。