疑難排解
建議變更
PDF
使用此處提供的提示來解決您在安裝和使用 Trident 時可能遇到的問題。
|
如需 Trident 協助，請使用 `tridentctl logs -a -n trident`建立支援套裝組合，並將其傳送給 NetApp 支援部門。 |
一般疑難排解
-
如果 Trident Pod 無法正常啟動（例如，當 Trident Pod 卡在
ContainerCreating`階段且就緒容器少於兩個時），執行 `kubectl -n trident describe deployment trident`和 `kubectl -n trident describe pod trident--**`可以提供更多資訊。取得 kubelet 日誌（例如，透過 `journalctl -xeu kubelet）也很有幫助。 -
如果 Trident 日誌中的資訊不足，您可以嘗試根據您的安裝選項，透過傳送 `-d`標誌給安裝參數來啟用 Trident 的偵錯模式。
然後使用
./tridentctl logs -n trident`確認已設定偵錯，並在日誌中搜尋 `level=debug msg。- 已安裝 Operator
-
kubectl patch torc trident -n <namespace> --type=merge -p '{"spec":{"debug":true}}'這將重新啟動所有 Trident Pod，這可能需要幾秒鐘。您可以透過觀察
kubectl get pod -n trident輸出中的「AGE」欄來檢查這一點。對於 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 backend update`來設定。 -
使用 Red Hat Enterprise Linux CoreOS (RHCOS) 時，請確保在工作節點上啟用 `iscsid`並預設為啟動。這可以使用 OpenShift MachineConfigs 或透過修改 ignition 模板來實現。
-
使用 Trident 搭配 "Azure NetApp Files"時，您可能會遇到的常見問題是租用戶金鑰和客戶端金鑰來自權限不足的應用程式註冊。有關 Trident 要求的完整清單，請參閱"Azure NetApp Files"組態。
-
如果將 PV 掛載到容器時出現問題，請確保已安裝並執行
rpcbind。請使用主機作業系統所需的套件管理員，並檢查 `rpcbind`是否正在執行。您可以透過執行 `systemctl status rpcbind`或其等效指令，來檢查 `rpcbind`服務的狀態。 -
如果 Trident 後端報告處於
failed狀態，即使先前運作正常，也可能是因為變更了與後端關聯的 SVM/管理員憑證所致。使用tridentctl update backend更新後端資訊或重新啟動 Trident pod 即可解決此問題。 -
如果在使用 Docker 作為容器執行時安裝 Trident 時遇到權限問題，請嘗試使用 `--in cluster=false`旗標安裝 Trident。這將不使用安裝程式 Pod，並避免因 `trident-installer`使用者而導致的權限問題。
-
使用 `uninstall parameter <Uninstalling Trident>`進行失敗執行後的清理。預設情況下，該腳本不會刪除 Trident 所建立的 CRD，因此即使在執行中的部署中，也可以安全地解除安裝並重新安裝。
-
如果您想要降級到早期版本的 Trident，請先執行 `tridentctl uninstall`指令以移除 Trident。下載所需的 "Trident 版本"並使用 `tridentctl install`指令進行安裝。
-
安裝成功後，如果 PVC 卡在 `Pending`階段，執行 `kubectl describe pvc`可以提供有關 Trident 未能為此 PVC 配置 PV 的其他資訊。
使用操作員部署 Trident 失敗
如果您使用 Operator 部署 Trident，則 TridentOrchestrator`的狀態會從 `Installing`變為 `Installed。如果您觀察到 `Failed`狀態，且 Operator 無法自行恢復，則應執行以下命令檢查 Operator 的日誌：
tridentctl logs -l trident-operator
追蹤 trident-operator 容器的日誌可以指出問題所在。例如，其中一個問題可能是無法在隔離環境中從上游登錄檔拉取所需的容器映像。
要了解為什麼 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'
此錯誤表示已存在 TridentOrchestrator`用於安裝 Trident。由於每個 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，然後使用修改後的準確定義建立新的變更要求。
使用 Trident 部署失敗 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.
徹底移除 Trident 和 CRDs
您可以完全移除 Trident 以及所有建立的 CRD 和相關的自訂資源。
|
此操作無法撤銷。除非您想要全新安裝 Trident，否則請勿執行此操作。若要解除安裝 Trident 而不移除 CRD，請參閱 "解除安裝 Trident"。 |
若要解除安裝 Trident 並使用 Trident 運算子徹底移除 CRD：
kubectl patch torc <trident-orchestrator-name> --type=merge -p '{"spec":{"wipeout":["crds"],"uninstall":true}}'
使用 Helm 卸載 Trident 並徹底刪除 CRD：
kubectl patch torc trident --type=merge -p '{"spec":{"wipeout":["crds"],"uninstall":true}}'
若要在使用 tridentctl 解除安裝 Trident 後完全移除 CRD
tridentctl obliviate crd
Kubernetes 1.26 版本中，使用 RWX 原始區塊命名空間時，NVMe 節點卸載失敗
如果您執行的是 Kubernetes 1.26，在使用 NVMe/TCP 搭配 RWX 原始區塊命名空間時，節點取消暫存可能會失敗。下列案例提供失敗的因應措施。或者，您也可以將 Kubernetes 升級至 1.27。
刪除了命名空間和 pod
假設您有一個 Trident 管理的命名空間（NVMe 持久卷）附加到 pod。如果您直接從 ONTAP 後端刪除該命名空間，則在嘗試刪除 pod 後，卸載程序會卡住。這種情況不會影響 Kubernetes 叢集或其他功能。
從對應的節點卸載持久性磁碟區 （與該命名空間對應），並將其刪除。
已封鎖的資料 LIF
If you block (or bring down) all the dataLIFs of the NVMe 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` 後端加入子系統。
升級 ONTAP 後，NFSv4.2 用戶端在預期啟用「v4.2-xattrs」時回報「invalid argument」
升級 ONTAP 後，NFSv4.2 用戶端在嘗試掛載 NFSv4.2 匯出時可能會報告「無效參數」錯誤。此問題發生於 SVM 上未啟用 `v4.2-xattrs`選項時。.因應措施：在 SVM 上啟用 `v4.2-xattrs`選項，或升級至 ONTAP 9.12.1 或更新版本，此選項在該版本中預設為啟用。