Cette page a été traduite par l'API Cloud Translation.

Configurer les vérifications d'état

Google Distributed Cloud (GDC) air-gapped propose des mécanismes de vérification de l'é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.

Sauf indication contraire,les vérifications de l'état Google Cloud sont implémentées par des tâches logicielles dédiées qui se connectent aux backends en fonction des paramètres spécifiés dans une ressource de vérification de l'état'état. Chaque tentative de connexion est appelée vérification. Google Cloud enregistre la réussite ou l'échec de chaque vérification.

L'état de fonctionnement de chaque backend est déterminé par un nombre configurable de vérifications consécutives ayant réussi ou échoué. En d'autres termes, vous configurez le nombre de vérifications consécutives réussies nécessaires pour marquer un backend comme opérationnel et le nombre d'échecs consécutifs pour le marquer comme non opérationnel.

Cet état de fonctionnement détermine si un backend peut recevoir de nouvelles requêtes ou connexions. Un backend non opérationnel, tel qu'identifié par la vérification de l'état l'état, ne recevra pas de trafic via l'équilibreur de charge. Vous définissez les critères de réussite d'une vérification. Pour en savoir plus, consultez la section Fonctionnement des vérifications d'état.

Protocoles de vérification de l'état

Les vérifications de l'état sont compatibles avec les protocoles suivants :

TCP
HTTP
HTTPS

Sélectionner une vérification de l'état

Les vérifications d'état doivent être compatibles avec le type d'équilibreur de charge et les types de backend. Tenez compte des facteurs suivants lorsque vous sélectionnez une vérification de l'état;état :

Protocole : protocole utilisé par GDC pour vérifier les backends. Les protocoles compatibles sont TCP, HTTP et HTTPS. Le protocole TCP est utile pour les vérifications d'état de base qui valident la connectivité à un backend, tandis que les protocoles HTTP et HTTPS fournissent des mécanismes de vérification d'état plus précis pour les VM qui exécutent déjà des charges de travail HTTP ou HTTPS.
Spécification de port : port utilisé par GDC avec le protocole pour vérifier l'état d'un backend. Vous devez spécifier un port pour votre vérification d'état.
Catégorie : les vérifications d'état peuvent être globales ou zonales. Les vérifications d'état globales s'étendent à toutes les zones d'un déploiement GDC, tandis que les vérifications d'état zonales correspondent à une seule zone.

Fonctionnement des vérifications d'état

Les sections suivantes décrivent le fonctionnement des vérifications d'état.

Vérifications

Lorsque vous établissez une vérification de l'état#39;état, vous définissez ou acceptez les paramètres par défaut qui régissent la fréquence à laquelle chaque vérification évalue l'état des points de terminaison associés. Ces paramètres sont essentiels, car l'équilibreur de charge cesse de router les requêtes vers un backend considéré comme non opérationnel en fonction des critères que vous avez configurés. La vérification d'état persistera dans ses évaluations et reprendra l'envoi de trafic au backend une fois qu'il sera de nouveau considéré comme opérationnel.

Il est important de noter que les paramètres de vérification de l'état de l'état s'appliquent de manière uniforme à tous les backends d'un service de backend ou d'un pool cible, et qu'ils ne peuvent pas être configurés par backend.

Indicateur de configuration	Explication	Valeur par défaut
intervalle entre deux tests `check-interval`	Durée (en secondes) entre le début d'un test et le début du test suivant par le même vérificateur.	`5s` (5 secondes)
timeoutSec `timeoutSec`	Délai d'attente (en secondes) pour une vérification avant de la considérer comme ayant échoué.	`5s` (5 secondes)
healthyThreshold `healthyThreshold`	Nombre de vérifications séquentielles qui doivent réussir pour que le point de terminaison soit considéré comme opérationnel.	2
unhealthyThreshold `unhealthyThreshold`	Nombre de tests séquentiels qui doivent échouer pour que le point de terminaison soit considéré comme non opérationnel.	2

Critères de réussite pour les vérifications d'état HTTP et HTTPS

