本页面概述了通过 Google Cloud 上的 Kubernetes Ingress 支持和可配置的内容。适用于 Google Kubernetes Engine (GKE) 和 Anthos 的 Ingress 可提供企业级负载均衡功能，并与您的 Google Cloud VPC 网络紧密集成。

注意：在 Kubernetes 1.19 及更高版本中，Ingress API 版本已升级为正式版 networking.k8s.io/v1，并且 Ingress/v1beta1 已标记为已弃用。在 Kubernetes 1.22 中，Ingress/v1beta1 已被移除。如果您使用的是 GKE 集群 1.19 版及更高版本，请迁移至 Ingress/v1。如需了解如何迁移到 Ingress/v1，请参阅 Ingress 迁移。

特性比较

下表提供了 Google Cloud 上 Ingress 的受支持特性列表。同时指示推出特性的正式版 (GA) 或 Beta 版。

^B从指定版本开始，此特性在 Beta 版中可用。所有可用的 GKE 和 Anthos 版本均支持未列出版本的特性。

^G从指定版本开始支持将此特性用作 GA。

配置 Ingress 特性

您无法使用 Google Cloud SDK 或 Google Cloud 控制台手动配置 LoadBalancer 功能。您必须使用 BackendConfig 或 FrontendConfig Kubernetes 资源。

使用默认控制器创建 Ingress 时，您可以使用对 Ingress 对象的注释来选择负载平衡器的类型（外部 HTTP(S) 负载平衡器或内部 HTTP(S) 负载平衡器）。您可以选择是 GKE 创建区域 NEG 还是它通过对每个 Service 对象使用注释来使用实例组。

FrontendConfig 和 BackendConfig 自定义资源定义 (CRD) 允许您进一步自定义负载平衡器。这些 CRD 允许您以分层方式定义其他负载平衡器特性，分层方式比注释更具结构化。如需使用 Ingress（以及这些 CRD），您必须启用 HTTP 负载平衡插件。GKE 集群默认启用了 HTTP 负载平衡；您不得将其停用。

FrontendConfigs 在 Ingress 对象中引用，BackendConfigs 通过 Service 对象引用。多个 Service 或 Ingress 对象可以引用相同的 CRD，以实现配置一致性。FrontendConfig 和 BackendConfig CRD 与其对应的 Ingress 和 Service 资源具有相同的生命周期，并且通常一起部署。

下图说明了具体方法：

• 对 Ingress 或 MultiClusterIngress 对象的注释引用了 FrontendConfig CRD。FrontendConfig CRD 引用了 Google Cloud SSL 政策。
• 对 Service 或 MultiClusterService 对象的注释引用了 BackendConfig CRD。BackendConfig CRD 为相应后端服务的健康检查指定自定义设置。
• 图：BackendConfig 和 FrontendConfig 概览

将 FrontendConfig 与 Ingress 关联

您可以将一个 FrontendConfig 与一个 Ingress 或 MultiClusterIngress 关联。

入站

多集群 Ingress

使用 networking.gke.io/v1beta1.FrontendConfig 注解：

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  annotations:    networking.gke.io/v1beta1.FrontendConfig: 'FRONTENDCONFIG_NAME'...

将 FRONTENDCONFIG_NAME 替换为您的 FrontendConfig 名称。

将 BackendConfig 与 Ingress 关联

Service 或 MultiClusterService 可以使用 cloud.google.com/backend-config 或 beta.cloud.google.com/backend-config 注释来指定 BackendConfig 的名称。与 Service 或 MultiClusterService 关联时，BackendConfig 资源会要求 Google Cloud 创建或修改后端服务设置。

在以下示例中：

如果您使用的是 GKE 1.16-gke.3 或更高版本，那么即使 beta.cloud.google.com/backend-config 注释也可以使用，您也仍应使用 cloud.google.com/backend-config 注释。对于早期版本，您必须使用 beta.cloud.google.com/backend-config 注释。

所有 Service 端口使用相同的 BackendConfig

如需对 Service 或 MultiClusterService 的所有端口使用相同的 BackendConfig，请在注释中使用 default 键。每次创建负载均衡器后端服务以引用 Service 的其中一个端口时，Ingress 控制器都会使用相同的 BackendConfig。

1.16-gke.3+

所有受支持的版本

apiVersion: v1kind: Servicemetadata:  annotations:    cloud.google.com/backend-config: '{'default': 'my-backendconfig'}'...

每个 Service 端口拥有唯一的 BackendConfig

您可以使用与端口名称或端口号匹配的密钥，为 Service 或 MultiClusterService 的一个或多个特定端口指定自定义 BackendConfig。Ingress 控制器在为引用的 Service 端口创建负载均衡器后端服务时会使用这些特定的 BackendConfig。

1.16-gke.3+

所有受支持的版本

