Skip to main content
本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

トラブルシューティング

PDF

Tridentのインストールおよび使用中に発生する可能性のある問題のトラブルシューティングについては、ここに示すヒントを参照してください。

メモ Tridentのヘルプについては、 `tridentctl logs -a -n trident`を使用してサポートバンドルを作成し、NetAppサポートに送信してください。

一般的なトラブルシューティング

  • Tridentポッドが正常に起動しない場合（例えば、Tridentポッドが `ContainerCreating`フェーズで準備完了コンテナが2つ未満の状態で停止している場合）、 `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ポッドが再起動されます。これには数秒かかることがあります。これは、 `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`を含めることもできます。例えば、TridentログでAPIコールやメソッドのトラバーサルを取得するには、 `debugTraceFlags: {"api":true, "method":true,}`を含めてください。既存のバックエンドには、 `debugTraceFlags`を `tridentctl backend update`で設定できます。

  • Red Hat Enterprise Linux CoreOS (RHCOS)を使用する場合は、 `iscsid`がワーカーノードで有効になっており、デフォルトで起動されていることを確認してください。これは、OpenShift MachineConfigsを使用するか、ignitionテンプレートを変更することで実行できます。

  • Tridentを "Azure NetApp Files"で使用する際に発生する可能性のある一般的な問題は、テナントシークレットとクライアントシークレットが、権限が不十分なアプリ登録から取得された場合です。Trident要件の完全なリストについては、"Azure NetApp Files"構成を参照してください。

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

  • Tridentバックエンドが以前は動作していたにもかかわらず `failed`状態であると報告する場合は、バックエンドに関連付けられたSVM/管理者の資格情報が変更されたことが原因である可能性があります。 `tridentctl update backend`を使用してバックエンド情報を更新するか、Tridentポッドをバウンスすることで、この問題は解決されます。

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

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

  • 以前のバージョンのTridentにダウングレードする場合は、まず `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-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'

このエラーは、Tridentのインストールに使用された `TridentOrchestrator`がすでに存在することを示しています。各KubernetesクラスタにはTridentのインスタンスを1つしか配置できないため、オペレータは、任意の時点でアクティブな `TridentOrchestrator`が1つだけ存在するようにします。

さらに、Tridentポッドのステータスを確認することで、何かが正常でない場合にそれを知らせることがよくあります。

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

1つ以上のコンテナイメージが取得されなかったため、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および CRD を完全に削除

Trident と作成されたすべての CRD および関連するカスタムリソースを完全に削除できます。

警告 これを元に戻すことはできません。Trident を完全に新規インストールする場合以外は、これを実行しないでください。CRD を削除せずに Trident をアンインストールするには、"Tridentのアンインストール"を参照してください。
Trident オペレータ

Tridentオペレータを使用してTridentをアンインストールし、CRDを完全に削除するには：

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

Trident をアンインストールし、Helm を使用して CRD を完全に削除するには：

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

Tridentをアンインストールした後にCRDを完全に削除するには tridentctl

tridentctl obliviate crd

Kubernetes 1.26 の RWX raw ブロック名前空間での NVMe ノードのアンステージング失敗

Kubernetes 1.26 を実行している場合、RWX 生のブロック名前空間で NVMe/TCP を使用すると、ノードのステージング解除が失敗する可能性があります。次のシナリオは、失敗に対する回避策を提供します。あるいは、Kubernetes を 1.27 にアップグレードすることもできます。

ネームスペースとポッドを削除しました

Trident で管理されている名前空間（NVMe 永続ボリューム）がポッドに接続されているシナリオを考えてみます。ONTAP バックエンドから直接名前空間を削除すると、ポッドを削除しようとした後、ステージング解除プロセスが停止します。このシナリオは、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.
.回避策
完全な機能を復元するには、dataLIFS を起動します。

名前空間マッピングを削除しました

 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`をサブシステムに追加し直します。

NFSv4.2クライアントは、「v4.2-xattrs」が有効になっていることを期待している場合、ONTAPのアップグレード後に「invalid argument」を報告します

ONTAP のアップグレード後、NFSv4.2 クライアントが NFSv4.2 エクスポートをマウントしようとすると「無効な引数」エラーを報告する場合があります。この問題は、SVM で `v4.2-xattrs`オプションが有効になっていない場合に発生します。.回避策：SVM で `v4.2-xattrs`オプションを有効にするか、ONTAP 9.12.1 以降にアップグレードしてください。このバージョンでは、このオプションがデフォルトで有効になっています。