Utiliser des vérifications d'état

Google Cloud propose des mécanismes de vérification d'état qui déterminent si les instances de backend répondent au trafic de façon appropriée. Ce document explique comment créer et utiliser des vérifications d'état pour les équilibreurs de charge et Traffic Director.

Sur cette page, nous partons du principe que vous connaissez bien les éléments suivants :

Créer des vérifications d'état

La console Google Cloud vous permet de créer ou de sélectionner une vérification d'état une fois la configuration du backend de l'équilibreur de charge terminée dans la console Google Cloud.

Vous pouvez également créer une vérification d'état indépendamment de la configuration de l'équilibreur de charge dans la console Google Cloud. Cela est utile si vous devez d'abord créer votre vérification d'état, ou si vous devez utiliser une vérification d'état pour plusieurs équilibreurs de charge. Vous pouvez créer une vérification d'état à l'aide de la console Google Cloud, de Google Cloud CLI ou des API REST.

Console

Accédez à la page "Vérifications d'état" dans Google Cloud Console.
Accéder à la page "Vérifications d'état"
Cliquez sur Créer une vérification d'état.
Sur la page Créer une vérification d'état, fournissez les informations suivantes :
- Nom : indiquez le nom de la vérification d'état.
- Description : vous pouvez éventuellement indiquer une description.
- Champ d'application : sélectionnez un champ d'application, Global ou Régional, selon le type d'équilibreur de charge.
  - Si vous avez sélectionné Régional, choisissez une Région dans la liste déroulante.
- Protocole : sélectionnez un protocole de vérification d'état.
- Port : indiquez un numéro de port. Lorsque vous créez une vérification d'état dans la console Google Cloud, vous devez spécifier le port à l'aide d'un numéro de port.
- Protocole de proxy : vous pouvez éventuellement ajouter un en-tête de proxy aux requêtes effectuées par les systèmes de test de vérification d'état.
- Chemin de requête et réponse : pour les protocoles HTTP, HTTPS et HTTP2, vous pouvez éventuellement fournir un chemin d'URL pour les systèmes de test de vérification d'état à contacter. Pour en savoir plus, consultez la section Options supplémentaires pour les vérifications d'état HTTP, HTTPS et HTTP/2.
- Requête et Réponse : pour les protocoles TCP et SSL, vous pouvez spécifier une chaîne de texte ASCII à envoyer et une chaîne de réponse textuelle attendue. Pour en savoir plus, consultez la section Options supplémentaires pour les vérifications d'état SSL et TCP.
- Intervalle entre deux tests : définit la durée écoulée entre le début d'une vérification et le début de la suivante.
- Délai avant expiration : définit la durée pendant laquelle Google Cloud attend une réponse à une vérification. Sa valeur doit être inférieure ou égale à l'intervalle entre deux tests.
- Seuil sanitaire : définit le nombre de vérifications séquentielles qui doivent réussir pour que l'instance de VM soit considérée comme opérationnelle.
- Seuil non sanitaire : définit le nombre de vérifications séquentielles qui doivent échouer pour que l'instance de VM soit considérée comme non opérationnelle.
Cliquez sur Créer.

gcloud

Pour créer une vérification d'état globale, utilisez la commande compute health-checks create appropriée :

gcloud compute health-checks create PROTOCOL NAME \
    --global \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

Pour créer une vérification d'état régionale, utilisez la commande compute health-checks create appropriée :

gcloud compute health-checks create PROTOCOL NAME \
    --region=REGION \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

Remplacez les éléments suivants :

PROTOCOL définit le protocole utilisé pour la vérification d'état. Les options valides sont grpc, http, https, http2, ssl et tcp.
NAME est le nom de la vérification d'état. Dans un projet donné, chaque vérification d'état globale doit posséder un nom unique, et les vérifications d'état régionales doivent posséder des noms uniques au sein d'une région donnée.
REGION : tous les équilibreurs de charge, à l'exception des équilibreurs de charge d'application externes régionaux et des équilibreurs de charge d'application internes régionaux, utilisent des vérifications d'état mondiales (--global). Les équilibreurs de charge d'application internes régionaux utilisent des vérifications d'état régionales, pour lesquelles la région doit correspondre à celle du service de backend.
DESCRIPTION est une description facultative.
CHECK_INTERVAL est la durée écoulée entre le début d'une connexion du système de test de vérification d'état et le début de la connexion suivante. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur 5s (cinq secondes).
TIMEOUT est la durée pendant laquelle Google Cloud attend une réponse à une vérification. La valeur de TIMEOUT doit être inférieure ou égale à celle de CHECK_INTERVAL. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur 5s (cinq secondes).
HEALTHY_THRESHOLD et UNHEALTHY_THRESHOLD indiquent le nombre de tests séquentiels qui doivent réussir ou échouer pour que l'instance de VM soit considérée comme opérationnelle ou non opérationnelle. Si l'une de ces valeurs est omise, Google Cloud utilise le seuil par défaut défini sur 2.
PORT_SPECIFICATION : définit la spécification du port à l'aide de l'une des options de spécification du port.
ADDITIONAL_FLAGS correspond à d'autres options permettant de spécifier des ports et des options propres au protocole PROTOCOL. Consultez les sections Options supplémentaires pour les vérifications d'état HTTP, HTTPS et HTTP/2, Options supplémentaires pour les vérifications d'état SSL et TCP ou Option supplémentaire pour les vérifications d'état gRPC.

