トラブルシューティング
変更を提案
PDF
Astra Trident のインストール中および使用中に発生する可能性のある問題のトラブルシューティングには、ここに記載されているポインタを使用してください。
|
Astra Trident のヘルプを参照するには 'tridentctl logs-a -n trident` を使用してサポートバンドルを作成し 'NetApp Support < 困ったときは > に送信してください |
|
トラブルシューティングに関する記事の包括的なリストについては、を参照してください "ネットアップナレッジベース（ログインが必要）"。また、 Astra に関連する問題のトラブルシューティングに関する情報も参照できます "こちらをご覧ください"。 |
全般的なトラブルシューティング
-
Trident ポッドが正常に起動しない場合（たとえば、 Trident ポッドが 2 つ未満の「 ContainerCreating 」フェーズで停止した場合）、「 kubectl-n trident 」を実行して、展開が trident 、「 kubectl-n trident 」が pod trident- を記述します -** 追加のインサイトを提供できます。kubelet ログの取得 (journalctl -xeu kubelet など ) も役立ちます。
-
Trident ログに十分な情報がない場合は、インストールオプションに基づいてインストールパラメータに「 -d 」フラグを渡して、 Trident のデバッグモードを有効にしてみてください。
次に './tridentctl logs -n trident` を使用して debug が設定され ' ログ内で 'level=debug msg' を検索していることを確認します
- オペレータとともにインストールされます
-
# kubectl patch torc trident -n <namespace> --type=merge -p '{"spec":{"debug":true}}'すべての Trident ポッドが再起動されます。これには数秒かかることがあります。これを確認するには 'kubectl get pod -n trident' の出力の 'age' 列を確認します
Astra Trident 20.07 と 20.10 では、「 Torc 」の代わりに「 tprov 」を使用します。
+ 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,}を指定します。既存のバックエンドには 'tridentctl backend update で構成された 'ebugTraceFlags' を設定できます -
RedHat CoreOS を使用する場合は 'iscsid がワーカー・ノードで有効になっており ' デフォルトで起動されていることを確認しますこの設定には、 OpenShift MachineConfig を使用するか、イグニッションテンプレートを変更します。
-
Trident をで使用する際によく発生する問題です "Azure NetApp Files の特長" テナントとクライアントのシークレットが、必要な権限がないアプリケーションの登録から取得された場合です。Trident の要件の詳細については、を参照してください "Azure NetApp Files の特長" 設定
-
コンテナへの PV のマウントに問題がある場合は 'rpcbind' がインストールされていて実行されていることを確認してくださいホスト OS に必要なパッケージ・マネージャを使用して 'rpcbind' が実行されているかどうかを確認しますrpcbind サービスのステータスは 'systemctl status rpcbind' またはそれに相当する処理を実行することで確認できます
-
Trident バックエンドが、以前に作業したことがあるにもかかわらず「 failed 」状態であると報告した場合は、バックエンドに関連付けられている SVM/admin クレデンシャルの変更が原因である可能性があります。「 tridentctl update backend 」または Trident ポッドのバウンスを使用してバックエンド情報を更新すると、この問題は修正されます。
-
Kubernetes クラスタや Trident をアップグレードしてベータ版のボリューム Snapshot を使用する場合は、既存の alpha スナップショット CRS がすべて削除されていることを確認してください。次に 'tridentctl コマンドを使用して ' アルファスナップショットの CRD を削除できますを参照してください "この blog" アルファスナップショットの移行手順を理解する。
-
Docker をコンテナランタイムとして Trident をインストールするときに権限の問題が発生した場合は、「 --in cluster=false」 フラグを付けて Trident のインストールを試みてください。これはインストーラポッドを使用せず、「 trident-installer 」ユーザのために発生する許可の問題を回避します。
-
実行に失敗した後のクリーンアップには 'uninstall パラメータ <Uninstalling Trident > を使用しますデフォルトでは、スクリプトは Trident によって作成された CRD を削除しないため、実行中の導入環境でも安全にアンインストールしてインストールできます。
-
Trident の以前のバージョンにダウングレードする場合は、まず tridenctl uninstall コマンドを実行して Trident を削除します。必要なをダウンロードします "Trident のバージョン" tridentctl install コマンドを使用してインストールします新しい PVS が作成されておらず、既存の PVS / バックエンド / ストレージクラスに変更がない場合にのみ、ダウングレードを検討してください。Trident は現在、ステートの維持に CRD を使用しているため、作成されたすべてのストレージエンティティ（バックエンド、ストレージクラス、 PVS 、およびボリュームスナップショット）には、以前にインストールされた Trident のバージョンで使用されていた PV に書き込まれたデータではなく、「関連 CRD オブジェクト」が含まれています。* 以前のバージョンに戻すと、新しく作成した PVS は使用できなくなります。 * バックエンド、 PVS 、ストレージクラス、ボリュームスナップショット（作成 / 更新 / 削除）などのオブジェクトに加えた変更は、ダウングレード時に Trident に表示されません * 。以前のバージョンの Trident で使用されていた PV は、 Trident から見ることができます。以前のバージョンに戻しても、アップグレードされていないかぎり、以前のリリースを使用してすでに作成された PVS へのアクセスは中断されません。
-
Trident を完全に削除するには、「 tridentctl identviate CRD 」コマンドを実行します。これにより、すべての CRD オブジェクトが削除され、 CRD が定義解除されます。Trident は、すでにプロビジョニングされている PVS を管理しなくなります。
Trident はその後、最初から再構成する必要があります。 -
インストールが成功した後、 PVC が「保留中」段階で停止した場合、「 kubectl 」を実行して 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:
Enable Node Prep:
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 つ以上のコンテナイメージがフェッチされなかったため、ポッドが完全に初期化できないことがわかります。
この問題に対処するには、「 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.