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.

Automatización de la conmutación por error de aplicaciones con estado con Trident

10/31/2025 Colaboradores

PDF

La función de desconexión forzada de Trident permite desconectar automáticamente los volúmenes de los nodos defectuosos en un clúster de Kubernetes, evitando la corrupción de datos y garantizando la disponibilidad de las aplicaciones. Esta función resulta especialmente útil en escenarios donde los nodos dejan de responder o se desconectan para realizar tareas de mantenimiento.

Detalles acerca de forzar separación

La separación forzada está disponible para ontap-san , ontap-san-economy , ontap-nas , y ontap-nas-economy solo. Antes de habilitar la desconexión forzada, se debe habilitar el apagado de nodo no elegante (NGNS) en el clúster de Kubernetes. NGNS está habilitado de forma predeterminada para Kubernetes 1.28 y superiores. Para obtener más información, consulte "Kubernetes: Cierre de nodo sin gracia" .

Cuando se utiliza ontap-nas el controlador o ontap-nas-economy, es necesario establecer el autoExportPolicy parámetro en la configuración de back-end para true que Trident pueda restringir el acceso desde el nodo Kubernetes con la contaminación aplicada mediante políticas de exportación gestionadas.

Dado que Trident se basa en LAS NGN de Kubernetes, no elimine out-of-service los daños de un nodo en mal estado hasta que se reprogramen todas las cargas de trabajo no tolerables. La aplicación o eliminación imprudente de la contaminación puede poner en peligro la protección de datos de back-end.

Cuando el administrador del clúster de Kubernetes haya aplicado la node.kubernetes.io/out-of-service=nodeshutdown:NoExecute tinta al nodo y enableForceDetach se establezca en true, Trident determinará el estado del nodo y:

Detener el acceso de E/S de backend para los volúmenes montados en ese nodo.

Marque el objeto de nodo Trident como dirty (no es seguro para las nuevas publicaciones).

El controlador Trident rechazará nuevas solicitudes de volumen de publicación hasta que el nodo se vuelva a calificar (después de haberse marcado como dirty) por el pod del nodo Trident. No se aceptarán todas las cargas de trabajo programadas con una RVP montada (incluso después de que el nodo del clúster esté en buen estado y listo) hasta que Trident pueda verificar el nodo clean (seguro para las nuevas publicaciones).

Cuando se restaure el estado del nodo y se elimine el tinte, Trident:

Identifique y limpie las rutas publicadas obsoletas en el nodo.
Si el nodo está en un cleanable estado (se ha quitado el taint de fuera de servicio y el nodo está en Ready estado) y todas las rutas obsoletas publicadas están limpias, Trident readmitirá el nodo como clean y permitirá que los nuevos volúmenes publicados al nodo.

Detalles sobre la conmutación por error automatizada

Puedes automatizar el proceso de desconexión forzada mediante la integración con"operador de comprobación del estado del nodo (NHC)" . Cuando se produce un fallo en un nodo, NHC activa la remediación de nodos Trident (TNR) y la desconexión forzada automáticamente mediante la creación de un CR TridentNodeRemediation en el espacio de nombres de Trident que define el nodo que ha fallado. El TNR se crea únicamente en caso de fallo del nodo y el NHC lo elimina una vez que el nodo vuelve a estar en línea o se elimina el nodo.

Falló el proceso de eliminación del pod del nodo.

La conmutación por error automatizada selecciona las cargas de trabajo que se eliminarán del nodo que ha fallado. Cuando se crea un TNR, el controlador TNR marca el nodo como modificado, impidiendo cualquier publicación de nuevos volúmenes y comenzando a eliminar los pods compatibles con desconexión forzada y sus conexiones de volumen.

Todos los volúmenes/PVC compatibles con la desconexión forzada son compatibles con la conmutación por error automatizada:

NAS y volúmenes NAS-economy que utilizan políticas de exportación automática (SMB aún no es compatible).
SAN y volúmenes de economía SAN.

Referirse aDetalles acerca de forzar separación .

Comportamiento predeterminado:

Los pods que utilizan volúmenes compatibles con force-detach se eliminan del nodo que ha fallado. Kubernetes reprogramará estas tareas en un nodo en buen estado.
Los pods que utilizan un volumen no compatible con force-detach, incluidos los volúmenes que no son Trident, no se eliminan del nodo que ha fallado.
Los pods sin estado (que no son PVC) no se eliminan del nodo fallido, a menos que la anotación del pod trident.netapp.io/podRemediationPolicy: delete está listo.

Anulación del comportamiento de eliminación de pods:

El comportamiento de eliminación de pods se puede personalizar mediante una anotación de pod: trident.netapp.io/podRemediationPolicy[retain, delete] . Estas anotaciones se examinan y utilizan cuando se produce una conmutación por error. Aplique anotaciones a la especificación del pod de despliegue/conjunto de réplicas de Kubernetes para evitar que la anotación desaparezca después de una conmutación por error:

retain- El pod NO se eliminará del nodo fallido durante una conmutación por error automatizada.
delete- El pod SERÁ eliminado del nodo fallido durante una conmutación por error automatizada.

Estas anotaciones se pueden aplicar a cualquier pod.

Las operaciones de E/S se bloquearán únicamente en los nodos fallidos para los volúmenes que admiten la desconexión forzada.
Para los volúmenes que no admiten la desconexión forzada, existe riesgo de corrupción de datos y problemas de conexión múltiple.

CR de remediación de nodos Trident

El CR TridentNodeRemediation (TNR) define un nodo fallido. El nombre del TNR es el nombre del nodo que falló.

Ejemplo de TNR:

apiVersion: trident.netapp.io/v1
kind: TridentNodeRemediation
metadata:
  name: <K8s-node-name>
spec: {}

Estado de TNR: Utilice los siguientes comandos para ver el estado de los TNR:
kubectl get tnr <name> -n <trident-namespace>

Los TNR pueden encontrarse en uno de los siguientes estados:

Remediación:
- Suspender el acceso de E/S de backend para los volúmenes compatibles con force-detach montados en ese nodo.
- El objeto de nodo Trident está marcado como sucio (no es seguro para nuevas publicaciones).
- Retire los pods y las conexiones de volumen del nodo.
Recuperación de nodo pendiente:
- El controlador está esperando a que el nodo vuelva a estar en línea.
- Una vez que el nodo esté en línea, la aplicación de la publicación garantizará que el nodo esté limpio y listo para nuevas publicaciones de volúmenes.
Si el nodo se elimina de K8s, el controlador TNR eliminará el TNR y detendrá la reconciliación.
Éxito:
- Todos los pasos de remediación y recuperación de nodos se completaron con éxito. El nodo está limpio y listo para nuevas publicaciones de volúmenes.
Fallido:
- Error irrecuperable. Los motivos de error se establecen en el campo status.message del CR.

Habilitación de la conmutación por error automática

Requisitos previos:

Asegúrese de que la desconexión forzada esté habilitada antes de habilitar la conmutación por error automática. Para obtener más información, consulteDetalles acerca de forzar separación .
Instale la comprobación del estado del nodo (NHC) en el clúster de Kubernetes.
- "Instalar operator-sdk".
- Instale Operator Lifecycle Manager (OLM) en el clúster si aún no está instalado: operator-sdk olm install .
- Instalar el operador de comprobación del estado del nodo: kubectl create -f https://operatorhub.io/install/node-healthcheck-operator.yaml .

También puede utilizar métodos alternativos para detectar fallos de nodo, tal como se especifica en el[Integrating Custom Node Health Check Solutions] sección a continuación.

Ver"Operador de comprobación del estado del nodo" Para más información.

Pasos

Cree un CR NodeHealthCheck (NHC) en el espacio de nombres Trident para supervisar los nodos de trabajo en el clúster. Ejemplo:

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: <CR name>
spec:
  selector:
    matchExpressions:
      - key: node-role.kubernetes.io/control-plane
        operator: DoesNotExist
      - key: node-role.kubernetes.io/master
        operator: DoesNotExist
  remediationTemplate:
    apiVersion: trident.netapp.io/v1
    kind: TridentNodeRemediationTemplate
    namespace: <Trident installation namespace>
    name: trident-node-remediation-template
  minHealthy: 0 # Trigger force-detach upon one or more node failures
  unhealthyConditions:
    - type: Ready
      status: "False"
      duration: 0s
    - type: Ready
      status: Unknown
      duration: 0s

