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.
Limitations
- Gateway limitations apply.
- You cannot use a FrontendConfig or a BackendConfig to configure a Gateway. You must use a Policy.
LBPolicy
andHealthCheckPolicy
resources can only be attached to av1
Service for single cluster Gateway and anet.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 ifenable
is set totrue
.sampleRate
is an optional field, but if it's configured thenenable: true
must also be set. Ifenable
is set totrue
andsampleRate
is not provided then GKE setsenable
tofalse
.
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 ofTIMEOUT
must be less than or equal to theINTERVAL
. Units are seconds. Each probe requires an HTTP 200 (OK) response code to be delivered before the probe timeout.HEALTHY_THRESHOLD
andUNHEALTHY_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 theport
andportName
fields. If neitherport
orportName
are specified, this field defaults toUSE_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 acontainerPort
of a serving Pods, even if thecontainerPort
is referenced by atargetPort
of the Service. You are not limited tocontainerPorts
referenced by a Service'stargetPort
.PORT_NAME
: specifies the port name as defined in InstanceGroup.NamedPort.name. If bothport
andportName
are defined, Google Cloud considers theport
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 useNONE
orPROXY_V1
. Defaults toNONE
.
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.