Créer des vérifications d'état

Google Cloud propose des mécanismes de vérification d'état qui déterminent si les instances de VM 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.

Dans cette page, nous partons du principe que vous maîtrisez les concepts de vérification d'état et que vous comprenez les règles de pare-feu Google Cloud.

Catégories, protocoles et ports pour les vérifications d'état

Google Cloud organise les vérifications d'état par catégorie et par protocole.

Il existe deux catégories de vérifications d'état : les vérifications d'état et les vérifications d'état héritées. Les catégories diffèrent suivant l'ensemble de protocoles qu'elles acceptent et la méthode de spécification du port à utiliser pour la vérification d'état.

La plupart des équilibreurs de charge font appel à des vérifications d'état non héritées, mais l'équilibrage de charge réseau nécessite des vérifications d'état héritées. Pour déterminer la catégorie, le protocole et la méthode de spécification du port appropriés, consultez la section Sélectionner une vérification d'état sur la page Concepts de vérification de l'état.

Le protocole que vous sélectionnez pour une vérification d'état n'a pas besoin de correspondre au protocole utilisé par l'équilibreur de charge. Dans certains cas, il arrive que cela ne soit pas possible du tout. Pour en savoir plus, consultez la section Protocoles et équilibreurs de charge.

Le terme "vérification d'état" ne fait pas référence aux vérifications d'état héritées. Dans ce document, celles-ci sont explicitement désignées par le terme "vérifications d'état héritées".

Créer des vérifications d'état

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 Cloud Console.

Vous pouvez également créer une vérification d'état indépendamment de la configuration de l'équilibreur de charge dans Cloud Console. 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 Cloud Console, de l'outil de ligne de commande gcloud ou des API REST. Après avoir consulté les informations générales figurant dans cette section, passez à la section Créer et modifier des vérifications d'état pour obtenir des instructions.

Les équilibreurs de charge réseau doivent utiliser des vérifications d'état héritées, que vous pouvez créer ou sélectionner une fois la configuration du backend de l'équilibreur de charge réseau terminée dans Cloud Console. Pour créer une vérification d'état héritée de façon indépendante, vous devez utiliser l'outil de ligne de commande gcloud ou les API REST. Pour en savoir plus, consultez la section Vérifications d'état héritées.

Options utilisées par toutes les vérifications d'état

Les options suivantes sont communes à toutes les vérifications d'état, quel que soit le protocole :

    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

Où :

PROTOCOL définit le protocole utilisé pour la vérification d'état. Les options valides sont http, https, http2, ssl et tcp.
HEALTH_CHECK_NAME est le nom de la vérification d'état. Dans un projet donné, chaque vérification d'état doit avoir un nom unique.
DESCRIPTION est une description facultative.
CHECK_INTERVAL est la durée écoulée entre le début d'une connexion du système 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 à la valeur 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 définissent le nombre de vérifications séquentielles qui doivent réussir ou échouer pour que l'instance de VM soit considérée comme opérationnelle ou non. Si l'une de ces valeurs est omise, Google Cloud utilise le seuil par défaut défini sur 2.
...additional flags sont d'autres options permettant de spécifier des ports et des options propres à PROTOCOL. Elles sont décrites dans les sections suivantes.

Options de spécification du port

Outre le protocole, vous devez spécifier un port pour une vérification d'état. La façon dont vous spécifiez le port dépend du type d'équilibreur de charge et du type de backend utilisé par son service de backend. Le tableau suivant présente les options de spécification du port pour des combinaisons d'équilibreur de charge et de backend valides. Dans le tableau, le terme groupe d'instances désigne aussi bien des groupes d'instances non gérés que des groupes d'instances zonaux gérés ou des groupes d'instances régionaux gérés.

Les vérifications d'état ne peuvent utiliser qu'un seul type de spécification du port.

Équilibreur de charge	Type de backend	Spécification du port
Équilibrage de charge TCP/UDP interne	Groupes d'instances	Utilisez l'une des options ci-dessous¹ : • `--port` : spécifie un port par son numéro, compris entre `1` et `65535` • `--port-name` : spécifie un port nommé exporté par un groupe d'instances Vous ne pouvez pas utiliser l'option `--use-serving-port` pour une vérification d'état associée à un équilibreur de charge interne, car les services de backend pour ce type d'équilibreur de charge ne disposent d'aucune spécification de port.
Équilibrage de charge HTTP(S) interne Équilibrage de charge proxy TCP Équilibrage de charge proxy SSL Équilibrage de charge HTTP(S)	Groupes de points de terminaison du réseau	Utilisez l'une des options ci-dessous¹ : • `--port` : spécifie un port 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	Utilisez l'une des options ci-dessous¹ : • `--port` : spécifie un port par son numéro, compris entre `1` et `65535` • `--port-name` : spécifie un port nommé exporté par un groupe d'instances • `--use-serving-port` : utilise le même port nommé de groupe d'instances que celui configuré pour le service de backend.

