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

トラブルシューティング

共同作成者

Astra Trident のインストール中および使用中に発生する可能性のある問題のトラブルシューティングには、ここに記載されているポインタを使用してください。

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

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

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

    次に、を使用してデバッグが設定されていることを ./tridentctl logs -n trident を検索しています level=debug msg ログに記録されます。

    オペレータとともにインストールされます
    kubectl patch torc trident -n <namespace> --type=merge -p '{"spec":{"debug":true}}'

    すべての Trident ポッドが再起動されます。これには数秒かかることがあります。これを確認するには、の出力の「経過時間」列を確認します kubectl get pod -n trident

    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 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ポッドをバウンスすると、この問題 が修正されます。

  • TridentをDockerでコンテナランタイムとしてインストールする際に権限の問題が発生した場合は、Tridentのインストールをで試してください --in cluster=false フラグ。これはインストーラポッドを使用せず、に起因する許可の問題を回避する 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 コンテナのログの末尾には、問題のある場所を示すことができます。たとえば、このような問題の 1 つは、エアーギャップ環境のアップストリームレジストリから必要なコンテナイメージをプルできないことです。

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のインスタンスを1つ使用することで、
アクティブな状態が1つだけ存在する時間 TridentOrchestrator それができること
を作成します。

また、 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つ以上のコンテナイメージが取得されなかったためです。

問題に対処するには、を編集する必要があります 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.

Astra TridentとCRDを完全に削除

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

警告 この操作は元に戻せません。Astra Tridentを完全に新規にインストールする場合を除き、この作業は行わないでください。CRDを削除せずにAstra Tridentをアンインストールする方法については、を参照してください。 "Astra Trident をアンインストール"
Trident オペレータ

Astra Tridentをアンインストールし、Tridentオペレータを使用してCRDを完全に削除するには、次の手順を実行します。

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

Astra Tridentをアンインストールし、Helmを使用してCRDを完全に削除する手順は次のとおりです。

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

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

tridentctl obliviate crd

RWX rawブロックネームスペースo Kubernetes 1.26でNVMeノードのステージング解除が失敗する

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

ネームスペースとポッドが削除されました

Astra Tridentで管理されるネームスペース(NVMeの永続的ボリューム)をポッドに接続したシナリオを考えてみましょう。ネームスペースをONTAPバックエンドから直接削除すると、ポッドを削除しようとすると、ステージング解除プロセスが停止します。このシナリオは、Kubernetesクラスタやその他の機能には影響しません。

回避策

該当するノードから永続的ボリューム(そのネームスペースに対応するボリューム)をアンマウントして削除します。

ブロックされたデータ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.
.回避策
すべての機能を復元するには、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` サブシステムに戻ります。