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 de l'état pour les équilibreurs de charge et Cloud Service Mesh.
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 de l'é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 vérificateurs 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 de l'état. Les options valides sont :grpc
,http
,https
,http2
,ssl
ettcp
.NAME
est le nom de la vérification d'état. Dans un projet donné, chaque vérification de l'état globale doit posséder un nom unique, et les vérifications de l'état régionales doivent posséder des noms uniques au sein d'une région donnée.REGION
: région de la vérification de l'état. Pour les équilibreurs de charge régionaux, la région de vérification de l'état 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 vérificateur de l'état et le début de la connexion suivante. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur5s
(cinq secondes).TIMEOUT
est la durée pendant laquelle Google Cloud attend une réponse du vérificateur. La valeur deTIMEOUT
doit être inférieure ou égale à celle deCHECK_INTERVAL
. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur5s
(cinq secondes).HEALTHY_THRESHOLD
etUNHEALTHY_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 sur2
.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 protocolePROTOCOL
. 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
.
Pour créer une vérification d'état régionale, utilisez la ressource google_compute_region_health_check.
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 de l'é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éehc-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 etREGION
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 :
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 et NEG compatibles |
L'indicateur |
Pools cibles | Les vérifications d'état héritées ne sont compatibles qu'avec la spécification par numéro de port (--port ). |
|
Équilibreur de charge réseau passthrough interne | Groupes d'instances et NEG compatibles |
L'indicateur |
Équilibreur de charge d'application externe global Équilibreur de charge d'application classique É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 interrégional Équilibreur de charge réseau proxy interne régional Cloud Service Mesh |
NEG compatibles |
|
Groupes d'instances |
|
Si vous omettez la spécification du port lors de la création de la vérification d'état, Google Cloud utilise les valeurs par défaut suivantes :
- Si le protocole de la vérification d'état est
TCP
ouHTTP
, il utilise--port=80
. - Si le protocole de la vérification d'état est
SSL
,HTTPS
ouHTTP2
, 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 valeurhttp
(HTTP/1.1 sans TLS),https
(HTTP/1.1 avec TLS) ouhttp2
(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 HTTPHost
. 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 surNONE
ouPROXY_V1
. En cas d'omission, Google Cloud utiliseNONE
. La valeurPROXY_V1
ajoute l'en-têtePROXY 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) oussl
. 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 surNONE
ouPROXY_V1
. En cas d'omission, Google Cloud utiliseNONE
. La valeurPROXY_V1
ajoute l'en-têtePROXY 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 diffusionSERVING
MyPackage.ServiceB
avec l'état de diffusionNOT_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 utiliserhttp-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 valeur5s
(cinq secondes).TIMEOUT
est la durée pendant laquelle Google Cloud attend une réponse à une vérification. La valeur deTIMEOUT
doit être inférieure ou égale à celle deCHECK_INTERVAL
. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur5s
(cinq secondes).HEALTHY_THRESHOLD
etUNHEALTHY_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 sur2
.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 utilise80
.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çantNAME
par son nom. Lorsque vous modifiez une vérification d'état héritée avecgcloud
, 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çantNAME
par son nom. Lorsque vous modifiez une vérification d'état héritée avecgcloud
, 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çantNAME
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çantNAME
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 Créer.
- Nom : attribuez un nom à la règle. Pour cet exemple, utilisez
- 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éefw-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 tagallow-health-checks
. En fonction du type d'équilibreur de charge, un autre ensemble de règles de pare-feu et d'intervalles d'adresses IP de vérification est accepté pour le trafic IPv6 vers les backends.Remplacez
NETWORK_NAME
par le nom de votre réseau VPC etPORT
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 et les équilibreurs de charge réseau proxy ne disposent que d'un seul service de backend par équilibreur de charge. Les équilibreurs de charge d'application ont un ou plusieurs services de backend associé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.
gcloud compute backend-services list \ --region=REGION \ --filter="loadBalancingScheme=INTERNAL"
Pour lister les services de backend des équilibreurs de charge réseau passthrough externes, exécutez la commande suivante.
gcloud compute backend-services list \ --region=REGION \ --filter="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 internes interrégionaux, exécutez la commande suivante.
gcloud compute backend-services list \ --global \ --filter="loadBalancingScheme=INTERNAL_MANAGED" \ --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 externes régionaux, exécutez la commande suivante.
gcloud compute backend-services list \ --region=REGION \ --filter="loadBalancingScheme=INTERNAL_MANAGED" \ --filter="protocol=(SSL,TCP)"
Pour identifier les services de backend des équilibreurs de charge d'application externes globaux, des équilibreurs de charge d'application classiques et des équilibreurs de charge d'application internes interrégionaux, 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 toujours globaux, 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. RemplacezURL_MAP_NAME
par le nom du mappage d'URL etREGION
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, remplacezBACKEND_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.
Pour associer une vérification d'état à un service de backend, utilisez l'un des appels d'API suivants :
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 etLEGACY_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çantNAME
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çantNAME
par le nom du pool cible etREGION
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.