En esta página, se proporcionan estrategias de solución de problemas y soluciones para algunos errores comunes.
Cuando soluciones problemas de Cloud Run for Anthos, 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 Cloud Run for Anthos, consulta las siguientes secciones para encontrar posibles soluciones.
También consulta la página problemas conocidos para obtener detalles sobre los problemas conocidos en Cloud Run for Anthos y cómo resolverlos.
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 Cloud Run for Anthos 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 implementado de Cloud Run for Anthos:
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
:
- Ready:
True
indica que el servicio está configurado y listo para recibir tráfico. - ConfigurationReady:
True
indica que la Configuration subyacente está lista. ParaFalse
o “Desconocido”, debes ver el estado de la última revisión. - RoutesReady:
True
indica que la ruta subyacente está lista. ParaFalse
o "Unknown", debes ver el estado de la ruta.
Para obtener detalles adicionales sobre las condiciones de estado, consulta Indicador de errores de Knative.
Verifica el estado de la ruta
Cada servicio de Cloud Run for Anthos 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 esTrue
:Verifica si la división del tráfico entre revisiones para tu servicio suma el 100%:
gcloud run services describe SERVICE
De lo contrario, ajusta la división del tráfico con el comando
gcloud run services update-traffic
.Intenta verificar el estado de la revisión para ver las revisiones que reciben tráfico.
IngressReady indica si el Ingress está listo. Si el
status
de esta condición no esTrue
, intenta verificar el estado de salida.CertificateProvisioned indica si se aprovisionaron certificados de Knative. Si el
status
de esta condición no esTrue
, 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
Cloud Run for Anthos usa un servicio de Kubernetes del balanceador de cargas llamado istio-ingress
que se encarga de manejar el tráfico entrante desde el exterior del clúster.
Para obtener la dirección IP externa del Ingress, usa
kubectl get svc istio-ingress -n gke-system
Si EXTERNAL-IP
es pending
, consulta EXTERNAL-IP es pending
por mucho tiempo a continuación.
Verifica el estado de la revisión
Para obtener la revisión más reciente del servicio de Cloud Run for Anthos, 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 específica de Cloud Run for Anthos:
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 esTrue
, 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 esTrue
, 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:
Para obtener la IP externa de la puerta de enlace de entrada de Istio, ejecuta lo siguiente:
kubectl get svc istio-ingress -n gke-system
El resultado se ve de la siguiente manera:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) istio-ingress 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-ingress -n gke-system
Esto genera un resultado similar al que se muestra a continuación:
Name: istio-ingress Namespace: gke-system Labels: addonmanager.kubernetes.io/mode=Reconcile app=istio-ingress chart=gateways-1.0.3 heritage=Tiller istio=ingress-gke-system 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=ingressgateway,istio=ingress-gke-system,release=istio 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 tu 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. Esta operación podría demorar 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:
Ejecuta el comando:
gcloud run domain-mappings describe --domain DOMAIN --namespace 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
En los resultados
yaml
de este comando, examina la condición del campoCertificateProvisioned
a fin de determinar la naturaleza del error.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 problemas | |
Error de DNS | 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 tu registro DNS correctamente. | |
Límite superado | acme: urn:ietf:params:acme:error:rateLimited: Error en la creación de un pedido nuevo
:: ya se emitieron demasiados certificados para el conjunto exacto de dominios: prueba.ejemplo.com: https://letsencrypt.org/docs/rate-limits/ |
Comunícate con Let's Encrypt a fin de aumentar la cuota de certificados para ese host. | |
Nombre de asignación del dominio no válido | El nombre %s de DomainMapping no puede ser el mismo que el host de URL de ruta %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. | |
Error de publicación del desafío | El sistema no pudo entregar la solicitud HTTP01. | Este error puede ocurrir si el servicio istio-ingress no puede entregar la solicitud de Let's Encrypt para validar la propiedad del dominio.
|
|
Errores del sistema
Código de error | Mensaje detallado | Instrucciones para solucionar problemas |
Error de pedido
Error de autorización Se produjo un error |
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 Cloud Run for Anthos reintentará la acción. La demora del reintento es exponencial y tiene un mínimo de 8 segundos y un máximo de 8 horas. Si deseas reintentar el error de forma manual, puedes borrar manualmente el pedido con errores.
|
|
Error de ACMEAPI | Este tipo de error se produce cuando Cloud Run for Anthos no puede llamar a Let's Encrypt. Por lo general, es un error transitorio y Cloud Run for Anthos reintentará la acción.
Si deseas volver a intentar el error de forma manual, borra manualmente el pedido con errores.
|
|
Error desconocido | 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 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 objeto Order tuvo éxito, los resultados contendrán los certificados emitidos y otra información.
Consumo excesivo de la cuota de Let's Encrypt
Verifica el estado de DomainMapping. Si excedes la cuota de Let's Encrypt, 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 Let's Encrypt 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.
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)
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
engke-system
. Ejecuta el siguiente comando para verificar el registro DNS:host DOMAIN
Ejecuta el siguiente comando para verificar la dirección IP externa del servicio
istio-ingress
engke-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.
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
Reemplazar
- 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.
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
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.
Para resolver el error de propagación del DNS, sigue estos pasos:
- Obtén la IP externa del servicio
istio-ingress
engke-system
mediante la ejecución del siguiente comando:kubectl get svc istio-ingress -n gke-system
Ejecuta el siguiente comando para verificar tu registro DNS en el dominio:
host DOMAIN
Si la dirección IP del registro DNS no coincide con la IP externa del servicio
istio-ingress
engke-system
, configura el registro DNS para asignar el dominio del usuario a la IP externa.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
- Obtén la IP externa del servicio
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 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, escala horizontalmente con 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
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.
Usa WebSockets con dominios personalizados
De forma predeterminada, los WebSockets están inhabilitados para los mapeos de dominios personalizados.
A fin de habilitar WebSockets para los dominios personalizados, ejecuta el siguiente comando y crea un objeto EnvoyFilter de Istio con allow_connect: true
:
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: allowconnect-cluster-local-gateway-tb
namespace: gke-system
spec:
workloadSelector:
labels:
istio: ingress-gke-system
configPatches:
- applyTo: NETWORK_FILTER
match:
listener:
portNumber: 8081
filterChain:
filter:
name: "envoy.http_connection_manager"
patch:
operation: MERGE
value:
typed_config:
"@type": "type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager"
http2_protocol_options:
allow_connect: true
EOF