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.
- Deploy an internal or external Gateway.
- Gateway limitations apply.
- You cannot use a FrontendConfig or a BackendConfig to configure a Gateway. You must use a Policy.
HealthCheckPolicyresources can only be attached to a
v1Service for single cluster Gateway and a
net.gke.io/v1ServiceImport 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
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
enableis set to
sampleRateis an optional field, but if it's configured then
enable: truemust also be set. If
enableis set to
sampleRateis not provided then GKE sets
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.
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
TIMEOUTmust 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.
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
portNamefields. If neither
portNameare specified, this field defaults to
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
containerPortof a serving Pods, even if the
containerPortis referenced by a
targetPortof the Service. You are not limited to
containerPortsreferenced by a Service's
PORT_NAME: specifies the port name as defined in InstanceGroup.NamedPort.name. If both
portNameare defined, Google Cloud considers the
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
PROXY_V1. Defaults to
For more information about HealthCheckPolicy fields, see the