¹Les combinaisons de spécification du port sont résolues comme suit :

Si l'option --use-serving-port est spécifiée, ni --port, ni --port-name ne peuvent être spécifiées.
Si les options --port et --port-name sont spécifiées, --port prévaut.
Si aucune des trois options n'est spécifiée, la valeur par défaut est --port=80.

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

En plus des options communes et de la spécification du port, vous pouvez utiliser les options facultatives suivantes 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 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

Le protocole peut être http (comme dans cet exemple), https ou http2.
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.
Le paramètre 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 facultatives pour les vérifications d'état SSL et TCP

En plus des options communes et de la spécification du port, vous pouvez utiliser les options facultatives suivantes 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 \
        --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

Le protocole peut être tcp (comme dans cet exemple) ou ssl.
Le paramètre 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.

Créer et modifier des vérifications d'état

Vous ne pouvez pas convertir une vérification d'état en vérification d'état héritée, et vice versa.

Console

Cloud Console répertorie à la fois les vérifications d'état et les vérifications d'état héritées. Vous pouvez modifier les vérifications d'état et les vérifications d'état héritées existantes. Toutefois, vous ne pouvez pas créer une vérification d'état héritée sur la page "Vérifications d'état" de Cloud Console.

Pour créer une vérification d'état, procédez comme suit :

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.
- Protocole : sélectionnez un protocole pour la vérification d'état.
- Port : indiquez 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 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 vérification d'état à contacter. Pour en savoir plus, consultez la section Options facultatives 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 facultatives 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'un test et le début du suivant.
- Délai avant expiration : 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.

Pour modifier une vérification d'état :

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

Exécutez les commandes gcloud suivantes pour répertorier les vérifications d'état :
```
    gcloud compute health-checks list
    
```
Identifiez une vérification d'état, puis décrivez-la à l'aide de la commande gcloud appropriée, en remplaçant HEALTH_CHECK_NAME par son nom.
```
    gcloud compute health-checks describe HEALTH_CHECK_NAME
    
```
Pour modifier la vérification d'état, exécutez la commande gcloud appropriée, en remplaçant HEALTH_CHECK_NAME par son nom. Vous pouvez modifier les options communes, les options de spécification du port et les options facultatives, exception faite du nom et du protocole définis pour la vérification d'état. Lorsque vous modifiez une vérification d'état existante à l'aide de la commande gcloud compute health-checks update, les paramètres préconfigurés sont conservés pour les options que vous omettez. La commande suivante modifie un exemple de vérification d'état 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 \
        --check-interval=20s \
        --timeout=15s \
        --request-path="/health"
    
```

API

Vous pouvez répertorier les vérifications d'état à l'aide de l'appel d'API healthChecks.list.
Si vous connaissez le nom d'une vérification d'état, vous pouvez obtenir les détails de sa configuration à l'aide de l'appel d'API healthChecks.get.
Si vous devez modifier une vérification d'état, utilisez les appels d'API suivants :
- healthChecks.update
- healthChecks.patch

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

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

Cette section décrit comment créer les vérifications d'état héritées requises par les équilibreurs de charge réseau.

Console

Bien que la page "Vérifications d'état" de Cloud Console répertorie à 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 dans Cloud Console. Seule la page "Équilibreur de charge réseau" de Cloud Console permet d'effectuer cette opération.

gcloud

Exécutez la commande gcloud suivante afin de créer une vérification d'état héritée pour un équilibreur de charge réseau :

    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

Où :

Le paramètre LEGACY_CHECK_TYPE est défini sur http-health-checks pour une vérification d'état héritée HTTP ou sur 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, vous devez utiliser http-health-checks.
LEGACY_HEALTH_CHECK_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'une vérification et le début de la 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 à la valeur 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 définissent le nombre de vérifications séquentielles qui doivent réussir ou échouer pour qu'une instance de VM soit considérée comme opérationnelle ou non. 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

Vous pouvez créer une vérification d'état héritée pour un équilibreur de charge réseau à l'aide de l'appel d'API suivant :

httpHealthChecks.insert

Afficher et modifier les vérifications d'état héritées

Console

Cloud Console répertorie à la fois les vérifications d'état et les vérifications d'état héritées sur la page "Vérifications d'état". Pour modifier une vérification d'état héritée existante :

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

Exécutez les commandes gcloud suivantes afin de répertorier les vérifications d'état héritées pour les équilibreurs de charge réseau.
```
    gcloud compute http-health-checks list
    
