This page explains how Ingress for external Application Load Balancers works inGoogle Kubernetes Engine (GKE). You can also learnhow to set up and use Ingress forExternal Load Balancing.

For general information about using load balancing in GKE, seeIngress for external Application Load Balancers.

Google Kubernetes Engine (GKE) networking is built uponCloud Load Balancing. WithCloud Load Balancing, a single anycast IP address enables routing to determinethe lowest cost path to the closest Google Cloud load balancer.

Support for Google Cloud features

You can use a BackendConfig to configure an external Application Load Balancer to use featureslike:

• Google Cloud Armor
• Health checks
• Cloud CDN
• Identity-Aware Proxy

BackendConfig is a custom resource that holds configuration information forGoogle Cloud features. To learn more about supported features, seeIngress configuration.

Support for WebSocket

With external Application Load Balancers, the WebSocket protocol works without anyconfiguration.

If you intend to use the WebSocket protocol, you might want to use a timeoutvalue larger than the default 30 seconds. For WebSocket traffic sent through aGoogle Cloud external Application Load Balancer, the backend service timeout is interpreted asthe maximum amount of time that a WebSocket connection can remain open, whetheridle or not.

To set the timeout value for a backendservice configured through Ingress, create a BackendConfig object, and use thebeta.cloud.google.com/backend-config annotation in your Service manifest.

For configuration information, seeBackend response timeout.

Static IP addresses for HTTPS load balancers

When you create an Ingress object, you get a stable external IP address thatclients can use to access your Services and in turn, your running containers.The IP address is stable in the sense that it lasts for the lifetime of theIngress object. If you delete your Ingress and create a new Ingress from thesame manifest file, you are not guaranteed to get the same external IP address.

If you want a permanent IP address that stays the same across deletingyour Ingress and creating a new one, you must reserve a globalstatic external IP address.Then in your Ingress manifest, include an annotation that gives the name of yourreserved static IP address. If you modify an existing Ingress to use a static IPaddress instead of an ephemeral IP address, GKE might change theIP address of the load balancer when GKE re-creates theforwarding rule of the load balancer.

For example, suppose you have reserved a global static external IP address namedmy-static-address. In your Ingress manifest, include akubernetes.io/ingress.global-static-ip-name annotation as shown here:

apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:my-ingressannotations:kubernetes.io/ingress.global-static-ip-name:my-static-address

Setting up HTTPS (TLS) between client and load balancer

An HTTP(S) load balancer acts as a proxy between your clients and yourapplication. If you want to accept HTTPS requests from your clients, the loadbalancer must have a certificate so it can prove its identityto your clients. The load balancer must also have a private key to complete theHTTPS handshake.

When the load balancer accepts an HTTPS request from a client, the trafficbetween the client and the load balancer is encrypted using TLS. However, theload balancer terminates the TLS encryption, and forwards the request withoutencryption to the application. For information about how to encrypt trafficbetween the load balancer and your application, seeHTTPS between load balancer and your application.

You can useGoogle-managed SSL certificates orcertificates that you manage yourself. For more information about creating anIngress that uses Google-managed certificates, seeUsing Google-managed SSLcertificates.

To provide an HTTP(S) load balancer with a certificate and key that you createdyourself,create a Kubernetes Secretobject. The Secret holds the certificate and key. Add the Secret to thetls field of yourIngress manifest, as in the following example:

apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:my-ingress-2spec:tls:-secretName:SECRET_NAMErules:-http:paths:-path:/*pathType:ImplementationSpecificbackend:service:name:SERVICE_NAMEport:number:60000

This manifest includes the following values:

• SECRET_NAME: the name of the Secret you created.
• SERVICE_NAME: the name of your backend service.

Changes to Secrets are picked up periodically so if you modify the data insideof the Secret, it will take a max of 10 minutes for those changes to be appliedto the load balancer.

For more information, seeUsing multiple SSL certificates in HTTPS load balancing withIngress.

To secure HTTPS encrypted Ingress for your GKE clusters, see exampleSecure Ingress.

Disabling HTTP

If you want all traffic between the client and the HTTP(S) load balancer to useHTTPS, you can disable HTTP by including thekubernetes.io/ingress.allow-httpannotation in your Ingress manifest. Set the value of the annotation to"false".

apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:my-ingress-2annotations:kubernetes.io/ingress.allow-http:"false"spec:tls:-secretName:SECRET_NAME...

This manifests includes theSECRET_NAME that is the name ofthe Secret you created.

As an alternative to using Kubernetes Secrets to provide certificates to theload balancer for HTTP(S) termination, you can use certificates previouslyuploaded to your Google Cloud project. For more information, seeUsing pre-shared certificatesandUsing multiple SSL certificates in HTTPS load balancing with Ingress.

HTTPS (TLS) between load balancer and your application

An HTTP(S) load balancer acts as a proxy between your clients and yourapplication. Clients can use HTTP or HTTPS to communicate with the loadbalancer proxy. The connection from the load balancer proxy toyour application uses HTTP by default. However, if your application, running in aGKE Pod, is capable of receiving HTTPS requests, you canconfigure the load balancer to use HTTPS when it forwards requests to yourapplication.

To configure the protocol used between the load balancer and your application,use thecloud.google.com/app-protocols annotation in your Service manifest.This Service manifest must includetype: NodePort unless you're usingcontainer native load balancing.If using container native load balancing, use thetype: ClusterIP.

The following Service manifest specifies two ports. The annotation says thatwhen an HTTP(S) load balancer targets port 80 of the Service, it should useHTTP. And when the load balancer targets port 443 of the Service, it shoulduse HTTPS.

The Service manifest must include aname value in the port annotation. You canonly edit the Service port by referring to its assignedname, not by itstargetPort value.

apiVersion:v1kind:Servicemetadata:name:my-service-3annotations:cloud.google.com/app-protocols:'{"my-https-port":"HTTPS","my-http-port":"HTTP"}'spec:type:NodePortselector:app:metricsdepartment:salesports:-name:my-https-portport:443targetPort:8443-name:my-http-portport:80targetPort:50001

• Configure an external Application Load Balancer bycreating a Deployment, Service, and Ingress.

• Learn how toexpose applications using Services.

• Do thetutorial on setting up an external Application Load Balancer with Ingress.

• Read an overview ofnetworking in GKE.

• Learn more about configuringIngress features.

• Learn how to enableHTTP to HTTPS redirects.