Creating Health Checks

Google Cloud (Google Cloud) provides health checking mechanisms that determine whether VM instances respond properly to traffic. This document describes how to create and use health checks for load balancers.

This page assumes that you are familiar with Health Check Concepts and that you have an understanding of Google Cloud firewall rules.

Health check categories, protocols, and ports

Google Cloud organizes health checks by category and protocol.

There are two health check categories: health checks and legacy health checks. Each category supports a different set of protocols and a means for specifying the port used for health checking.

Most load balancers use non-legacy health checks, but Network Load Balancing requires that you use legacy health checks. Refer to Selecting a health check on the Health Checks Concepts page to determine the appropriate category, protocol, and port specification method.

The protocol you select for a health check is not required to match the protocol used by the load balancer, and in some cases, it cannot. Refer to Protocols and load balancers for more information.

The term "health check" does not refer to legacy health checks. Legacy health checks are explicitly called "legacy health checks" in this document.

Creating health checks

Google Cloud allows you to create or select a health check when you complete the load balancer's backend configuration in the Cloud Console.

You can also create a health check independently of load balancer configuration in the Cloud Console. This is useful if you need to create your health check first, or if you need to use a health check for multiple load balancers. You can create a health check using the Cloud Console, the gcloud command-line tool, or the REST APIs. After reviewing the background information in this section, continue to Creating and modifying health checks for instructions.

Network load balancers must use legacy health checks, which you can create or select when you complete the network load balancer's backend configuration in the Cloud Console. To create a legacy health check independently, you must use either the gcloud command-line tool or the REST APIs. Refer to legacy health checks for more information.

Flags used by all health checks

The following flags are common to all health checks, regardless of protocol:

gcloud compute health-checks create PROTOCOL HEALTH_CHECK_NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    ...additional flags

Where:

• PROTOCOL defines the protocol used for the health check. Valid options are http, https, http2, ssl, and tcp.
• HEALTH_CHECK_NAME is the name of the health check. Within a given project, each health check must have a unique name.
• DESCRIPTION is an optional description.
• CHECK_INTERVAL is the amount of time from the start of one health check probe system's connection to the start of the next one. Units are seconds. If omitted, Google Cloud uses a value of 5s (5 seconds).
• TIMEOUT is the amount of time that Google Cloud waits for a response to a probe. The value of TIMEOUT must be less than or equal to the CHECK_INTERVAL. Units are seconds. If omitted, Google Cloud uses a value of 5s (5 seconds).
• HEALTHY_THRESHOLD and UNHEALTHY_THRESHOLD specify the number of sequential probes that must succeed or fail for the VM instance to be considered healthy or unhealthy. If either is omitted, Google Cloud uses a default threshold of 2.
• ...additional flags are other flags for specifying ports and options specific to the PROTOCOL. These flags are discussed in the following sections.

Port specification flags

Beta

This product or feature is in a pre-release state and might change or have limited support. For more information, see the product launch stages.

In addition to a protocol, you must specify a port for a health check. The way you specify the port depends on the type of load balancer and the type of backends used by its backend service. The following table shows port specification options for valid load balancer and backend combinations. As used in the table, the term instance group refers to unmanaged instance groups, managed zonal instance groups, or managed regional instance groups.

Health checks can only use one type of port specification.

Load balancer	Backend type	Port specification
Internal TCP/UDP Load Balancing	Instance Groups	Use one of these options^1: • --port: Specify a port by number, from 1 to 65535 • --port-name: Specify any named port exported by an instance group You cannot use the --use-serving-port flag for a health check associated with an internal load balancer because backend services for internal load balancers lack a port specification of any kind.
Internal HTTP(S) Load Balancing TCP Proxy Load Balancing SSL Proxy Load Balancing HTTP(S) Load Balancing	Network Endpoint Groups	Use one of these options^1: • --port: Specify a port by number, from 1 to 65535 • --use-serving-port^2: Use the port specified by each endpoint in the network endpoint group.
	Instance Groups	Use one of these options^1: • --port: Specify a port by number, from 1 to 65535 • --port-name: Specify any named port exported by an instance group • --use-serving-port^2: Use the same instance group named port that the backend service is configured to use.

¹Port specification combinations are resolved in the following way:

• If --use-serving-port is specified, neither --port nor --port-name can be specified.
• If both --port and --port-name are specified, --port prevails.
• If none of the three is specified, the default is: --port=80

²Beta: You must use the following beta gcloud commands if you need --use-serving-port:

• gcloud beta compute health-checks create
• gcloud beta compute health-checks update

Optional flags for HTTP, HTTPS, and HTTP/2 health checks

In addition to the common flags and port specification, you can use the following optional flags for HTTP, HTTPS, and HTTP/2 health checks. This example creates a HTTP health check named hc-http-port-80 using port 80 with default interval, timeout, and health threshold criteria.

gcloud compute health-checks create http hc-http-port-80 \
    --description="Simple HTTP port 80 health check" \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2 \
    --port=80 \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE

• The protocol can be http (in this example), https, or http2.
• HOST allows you to provide a host HTTP header. If omitted, the IP address of the load balancer's forwarding rule is used.
• PROXY_HEADER must be one of NONE or PROXY_V1. If omitted, Google Cloud uses NONE. The value of PROXY_V1 adds the header PROXY UNKNOWN\r\n.
• REQUEST_PATH specifies the URL path that Google Cloud uses when sending health check requests. If omitted, the health check request is sent to /.
• RESPONSE defines an optional expected response. Response strings must follow these rules:
  • The response string must consist of ASCII letters, numbers, and spaces.
  • The response string can be up to 1,024 characters long.
  • Wildcard matching is not supported.
  • Content-based checking does not support inversion; for example, operators such as ! in HAProxy are not supported.

If Google Cloud finds the expected response string anywhere in the first 1,024 bytes of the received response body, and if the HTTP status is 200 (OK), the probe is considered successful.

The --request-path and --response flags modify the success criteria for the health check probe.

Optional flags for SSL and TCP health checks

In addition to the common flags and port specification, you can use the following optional flags for SSL and TCP health checks. This example creates a TCP health check named hc-tcp-3268 using port 3268 with default interval, timeout, and health threshold criteria.

gcloud compute health-checks create tcp hc-tcp-3268 \
    --description="Health check: TCP 3268" \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2 \
    --port=3268 \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING

• The protocol can be tcp (in this example) or ssl.
• PROXY_HEADER must be one of NONE or PROXY_V1. If omitted, Google Cloud uses NONE. The value of PROXY_V1 adds the header PROXY UNKNOWN\r\n.
• REQUEST_STRING: You can provide a string, up to 1,024 ASCII characters long, to send once the TCP or SSL session has been established.
• RESPONSE_STRING: You can provide a string, up to 1,024 ASCII characters long, for the expected response.

The --request and --response flags modify the success criteria for the health check probe. If you use the --response flag, either by itself or in conjunction with the --request flag, the response returned must exactly match the expected response string.

Creating and modifying health checks

You cannot convert a health check to a legacy health check, or vice versa, by modifying it.

Console

The Cloud Console lists both health checks and legacy health checks. You can edit existing health checks and legacy health checks; however, you cannot create a legacy health check on the health checks page in the Cloud Console.

To create a health check:

1. Go to the Health checks page in the Google Cloud Console.
   Go to the Health checks page
2. Click Create a health check.
3. On the Create a health check page, supply the following information:
   • Name: Provide a name for the health check.
   • Description: Optionally, provide a description.
   • Protocol: Choose a health check protocol.
   • Port: Provide a port number.
   • Proxy protocol: Optionally, you can append a proxy header to the requests made by the health check probe systems.
   • Request path and Response: For HTTP, HTTPS, and HTTP2 protocols, you can optionally provide a URL path for the health check probe systems to contact. Refer to optional flags for HTTP, HTTPS, and HTTP/2 health checks for more information.
   • Request and Response: For TCP and SSL protcols, you can specify an ASCII text string to send and expected text response string. Refer to optional flags for SSL and TCP health checks for more information.
   • Check interval: Defines the amount of time from the start of one probe to the start of the next one.
   • Timeout: Defines the amount of time that Google Cloud will wait for a response to a probe. Its value must be less than or equal to the check interval.
   • Healthy threshold: Defines the number of sequential probes that must succeed for the VM instance to be considered healthy.
   • Unhealthy threshold: Defines the number of sequential probes that must fail for the VM instance to be considered unhealthy.
