Creating Health Checks

Beta

This is a Beta release of HTTP/2 health checks. This feature is not covered by any SLA or deprecation policy and might be subject to backward-incompatible changes.

Google Cloud Platform (GCP) 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 GCP firewall rules.

Health check categories, protocols, and ports

GCP 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 does not (and, in some situations, cannot) match the protocol used by the load balancer. Refer to Protocols and load balancers for more information.

Note: For the remainder of this document, the term “health check” will not refer to a legacy health check. Legacy health checks will be explicitly called “legacy health checks.”

Creating health checks

When you create a load balancer using the GCP Console, you can create a health check, or select an existing one, when you complete the load balancer's backend configuration. You cannot create health checks separately using the Health checks section of the GCP Console. To create a health check for one of the following load balancers separately, use the gcloud command line tool:

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

You can view and modify existing health checks using the Health checks section in the GCP Console.

Network load balancers must use legacy health checks instead.

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 connection to the start of the next one. Units are seconds. If omitted, GCP uses a value of 5s (5 seconds).
• [TIMEOUT] is the amount of time that GCP 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, GCP uses a value of 5s (5 seconds).
• [HEALTHY_THRESHOLD] and [UNHEALTHY_THRESHOLD] specify the number of sequential probes that must succeed or fail in order for the VM instance to be considered healthy or unhealthy. If either is omitted, GCP 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

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.

Load balancer	Backend type	Port specification
• Internal 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.
• TCP Proxy Load Balancing • SSL Proxy Load Balancing • HTTP(S) Load Balancing	Network Endpoint Groups	Only --use-serving-port^2: This instructs the health check to use the port specified by each individual network endpoint in the network endpoint group. This flag is required for network endpoint groups because each endpoint might use a different port.
	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

You cannot use instance groups and network endpoint groups as backends of the same backend service. For a given backend service, all of its backends must either be instance groups or network endpoint groups. You can use different types of instance groups (for example, managed and unmanaged instance groups) on the same backend service, but you cannot mix and match instance groups with network endpoint groups on the same backend service. Health checks can only use one type of port specification.

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 beta 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, GCP uses NONE. The value of PROXY_V1 adds the header PROXY UNKNOWN\r\n.
• [REQUEST_PATH] specifies the URL path that GCP 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 GCP 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, GCP 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.

Viewing and modifying health checks

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

Console

The GCP Console lists all types of health checks, including legacy health checks. You can edit any existing health check; however, you can only create legacy health checks from the health checks page.

1. Go to the Health checks page in the Google Cloud Platform 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. If you need to modify the health check, use the appropriate gcloud command, replacing [HEALTH_CHECK_NAME] with its name. Except for its name and protocol, you can modify any of the common flags, the port specification flags, and optional flags. When modifying a health check with gcloud, existing settings for the flags you omit are preserved. 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

You should only create a legacy health check for a network load balancer. (It is possible to use a legacy health check for backend services with instance group backends on a HTTP(S) load balancer, but it is not recommended.) This section describes how to create legacy health checks for network load balancers.

Console

1. Go to the Health checks page in the Google Cloud Platform 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 HTTP or HTTPS. Legacy health checks can only use these two protocols.
   • Port: Provide a port number. Legacy health checks can only reference a numbered port.
   • Request path: Provide the URL path that GCP uses when sending health check requests.
   • 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 GCP 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 in order for the VM instance to be considered healthy.
   • Unhealthy threshold: Defines the number of sequential probes that must fail in order for the VM instance to be considered unhealthy.
4. Click Create.

gcloud

Use the following gcloud command to create a legacy health check:

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 either http-health-checks for the HTTP protocol or https-health-checks for HTTPS.
• [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, GCP uses a value of 5s (5 seconds).
• [TIMEOUT] is the amount of time that GCP 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, GCP uses a value of 5s (5 seconds).
• [HEALTHY_THRESHOLD] and [UNHEALTHY_THRESHOLD] specify the number of sequential probes that must succeed or fail in order for a VM instance to be considered healthy or unhealthy. If either is omitted, GCP 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, GCP uses 80.
• [REQUEST_PATH] specifies the URL path that GCP uses when sending health check requests. If omitted, the health check request is sent to /.

API

You can create a legacy health check using either of these API calls:

• httpHealthChecks.insert
• httpsHealthChecks.insert

Viewing and modifying legacy health checks

Console

The GCP Console lists all types of health checks, including legacy health checks.

1. Go to the Health checks page in the Google Cloud Platform 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. Because there are two different types, there are two different commands:

   gcloud compute http-health-checks list
   gcloud compute https-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.

   • If the health check is a legacy HTTP health check:

     gcloud compute http-health-checks describe [LEGACY_HEALTH_CHECK_NAME]
     

   • If the health check is a legacy HTTPS health check:

     gcloud compute https-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.

   • If the health check is a legacy HTTP health check:

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

   • If the health check is a legacy HTTPS health check:

     gcloud compute https-health-checks update [LEGACY_HEALTH_CHECK_NAME] \
         ...other options
     

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

API

1. Use the following API calls to list legacy health checks. Because there are two different types, there are two different API calls:

   • httpHealthChecks.list
   • httpsHealthChecks.list

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

   • httpHealthChecks.get
   • httpsHealthChecks.get

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

   • httpHealthChecks.update or httpHealthChecks.patch
   • httpsHealthChecks.update or httpsHealthChecks.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 GCP 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 GCP 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 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

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 Platform 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 Platform 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 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 HTTP and HTTPS protocols. If you use a network load balancer to balance TCP traffic, you'd need to run a HTTP service on the VMs being load balanced so that they could respond to health checks 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 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.

Note: To associate a health check with a new internal, TCP Proxy, SSL Proxy, or HTTP(S) load balancer, refer to the how-to guide for the respective load balancer. Associating a health check is required whenever you create a new 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 Platform 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 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 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.

Note: To associate a legacy health check with a new network load balancer, refer to its how-to guide. You must associate a legacy health check with its target pool whenever 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 Platform 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