Configure Gateway resources using Policies

Standard

---

Preview

The GKE Gateway controller for multi-cluster networking, multi-cluster Gateways, and the new GatewayClasses gke-l7-global-external-managed and gke-l7-global-external-managed-mc are currently in the Preview launch stage which carries no SLA or technical support. If you have questions about multi-cluster Gateways, Global external HTTP(S) load balancer with the GKE Gateway controller or feedback you want to share, contact [e-mail].

This page shows you how to configure the load balancer that GKE creates when you deploy a Gateway in a Google Kubernetes Engine (GKE) cluster.

When you deploy a Gateway in a GKE cluster, the GatewayClass configuration determines which load balancer GKE creates. This managed load balancer is pre-configured with default settings that you can modify using a Policy.

You can only attach Policies to Services or ServiceImports. After you apply or modify a Policy, you do not need to delete or recreate your Gateway, Route, or Service resources.

Before you begin

Before you start, make sure you have performed the following tasks:

• Enable the Google Kubernetes Engine API.
Enable Google Kubernetes Engine API
• If you want to use the Google Cloud CLI for this task, install and then initialize the gcloud CLI.
  Note: For existing gcloud CLI installations, make sure to set the compute/region and compute/zone properties. By setting default locations, you can avoid errors in gcloud CLI like the following: One of [--zone, --region] must be supplied: Please specify location.

• Deploy an internal or external Gateway.

Limitations

• Gateway limitations apply.
• You cannot use a FrontendConfig or a BackendConfig to configure a Gateway. You must use a Policy.
• LBPolicy and HealthCheckPolicy resources can only be attached to a v1 Service for single cluster Gateway and a net.gke.io/v1 ServiceImport for multi cluster Gateways.

Configure Backend Service timeout

The following LBPolicy manifest specifies a backend service timeout period of 40 seconds. The timeoutSec field defaults to 30 seconds.

apiVersion: networking.gke.io/v1
kind: LBPolicy
metadata:
  name: lb-policy
spec:
  default:
    timeoutSec: 40
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Configure session affinity

You can configure session affinity based on the following criteria:

• Client IP address
• Generated cookie

The following LBPolicy manifest specifies a session affinity based on the client IP address:

apiVersion: networking.gke.io/v1
kind: LBPolicy
metadata:
  name: lb-policy
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: ""
    kind: Service
    name: lb-service

The following LBPolicy manifest specifies a session affinity based on a generated cookie and configures the cookies TTL to 50 seconds:

apiVersion: networking.gke.io/v1
kind: LBPolicy
metadata:
  name: lb-policy
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50
  targetRef:
    group: ""
    kind: Service
    name: lb-service

You can use the following options for sessionaffinity.Type: CLIENT_IP, CLIENT_IP_PROTO, CLIENT_IP_PORT_PROTO, GENERATED_COOKIE, HEADER_FIELD, HTTP_COOKIE, NONE.

Configure connection draining timeout

You can configure connection draining timeout using an LBPolicy. Connection draining timeout is the time, in seconds, to wait for connections to drain. The timeout duration can be from 0 to 3600 seconds. The default value is 0, which also disables connection draining.

The following LBPolicy manifest specifies a connection draining timeout of 60 seconds:

apiVersion: networking.gke.io/v1
kind: LBPolicy
metadata:
  name: lb-policy
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: ""
    kind: Service
    name: lb-service

For the specified duration of the timeout, GKE waits for existing requests to the removed backend to complete. The load balancer does not send new requests to the removed backend. After the timeout duration is reached, GKE closes all remaining connections to the backend.

Configure HTTP access logging

Gateway can log all HTTP requests from clients to Cloud Logging.

You can enable and disable access logging using an LBPolicy. You can also configure the access logging sampling rate.

To configure access logging, use the logging field in your LBPolicy. If logging is omitted, access logging is disabled by default.

The following LBPolicy manifest enables access logging and sets the sample rate to 50% of the HTTP requests for a given Service resource:

apiVersion: networking.gke.io/v1
kind: LBPolicy
metadata:
  name: lb-policy
spec:
  default:
    logging:
      enabled: true
      sampleRate: 500000
  targetRef:
    group: ""
    kind: Service
    name: lb-service

This manifest has the following fields:

• enable: true: enables access logging. Logs are available in Logging.
• sampleRate: 500000: specifies that 50% of packets are logged. You can use a value between 0 and 1,000,000. GKE converts this value to a floating point value in the range [0, 1] by dividing by 1,000,000. This field is only relevant if enable is set to true. sampleRate is an optional field, but if it's configured then enable: true must also be set. If enable is set to true and sampleRate is not provided then GKE sets enable to false.

Configure health checks

You can use a HealthCheckPolicy to control the load balancer health check settings. To learn more about how GKE Ingress deploys health checks, see Ingress health checks.

For healthCheck parameters, Google Cloud creates a unique health check for each backend service for each GKE Service.

The following HealthCheckPolicy manifest shows all the fields available when configuring a health check policy:

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
spec:
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Replace the following:

• INTERVAL: specifies the check-interval, in seconds, for each health check prober. This is the time from the start of one prober's check to the start of its next check. If you omit this parameter, the Google Cloud default is 5 seconds. For more information, see Multiple probes and frequency.
• TIMEOUT: specifies the amount of time that Google Cloud waits for a response to a probe. The value of TIMEOUT must be less than or equal to the INTERVAL. Units are seconds. Each probe requires an HTTP 200 (OK) response code to be delivered before the probe timeout.
• HEALTHY_THRESHOLD and UNHEALTHY_THRESHOLD: specifies the number of sequential connection attempts that must succeed or fail, for at least one prober, to change the health state from healthy to unhealthy or unhealthy to healthy. If you omit one of these parameters, the Google Cloud default is 2.
• PROTOCOL: specifies a protocol used by probe systems for health checking. The BackendConfig only supports creating health checks using the HTTP, HTTPS, or HTTP2 protocols. For more information, see Success criteria for HTTP, HTTPS, and HTTP/2. This parameter is required.
• ENABLED: specifies if logging is enabled or disabled.
• PORT_SPECIFICATION: specifies if the health check uses a fixed port (USE_FIXED_PORT), named port (USE_NAMED_PORT) or serving port (USE_SERVING_PORT). If not specified, the health check follows the behavior specified in the port and portName fields. If neither port or portName are specified, this field defaults to USE_SERVING_PORT.
• PATH: specifies the request-path to which the probe system should connect for HTTP, HTTPS, or HTTP2 health checks. If you omit this parameter, the Google Cloud default is /.
• PORT: A HealthCheckPolicy only supports specifying the load balancer health check port by using a port number. If you omit this parameter, the Google Cloud default is 80. Because the load balancer sends probes to the Pod's IP address directly, you should select a port matching a containerPort of a serving Pods, even if the containerPort is referenced by a targetPort of the Service. You are not limited to containerPorts referenced by a Service's targetPort.
• PORT_NAME: specifies the port name as defined in InstanceGroup.NamedPort.name. If both port and portName are defined, Google Cloud considers the port value first.
• REQUEST_PATH: specifies the request path of the health check request. If not specified or left empty, defaults to /.
• RESPONSE: specifies the bytes to match against the beginning of the response data. If not specified or left empty, GKE interprets any response as healthy. The response data can only be ASCII.
• PROXY_HEADER: specifies the proxy header type. You can use NONE or PROXY_V1. Defaults to NONE.

For more information about HealthCheckPolicy fields, see the healthChecks reference.

What's next

• Learn more about the Gateway controller.
• Learn how to reference a Gateway from a resource.