Problemas conocidos en Cloud Run for Anthos

En esta página, se detallan los problemas conocidos de Cloud Run for Anthos en Google Cloud. 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 lo siguiente

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:

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

    kubectl delete pod -n knative-serving -lapp=webhook
    kubectl get mutatingwebhookconfiguration --watch
  2. Reinicia los controladores:

    kubectl delete pod -n gke-system -listio=pilot
    kubectl delete pod -n knative-serving -lapp=controller
  3. 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.

  4. 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 en Google Cloud, 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 en Google Cloud no funcione como se espera. Servicios implementados en ese clúster

  • No se muestran en Cloud Console ni en el SDK 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 se implementa a través de Google Cloud Console, se usa el valor predeterminado de 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, puedes definir un límite de CPU predeterminado para el espacio de nombres en el que implementas los servicios con Cloud Run for Anthos en Google Cloud. 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 en Google Cloud requieren CPU 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 en Google Cloud, 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

  1. Ejecuta el siguiente comando para enumerar todas las DomainMappings:

    kubectl get domainmapping --all-namespaces
    
  2. 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:

Actualización del error de configmap: error de llamada al webhook

Los clústeres que se actualizan a la versión 0.20.0-gke.6 pueden recibir el siguiente error cuando se actualiza el ConfigMap de ese clúster:

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

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.