Terraform

Pour créer une vérification d'état globale, utilisez la ressource google_compute_health_check.

resource "google_compute_health_check" "health_check_tcp_with_logging" {
  provider = google-beta

  name = "health-check-tcp"

  timeout_sec        = 1
  check_interval_sec = 1

  tcp_health_check {
    port = "22"
  }

  log_config {
    enable = true
  }
}

Pour créer une vérification d'état régionale, utilisez la ressource google_compute_region_health_check.

resource "google_compute_region_health_check" "default" {
  name               = "tcp-health-check-region-west"
  timeout_sec        = 5
  check_interval_sec = 5
  tcp_health_check {
    port = "80"
  }
  region = "us-west1"
}

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez la page Commandes Terraform de base.

API

Pour créer une vérification d'état globale, utilisez healthChecks.insert.
Pour créer une vérification d'état régionale, utilisez regionHealthChecks.insert.

Modifier les vérifications d'état

Vous ne pouvez pas modifier une vérification d'état de façon à la convertir en vérification d'état héritée (ou inversement). Vous ne pouvez pas non plus modifier le nom ou le champ d'application d'une vérification d'état (par exemple, de global à régional).

Console

Accédez à la page "Vérifications d'état" dans Google Cloud Console.
Accéder à la page "Vérifications d'état"
Cliquez sur une vérification d'état pour en afficher les détails.
Si vous devez modifier la vérification d'état, cliquez sur Modifier. Procédez ensuite comme suit :
- Modifiez les paramètres si nécessaire.
- Cliquez sur Enregistrer.

gcloud

Identifiez le nom et le champ d'application de la vérification d'état. Pour obtenir des instructions, consultez la section Répertorier les vérifications d'état.
Vous pouvez modifier toutes les options communes, options de spécification du port et options facultatives d'une vérification d'état, sauf le nom, le protocole et le champ d'application. Pour modifier une vérification d'état existante, utilisez la commande compute health-checks update appropriée. Pour les options que vous omettez, les paramètres préconfigurés sont conservés.
- Exemple de modification d'une vérification d'état globale : la commande suivante modifie une vérification d'état HTTP globale nommée hc-http-port-80 en modifiant l'intervalle entre deux tests, le délai avant expiration et le chemin de requête :
```
gcloud compute health-checks update http hc-http-port-80 \
    --global \
    --check-interval=20s \
    --timeout=15s \
    --request-path="/health"
```
- Exemple de modification d'une vérification d'état régionale : la commande suivante modifie une vérification d'état TCP régionale dans us-west1 nommée hc-west1-tcp-ldap en modifiant sa spécification de port :
```
gcloud compute health-checks update tcp hc-west1-tcp-ldap \
    --region=us-west1 \
    --port=631
```

API

Identifiez le nom et le champ d'application de la vérification d'état. Pour obtenir des instructions, consultez la section Répertorier les vérifications d'état.
Les appels d'API suivants vous permettent de modifier toutes les options communes, options de spécification du port et options facultatives d'une vérification d'état, sauf le nom, le protocole et le champ d'application. Utilisez les appels d'API patch pour conserver les paramètres préconfigurés qui ne sont pas explicitement définis dans la requête.
- Pour modifier une vérification d'état globale, utilisez healthChecks.update ou healthChecks.patch.
- Pour modifier une vérification d'état régionale, utilisez regionHealthChecks.update ou regionHealthChecks.patch.

Obtenir la liste des vérifications d'état

Console

Accédez à la page "Vérifications d'état" dans Google Cloud Console.
Accéder à la page "Vérifications d'état"
Cliquez sur une vérification d'état pour en afficher les détails.

gcloud

Pour répertorier les vérifications d'état, utilisez la commande compute health-checks list :

Pour répertorier les vérifications d'état globales :
```
gcloud compute health-checks list \
    --global
```
Pour répertorier les vérifications d'état régionales, remplacez REGION_LIST par une liste de régions Google Cloud à interroger, séparées par des virgules.
```
gcloud compute health-checks list \
    --regions=REGION_LIST
```

Si vous connaissez le nom et le champ d'application d'une vérification d'état, exécutez la commande compute health-checks describe pour afficher sa configuration actuelle.

Pour décrire une vérification d'état globale, remplacez NAME par son nom.
```
gcloud compute health-checks describe NAME \
    --global
```
Pour décrire une vérification d'état régionale, remplacez NAME par son nom et REGION par sa région.
```
gcloud compute health-checks describe NAME \
    --region=REGION
```

API

Pour répertorier les vérifications d'état, utilisez les appels d'API suivants :

Pour répertorier les vérifications d'état globales : healthChecks.list
Pour répertorier les vérifications d'état régionales : regionHealthChecks.list

Pour décrire la configuration actuelle d'une vérification d'état, utilisez les appels d'API suivants :

Pour décrire une vérification d'état globale : healthChecks.get
Pour décrire une vérification d'état régionale : regionHealthChecks.get

Options supplémentaires