apiVersion: v1kind: Servicemetadata:  annotations:    cloud.google.com/backend-config: '{'ports': {    'SERVICE_REFERENCE_A':'BACKENDCONFIG_REFERENCE_A',    'SERVICE_REFERENCE_B':'BACKENDCONFIG_REFERENCE_B'    }}'spec:  ports:  - name: PORT_NAME_1    port: PORT_NUMBER_1    protocol: TCP    targetPort: 50000  - name: PORT_NAME_2    port: PORT_NUMBER_2    protocol: TCP    targetPort: 8080...

替换以下内容：

• BACKENDCONFIG_REFERENCE_A：现有 BackendConfig 的名称。
• BACKENDCONFIG_REFERENCE_B：现有 BackendConfig 的名称。
• SERVICE_REFERENCE_A：使用 PORT_NUMBER_1 或 PORT_NAME_1 的值。这是因为 Service 的 BackendConfig 注释可以引用端口的名称 (spec.ports[].name) 或端口的编号 (spec.ports[].port)。
• SERVICE_REFERENCE_B：使用 PORT_NUMBER_2 或 PORT_NAME_2 的值。这是因为 Service 的 BackendConfig 注释可以引用端口的名称 (spec.ports[].name) 或端口的编号 (spec.ports[].port)。

按端口号引用 Service 的端口时，必须使用 port 值，而不是 targetPort 值。此处使用的端口号仅用于绑定 BackendConfig；它不控制负载均衡器向哪个端口发送流量或健康检查探测：

• 使用容器原生负载均衡时，负载均衡器会将流量发送到引用的 Service 端口 targetPort（必须与服务 Pod 的 containerPort 匹配）上的网络端点组中的某个端点（与 Pod 的 IP 地址匹配）。否则，负载均衡器会将流量发送到引用的 Service 端口 nodePort 上的节点 IP 地址。
• 使用 BackendConfig 提供自定义负载均衡器健康检查时，用于负载均衡器健康检查的端口号可以与 Service 的 spec.ports[].port 端口号不同。如需详细了解健康检查的端口号，请参阅自定义健康检查配置。
• 注意：与 BackendConfig 关联的服务端口也必须在 Ingress 定义字段 backend.service.port 中使用。如果未在任何 Ingress 对象中使用服务端口，系统将忽略 BackendConfig。

通过 FrontendConfig 参数配置 Ingress 特性

以下部分介绍如何设置 FrontendConfig 以启用特定 Ingress 特性。

SSL 政策

SSL 政策允许您指定一组 TLS 版本和密码，负载平衡器使用这些版本和密码终止来自客户端的 HTTPS 流量。必须先在 GKE 外部创建 SSL 政策。创建后，可以在 FrontendConfig CRD 中引用它。

FrontendConfig 中的 sslPolicy 字段引用与 GKE 集群相同的 Google Cloud 项目中的 SSL 政策名称。它将 SSL 政策附加到目标 HTTPS 代理，后者是 Ingress 为外部 HTTP(S) 负载平衡器创建的。多个 Ingress 资源可以引用同一个 FrontendConfig 资源和 SSL 政策。如果引用的 SSL 政策发生更改，则更改会传播到为 Ingress 创建的外部 HTTP（S）负载平衡器提供支持的 Google Front End (GFE)。

以下 FrontendConfig 清单启用名为 gke-ingress-ssl-policy 的 SSL 政策：

apiVersion: networking.gke.io/v1beta1kind: FrontendConfigmetadata:  name: my-frontend-configspec:  sslPolicy: gke-ingress-ssl-policy

从 HTTP 到 HTTPS 的重定向

外部 HTTP 负载平衡器可以将未加密的 HTTP 请求重定向到使用同一 IP 地址的 HTTPS 负载平衡器。当您在创建启用了从 HTTP 到 HTTPS 的重定向的 Ingress 时，系统会自动创建这两个负载平衡器。对端口 80 上 Ingress 的外部 IP 地址的请求会自动重定向到端口 443 上的同一外部 IP 地址。此功能构建于 Cloud Load Balancing 提供的从 HTTP 到 HTTPS 的重定向之上。

如需支持 HTTP 到 HTTPS 重定向，必须配置 Ingress 以同时提供 HTTP 和 HTTPS 流量。如果停用 HTTP 或 HTTPS，则重定向将不起作用。

HTTP 到 HTTPS 重定向使用 FrontendConfig 自定义资源中的 redirectToHttps 字段进行配置。系统会对整个 Ingress 资源启用重定向功能，以便 Ingress 引用的所有服务都将启用 HTTPS 重定向功能。

以下 FrontendConfig 清单允许从 HTTP 到 HTTPS 的重定向。将 spec.redirectToHttps.enabled 字段设置为 true 以启用 HTTPS 重定向功能。spec.responseCodeName 字段为可选字段。如果省略此项，则系统会使用 301 Moved Permanently 重定向。

apiVersion: networking.gke.io/v1beta1kind: FrontendConfigmetadata:  name: my-frontend-configspec:  redirectToHttps:    enabled: true    responseCodeName: RESPONSE_CODE

将 RESPONSE_CODE 替换为以下项之一：

