Skip to main content
Hay disponible una nueva versión de este producto.
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Problemas conocidos

Colaboradores

Los backups de aplicaciones y las snapshots producen errores si la clase volumesnapshotse añade después de gestionar un clúster

Los backups y las Snapshot fallan con un UI 500 error en este escenario. Como solución alternativa, actualice la lista de aplicaciones.

Se produce un error en los clones de aplicaciones después de poner en marcha una aplicación con una clase de almacenamiento establecida

Una vez que se implementa una aplicación con una clase de almacenamiento definida explícitamente (por ejemplo, helm install …​-set global.storageClass=netapp-cvs-perf-extreme), los intentos posteriores de clonar la aplicación requieren que el clúster de destino tenga la clase de almacenamiento especificada originalmente.
Se producirá un error al clonar una aplicación con una clase de almacenamiento definida explícitamente a un clúster que no tenga la misma clase de almacenamiento. No existen pasos de recuperación en este escenario.

Se produce un error en la gestión de un clúster con Astra Control Center cuando el archivo kubeconfig contiene más de un contexto

No puede utilizar una imagen de kubeconfig con más de un clúster y contexto en él. Consulte "artículo de base de conocimientos" si quiere más información.

Un pod de supervisión puede fallar en entornos Istio

Si emparejas Astra Control Center con Cloud Insights en un entorno de Istio, el telegraf-rs el pod puede bloquearse. Para solucionar esta solución, siga estos pasos:

  1. Busque el pod averiado:

    kubectl -n netapp-monitoring get pod | grep Error

    Debería ver una salida similar a la siguiente:

    NAME READY STATUS RESTARTS AGE
    telegraf-rs-fhhrh 1/2 Error 2 (26s ago) 32s
  2. Reinicie el pod averiado, sustituyéndolo <pod_name_from_output> con el nombre del pod afectado:

    kubectl -n netapp-monitoring delete pod <pod_name_from_output>

    Debería ver una salida similar a la siguiente:

    pod "telegraf-rs-fhhrh" deleted
  3. Compruebe que el pod se ha reiniciado y que no está en un estado de error:

    kubectl -n netapp-monitoring get pod

    Debería ver una salida similar a la siguiente:

    NAME READY STATUS RESTARTS AGE
    telegraf-rs-rrnsb 2/2 Running 0 11s

Las operaciones de gestión de datos de aplicaciones producen errores internos de servicio (500) cuando Astra Trident está sin conexión

Si Astra Trident se desconecta (y se vuelve a conectar) y se producen 500 errores internos de servicio al intentar gestionar los datos de las aplicaciones, reinicie todos los nodos de Kubernetes del clúster de aplicaciones para restaurar la funcionalidad.

Obtenga más información