Cette section décrit des options supplémentaires que vous pouvez utiliser lors de la création ou de la modification d'une vérification d'état. Certaines options, telles que la spécification du port, doivent être définies à l'aide de gcloud ou de l'API.

Options de spécification du port

Si vous créez une vérification d'état à l'aide de Google Cloud CLI ou de l'API, vous disposez de deux méthodes pour spécifier le port de la vérification d'état. Le tableau suivant présente les options de spécification du port pour les combinaisons d'équilibreur de charge et de backend valides. Le terme groupe d'instances désigne les groupes d'instances non gérés, les groupes d'instances gérés zonaux ou les groupes d'instances gérés régionaux.

Chaque vérification d'état ne peut utiliser qu'un seul type de spécification de port.

Produit	Type de backend	Options de spécification du port
Équilibreur de charge réseau passthrough externe	Groupes d'instances	• `--port` : spécifie un port TCP par numéro, de `1` à `65535` L'option `--use-serving-port` sera ignorée pour une vérification d'état associée avec un équilibreur de charge réseau passthrough externe, car les services de backend des équilibreurs de charge réseau passthrough externes n'ont pas de spécification de port.
Équilibreur de charge réseau passthrough interne	Groupes d'instances	• `--port` : spécifie un port TCP par numéro, de `1` à `65535` L'option `--use-serving-port` sera ignorée pour une vérification d'état associée avec un équilibreur de charge réseau passthrough interne, car les services de backend des équilibreurs de charge réseau passthrough internes n'ont pas de spécification de port.
Équilibreur de charge d'application externe global Équilibreur de charge d'application externe régional Équilibreur de charge d'application interne interrégional Équilibreur de charge d'application interne régional Équilibreur de charge réseau proxy externe global Équilibreur de charge réseau proxy classique Équilibreur de charge réseau proxy externe régional Équilibreur de charge réseau proxy interne régional Équilibreur de charge réseau proxy interne interrégional Traffic Director	NEG zonaux	• `--port` : spécifie un port TCP par son numéro, compris entre `1` et `65535` • `--use-serving-port` : utilise le port spécifié par chaque point de terminaison dans le groupe de points de terminaison du réseau
	Groupes d'instances	• `--port` : spécifie un port TCP par numéro, compris entre `1` et `65535` • `--use-serving-port` : utilise le même port nommé de groupe d'instances que celui configuré pour le service de backend

Si vous omettez la spécification du port, Google Cloud utilise les valeurs par défaut suivantes :

Si le protocole de la vérification d'état est TCP ou HTTP, il utilise --port=80.
Si le protocole de la vérification d'état est SSL, HTTPS ou HTTP2, il utilise --port=443.
Si le protocole de la vérification d'état est GRPC, il n'y a pas de valeur par défaut implicite. Vous devez inclure la spécification de port.

Options supplémentaires pour les vérifications d'état HTTP, HTTPS et HTTP/2

En plus des indicateurs communs et de la spécification du port, vous pouvez utiliser les indicateurs facultatifs suivants pour les vérifications d'état HTTP, HTTPS et HTTP/2. Cet exemple crée une vérification d'état HTTP nommée hc-http-port-80 utilisant le port 80 avec les critères d'intervalle, de délai avant expiration et de seuil sanitaire par défaut.

gcloud compute health-checks create HTTP_PROTOCOL hc-http-port-80 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE

HTTP_PROTOCOL : peut prendre la valeur http (HTTP/1.1 sans TLS), https (HTTP/1.1 avec TLS) ou http2 (HTTP/2 avec TLS).
COMMON_FLAGS : définit les options communes. Consultez la section Procédure de création.
PORT_SPECIFICATION : définit la spécification du port à l'aide de l'une des options de spécification du port.
HOST vous permet de fournir un en-tête HTTP Host. En cas d'omission, l'adresse IP de la règle de transfert de l'équilibreur de charge est utilisée.
PROXY_HEADER doit être défini sur NONE ou PROXY_V1. En cas d'omission, Google Cloud utilise NONE. La valeur PROXY_V1 ajoute l'en-tête PROXY UNKNOWN\r\n.
REQUEST_PATH spécifie le chemin d'URL que Google Cloud utilise lors de l'envoi de requêtes de vérification d'état. En cas d'omission, la requête de vérification d'état est envoyée à /.
RESPONSE définit une réponse attendue facultative. Les chaînes de réponse doivent respecter les règles suivantes :
- La chaîne de réponse doit être composée de lettres ASCII, de chiffres et d'espaces.
- La chaîne de réponse peut comporter jusqu'à 1 024 caractères.
- La mise en correspondance des caractères génériques n'est pas prise en charge.
- La vérification basée sur le contenu n'est pas compatible avec l'inversion. Par exemple, des opérateurs tels que ! dans HAProxy ne sont pas acceptés.

Si Google Cloud trouve la chaîne de réponse attendue n'importe où dans les 1 024 premiers octets du corps de la réponse reçue, et si l'état HTTP est 200 (OK), la vérification est considérée comme réussie.

Les options --request-path et --response modifient les critères de réussite des vérifications d'état.

Options supplémentaires pour les vérifications d'état SSL et TCP

