Dépannage

Cette page présente des stratégies de dépannage et des solutions pour certaines erreurs courantes.

Lors du dépannage de Knative serving, vérifiez d'abord que vous pouvez exécuter votre image de conteneur localement.

Si votre application ne s'exécute pas localement, vous devrez diagnostiquer et résoudre le problème. Pour déboguer un projet déployé, vous devez utiliser Cloud Logging.

Lors de la résolution de problèmes liés à Knative serving, consultez les sections suivantes afin de trouver des solutions possibles.

Vérifier le résultat de la ligne de commande

Si vous utilisez la CLI Google Cloud, vérifiez le résultat de votre commande pour voir si elle a abouti ou non. Par exemple, si votre déploiement a échoué, un message d'erreur décrivant la raison de l'échec devrait être affiché.

Les échecs de déploiement sont probablement dus à un manifeste mal configuré ou à une commande incorrecte. Par exemple, le résultat suivant indique que vous devez configurer le pourcentage de trafic acheminé pour que le total soit égal à 100.

Error from server (InternalError): error when applying patch:</p><pre>{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"serving.knative.dev/v11\",\"kind\":\"Route\",\"metadata\":{\"annotations\":{},\"name\":\"route-example\",\"namespace\":\"default\"},\"spec\":{\"traffic\":[{\"configurationName\":\"configuration-example\",\"percent\":50}]}}\n"}},"spec":{"traffic":[{"configurationName":"configuration-example","percent":50}]}}
to:
&{0xc421d98240 0xc421e77490 default route-example STDIN 0xc421db0488 264682 false}
for: "STDIN": Internal error occurred: admission webhook "webhook.knative.dev" denied the request: mutation failed: The route must have traffic percent sum equal to 100.
ERROR: Non-zero return code '1' from command: Process exited with status 1

Vérifier les journaux de votre service

Vous pouvez utiliser Cloud Logging ou la page Knative serving de la console Google Cloud pour vérifier les journaux de requêtes et les journaux de conteneur. Pour plus de précisions, consultez la page Journaliser et afficher les journaux.

Si vous utilisez Cloud Logging, la ressource sur laquelle vous devez filtrer est Conteneur Kubernetes.

Vérifier l'état du service

Exécutez la commande suivante pour obtenir l'état d'un service Knative serving déployé :

gcloud run services describe SERVICE

Vous pouvez ajouter --format yaml(status) ou --format json(status) pour obtenir l'état complet, par exemple :

gcloud run services describe SERVICE --format 'yaml(status)'

Les conditions dans status peuvent vous aider à déterminer la cause de l'échec. Les conditions peuvent inclure True, False ou Unknown :

Pour en savoir plus sur les conditions d'état, consultez la section Signalement d'erreur Knative.

Vérifier l'état de la route

Chaque service Knative serving gère une route qui représente l'état de routage actuel par rapport aux révisions du service.

Pour vérifier l'état général de la route, consultez l'état du service :

gcloud run services describe SERVICE --format 'yaml(status)'

La condition RoutesReady dans status indique l'état de la route.

Vous pouvez analyser plus en détail l'état de la route en exécutant la commande suivante :

kubectl get route SERVICE -o yaml

Les conditions dans status fournissent le motif d'un échec. par exemple les éléments suivants :

  • Ready indique si le service est configuré et dispose de backends disponibles. Si la valeur est true, la route est configurée correctement.

  • AllTrafficAssigned indique si le service est configuré correctement et dispose de backends disponibles. Si status de cette condition n'est pas défini sur True :

    • Vérifiez si la répartition du trafic entre les révisions de votre service est égale à 100 % :

      gcloud run services describe SERVICE

      Si ce n'est pas le cas, ajustez la répartition du trafic à l'aide de la commande gcloud run services update-traffic.

    • Vérifiez l'état de la révision pour identifier les révisions recevant du trafic.

  • IngressReady indique que l'entrée est prête. Si status de cette condition n'est pas défini sur True, vérifiez l'état d'entrée.

  • CertificateProvisioned indique si les certificats Knative ont été provisionnés. Si status de cette condition n'est pas défini sur True, essayez de résoudre les problèmes liés aux certificats TLS gérés.

Pour en savoir plus sur les conditions d'état, consultez la section Création de rapports et conditions d'erreur Knative.

Vérifier l'état de l'entrée

