Introduction

On GKE, request timeouts for the built-in Google Cloud load balancer are not usually set directly on the Ingress object with a generic timeout annotation. The standard path is to create a BackendConfig and attach it to the Service behind the Ingress. Once that is clear, the configuration becomes straightforward and much less confusing than mixing advice for GKE, NGINX Ingress, and other controllers.

The GKE-Specific Model

A common mistake is to search for a single universal "Ingress timeout annotation" and apply examples from a different ingress controller. GKE's default external HTTP(S) Ingress uses Google Cloud load balancing, so the backend service settings are configured through GKE-specific resources.

For request timeout behavior, the key field is timeoutSec in a BackendConfig.

Create A BackendConfig

Here is a minimal example that sets a 10-minute backend timeout.

1apiVersion: cloud.google.com/v1
2kind: BackendConfig
3metadata:
4  name: app-backendconfig
5spec:
6  timeoutSec: 600

This tells the Google Cloud backend service how long it may wait for the backend before timing out the request.

Attach It To The Service

The BackendConfig is not referenced directly by the Ingress. It is attached to the Service through an annotation.

1apiVersion: v1
2kind: Service
3metadata:
4  name: app-service
5  annotations:
6    cloud.google.com/backend-config: '{"default": "app-backendconfig"}'
7spec:
8  selector:
9    app: app
10  ports:
11    - port: 80
12      targetPort: 8080
13  type: NodePort

That service is then used by the Ingress in the normal way.

Example Ingress

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5spec:
6  rules:
7    - host: example.com
8      http:
9        paths:
10          - path: /
11            pathType: Prefix
12            backend:
13              service:
14                name: app-service
15                port:
16                  number: 80

Once the Ingress points to the annotated service, GKE creates or updates the underlying backend service with the timeout configuration.

Verify The Result

After applying the manifests, give GKE time to reconcile. Then inspect both Kubernetes and Google Cloud state.

From Kubernetes:

kubectl describe ingress app-ingress
kubectl describe service app-service
kubectl get backendconfig app-backendconfig -o yaml

From Google Cloud, you can also inspect the backend service if needed:

gcloud compute backend-services list

That helps confirm whether the timeout setting actually propagated.

Distinguish Request Timeout From Other Timeouts

timeoutSec is not the only timeout in the path. Depending on the workload, you may also care about:

• client-side timeouts
• application server timeouts
• health check behavior
• connection draining and backend shutdown timing

Changing only the GKE backend timeout will not fix every long-request problem if the application or client closes earlier.

Do Not Mix Controller Documentation

A lot of confusion comes from mixing controller-specific guides. An annotation that works for NGINX Ingress may do nothing on GKE's native controller. If the cluster uses a different ingress controller than the default GKE one, the correct timeout mechanism may be completely different.

So before copying YAML from the internet, confirm which controller is actually serving the Ingress.

Common Pitfalls

• Putting timeout annotations on the Ingress copied from another controller such as NGINX and expecting GKE to honor them.
• Creating a BackendConfig but forgetting to attach it to the Service.
• Updating the YAML and then checking too quickly before GKE has finished reconciling the backend service.
• Treating timeoutSec as the only timeout in the request path when the client or application server may still terminate earlier.
• Forgetting that the service behind a GKE external Ingress is commonly a NodePort service.

Summary

• On GKE's native Ingress, request timeout is typically configured through BackendConfig.spec.timeoutSec.
• Attach the BackendConfig to the backend Service, not directly to the Ingress.
• Use the Ingress normally after the service is annotated.
• Verify the change after reconciliation rather than assuming the manifests applied instantly.
• Always match the timeout method to the actual ingress controller in use.