Soluciona de problemas de Cloud Run for Anthos en Google Cloud

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

Antes de solucionar problemas de Cloud Run for Anthos en Google Cloud, asegúrate de que puedas 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 Cloud Run for Anthos en Google Cloud, consulta las siguientes secciones para encontrar posibles soluciones.

Verifica el resultado de la línea de comandos

Si usas la línea de comandos de gcloud, verifica 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 a 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 Cloud Run en Cloud Console 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 la ruta

Ejecuta el siguiente comando a fin de obtener el estado del objeto Route que usaste para implementar tu aplicación:

kubectl get route ROUTE

Las condiciones en status proporcionan el motivo de la falla.

Verifica el enrutamiento de Istio

Compara la configuración del objeto Route de Istio, que se obtiene cuando se verifica el estado de Route, con la configuración del objeto RouteRule de Istio.

Ingresa lo siguiente y reemplaza ROUTERULE-NAME por el valor correspondiente:

kubectl get routerule ROUTERULE-NAME -o yaml

Si no conoces el nombre de la regla de ruta, usa kubectl get routerule para encontrarlo.

Mediante el comando, se muestra la configuración de la regla de ruta. Compara los dominios entre la ruta y la regla de ruta, ya que deben coincidir.

Verifica el estado de la revisión

Si estableces Route con la configuración, ejecuta el siguiente comando a fin de obtener el nombre de la revisión creada para la implementación y busca el nombre de la configuración en el archivo .yaml de Route:

kubectl get configuration CONFIGURATION-NAME -o jsonpath="{.status.latestCreatedRevisionName}"

Si configuras Route con la revisión directamente, busca el nombre de la revisión en el archivo yaml de Route.

Luego, ejecuta lo siguiente:

kubectl get revision REVISION-NAME -o yaml

Si una revisión está lista debe tener la siguiente condición en el estado:

conditions:
  - reason: ServiceReady
    status: "True"
    type: Ready

Si ves esta condición, verifica lo siguiente para continuar con la depuración:

  • El estado del Pod
  • Los registros de la aplicación
  • El enrutamiento de Istio

Si ves otras condiciones, para depurar aún más, haz lo siguiente:

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 información detallada sobre su estado. Algunos campos útiles son las condiciones 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:

Para obtener la IP externa de la puerta de enlace de entrada de Istio, ejecuta lo siguiente:

kubectl get svc ISTIO-GATEWAY -n NAMESPACE 
Reemplaza ISTIO-GATEWAY y NAMESPACE de la siguiente manera:
Versión del clúster ISTIO-GATEWAY NAMESPACE
1.15.3-gke.19 y posteriores
1.14.3-gke.12 y posteriores
1.13.10-gke.8 y posteriores
istio-ingress gke-system
Todas las demás versiones istio-ingressgateway istio-system

El resultado se ve de la siguiente manera:

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

La EXTERNAL-IP del balanceador de cargas es la dirección IP que debes usar.

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-GATEWAY -n NAMESPACE

Reemplaza ISTIO-GATEWAY y NAMESPACE por los valores de la tabla anterior. Esto genera un resultado similar al que se muestra a continuación:

stem
Name:                     ISTIO-GATEWAY
Namespace:                NAMESPACE
Labels:                   addonmanager.kubernetes.io/mode=Reconcile
                          app=ISTIO-GATEWAY
                          chart=gateways-1.0.3
                          heritage=Tiller
                          istio=ingressgateway
                          k8s-app=istio
                          kubernetes.io/cluster-service=true
                          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-GATEWAY,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 Google Cloud Console.

La puerta de enlace continuará reintentando hasta que se asigne una dirección IP externa. Este proceso podría tomar unos minutos.

Soluciona problemas de TLS administrada

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

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:

    kubectl get domainMapping DOMAIN -n NAMESPACE -oyaml

    Reemplaza los siguientes elementos:

    • 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 Mensaje detallado Instrucciones para solucionar el problema
DNSErrored El registro DNS no está configurado correctamente. Se debe asignar el dominio [XXX] a la dirección IP XX.XX.XX.XX Sigue las instrucciones proporcionadas para configurar correctamente el registro DNS.
RateLimitExceeded acme: urn:ietf:params:acme:error:rateLimited: Error en la creación de un Order nuevo

:: ya se emitieron muchos certificados para el mismo conjunto de dominios:

test.example.com:

consulta https://letsencrypt.org/docs/rate-limits/

Comunícate con LetsEncrypt a fin de aumentar la cuota de certificados para ese host.
InvalidDomainMappingName Los % del nombre de DomainMapping no pueden ser iguales que los del host de URL de ruta. El nombre de DomainMapping no puede ser el mismo que el del host de la ruta a la que se asigna. Utiliza un dominio diferente para el nombre de DomainMapping.

Errores del sistema

Código de error Mensaje detallado Instrucciones para solucionar el problema
OrderErrored

AuthzErrored

ChallengeErrored

Estos 3 tipos de errores se producen si falla la verificación de la propiedad del dominio por parte de LetsEncrypt.

Por lo general, estos errores son transitorios y Cloud Run volverá a intentarlo.

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 Cloud Run no puede llamar a LetsEncrypt. Por lo general, es un error transitorio y Cloud Run lo intentará de nuevo.

Si deseas volver a probar 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 de Order

El estado de Order registra el proceso de interacción con LetsEncrypt y, por lo tanto, se puede usar para depurar los problemas relacionados con LetsEncrypt. Si es necesario, ejecuta este comando para verificar el estado de Order:

kubectl get order DOMAIN -n NAMESPACE -oyaml

Reemplaza los siguientes elementos:

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

Si el pedido se realizó de forma correcta, los resultados contendrán los certificados emitidos y otra información.

Consumo excesivo de la cuota de LetsEncrypt

Verifica el estado de DomainMapping. Si excedes la cuota de LetsEncrypt, verás un mensaje de error en DomainMapping como el que se muestra a continuación:

acme: urn:ietf:params:acme:error:rateLimited: Error creating new order
:: too many certificates already issued for exact set of domains:
test.example.com:
see https://letsencrypt.org/docs/rate-limits/'

Consulta la documentación de LetsEncrypt sobre los límites de frecuencia a fin de aumentar la cuota de certificados.

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.example.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 istio-ingress en gke-system. Ejecuta el siguiente comando para verificar el registro DNS:

    host DOMAIN
  3. Ejecuta el siguiente comando para verificar la dirección IP externa del servicio istio-ingress en gke-system:

    kubectl get svc istio-ingress -n gke-system

    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 los siguientes elementos:

    • 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, LetsEncrypt 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. Obtén la IP externa del servicio istio-ingress en gke-system mediante la ejecución del siguiente comando:
      kubectl get svc istio-ingress -n gke-system
    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 servicio istio-ingress en gke-system, 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 los siguientes elementos:

    • 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: (gcloud.run.deploy) 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 istio-pilot en el espacio de nombres gke-system. Este error, que se observa con más frecuencia en Kubernetes 1.14, puede ocurrir si los servicios se crean antes de que istio_pilot 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, auméntala mediante comandos similares a los siguientes:

kubectl scale deployment istio-pilot -n gke-system --replicas=0
kubectl scale deployment istio-pilot -n gke-system --replicas=1