Notas de la versión
Problemas conocidos
Sugerir cambios
PDF
Los problemas conocidos identifican problemas por los que el uso correcto de esta versión del producto puede resultar imposible.
Los siguientes problemas conocidos afectan a la versión actual:
La restauración de una aplicación genera un tamaño VP superior al VP original
Si cambia el tamaño de un volumen persistente después de crear un backup y luego se restaura a partir de ese backup, el tamaño del volumen persistente coincidiría con el nuevo tamaño del VP en lugar de usar el tamaño del backup.
Los clones de aplicaciones producen un error al utilizar una versión específica de PostgreSQL
Los clones de aplicaciones dentro del mismo clúster fallan constantemente con el gráfico BitNami PostgreSQL 11.5.0. Para clonar correctamente, utilice una versión anterior o posterior del gráfico.
Error en los clones de aplicaciones al utilizar restricciones de contexto de seguridad OCP de nivel de cuenta de servicio (SCC)
Un clon de aplicación podría fallar si las restricciones de contexto de seguridad originales están configuradas en el nivel de cuenta de servicio dentro del espacio de nombres en el clúster de OpenShift Container Platform. Cuando se produce un error en el clon de la aplicación, aparece en el área aplicaciones gestionadas del Centro de control de Astra con el estado Removed. Consulte "artículo de base de conocimientos" si quiere más información.
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.
La administración de un clúster con Astra Control Center falla cuando el archivo kubeconfig predeterminado 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.
Algunos pods no se inician después de actualizar a Astra Control Center 23,04
Después de actualizar a Astra Control Center 23,04, es posible que algunos pods no se inicien. Como solución alternativa, reinicie manualmente los pods afectados mediante los siguientes pasos:
-
Busque los pods afectados y sustituya a <namespace> por el espacio de nombres actual:
kubectl get pods -n <namespace> | grep au-pod
Los pods afectados tendrán resultados similares a los siguientes:
pcloud-astra-control-center-au-pod-0 0/1 CreateContainerConfigError 0 13s
-
Reinicie cada pod afectado, sustituyendo <namespace> por el espacio de nombres actual:
kubectl delete pod pcloud-astra-control-center-au-pod-0 -n <namespace>
Algunos pods muestran un estado de error después de la etapa de depuración de la actualización de 23,04 a 23.04.2
Después de actualizar a Astra Control Center 23.04.2, es posible que algunos pods muestren un error en
registros relacionados con task-service-task-purge:
kubectl get all -n netapp-acc -o wide|grep purge pod/task-service-task-purge-28282828-ab1cd 0/1 Error 0 48m 10.111.0.111 openshift-clstr-ol-07-zwlj8-worker-jhp2b <none> <none>
Este estado de error significa que un paso de limpieza no se ejecutó correctamente. La actualización general a 23.04.2 se realiza correctamente. Ejecute el siguiente comando para limpiar la tarea y eliminar el estado de error:
kubectl delete job task-service-task-purge-[system-generated task ID] -n <netapp-acc or custom namespace>
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:
-
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
-
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
-
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
Los clústeres gestionados no aparecen en Cloud Insights de NetApp cuando se conectan a través de un proxy
Cuando Astra Control Center se conecta a Cloud Insights de NetApp mediante un proxy, es posible que los clústeres gestionados no aparezcan en Cloud Insights. Para solucionar esta solución, ejecute los siguientes comandos en cada clúster gestionado:
kubectl get cm telegraf-conf -o yaml -n netapp-monitoring | sed '/\[\[outputs.http\]\]/c\ [[outputs.http]]\n use_system_proxy = true' | kubectl replace -f -kubectl get cm telegraf-conf-rs -o yaml -n netapp-monitoring | sed '/\[\[outputs.http\]\]/c\ [[outputs.http]]\n use_system_proxy = true' | kubectl replace -f -kubectl get pods -n netapp-monitoring --no-headers=true | grep 'telegraf-ds\|telegraf-rs' | awk '{print $1}' | xargs kubectl delete -n netapp-monitoring podLas 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.