Résoudre les problèmes liés aux vérifications de l'état d'Ingress

Cette page explique comment résoudre les problèmes liés aux vérifications de l'état Ingress dans Google Kubernetes Engine (GKE).

Comprendre le fonctionnement des vérifications de l'état Ingress

Avant de procéder au dépannage, il peut être utile de comprendre comment fonctionnent les vérifications de l'é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 uneé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 vérification de l'étatTrusted Cloud . 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 d'état pour tous les services de backend de l'équilibreur de charge, la référence de la vérification d'é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 de l'état selon l'une des méthodes suivantes :

  • CRD BackendConfig : définition de ressource personnalisée (CRD, Custom Resource Definition) qui vous permet de contrôler précisément la façon 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 de l'état associée au service de backend correspondant. Ces paramètres personnalisés offrent davantage de flexibilité et de contrôle sur les vérifications de l'é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 : contrôle de diagnostic qui détermine si un conteneur d'un pod est prêt à diffuser du trafic. Le contrôleur GKE Ingress crée la vérification de l'état 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éduire les paramètres de vérification de l'état (chemin d'accès, port et protocole, par exemple) de la définition de la vérification d'aptitude.
  • Valeurs par défaut : paramètres utilisés lorsque vous ne configurez pas de CRD BackendConfig ou ne définissez pas d'attributs pour la vérification d'aptitude.
Bonne pratique :

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

GKE utilise la procédure suivante pour créer une vérification d'é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 d'état en utilisant seulement les valeurs par défaut.

Remarques

Cette section présente quelques points à prendre en compte lorsque vous configurez un CRD BackendConfig ou utilisez une vérification de l'état de préparation.

BackendConfig CRD

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

  • Si vous utilisez l'équilibrage de charge natif en conteneurs, assurez-vous que le port de vérification de l'état dans le fichier manifeste BackendConfig correspond au containerPort d'un pod de diffusion.
  • 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.
  • Ingress n'est pas compatible avec gRPC pour les configurations de vérification de l'état personnalisées. La CRD 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 un CRD BackendConfig, consultez gke-networking-recipes.

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

Vérification de l'aptitude

Lorsque vous utilisez GKE Ingress avec l'équilibrage de charge HTTP ou HTTPS, GKE envoie des vérifications d'état pour déterminer si votre application s'exécute correctement. Ces tests de vérification de l'état d'état sont envoyés 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 de diffusion 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 d'entrée doit faire référence à un port valide de la section spec.ports[] de la configuration du service. Pour cela, deux possibilités s'offrent à vous :
    • 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#39;état

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

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

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

  1. Examinez l'état des pods : si la vérification de l'état d'état échoue, examinez l'état des pods de diffusion 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érifications d'état.

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

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

  4. Analysez 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 l'assistanceTrusted Cloud by S3NS pour obtenir de l'aide.

  5. Résolvez 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 demandes de vérification de l'état'état. Vérifiez que la vérification de l'état'état cible le bon chemin d'accès et le bon port sur les pods, puis examinez les journaux d'application, les fichiers de configuration et les dépendances. Si vous ne trouvez pas l'erreur, contactez l'assistance Trusted Cloud by S3NS .

L'application ne répond pas aux vérifications de l'é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 de l'état sur le chemin et le port configurés.

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

  • Groupes de points de terminaison du 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 configurés.
    • Des problèmes de connectivité réseau empêchent la vérification de l'état'é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 de l'état échouent, résolvez le problème 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 les 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 en bon état et qu'ils répondent aux vérifications d'état par défaut.
  2. Si les nœuds sont en bon état, 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 Trusted Cloud by S3NS pour obtenir de l'aide.

Erreur lors de la modification de la vérification de l'état de préparation sur le pod

Lorsque vous essayez de modifier la vérification d'aptitude d'un pod pour changer les paramètres de vérification de l'état;état, une erreur semblable à celle-ci s'affiche :

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à associé à un objet Ingress (et à l'équilibreur de charge correspondant), GKE ne met pas automatiquement à jour la configuration de la vérification de l'état d'é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 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 de l'état, et à intégrer les nouveaux paramètres de la vérification de disponibilité.

Le déploiement et l'équilibreur de charge ne démarrent pas

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

Le message d'erreur suivant peut s'afficher, mentionnant un échec de la vérification de l'état :

Readiness probe failed: connection refused

L'application du pod ne répond pas correctement à la vérification de disponibilité configurée dans la configuration YAML du pod. Cela peut être dû à diverses raisons, par exemple si l'application ne démarre pas correctement, si elle écoute le mauvais port ou si elle rencontre 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 et le port spécifiés dans les paramètres de la 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'entrée Ingress.

Règles de pare-feu d'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 d'entrée automatiques, que GKE crée généralement lorsqu'une ressource Ingress est créée, sont manquantes ou ont été supprimées par inadvertance.

Pour rétablir la connectivité à votre service de backend :

  • Vérifiez l'existence des règles de pare-feu d'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, tels que définis dans votre ressource Ingress.

Protocole incorrect utilisé dans le fichier manifeste BackendConfig

Si vous configurez un 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 CRD BackendConfig n'accepte que la création de vérifications de l'état à l'aide des protocoles HTTP, HTTPS ou HTTP/2. Pour en savoir plus, consultez Critères de réussite pour HTTP, HTTPS et HTTP/2.

Étapes suivantes