Tridentポッドが正常に起動しないと（Tridentポッドがで停止した場合など） ContainerCreating 準備が完了したコンテナが2つ未満のフェーズ）を実行中であること kubectl -n trident describe deployment trident および kubectl -n trident describe pod trident--** 詳細な分析情報を提供できます。kubeletログの取得（例：Via journalctl -xeu kubelet)また有用である場合もある。

Tridentのログに十分な情報がない場合は、にアクセスしてTridentのデバッグモードを有効にすることができます -d インストールオプションに基づいてインストールパラメータにフラグを設定します。

を含めて、各バックエンドのデバッグログを取得することもできます debugTraceFlags バックエンドの定義に含まれています。たとえば、と指定します debugTraceFlags: {“api”:true, “method”:true,} TridentログでAPI呼び出しとメソッドの逆数を取得する。既存のバックエンドにはを追加できます debugTraceFlags を使用して設定します tridentctl backend update。

Red Hat CoreOSを使用する場合は、次の点を確認してください iscsid はワーカーノードで有効になり、デフォルトで開始されます。この設定には、 OpenShift MachineConfig を使用するか、イグニッションテンプレートを変更します。

Trident をで使用する際によく発生する問題です "Azure NetApp Files の特長" テナントとクライアントのシークレットが、必要な権限がないアプリケーションの登録から取得された場合です。Trident の要件の詳細については、を参照してください "Azure NetApp Files の特長" 設定

PVをコンテナにマウントする際に問題が発生する場合は、を確認してください rpcbind をインストールして実行しておきます。ホストOSに必要なパッケージマネージャを使用して、かどうかを確認します rpcbind を実行しています。のステータスを確認できます rpcbind を実行してサービスを提供します systemctl status rpcbind またはそれと同等のものです。

Tridentバックエンドがにあると報告した場合 failed 以前は対処したことがあるにもかかわらず、状況はバックエンドに関連付けられたSVM /管理者クレデンシャルの変更が原因であると考えられます。を使用したバックエンド情報の更新 tridentctl update backend Tridentポッドをバウンスすると、この問題 が修正されます。

Kubernetes クラスタや Trident をアップグレードしてベータ版のボリューム Snapshot を使用する場合は、既存の alpha スナップショット CRS がすべて削除されていることを確認してください。その後、を使用できます tridentctl obliviate alpha-snapshot-crd アルファスナップショット作成の作成を削除するコマンド。を参照してください "この blog" アルファスナップショットの移行手順を理解する。

TridentをDockerでコンテナランタイムとしてインストールする際に権限の問題が発生した場合は、Tridentのインストールをで試してください --in cluster=false フラグ。これはインストーラポッドを使用せず、に起因する許可の問題を回避する trident-installer ユーザ：

を使用します uninstall parameter <Uninstalling Trident> 実行に失敗したあとにクリーンアップに使用します。デフォルトでは、スクリプトは Trident によって作成された CRD を削除しないため、実行中の導入環境でも安全にアンインストールしてインストールできます。

Tridentの以前のバージョンにダウングレードする場合は、最初にを実行します tridenctl uninstall Tridentを削除するコマンド。必要なをダウンロードします "Trident のバージョン" を使用してをインストールします tridentctl install コマンドを実行します新しい PVS が作成されておらず、既存の PVS / バックエンド / ストレージクラスに変更がない場合にのみ、ダウングレードを検討してください。Tridentは現在、状態を維持するためにSSDを使用しているため、作成されたすべてのストレージエンティティ（バックエンド、ストレージクラス、PVS、ボリュームSnapshot）にはが含まれています associated CRD objects <Kubernetes CustomResourceDefinition Objects> 以前にインストールされたTridentのバージョンで使用されていたPVに書き込まれるデータではありません。* 以前のバージョンに戻すと、新しく作成した PVS は使用できなくなります。 * バックエンド、 PVS 、ストレージクラス、ボリュームスナップショット（作成 / 更新 / 削除）などのオブジェクトに加えた変更は、ダウングレード時に Trident に表示されません * 。以前のバージョンの Trident で使用されていた PV は、 Trident から見ることができます。以前のバージョンに戻しても、アップグレードされていないかぎり、以前のリリースを使用してすでに作成された PVS へのアクセスは中断されません。

Tridentを完全に削除するには、を実行します tridentctl obliviate crd コマンドを実行しますこれにより、すべての CRD オブジェクトが削除され、 CRD が定義解除されます。Trident は、すでにプロビジョニングされている PVS を管理しなくなります。

Trident はその後、最初から再構成する必要があります。

インストールが成功した後、PVCがにスタックしている場合 Pending 実行中のフェーズ kubectl describe pvc TridentがこのPVCのPVのプロビジョニングに失敗した理由について追加情報 に説明できる。