En plus des indicateurs communs et de la spécification du port, vous pouvez utiliser les indicateurs facultatifs suivants pour les vérifications d'état SSL et TCP. Cet exemple crée une vérification d'état TCP nommée hc-tcp-3268 utilisant le port 3268 avec les critères d'intervalle, de délai avant expiration et de seuil sanitaire par défaut.

gcloud compute health-checks create tcp hc-tcp-3268 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING

Le protocole peut être tcp (comme dans cet exemple) ou ssl.
COMMON_FLAGS : définit les options communes. Consultez la section Procédure de création.
PORT_SPECIFICATION : définit la spécification du port à l'aide de l'une des options de spécification du port.
PROXY_HEADER doit être défini sur NONE ou PROXY_V1. En cas d'omission, Google Cloud utilise NONE. La valeur PROXY_V1 ajoute l'en-tête PROXY UNKNOWN\r\n.
REQUEST_STRING : vous pouvez fournir une chaîne contenant jusqu'à 1 024 caractères ASCII, qui sera envoyée une fois la session TCP ou SSL établie.
RESPONSE_STRING : vous pouvez fournir une chaîne contenant jusqu'à 1 024 caractères ASCII en tant que réponse attendue.

Les options --request et --response modifient les critères de réussite des vérifications d'état. Si vous utilisez l'option --response, soit seule, soit conjointement avec l'option --request, la réponse renvoyée doit correspondre exactement à la chaîne de réponse attendue.

Option supplémentaire pour les vérifications d'état gRPC

Votre serveur gRPC backend doit mettre en œuvre le service d'état gRPC tel que décrit dans le protocole de vérification de l'état gRPC. Google Cloud envoie un message HealthCheckRequest à vos backends en appelant la méthode Check du service de santé sur votre backend. Le paramètre de service dans la requête est défini sur une chaîne vide, sauf si un nom de service gRPC est spécifié.

Une vérification d'état gRPC peut vérifier l'état d'un service gRPC. Vous pouvez inclure une chaîne contenant jusqu'à 1 024 caractères ASCII, soit le nom d'un service gRPC particulier s'exécutant sur une VM de backend ou un NEG. Pour ce faire, utilisez l'option facultative suivante pour les vérifications d'état gRPC :

--grpc-service-name=GRPC_SERVICE_NAME

Par exemple, vous pouvez avoir les services et l'état suivants, que le serveur backend enregistre avec le service d'état gRPC de votre backend.

MyPackage.ServiceA avec l'état de diffusion SERVING
MyPackage.ServiceB avec l'état de diffusion NOT_SERVING
Nom du service vide avec l'état de diffusion NOT_SERVING

Si vous créez une vérification d'état avec MyPackage.ServiceA, comme suit, celle-ci renvoie HEALTHY, car l'état du service est SERVING.

gcloud beta compute health-checks create grpc MyGrpcHealthCheckServiceA \
    --grpc-service-name=MyPackage.ServiceA

Si vous créez une vérification d'état sur MyPackage.ServiceB, celle-ci renvoie UNHEALTHY, car l'état du service est NOT_SERVING.

Si vous créez une vérification d'état sur MyPackage.ServiceC, qui n'est pas enregistrée auprès du service d'état gRPC, la vérification de l'état renvoie l'état gRPC NOT_FOUND, ce qui équivaut à UNHEALTHY.

Si vous créez une vérification d'état avec le nom de service vide, celle-ci renvoie l'état UNHEALTHY, car le nom de service vide est enregistré avec l'état NOT_SERVING.

Vérifications d'état héritées

Cette section explique comment créer, modifier et répertorier des vérifications d'état héritées HTTP et HTTPS. Vous ne pouvez pas convertir une vérification d'état héritée en vérification d'état, et inversement.

Pour savoir quels types d'équilibreurs de charge sont compatibles avec les vérifications d'état héritées, consultez le guide sur les équilibreurs de charge.

Créer des vérifications d'état héritées

Console

Bien que la page des vérifications d'état de la console Google Cloud répertorie et permette de modifier à la fois les vérifications d'état et les vérifications d'état héritées, vous ne pouvez pas créer une vérification d'état héritée depuis cette page.

Vous pouvez créer une vérification d'état héritée dans la console Google Cloud uniquement pendant la création d'un équilibreur de charge réseau passthrough externe basé sur un pool cible. Pour créer la vérification d'état héritée séparément, suivez les instructions gcloud ou d'API de cette section.

gcloud

Pour créer une vérification d'état héritée, exécutez la commande compute http-health-checks create :

gcloud compute LEGACY_CHECK_TYPE create 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

Remplacez les éléments suivants :

