简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

使用 Trident 自动化有状态应用程序的故障转移

02/26/2026

Trident 的强制分离功能允许您自动从 Kubernetes 集群中的不正常节点分离卷，从而防止数据损坏并确保应用程序可用性。此功能在节点无响应或因维护而离线的情况下特别有用。

关于强制分离的详细信息

强制分离仅适用于 ontap-san、 ontap-san-economy、 ontap-nas`和 `ontap-nas-economy。在启用强制分离之前，必须在 Kubernetes 集群上启用非优雅节点关闭（NGNS）。默认情况下，Kubernetes 1.28 及更高版本已启用 NGNS。有关详细信息，请参阅"Kubernetes：非 Graceful 节点关闭"。

使用 ontap-nas 或 ontap-nas-economy 驱动程序时，需要在后端配置中将 autoExportPolicy 参数设置为 true，以便 Trident 可以使用托管导出策略限制来自应用了污点的 Kubernetes 节点的访问。

由于 Trident 依赖于 Kubernetes NGNS，因此在重新安排所有无法忍受的工作负载之前，请勿从不正常的节点中删除 `out-of-service`污点。不计后果地应用或删除污点可能会危及后端数据保护。

当 Kubernetes 集群管理员将 node.kubernetes.io/out-of-service=nodeshutdown:NoExecute taint 应用到节点并将 `enableForceDetach`设置为 `true`时，Trident 将确定节点状态并：

停止对装载到该节点的卷的后端 I/O 访问。

将 Trident 节点对象标记为 dirty（对新发布不安全）。

Trident 控制器将拒绝新的发布卷请求，直到节点被 Trident 节点 Pod 重新限定（在被标记为 dirty`之后）。在 Trident 能够验证节点 `clean（对新发布安全）之前，将不接受使用已挂载 PVC 调度的任何工作负载（即使在集群节点健康且就绪之后）。

当节点运行状况恢复并清除污点时，Trident 将：

识别并清除节点上过时的已发布路径。
如果该节点处于 `cleanable`状态（已清除停用污点，并且该节点处于 `Ready`状态），并且所有过时、已发布的路径都是干净的，则 Trident 将重新接收该节点为 `clean`并允许新发布的卷进入该节点。

有关自动故障转移的详细信息

您可以通过与 "节点运行状况检查 (NHC) 操作器" 集成来自动执行强制分离过程。当发生节点故障时，NHC 会触发 Trident 节点修复（TNR），并通过在 Trident 命名空间中创建 TridentNodeRemediation CR 来定义故障节点，从而自动进行强制分离。TNR 仅在节点故障时创建，并在节点恢复联机或节点被删除后由 NHC 删除。

节点 pod 移除过程失败

自动故障转移选择要从故障节点中删除的工作负载。创建 TNR 后，TNR 控制器将节点标记为脏节点，防止任何新的卷发布，并开始删除强制拆卸支持的 Pod 及其卷附件。

自动故障转移支持强制拆卸支持的所有卷/PVC：

使用自动导出策略的 NAS 和 NAS-economy 卷（尚不支持 SMB）。
SAN 和 SAN-economy 卷。

请参阅关于强制分离的详细信息。

默认行为：

使用强制拆卸支持的卷的 Pod 将从故障节点中删除。Kubernetes 会将这些重新调度到健康的节点上。
使用强制拆卸不支持的卷（包括非 Trident 卷）的 Pod 不会从故障节点中删除。
除非设置了 Pod 注释 trident.netapp.io/podRemediationPolicy: delete，否则不会从故障节点中删除无状态 Pod（非 PVC）。

覆盖 Pod 移除行为：

可以使用 Pod 注释自定义 Pod 移除行为： trident.netapp.io/podRemediationPolicy[retain, delete]。当发生故障转移时，会检查并使用这些注释。将注释应用于 Kubernetes deployment/replicaset pod 规范，以防止故障转移后注释消失：

retain - 在自动故障转移期间，不会从故障节点中删除 Pod。
delete - 在自动故障转移期间，Pod 将从故障节点中删除。

这些注释可以应用于任何 pod。

对于支持强制分离的卷，I/O 操作仅在故障节点上被阻止。
对于不支持强制分离的卷，存在数据损坏和多重连接问题的风险。