Knative serving utilise un service d'équilibrage de charge appelé istio-ingressgateway, qui est chargé de gérer le trafic entrant provenant de l'extérieur du cluster.

Pour obtenir l'adresse IP externe de l'équilibreur de charge, exécutez la commande suivante :

kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

Remplacez ASM-INGRESS-NAMESPACE par l'espace de noms où se trouve votre entrée Cloud Service Mesh. Spécifiez istio-system si vous avez installé Cloud Service Mesh à l'aide de sa configuration par défaut.

La sortie ressemble à ceci :

NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

où la valeur EXTERNAL-IP est votre adresse IP externe de l'équilibreur de charge.

Si le champ EXTERNAL-IP est défini sur pending, EXTERNAL-IP affiche l'état pending depuis longtemps.

Vérifier l'état de la révision

Pour obtenir la dernière révision de votre service Knative serving, exécutez la commande suivante :

gcloud run services describe SERVICE --format='value(status.latestCreatedRevisionName)'

Exécutez la commande suivante pour obtenir l'état d'une révision de service Knative spécifique :

gcloud run revisions describe REVISION

Vous pouvez ajouter --format yaml(status) ou --format json(status) pour obtenir l'état complet :

gcloud run revisions describe REVISION --format yaml(status)

Les conditions dans status fournissent les raisons d'un échec. par exemple les éléments suivants :

  • Ready indique si les ressources d'environnement d'exécution sont prêtes. Si la valeur est true, la révision est configurée correctement.
  • ResourcesAvailable indique si les ressources Kubernetes sous-jacentes ont été provisionnées. Si status de cette condition n'est pas défini sur True, vérifiez l'état du pod.
  • ContainerHealthy indique si la vérification de préparation de la révision est terminée. Si status de cette condition n'est pas défini sur True, vérifiez l'état du pod.
  • Active : indique si la révision reçoit du trafic.

Si l'un des status de ces conditions n'est pas défini sur True, vérifiez l'état du pod.

Vérifier l'état du pod

Pour obtenir les pods de tous vos déploiements, exécutez la commande suivante :

kubectl get pods

Ceci devrait répertorier tous les pods dont l'état est bref. Exemple :

NAME                                                      READY     STATUS             RESTARTS   AGE
configuration-example-00001-deployment-659747ff99-9bvr4   2/2       Running            0          3h
configuration-example-00002-deployment-5f475b7849-gxcht   1/2       CrashLoopBackOff   2          36s

Choisissez-en un et utilisez la commande suivante pour afficher des informations détaillées sur son status. Voici quelques champs conditions et containerStatuses utiles :

kubectl get pod POD-NAME -o yaml

EXTERNAL-IP affiche l'état <pending> depuis longtemps

Parfois, il est possible que vous ne receviez pas d'adresse IP externe immédiatement après la création d'un cluster, mais qu'une adresse IP externe apparaisse avec l'état pending. Par exemple, cela peut se produire en appelant la commande suivante :

Pour obtenir l'adresse IP externe de l'équilibreur de charge, exécutez la commande suivante :

kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

Remplacez ASM-INGRESS-NAMESPACE par l'espace de noms où se trouve votre entrée Cloud Service Mesh. Spécifiez istio-system si vous avez installé Cloud Service Mesh à l'aide de sa configuration par défaut.

La sortie ressemble à ceci :

NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

où la valeur EXTERNAL-IP est votre adresse IP externe de l'équilibreur de charge.

Cela peut signifier que vous avez épuisé votre quota d'adresses IP externes dans Google Cloud. Vous pouvez vérifier la cause possible en appelant la commande suivante :

kubectl describe svc istio-ingressgateway -n INGRESS_NAMESPACE
où INGRESS_NAMESPACE est l'espace de noms de l'entrée ASM qui, par défaut, est "istio-system". Le résultat ressemble à ce qui suit :
Name:                     istio-ingressgateway
Namespace:                INGRESS_NAMESPACE
Labels:                   app=istio-ingressgateway
                          istio=ingressgateway
                          istio.io/rev=asm-1102-3
                          operator.istio.io/component=IngressGateways
                          operator.istio.io/managed=Reconcile
                          operator.istio.io/version=1.10.2-asm.3
                          release=istio