Pour les vérifications d'état HTTP et HTTPS, un code d'état HTTP 200 (OK) est requis pour une réponse réussie avant l'expiration du délai de la vérification de l'état d'état. Les autres codes de réponse HTTP, y compris les redirections (par exemple, 301, 302), sont considérés comme non opérationnels.

En plus d'exiger un code de réponse HTTP 200 (OK), vous pouvez :

Configurez chaque vérificateur d'état pour qu'il envoie des requêtes HTTP vers un chemin de requête spécifique au lieu du chemin de requête par défaut,/.
Configurez chaque vérificateur d'état pour qu'il vérifie la présence d'une chaîne de réponse attendue dans le corps de la réponse HTTP. La chaîne de réponse attendue doit être composée uniquement de caractères ASCII imprimables mono-octets, situés dans les 1 024 premiers octets du corps de la réponse HTTP.

Le tableau suivant liste les combinaisons valides des champs requestPath et response disponibles pour les vérifications d'état HTTP et HTTPS.

Options de configuration	Comportement du vérificateur	Critères de réussite
Ni RequestPath ni Response spécifiés	Le vérificateur utilise `/` comme chemin d'accès à la requête.	Code de réponse HTTP `200 (OK)` uniquement.
RequestPath et Response sont spécifiés	Le vérificateur utilise le chemin d'accès à la requête configuré.	Le code de réponse `200 (OK)` HTTP et les 1 024 premiers caractères ASCII du corps de la réponse HTTP doivent correspondre à la chaîne de réponse attendue.
Seule la réponse est spécifiée	Le vérificateur utilise `/` comme chemin d'accès à la requête.	Le code de réponse `200 (OK)` HTTP et les 1 024 premiers caractères ASCII du corps de la réponse HTTP doivent correspondre à la chaîne de réponse attendue.
Seul RequestPath est spécifié	Le vérificateur utilise le chemin d'accès à la requête configuré.	Code de réponse HTTP `200 (OK)` uniquement.

Critères de réussite pour les vérifications d'état TCP

Les vérifications d'état TCP ont les critères de réussite de base suivants :

Pour les vérifications d'état TCP, un vérificateur d'état doit ouvrir une connexion TCP vers le backend avant le délai d'expiration de la vérification de l'état d'état.
Pour les vérifications d'état TCP, la connexion TCP doit être fermée de l'une des manières suivantes :
- Par le vérificateur d'état qui envoie un paquet FIN ou RST (reset).
- Par le backend qui envoie un paquet FIN.
- Si un backend envoie un paquet TCP RST, la vérification peut être considérée comme un échec si le vérificateur d'état a déjà envoyé un paquet FIN.

Avant de commencer

Pour configurer des tests de vérification de l'état, vous devez disposer des éléments suivants :

Être propriétaire du projet pour lequel vous configurez l'équilibreur de charge. Pour en savoir plus, consultez Créer un projet.
Rôles d'identité et d'accès nécessaires :
- Demandez à votre administrateur IAM de l'organisation de vous attribuer le rôle Administrateur de l'équilibreur de charge (load-balancer-admin).
- Pour les équilibreurs de charge internes mondiaux, demandez à votre administrateur IAM de l'organisation de vous attribuer le rôle Administrateur de l'équilibreur de charge mondial (global-load-balancer-admin). Pour en savoir plus, consultez Descriptions des rôles prédéfinis.

Créer et gérer des vérifications d'état

GDC est compatible avec les vérifications d'état mondiales et zonales.

API HealthCheck

Vous pouvez configurer un objet HealthCheck comme global ou zonal. Les objets HealthCheck globaux sont utilisés pour les configurations d'équilibreur de charge global, tandis que les objets HealthCheck zonaux sont utilisés pour les configurations d'équilibreur de charge zonal. Les deux types ont le même nom et la même spécification. Toutefois, ils utilisent des valeurs apiVersion et des serveurs d'API différents :

apiVersion zonal : networking.gdc.goog
apiVersion global : networking.global.gdc.goog

Vous pouvez également utiliser la CLI gdcloud pour créer et gérer des vérifications de l'état.

Créer un `HealthCheck` global