Aplique la comprobación de estado del nodo CR en el trident espacio de nombres.

kubectl apply -f <nhc-cr-file>.yaml -n <trident-namespace>

El CR anterior está configurado para vigilar los nodos de trabajo de K8s en busca de condiciones de nodo Ready: false y Unknown. La conmutación por error automática se activará cuando un nodo pase al estado Listo: falso o Listo: desconocido.

El unhealthyConditions En el CR se utiliza un período de gracia de 0 segundos. Esto provoca que la conmutación por error automatizada se active inmediatamente después de que K8s establezca la condición del nodo Ready: false, que se establece después de que K8s pierde el latido de un nodo. K8s tiene un tiempo de espera predeterminado de 40 segundos después del último latido antes de establecer Ready: false. Este período de gracia se puede personalizar en las opciones de implementación de K8s.

Para obtener opciones de configuración adicionales, consulte"Documentación del operador de comprobación de estado del nodo" .

Información de configuración adicional

Cuando Trident se instala con la opción de desconexión forzada habilitada, se crean automáticamente dos recursos adicionales en el espacio de nombres de Trident para facilitar la integración con NHC: TridentNodeRemediationTemplate (TNRT) y ClusterRole.

Plantilla de remediación de nodos Trident (TNRT):

El TNRT sirve como plantilla para el controlador NHC, que utiliza el TNRT para generar recursos TNR según sea necesario.

apiVersion: trident.netapp.io/v1
kind: TridentNodeRemediationTemplate
metadata:
  name: trident-node-remediation-template
  namespace: trident
spec:
  template:
    spec: {}

Rol de clúster:

También se agrega un rol de clúster durante la instalación cuando se habilita la desconexión forzada. Esto otorga a NHC permisos para TNR en el espacio de nombres Trident .

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    rbac.ext-remediation/aggregate-to-ext-remediation: "true"
  name: tridentnoderemediation-access
rules:
- apiGroups:
  - trident.netapp.io
  resources:
  - tridentnoderemediationtemplates
  - tridentnoderemediations
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete

Actualizaciones y mantenimiento de clústeres K8s

Para evitar cualquier conmutación por error, pause la conmutación por error automatizada durante el mantenimiento o las actualizaciones de K8s, cuando se espera que los nodos se desconecten o se reinicien. Puedes pausar el CR del NHC (descrito anteriormente) parcheando su CR:

kubectl patch NodeHealthCheck <cr-name> --patch '{"spec":{"pauseRequests":["<description-for-reason-of-pause>"]}}' --type=merge

Esto pausa el proceso de conmutación por error automática. Para volver a habilitar la conmutación por error automática, elimine las solicitudes de pausa de la especificación una vez finalizado el mantenimiento.

Limitaciones

Las operaciones de E/S se impiden únicamente en los nodos fallidos para los volúmenes compatibles con force-detach. Solo se eliminan automáticamente los pods que utilizan volúmenes/PVC compatibles con force-detach.
La conmutación por error automática y la desconexión forzada se ejecutan dentro del módulo controlador Trident. Si falla el nodo que aloja el controlador Trident, la conmutación por error automatizada se retrasará hasta que K8s mueva el pod a un nodo en buen estado.

Integración de soluciones personalizadas de comprobación del estado de los nodos

Puede reemplazar el operador de comprobación de estado del nodo con herramientas alternativas de detección de fallos de nodo para activar la conmutación por error automática. Para garantizar la compatibilidad con el mecanismo de conmutación por error automatizado, su solución personalizada debe:

Cree un TNR cuando se detecte una falla de nodo, utilizando el nombre del nodo fallido como nombre CR del TNR.
Elimine el TNR cuando el nodo se haya recuperado y el TNR esté en el estado Correcto.