Résoudre les problèmes liés aux vérifications de l'état des entrées

Si les vérifications d'état Ingress échouent dans Google Kubernetes Engine (GKE), le trafic peut ne pas atteindre votre application, même si les pods sont en cours d'exécution.

Ce document explique le fonctionnement des vérifications d'état Ingress, les points à prendre en compte concernant BackendConfig et les vérifications d'aptitude, et comment diagnostiquer les problèmes tels que les applications qui ne répondent pas ou les règles de pare-feu manquantes.

Ces informations sont importantes pour les administrateurs et opérateurs de plate-forme, ainsi que pour les développeurs d'applications qui configurent et gèrent les ressources Ingress, et qui doivent s'assurer que leurs applications signalent correctement leur état à l'équilibreur de charge. Pour en savoir plus sur les rôles courants et les exemples de tâches auxquels nous faisons référence dans le Google Cloud contenu, consultez Rôles et tâches courants des utilisateurs GKE.

Comprendre le fonctionnement des vérifications d'état Ingress

Avant de passer aux étapes de dépannage, il peut être utile de comprendre le fonctionnement des vérifications d'état dans GKE et les points à prendre en compte pour garantir leur réussite.

Lorsque vous exposez un ou plusieurs services via un objet Ingress à l'aide du contrôleur d'entrée par défaut, GKE crée un équilibreur de charge d'application classique ou un équilibreur de charge d'application interne. Ces deux équilibreurs de charge acceptent plusieurs services de backend sur un même mappage d'URL. Chacun des services de backend correspond à un service Kubernetes, et chacun doit faire référence à une Google Cloud vérification d'état. Cette vérification de l'état est différente d'une vérification d'activité ou d'aptitude Kubernetes, car elle est mise en œuvre en dehors du cluster.

Les vérifications d'état de l'équilibreur de charge sont spécifiées par service de backend. Bien qu'il soit possible d'utiliser la même vérification de l'état pour tous les services de backend de l'équilibreur de charge, la référence de la vérification de l'état n'est pas spécifiée pour l'équilibreur de charge dans son ensemble (au niveau de l'objet Ingress proprement dit).

GKE crée des vérifications d'état selon l'une des méthodes suivantes :

  • CRD BackendConfig : définition de ressource personnalisée (CRD) qui vous permet de contrôler précisément la manière dont vos services interagissent avec l'équilibreur de charge. Les CRD BackendConfig vous permettent de spécifier des paramètres personnalisés pour la vérification d'état associée au service de backend correspondant. Ces paramètres personnalisés offrent une plus grande flexibilité et un meilleur contrôle sur les vérifications d'état pour l'équilibreur de charge d'application classique et l'équilibreur de charge d'application interne créés par un objet Ingress.
  • Vérification d'aptitude : vérification de diagnostic qui détermine si un conteneur dans un pod est prêt à diffuser du trafic. Le contrôleur GKE Ingress crée la vérification de l'état pour le service de backend du service en fonction de la vérification d'aptitude utilisée par les pods actifs de ce service. Vous pouvez dériver les paramètres de vérification de l'état tels que le chemin d'accès, le port et le protocole à partir de la définition de la vérification d'aptitude.
  • Valeurs par défaut : paramètres utilisés lorsque vous ne configurez pas de BackendConfig CRD ni ne définissez d'attributs pour la vérification d'aptitude.
Bonne pratique :

Utilisez une CRD BackendConfig pour contrôler au mieux les paramètres de vérification de l'état de l'équilibreur de charge.

GKE utilise la procédure suivante pour créer une vérification de l'état pour chaque service de backend correspondant à un service Kubernetes :

  • Si le service fait référence à une CRD BackendConfig contenant des informations healthCheck, GKE s'en sert pour créer la vérification d'état. Le contrôleur GKE Enterprise Ingress et le contrôleur GKE Ingress permettent tous deux de créer des vérifications d'état de cette manière.

  • Si le service ne fait pas référence à une CRD BackendConfig :

    • GKE peut déduire la totalité ou une partie des paramètres d'une vérification d'état si les pods actifs utilisent un modèle de pod avec un conteneur dont la vérification d'aptitude possède des attributs pouvant être interprétés comme des paramètres de vérification d'état. Consultez la section Paramètres d'une vérification d'aptitude pour en savoir plus sur la mise en œuvre, ainsi que la section Paramètres par défaut et paramètres déduits pour obtenir une liste des attributs pouvant être utilisés pour créer des paramètres de vérification d'état. Seul le contrôleur GKE Ingress permet de déduire les paramètres d'une vérification d'aptitude.

    • Si le modèle utilisé par les pods actifs du service ne possède pas de conteneur avec une vérification d'aptitude dont les attributs peuvent être interprétés comme des paramètres de vérification d'état, des valeurs par défaut sont utilisées pour créer la vérification d'état. Le contrôleur GKE Enterprise Ingress et le contrôleur GKE Ingress peuvent tous deux créer une vérification de l'état en utilisant seulement les valeurs par défaut.

Remarques

