Esta es la versión GitHub de la documentación. El período de prueba gratuita finalizó el 30 de septiembre de 2021.

Consulta la documentación de la versión de GA para obtener detalles sobre cómo instalar Cloud Run for Anthos como componente de la flota de Anthos con Anthos Service Mesh.

Versiones disponibles

Más reciente
Archivo

Soluciona problemas

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. Para False o “Desconocido”, debes ver el estado de la última revisión.
RoutesReady: True indica que la ruta subyacente está lista. Para False 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 es True:
- 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 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

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 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:

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 campo CertificateProvisioned 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.	Asegúrate de que se pueda acceder a tu servicio `istio-ingress` desde la Internet pública sin usar la nube privada virtual. Asegúrate de que tu servicio `istio-ingress` 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	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. `kubectl delete order DOMAIN -n NAMESPACE`
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. `kubectl delete order DOMAIN -n NAMESPACE`
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 en gke-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 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.
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:
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. 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 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: 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