LEGACY_CHECK_TYPE correspond à http-health-checks pour une vérification d'état héritée HTTP ou à https-health-checks pour une vérification d'état héritée HTTPS. Si vous créez la vérification d'état héritée pour un équilibreur de charge réseau passthrough externe basé sur un pool cible, vous devez utiliser http-health-checks.
NAME est le nom de la vérification d'état héritée. Dans un projet donné, chaque vérification d'état héritée doit avoir un nom unique.
DESCRIPTION est une description facultative.
CHECK_INTERVAL définit la durée écoulée entre le début d'un test et le début du suivant Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur 5s (cinq secondes).
TIMEOUT est la durée pendant laquelle Google Cloud attend une réponse à une vérification. La valeur de TIMEOUT doit être inférieure ou égale à celle de CHECK_INTERVAL. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur 5s (cinq secondes).
HEALTHY_THRESHOLD et UNHEALTHY_THRESHOLD indiquent le nombre de tests séquentiels qui doivent réussir ou échouer pour qu'une instance de VM soit considérée comme opérationnelle ou non opérationnelle. Si l'une de ces valeurs est omise, Google Cloud utilise le seuil par défaut défini sur 2.
HOST vous permet de fournir un en-tête HTTP d'hôte. En cas d'omission, l'adresse IP de la règle de transfert de l'équilibreur de charge est utilisée.
PORT vous permet d'indiquer un numéro de port. En cas d'omission, Google Cloud utilise 80.
REQUEST_PATH spécifie le chemin d'URL que Google Cloud utilise lors de l'envoi de requêtes de vérification d'état. En cas d'omission, la requête de vérification d'état est envoyée à /.

API

Pour créer une vérification d'état héritée HTTP, utilisez l'appel d'API httpHealthChecks.insert.
Pour créer une vérification d'état héritée HTTPS, utilisez l'appel d'API httpsHealthChecks.insert.

Terraform

Pour créer une ressource de vérification d'état héritée HTTP, utilisez la ressource google_compute_http_health_check.
Pour créer une ressource de vérification d'état héritée HTTPS, utilisez la ressource google_compute_https_health_check.

Modifier les vérifications d'état héritées

Console

Accédez à la page "Vérifications d'état" dans Google Cloud Console.
Accéder à la page "Vérifications d'état"
Cliquez sur une vérification d'état pour en afficher les détails.
Cliquez sur Modifier , apportez les modifications nécessaires, puis cliquez sur Enregistrer.

gcloud

Pour modifier une vérification d'état héritée HTTP, utilisez la commande compute http-health-checks update en remplaçant NAME par son nom. Lorsque vous modifiez une vérification d'état héritée avec gcloud, les paramètres préconfigurés des options omises sont conservés. Les options "OTHER_OPTIONS" sont celles décrites à la section Créer une vérification d'état héritée.
```
gcloud compute http-health-checks update NAME \
  OTHER_OPTIONS
```
Pour modifier une vérification d'état héritée HTTPS, utilisez la commande compute https-health-checks update en remplaçant NAME par son nom. Lorsque vous modifiez une vérification d'état héritée avec gcloud, les paramètres préconfigurés des options omises sont conservés. Les options "OTHER_OPTIONS" sont celles décrites à la section Créer une vérification d'état héritée.
```
gcloud compute https-health-checks update NAME \
  OTHER_OPTIONS
```

API

Hormis le nom et le type d'une vérification d'état héritée, vous pouvez modifier n'importe quelle option utilisée pour sa création. Les appels d'API patch conservent les paramètres préconfigurés qui ne sont pas explicitement définis dans la requête "patch".

Pour modifier une vérification d'état héritée HTTP, utilisez httpHealthChecks.update ou httpHealthChecks.patch.
Pour modifier une vérification d'état héritée HTTPS, utilisez httpsHealthChecks.update ou httpsHealthChecks.patch.

Répertorier les vérifications d'état héritées

Console

Accédez à la page "Vérifications d'état" dans Google Cloud Console.
Accéder à la page "Vérifications d'état"
Cliquez sur une vérification d'état héritée pour en afficher les détails.

gcloud

Pour répertorier les vérifications d'état héritées HTTP, utilisez la commande compute http-health-checks list :
```
gcloud compute http-health-checks list
```
Pour répertorier les vérifications d'état héritées HTTPS, utilisez la commande compute https-health-checks list :
```
gcloud compute https-health-checks list
```
Pour décrire une vérification d'état héritée HTTP, utilisez la commande compute http-health-checks describe en remplaçant NAME par son nom.
```
gcloud compute http-health-checks describe NAME
```
Pour décrire une vérification d'état héritée HTTPS, utilisez la commande compute https-health-checks describe en remplaçant NAME par son nom.
```
gcloud compute https-health-checks describe NAME
```

API

Pour répertorier les vérifications d'état héritées :
- Utilisez la méthode httpHealthChecks.list pour répertorier les vérifications d'état héritées HTTP.
- Utilisez la méthode httpsHealthChecks.list pour répertorier les vérifications d'état héritées HTTPS.
Pour décrire une vérification d'état héritée :
- Utilisez la méthode httpHealthChecks.get pour décrire une vérification d'état héritée HTTP.
- Utilisez la méthode httpsHealthChecks.get pour décrire une vérification d'état héritée HTTPS.

Créer les règles de pare-feu requises

Vous devez créer des règles de pare-feu d'entrée applicables à toutes les VM faisant l'objet d'un équilibrage de charge pour autoriser le trafic provenant des plages d'adresses IP du système de test de vérification d'état. L'exemple suivant crée une règle de pare-feu applicable aux instances de VM identifiées par un tag cible spécifique.

