Solución de problemas

En esta página se ofrecen estrategias y soluciones para resolver algunos errores habituales.

Cuando tengas problemas con Knative Serving, primero confirma que puedes ejecutar tu imagen de contenedor de forma local.

Si tu aplicación no se ejecuta de forma local, tendrás que diagnosticarla y corregirla. Debes usar Cloud Logging para depurar un proyecto implementado.

Cuando tengas problemas con el servicio de Knative, consulta las siguientes secciones para ver posibles soluciones.

Comprobar la salida de la línea de comandos

Si usas la CLI de Google Cloud, comprueba el resultado del comando para ver si se ha completado correctamente. Por ejemplo, si tu implementación se ha cancelado sin éxito, debería aparecer un mensaje de error que describa el motivo del fallo.

Lo más probable es que los errores de despliegue se deban a un manifiesto mal configurado o a un comando incorrecto. Por ejemplo, en el siguiente resultado se indica que debe configurar el porcentaje de tráfico de la ruta para que sume 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

Consultar los registros de tu servicio

Puedes usar Cloud Logging o la página de servicio de Knative en laGoogle Cloud consola para consultar los registros de solicitudes y los registros de contenedores. Para obtener más información, consulta el artículo Registrar y ver registros.

Si usas Cloud Logging, el recurso por el que debes filtrar es Contenedor de Kubernetes.

Comprobar el estado del servicio

Ejecuta el siguiente comando para obtener el estado de un servicio de Knative Serving desplegado:

gcloud run services describe SERVICE

Puedes añadir --format yaml(status) o --format json(status) para obtener el estado completo. Por ejemplo:

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

Las condiciones de status pueden ayudarte a localizar la causa del error. Las condiciones pueden incluir True, False o Unknown:

• Listo: True indica que el servicio está configurado y listo para recibir tráfico.
• ConfigurationReady True indica que la configuración subyacente está lista. En el caso de False o Unknown, debes consultar el estado de la última revisión.
• RoutesReady True indica que la ruta subyacente está lista. Para False o Unknown, debes consultar el estado de la ruta.

Para obtener más información sobre las condiciones de estado, consulta Señales de error de Knative.

Comprobar el estado de la ruta

Cada servicio de Knative Serving gestiona una ruta que representa el estado de enrutamiento actual de las revisiones del servicio.

Para comprobar el estado general de la ruta, consulta el estado del servicio:

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

La condición RoutesReady de status proporciona el estado de la ruta.

Para diagnosticar el estado de la ruta, ejecuta el siguiente comando:

kubectl get route SERVICE -o yaml

Las condiciones de status indican el motivo del error. Por ejemplo:

• Listo indica si el servicio está configurado y tiene back-ends disponibles. Si es true, la ruta se ha configurado correctamente.

• AllTrafficAssigned indica si el servicio está configurado correctamente y tiene backends disponibles. Si el status de esta condición no es True:

  • Prueba a comprobar si la división del tráfico entre las revisiones de tu servicio suma el 100%:

    gcloud run services describe SERVICE

    Si no es así, ajusta la división del tráfico con el comando gcloud run services update-traffic.

  • Prueba a consultar el estado de la revisión de las revisiones que reciben tráfico.

• IngressReady indica si el Ingress está listo. Si el status de esta condición no es True, prueba a comprobar el estado de entrada.

• CertificateProvisioned indica si se han aprovisionado los certificados de Knative. Si el valor de status de esta condición no es True, prueba a solucionar problemas de TLS gestionado.

Para obtener más información sobre las condiciones de estado, consulta Knative Error Conditions and Reporting (Condiciones de error e informes de Knative).

Comprobar el estado de Ingress

Knative Serving usa un servicio de balanceador de carga llamado istio-ingressgateway, que se encarga de gestionar el tráfico entrante desde fuera del clúster.

Para obtener la IP externa del balanceador de carga, ejecuta el siguiente comando:

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

Sustituye ASM-INGRESS-NAMESPACE por el espacio de nombres en el que se encuentra tu entrada de Cloud Service Mesh. Especifica istio-system si has instalado Cloud Service Mesh con su configuración predeterminada.

