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

Problemas conocidos en Cloud Run for Anthos

En esta página, se enumeran los problemas conocidos de Cloud Run for Anthos. Para ver vulnerabilidades de seguridad conocidas, consulta Prácticas recomendadas de seguridad.

También puedes verificar los problemas existentes o abrir problemas nuevos desde la herramienta pública de seguimiento de errores.

También puedes consultar la página solución de problemas a fin de obtener información sobre las estrategias para solucionar problemas y las soluciones para algunos errores comunes.

Servicios estancados en `RevisionMissing` debido a la falta de `MutatingWebhookConfiguration`

La creación de un servicio nuevo o una revisión de servicio nueva puede detenerse en el estado “RevisionMissing” debido a la falta de una configuración de webhook. Puedes verificar esto mediante el comando

kubectl get mutatingwebhookconfiguration webhook.serving.knative.dev

que muestra

kmutatingwebhookconfigurations.admissionregistration.k8s.io "webhook.serving.knative.dev" not found`

Solución temporal

Hasta que esto se corrija en la próxima versión, puedes hacer lo que se indica a continuación para corregir este problema:

Reinicia el Pod de webhook para volver a crear el MutatingWebhookConfiguration:

kubectl delete pod -n knative-serving -lapp=webhook
kubectl get mutatingwebhookconfiguration --watch

Reinicia los controladores:

kubectl delete pod -n gke-system -listio=pilot
kubectl delete pod -n knative-serving -lapp=controller

Implementa una revisión nueva para cada servicio que tenga el problema RevisionMissing:
```
gcloud run services update SERVICE --update-labels client.knative.dev/nonce=""
```
y reemplaza SERVICE por el nombre del servicio.
Repite los pasos anteriores según sea necesario si experimentas el mismo problema cuando implementas revisiones nuevas del servicio.

Clústeres zonales

Cuando usas un clúster zonal con Cloud Run for Anthos, el acceso al plano de control no está disponible durante el mantenimiento del clúster.

Durante este período, es posible que Cloud Run for Anthos no funcione como se espera. Servicios implementados en ese clúster

No se muestran en Cloud Console ni a través de la CLI de gcloud
No se puede borrar ni actualizar
Las instancias no se ajustarán automáticamente, pero las instancias existentes continuarán entregando solicitudes nuevas

Para evitar estos problemas, puedes usar un clúster regional, que garantiza un plano de control de alta disponibilidad.

El límite de memoria predeterminado no se aplica mediante la línea de comandos

Si usas la línea de comandos con el fin de implementar tus servicios, debes incluir la marca --memory a fin de establecer un límite de memoria para ese servicio. La exclusión de la marca --memory permite que un servicio consuma hasta la cantidad total de memoria disponible en el nodo en el que se ejecuta ese Pod, lo que puede tener efectos secundarios inesperados.

Cuando realizas una implementación a través de Google Cloud Console, se usa el valor predeterminado 256M, a menos que se especifique un valor diferente.

A fin de evitar tener que definir límites predeterminados para cada servicio, puedes definir un límite de memoria predeterminado para el espacio de nombres en el que implementas esos servicios. Para obtener más información, consulta Configura límites de memoria predeterminados en la documentación de Kubernetes.

El límite de CPU predeterminado no está habilitado

Cuando se implementa mediante la línea de comandos o Console, la cantidad de CPU que un servicio puede usar no se define. Esto permite que el servicio consuma toda la CPU disponible en el nodo en el que se ejecuta, lo cual puede tener efectos secundarios inesperados.

A fin de solucionar este problema, define un límite de CPU predeterminado para el espacio de nombres en el que implementas los servicios con Cloud Run for Anthos. Para obtener más información, consulta Configura límites de CPU predeterminados en la documentación de Kubernetes.

Nota: De forma predeterminada, los servicios implementados con Cloud Run for Anthos solicitan CPU de 400m, que se usa para programar instancias de un servicio en los nodos del clúster.

El contenido de los puntos de lectura/escritura en el contenedor siempre está vacío

Si tienes un contenedor que crea archivos o carpetas en /var/log, por ejemplo, /var/log/nginx, cuando ejecutas ese contenedor en Cloud Run for Anthos, esos archivos o carpetas no serán visibles porque un volumen de lectura o escritura vacío se activó en /var/log, lo que oculta el contenido del contenedor subyacente.

Si tu servicio necesita escribir en un subdirectorio de /var/log, debe asegurarse de que la carpeta exista en el entorno de ejecución antes de escribir en ella. No se puede suponer que la carpeta existe a partir de la imagen de contenedor.

Solución alternativa

Si actualizaste tu clúster a la versión 1.17 de GKE y tienes problemas con la implementación del servicio, debes borrar el VirtualService que generó DomainMapping porque ya no es compatible con el controlador nuevo. Después de borrarlo, el controlador vuelve a crear un VirtualService compatible y resuelve los problemas de implementación del servicio.

Ejecuta los siguientes comandos para borrar tu VirtualService, en el que el nombre de VirtualService es el mismo que tus DomainMappings. Por ejemplo: foo.example.com

Ejecuta el siguiente comando para enumerar todas las DomainMappings:
```
kubectl get domainmapping --all-namespaces
```

Ejecuta el siguiente comando para borrar el VirtualService especificado:

kubectl delete vs your-domain-mapping-name -n your-domain-mapping-namespace

Implementa imágenes de contenedor privadas en Artifact Registry

Existe un problema de implementación conocido que se produce por una falla de autenticación entre Cloud Run for Anthos y Artifact Registry cuando se implementan imágenes de contenedor privadas. Para evitar problemas cuando implementas imágenes privadas en Artifact Registry, puedes hacer lo siguiente:

Usa el resumen de imágenes de tus imágenes de contenedor privadas para implementar un servicio.
Crea y usa un imagePullSecret. Usar un imagePullSecret te permite usar la etiqueta de imagen de tus imágenes de contenedor privadas. Para obtener detalles, consulta Implementa imágenes de contenedor privadas de otros registros de contenedores.

Errores de configuración en clústeres actualizados a la versión `0.20.0-gke.6`

Los clústeres que se actualizan a la versión 0.20.0-gke.6 pueden recibir uno de los siguientes errores.

Cuando actualizas el ConfigMap de ese clúster, el clúster puede recibir el siguiente error:

Error from server (InternalError): error when replacing "/tmp/file.yaml":
Internal error occurred: failed calling webhook "config.webhook.istio.networking.internal.knative.dev":
the server rejected our request for an unknown reason

Si los Pods no se inician debido a una falla en el proxy de cola, el clúster puede recibir el siguiente error:

Startup probe failed: flag provided but not defined: -probe-timeout

A fin de resolver el error, debes ejecutar el siguiente comando para quitar la configuración validatingwebhookconfiguration que ya no es compatible con 0.20.0:

kubectl delete validatingwebhookconfiguration config.webhook.istio.networking.internal.knative.dev

Después de quitar la configuración no compatible, puedes continuar con la actualización del ConfigMap de tu clúster.

Faltan métricas después de actualizar a Cloud Run for Anthos 0.23.0-gke.9

Problema: Faltan las siguientes métricas después de actualizar la versión del clúster a 0.23.0-gke.9: Request count, Request latencies y Container instance count

Causa posible: Metric Collector está inhabilitado.

Para determinar si el Metric Collector impide que se recopilen tus métricas, sigue estos pasos:

Ejecuta el siguiente comando a fin de asegurarte de que tu versión de Cloud Run for Anthos sea 0.23.0-gke.9:

kubectl get deployment controller -n knative-serving -o jsonpath='{.metadata.labels.serving\.knative\.dev/release}'

Ejecuta el siguiente comando para verificar si Metric Collector está inhabilitado:
```
kubectl get cloudrun cloud-run -n cloud-run-system -o jsonpath='{.spec.metricscollector}'
```
Tu Metric Collector se inhabilita si el resultado no es {enabled: true}.

Para habilitar Metric Collector, ejecuta uno de los siguientes comandos:

Si el resultado está vacío, ejecuta el siguiente comando:

kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "test", "path": "/spec", "value": NULL}, {"op": "add", "path": "/spec", "value": {}}]'
kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "test", "path": "/spec/metricscollector", "value": NULL}, {"op": "add", "path": "/spec/metricscollector", "value": {}}]'
kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "add", "path": "/spec/metricscollector/enabled", "value": true}]'

Si el resultado es {enabled: false}, ejecuta el siguiente comando:

kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "replace", "path": "/spec/metricscollector/enabled", "value": true}]'

Ejecuta el siguiente comando para verificar que Metric Collector esté habilitado:

kubectl get cloudrun cloud-run -n cloud-run-system -o jsonpath='{.spec.metricscollector}'