4. Click Create.

To edit a health check:

1. Go to the Health checks page in the Google Cloud Console.
   Go to the Health checks page
2. Click on a health check to view its details.
3. If you need to modify the health check, click Edit, then:
   • Make changes to the parameters as necessary.
   • Click Save.

gcloud

1. Use the following gcloud commands to list health checks:

   gcloud compute health-checks list
   

2. Identify a health check, then describe it using the appropriate gcloud command, replacing HEALTH_CHECK_NAME with its name.

   gcloud compute health-checks describe HEALTH_CHECK_NAME
   

3. To modify the health check, use the appropriate gcloud command, replacing HEALTH_CHECK_NAME with its name. Except for the health check name and protocol, you can modify any of the common flags, the port specification flags, and optional flags. When you modify an existing health check with the gcloud compute health-checks update command, preconfigured settings are preserved for flags that you omit. The following command modifies an example health check by changing its check interval, timeout, and request path:

   gcloud compute health-checks update http hc-http-port-80 \
       --check-interval=20s \
       --timeout=15s \
       --request-path="/health"
   

API

1. You can list health checks with the healthChecks.list API call.

2. If you know the name of a health check, you can get its configuration details with the healthChecks.get API call.

3. If you need to modify a health check, use these API calls:

   • healthChecks.update
   • healthChecks.patch

Legacy health checks

Creating legacy health checks

This section describes how to create legacy health checks which are required by network load balancers.

Note: Although legacy health checks can be created using either the HTTP or HTTPS protocols, network load balancers only suppport legacy health checks that use the HTTP protocol.

Console

Although the Cloud Console's health checks page lists both health checks and legacy health checks, you cannot create a legacy health check on the Cloud Console. You can only create a legacy health check using the Cloud Console's network load balancer page.

gcloud

Use the following gcloud command to create a legacy health check for a network load balancer:

gcloud compute LEGACY_CHECK_TYPE create LEGACY_HEALTH_CHECK_NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --host=HOST \
    --port=PORT \
    --request-path=REQUEST_PATH

Where:

• LEGACY_CHECK_TYPE is http-health-checks for a legacy HTTP health check or https-health-checks for a legacy HTTPS health check. If you are creating the legacy health check for a network load balancer, you must use http-health-checks.
• LEGACY_HEALTH_CHECK_NAME is the name of the legacy health check. Within a given project, each legacy health check must have a unique name.
• DESCRIPTION is an optional description.
• CHECK_INTERVAL is the amount of time from the start of one probe to the start of the next one. Units are seconds. If omitted, Google Cloud uses a value of 5s (5 seconds).
• TIMEOUT is the amount of time that Google Cloud will wait for a response to a probe. The value of TIMEOUT must be less than or equal to the CHECK_INTERVAL. Units are seconds. If omitted, Google Cloud uses a value of 5s (5 seconds).
• HEALTHY_THRESHOLD and UNHEALTHY_THRESHOLD specify the number of sequential probes that must succeed or fail for a VM instance to be considered healthy or unhealthy. If either is omitted, Google Cloud uses a default threshold of 2.
• HOST allows you to provide a host HTTP header. If omitted, the IP address of the load balancer's forwarding rule is used.
• PORT allows you to provide a port number. If omitted, Google Cloud uses 80.
• REQUEST_PATH specifies the URL path that Google Cloud uses when sending health check requests. If omitted, the health check request is sent to /.

API

You can create a legacy health check using this API call for a network load balancer:

• httpHealthChecks.insert

Viewing and modifying legacy health checks

Console

The Cloud Console lists both health checks and legacy health checks on the health checks page. To edit an existing legacy health check:

1. Go to the Health checks page in the Google Cloud Console.
   Go to the Health checks page
2. Click on a health check to view its details.
3. If you need to modify the health check, click Edit, then:
   • Make changes to the parameters as necessary.
   • Click Save.

gcloud

1. Use the following gcloud commands to list legacy health checks for network load balancers.

   gcloud compute http-health-checks list
   

2. Identify a legacy health check, then describe it using the appropriate gcloud command, replacing LEGACY_HEALTH_CHECK_NAME with its name.

   gcloud compute http-health-checks describe LEGACY_HEALTH_CHECK_NAME
   