```
Identifiez une vérification d'état héritée, puis décrivez-la à l'aide de la commande gcloud appropriée, en remplaçant LEGACY_HEALTH_CHECK_NAME par son nom.
```
    gcloud compute http-health-checks describe LEGACY_HEALTH_CHECK_NAME
    
```
Si vous devez modifier une vérification d'état héritée, exécutez la commande gcloud appropriée, en remplaçant LEGACY_HEALTH_CHECK_NAME par son nom. Lorsque vous modifiez une vérification d'état avec gcloud, les paramètres existants des options omises sont conservés.
```
    gcloud compute http-health-checks update LEGACY_HEALTH_CHECK_NAME \
        ...other options
    
```
Où ...other options correspond aux options permettant de créer une vérification d'état héritée.

API

Répertoriez les vérifications d'état héritées pour les équilibreurs de charge réseau à l'aide de l'appel d'API suivant :
- httpHealthChecks.list
Si vous connaissez le nom d'une vérification d'état héritée, vous pouvez obtenir les détails de sa configuration à l'aide de l'appel d'API suivant :
- httpHealthChecks.get
Si vous devez modifier une vérification d'état héritée, utilisez les appels d'API suivants :
- httpHealthChecks.update
- httpHealthChecks.patch

Règles de pare-feu

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 vérification d'état. Les exemples suivants créent des règles de pare-feu applicables aux instances de VM en fonction de leur tag cible. 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.

Chacun de ces exemples permet d'acheminer 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.

Règles pour les vérifications d'état

L'exemple suivant crée une règle de pare-feu d'entrée pour les équilibreurs de charge suivants :

Équilibrage de charge TCP/UDP interne (vérifications d'état)
Équilibrage de charge HTTP(S) interne (vérifications d'état)
Équilibrage de charge proxy TCP (vérifications d'état)
Équilibrage de charge proxy SSL (vérifications d'état)
Équilibrage de charge HTTP(S) (vérifications d'état et vérifications d'état héritées)

Pour ces équilibreurs de charge, les plages d'adresses IP sources des vérifications d'état (y compris des vérifications d'état héritées si elles sont utilisées pour l'équilibrage de charge HTTP(S)) sont les suivantes :

35.191.0.0/16
130.211.0.0/22

Pour l'équilibrage de charge HTTP(S) interne uniquement, la plage d'adresses IP sources correspond à toutes les adresses IP du sous-réseau proxy réservé.

Si vous devez créer des règles pour l'équilibrage de charge réseau, consultez la section suivante, Règles pour l'équilibrage de charge réseau.

Console

Accédez à la page "Règles de pare-feu" de Google Cloud Console.
Accéder à la page "Règles 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 : sélectionnez Entrée.
- Action en cas de correspondance : sélectionnez Autoriser.
- Cibles : sélectionnez Tags cibles spécifiés, puis saisissez des tags dans la zone de texte Tags cibles. Pour cet exemple, utilisez allow-health-checks.
- Filtre source : sélectionnez Plages d'adresses IP.
- Plages d'adresses IP sources : 35.191.0.0/16,130.211.0.0/22.
- Protocoles et ports autorisés : utilisez tcp. TCP est le protocole sous-jacent de tous les protocoles de vérification d'état.
- Cliquez sur 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 entrantes aux instances de votre réseau ayant le tag allow-health-checks. Remplacez NETWORK_NAME par le nom de votre réseau.

    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

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.

Règles pour l'équilibrage de charge réseau

L'exemple suivant crée une règle de pare-feu d'entrée pour l'équilibrage de charge réseau, qui nécessite une vérification d'état héritée. Les plages d'adresses IP sources des vérifications d'état héritées pour l'équilibrage de charge réseau sont les suivantes :

35.191.0.0/16
209.85.152.0/22
209.85.204.0/22

Console

Accédez à la page "Règles de pare-feu" de Google Cloud Console.
Accéder à la page "Règles 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-network-lb-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 : sélectionnez Entrée.
- Action en cas de correspondance : sélectionnez Autoriser.
- Cibles : sélectionnez Tags cibles spécifiés, puis saisissez des tags dans la zone de texte Tags cibles. Pour cet exemple, utilisez allow-network-lb-health-checks.
- Filtre source : sélectionnez Plages d'adresses IP.
- Plages d'adresses IP sources : 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22.
- Protocoles et ports autorisés : utilisez tcp. TCP est le protocole sous-jacent pour HTTP et HTTPS.
- Cliquez sur 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-network-lb-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-network-lb-health-checks qui autorise les connexions entrantes aux instances de votre réseau ayant le tag allow-network-lb-health-checks. Remplacez NETWORK_NAME par le nom de votre réseau.

    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

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-network-lb-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.

Établir l'association avec les équilibreurs de charge

Protocoles et équilibreurs de charge

Il est préférable d'utiliser une vérification d'état (ou une vérification d'état héritée) dont le protocole correspond à celui utilisé par le service de backend ou le pool cible de l'équilibreur de charge. Toutefois, les protocoles de vérification d'état et d'équilibreur de charge n'ont pas besoin d'être identiques. Par exemple :

Pour l'équilibrage de charge TCP/UDP interne, vous ne pouvez utiliser que TCP ou UDP comme protocole du service de backend. Si vous diffusez le trafic HTTP des VM derrière un équilibreur de charge interne, il est judicieux d'utiliser une vérification d'état utilisant le protocole HTTP.
Une vérification d'état héritée est limitée au protocole HTTP. Si vous utilisez un équilibreur de charge réseau pour équilibrer le trafic TCP, vous devez exécuter un service HTTP sur les VM faisant l'objet d'un équilibrage de charge de sorte qu'elles puissent répondre aux vérifications d'état.

Vérifications d'état pour les services de backend

Cette section explique comment associer une vérification d'état à un service de backend pour les types d'équilibreurs de charge suivants :

Équilibrage de charge TCP/UDP interne
Équilibrage de charge HTTP(S) interne
Équilibrage de charge proxy TCP
Équilibrage de charge proxy SSL
Équilibrage de charge HTTP(S)

Cette section suppose que vous avez déjà :

créé un équilibreur de charge interne, proxy TCP, proxy SSL ou HTTP(S) ;
créé une vérification d'état ;
configuré les règles de pare-feu pour les vérifications d'état.

Pour associer une vérification d'état à un nouvel équilibreur de charge interne, proxy TCP, proxy SSL ou HTTP(S), consultez le guide de configuration de l'équilibreur de charge correspondant.

Console

Pour associer une vérification d'état à un équilibreur de charge interne, proxy TCP, proxy SSL ou HTTP(S) existant :

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 équilibreur de charge interne, proxy TCP, proxy SSL ou HTTP(S) existant :

Identifiez le ou les services de backend utilisés par l'équilibreur de charge. Les équilibreurs de charge internes, proxy TCP et proxy SSL ne disposent que d'un seul service de backend pour l'intégralité de l'équilibreur de charge. Les équilibreurs de charge HTTP(S) ont un ou plusieurs services de backend associés à leur mappage d'URL.
- Pour répertorier les services de backend des équilibreurs de charge TCP/UDP internes, exécutez la commande suivante. Identifiez le nom et la région du service de backend.
```
    gcloud compute backend-services list \
        --filter="loadBalancingScheme=INTERNAL"
    
