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

故障排除

贡献者

使用此处提供的指针排除安装和使用 Astra Trident 时可能遇到的问题。

常规故障排除

  • 如果 Trident Pod 无法正常启动（例如，当 Trident Pod 停留在 ContainerCreating 阶段且已准备好的容器少于两个时），则运行 kubectl -n trident describe deployment trident and kubectl -n trident describe pod trident -%%.%.%.* -* 可以提供更多见解。获取 kubelet 日志（例如，通过 jlogalctl -xeu kubelet ）也会很有帮助。

  • 如果 Trident 日志中的信息不足，您可以根据安装选项将 ` -d` 标志传递到 install 参数，尝试为 Trident 启用调试模式。

    然后，使用 ` ./tridentctl logs -n trident` 并在日志中搜索 level=debug msg 来确认是否设置了调试。

    随操作员一起安装
    kubectl patch torc trident -n <namespace> --type=merge -p '{"spec":{"debug":true}}'

    此操作将重新启动所有 Trident Pod ，这可能需要几秒钟的时间。您可以通过观察 kubectl get pod -n trident 输出中的 "age" 列来检查此问题。

    对于 Astra Trident 20.07 和 20.10 ，请使用 tprov 代替 Torc 。

    随 Helm 一起安装
    helm upgrade <name> trident-operator-21.07.1-custom.tgz --set tridentDebug=true`
    使用 tridentctl 安装
    ./tridentctl uninstall -n trident
./tridentctl install -d -n trident

  • 您还可以通过在后端定义中包含 debugTraceFlags 来获取每个后端的调试日志。例如，包括 debugTraceFlags ： ｛ "api" ： true ， "method " ： true ， ｝ 以获取 Trident 日志中的 API 调用和方法遍历。现有后端可以已配置 debugTraceFlags 并配置 tridentctl 后端更新 。

  • 使用 RedHat CoreOS 时，请确保在工作节点上启用了 iscsid 并默认启动。可以使用 OpenShift MachineConfigs 或修改点燃模板来完成此操作。

  • 使用 Trident 时可能会遇到的一个常见问题 "Azure NetApp Files" 租户和客户端密码来自权限不足的应用程序注册。有关完整的三项要求列表、请参见 "Azure NetApp Files" Configuration

  • 如果在将 PV 挂载到容器时出现问题，请确保 rpcbind 已安装并正在运行。对主机操作系统使用所需的软件包管理器，并检查 rpcbind 是否正在运行。您可以通过运行 systemctl status rpcbind 或其等效项来检查 rpcbind 服务的状态。

  • 如果 Trident 后端报告其处于 Failed 状态，尽管之前已正常工作，但这可能是由于更改了与后端关联的 SVM/ 管理员凭据所致。使用 tridentctl update backend 更新后端信息或放弃 Trident Pod 将修复此问题描述。

  • 如果在容器运行时安装 Trident 时遇到权限问题，请使用 ` -in cluster=false` 标志尝试安装 Trident 。这不会使用安装程序 POD ，并可避免因 trident 安装程序 用户而出现权限问题。

  • 使用 uninstall 参数 <Uninstalling Trident > 在运行失败后进行清理。默认情况下，该脚本不会删除 Trident 创建的 CRD ，因此即使在正在运行的部署中，也可以安全地卸载并重新安装。

  • 如果要降级到早期版本的三端到功能、请先运行 tridentctl uninstall 用于删除Trident的命令。下载所需的 "Trident 版本" 并使用安装 tridentctl install 命令：

  • 成功安装后，如果 PVC 停留在 Pending 阶段，则运行 kubectl describe PVC 可以提供追加信息，说明 Trident 为何无法为此 PVC 配置 PV 。

使用操作员无法成功部署TRIdent

如果使用操作员部署 Trident ，则 TridentOrchestrator 的状态将从 Installing 更改为 Installed 。如果您观察到 failed 状态，并且操作员无法自行恢复，则应运行以下命令来检查操作员的日志：

tridentctl logs -l trident-operator

跟踪 trident 操作器容器的日志可能会指向问题所在。例如，其中一个问题描述可能是无法从运行良好的环境中的上游注册表中提取所需的容器映像。

要了解 Trident 安装失败的原因，您应查看 TridentOrchestrator 的状态。

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'

此错误表示已存在用于安装 Trident 的 TridentOrchestrator 。由于每个 Kubernetes 集群只能有一个 Trident 实例，因此操作员可确保在任意给定时间只存在一个可创建的活动 TridentOrchestrator 。

此外，观察 Trident Pod 的状态通常可以指示情况是否不正确。

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

您可以清楚地看到，由于未提取一个或多个容器映像， Pod 无法完全初始化。

要解决此问题，您应编辑 TridentOrchestrator CR 。或者，您也可以删除 TridentOrchestrator ，并使用修改后的准确定义创建一个新的。

使用无法成功部署TRIYent tridentctl

为了帮助您找出出现问题的原因，您可以使用 -d 参数再次运行安装程序，该参数将打开调试模式并帮助您了解问题所在：

./tridentctl install -n trident -d

解决此问题后，您可以按如下所示清理安装，然后再次运行 tridentctl install 命令：

./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.

完全删除Asta Trandent和CRD

您可以完全删除Asta Dent以及所有创建的CRD和关联的自定义资源。

警告 此操作无法撤消。除非您需要全新安装Asta三端安装、否则请勿执行此操作。要在不删除CRD的情况下卸载Astra Trdent、请参阅 "卸载 Astra Trident"。
Trident 运算符

要卸载Asta Dandent并使用Dandent操作符完全删除CRD：

kubectl patch torc <trident-orchestrator-name> --type=merge -p '{"spec":{"wipeout":["crds"],"uninstall":true}}'
掌舵

要使用Helm卸载Asta Dent并完全删除CRD、请执行以下操作：

kubectl patch torc trident --type=merge -p '{"spec":{"wipeout":["crds"],"uninstall":true}}'
<code>tridentctl</code>

在使用卸载Asta Dent后完全删除CRD tridentctl

tridentctl obliviate crd

使用Kubnetes 1.26上的rwx原始块命名区卸载NVMe节点失败

如果您运行的是Kubnetes 1.26、则在对rwx原始块命名区使用NVMe/TCP时、节点取消暂存可能会失败。以下场景提供了故障的临时解决策。或者、您也可以将Kubbernetes升级到1.27。

已删除命名空间和POD

假设您已将Asta三端到托管命名空间(NVMe永久性卷)附加到Pod。如果直接从ONTAP后端删除命名空间、则取消暂存过程会在您尝试删除Pod后停滞。此情形不会影响Kubornetes集群或其他功能。

临时解决策

从相应节点卸载永久性卷(与该命名空间对应)并将其删除。

已阻止数据LIF

 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.
.临时解决策
启动dataLIF以恢复完整功能。

已删除命名空间映射

 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.
.临时解决策
添加 `hostNQN` 返回到子系统。