3. If you need to modify a legacy health check, use the appropriate gcloud command, replacing LEGACY_HEALTH_CHECK_NAME with its name. When modifying a health check with gcloud, existing settings for the flags you omit are preserved.

   gcloud compute http-health-checks update LEGACY_HEALTH_CHECK_NAME \
       ...other options
   

   Where the ...other options are the options for creating a legacy health check.

API

1. Use the following API call to list legacy health checks for network load balancers.

   • httpHealthChecks.list

2. If you know the name of a legacy health check, you can get its configuration details with this API call:

   • httpHealthChecks.get

3. If you need to modify a legacy health check, use these API calls:

   • httpHealthChecks.update
   • httpHealthChecks.patch

Firewall rules

You need to create ingress firewall rules applicable to all VMs being load balanced to allow traffic from health check prober IP ranges. The following examples create firewall rules that are applicable to VM instances by target tag. For more information about specifying targets for firewall rules, see the explanation of targets in the Firewall Rules Overview and Configuring Network Tags.

Each of these examples allows all TCP traffic from Google Cloud health check systems to your VM instances. (TCP traffic includes SSL, HTTP, HTTPS, and HTTP/2 traffic.) If you prefer, you can specify ports along with the TCP protocol; however, if you specify ports, your firewall rules might become specific to a particular health check. If you use tcp:80 for the protocol and port, this allows TCP traffic on port 80, so Google Cloud could contact your VMs using HTTP on port 80, but it could not contact them using HTTPS on port 443.

Rules for health checks

The following example creates an ingress firewall rule for the following load balancers:

• Internal TCP/UDP Load Balancing (health checks)
• Internal HTTP(S) Load Balancing (health checks)
• TCP Proxy Load Balancing (health checks)
• SSL Proxy Load Balancing (health checks)
• HTTP(S) Load Balancing (health checks and legacy health checks)

For these load balancers, the source IP ranges for health checks (including legacy health checks if used for HTTP(S) Load Balancing) are:

• 35.191.0.0/16
• 130.211.0.0/22

For Internal HTTP(S) Load Balancing only, the source IP range is all the IP addresses in the proxy-only subnet.

If you need to create rules for Network Load Balancing, refer to the next section, Rules for Network Load Balancing.

Console

1. Go to the Firewall rules page in the Google Cloud Console.
   Go to the Firewall rules page
2. Click Create firewall rule.
3. On the Create a firewall rule page, supply the following information:
   • Name: Provide a name for the rule. For this example, use fw-allow-health-checks.
   • Network: Choose a VPC network.
   • Priority: Enter a number for the priority. Lower numbers have higher priorities. Be sure that the firewall rule has a higher priority than other rules that might deny ingress traffic.
   • Direction of traffic: Choose ingress.
   • Action on match: Choose allow.
   • Targets: Choose Specified target tags, then enter tags in the Target tags text box. For this example, use allow-health-checks.
   • Source filter: Choose IP ranges.
   • Source IP ranges: 35.191.0.0/16,130.211.0.0/22
   • Allowed protocols and ports: Use tcp. TCP is the underlying protocol for all health check protocols.
   • Click Create.
4. On each of your instances being load balanced, add the network tag so that this new ingress firewall rule applies to them. This example uses allow-health-checks for the network tag.

gcloud

1. Use the following gcloud command to create a firewall rule named fw-allow-health-checks that allows incoming connections to instances in your network with the allow-health-checks tag. Replace NETWORK_NAME with the name of your network.

   gcloud compute firewall-rules create fw-allow-health-checks \
       --network NETWORK_NAME \
       --action ALLOW \
       --direction INGRESS \
       --source-ranges 35.191.0.0/16,130.211.0.0/22 \
       --target-tags allow-health-checks \
       --rules tcp

2. On each of your instances being load balanced, add the network tag so that this new ingress firewall rule applies to them. This example uses allow-health-checks for the network tag.

Refer to the gcloud firewall rules documentation and the API documentation for more details.

Rules for Network Load Balancing

The following example creates an ingress firewall rule for Network Load Balancing, which requires a legacy health check. The source IP ranges for legacy health checks for Network Load Balancing are:

• 35.191.0.0/16
• 209.85.152.0/22

• 209.85.204.0/22

Console

1. Go to the Firewall rules page in the Google Cloud Console.
   Go to the Firewall rules page