```
- Pour répertorier les services de backend des équilibreurs de charge HTTP(S) internes, exécutez la commande suivante. Identifiez le nom et la région du service de backend.
```
    gcloud compute backend-services list \
        --filter="loadBalancingScheme=INTERNAL_MANAGED"
    
```
- Pour répertorier les services de backend des équilibreurs de charge proxy TCP, exécutez la commande suivante.
```
    gcloud compute backend-services list \
        --filter="loadBalancingScheme=EXTERNAL" \
        --filter="protocol=TCP"
    
```
- Pour répertorier les services de backend des équilibreurs de charge proxy SSL, exécutez la commande suivante.
```
    gcloud compute backend-services list \
        --filter="loadBalancingScheme=EXTERNAL" \
        --filter="protocol=SSL"
    
```
- Pour identifier les services de backend pour l'équilibrage de charge HTTP(S), identifiez le mappage d'URL puis décrivez-le en remplaçant URL_MAP_NAME par son nom. Les services de backend qu'il utilise sont répertoriés dans la section pathMatchers de la réponse.
```
    gcloud compute url-maps list
    gcloud compute url-maps describe URL_MAP_NAME
    
```
Identifiez une vérification d'état. Si nécessaire, affichez les vérifications d'état.
Associez la vérification d'état au service de backend. Dans les commandes suivantes, remplacez BACKEND_SERVICE_NAME par le nom du service de backend et HEALTH_CHECK_NAME par le nom de la vérification d'état. Ces commandes remplacent toutes les vérifications d'état associées au service de backend. Dans la plupart des cas, une seule vérification d'état est associée au service de backend.
- Pour modifier la vérification d'état d'un service de backend pour un équilibreur de charge interne, exécutez la commande suivante. Les services de backend pour les équilibreurs de charge internes sont régionaux. Par conséquent, vous devez spécifier l'élément REGION en plus du nom.
```
    gcloud compute backend-services update BACKEND_SERVICE_NAME \
        --region REGION \
        --health-checks HEALTH_CHECK_NAME
    