Cette section présente quelques points à prendre en compte lorsque vous configurez une CRD BackendConfig ou utilisez une vérification d'aptitude.

CRD BackendConfig

Lorsque vous configurez des CRD BackendConfig, tenez compte des points suivants :

  • Si vous utilisez l'équilibrage de charge natif en conteneur, assurez-vous que le port de vérification de l'état dans le fichier manifeste BackendConfig correspond au containerPort d'un pod actif.
  • Pour les backends de groupes d'instances, assurez-vous que le port de vérification de l'état dans le fichier manifeste BackendConfig correspond au nodePort exposé par le service.
  • La ressource Ingress n'est pas compatible avec gRPC pour les configurations de vérification de l'état personnalisées. Une ressource BackendConfig n'accepte que la création de vérifications de l'état à l'aide des protocoles HTTP, HTTPS ou HTTP2. Pour obtenir un exemple d'utilisation du protocole dans une BackendConfig CRD, consultez gke-networking-recipes.

Pour en savoir plus, consultez Quand utiliser des CRD BackendConfig.

Vérification d'aptitude

Lorsque vous utilisez GKE Ingress avec l'équilibrage de charge HTTP ou HTTPS, GKE envoie les vérifications d'état pour déterminer si votre application s'exécute correctement. Ces vérifications d'état sont envoyées au port spécifique de vos pods que vous avez défini dans la section spec.containers[].readinessProbe.httpGet.port de la configuration YAML de votre pod, à condition que les conditions suivantes soient remplies :

  • Le numéro de port de la vérification d'aptitude spécifié dans spec.containers[].readinessProbe.httpGet.port doit correspondre au port réel sur lequel votre application écoute dans le conteneur, qui est défini dans le champ containers[].spec.ports.containerPort de la configuration de votre pod.
  • L'élément containerPort du pod actif doit correspondre à l'élément targetPort du service. Cela garantit que le trafic est dirigé du service vers le port approprié de vos pods.
  • La spécification de port du backend de service Ingress doit faire référence à un port valide de la section spec.ports[] de la configuration de service. Vous pouvez procéder de deux manières :
    • spec.rules[].http.paths[].backend.service.port.name dans l'objet Ingress correspond à l'entrée spec.ports[].name définie dans le service correspondant.
    • spec.rules[].http.paths[].backend.service.port.number dans l'objet Ingress correspond à l'entrée spec.ports[].port définie dans le service correspondant.

Résoudre les problèmes courants liés vérification de l'état

Utilisez l'organigramme de dépannage suivant pour identifier les problèmes liés vérification de l'état :

Résoudre les problèmes liés aux vérifications d'état des entrées.
Figure : Résoudre les problèmes liés aux vérifications d'état

Dans cet organigramme, les conseils de dépannage suivants vous aident à déterminer l'origine du problème :

  1. Examiner l'état des pods : si la vérification de l'état échoue, examinez l' état des pods actifs de votre service. Si les pods ne sont pas en cours d'exécution et ne sont pas opérationnels :

    • Recherchez d'éventuelles erreurs ou problèmes dans les journaux des pods qui les empêchent de s'exécuter.
    • Vérifiez l'état des vérifications d'aptitude et d'activité.

  2. Journalisation des vérifications d'état : assurez-vous d'avoir activé la journalisation des vérification de l'état.

  3. Vérifier la configuration du pare-feu : assurez-vous que vos règles de pare-feu autorisent les vérifications d'état à atteindre vos pods. Si ce n'est pas le cas :

    • Vérifiez vos règles de pare-feu pour vous assurer qu'elles autorisent le trafic entrant provenant des plages d'adresses IP de vérification de l'état.
    • Ajustez les règles de pare-feu si nécessaire pour tenir compte de ces plages d'adresses IP.

  4. Analyser la capture de paquets : si le pare-feu est correctement configuré, effectuez une capture de paquets pour voir si votre application répond aux vérifications d'état. Si la capture de paquets affiche une réponse positive, contactez Google Cloud l'assistance pour obtenir de l'aide.

  5. Résoudre les problèmes liés à l'application : si la capture de paquets n'affiche pas de réponse positive, recherchez pourquoi votre application ne répond pas correctement aux requêtes de vérification de l'état. Vérifiez que la vérification de l'état cible le bon chemin d'accès et le bon port sur les pods, et examinez les journaux d'application, les fichiers de configuration et les dépendances. Si vous ne trouvez pas l'erreur, contactez l' Google Cloud assistance.

Application qui ne répond pas aux vérifications d'état

L'application ne répond pas avec le code d'état attendu (200 OK pour HTTP ou SYN, ACK pour TCP) lors des vérifications d'état sur le chemin d'accès et le port configurés.

Si votre application ne répond pas correctement aux vérifications d'état, cela peut être dû à l'une des raisons suivantes :

  • Groupes de points de terminaison réseau(NEG)
      :
    • L'application ne s'exécute pas correctement dans le pod.
    • L'application n'écoute pas sur le port ou le chemin d'accès configuré.
    • Des problèmes de connectivité réseau empêchent la vérification de l'état d'atteindre le pod.
  • **Groupe d'instances** :
    • Les nœuds du groupe d'instances ne sont pas opérationnels.
    • L'application ne s'exécute pas correctement sur les nœuds.
    • Les requêtes de vérification de l'état n'atteignent pas les nœuds.