2. Click Create firewall rule.
3. On the Create a firewall rule page, supply the following information:
   • Name: Provide a name for the rule. For this example, use fw-allow-network-lb-health-checks.
   • Network: Choose a VPC network.
   • Priority: Enter a number for the priority. Lower numbers have higher priorities. Be sure that the firewall rule has a higher priority than other rules that might deny ingress traffic.
   • Direction of traffic: Choose ingress.
   • Action on match: Choose allow.
   • Targets: Choose Specified target tags, then enter tags in the Target tags text box. For this example, use allow-network-lb-health-checks.
   • Source filter: Choose IP ranges.
   • Source IP ranges: 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22
   • Allowed protocols and ports: Use tcp. TCP is the underlying protocol for HTTP and HTTPS.
   • Click Create.
4. On each of your instances being load balanced, add the network tag so that this new ingress firewall rule applies to them. This example uses allow-network-lb-health-checks for the network tag.

gcloud

1. Use the following gcloud command to create a firewall rule named fw-allow-network-lb-health-checks that allows incoming connections to instances in your network with the allow-network-lb-health-checks tag. Replace NETWORK_NAME with the name of your network.

   gcloud compute firewall-rules create fw-allow-network-lb-health-checks \
       --network NETWORK_NAME \
       --action ALLOW \
       --direction INGRESS \
       --source-ranges 35.191.0.0/16,209.85.152.0/22,209.85.204.0/22 \
       --target-tags allow-network-lb-health-checks \
       --rules tcp

2. On each of your instances being load balanced, add the network tag so that this new ingress firewall rule applies to them. This example uses allow-network-lb-health-checks for the network tag.

Refer to the gcloud firewall rules documentation and the API documentation for more details.

Associating with load balancers

Protocols and load balancers

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. As examples:

• For Internal TCP/UDP Load Balancing, you can only use TCP or UDP for the backend service's protocol. If you serve HTTP traffic from VMs behind an internal load balancer, it makes sense to employ a health check using the HTTP protocol.

• A legacy health check is limited to the HTTP protocol. If you use a 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.

Health checks for backend services

This section describes how to associate a health check with a backend service for these types of load balancers:

• Internal TCP/UDP Load Balancing
• Internal HTTP(S) Load Balancing
• TCP Proxy Load Balancing
• SSL Proxy Load Balancing
• HTTP(S) Load Balancing

This section assumes that you have already:

• Created an internal, TCP Proxy, SSL Proxy, or HTTP(S) load balancer.
• Created a health check.
• Configured the firewall rules for health checks.

To associate a health check with a new internal, TCP Proxy, SSL Proxy, or HTTP(S) load balancer, refer to the setup guide for the respective load balancer.

Console

To associate a health check with an existing internal, TCP Proxy, SSL Proxy, or HTTP(S) load balancer:

1. Go to the Load balancing page in the Google Cloud Console.
   Go to the Load balancing page
2. Click on a load balancer to view its details.
3. Click Edit, then click Backend configuration.
4. Choose a health check from the Health check menu.
5. Click Update.

gcloud

To associate a health check with an existing internal, TCP Proxy, SSL Proxy, or HTTP(S) load balancer:

1. Identify the backend service or services used by the load balancer. Internal, TCP Proxy, and SSL Proxy load balancers have only one backend service for the whole load balancer. HTTP(S) load balancers have one or more backend services associated with their URL map.

   • To list backend services for internal TCP/UDP load balancers, run the following command. Identify the name and region of the backend service.

     gcloud compute backend-services list \
         --filter="loadBalancingScheme=INTERNAL"
     

   • To list backend services for internal HTTP(S) load balancers, run the following command. Identify the name and region of the backend service.

     gcloud compute backend-services list \
         --filter="loadBalancingScheme=INTERNAL_MANAGED"
     

   • To list backend services for TCP Proxy load balancers:

     gcloud compute backend-services list \
         --filter="loadBalancingScheme=EXTERNAL" \
         --filter="protocol=TCP"
     

   • To list backend services for SSL Proxy load balancers:

     gcloud compute backend-services list \
         --filter="loadBalancingScheme=EXTERNAL" \
         --filter="protocol=SSL"
     

   • To identify backend services for HTTP(S) load balancing, identify the URL map, then describe it, replacing URL_MAP_NAME with the name of the URL map. The backend service(s) it uses are listed in the pathMatchers section of the response.

     gcloud compute url-maps list
     gcloud compute url-maps describe URL_MAP_NAME
     