Cet exemple autorise tout le trafic TCP en provenance des systèmes de vérification d'état de Google Cloud vers vos instances de VM. (Le trafic TCP inclut le trafic SSL, HTTP, HTTPS et HTTP/2.) Si vous préférez, vous pouvez spécifier des ports avec le protocole TCP. Toutefois, si vous spécifiez des ports, vos règles de pare-feu peuvent devenir propres à une certaine vérification d'état. Si vous utilisez tcp:80 pour le protocole et le port, cela autorise le trafic TCP sur le port 80. Google Cloud peut alors contacter vos VM via HTTP sur le port 80, mais pas via HTTPS sur le port 443.

Console

Dans la console Google Cloud, accédez à la page Règles d'administration.
Accéder à la page "Stratégies de pare-feu"
Cliquez sur Créer une règle de pare-feu.
Sur la page Créer une règle de pare-feu, fournissez les informations suivantes :
- Nom : attribuez un nom à la règle. Pour cet exemple, utilisez fw-allow-health-checks.
- Réseau : choisissez un réseau VPC.
- Priorité : saisissez un numéro pour la priorité. Plus la valeur est faible, plus la priorité est élevée. Assurez-vous que la règle de pare-feu a une priorité plus élevée que les autres règles susceptibles de refuser le trafic entrant.
- Sens du trafic : choisissez Entrée.
- Action en cas de correspondance : sélectionnez Autoriser.
- Cibles : sélectionnez Tags cibles spécifiés, puis saisissez des tags dans le champ Tags cibles. Pour cet exemple, utilisez allow-health-checks.
- Filtre source : choisissez Plages d'adresses IP.
- Plages d'adresses IP sources : saisissez la plage d'adresses IP source en fonction du type d'équilibreur de charge, du type de trafic et du type de vérification d'état. Consultez la page Plages d'adresses IP de vérification et règles de pare-feu.
- Protocoles et ports autorisés : utilisez tcp et le port configuré dans votre vérification d'état. TCP est le protocole sous-jacent de tous les protocoles de vérification d'état.
- Cliquez sur Create (Créer).
Sur chacune de vos instances faisant l'objet d'un équilibrage de charge, ajoutez le tag réseau de sorte que cette nouvelle règle de pare-feu d'entrée lui soit appliquée. Cet exemple utilise allow-health-checks pour le tag réseau.

gcloud

Exécutez la commande gcloud suivante pour créer une règle de pare-feu nommée fw-allow-health-checks qui autorise les connexions TCP entrantes, en provenance des systèmes de vérification d'état de Google Cloud, à destination des instances de votre réseau VPC portant le tag allow-health-checks. Remplacez NETWORK_NAME par le nom de votre réseau VPC et PORT par les ports utilisés par votre équilibreur de charge.
```
gcloud compute firewall-rules create fw-allow-health-checks \
    --network=NETWORK_NAME \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=SOURCE_IP_RANGE \
    --target-tags=allow-health-checks \
    --rules=tcp:PORT
```
La valeur de SOURCE_IP_RANGE dépend du type d'équilibreur de charge, du type de trafic et du type de vérification d'état. Consultez la page Plages d'adresses IP de vérification et règles de pare-feu.
Sur chacune de vos instances faisant l'objet d'un équilibrage de charge, ajoutez le tag réseau de sorte que cette nouvelle règle de pare-feu d'entrée lui soit appliquée. Cet exemple utilise allow-health-checks pour le tag réseau.

Pour en savoir plus, consultez la documentation sur les règles de pare-feu gcloud et la documentation de l'API.

Documentation associée :

Pour en savoir plus sur la spécification des cibles pour les règles de pare-feu, consultez la description des cibles sur la page Présentation des règles de pare-feu ainsi que la page Configurer des tags réseau.
Pour en savoir plus sur toutes les règles de pare-feu requises par les équilibreurs de charge, consultez la page Règles de pare-feu.

Associer des vérifications d'état à des équilibreurs de charge

Si vous ne l'avez pas déjà fait, consultez la page Présentation des vérifications d'état : sélectionner une vérification d'état.

Pour associer une vérification d'état à un nouvel équilibreur de charge, consultez le guide de configuration de l'équilibreur de charge correspondant. Cette section explique comment associer une vérification d'état au service de backend d'un équilibreur de charge existant.

Cette section suppose que vous avez déjà :

créé un équilibreur de charge ;
créé une vérification d'état ;
Création de la règle de pare-feu requise

Console

Pour associer une vérification d'état à un équilibreur de charge existant, procédez comme suit :

Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
Accéder à la page Équilibrage de charge
Cliquez sur un équilibreur de charge pour en afficher les détails.
Cliquez sur Modifier , puis sur Configuration du backend.
Sélectionnez une vérification d'état dans le menu Vérification d'état.
Cliquez sur Mettre à jour.

gcloud

Pour associer une vérification d'état à un service de backend existant, procédez comme suit.