• MOVED_PERMANENTLY_DEFAULT，用于返回 301 重定向响应代码（如果未指定 responseCodeName，则默认为此项）。
• FOUND，用于返回 302 重定向响应代码。
• SEE_OTHER，用于返回 303 重定向响应代码。
• TEMPORARY_REDIRECT，用于返回 307 重定向响应代码。
• PERMANENT_REDIRECT，用于返回 308 重定向响应代码。

启用重定向后，Ingress 控制器会创建负载均衡器，如下图所示：

如需验证重定向是否正常工作，请使用 curl 命令：

curl http://IP_ADDRESS

将 IP_ADDRESS 替换为 Ingress 的 IP 地址。

该响应会显示您配置的重定向响应代码。例如，以下示例展示了配置了 301: MovedPermanently 重定向的 FrontendConfig：

<HTML><HEAD><meta http-equiv='content-type' content='text/html;charset=utf-8'>
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF='https://35.244.160.59/'>here</A>.</BODY></HTML>

通过 BackendConfig 参数配置 Ingress 特性

以下部分演示如何设置 BackendConfig 以启用特定 Ingress 特性。系统会不断协调对 BackendConfig 资源的更改，因此您无需删除并重新创建 Ingress 就可以看到 BackendConfig 的更改反映出来。

如需了解 BackendConfig 限制，请参阅限制部分。

重要提示：对于 GKE 1.16.8-gke.3 及更高版本，建议您使用 cloud.google.com/v1 API 版本。如果您使用的是早期版本的 GKE，请使用 cloud.google.com/v1beta1。

后端服务超时

您可以使用 BackendConfig 来设置后端服务超时时间段（以秒为单位）。如果未指定值，则默认值为 30 秒。

以下 BackendConfig 清单指定 40 秒的超时：

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name: my-backendconfigspec:  timeoutSec: 40

Cloud CDN

您可以使用 BackendConfig 来启用Cloud CDN。

注意：不能在 BackendConfig 中同时启用 IAP 和 Cloud CDN。如果 BackendConfig 没有 iap 块，则会继承后端服务上的任何现有的 IAP 设置。

以下 BackendConfig 清单显示了启用 Cloud CDN 时可用的所有字段：

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name: my-backendconfigspec:  cdn:    enabled: CDN_ENABLED    cachePolicy:      includeHost: INCLUDE_HOST      includeProtocol: INCLUDE_PROTOCOL      includeQueryString: INCLUDE_QUERY_STRING      queryStringBlacklist: QUERY_STRING_DENYLIST      queryStringWhitelist: QUERY_STRING_ALLOWLIST    cacheMode: CACHE_MODE    clientTtl: CLIENT_TTL    defaultTtl: DEFAULT_TTL    maxTtl: MAX_TTL    negativeCaching: NEGATIVE_CACHING    negativeCachingPolicy:      code: NEGATIVE_CACHING_CODE      ttl: NEGATIVE_CACHING_TTL    requestCoalescing: REQ_COALESCING    serveWhileStale: SERVE_WHILE_STALE    signedUrlCacheMaxAgeSec: SIGNED_MAX_AGE    signedUrlKeys:      keyName: KEY_NAME      keyValue: KEY_VALUE      secretName: SECRET_NAME

替换以下内容：

• CDN_ENABLED：如果设置为 true，则会为此 Ingress 后端启用 Cloud CDN。
• INCLUDE_HOST：如果设置为 true，则会分别缓存对不同主机的请求。
• INCLUDE_PROTOCOL：如果设置为 true，则会分别缓存 HTTP 和 HTTPS 请求。
• INCLUDE_QUERY_STRING：如果设置为 true，则会根据 queryStringBlacklist 或 queryStringWhitelist 将查询字符串参数包含在缓存键中。如果两者都未设置，则包括整个查询字符串。如果设置为 false，则会从缓存键中排除整个缓存字符串。
• QUERY_STRING_DENYLIST：指定含有要从缓存键中排除的查询字符串参数名称的字符串数组。包括所有其他参数。您可以指定 queryStringBlacklist 或 queryStringWhitelist，但不能同时指定这两者。
• QUERY_STRING_ALLOWLIST：指定含有要包含在缓存键中的查询字符串参数名称的字符串数组。排除所有其他参数。您可以指定 queryStringBlacklist 或 queryStringWhitelist，但不能同时指定这两者。

只有使用 GKE Ingress 的 GKE 版本 1.23.3-gke.900 及更高版本支持以下字段。使用多集群 Ingress 的版本不支持它们：