La salida resultante tiene un aspecto similar al siguiente:

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

donde el valor EXTERNAL-IP es la dirección IP externa del balanceador de carga.

Si el valor de EXTERNAL-IP es pending, consulta la sección EXTERNAL-IP es pending durante mucho tiempo más abajo.

Comprobar el estado de la revisión

Para obtener la revisión más reciente de tu servicio de Knative Serving, ejecuta el siguiente comando:

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

Ejecuta el siguiente comando para obtener el estado de una revisión de Knative Serving específica:

gcloud run revisions describe REVISION

Puedes añadir --format yaml(status) o --format json(status) para ver el estado completo:

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

Las condiciones de status indican los motivos de un error. Por ejemplo:

• Listo indica si los recursos del tiempo de ejecución están listos. Si es true, la revisión se ha configurado correctamente.
• ResourcesAvailable indica si se han aprovisionado los recursos de Kubernetes subyacentes. Si el valor de status de esta condición no es True, prueba a comprobar el estado del pod.
• ContainerHealthy indica si se ha completado la comprobación de la disponibilidad de la revisión. Si el valor de status de esta condición no es True, prueba a comprobar el estado del pod.
• Activo: indica si la revisión está recibiendo tráfico.

Si no se cumple alguna de estas condiciones, statusTrue prueba a comprobar el estado del Pod.

Comprobar el estado de un Pod

Para obtener los pods de todas tus implementaciones, haz lo siguiente:

kubectl get pods

Debería mostrar todos los pods con un breve estado. Por ejemplo:

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

Elige uno y usa el siguiente comando para ver información detallada sobre su status. Algunos campos útiles son conditions y containerStatuses:

kubectl get pod POD-NAME -o yaml

EXTERNAL-IP está <pending> durante mucho tiempo

A veces, es posible que no obtengas una dirección IP externa inmediatamente después de crear un clúster, sino que veas pending. Por ejemplo, puedes verlo invocando el comando:

Para obtener la IP externa del balanceador de carga, ejecuta el siguiente comando:

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

Sustituye ASM-INGRESS-NAMESPACE por el espacio de nombres en el que se encuentra tu entrada de Cloud Service Mesh. Especifica istio-system si has instalado Cloud Service Mesh con su configuración predeterminada.

La salida resultante tiene un aspecto similar al siguiente:

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

donde el valor EXTERNAL-IP es la dirección IP externa del balanceador de carga.

Es posible que se deba a que has agotado la cuota de direcciones IP externas en Google Cloud. Para comprobar la posible causa, invoca lo siguiente:

kubectl describe svc istio-ingressgateway -n INGRESS_NAMESPACE

donde INGRESS_NAMESPACE es el espacio de nombres de entrada de ASM, que de forma predeterminada es `istio-system`. Esto genera un resultado similar al siguiente:

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 en el resultado se indica que se ha superado la cuota, puede solicitar cuota adicional en la página Gestión de identidades y accesos y administrador de la consola.IN_USE_ADDRESSES Google Cloud

La pasarela seguirá intentándolo hasta que se le asigne una dirección IP externa. Esta acción puede llevar unos minutos.

Solucionar problemas con dominios personalizados y TLS gestionado

Sigue los pasos que se indican a continuación para solucionar problemas generales relacionados con los dominios personalizados y la función de certificados TLS gestionados.

Dominios personalizados para redes privadas e internas

Si has asignado un dominio personalizado a tu clúster o servicios de Knative Serving en una red interna privada, debes inhabilitar los certificados TLS gestionados. De lo contrario, tu configuración de dominio no alcanzará el estado ready. De forma predeterminada, el balanceador de carga interno no puede comunicarse externamente con la autoridad de certificación.

Comprobar el estado de una asignación de dominio específica

Para comprobar el estado de una asignación de dominio específica, sigue estos pasos:

1. Ejecuta el comando:

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

   Sustituir

   • DOMAIN con el nombre del dominio que estés usando.
   • NAMESPACE con el espacio de nombres que uses para la asignación de dominio.