L'exemple suivant montre comment créer une vérification de l'état à l'aide de l'API :

  kubectl --kubeconfig GLOBAL_ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.global.gdc.goog/v1 
  kind: HealthCheck 
  metadata: 
    namespace: PROJECT 
    name: my-hc 
  spec: 
    httpHealthCheck: 
      port: PORT 
      host: HOST 
      requestPath: requestPath 
      response: responseT 
  EOF

Créer un `HealthCheck` zonal

L'exemple suivant montre comment créer une vérification de l'état à l'aide de l'API :

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.gdc.goog/v1
  kind: HealthCheck
  metadata:
    namespace: PROJECT
    name: my-hc
  spec:
    httpHealthCheck:
      port: PORT
      host: HOST
      requestPath: requestPath 
      response: response 
  EOF

Pour associer une vérification de l'état à un équilibreur de charge, consultez les ressources suivantes :

Vérification de la configuration

Pour vous assurer que la configuration est correcte, vérifiez l'état Ready de l'objet HealthCheck. Cette condition indique toute erreur de configuration. Vérifiez également que les champs reflètent précisément les paramètres HealthCheck requis.

Notes supplémentaires sur l'utilisation

Les sections suivantes incluent des notes supplémentaires sur l'utilisation des vérifications de l'état sur Google Cloud.

Certificats et vérifications d'état

Pour les protocoles tels que HTTPS, qui exigent des certificats sur vos backends,

Les certificats peuvent être autosignés ou provenir de n'importe quelle autorité de certification.
Les certificats expirés ou dont la date de validité est future sont acceptés.

Headers

Lorsque vous configurez des vérifications d'état pour les protocoles HTTP ou HTTPS, vous pouvez spécifier un en-tête HTTP Host à l'aide de l'option --host.

Il est important de noter que l'équilibreur de charge n'ajoute les en-têtes de requêtes personnalisés que vous configurez qu'aux requêtes client, et non aux vérifications d'état. Par conséquent, si votre backend nécessite un en-tête spécifique pour l'autorisation qui ne figure pas dans le paquet de vérification de l'état;état, la vérification de l'état d'état peut échouer.

Exemple de vérification d'état

Si une vérification de l'état est configurée avec les paramètres suivants :

Intervalle : 30 secondes
Délai avant expiration : 5 secondes
Protocole : HTTP
Seuil de faible capacité : 2 (valeur par défaut)
Seuil opérationnel : 2 (valeur par défaut)

La vérification de l'état fonctionnera comme suit :

Chaque vérificateur d'état :
1. Établissement d'une connexion HTTP entre une adresse IP source et l'instance de backend toutes les 30 secondes.
2. Attente d'un code d'état 200 (OK) HTTP pendant cinq secondes au maximum (critère de réussite désigné pour les protocoles HTTP et HTTPS).
Un backend est considéré comme non opérationnel si au moins un système de vérification d'état remplit les conditions suivantes :
1. Deux vérifications consécutives ne reçoivent pas de réponse HTTP 200 (OK) en raison d'une connexion refusée, d'un délai avant expiration de la connexion ou d'un délai avant expiration du socket.
2. Les deux réponses consécutives reçues ne correspondent pas aux critères de réussite spécifiques au protocole.
Un backend est considéré comme opérationnel lorsqu'au moins un système de vérification d'état reçoit deux réponses consécutives qui répondent aux critères de réussite spécifiques au protocole.

Dans cet exemple, chaque vérificateur établit une connexion toutes les 30 secondes. Trente secondes s'écoulent entre les tentatives de connexion d'un vérificateur, quelle que soit la durée du délai avant expiration (que la connexion ait expiré ou non). En d'autres termes, le délai avant expiration doit toujours être inférieur ou égal à l'intervalle, et il n'augmente jamais celui-ci.

Limites

Les vérifications d'état GDC ne s'appliquent qu'aux points de terminaison des VM.
Les équilibreurs de charge avec vérifications de l'état ne peuvent pas être configurés avec des pods et des VM comme backends mixtes. Un équilibreur de charge doit être constitué uniquement de pods ou uniquement de VM comme points de terminaison. Pour le moment, un équilibreur de charge doit être constitué uniquement de pods ou uniquement de VM comme points de terminaison.
La mutabilité de l'équilibreur de charge et de la vérification de l'état associée n'est pas encore prise en charge.