Cette page explique comment résoudre les problèmes liés aux vérifications de l'état d'Ingress dans Google Kubernetes Engine (GKE).
Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.
Comprendre le fonctionnement des vérifications de l'état Ingress
Avant de procéder aux étapes de dépannage, il peut être utile de comprendre le fonctionnement des vérifications d'état dans GKE et les considérations à prendre en compte pour que les vérifications d'état soient réussies.
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 d'étatGoogle 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 en fonction de 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 façon dont vos services interagissent avec l'équilibreur de charge. Les CRDBackendConfig
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 une plus grande flexibilité et un meilleur contrôle sur les vérifications d'état de l'équilibreur de charge d'application classique et de l'équilibreur de charge d'application interne créé 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 de l'état pour le service de backend 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'état tels que le chemin, 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 CRD
BackendConfig
ni ne définissez d'attributs pour la vérification d'aptitude.
Utilisez un CRD BackendConfig
pour contrôler au maximum 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 informationshealthCheck
, 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 un test de préparation.
CRD BackendConfig
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 aucontainerPort
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 aunodePort
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 CRDBackendConfig
, consultez gke-networking-recipes.
Pour en savoir plus, consultez la section Quand utiliser des CRD BackendConfig
.
Vérification de l'aptitude
Lorsque vous utilisez GKE Ingress avec un équilibrage de charge HTTP ou HTTPS, GKE envoie les vérifications d'état pour déterminer si votre application s'exécute correctement. Ces sondes de vérification de l'é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 champcontainers[].spec.ports.containerPort
de la configuration de votre pod. - Le
containerPort
du pod de diffusion doit correspondre autargetPort
du service. Cela garantit que le trafic est dirigé du service vers le port approprié sur 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 ce faire, procédez de l'une des deux manières suivantes :spec.rules[].http.paths[].backend.service.port.name
dans l'objet Ingress correspond àspec.ports[].name
défini dans le service correspondant.spec.rules[].http.paths[].backend.service.port.number
dans l'objet Ingress correspond àspec.ports[].port
défini 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'état:
Dans cet organigramme, les conseils de dépannage suivants vous aident à déterminer l'origine du problème:
Examiner 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:
- Vérifiez les journaux du pod pour détecter d'éventuelles erreurs ou problèmes qui l'empêchent de s'exécuter.
- Vérifiez l'état des vérifications d'aptitude et d'activité.
Journalisation des vérifications d'état: assurez-vous d'avoir activé la journalisation des vérifications d'état.
Vérifiez la configuration du pare-feu: assurez-vous que vos règles de pare-feu autorisent les sondes de vérification de l'état'é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 la sonde de vérification de l'état d'état.
- Ajustez les règles de pare-feu si nécessaire pour prendre en charge ces plages d'adresses IP.
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 indique une réponse réussie, contactez l'assistanceGoogle Cloud pour obtenir de l'aide.
Dépannage de 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'état cible le bon chemin 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 Google Cloud .
Application qui 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 d'accès 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, en fonction de votre configuration, procédez comme suit pour résoudre le problème:
Pour les NEG:
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 "interactive", 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 estbash
oush
pour obtenir un shell interactif.
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:
- Assurez-vous que les nœuds sont opérationnels et répondent aux vérifications d'état par défaut.
- Si les nœuds sont opérationnels, mais que le pod de l'application ne répond pas, examinez l'application plus en détail.
- Si les requêtes n'atteignent pas les pods, il peut s'agir d'un problème de réseau GKE. Contactez l'assistance Google Cloud pour obtenir de l'aide.
Erreur lors de la modification de la sonde de préparation sur le pod
Lorsque vous essayez de modifier la vérification d'aptitude d'un pod pour modifier 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 Ingress (et à son é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 un décalage entre la vérification de l'aptitude du pod et la vérification de l'état de l'équilibreur de charge, ce qui entraîne 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 oblige GKE à recréer l'équilibreur de charge et ses vérifications de l'état, et à intégrer les nouveaux paramètres de la sonde de préparation.
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 sonde de préparation:
Readiness probe failed: connection refused
L'application du pod ne répond pas correctement à la sonde 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 sur le mauvais port ou si elle rencontre une erreur lors de l'initialisation.
Pour résoudre ce problème, examinez et corrigez les écarts de configuration ou de 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 la sonde de disponibilité.
- Examinez les journaux de l'application et corrigez les erreurs ou les problèmes de démarrage.
- Vérifiez que le
containerPort
de la configuration du pod correspond autargetPort
du service et au port de backend spécifié dans l'objet 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 restaurer la connectivité avec votre service de backend, procédez comme suit:
- 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, comme défini 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"]'
BackendConfig
permet de créer des vérifications de l'état à l'aide des protocoles HTTP, HTTPS ou HTTP/2 uniquement. Pour en savoir plus, consultez la section Critères de réussite pour HTTP, HTTPS et HTTP/2.
Étape suivante
Pour configurer des vérifications de l'état personnalisées pour Ingress dans un seul cluster, consultez les recettes de mise en réseau GKE.