Si vos vérifications d'état échouent, résolvez le problème comme suit, en fonction de votre configuration :

Pour les NEG :

  1. Accédez à un pod à l'aide de kubectl exec :

    kubectl exec -it pod-name -- command

    L'indicateur -it fournit une session de terminal interactive (i pour interactif, t pour TTY).

    Remplacez les éléments suivants :

    • pod-name : nom de votre pod.
    • command : commande que vous souhaitez exécuter dans le pod. La commande la plus courante est bash ou sh pour obtenir un shell interactif.

  2. Exécutez des commandes curl pour tester la connectivité et la réactivité de l'application :

    • curl localhost:<Port>/<Path>
    • curl -v http://<POD_IP>/[Path configured in HC]
    • curl http://localhost/[Path configured in HC]

Pour les groupes d'instances :

  1. Assurez-vous que les nœuds sont opérationnels et répondent aux vérifications d'état par défaut.
  2. Si les nœuds sont opérationnels, mais que le pod d'application ne répond pas, examinez l'application plus en détail.
  3. Si les requêtes n'atteignent pas les pods, il peut s'agir d'un problème de mise en réseau GKE. Contactez l'assistance pour obtenir de l'aide. Google Cloud

Erreur lors de la modification de la vérification d'aptitude sur le pod

Lorsque vous tentez de modifier la vérification d'aptitude sur un pod pour modifier les paramètres de vérification de l'état, une erreur semblable à la suivante se produit :

Pod "pod-name" is invalid: spec: Forbidden: pod updates may not change fields

Si vous modifiez la vérification d'aptitude des pods associés à un service déjà lié à un objet Ingress (et à son équilibreur de charge correspondant), GKE ne met pas automatiquement à jour la configuration de vérification de l'état sur l'équilibreur de charge. Cela entraîne une incohérence entre la vérification d'aptitude du pod et la vérification de l'état de l'équilibreur de charge, ce qui provoque l'échec de la vérification de l'état.

Pour résoudre ce problème, redéployez les pods et la ressource Ingress. Cela force GKE à recréer l'équilibreur de charge et ses vérifications d'état, et à intégrer les nouveaux paramètres de vérification d'aptitude.

Échec du démarrage du déploiement et de l'équilibreur de charge

Si votre déploiement ne démarre pas et que les services de backend situés derrière l'équilibreur de charge de votre contrôleur Ingress sont marqués comme non opérationnels, l'échec d'une vérification d'aptitude peut en être la cause.

Le message d'erreur suivant peut s'afficher et mentionner l'échec d'une vérification d'aptitude :

Readiness probe failed: connection refused

L'application dans le pod ne répond pas correctement à la vérification d'aptitude configurée dans la configuration YAML du pod. Cela peut être dû à diverses raisons, telles que le démarrage incorrect de l'application, l'écoute sur le mauvais port ou une erreur lors de l'initialisation.

Pour résoudre ce problème, examinez et corrigez les éventuelles incohérences dans la configuration ou le comportement de votre application en procédant comme suit :

  • Assurez-vous que l'application est correctement configurée et qu'elle répond sur le chemin d'accès et le port spécifiés dans les paramètres de vérification d'aptitude.
  • Examinez les journaux d'application et résolvez les problèmes ou erreurs de démarrage.
  • Vérifiez que le containerPort dans la configuration du pod correspond au targetPort dans le service et au port de backend spécifié dans l'objet Ingress.

Règles de pare-feu Ingress automatiques manquantes

Vous avez créé une ressource Ingress, mais le trafic n'atteint pas le service de backend.

Les règles de pare-feu Ingress automatiques, que GKE crée généralement lors de la création d'une ressource Ingress, sont manquantes ou ont été supprimées par inadvertance.

Pour rétablir la connectivité à votre service de backend, procédez comme suit :

  • Vérifiez l'existence des règles de pare-feu Ingress automatiques dans votre réseau VPC.
  • Si les règles sont manquantes, vous pouvez les recréer manuellement, ou supprimer et recréer la ressource Ingress pour déclencher leur création automatique.
  • Assurez-vous que les règles de pare-feu autorisent le trafic sur les ports et protocoles appropriés, comme défini dans votre ressource Ingress.

Protocole incorrect utilisé dans le fichier manifeste BackendConfig

Si vous configurez une CRD BackendConfig avec un protocole de type TCP, l'erreur suivante s'affiche :

Error syncing to GCP: error running backend syncing routine:
error ensuring health check: Protocol "TCP" is not valid, must be one of ["HTTP","HTTPS","HTTP2"]'

La ressource BackendConfig n'accepte que la création de vérifications de l'état à l'aide des protocoles HTTP, HTTPS ou HTTP/2. Pour plus d'informations, consultez la section Critères de réussite pour HTTP, HTTPS et HTTP/2.

Étape suivante