2. Identify a health check. View health checks if necessary.

3. Associate the health check with the backend service. In the following commands, replace BACKEND_SERVICE_NAME with the name of the backend service and HEALTH_CHECK_NAME with the name of the health check. These commands replace all health checks associated with the backend service. In most cases, you'll have just one health check associated with the backend service.

   • To change the health check for a backend service for an internal load balancer, use the following command. Backend services for internal load balancers are regional, so you must specify the REGION in addition to its name.

     gcloud compute backend-services update BACKEND_SERVICE_NAME \
         --region REGION \
         --health-checks HEALTH_CHECK_NAME
     

   • To change the health check for a backend service for TCP Proxy, SSL Proxy, and HTTP(S) load balancers:

     gcloud compute backend-services update BACKEND_SERVICE_NAME \
         --global \
         --health-checks HEALTH_CHECK_NAME
     

API

1. You can list backend services with the backendServices.list API call.

2. View health checks.

3. To associate a health check with a backend service use one of these API calls:

   • backendServices.update
   • backendServices.patch

Legacy health checks for Network Load Balancing

This section describes how to associate a legacy health check with a target pool for Network Load Balancing. This section assumes that you have already:

• Created a network load balancer.
• Created a legacy health check.
• Configured the firewall rules for Network Load Balancing.

To associate a legacy health check with a new network load balancer, refer to Setting Up Network Load Balancing. You must associate a legacy health check with its target pool when you create a new network load balancer.

Console

To associate a health check with an existing network load balancer:

1. Go to the Load balancing page in the Google Cloud Console.
   Go to the Load balancing page
2. Click on a network load balancer to view its details.
3. Click Edit, then click Backend configuration.
4. Choose a legacy health check from the Health check menu. (Only eligible legacy health checks are shown.)
5. Click Update.

gcloud

To associate a health check with an existing network load balancer:

1. Identify the target pool(s). Network load balancers have at least one target pool, and might have a secondary backup pool.

   gcloud compute target-pools list
   

2. Identify a legacy health check using the HTTP protocol. View legacy health checks if necessary.

3. Associate the legacy health check with the target pool(s). In the following commands, replace TARGET_POOL_NAME with the name of the target pool, REGION with its region, and LEGACY_HEALTH_CHECK_NAME with the name of the legacy health check. The legacy health check must use the HTTP protocol.

   • To remove a legacy HTTP health check from a target pool:

     gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \
         --region REGION \
         --http-health-check LEGACY_HEALTH_CHECK_NAME
     

   • To add a legacy HTTP health check to a target pool:

     gcloud compute target-pools add-health-checks TARGET_POOL_NAME \
         --region REGION \
         --http-health-check LEGACY_HEALTH_CHECK_NAME
     

API

1. You can list target pools with the targetPools.list API call.

2. View legacy health checks and identify a legacy HTTP health check.

3. To associate a legacy HTTP health check with a target pool use the API call targetPools.addHealthCheck.

Troubleshooting health checks by blocking IP address ranges

Under certain circumstances, it's useful to purposefully fail health checks. You might need to force a particular VM to fail health checks as part of a troubleshooting activity, or you might want to have it fail health checks as part of its shutdown procedure.

You can force a health check or legacy health check to fail by temporarily blocking access to the health check IP ranges. This example shows you how to fail health checks using the iptables firewall software running on a Linux VM.

Important: Blocking new health check and legacy health check probes might also block other new incoming connections. This is the case if your health check uses the same port as your service and if connections are sourced from the same health check IP ranges.

To cause a VM to fail health check and legacy health check probes, connect to it and run an iptables command like the following example, replacing HEALTH_CHECK_PORT with the appropriate TCP port number. If you need a VM to purposefully fail probes as it is shutting down, you can add iptables commands like these to a shutdown script followed by an appropriate delay based on the health check's check interval and unhealthy threshold.

$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset

To remove the iptables rules, run the following commands, replacing HEALTH_CHECK_PORT with the health check's TCP port.

$ sudo iptables -D INPUT -m state --state NEW \
-s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset