トラブルシューティング
Astra Trident のインストール中および使用中に発生する可能性のある問題のトラブルシューティングには、ここに記載されているポインタを使用してください。
Astra Tridentのサポートを受けるには、を使用してサポートバンドルを作成してください tridentctl logs -a -n trident に送信します NetApp Support <Getting Help> 。
|
トラブルシューティングに関する記事の包括的なリストについては、を参照してください "ネットアップナレッジベース(ログインが必要)"。また、 Astra に関連する問題のトラブルシューティングに関する情報も参照できます "こちらをご覧ください"。 |
全般的なトラブルシューティング
-
Tridentポッドが正常に起動しないと(Tridentポッドがで停止した場合など)
ContainerCreating
準備が完了したコンテナが2つ未満のフェーズ)を実行中であることkubectl -n trident describe deployment trident
およびkubectl -n trident describe pod trident--**
詳細な分析情報を提供できます。kubeletログの取得(例:Viajournalctl -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ポッドをバウンスすると、この問題 が修正されます。 -
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の以前のバージョンにダウングレードする場合は、最初にを実行します
tridentctl 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のプロビジョニングに失敗した理由について追加情報 に説明できる。
オペレータを使用して失敗した 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.