• CACHE_MODE：缓存模式。
• CLIENT_TTL、DEFAULT_TTL 和 MAX_TTL：TTL 配置。如需了解详情，请参阅使用 TTL 设置和替换。
• NEGATIVE_CACHING：如果设置为 true，则会启用负缓存。如需了解详情，请参阅使用负缓存。
• NEGATIVE_CACHING_CODE 和 NEGATIVE_CACHING_TTL：负缓存配置。如需了解详情，请参阅使用负缓存。
• REQ_COALESCING：如果设置为 true，则启用折叠功能。如需了解详情，请参阅请求折叠（合并）。
• SERVE_WHILE_STALE：响应过期后 Cloud CDN 继续提供过时版本的时间（以秒为单位）。如需了解详情，请参阅提供过时内容。
• SIGNED_MAX_AGE：可以缓存响应的最长时间（以秒为单位）。如需了解详情，请参阅选择性地自定义最长缓存时间。
• KEY_NAME、KEY_VALUE 和 SECRET_NAME：签名网址密钥配置。如需了解详情，请参阅创建签名请求密钥。

展开以下部分即可看到通过 Ingress 部署 Cloud CDN，然后验证应用内容是否缓存的示例。

Cloud CDN 示例

连接排空超时

您可以使用 BackendConfig 来配置连接排空超时。连接排空超时是指等待连接排空的时间（以秒为单位）。在指定的超时持续时间内，系统会为对已移除后端发出的现有请求留出一定的时间，让这些请求可以完成。负载平衡器不会向已移除的后端发送新请求。达到超时持续时间之后，系统会关闭与该后端的所有剩余连接。超时持续时间可以介于 0 到 3600 秒之间。默认值为 0，此值也会停用连接排空。

警告：在使用实例组的 Ingress 或 Service 上为 drainingTimeoutSec 设置较高的值（例如 3600 秒）会导致比例延迟设置为更新集群中的其他 Ingress 资源时设置的 drainingTimeoutSec 的时长。这是因为集群中的所有基于实例组的 Ingress 资源都共享同一实例组。如果您需要较高的值，请考虑使用由网络端点组提供支持的 Service。

以下 BackendConfig 清单指定 60 秒的连接排空超时：

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name: my-backendconfigspec:  connectionDraining:    drainingTimeoutSec: 60

自定义健康检查配置

通过 Ingress 进行部署时，GKE 有多种方法配置 Google Cloud 负载均衡器健康检查。如需详细了解 GKE Ingress 如何部署健康检查，请参阅 Ingress 健康检查。

借助 BackendConfig，您可以精确控制负载均衡器的健康检查设置。

注意：Ingress 不支持自定义健康检查配置的 gRPC。

您可以配置多个 GKE 服务，以将同一个 BackendConfig 作为可重复使用的模板引用。对于 healthCheck 参数，系统会为与每个 GKE 服务对应的每个后端服务创建唯一的 Google Cloud 健康检查。

以下 BackendConfig 清单显示了配置 BackendConfig 健康检查时可用的所有字段：

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name: my-backendconfigspec:  healthCheck:    checkIntervalSec: INTERVAL    timeoutSec: TIMEOUT    healthyThreshold: HEALTH_THRESHOLD    unhealthyThreshold: UNHEALTHY_THRESHOLD    type: PROTOCOL    requestPath: PATH    port: PORT

请替换以下内容：

• INTERVAL：为每个健康检查探测器指定 check-interval（以秒为单位）。这是指从探测器检查开始到下一次检查开始的时间。如果您省略此参数，则会使用 Google Cloud 默认值 5 秒。如需其他实现详情，请参阅多重探测和频率。
• TIMEOUT：指定 Google Cloud 等待探测响应的时间量。TIMEOUT 的值必须小于或等于 INTERVAL。该时间以秒为单位。每个探测都要求在探测超时之前传送 HTTP 200 (OK) 响应代码。
• HEALTH_THRESHOLD 和 UNHEALTHY_THRESHOLD：指定至少一个探测器必须进行的成功或失败顺序连接尝试次数，以便将运行状况从运行状况良好更改为运行状况不佳，反之亦然。如果您省略其中一个参数，Google Cloud 会使用默认值 2。
• PROTOCOL：指定探测系统用于健康检查的协议。BackendConfig 仅支持使用 HTTP、HTTPS 或 HTTP2 协议来创建健康检查。如需了解详情，请参阅 HTTP、HTTPS、HTTP/2 成功标准。您不能省略此参数。
• PATH：对于 HTTP、HTTPS 或 HTTP2 健康检查，指定探测系统应连接到的 request-path。如果您省略此参数，Google Cloud 将使用默认值 /。PORT：BackendConfig 仅支持使用端口号指定负载均衡器的健康检查端口。如果您省略此参数，Google Cloud 将使用默认值 80。使用容器原生负载均衡时，您应选择与服务 Pod 的 containerPort 匹配的端口（无论 containerPort 是否被 Service 的 targetPort 引用）。由于负载均衡器将探测直接发送到 Pod 的 IP 地址，因此您并非只能使用 Service 的 targetPort 引用的 containerPort。健康检查探测系统会连接到指定端口上服务 Pod 的 IP 地址。对于实例组后端，您必须选择与 Service 公开的 nodePort 匹配的端口。之后，健康检查探测系统便会连接到该端口上的每个节点。

Google Cloud Armor Ingress 安全政策

