Resolución de problemas
Utilice los punteros que se proporcionan aquí para solucionar problemas que puedan surgir durante la instalación y el uso de Astra Trident.
Resolución de problemas generales
-
Si el pod de Trident no sale correctamente (por ejemplo, cuando el pod de Trident se encuentra atascado en el
ContainerCreating
fase con menos de dos contenedores listos para usar) en ejecuciónkubectl -n trident describe deployment trident
y..kubectl -n trident describe pod trident--**
puede proporcionar información adicional. Obtención de registros de kubelet (por ejemplo, mediantejournalctl -xeu kubelet
) también puede ser útil. -
Si no hay suficiente información en los registros de Trident, puede intentar habilitar el modo de depuración para Trident aprobando el
-d
marque el parámetro install en función de su opción de instalación.A continuación, confirme que la depuración se ha configurado mediante
./tridentctl logs -n trident
y buscandolevel=debug msg
en el registro.- Instalado con el operador
-
kubectl patch torc trident -n <namespace> --type=merge -p '{"spec":{"debug":true}}'
Así se reiniciarán todos los pods de Trident, que pueden tardar varios segundos. Puede comprobarlo observando la columna "ANTIGÜEDAD" en la salida de
kubectl get pod -n trident
.Para uso de Astra Trident 20.07 y 20.10
tprov
en lugar detorc
. - Instalado con Helm
-
helm upgrade <name> trident-operator-21.07.1-custom.tgz --set tridentDebug=true`
- Instalado con trimentctl
-
./tridentctl uninstall -n trident ./tridentctl install -d -n trident
-
También puede obtener registros de depuración para cada back-end incluyendo
debugTraceFlags
en su definición de backend. Por ejemplo, incluyadebugTraceFlags: {“api”:true, “method”:true,}
Para obtener llamadas API y recorridos de métodos en los registros de Trident. Los back-ends existentes pueden tenerdebugTraceFlags
configurado con unatridentctl backend update
. -
Cuando utilice RedHat CoreOS, asegúrese de ello
iscsid
está activado en los nodos de trabajo e iniciado de forma predeterminada. Esto se puede hacer usando OpenShift MachineConfigs o modificando las plantillas de ignición. -
Un problema común que se puede encontrar cuando se usa Trident con "Azure NetApp Files" es cuando el inquilino y los secretos de cliente provienen de un registro de aplicación con permisos insuficientes. Si desea ver una lista completa de los requisitos de Trident, consulte "Azure NetApp Files" configuración.
-
Si hay problemas con el montaje de un PV en un contenedor, asegúrese de que
rpcbind
está instalado y en ejecución. Utilice el administrador de paquetes necesario para el sistema operativo del host y compruebe sirpcbind
está en ejecución. Puede comprobar el estado derpcbind
ejecutar unsystemctl status rpcbind
o su equivalente. -
Si un back-end de Trident informa que está en la
failed
estado a pesar de haber trabajado antes, es probable que sea por el cambio de las credenciales de SVM/administrador asociadas con el back-end. Actualización de la información del back-end mediantetridentctl update backend
O rebotando el Pod de Trident se corregirá este problema. -
Si se producen problemas de permisos al instalar Trident con Docker como el tiempo de ejecución de contenedores, intente instalar Trident con el
--in cluster=false
bandera. Esto no utilizará un módulo de instalación y evitará problemas de permisos vistos debido a latrident-installer
usuario. -
Utilice la
uninstall parameter <Uninstalling Trident>
para limpiar después de una ejecución fallida. De forma predeterminada, la secuencia de comandos no elimina los CRD creados por Trident, por lo que es seguro desinstalar e instalar de nuevo incluso en una implementación en ejecución. -
Si desea degradar a una versión anterior de Trident, ejecute primero el
tridentctl uninstall
Comando para quitar Trident. Descargue el contenido que desee "Versión de Trident" e instálela utilizandotridentctl install
comando. -
Después de una instalación correcta, si un PVC está atascado en el
Pending
fase, en marchakubectl describe pvc
Puede proporcionar información adicional acerca de por qué Trident no pudo aprovisionar un VP para esta RVP.
Implementación incorrecta de Trident con el operador
Si utiliza el operador, el estado de implementación de Trident TridentOrchestrator
cambios de Installing
para Installed
. Si observa la Failed
y el operador no puede recuperarse por sí solo, debe comprobar los registros del operador ejecutando el siguiente comando:
tridentctl logs -l trident-operator
Al dejar atrás los registros del contenedor del operador-trident, puede indicar dónde se encuentra el problema. Por ejemplo, uno de estos problemas podría ser la incapacidad de extraer las imágenes contenedoras necesarias de los registros de entrada en un entorno con conexión aérea.
Para comprender por qué la instalación de Trident no se ha realizado correctamente, usted
debería echar un vistazo a la TridentOrchestrator
estado.
kubectl describe torc trident-2 Name: trident-2 Namespace: Labels: <none> Annotations: <none> API Version: trident.netapp.io/v1 Kind: TridentOrchestrator ... Status: Current Installation Params: IPv6: Autosupport Hostname: Autosupport Image: Autosupport Proxy: Autosupport Serial Number: Debug: Image Pull Secrets: <nil> Image Registry: k8sTimeout: Kubelet Dir: Log Format: Silence Autosupport: Trident Image: Message: Trident is bound to another CR 'trident' Namespace: trident-2 Status: Error Version: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Error 16s (x2 over 16s) trident-operator.netapp.io Trident is bound to another CR 'trident'
Este error indica que ya existe un TridentOrchestrator
Que se utilizó para instalar Trident. Puesto que cada clúster de Kubernetes solo puede
Tener una instancia de Trident, el operador se asegura de que en cualquier momento dado
el tiempo solo existe uno activo TridentOrchestrator
que puede
cree.
Además, observar el estado de los pods de Trident puede indicar con frecuencia si algo no es correcto.
kubectl get pods -n trident NAME READY STATUS RESTARTS AGE trident-csi-4p5kq 1/2 ImagePullBackOff 0 5m18s trident-csi-6f45bfd8b6-vfrkw 4/5 ImagePullBackOff 0 5m19s trident-csi-9q5xc 1/2 ImagePullBackOff 0 5m18s trident-csi-9v95z 1/2 ImagePullBackOff 0 5m18s trident-operator-766f7b8658-ldzsv 1/1 Running 0 8m17s
Puede ver claramente que los pods no son capaces de inicializarse completamente
porque no se han recuperado una o más imágenes de contenedor.
Para solucionar el problema, debe editar el TridentOrchestrator
CR.
Como alternativa, puede eliminar TridentOrchestrator
, y crear un nuevo
uno con la definición modificada y precisa.
Puesta en marcha de Trident incorrecta mediante tridentctl
Para ayudar a averiguar qué fue lo que salió mal, puede ejecutar el instalador de nuevo utilizando el -d
argumento, que activa el modo de depuración y le ayuda a comprender cuál es el problema:
./tridentctl install -n trident -d
Después de solucionar el problema, puede limpiar la instalación de la siguiente manera y, a continuación, ejecutar el tridentctl install
comando:
./tridentctl uninstall -n trident INFO Deleted Trident deployment. INFO Deleted cluster role binding. INFO Deleted cluster role. INFO Deleted service account. INFO Removed Trident user from security context constraint. INFO Trident uninstallation succeeded.
Elimina por completo Astra Trident y CRD
Puedes quitar por completo Astra Trident y todos los CRD creados y los recursos personalizados asociados.
Esta acción no se puede deshacer. No hagas esto a menos que quieras una instalación completamente nueva de Astra Trident. Para desinstalar Astra Trident sin eliminar CRD, consulte "Desinstale Astra Trident". |
Para desinstalar Astra Trident y eliminar completamente CRD mediante el operador Trident:
kubectl patch torc <trident-orchestrator-name> --type=merge -p '{"spec":{"wipeout":["crds"],"uninstall":true}}'
Para desinstalar Astra Trident y eliminar por completo CRD mediante Helm:
kubectl patch torc trident --type=merge -p '{"spec":{"wipeout":["crds"],"uninstall":true}}'
Para eliminar completamente CRD después de desinstalar Astra Trident mediante tridentctl
tridentctl obliviate crd
Se produce un error al anular el almacenamiento en caché del nodo de NVMe con espacios de nombres de bloque sin configurar RWX o Kubernetes 1,26
Si ejecuta Kubernetes 1,26, la anulación del almacenamiento provisional del nodo puede fallar cuando se usa NVMe/TCP con espacios de nombres de bloque sin configurar de RWX. Los siguientes escenarios proporcionan una solución alternativa al fallo. También puede actualizar Kubernetes a 1,27.
Se ha eliminado el espacio de nombres y el pod
Piensa en un escenario en el que tienes un espacio de nombres gestionado por Astra Trident (volumen persistente NVMe) conectado a un pod. Si elimina el espacio de nombres directamente desde el backend de ONTAP, el proceso de anulación del almacenamiento provisional se bloquea después de intentar eliminar el pod. Este escenario no afecta al clúster de Kubernetes ni a otro funcionamiento.
Desmonte el volumen persistente (que corresponde al espacio de nombres) del nodo correspondiente y elimínelo.
LIF de datos bloqueadas
If you block (or bring down) all the dataLIFs of the NVMe Astra Trident backend, the unstaging process gets stuck when you attempt to delete the pod. In this scenario, you cannot run any NVMe CLI commands on the Kubernetes node. .Solución alternativa Abra dataLIFS para restaurar la funcionalidad completa.
Se ha eliminado la asignación de espacio de nombres
If you remove the `hostNQN` of the worker node from the corresponding subsystem, the unstaging process gets stuck when you attempt to delete the pod. In this scenario, you cannot run any NVMe CLI commands on the Kubernetes node. .Solución alternativa Añada el `hostNQN` de vuelta al subsistema.