```
- Pour modifier la vérification d'état d'un service de backend pour les équilibreurs de charge proxy TCP, proxy SSL et HTTP(S), exécutez la commande suivante :
```
    gcloud compute backend-services update BACKEND_SERVICE_NAME \
        --global \
        --health-checks HEALTH_CHECK_NAME
    
```

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

Vérifications d'état héritées pour l'équilibrage de charge réseau

Cette section explique comment associer une vérification d'état héritée à un pool cible pour l'équilibrage de charge réseau. Cette section suppose que vous avez déjà :

créé un équilibreur de charge réseau ;
créé une vérification d'état héritée ;
configuré les règles de pare-feu pour l'équilibrage de charge réseau.

Pour associer une vérification d'état héritée à un nouvel équilibreur de charge réseau, consultez la page Configurer l'équilibrage de charge réseau. Vous devez associer une vérification d'état héritée à son pool cible lorsque vous créez un équilibreur de charge réseau.

Console

Pour associer une vérification d'état à un équilibreur de charge réseau 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 réseau 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 existant, procédez comme suit :

Identifiez le ou les pools cibles. Les équilibreurs de charge réseau disposent d'au moins un pool cible et peuvent 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_HEALTH_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_HEALTH_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_HEALTH_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 vos ressources faisant l'objet d'une vérification d'état

Après avoir associé une vérification d'état à un service de backend ou à un pool cible, vous pouvez vous assurer que la ressource est opérationnelle.

Pour ce faire, exécutez l'une des commandes get-health de gcloud :

gcloud compute backend-services get-healthBACKEND_SERVICE_NAME
gcloud compute target-pools get-healthTARGET_POOL_NAME

Résoudre les problèmes liés aux vérifications d'état en bloquant les plages d'adresses IP

Dans certains cas, il est utile de provoquer l'échec des vérifications d'état. Cette opération est parfois nécessaire lors d'une opération de dépannage d'une VM ou dans le cadre de sa procédure d'arrêt.

Pour forcer l'échec d'une vérification d'état ou d'une vérification d'état ancienne, vous pouvez bloquer temporairement l'accès aux plages d'adresses IP qui lui sont associées. Cet exemple montre comment faire échouer des vérifications d'état à l'aide du logiciel de pare-feu iptables exécuté sur une VM Linux.

Pour provoquer l'échec des vérifications d'état et des vérifications d'état héritées d'une VM, connectez-vous à celles-ci et exécutez une commande iptables comme dans l'exemple suivant, en remplaçant HEALTH_CHECK_PORT par le numéro de port TCP approprié. Si vous devez faire échouer les vérifications d'une VM car elle est en cours d'arrêt, vous pouvez ajouter des commandes iptables comme celles ci-dessous à un script d'arrêt, suivies d'un délai approprié en fonction de l'intervalle entre deux tests de la vérification d'état et en fonction du seuil non sanitaire.

    $ 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

Pour supprimer les règles iptables, exécutez les commandes suivantes, en remplaçant HEALTH_CHECK_PORT par le port TCP de la vérification d'état.

    $ 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