Google Cloud Armor 安全政策有助于保护您的负载均衡应用免遭 Web 攻击。配置 Google Cloud Armor 安全政策后，您可以使用 BackendConfig 来引用该政策。

将安全政策的名称添加到 BackendConfig。以下 BackendConfig 清单指定了名为 example-security-policy 的安全政策：

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  namespace: cloud-armor-how-to  name: my-backendconfigspec:  securityPolicy:    name: 'example-security-policy'

HTTP 访问日志记录

注意：多集群 Ingress 的访问日志记录在 GKE 1.18 之前的所有版本中均默认为“启用”，但从 1.16.8-gke.10 开始作为可配置字段公开。其他入站流量类型的访问日志记录默认关闭。

Ingress 可以将来自客户端的所有 HTTP 请求记录到 Cloud Logging 中。您可以通过使用 BackendConfig 以及设置访问日志记录采样率来启用和停用访问日志记录。

要配置访问日志记录，请使用 BackendConfig 中的 logging 字段。如果省略 logging，则访问日志记录将采用默认行为。这取决于 GKE 版本。

您可以配置以下字段：

• enable：如果设置为 true，系统将为此 Ingress 启用访问日志记录功能，并且日志可在 Cloud Logging 中获得。否则，系统会为此 Ingress 停用访问日志记录。
• sampleRate：指定一个介于 0.0 到 1.0 之间的值，其中 0.0 表示不记录数据包，1.0 表示记录所有数据包。只有当 enable 设置为 true 时，此字段才相关。sampleRate 是可选字段，但如果已配置，则必须设置 enable: true，否则将被解读为 enable: false。

以下 BackendConfig 清单启用访问日志记录，并将采样率设置为指定 Ingress 资源 HTTP 请求的 50％。

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name: my-backendconfigspec:  logging:    enable: true    sampleRate: 0.5

Identity-Aware Proxy

要为 Identity-Aware Proxy IAP 配置 BackendConfig，您需要将 enabled 和 secretName 值指定为 BackendConfig 中的 iap 块。要指定这些值，请确保您拥有 compute.backendServices.update 权限。

注意：不能在 BackendConfig 中同时启用 IAP 和 Cloud CDN。如果 BackendConfig 没有 iap 块，则会继承后端服务上的任何现有的 IAP 设置。

以下 BackendConfig 清单启用 Identity-Aware Proxy：

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name:  my-backendconfigspec:  iap:    enabled: true    oauthclientCredentials:      secretName: my-secret

如需查看完整说明，请参阅 IAP 文档中的为 GKE 启用 IAP。

具有内部 Ingress 的 Identity-Aware Proxy

如需为 IAP 配置内部 Ingress，您必须使用高级层级。如果您不使用高级层级，则无法使用 Identity-Aware Proxy 查看或创建内部 HTTP(S) 负载均衡器。您还必须拥有 BeyondCorp Enterprise 订阅，才能将内部 Ingress 用于 IAP。

会话亲和性

您可以使用 BackendConfig 将会话亲和性设置为客户端 IP 或生成的 Cookie。

重要提示：如果要配置会话亲和性，请使用 VPC 原生集群。会话亲和性仅适用于网络端点组支持的 Service，并且网络端点组需要 VPC 原生集群。

客户端 IP 亲和性

要使用 BackendConfig 设置客户端 IP 亲和性，请将 affinityType 设置为 'CLIENT_IP'，如以下示例所示：

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name: my-backendconfigspec:  sessionAffinity:    affinityType: 'CLIENT_IP'

生成的 Cookie 亲和性

要使用 BackendConfig 设置生成的 Cookie 亲和性，请在 BackendConfig 清单中将 affinityType 设置为GENERATED_COOKIE。您还可以使用 affinityCookieTtlSec 来设置 Cookie 保持活动的时间段。

以下清单将亲和性类型设置为生成的 Cookie 并为 Cookie 设置 50 秒的 TTL：

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name: my-backendconfigspec:  sessionAffinity:    affinityType: 'GENERATED_COOKIE'    affinityCookieTtlSec: 50

用户定义的请求标头

您可以使用 BackendConfig 来配置用户定义的请求标头。负载平衡器会将您指定的标头添加至它转发到后端的请求。

要启用用户定义的请求标头，您需要在 BackendConfig 资源的 customRequestHeaders 属性中指定标头列表。您可以将每个标头指定为 header-name:header-value 字符串。

以下 BackendConfig 清单添加了三个请求标头：

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name: my-backendconfigspec:  customRequestHeaders:    headers:    - 'X-Client-Region:{client_region}'    - 'X-Client-City:{client_city}'    - 'X-Client-CityLatLong:{client_city_lat_long}'

练习：使用后端服务设置 Ingress 超时

以下练习展示了使用具有 BackendConfig 资源的 Ingress 配置超时和连接排空所需的步骤。

要配置 Ingress 的后端属性，请完成以下任务：