2. En los yaml resultados de este comando, examine la condición del campo CertificateProvisioned para determinar la naturaleza del error.

3. Si se muestra un error, debería coincidir con uno de los errores de las tablas que se indican a continuación. Sigue las sugerencias de las tablas para resolver el problema.

Errores de configuración del usuario

Código de error	Detalles
DNSErrored	Mensaje: El registro DNS no está configurado correctamente. Necesito asignar el dominio [XXX] a la IP XX.XX.XX.XX Sigue las instrucciones que se indican para configurar correctamente el registro DNS.
RateLimitExceeded	Mensaje: 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: see https://letsencrypt.org/docs/rate-limits/ Se ha superado la cuota de Let's Encrypt. Debes aumentar la cuota de certificados Let's Encrypt de ese host.
InvalidDomainMappingName	Mensaje: El nombre de DomainMapping %s no puede ser el mismo que el host de la URL de ruta %s. El nombre de DomainMapping no puede ser exactamente el mismo que el host de la ruta a la que se asigna. Usa otro dominio para el nombre de DomainMapping.
ChallengeServingErrored	Mensaje: El sistema no ha podido atender la solicitud HTTP01. Este error puede producirse si el servicio istio-ingressgateway no puede atender la solicitud de Let's Encrypt para validar la propiedad del dominio. Asegúrate de que se pueda acceder a tu servicio istio-ingressgateway desde Internet público sin usar nubes privadas virtuales. Asegúrate de que tu servicio istio-ingressgateway acepte solicitudes de la URL http://DOMAIN/.well-known/acme-challenge/..., donde DOMAIN es el dominio que se está validando.

Errores del sistema

Código de error	Detalles
OrderErrored AuthzErrored ChallengeErrored	Estos tres tipos de errores se producen si no se puede verificar la propiedad del dominio por parte de Let's Encrypt. Estos errores suelen ser transitorios y Knative Serving volverá a intentarlo. El retraso de reintento es exponencial, con un mínimo de 8 segundos y un máximo de 8 horas. Si quieres volver a intentar corregir el error manualmente, puedes eliminar el pedido fallido manualmente. kubectl delete order DOMAIN -n NAMESPACE
ACMEAPIFailed	Este tipo de error se produce cuando Knative Serving no puede llamar a Let's Encrypt. Este error suele ser temporal y Knative Serving volverá a intentarlo. Si quieres volver a intentar corregir el error manualmente, elimina el pedido fallido manualmente. kubectl delete order DOMAIN -n NAMESPACE
UnknownErrored	Este error indica que se ha producido un error desconocido del sistema, que debería ocurrir muy rara vez en el clúster de GKE. Si ves este mensaje, ponte en contacto con el equipo de Asistencia de Cloud para obtener ayuda con la depuración.

Comprobar el estado del pedido

El estado del pedido registra el proceso de interacción con Let's Encrypt y, por lo tanto, se puede usar para depurar los problemas relacionados con Let's Encrypt. Si es necesario, comprueba el estado del pedido ejecutando este comando:

kubectl get order DOMAIN -n NAMESPACE -oyaml

Sustituir

• DOMAIN con el nombre del dominio que estés usando.
• NAMESPACE con el espacio de nombres que uses para la asignación de dominio.

Los resultados contendrán los certificados emitidos y otra información si el pedido se ha completado correctamente.

Tiempo de espera del pedido

El objeto Order se agotará tras 20 minutos si sigue sin obtener certificados.

1. Consulta el estado de la asignación de dominio. En caso de que se agote el tiempo de espera, busca un mensaje de error como este en el resultado del estado:

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

2. Una causa habitual del problema de tiempo de espera es que tu registro DNS no esté configurado correctamente para asignar el dominio que estás usando a la dirección IP del servicio de entrada. Ejecuta el siguiente comando para comprobar el registro DNS:

   host DOMAIN

