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

既知の問題

共同作成者

クラスタの管理後にボリュームnapshotclassを追加すると、アプリケーションのバックアップとSnapshotが失敗します

でバックアップとSnapshotの作成が失敗する UI 500 error このシナリオでは、回避策 として、アプリリストを更新します。

ストレージクラスを設定してアプリケーションを導入すると、アプリケーションのクローンが失敗する

ストレージクラスを明示的に設定してアプリケーションを導入したあと(例: `helm install …​-set global.storageClass=netapp-cvs-perf-extreme`その後、アプリケーションのクローニングを実行するには、ターゲットクラスタに元のストレージクラスが指定されている必要があります。
ストレージクラスを明示的に設定したアプリケーションを、同じストレージクラスを含まないクラスタにクローニングすると、失敗します。このシナリオではリカバリ手順はありません。

kubeconfigファイルに複数のコンテキストが含まれている場合にAstra Control Centerでクラスタの管理が失敗する

複数のクラスタおよびコンテキストで kubeconfig を使用することはできません。を参照してください "技術情報アーティクル" を参照してください。

Istio環境で監視ポッドがクラッシュする可能性があります

Istio環境でAstra Control CenterをCloud Insights とペアリングする場合は telegraf-rs ポッドがクラッシュすることがあります。回避策として、次の手順を実行します。

  1. クラッシュしたポッドを検索します。

    kubectl -n netapp-monitoring get pod | grep Error

    次のような出力が表示されます。

    NAME READY STATUS RESTARTS AGE
    telegraf-rs-fhhrh 1/2 Error 2 (26s ago) 32s
  2. クラッシュしたポッドを再起動し、交換します <pod_name_from_output> 影響を受けるポッドの名前を入力します。

    kubectl -n netapp-monitoring delete pod <pod_name_from_output>

    次のような出力が表示されます。

    pod "telegraf-rs-fhhrh" deleted
  3. PODが再起動し、Error状態でないことを確認します。

    kubectl -n netapp-monitoring get pod

    次のような出力が表示されます。

    NAME READY STATUS RESTARTS AGE
    telegraf-rs-rrnsb 2/2 Running 0 11s

Astra Trident がオフラインの場合、 Internal Service Error ( 500 )によりアプリケーションデータ管理処理が失敗する

アプリケーションクラスタの Astra Trident がオフラインになり(オンラインに戻った)、 500 件の内部サービスエラーが発生した場合に、アプリケーションデータ管理を試みると、アプリケーションクラスタ内のすべての Kubernetes ノードを再起動して機能を復旧します。

詳細については、こちらをご覧ください