Annotations:              kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"addonmanager.kubernetes.io/mode":"Reconcile","app":"istio-ingressgateway","...
Selector:                 app=istio-ingressgateway,istio=ingressgateway
Type:                     LoadBalancer
IP:                       10.XX.XXX.XXX
LoadBalancer Ingress:     35.XXX.XXX.188
Port:                     http2  80/TCP
TargetPort:               80/TCP
NodePort:                 http2  31380/TCP
Endpoints:                XX.XX.1.6:80
Port:                     https  443/TCP
TargetPort:               443/TCP
NodePort:                 https  3XXX0/TCP
Endpoints:                XX.XX.1.6:XXX
Port:                     tcp  31400/TCP
TargetPort:               3XX00/TCP
NodePort:                 tcp  3XX00/TCP
Endpoints:                XX.XX.1.6:XXXXX
Port:                     tcp-pilot-grpc-tls  15011/TCP
TargetPort:               15011/TCP
NodePort:                 tcp-pilot-grpc-tls  32201/TCP
Endpoints:                XX.XX.1.6:XXXXX
Port:                     tcp-citadel-grpc-tls  8060/TCP
TargetPort:               8060/TCP
NodePort:                 tcp-citadel-grpc-tls  31187/TCP
Endpoints:                XX.XX.1.6:XXXX
Port:                     tcp-dns-tls  853/TCP
TargetPort:               XXX/TCP
NodePort:                 tcp-dns-tls  31219/TCP
Endpoints:                10.52.1.6:853
Port:                     http2-prometheus  15030/TCP
TargetPort:               XXXXX/TCP
NodePort:                 http2-prometheus  30944/TCP
Endpoints:                10.52.1.6:15030
Port:                     http2-grafana  15031/TCP
TargetPort:               XXXXX/TCP
NodePort:                 http2-grafana  31497/TCP
Endpoints:                XX.XX.1.6:XXXXX
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type    Reason                Age                  From                Message
  ----    ------                ----                 ----                -------
  Normal  EnsuringLoadBalancer  7s (x4318 over 15d)  service-controller  Ensuring load balancer

Si le résultat indique que le quota IN_USE_ADDRESSES a été dépassé, vous pouvez demander un quota supplémentaire en accédant à la page IAM et admin de Google Cloud Console.

La passerelle poursuivra les tentatives jusqu'à ce qu'une adresse IP externe soit attribuée. Cela peut prendre quelques minutes.

Résoudre les problèmes liés aux domaines personnalisés et aux certificats TLS gérés

Suivez les étapes de dépannage ci-dessous pour résoudre les problèmes généraux liés aux domaines personnalisés et la fonctionnalité des certificats TLS gérés.

Domaines personnalisés pour les réseaux privés internes

Si vous avez mappé un domaine personnalisé à votre cluster ou à vos services Knative serving au sein d'un réseau privé interne, vous devez désactiver les certificats TLS gérés sinon la configuration de votre domaine ne pourra pas atteindre l'état ready. Par défaut, l'équilibreur de charge interne ne peut pas communiquer en externe avec l'autorité de certification.

Vérifier l'état d'un mappage de domaine spécifique

Pour vérifier l'état d'un mappage de domaine spécifique, procédez comme suit :

  1. Exécutez la commande suivante :

    gcloud run domain-mappings describe --domain DOMAIN --namespace NAMESPACE

    Remplacer

    • DOMAIN par le nom du domaine que vous utilisez ;
    • NAMESPACE par l'espace de noms que vous utilisez pour le mappage de domaine.

  2. Dans les résultats yaml de cette commande, examinez la condition du champ CertificateProvisioned pour déterminer la nature de l'erreur.

  3. Si une erreur s'affiche, elle doit correspondre à l'une des erreurs répertoriées dans les tableaux ci-dessous. Pour résoudre le problème, suivez les instructions figurant dans les tableaux.

Erreurs de configuration utilisateur