TridentNodeRemediation CR

TridentNodeRemediation (TNR) CR 定义失败的节点。TNR 的名称是失败节点的名称。

TNR 示例：

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

TNR 状态：使用以下命令查看 TNR 的状态：
kubectl get tnr <name> -n <trident-namespace>

TNR 可能处于以下状态之一：

修复中：
- 停止对装载到该节点的强制拆卸所支持的卷的后端 I/O 访问。
- Trident 节点对象被标记为脏（对于新出版物不安全）。
- 从节点中删除 Pod 和卷附件
NodeRecoveryPending：
- 控制器正在等待节点恢复联机。
- 节点联机后，发布强制将确保节点干净，可供新卷发布。
如果从 K8s 中删除节点，TNR 控制器将删除 TNR 并停止对账。
成功：
- 已成功完成所有修正和节点恢复步骤。节点已干净，可供新卷发布。
失败：
- 不可恢复的错误。错误原因在 CR 的 status.message 字段中设置。

启用自动故障转移

前提条件：

在启用 automated-failover 之前，请确保已启用强制分离。有关详细信息，请参阅关于强制分离的详细信息。
在 Kubernetes 集群中安装节点运行状况检查 (NHC)。
- "安装 operator-sdk"。
- 在集群中安装 Operator Lifecycle Manager (OLM)（如果尚未安装）： operator-sdk olm install。
- 安装 Node Health check Operator： kubectl create -f https://operatorhub.io/install/node-healthcheck-operator.yaml。

您还可以使用其他方法来检测节点故障，如下面的 [Integrating Custom Node Health Check Solutions] 部分所述。

有关详细信息，请参见 "节点健康检查运算符"。

步骤

在 Trident 命名空间中创建 NodeHealthCheck (NHC) CR 以监视集群中的工作节点。示例：

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

在 trident 命名空间中应用节点运行状况检查 CR。

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

上述 CR 配置为监视 K8s worker 节点的节点条件 Ready: false 和 Unknown。节点进入 Ready: false 或 Ready: Unknown 状态时将触发 Automated-Failover。

CR 中的 `unhealthyConditions`使用 0 秒宽限期。这导致自动故障转移在 K8s 设置节点条件 Ready: false 时立即触发，这是在 K8s 失去节点的心跳后设置的。K8s 的默认值为最后一次心跳后等待 40 秒，然后设置 Ready: false。可以在 K8s 部署选项中自定义此宽限期。

要查看其他配置选项，请参阅 "Node-Healthcheck-Operator 文档"。

其他设置信息

安装 Trident 并启用强制拆卸功能时，系统将在 Trident 命名空间中自动创建两个额外资源，以促进与 NHC 的集成：TridentNodeRemediationTemplate (TNRT) 和 ClusterRole。

TridentNodeRemediationTemplate (TNRT)：

TNRT 充当 NHC 控制器的模板，该控制器根据需要使用 TNRT 生成 TNR 资源。

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

ClusterRole：

启用强制拆卸后，在安装过程中也会添加群集角色。这赋予了 NHC 对 Trident 命名空间中 TNR 的权限。

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

K8s 集群升级和维护

为了防止任何故障转移，请在 K8s 维护或升级期间暂停自动故障转移，其中节点预计会停机或重新启动。您可以通过修补 CR 来暂停 NHC CR（如上所述）：

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

这会暂停自动故障转移。要重新启用自动故障转移，请在维护完成后从规范中删除 pauseRequests。

限制

仅在强制分离支持的卷的故障节点上阻止 I/O 操作。只有使用强制分离支持的卷/PVC 的 Pod 才会自动移除。
自动故障转移和强制拆卸在 trident-controller pod 内运行。如果托管 trident-controller 的节点出现故障，则自动故障转移将被延迟，直到 K8s 将 pod 移动到健康节点。

集成自定义节点运行状况检查解决方案

您可以将 Node Healthcheck Operator 替换为备用节点故障检测工具以触发自动故障转移。为了确保与自动故障转移机制的兼容性，您的自定义解决方案应：

检测到节点故障时创建 TNR，使用故障节点的名称作为 TNR CR 名称。
当节点已恢复且 TNR 处于 Succeeded 状态时，请删除 TNR。