1. 创建一个 Deployment。
2. 创建 BackendConfig。
3. 创建一个 Service，并将它的一个端口与 BackendConfig 关联。
4. 创建一个 Ingress，并将该 Ingress 与（Service, 端口）对关联。
5. 验证后端服务的属性。
6. 清理.

创建 Deployment

在创建 BackendConfig 和 Service 之前，您需要创建一个 Deployment。

以下示例清单适用于名为 my-deployment.yaml 的 Deployment：

# my-deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: my-deploymentspec:  selector:    matchLabels:      purpose: bsc-config-demo  replicas: 2  template:    metadata:      labels:        purpose: bsc-config-demo    spec:      containers:      - name: hello-app-container        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

通过运行以下命令以创建 Deployment：

kubectl apply -f my-deployment.yaml

创建 BackendConfig

使用 BackendConfig 指定要使用的 Ingress 特性。

这个名为 my-backendconfig.yaml 的 BackendConfig 清单指定了以下内容：

• 超时时间为 40 秒。
• 连接排空超时为 60 秒。

# my-backendconfig.yamlapiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name: my-backendconfigspec:  timeoutSec: 40  connectionDraining:    drainingTimeoutSec: 60

如需查看可使用 BackendConfig 设置的特性的完整列表，请参阅特性表的 BackendConfig 部分。

运行以下命令以创建 BackendConfig：

kubectl apply -f my-backendconfig.yaml

创建 Service

即使 Service 具有多个端口，BackendConfig 也会与单个 Service-Port 组合相对应。每个端口都可以与单个 BackendConfig CRD 相关联。如果 Ingress 引用了某一 Service 端口，并且该 Service 端口与 BackendConfig 相关联，则 HTTP(S) 负载平衡后端服务会从 BackendConfig 中获取其部分配置。

以下是一个名为 my-service.yaml 的 Service 清单文件示例：

# my-service.yamlapiVersion: v1kind: Servicemetadata:  name: my-service  labels:    purpose: bsc-config-demo  annotations:    cloud.google.com/backend-config: '{'ports': {'80':'my-backendconfig'}}'    cloud.google.com/neg: '{'ingress': true}'spec:  type: ClusterIP  selector:    purpose: bsc-config-demo  ports:  - port: 80    protocol: TCP    targetPort: 8080

cloud.google.com/backend-config 注释指定端口与 BackendConfig 对象之间的映射。在 my-service.yaml 中：

• 具有 purpose: bsc-config-demo 标签的任何 Pod 都是 Service 的成员。
• Service 的 TCP 端口 80 与名为 my-backendconfig 的 BackendConfig 相关联。这是由 cloud.google.com/backend-config 注释指定的。
• 发送到 Service 端口 80 的请求被转发到端口 8080 上的一个成员 Pod。

要创建 Service，请运行以下命令：

kubectl apply -f my-service.yaml

创建 Ingress