Code d'erreur Détails
DNSErrored Message : DNS record is not configured correctly. Need to map domain [XXX] to IP XX.XX.XX.XX (L'enregistrement DNS n'est pas configuré correctement. Associez le domaine [XXX] à l'adresse IP XX.XX.XX.XX)

Suivez les instructions fournies pour configurer correctement l'enregistrement DNS.

RateLimitExceeded Message :acme: urn:ietf:params:acme:error:rateLimited: Error creating new order
:: too many certificates already issued for exact set of domains:
test.your-domain.com :
https://letsencrypt.org/docs/rate-limits/ (Erreur lors de la création d'une nouvelle commande : trop de certificats déjà émis pour un ensemble de domaines exact : test.your-domain.com : https://letsencrypt.org/docs/rate-limits/)

Le quota Let's Encrypt a été dépassé. Vous devez augmenter votre quota de certificats Let's Encrypt pour cet hôte.

InvalidDomainMappingName Message : DomainMapping name %s cannot be the same as Route URL host %s. (Le % de nom DomainMapping ne peut pas être identique au % de l'hôte de l'URL de routage).

Le nom DomainMapping ne peut pas être exactement le même que celui de l'hôte de la route vers lequel il est mappé. Utilisez un domaine différent pour le nom DomainMapping.

ChallengeServingErrored Message : System failed to serve HTTP01 request (Le système n'a pas réussi à répondre à la requête HTTP01).

Cette erreur peut se produire si le service istio-ingressgateway ne parvient pas à traiter la requête de Let's Encrypt pour valider la propriété du domaine.

  1. Assurez-vous que votre service istio-ingressgateway est accessible depuis l'Internet public sans utiliser le cloud privé virtuel.
  2. Assurez-vous que votre service istio-ingressgateway accepte les requêtes provenant de l'URL http://DOMAIN/.well-known/acme-challenge/..., où DOMAIN correspond au domaine en cours de validation.

Erreurs système

Code d'erreur Détails
OrderErrored

AuthzErrored

ChallengeErrored

Ces trois types d'erreurs se produisent en cas d'échec de validation de la propriété du domaine par Let's Encrypt.

Ces erreurs sont généralement des erreurs temporaires et Knative serving effectue de nouvelles tentatives.

Le délai entre les tentatives croît exponentiellement, avec un minimum de 8 secondes et un maximum de 8 heures.

Si vous souhaitez relancer manuellement la commande, supprimez d'abord celle qui a échoué :

kubectl delete order DOMAIN -n NAMESPACE

ACMEAPIFailed Ce type d'erreur se produit lorsque Knative serving ne parvient pas à appeler Let's Encrypt. Il s'agit généralement d'une erreur temporaire et Knative serving effectue de nouvelles tentatives.

Si vous souhaitez relancer manuellement la commande, supprimez d'abord celle qui a échoué :

kubectl delete order DOMAIN -n NAMESPACE

UnknownErrored Ce message indique une erreur système inconnue, qui ne devrait se produire que très rarement dans le cluster GKE. Si cette erreur apparaît, contactez l'assistance Cloud pour obtenir de l'aide pour le débogage.

Vérifier l'état de la commande

L'état de la commande enregistre le processus d'interaction avec Let's Encrypt et peut donc être utilisé pour résoudre les problèmes liés à Let's Encrypt. Si nécessaire, vérifiez l'état de la commande en exécutant la commande suivante :

kubectl get order DOMAIN -n NAMESPACE -oyaml

Remplacer

  • DOMAIN par le nom du domaine que vous utilisez ;
  • NAMESPACE par l'espace de noms que vous utilisez pour le mappage de domaine.

Si la commande a été acceptée, les résultats contiendront les certificats émis ainsi que d'autres informations.

Expiration de la commande

Un objet Commande expire au bout de 20 minutes s'il ne peut toujours pas obtenir de certificats.

  1. Vérifiez l'état du mappage de domaine. Pour l'expiration, recherchez un message d'erreur tel que celui-ci dans le résultat renvoyé :

    order (test.your-domain.com) timed out (20.0 minutes)

  2. L'expiration est souvent due au fait que votre enregistrement DNS n'est pas configuré correctement pour mapper le domaine que vous utilisez avec l'adresse IP du service d'entrée. Exécutez la commande suivante pour vérifier l'enregistrement DNS :

    host DOMAIN

  3. Vérifiez l'adresse IP externe de votre équilibreur de charge d'entrée :

    Pour obtenir l'adresse IP externe de l'équilibreur de charge, exécutez la commande suivante :

    kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

    Remplacez ASM-INGRESS-NAMESPACE par l'espace de noms où se trouve votre entrée Cloud Service Mesh. Spécifiez istio-system si vous avez installé Cloud Service Mesh à l'aide de sa configuration par défaut.

    La sortie ressemble à ceci :

    NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

    où la valeur EXTERNAL-IP est votre adresse IP externe de l'équilibreur de charge.

    Si l'adresse IP externe de votre domaine ne correspond pas à l'adresse IP d'entrée, reconfigurez votre enregistrement DNS pour effectuer le mappage avec l'adresse IP appropriée.

  4. Une fois l'enregistrement DNS (mis à jour) effectif, exécutez la commande suivante pour supprimer l'objet Commande afin de relancer le processus de demande de certificat TLS :

    kubectl delete order DOMAIN -n NAMESPACE

    Remplacer

    • DOMAIN par le nom du domaine que vous utilisez ;
    • NAMESPACE par l'espace de noms que vous utilisez.

Échecs d'autorisation

Des échecs d'autorisation peuvent se produire lorsqu'un enregistrement DNS n'est pas propagé globalement à temps. Par conséquent, Let's Encrypt ne parvient pas à valider la propriété du domaine.

  1. Vérifiez l'état de la commande. Recherchez le lien d'autorisation dans le champ de l'état acmeAuthorizations. L'URL doit se présenter comme suit :

    https://acme-v02.api.letsencrypt.org/acme/authz-v3/1717011827

  2. Ouvrez le lien. Si un message semblable à celui-ci s'affiche : 

    urn:ietf:params:acme:error:dns

    le problème est dû à une propagation DNS incomplète.

  3. Pour résoudre l'erreur de propagation DNS, procédez comme suit :

    1. Vérifiez l'adresse IP externe de votre équilibreur de charge d'entrée :

      Pour obtenir l'adresse IP externe de l'équilibreur de charge, exécutez la commande suivante :

      kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

      Remplacez ASM-INGRESS-NAMESPACE par l'espace de noms où se trouve votre entrée Cloud Service Mesh. Spécifiez istio-system si vous avez installé Cloud Service Mesh à l'aide de sa configuration par défaut.

      La sortie ressemble à ceci :

      NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

      où la valeur EXTERNAL-IP est votre adresse IP externe de l'équilibreur de charge.

    2. Vérifiez votre enregistrement DNS pour le domaine en exécutant la commande suivante :

      host DOMAIN

      Si l'adresse IP de l'enregistrement DNS ne correspond pas à l'adresse IP externe du service d'entrée, configurez votre enregistrement DNS pour mapper le domaine de l'utilisateur avec l'adresse IP externe.

    3. Une fois l'enregistrement DNS (mis à jour) effectif, exécutez la commande suivante pour supprimer l'objet Commande afin de relancer le processus de demande de certificat TLS :

      kubectl delete order DOMAIN -n NAMESPACE

    Remplacer

    • DOMAIN par le nom du domaine que vous utilisez ;
    • NAMESPACE par l'espace de noms que vous utilisez pour le mappage de domaine.

Échec du déploiement sur un cluster privé : erreur lors de l'appel du webhook

Il est possible que votre pare-feu ne soit pas configuré correctement si votre déploiement sur un cluster privé échoue avec le message suivant :

Error: failed calling webhook "webhook.serving.knative.dev": Post
https://webhook.knative-serving.svc:443/?timeout=30s: context deadline exceeded (Client.Timeout
exceeded while awaiting headers)

Pour en savoir plus sur les modifications de pare-feu requises pour procéder au déploiement sur un cluster privé, consultez la section Activer les déploiements sur un cluster privé.

État du rapport sur les services d'IngressNotConfigured

Si IngressNotConfigured s'affiche dans l'état de votre service, vous devrez peut-être redémarrer le déploiement istiod dans l'espace de noms istio-system si vous utilisez le plan de contrôle au sein du cluster Cloud Service Mesh. Cette erreur, qui a été plus fréquemment observée sur Kubernetes 1.14, peut se produire si les services sont créés avant que istiod ne soit prêt à commencer le rapprochement des VirtualServices et la transmission de la configuration Envoy aux passerelles d'entrée.

Pour résoudre ce problème, effectuez un scaling vertical du déploiement suivi d'un scaling horizontal à l'aide de commandes semblables à celle-ci :

kubectl scale deployment istiod -n istio-system --replicas=0
kubectl scale deployment istiod -n istio-system --replicas=1

Métriques de comptage et de latence des requêtes manquantes

Si vous avez activé Workload Identity Federation for GKE et que vous n'avez pas accordé certaines autorisations au compte de service utilisé par votre service, il est possible que celui-ci ne puisse pas générer de métriques de comptage et de latence des requêtes.

Pour résoudre ce problème, suivez la procédure décrite dans la section Activer les métriques sur un cluster avec Workload Identity Federation for GKE.