Solución de problemas

En esta página, se proporcionan estrategias de solución de problemas y soluciones para algunos errores comunes.

Cuando soluciones problemas de Knative serving, primero confirma que puedes ejecutar la imagen de contenedor de forma local.

Si tu aplicación no se ejecuta de forma local, deberás diagnosticar y corregir este problema. Debes usar Cloud Logging para ayudar a depurar un proyecto implementado.

Cuando soluciones problemas de Knative serving, consulta las siguientes secciones para encontrar posibles soluciones.

Verifica el resultado de la línea de comandos

Si usas Google Cloud CLI, comprueba el resultado del comando para ver si se ejecutó de forma correcta. Por ejemplo, si la implementación no se completó de forma correcta, debería aparecer un mensaje de error que describa el motivo de la falla.

Lo más probable es que las fallas de implementación se produzcan por un manifiesto mal configurado o por un comando incorrecto. Por ejemplo, el siguiente resultado indica que debes configurar el porcentaje de tráfico de ruta para sumar 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

Verifica los registros del servicio

Puedes usar Cloud Logging o la página de Knative serving en la consola de Google Cloud para verificar los registros de solicitudes y de contenedores. Si deseas obtener más información, consulta Registra y visualiza registros.

Si usas Cloud Logging, el recurso que necesitas filtrar es el contenedor de Kubernetes.

Verifica el estado de Service

Ejecuta el siguiente comando para obtener el estado de un servicio de Knative serving implementado:

gcloud run services describe SERVICE

Puedes agregar --format yaml(status) o --format json(status) para obtener el estado completo, por ejemplo:

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

Las condiciones en status pueden ayudarte a encontrar la causa de la falla. Las condiciones pueden incluir True, False o Unknown:

Para obtener detalles adicionales sobre las condiciones de estado, consulta Indicador de errores de Knative.

Verifica el estado de la ruta

Cada servicio de Knative serving administra una ruta que representa el estado de enrutamiento actual en las revisiones del servicio.

Para verificar el estado general de la ruta, mira el estado del servicio:

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

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

Para diagnosticar aún más el estado de la ruta, ejecuta el siguiente comando:

kubectl get route SERVICE -o yaml

Las condiciones en status proporcionan el motivo de la falla. Es decir,

  • Ready indica si el servicio está configurado y tiene backends disponibles. Si es true, la ruta se configuró correctamente.

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

  • IngressReady indica si el Ingress está listo. Si el status de esta condición no es True, intenta verificar el estado de salida.

  • CertificateProvisioned indica si se aprovisionaron certificados de Knative. Si el status de esta condición no es True, intenta solucionar los problemas de TLS administrados.

Para obtener detalles adicionales sobre las condiciones de estado, consulta Informes y condiciones de error de Knative.

Verifica el estado de Ingress

Knative serving usa un servicio de balanceador de cargas llamado istio-ingressgateway que se encarga de manejar el tráfico entrante desde el exterior del clúster.

A fin de obtener la IP externa para el balanceador de cargas, ejecuta el siguiente comando:

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

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

El resultado es 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

El valor EXTERNAL-IP es la dirección IP externa del balanceador de cargas.

Si EXTERNAL-IP es pending, consulta EXTERNAL-IP es pending durante mucho tiempo a continuación.

Verifica el estado de la revisión

Para obtener la revisión más 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ífico:

gcloud run revisions describe REVISION

Puedes agregar --format yaml(status) o --format json(status) para obtener el estado completo:

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

Las condiciones en status proporcionan los motivos de la falla. Es decir,

  • Ready indica si los recursos del entorno de ejecución están listos. Si es true, la revisión se configuró de forma adecuada.
  • ResourcesAvailable indica si se aprovisionaron recursos subyacentes de Kubernetes. Si el status de esta condición no es True, intenta verificar el estado del Pod.
  • ContainerHealthy indica si se completó la verificación de preparación de la revisión. Si el status de esta condición no es True, intenta verificar el estado del Pod.
  • Active indica si la revisión recibe tráfico.

Si el status de alguna de estas condiciones no es True, intenta verificar el estado del Pod.

Verifica el estado del Pod

Para obtener los Pods de todas las implementaciones, ejecuta lo siguiente:

kubectl get pods

En esta lista, se deben incluir todos los Pods con estado breve. 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 la información detallada sobre su status. Algunos campos útiles son conditions y containerStatuses:

kubectl get pod POD-NAME -o yaml

EXTERNAL-IP tiene el estado <pending> hace mucho tiempo