Identifiez le nom et le champ d'application du service de backend. Les équilibreurs de charge réseau passthrough externes, les équilibreurs de charge réseau passthrough internes, les équilibreurs de charge réseau proxy internes régionaux et les équilibreurs de charge réseau proxy externes ne disposent que d'un seul service de backend par équilibreur de charge. Les équilibreurs de charge d'application externes et internes sont associés à un ou plusieurs services de backend liés à un mappage d'URL unique.
- Pour lister les services de backend des équilibreurs de charge réseau passthrough internes, exécutez la commande suivante en remplaçant REGION_LIST par une liste de régions Google Cloud à interroger, séparées par des virgules.
```
gcloud compute backend-services list \
    --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=INTERNAL"
```
- Pour lister les services de backend des équilibreurs de charge réseau passthrough externes, exécutez la commande suivante en remplaçant chaque REGION par la région Google Cloud à interroger.
```
gcloud compute backend-services list \
    --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=EXTERNAL"
```
- Pour lister les services de backend des équilibreurs de charge réseau proxy externes globaux, exécutez la commande suivante.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- Pour lister les services de backend des équilibreurs de charge réseau proxy classiques, exécutez la commande suivante.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL" \
    --filter="protocol=(SSL,TCP)"
```
- Pour lister les services de backend des équilibreurs de charge réseau proxy externes régionaux, exécutez la commande suivante.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- Pour lister les services de backend des équilibreurs de charge réseau proxy internes régionaux, exécutez la commande suivante en remplaçant REGION_LIST par une liste de régions Google Cloud à interroger, séparées par des virgules.
```
gcloud beta compute backend-services list \
    --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=INTERNAL_MANAGED"
```
- Pour lister les services de backend des équilibreurs de charge réseau proxy externes à l'aide de SSL, exécutez la commande suivante. Les services de backend pour ces équilibreurs de charge sont toujours globaux, quel que soit le niveau de service réseau.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL" \
    --filter="protocol=(SSL,TCP)"
```
- Pour identifier les services de backend d'un équilibreur de charge d'application externe, commencez par identifier un mappage d'URL, puis décrivez-le. Les mappages d'URL et les services de backend pour les équilibreurs de charge d'application externes ou internes interrégionaux sont toujours mondiaux, quel que soit le niveau de service réseau. Remplacez URL_MAP_NAME par le nom du mappage d'URL. Les services de backend utilisés par l'équilibreur de charge sont répertoriés dans la réponse.
```
gcloud compute url-maps list \
    --global
```
```
gcloud compute url-maps describe URL_MAP_NAME \
    --global
```
- Pour identifier les services de backend d'un équilibreur de charge d'application externe régional ou d'un équilibreur de charge d'application interne régional, commencez par identifier un mappage d'URL, puis décrivez-le. Les mappages d'URL et les services de backend pour ces équilibreurs de charge sont régionaux. Remplacez REGION_LIST par une liste de régions Google Cloud à interroger, séparées par des virgules. Remplacez URL_MAP_NAME par le nom du mappage d'URL et REGION par sa région. Les services de backend utilisés par l'équilibreur de charge sont répertoriés dans la réponse.
```
gcloud compute url-maps list \
    --regions=REGION_LIST
```
```
gcloud compute url-maps describe URL_MAP_NAME \
    --region=REGION
```
Identifiez une vérification d'état. Consultez la section Répertorier les vérifications d'état.
Associez une vérification d'état au service de backend à l'aide de la commande compute backend-services update. Chaque service de backend doit faire référence à une seule vérification d'état. Dans les commandes ci-dessous, remplacez BACKEND_SERVICE_NAME par le nom du service de backend, HEALTH_CHECK_NAME par le nom de la vérification d'état et, si nécessaire, REGION par la région Google Cloud du service de backend, la vérification d'état ou les deux.
- Pour modifier la vérification d'état d'un équilibreur de charge réseau passthrough interne : le service de backend d'un équilibreur de charge réseau passthrough interne est régional. Il peut faire référence à une vérification d'état globale ou régionale. L'exemple suivant montre une référence de vérification d'état régionale. Si vous utilisez une vérification d'état globale avec votre équilibreur de charge réseau passthrough interne, utilisez --global-health-checks au lieu de --health-checks-region.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
- Pour modifier la vérification d'état d'un équilibreur de charge réseau passthrough externe basé sur un service de backend : le service de backend d'un équilibreur de charge réseau passthrough externe est régional. Il peut faire référence à une vérification d'état régionale.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
- Pour modifier la vérification de l'état d'un équilibreur de charge réseau externe global, d'un équilibreur de charge réseau proxy classique, d'un équilibreur de charge d'application externe global, d'un équilibreur de charge d'application classique ou d'un équilibreur de charge d'application interne interrégional : le service de backend et la vérification de l'état sont globaux pour ces équilibreurs de charge. Les équilibreurs de charge d'application peuvent référencer plusieurs vérifications de l'état s'ils font référence à plusieurs services de backend.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --global \
    --health-checks HEALTH_CHECK_NAME \
    --global-health-checks
```
- Pour modifier la vérification d'état d'un équilibreur de charge d'application externe régional, d'un équilibreur de charge réseau proxy externe régional, d'un équilibreur de charge d'application interne régional ou d'un équilibreur de charge réseau proxy interne régional, notez que le service de backend et la vérification de l'état sont régionaux. Certains équilibreurs de charge peuvent faire référence à plusieurs vérifications d'état s'ils peuvent faire référence à plusieurs services de backend.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```

API

Vous pouvez répertorier les services de backend à l'aide de l'appel d'API backendServices.list.
Affichez les vérifications d'état.
Pour associer une vérification d'état à un service de backend, utilisez l'un des appels d'API suivants :
- backendServices.update
- backendServices.patch