以下是一个名为 my-ingress.yaml. 的 Ingress 清单。在此示例中，传入请求路由到名为 my-service 的 Service 的端口 80。

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: my-ingressspec:  rules:  - http:      paths:      - path: /*        pathType: ImplementationSpecific        backend:          service:            name: my-service            port:              number: 80

要创建 Ingress，请运行以下命令：

kubectl apply -f my-ingress.yaml

等待几分钟，让 Ingress 控制器配置 HTTP(S) 负载平衡和关联的后端服务。此操作完成后，将 Ingress 配置为使用 40 秒超时，并将连接排空超时设置为 60 秒。

验证后端服务属性

您可以通过 BackendConfig 验证是否已应用正确的负载平衡器设置。为此，请确定 Ingress 已部署的后端服务并检查其设置，以验证它们是否与 Deployment 清单匹配。

首先，描述列出与 Ingress 关联的后端服务的 my-ingress 资源和过滤条件。例如：

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

您将看到如下所示的输出：

ingress.kubernetes.io/backends: '{'k8s1-27fde173-default-my-service-80-8d4ca500':'HEALTHY','k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c':'HEALTHY'}

输出会提供后端服务的相关信息。例如，此注释包含两个后端服务：

• 'k8s1-27fde173-default-my-service-80-8d4ca500':'HEALTHY' 针对与 my-service Kubernetes Service 关联的后端服务提供相关信息。
• 'k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c':'HEALTHY' 针对与默认后端（404 服务器）关联的后端服务提供相关信息。

接下来，使用 gcloud 检查与 my-service 关联的后端服务。过滤 'drainingTimeoutSec' 和 'timeoutSec'，以确认是否已在 Google Cloud 负载平衡器控制层面中设置它们。例如：

# Optionally, set a variableexport BES=k8s1-27fde173-default-my-service-80-8d4ca500# Filter for drainingTimeoutSec and timeoutSecgcloud compute backend-services describe ${BES} --global | grep -e 'drainingTimeoutSec' -e 'timeoutSec'

输出：

  drainingTimeoutSec: 60  timeoutSec: 40

如果在输出中看到 drainingTimeoutSec 和 timeoutSec，则确认它们的值已通过 BackendConfig 正确设置。

清理

为了防止您的帐号产生不必要的费用，请删除您为此练习创建的 Kubernetes 对象：

kubectl delete ingress my-ingresskubectl delete service my-servicekubectl delete backendconfig my-backendconfigkubectl delete deployment my-deployment

BackendConfig 限制

BackendConfig 存在以下限制：

• 一个（Service，端口）对只能使用一个 BackendConfig，即使多个 Ingress 对象都引用该（Service，端口）对也是如此。这意味着，引用相同（Service，端口）对的所有 Ingress 对象都必须对 Cloud Armor、IAP 和 Cloud CDN 使用相同的配置。
• 无法为同一 HTTP(S) 负载平衡后端服务启用 IAP 和 Cloud CDN。这意味着您不能在同一 BackendConfig 中同时配置 IAP 和 Cloud CDN。
• 您必须使用 kubectl 1.7 或更高版本与 BackendConfig 进行交互。

移除在 FrontendConfig 或 BackendConfig 中指定的配置

要撤消某个 Ingress 特性，必须在 FrontendConfig 或 BackendConfig CRD 中明确停用特性配置。Ingress 控制器仅与这些 CRD 中指定的配置协调。

要清除或停用先前启用的配置，请将字段的值设置为空字符串 ('') 或布尔值 false，具体取决于字段类型。

以下 BackendConfig 清单会停用 Google Cloud Armor 安全政策和 Cloud CDN：

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name: my-backendconfigspec:  cdn:    enabled: false  securityPolicy:    name: ''

删除 FrontendConfig 或 BackendConfig

FrontendConfig

BackendConfig

如需删除 FrontendConfig，请按照下列步骤进行操作：

1. 从 Ingress 清单中的 networking.gke.io/v1beta1.FrontendConfig 注释中移除 FrontendConfig 的名称。
2. 将更改后的 Ingress 清单应用到集群。例如，使用 kubectl apply。
3. 删除 FrontendConfig。例如，使用 kubectl delete frontendconfig config my-frontendconfig。
4. 重要提示：在从 networking.gke.io/v1beta1.FrontendConfig 注释中移除 FrontendConfig 对象的名称并应用更新后的 Ingress 清单之前，请勿删除该对象。否则，配置不会从 HTTP(S) 负载平衡后端服务中移除。此外，您还会在 Ingress 对象上看到表现为 Kubernetes 事件的错误。

问题排查

找不到 BackendConfig

如果在 Service 注释中指定了 Service 端口的 BackendConfig，但找不到实际 BackendConfig 资源，那么就会发生这种错误。 如果您尚未创建 BackendConfig 资源，或在错误的命名空间中创建了该资源，或在 Service 注释中拼错了引用，那么就会发生这种情况。

要评估 Kubernetes 事件，请运行以下命令：

kubectl get event

以下类型的输出表示找不到 BackendConfig：

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service 'default/my-service':
no BackendConfig for service port exists

找不到 Ingress 安全政策

Ingress 对象创建完毕后，如果安全政策未与负载平衡器服务正确关联，请评估 Kubernetes 事件以了解是否存在配置错误。如果 BackendConfig 指定了不存在的政策，则系统会定期发出警告事件。如需解决此问题，请确保在 BackendConfig 中按名称指定正确的安全政策。

要评估 Kubernetes 事件，请运行以下命令：

kubectl get event

以下类型的输出表示找不到安全政策：

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy 'my-policy' does not exist.

创建内部 Ingress 资源时找不到 NEG

当您在 GKE 中创建内部 Ingress 时，可能会发生以下错误：

Error syncing to GCP: error running backend syncing routine: googleapi: Error 404: The resource 'projects/PROJECT_ID/zones/ZONE/networkEndpointGroups/NEG' was not found, notFound

发生此错误的原因是内部 HTTP(S) 负载均衡的 Ingress 需要网络端点组 (NEG) 作为后端。

在共享 VPC 环境或启用了网络政策的集群中，您必须将注释 cloud.google.com/neg: '{'ingress': true}' 添加到 Service 清单。

504 网关超时：上游请求超时

从 GKE 中的内部 Ingress 访问 Service 时，可能会发生以下错误：

HTTP/1.1 504 Gateway Timeout
content-length: 24
content-type: text/plain

upsteam request timeout

发生此错误是因为发送到内部 HTTP(S) 负载均衡器的流量通过代理专用子网范围内的 envoy 代理来代理。

您必须创建防火墙规则以允许来自代理专用子网范围的流量（在 Service 的 targetPort 上）。

错误 400：字段“resource.target”的值无效

从 GKE 中的内部 Ingress 访问 Service 时，可能会发生以下错误：

Error syncing to GCP:LB_NAME does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION_NAME/targetHttpProxies/LB_NAME. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.

发生此错误的原因是适用于内部 HTTP(S) 负载均衡的 Ingress 需要代理专用子网。

同步时出错：运行负载均衡器同步例程时出错：负载均衡器不存在

在 GKE 控制层面升级或修改 Ingress 对象时，可能会发生以下错误之一：

'Error during sync: error running load balancer syncing routine: loadbalancer
INGRESS_NAME does not exist: invalid ingress frontend configuration, please
check your usage of the 'kubernetes.io/ingress.allow-http' annotation.'

Error during sync: error running load balancer syncing routine: loadbalancer LOAD_BALANCER_NAME does not exist:
googleapi: Error 400: Invalid value for field 'resource.IPAddress':'INGRESS_VIP'. Specified IP address is in-use and would result in a conflict., invalid

如需解决这些问题，请尝试以下操作：

• 在 Ingress 清单的 tls 部分中添加 hosts 字段，然后删除 Ingress。等待 5 分钟，让 GKE 删除未使用的 Ingress 资源，然后重新创建 Ingress。如需了解详情，请参阅 Ingress 对象的主机字段。
• 还原您对 Ingress 所做的更改。然后，使用注释或 Kubernetes Secret 添加证书。

已知问题

无法通过 V1 Ingress 命名方案启用 HTTPS 重定向

您无法在 GKE 1.16.8-gke.12 及更低版本上创建的 GKE Ingress 资源上启用 HTTPS 重定向。您必须先重新创建 Ingress，然后才能启用 HTTPS 重定向；或者系统会创建一个错误事件，并且 Ingress 不会同步。

错误事件消息类似于以下内容：

Error syncing to GCP: error running load balancer syncing routine: loadbalancer lb-name does not exist: ensureRedirectUrlMap() = error: cannot enable HTTPS Redirects with the V1 Ingress naming scheme. Please recreate your ingress to use the newest naming scheme.

从 BackendConfig 中移除 Google Cloud Armor 安全政策字段

存在一个已知问题，即使用 v1beta1 API 更新 BackendConfig 资源会从其 Service 中移除活跃的 Google Cloud Armor 安全政策。此问题会影响以下 GKE 版本：

• 1.18.19-gke.1400 到 1.18.20-gke.5099
• 1.19.10-gke.700 到 1.19.14-gke.299
• 1.20.6-gke.700 到 1.20.9-gke.899

如果您未通过 BackendConfig 在 Ingress 资源上配置 Google Cloud Armor，则此问题不会影响您的集群。

对于通过 BackendConfig 配置 Google Cloud Armor 的 GKE 集群，强烈建议仅使用 v1 API 更新 BackendConfig 资源。将 BackendConfig 应用于使用 v1beta1 BackendConfig 资源的集群将会从其引用的 Service 中移除 Google Cloud Armor 安全政策。

为了缓解此问题，只能使用 v1 BackendConfig API 更新 BackendConfig。v1 BackendConfig 支持与 v1beta1 相同的所有字段，并且不做破坏性更改，因此可以透明地更新 API 字段。将所有活跃 BackendConfig 清单的 apiVersion 字段替换为 cloud.google.com/v1，不使用 cloud.google.com/v1beta1。以下示例清单描述了使用 v1 API 的 BackendConfig 资源：

  apiVersion: cloud.google.com/v1  kind: BackendConfig  metadata:    name: my-backend-config  spec:    securityPolicy:      name: 'ca-how-to-security-policy'

如果您有定期更新 BackendConfig 资源的 CI : 持续集成/CD : 持续交付系统或工具，请确保您在这些系统中使用 cloud.google.com/v1 API 组。

如果您已使用 v1beta1 API 更新了 BackendConfig，则您的 Google Cloud Armor 安全政策可能已被移除。您可以通过运行以下命令来确定是否发生了这种情况：

kubectl get backendconfigs -A -o json | jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | '(.namespace)/(.name)''

如果响应返回输出，则您的集群会受到问题的影响。此命令的输出将返回受此问题影响的 BackendConfig 资源 (<namespace>/<name>) 列表。如果输出为空，则说明由于该问题的出现，BackendConfig 尚未使用 v1beta1 API 更新了。BackendConfig 的任何未来更新都应仅使用 v1。

如果您的 Google Cloud Armor 安全政策已移除，您可以使用以下 Logging 查询来确定该政策何时被移除：

resource.type='gce_backend_service'
protoPayload.methodName='v1.compute.backendServices.setSecurityPolicy'
protoPayload.authenticationInfo.principalEmail:'container-engine-robot.iam.gserviceaccount.com'
protoPayload.response.status = 'RUNNING'
NOT protoPayload.authorizationInfo.permission:'compute.securityPolicies.use'

如果您的任何集群受到影响，则可以通过推送对使用 v1 API 的 BackendConfig 资源的更新来解决此问题。

将 GKE 控制平面升级到以下更新版本之一，该版本可以修补此问题并允许安全使用 v1beta1 BackendConfig 资源：

• 1.18.20-gke.5100 及更高版本
• 1.19.14-gke.300 及更高版本
• 1.20.9-gke.900 及更高版本