A veces, es posible que no obtengas una dirección IP externa de inmediato después de crear un clúster, en cambio, verás la IP externa como pending. Por ejemplo, puedes verlo si invocas el comando:

A fin de obtener la IP externa para el balanceador de cargas, ejecuta el siguiente comando:

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

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

El resultado es 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

El valor EXTERNAL-IP es la dirección IP externa del balanceador de cargas.

Esto podría implicar que te quedaste sin cuota de direcciones IP externas en Google Cloud. Puedes verificar las posibles causas si invocas lo siguiente:

kubectl describe svc istio-ingressgateway -n INGRESS_NAMESPACE
En el ejemplo anterior, INGRESS_NAMESPACE es el espacio de nombres de la entrada de ASM, que es “istio-system” de forma predeterminada. Esto genera un resultado similar al que se muestra a continuación: 
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 el resultado contiene una indicación de que se superó la cuota IN_USE_ADDRESSES, puedes solicitar una cuota adicional; para ello, navega a la página IAM y administración en la consola de Google Cloud.

La puerta de enlace continuará reintentando hasta que se asigne una dirección IP externa. Esta operación podría tardar unos minutos.

Soluciona problemas de dominios personalizados y TLS administrados

Usa los pasos que se indican a continuación para solucionar problemas generales de dominios personalizados y la función de certificados TLS administrados.

Dominios personalizados para redes internas privadas

Si asignaste un dominio personalizado a tu clúster o servicios de Knative serving dentro de una red interna privada, debesinhabilitar los certificados TLS administrados; de lo contrario, la configuración de tu dominio no podrá lograr el estado ready. De forma predeterminada, el balanceador de cargas interno no puede comunicarse de forma externa con la autoridad certificadora.

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

Para verificar 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

    Reemplaza

    • DOMAIN por el nombre del dominio que usas
    • NAMESPACE por el espacio de nombres que usas para la asignación del dominio

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

  3. Si se muestra un error, debería coincidir con uno de los errores de las siguientes tablas. Sigue las sugerencias de las tablas para solucionar el problema.

Errores de configuración del usuario

Código de error Detalles
DNSErrored Mensaje: El registro DNS no está configurado correctamente. Se debe asignar el dominio [XXX] a la IP XX.XX.XX.XX

Sigue las instrucciones proporcionadas para configurar correctamente el registro DNS.

RateLimitExceeded Mensaje: acme: urn:ietf:params:acme:error:rateLimited: Error creating new order
: ya se emitieron muchos certificados para el mismo conjunto de dominios:
test.tu-dominio.com:
consulta https://letsencrypt.org/docs/rate-limits/

Se superó la cuota de Let's Encrypt. Debes aumentar la cuota de tu certificado de Let's Encrypt para ese host.

InvalidDomainMappingName Mensaje: DomainMapping name %s cannot be the same as Route URL host %s.

El nombre de DomainMapping no puede ser el mismo que el del host de la ruta a la que se asigna. Usa un dominio diferente para el nombre de DomainMapping.

ChallengeServingErrored Mensaje: System failed to serve HTTP01 request.

Este error puede ocurrir si el servicio istio-ingressgateway no puede entregar la solicitud de Let's Encrypt para validar la propiedad del dominio.

  1. Asegúrate de que se pueda acceder a tu servicio istio-ingressgateway desde la Internet pública sin usar la nube privada virtual.
  2. Asegúrate de que el servicio istio-ingressgateway acepte solicitudes de la URL http://DOMAIN/.well-known/acme-challenge/..., en la que DOMAIN es el dominio que se valida.

Errores del sistema

Código de error Detalles
OrderErrored

AuthzErrored

ChallengeErrored

Estos 3 tipos de errores se producen si falla la verificación de la propiedad del dominio por parte de Let's Encrypt.

Por lo general, estos errores son transitorios, y Knative serving lo volverá a intentar.

La demora del reintento es exponencial y tiene un mínimo de 8 segundos y un máximo de 8 horas.

Si deseas volver a probar el error de forma manual, puedes borrar manualmente el Order.

kubectl delete order DOMAIN -n NAMESPACE

ACMEAPIFailed Este tipo de error se produce cuando Knative serving no puede llamar a Let's Encrypt. Por lo general, es un error transitorio y Knative serving lo intentará de nuevo.

Si deseas reintentar el error de forma manual, borra manualmente el Order.

kubectl delete order DOMAIN -n NAMESPACE