Associer des vérifications d'état héritées à des équilibreurs de charge réseau passthrough externes basés sur un pool cible

Pour associer une vérification d'état héritée à un nouvel équilibreur de charge réseau passthrough externe, consultez la page Configurer un équilibreur de charge réseau passthrough externe avec un pool cible. Cette section explique comment associer une vérification d'état héritée à un équilibreur de charge réseau passthrough externe basé sur un pool cible.

Cette section suppose que vous avez déjà :

créé un équilibreur de charge réseau passthrough externe basé sur un pool cible ;
créé une vérification d'état héritée ;
Création de la règle de pare-feu requise.

Console

Pour associer une vérification d'état à un équilibreur de charge réseau passthrough externe basé sur un pool cible existant, procédez comme suit :

Accédez à la page Équilibrage de charge dans Google Cloud Console.
Accéder à la page Équilibrage de charge
Cliquez sur un équilibreur de charge pour en afficher les détails.
Cliquez sur Modifier , puis sur Configuration du backend.
Sélectionnez une vérification d'état héritée dans le menu Vérification d'état. (Seules les vérifications d'état héritées éligibles sont affichées.)
Cliquez sur Mettre à jour.

gcloud

Pour associer une vérification d'état à un équilibreur de charge réseau passthrough externe basé sur un pool cible existant, procédez comme suit :

Identifiez le ou les pools cibles. Un équilibreur de charge réseau passthrough externe possède au moins un pool cible et peut avoir un pool de sauvegarde secondaire.
```
gcloud compute target-pools list
```
Identifiez une vérification d'état héritée utilisant le protocole HTTP. Si nécessaire, affichez les vérifications d'état héritées.
Associez la vérification d'état héritée aux pools cibles. Dans les commandes suivantes, remplacez TARGET_POOL_NAME par le nom du pool cible, REGION par sa région et LEGACY_CHECK_NAME par le nom de la vérification d'état héritée. La vérification d'état héritée doit utiliser le protocole HTTP.
- Pour supprimer une vérification d'état héritée HTTP d'un pool cible, exécutez la commande suivante :
```
gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME
```
- Pour ajouter une vérification d'état héritée à un pool cible, exécutez la commande suivante :
```
gcloud compute target-pools add-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME
```

API

Vous pouvez répertorier les pools cibles à l'aide de l'appel d'API targetPools.list.
Affichez les vérifications d'état héritées, puis identifiez-en une qui utilise le protocole HTTP.
Pour associer une vérification d'état héritée HTTP à un pool cible, utilisez l'appel d'API targetPools.addHealthCheck.

Vérifier l'état de la vérification d'état

Une fois que vous avez associé une vérification d'état à un service de backend ou à un pool cible, vous pouvez obtenir l'état instantané de la vérification de l'état des backends associés à l'équilibreur de charge.

Console

Accédez à la page de résumé de l'équilibrage de charge.
Accéder à la page "Équilibrage de charge"
Cliquez sur le nom d'un équilibreur de charge.
Sous Backend, examinez la colonne Opérationnel. L'état de fonctionnement y apparaît pour chaque groupe d'instances backend ou groupe de points de terminaison du réseau.

gcloud

Pour tous les équilibreurs de charge, à l'exception des équilibreurs de charge réseau passthrough externes basés sur un pool cible, identifiez le nom et le champ d'application (mondial ou régional) du service de backend. Pour obtenir la liste complète des équilibreurs de charge et des champs d'application, consultez la page Services de backend.

Exécutez la commande compute backend-services get-health en remplaçant NAME par le nom du service de backend et, si nécessaire, REGION par sa région.
- Pour obtenir l'état de fonctionnement instantané d'un service de backend global, procédez comme suit :
```
gcloud compute backend-services get-health GLOBAL_BACKEND_SERVICE_NAME \
    --global
```
- Pour obtenir l'état de fonctionnement instantané d'un service de backend régional, procédez comme suit :
```
gcloud compute backend-services get-health REGIONAL_BACKEND_SERVICE_NAME \
    --region=REGION
```
Pour les équilibreurs de charge réseau passthrough externes basés sur un pool cible, identifiez le nom et la région du pool cible de l'équilibreur de charge, puis utilisez la commande compute target-pools get-health, en remplaçant NAME par le nom du pool cible et REGION par sa région.
```
gcloud compute target-pools get-health TARGET_POOL_NAME \
    --region=REGION
```

API

Pour tous les équilibreurs de charge, à l'exception des équilibreurs de charge réseau passthrough externes basés sur un pool cible, identifiez le nom et le champ d'application (mondial ou régional) du service de backend. Pour obtenir la liste complète des équilibreurs de charge et des champs d'application, consultez la page Services de backend.
- Pour obtenir l'état de fonctionnement instantané d'un service de backend global, utilisez la méthode backendServices.getHealth.
- Pour obtenir l'état de fonctionnement instantané d'un service de backend régional, utilisez la méthode regionBackendServices.getHealth.
Pour les équilibreurs de charge réseau passthrough externes basés sur un pool cible, utilisez la méthode targetPools.getHealth.