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

既知の問題

共同作成者
PDF

既知の問題は、このリリースの製品を正常に使用できない可能性のある問題を特定します。

現在のリリースに影響する既知の問題は次のとおりです。

アプリケーション
クラスタ
その他の問題

アプリケーションをリストアすると、 PV のサイズが元の PV よりも大きくなります

バックアップの作成後に永続ボリュームのサイズを変更し、そのバックアップからリストアすると、永続ボリュームのサイズはバックアップのサイズではなく PV の新しいサイズと一致します。

特定のバージョンの PostgreSQL を使用すると、アプリケーションクローンが失敗します

Bitnami PostgreSQL 11.5.0 チャートを使用すると、同じクラスタ内のアプリケーションクローンは一貫して失敗します。正常にクローニングするには、以前のバージョンのグラフを使用してください。

サービスアカウントレベルの OCP セキュリティコンテキスト制約（ SCC ）を使用すると、アプリケーションのクローンが失敗する

OpenShift Container Platform クラスタのネームスペース内のサービスアカウントレベルで元のセキュリティコンテキストの制約が設定されていると、アプリケーションクローンが失敗する場合があります。アプリケーションクローンが失敗すると、Astra Control Centerの管理対象アプリケーション領域にステータスとともに表示されます Removed。を参照してください "技術情報アーティクル" を参照してください。

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

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

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

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

デフォルトの kubeconfig ファイルに複数のコンテキストが含まれている場合、 Astra Control Center を使用したクラスタの管理が失敗します

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

Astra Control Center 23.04へのアップグレード後に一部のポッドが起動しない

Astra Control Center 23.04にアップグレードすると、一部のポッドが起動しないことがあります。回避策 として、次の手順に従って該当するポッドを手動で再起動します。

  1. 影響を受けるポッドを特定し、<namespace> を現在のネームスペースに置き換えます。

    kubectl get pods -n <namespace> | grep au-pod

    影響を受けるポッドの結果は次のようになります。

    pcloud-astra-control-center-au-pod-0 0/1 CreateContainerConfigError 0 13s

  2. 影響を受ける各ポッドを再起動し、<namespace> を現在のネームスペースに置き換えます。

    kubectl delete pod pcloud-astra-control-center-au-pod-0 -n <namespace>

一部のポッドでは、23.04から23.04.2へのアップグレードのパージステージ後にエラー状態が表示されます

Astra Control Center 23.04.2にアップグレードすると、一部のポッドでエラーが表示されることがある
カンレンノロク task-service-task-purge：

kubectl get all -n netapp-acc -o wide|grep purge

pod/task-service-task-purge-28282828-ab1cd     0/1     Error       0             48m     10.111.0.111   openshift-clstr-ol-07-zwlj8-worker-jhp2b   <none>           <none>

このエラー状態は、クリーンアップステップが正しく実行されなかったことを意味します。23.04.2への全体的なアップグレードが成功しました。次のコマンドを実行してタスクをクリーンアップし、エラー状態を解消します。

kubectl delete job task-service-task-purge-[system-generated task ID] -n <netapp-acc or custom namespace>

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

プロキシ経由で接続している場合、管理対象クラスタはNetApp Cloud Insights に表示されません

アストラコントロールセンターがプロキシ経由でネットアップCloud Insights に接続している場合、管理対象クラスタがCloud Insights に表示されないことがあります。回避策 として、管理対象の各クラスタで次のコマンドを実行します。

kubectl get cm telegraf-conf -o yaml -n netapp-monitoring | sed '/\[\[outputs.http\]\]/c\    [[outputs.http]]\n    use_system_proxy = true' | kubectl replace -f -
kubectl get cm telegraf-conf-rs -o yaml -n netapp-monitoring | sed '/\[\[outputs.http\]\]/c\    [[outputs.http]]\n    use_system_proxy = true' | kubectl replace -f -
kubectl get pods -n netapp-monitoring --no-headers=true | grep 'telegraf-ds\|telegraf-rs' | awk '{print $1}' | xargs kubectl delete -n netapp-monitoring pod

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

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

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