UnknownErrored Este error indica un error desconocido del sistema, lo que debería ocurrir muy pocas veces en el clúster de GKE. Si ves este problema, comunícate con la asistencia de Cloud para obtener ayuda con la depuración.

Verifica el estado del objeto Order

El estado de Order 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, ejecuta este comando para verificar el estado de Order:

kubectl get order DOMAIN -n NAMESPACE -oyaml

Reemplaza

  • DOMAIN por el nombre del dominio que usas
  • NAMESPACE por el espacio de nombres que usas para la asignación del dominio

Si el objeto Order tuvo éxito, los resultados contendrán los certificados emitidos y otra información.

Tiempo de espera de Order

El tiempo de espera de un objeto Order se agotará después de 20 minutos si aún no puede obtener certificados.

  1. Verifica el estado de la asignación de dominio. Para ver 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 común del tiempo de espera agotado es que el registro DNS no está configurado de forma correcta para asignar el dominio que usas a la dirección IP del servicio de entrada. Ejecuta el siguiente comando para verificar el registro DNS:

    host DOMAIN

  3. Verifica la dirección IP externa del balanceador de cargas de entrada:

    A fin de obtener la IP externa para el balanceador de cargas, ejecuta el siguiente comando:

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

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

    El resultado es 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

    El valor EXTERNAL-IP es la dirección IP externa del balanceador de cargas.

    Si la dirección IP externa del dominio no coincide con la dirección IP de entrada, vuelve a configurar el registro DNS para asignar a la dirección IP correcta.

  4. Una vez que el registro DNS (actualizado) entre en vigencia, ejecuta el siguiente comando para borrar el objeto Order y volver a activar el proceso de solicitud de un certificado TLS:

    kubectl delete order DOMAIN -n NAMESPACE

    Reemplaza

    • DOMAIN por el nombre del dominio que usas
    • NAMESPACE por el espacio de nombres que usas

Errores de autorización

Los errores de autorización pueden ocurrir cuando un registro DNS no se propaga de forma global a tiempo. Como resultado, Let's Encrypt no puede verificar la propiedad del dominio.

  1. Verifica el estado del objeto Order. Encuentra el vínculo de autorización en el campo de estado acmeAuthorizations. La URL debería verse de esta forma:

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

  2. Abre el vínculo. Si ves un mensaje similar al siguiente: 

    urn:ietf:params:acme:error:dns

    el problema se debe a una propagación incompleta del DNS.

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

    1. Verifica la dirección IP externa del balanceador de cargas de entrada:

      A fin de obtener la IP externa para el balanceador de cargas, ejecuta el siguiente comando:

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

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

      El resultado es 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

      El valor EXTERNAL-IP es la dirección IP externa del balanceador de cargas.

    2. Verifica el registro DNS del dominio mediante 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 asignar el dominio del usuario a la IP externa.

    3. Una vez que el registro DNS (actualizado) entre en vigencia, ejecuta el siguiente comando para borrar el objeto Order y volver a activar el proceso de solicitud de un certificado TLS:

      kubectl delete order DOMAIN -n NAMESPACE

    Reemplaza

    • DOMAIN por el nombre del dominio que usas
    • NAMESPACE por el espacio de nombres que usas para la asignación del dominio

Falla en la implementación en un clúster privado: error de llamada al webhook

Es posible que el firewall no esté configurado de forma correcta si la implementación en un clúster privado falla con 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)

Si deseas obtener información sobre los cambios de firewall necesarios para admitir la implementación en un clúster privado, consulta Habilita implementaciones en un clúster privado.

Estado del informe del servicio IngressNotConfigured

Si IngressNotConfigured aparece en el estado del servicio, es posible que debas reiniciar la implementación de istiod en el espacio de nombres istio-system si usas Cloud Service Mesh del plano de control del clúster. Este error, que se observa con más frecuencia en Kubernetes 1.14, puede ocurrir si los servicios se crean antes de que istiod esté listo para comenzar su trabajo de conciliar VirtualServices y enviar la configuración de Envoy a las puertas de enlace de entrada.

Para solucionar este problema, reduce la escala de la implementación y, luego, escala horizontalmente 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 el recuento y las métricas de latencia de las solicitudes

Es posible que tu servicio no informe el recuento de solicitudes de revisión y las métricas de latencia de las solicitudes si tienes Workload Identity habilitado y no otorgaste ciertos permisos a la cuenta de servicio que usa el servicio.

Para solucionar este problema, sigue los pasos de la sección Habilita métricas en un clúster con Workload Identity.