3. Comprueba la dirección IP externa de tu balanceador de carga de entrada:

   Para obtener la IP externa del balanceador de carga, ejecuta el siguiente comando:

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

   Sustituye ASM-INGRESS-NAMESPACE por el espacio de nombres en el que se encuentra tu entrada de Cloud Service Mesh. Especifica istio-system si has instalado Cloud Service Mesh con su configuración predeterminada.

   La salida resultante tiene un aspecto similar al siguiente:

   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

   donde el valor EXTERNAL-IP es la dirección IP externa del balanceador de carga.

   Si la dirección IP externa de tu dominio no coincide con la dirección IP de entrada, vuelve a configurar tu registro DNS para que se asigne a la dirección IP correcta.

4. Una vez que el registro DNS (actualizado) se haya aplicado, ejecuta el siguiente comando para eliminar el objeto Order y volver a activar el proceso de solicitud de un certificado TLS:

   kubectl delete order DOMAIN -n NAMESPACE

   Sustituir

   • DOMAIN con el nombre del dominio que estés usando.
   • NAMESPACE con el espacio de nombres que uses.

Errores de autorización

Los errores de autorización pueden producirse cuando un registro DNS no se propaga globalmente a tiempo. Por lo tanto, Let's Encrypt no puede verificar la propiedad del dominio.

1. Comprobar el estado del pedido. Busca el enlace de autorización en el campo acmeAuthorizations de estado. La URL debe tener este aspecto:

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

2. Abre el enlace. Si ves un mensaje similar a este:

   urn:ietf:params:acme:error:dns

   entonces el problema se debe a que la propagación del DNS no se ha completado.

3. Para resolver el error de propagación de DNS, sigue estos pasos:

   1. Comprueba la dirección IP externa de tu balanceador de carga de entrada:

      Para obtener la IP externa del balanceador de carga, ejecuta el siguiente comando:

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

      Sustituye ASM-INGRESS-NAMESPACE por el espacio de nombres en el que se encuentra tu entrada de Cloud Service Mesh. Especifica istio-system si has instalado Cloud Service Mesh con su configuración predeterminada.

      La salida resultante tiene un aspecto similar al siguiente:

      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

      donde el valor EXTERNAL-IP es la dirección IP externa del balanceador de carga.

   2. Comprueba el registro DNS del dominio ejecutando el siguiente comando:

      host DOMAIN

      Si la dirección IP del registro DNS no coincide con la IP externa del balanceador de carga de entrada, configura el registro DNS para que asigne el dominio del usuario a la IP externa.

   3. Una vez que el registro DNS (actualizado) se haya aplicado, ejecuta el siguiente comando para eliminar el objeto Order y volver a activar el proceso de solicitud de un certificado TLS:

      kubectl delete order DOMAIN -n NAMESPACE

   Sustituir

   • DOMAIN con el nombre del dominio que estés usando.
   • NAMESPACE con el espacio de nombres que uses para la asignación de dominio.

Error al implementar en un clúster privado: error al llamar al webhook

Es posible que tu cortafuegos no esté configurado correctamente si tu implementación en un clúster privado falla y aparece el siguiente mensaje:

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)

Para obtener información sobre los cambios en el firewall necesarios para admitir la implementación en un clúster privado, consulta Habilitar implementaciones en un clúster privado.

Los servicios devuelven el estado IngressNotConfigured

Si aparece IngressNotConfigured en el estado de tu servicio, puede que tengas que reiniciar el despliegue de istiod en el espacio de nombres istio-system si usas el plano de control de Cloud Service Mesh en el clúster. Este error, que se ha observado con más frecuencia en Kubernetes 1.14, puede producirse si los servicios se crean antes de que istiod esté listo para empezar a reconciliar VirtualServices y enviar la configuración de Envoy a las pasarelas de entrada.

Para solucionar este problema, escala la implementación y, a continuación, vuelve a reducirla con comandos similares a los siguientes:

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

Faltan las métricas de número de solicitudes y latencia de solicitudes

Es posible que tu servicio no registre las métricas de recuento de solicitudes de revisión y latencia de solicitudes si tienes habilitada la federación de identidades de carga de trabajo para GKE y no has concedido determinados permisos a la cuenta de servicio que utiliza tu servicio.

Para solucionar este problema, sigue los pasos que se indican en la sección Habilitar métricas en un clúster con Workload Identity Federation para GKE.