Health checks overview

Google Cloud offers configurable health checks for Google Cloud load balancer backends, Cloud Service Mesh backends, and application-based autohealing for managed instance groups. This document covers key health checking concepts.

Unless otherwise noted, Google Cloud health checks are implemented by dedicated software tasks that connect to backends according to parameters specified in a health check resource. Each connection attempt is called a probe. Google Cloud records the success or failure of each probe.

Based on a configurable number of sequential successful or failed probes, an overall health state is computed for each backend. Backends that respond successfully for the configured number of times are considered healthy. Backends that fail to respond successfully for a separately configurable number of times are unhealthy.

The overall health state of each backend determines eligibility to receive new requests or connections. You can configure the criteria that define a successful probe. This is discussed in detail in the section How health checks work.

Health checks implemented by dedicated software tasks use special routes that aren't defined in your Virtual Private Cloud (VPC) network. For more information, see Paths for health checks.

Health check categories, protocols, and ports

Health checks have a category and a protocol. The two categories are health checks and legacy health checks and their supported protocols are as follows:

• Health checks

  • Regional (gRPC, gRPC (with TLS), TCP, SSL, HTTP, HTTPS, or HTTP/2)
  • Global (gRPC, gRPC (with TLS), TCP, SSL, HTTP, HTTPS, or HTTP/2)

• Legacy health checks:

  • Legacy global (HTTP)
  • Legacy global (HTTPS)

The protocol and port determine how health check probes are done. For example, a health check can use the HTTP protocol on TCP port 80, or it can use the TCP protocol for a named port in an instance group.

You cannot convert a legacy health check to a health check, and you cannot convert a health check to a legacy health check.

Select a health check

Health checks must be compatible with the type of load balancer (or Cloud Service Mesh) and the backend types. The factors to consider when you select a health check are as follows:

• Category: health check or legacy health check. Only target pool-based regional external passthrough Network Load Balancers require legacy health checks. For all other products, you'll use regular health checks.
• Protocol: protocol that Google Cloud uses to probe the backends. It's best to use a health check (or legacy health check) whose protocol matches the protocol used by the load balancer's backend service or target pool. However, the health check protocols and load balancer protocols do not need to be the same.
• Port specification: ports that Google Cloud uses with the protocol. You must specify a port for your health check. Health checks have two port specification methods: --port and --use-serving-port. For legacy health checks, there is one method: --port. For more information about health check port requirements per load balancer, see Port specification flags.

The next section describes valid health check selections for each type of load balancer and backend.

Load balancer guide

This table shows the supported health check category and scope for each load balancer type.

Additional usage notes

• For backend instance groups, zonal NEGs with GCE_VM_IP endpoints, and zonal NEGs with GCE_VM_IP_PORT endpoints, probers only attempt to connect to VM instances (or VM instances that contain endpoints) if the VMs are running. Probers don't attempt to connect to instances (or VM instances that contain endpoints) if they are stopped.

• A target pool-based regional external passthrough Network Load Balancer must use a legacy HTTP health check. It cannot use a legacy HTTPS health check or any non-legacy health check. If you use a target pool-based regional external passthrough Network Load Balancer to balance TCP traffic, you need to run an HTTP service on the VMs being load balanced so that they can respond to health check probes.
  
  For almost all other load balancer types, you must use regular, non-legacy health checks where the protocol matches the load balancer's backend service protocol.

• For backend services that use the gRPC protocol, use only gRPC or TCP health checks. Don't use HTTP(S) or HTTP/2 health checks.

• Certain Envoy-based load balancers that use hybrid NEG backends don't support gRPC health checks. For more information, see the Hybrid NEGs overview.

Health checking with Cloud Service Mesh

Note the following differences in behavior when you're using health checks with Cloud Service Mesh.

• With Cloud Service Mesh, health checking behavior for network endpoints of the type INTERNET_FQDN_PORT and NON_GCP_PRIVATE_IP_PORT differs from health checking behavior for other types of network endpoints. Instead of using the dedicated software tasks, Cloud Service Mesh programs Envoy proxies to perform health checks for internet NEGs (INTERNET_FQDN_PORT endpoints) and hybrid NEGs (NON_GCP_PRIVATE_IP_PORT endpoints).

  Envoy supports the following protocols for health checking:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

• When Cloud Service Mesh is integrated with Service Directory and you bind a Service Directory service to a Cloud Service Mesh backend service, you cannot set a health check on the backend service.

Probe IP ranges

Google Cloud requires that you create the necessary ingress allow firewall rules to permit traffic from probers to your backends or other resources. Note the following when you create these firewall rules:

• The probe IP ranges are a complete set of possible IP addresses used by Google Cloud probers. If you use tcpdump or a similar tool, you might not observe traffic from all IP addresses in all probe IP ranges. As a best practice, create ingress firewall rules that allow all of the probe IP ranges as sources. Google Cloud can implement new probers automatically without notification.

• As a best practice, limit these rules to just the protocols and ports that match those used by your health checks.

If you don't have ingress allow firewall rules that permit health check probers to connect to your load balancer backends, the implied deny ingress firewall action blocks traffic, causing your backends to be unhealthy. For more information, see Firewall policies and rules.

Probe IP ranges for GFE-based load balancer backends

External Application Load Balancers and external proxy Network Load Balancers that use Google Front Ends (GFEs) are:

• Global external Application Load Balancers
• Classic Application Load Balancers
• Global external proxy Network Load Balancers
• Classic proxy Network Load Balancers

Health checks for backends of these load balancers come from the IP address ranges in the following table:

Probe IP ranges for Cloud Service Mesh backends

Health checks for Cloud Service Mesh backends come from the IP address ranges in the following table: