1.2. 既知の問題
Red Hat Advanced Cluster Management for Kubernetes の既知の問題を確認してください。以下の一覧には、本リリースの既知の問題、または以前のリリースから持ち越された既知の問題が記載されています。Red Hat OpenShift Container Platform クラスターについては、OpenShift Container Platform の既知の問題 を参照してください。
1.2.1. ドキュメントの既知の問題
1.2.1.1. カスタマーポータルのドキュメントリンクは、上位レベルのセクションにリンクしている場合がある
場合によっては、カスタマーポータルの Red Hat Advanced Cluster Management ドキュメントの他のセクションへの内部リンクが指定されたセクションに直接リンクしないことがあります。最上位のセクションにリンクされる場合もあります。
これが発生した場合は、指定されたセクションを手動で見つけるか、次の手順を実行して解決できます。
-
解決されていないリンクを正しいセクションにコピーして、ブラウザーのアドレスバーに貼り付けます。たとえば、
https://access.redhat.com/documentation/ja-jp/red_hat_advanced_cluster_management_for_kubernetes/2.5/html/clusters/index#volsync
のようになります。 -
リンクの
html
をhtml-single
に置き換えます。新しい URL はhttps://access.redhat.com/documentation/ja-jp/red_hat_advanced_cluster_management_for_kubernetes/2.5/html-single/clusters/index#volsync
のようになります。 - 新しい URL にリンクして、ドキュメントで指定されたセクションを見つけます。
1.2.2. インストールの既知の問題
1.2.2.1. Red Hat Advanced Cluster Management のアップグレード後に Pod が復旧しないことがある
Red Hat Advanced Cluster Management を新しいバージョンにアップグレードした後、StatefulSet
に属するいくつかの Pod が failed
状態のままになることがあります。このまれなイベントは、Kubernetes の既知の問題 が原因です。
この問題の回避策として、失敗した Pod を削除します。Kubernetes は、正しい設定で自動的に再起動します。
1.2.2.2. OpenShift Container Platform クラスターのアップグレード失敗のステータス
Openshift Container Platform クラスターがアップグレードの段階に入ると、クラスター Pod は再起動され、クラスターのステータスが 1-5 分ほど、upgrade failed
のままになることがあります。この動作は想定されており、数分後に解決されます。
1.2.2.3. アップグレード後、2 つのクラスターキュレーターコントローラーが同時に実行されている
2.4.x から 2.5.0 にアップグレードした後、2 つのクラスターキュレーターコントローラーが同時に実行される場合があります。クラスターライフサイクル Ansible 統合の一部のプリフックおよびポストフックに対して、2 つ以上の AnsibleJob
が作成されました。この問題を解決するには、次の手順を参照してください。
2 つのクラスターキュレーターコントローラーが実行されているかどうかを確認します。multicluster engine Operator からの
multicluster-engine
namespace とopen-cluster-management
namespace を含む次のコマンドを実行します。kubectl -n multicluster-engine get deploy cluster-curator-controller
kubectl -n open-cluster-management get deploy cluster-curator-controller
2 つのクラスターキュレーターコントローラーが実行されている場合は、
open-cluster-management
namespace のcluster-curator-controller
を削除します。以下のコマンドを実行します。kubectl -n open-cluster-management delete deploy cluster-curator-controller
1.2.2.4. MultiClusterEngine の作成ボタンが機能しない
Red Hat OpenShift Container Platform コンソールに Red Hat Advanced Cluster Management for Kubernetes をインストールすると、ポップアップウィンドウに次のメッセージが表示されます。
MultiClusterEngine required
Create a MultiClusterEngine instance to use this Operator.
ポップアップウィンドウメッセージの Create MultiClusterEngine ボタンが機能しない場合があります。この問題を回避するには、提供された API セクションの MultiClusterEngine タイルで インスタンスの作成 を選択します。
1.2.3. Web コンソールの既知の問題
1.2.3.1. Red Hat Advanced Cluster Management バージョン 2.5.x ではダークモードはサポートされていません
Red Hat Advanced Cluster Management バージョン 2.5.2 以降の 2.5.x バージョンは Red Hat OpenShift Container Platform バージョン 4.11 でサポートされていますが、Red Hat Advanced Cluster Management 2.5.x ではダークモードはサポートされていません。設定でダークモードを無効にするか、Red Hat Advanced Cluster Management バージョン 2.6 にアップグレードしてダークモードを有効にします。
1.2.3.2. ダークモードは、Kubernetes Operator バージョン 2.0.x のマルチクラスターエンジンではサポートされていません
Kubernetes Operator バージョン 2.0.2 およびそれ以降の 2.0.x バージョンのマルチクラスターエンジンは Red Hat OpenShift Container Platform バージョン 4.11 でサポートされますが、ダークモードは Kubernetes Operator 2.0.x のマルチクラスターエンジンではサポートされません。設定でダークモードを無効にするか、Kubernetes Operator バージョン 2.1 のマルチクラスターエンジンにアップグレードしてダークモードを有効にします。
1.2.3.3. LDAP ユーザー名の大文字と小文字が区別される
LDAP ユーザー名は、大文字と小文字が区別されます。LDAP ディレクトリーで設定したものと全く同じ名前を使用する必要があります。
1.2.3.4. コンソール機能は Firefox の以前のバージョンで表示されない場合がある
この製品は、Linux、macOS、および Windows で利用可能な Mozilla Firefox 74.0 または最新バージョンをサポートします。コンソールの互換性を最適化するため、最新版にアップグレードしてください。
1.2.3.5. searchcustomization におけるストレージサイズの制限
searchcustomization
CR でストレージサイズを更新する場合、PVC 設定は変更されません。ストレージサイズを更新する必要がある場合は、以下のコマンドで PVC (<storageclassname>-search-redisgraph-0
) を更新します。
oc edit pvc <storageclassname>-search-redisgraph-0
1.2.3.6. 検索クエリーの解析エラー
環境が大規模になり、スケーリングのためにさらに多くのテストが必要になると、検索クエリーがタイムアウトになり、解析エラーメッセージが表示されることがあります。このエラーは、検索クエリーを 30 秒間待機した後に表示されます。
次のコマンドでタイムアウト時間を延長します。
kubectl annotate route multicloud-console haproxy.router.openshift.io/timeout=Xs
1.2.3.7. クラスターセットのネームスペースバインディングを編集できない
admin
ロールを使用してクラスターセットの namespace バインディングを編集すると、次のメッセージのようなエラーが発生する場合があります。
ResourceError: managedclustersetbindings.cluster.open-cluster-management.io "<cluster-set>" is forbidden: User "<user>" cannot create/delete resource "managedclustersetbindings" in API group "cluster.open-cluster-management.io" in the namespace "<namespace>".
この問題を解決するには、バインドする namespace で ManagedClusterSetBinding
リソースを作成または削除する権限も持っていることを確認してください。ロールバインディングでは、クラスターセットを namespace にバインドすることしかできません。
1.2.3.8. クラスターの詳細で誤ったスケーリングアラートが表示される
コンソールでクラスターの詳細を表示すると、ノード タブまたは マシンプール タブに次のメッセージが表示される場合があります。
Worker nodes are currently being removed from this cluster.Click the View machines button to see the status of the scaling operations (it may take a few minutes for the changes to be reflected on this console).
マシンプールが存在しない場合 (ユーザープロビジョニングインフラストラクチャー (UPI) インストールを使用するプロバイダーの場合) は、誤ったアラートを無視してください。コントロールプレーンの一部ではないワーカーノードがある場合に、このアラートが表示されます。マシンプールをスケーリングするのではなく、ワーカーノードが直接クラスターに追加された場合には、インストーラーでプロビジョニングされるインフラストラクチャー (IPI) のインストールを使用してプロビジョニングされたクラスターに対して、誤ったアラートが表示されることもあります。
1.2.4. 可観測性の既知の問題
1.2.4.1. サービスレベルの概要ダッシュボードでローカルクラスターが重複する
さまざまなハブクラスターが同じ S3 ストレージを使用して Red Hat Advanced Cluster Management の可観測性をデプロイする場合、重複する local-clusters
は Kubernetes/Service-Level Overview/API Server ダッシュボード内で検出および表示できます。重複クラスターは、Top Clusters、Number of clusters that has exceeded the SLO、および Number of clusters that are meeting the SLO のパネル内の結果に影響を及ぼします。local-clusters
は、共有 S3 ストレージに関連付けられた一意のクラスターです。複数の local-clusters
がダッシュボード内で表示しないようにするには、一意のハブクラスターごとに、ハブクラスター専用の S3 バケットを使用して可観測性をデプロイすることが推奨されます。
1.2.4.2. 可観測性エンドポイント Operator がイメージのプルに失敗する
可観測性エンドポイント Operator は、MultiClusterObservability CustomResource (CR) へのデプロイにプルシークレットを作成したにもかかわらず、open-cluster-management-observability
namespace にプルシークレットがない場合に問題が発生します。新しいクラスターをインポートする場合、または Red Hat Advanced Cluster Management で作成された Hive クラスターをインポートする場合は、マネージドクラスターにプルイメージシークレットを手動で作成する必要があります。
詳細は、可観測性の有効化 を参照してください。
1.2.4.3. ROKS クラスターおよび HyperShift クラスターからのデータはありません
Red Hat Advanced Cluster Management の可観測性は、組み込みダッシュボードで、ROKS クラスターおよび HyperShift クラスターのデータが表示されないパネルがあります。これは、ROKS および HyperShift が管理するサーバーからの API サーバーメトリックを公開しないためです。以下の Grafana ダッシュボードには、Kubernetes/API server
、Kubernetes/Compute Resources/Workload
、Kubernetes/Compute Resources/Namespace(Workload)
の ROKS クラスターおよび HyperShift クラスターをサポートしないパネルが含まれます。
1.2.4.4. ROKS クラスターおよび HyperShift クラスターからの etcd データはありません
ROKS クラスターおよび HyperShift クラスターの場合、Red Hat Advanced Cluster Management の可観測性は、ダッシュボードの etcd パネルにデータを表示しません。
1.2.4.5. search-collector Pod による CPU の使用率が高くなる
1000 のクラスターを管理するハブクラスターで検索を無効にすると、メモリー不足 (OOM) が原因で search-collector
Pod がクラッシュします。以下の手順を実行します。
-
ハブクラスターで検索が無効にされている場合、
search-redisgraph-pod
はデプロイされないため、search-collector
デプロイメントを0
レプリカにスケールダウンしてメモリーの使用量を削減します。 -
ハブクラスターで検索が有効になっている場合 (
search-redisgraph-pod
がデプロイされていることを意味する) は、search-collector
デプロイメントを編集して割り当てられるメモリーを増やします。
1.2.4.6. 証明書が無効な場合に検索 Pod が TLS ハンドシェイクを完了できない
まれに、検索 Pod は証明書の変更後に自動的に再デプロイされない場合があります。これにより、サービス Pod 全体で証明書が一致しなくなるため、転送レイヤーセキュリティー (TLS) ハンドシェイクが失敗します。この問題を修正するには、検索 Pod を再起動して証明書をリセットします。
1.2.4.7. Grafana コンソールでメトリクスが利用できない
Grafana コンソールでアノテーションのクエリーに失敗する:
Grafana コンソールで特定のアノテーションを検索すると、トークンの有効期限が切れているために、以下のエラーメッセージが表示されることがあります。
"annotation Query Failed"
ブラウザーを更新し、ハブクラスターにログインしていることを確認します。
rbac-query-proxy Pod のエラー:
managedcluster
リソースにアクセス権がないために、プロジェクトでクラスターのクエリーを実行すると以下のエラーが表示される場合があります。no project or cluster found
ロールのパーミッションを確認し、適切に更新します。詳細は、ロールベースのアクセス制御 を参照してください。
1.2.4.8. マネージドクラスターでの Prometheus データ喪失
デフォルトでは、OpenShift の Prometheus は一時ストレージを使用します。Prometheus は、再起動されるたびにすべてのメトリクスデータを失います。
Red Hat Advanced Cluster Management が管理する OpenShift Container Platform マネージドクラスターで可観測性を有効または無効にすると、可観測性エンドポイント Operator は、ローカルの Prometheus を自動的に再起動する alertmanager 設定を追加して cluster-monitoring-config
ConfigMap
を更新します。
1.2.4.9. Out-of-order サンプルの取り込みエラー
Observability receive
Pod では、以下のエラーをレポートします。
Error on ingesting out-of-order samples
このエラーメッセージは、マネージドクラスターがメトリック収集間隔中に送信した時系列データが、以前の収集間隔中に送信した時系列データよりも古いことを意味します。この問題が発生した場合には、データは Thanos レシーバーによって破棄され、Grafana ダッシュボードに表示されるデータにギャップが生じる場合があります。エラーが頻繁に発生する場合は、メトリクスコレクションの間隔をより大きい値に増やすことが推奨されます。たとえば、間隔を 60 秒に増やすことができます。
この問題は、時系列の間隔が 30 秒などの低い値に設定されている場合にのみ見られます。メトリクス収集の間隔がデフォルト値の 300 秒に設定されている場合には、この問題は発生しません。
1.2.4.10. マネージドクラスターで Grafana のデプロイが失敗する
マニフェストのサイズが 50,000 バイトを超えると、Grafana インスタンスはマネージドクラスターにデプロイされません。可観測性をデプロイした後、local-cluster
のみが Grafana に表示されます。
1.2.5. クラスター管理の既知の問題
クラスター管理に関する次の既知の問題と制限を参照してください。
1.2.5.1. クラスター作成用の切断されたインストール設定は入力できないか、入力しても無視される
ベアメタルプロバイダーと切断されたインストールを使用してクラスターを作成する場合、切断されたインストールの設定 セクションの資格情報にすべての設定を保存する必要があります。クラスター作成コンソールエディターでそれらを入力することはできません。
VMware vSphere または Red Hat OpenStack Platform プロバイダーを使用してクラスターを作成し、切断されたインストールを行う場合、ミラーレジストリーにアクセスするために証明書が必要な場合は、切断されたインストールの設定セクションの資格情報の追加の信頼バンドルフィールドに証明書を入力する必要があります。.その証明書をクラスター作成コンソールエディターに入力すると、無視されます。
1.2.5.2. 切断されたインストーラーの資格情報は、証明書を区別しない
ベアメタル、VMware vSphere、または Red Hat OpenStack Platform プロバイダーの資格情報を作成する場合、インストーラーは証明書を区別しないため、切断されたインストールのプロキシーと設定の追加の信頼バンドルフィールドには同じ値が含まれていることに注意してください。これらの機能を個別に使用することもできます。また、プロキシーインストールと非接続インストールで異なる証明書が必要な場合は、フィールドに複数の証明書を入力できます。
1.2.5.3. アドオンの削除時にマネージドクラスターで必要な VolSync CSV の手動削除
ハブクラスターから VolSync ManagedClusterAddOn
を削除すると、マネージドクラスターの VolSync Operator サブスクリプションが削除されますが、クラスターサービスバージョン (CSV) は削除されません。マネージドクラスターから CSV を削除するには、VolSync を削除する各マネージドクラスターで以下のコマンドを実行します。
oc delete csv -n openshift-operators volsync-product.v0.4.0
別のバージョンの VolSync がインストールされている場合は、v0.4.0
をインストール済みバージョンに置き換えます。
1.2.5.4. sushy-tools の使用時にベアメタルマネージドクラスターのプロビジョニングに失敗する
sushy-tools を使用してベアメタルにマネージドクラスターをプロビジョニングすると、virtual media cd query return
500 エラーでプロビジョニングに失敗する場合があります。sushy-tools の使用は、長時間稼働するクラスターでの信頼性を保証するものではありません。
sushy-tools が最新バージョンであることを確認して、sushy エミュレーターを再起動して問題を回避します。
1.2.5.5. デュアルスタックハブを使用する場合に OpenShift Container Platform 4.10 でのベアメタルクラスターのプロビジョニングに失敗する
OpenShift Container Platform バージョン 4.10 を実行しているデュアルスタックハブでベアメタルクラスターをプロビジョニングすると、プロビジョニングが失敗し、ノードの検査中に 'timeout reached during the node' というエラーメッセージが表示されます。この問題を回避するには、以下の例にあるように、install-config.yaml
ファイルでプロビジョニングネットワークを無効にします。
platform: baremetal: provisioningNetwork: "Disabled"
プロビジョニングネットワークの詳細は、OpenShift Container Platform ドキュメントの プロビジョニングネットワークなしでのデプロイ を参照してください。
1.2.5.6. マネージドクラスターセットを削除してもそのラベルが自動的に削除されない
ManagedClusterSet
を削除した後に、クラスターセットに関連付ける各マネージドクラスターに追加されるラベルは自動的に削除されません。削除したマネージドクラスターセットに含まれる各マネージドクラスターからラベルを手動で削除します。ラベルは cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name>
のようになります。
1.2.5.7. ClusterClaim エラー
ClusterPool
に対して Hive ClusterClaim
を作成し、ClusterClaimspec
の有効期限のフィールドを無効な golang タイム値に手動で設定すると、Red Hat Advanced Cluster Management は不正な要求だけでなく、すべての ClusterClaims
の実行および調整を停止します。
このエラーが発生すると、clusterclaim-controller
Pod ログに以下の内容が表示されます。これは、プール名と、無効な有効期限が含まれた特定の例です。
E0203 07:10:38.266841 1 reflector.go:138] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to watch *v1.ClusterClaim: failed to list *v1.ClusterClaim: v1.ClusterClaimList.Items: []v1.ClusterClaim: v1.ClusterClaim.v1.ClusterClaim.Spec: v1.ClusterClaimSpec.Lifetime: unmarshalerDecoder: time: unknown unit "w" in duration "1w", error found in #10 byte of ...|time":"1w"}},{"apiVe|..., bigger context ...|clusterPoolName":"policy-aas-hubs","lifetime":"1w"}},{"apiVersion":"hive.openshift.io/v1","kind":"Cl|...
無効な要求を削除できます。
不正な要求が削除されると、要求は追加の対話なしに正常に調整を開始します。
1.2.5.8. 製品チャネルが、プロビジョニングされたクラスターと同期されない
clusterimageset
は fast
チャネルに置かれますが、プロビジョニングされたクラスターは stable
チャネルにあります。現時点で、製品は channel
をプロビジョニングされた OpenShift Container Platform クラスターと同期しません。
OpenShift Container Platform コンソールで適切なチャネルに切り替えます。Administration > Cluster Settings > Details Channel の順にクリックします。
1.2.5.9. カスタム CA 証明書を使用した管理対象クラスターの、復元されたハブクラスターへの接続の復元は失敗する可能性がある
カスタム CA 証明書を使用してクラスターを管理したハブクラスターのバックアップを復元した後、管理対象クラスターとハブクラスター間の接続が失敗する場合があります。これは、復元されたハブクラスターで CA 証明書がバックアップされなかったためです。接続を復元するには、管理対象クラスターの namespace にあるカスタム CA 証明書情報を、復元されたハブクラスターの <managed_cluster>-admin-kubeconfig
シークレットにコピーします。
ヒント: バックアップコピーを作成する前にこの CA 証明書をハブクラスターにコピーする場合は、バックアップコピーにシークレット情報が含まれます。将来、バックアップコピーを使用して復元する場合、ハブと管理対象クラスター間の接続は自動的に完了します。
1.2.5.10. ローカルクラスターが自動的に再作成されない場合がある
disableHubSelfManagement
が false
に設定されている場合、local-cluster は MulticlusterHub
Operator によって再作成されます。ローカルクラスターをデタッチした後、ローカルクラスターが自動的に再作成されない場合があります。
この問題を解決するには、
MulticlusterHub
によって監視されるリソースを変更します。以下の例を参照してください。oc delete deployment multiclusterhub-repo -n <namespace>
-
local-cluster を適切にデタッチするには、
MultiClusterHub
でdisableHubSelfManagement
を true に設定します。
1.2.5.11. オンプレミスクラスターを作成する場合は、サブネットを選択する必要がある
Red Hat Advanced Cluster Management コンソールを使用してオンプレミスクラスターを作成する場合は、クラスターで使用可能なサブネットを選択する必要があります。必須フィールドとしてマークされていません。
1.2.5.12. Google Cloud Platform でのクラスタープロビジョニングに失敗する
Google Cloud Platform(GCP) でのクラスターのプロビジョニングを試みると、以下のエラーが発生して失敗する可能性があります。
Cluster initialization failed because one or more operators are not functioning properly. The cluster should be accessible for troubleshooting as detailed in the documentation linked below, https://docs.openshift.com/container-platform/latest/support/troubleshooting/troubleshooting-installations.html The 'wait-for install-complete' subcommand can then be used to continue the installation
GCP プロジェクトで ネットワークセキュリティー API を有効にして、このエラーを回避することができます。これにより、クラスターのインストールを継続できます。
1.2.5.13. Infrastructure Operator を使用したクラスターのプロビジョニングに失敗する
Infrastructure Operator を使用して OpenShift Container Platform クラスターを作成する場合、ISO イメージのファイル名は長すぎる可能性があります。長いイメージ名により、イメージのプロビジョニングとクラスターのプロビジョニングが失敗します。この問題が生じるかどうかを確認するには、以下の手順を実行します。
以下のコマンドを実行して、プロビジョニングするクラスターのベアメタルホスト情報を表示します。
oc get bmh -n <cluster_provisioning_namespace>
describe
コマンドを実行して、エラー情報を表示します。oc describe bmh -n <cluster_provisioning_namespace> <bmh_name>
以下の例と同様のエラーは、ファイル名の長さが問題であることを示します。
Status: Error Count: 1 Error Message: Image provisioning failed: ... [Errno 36] File name too long ...
この問題が発生する場合、これは通常 OpenShift Container Platform の以下のバージョンで発生します。インフラストラクチャー Operator がイメージサービスを使用していないためです。
- 4.8.17 以前
- 4.9.6 以前
このエラーを回避するには、OpenShift Container Platform をバージョン 4.8.18 以降、または 4.9.7 以降にアップグレードしてください。
1.2.5.14. Azure Government クラスターを休止状態にできない
Azure Government クラスターを休止状態にしようとすると、以下のエラーがプロビジョニング Pod ログに追加されてハイバネートに失敗します。
Confidential Client is not supported in Cross Cloud request
1.2.5.15. 別の名前で再インポートした後に local-cluster のステータスがオフラインになる
local-cluster
という名前のクラスターを、誤って別の名前のクラスターとして再インポートしようとすると、local-cluster
と再インポートしたクラスターのステータスが offline
と表示されます。
このケースから回復するには、以下の手順を行います。
ハブクラスターで以下のコマンドを実行して、ハブクラスターの自己管理の設定を一時的に編集します。
oc edit mch -n open-cluster-management multiclusterhub
-
spec.disableSelfManagement=true
の設定を追加します。 ハブクラスターで以下のコマンドを実行し、local-cluster を削除し、再デプロイします。
oc delete managedcluster local-cluster
以下のコマンドを実行して
local-cluster
管理設定を削除します。oc edit mch -n open-cluster-management multiclusterhub
-
前の手順で追加した
spec.disableSelfManagement=true
を削除します。
1.2.5.16. Ansible 自動化を使用したクラスタープロビジョニングがプロキシー環境で失敗する
マネージドクラスターを自動的にプロビジョニングするように設定された AnsibleJob テンプレートは、以下の条件の両方が満たされると失敗する可能性があります。
- ハブクラスターで、クラスター全体のプロキシーが有効になっている。
- Ansible Tower には、プロキシーを介してのみアクセスできる。
1.2.5.17. klusterlet Operator のバージョンは、ハブクラスターと同じである必要がある
klusterlet Operator をインストールしてマネージドクラスターをインポートする場合には、klusterlet Operator のバージョンは、ハブクラスターのバージョンと同じでなければなりません。そうでないと、klusterlet Operator は動作しません。
1.2.5.18. マネージドクラスター namespace を手動で削除できない
マネージドクラスターの namespace を手動で削除できません。マネージドクラスター namespace は、マネージドクラスターの割り当てを解除した後に自動的に削除されます。マネージドクラスターの割り当てを解除する前に手動でマネージドクラスター namespace を削除する場合は、マネージドクラスターの削除後にマネージドクラスターに継続的な終了ステータスが表示されます。この終了マネージドクラスターを削除するには、割り当てを解除したマネージドクラスターからファイナライザーを手動で削除します。
1.2.5.19. バージョン 2.3 にアップグレードした後にクラスターの認証情報を変更できない
Red Hat Advanced Cluster Management をバージョン 2.3 にアップグレードすると、アップグレード前に Red Hat Advanced Cluster Management で作成して管理されていたマネージドクラスターの認証情報シークレットが変更できなくなります。
1.2.5.20. ハブクラスターとマネージドクラスターのクロックが同期されない
ハブクラスターおよびマネージドクラスターの時間が同期されず、コンソールで unknown
と表示され、最数的に、数分以内に available
と表示されます。Red Hat OpenShift Container Platform ハブクラスターの時間が正しく設定されていることを確認します。ノードのカスタマイズ を参照してください。
1.2.5.21. IBM OpenShift Container Platform Kubernetes Service クラスターの特定のバージョンのインポートはサポートされていない
IBM OpenShift Container Platform Kubernetes Service バージョン 3.11 のクラスターをインポートすることはできません。IBM OpenShift Kubernetes Service の 3.11 よりも後のバージョンはサポート対象です。
1.2.5.22. OpenShift Container Platform 3.11 の割り当てを解除しても open-cluster-management-agent が削除されない
OpenShift Container Platform 3.11 でマネージドクラスターをデタッチしても、open-cluster-management-agent
namespace は自動的に削除されません。以下のコマンドを実行して namespace を手動で削除します。
oc delete ns open-cluster-management-agent
1.2.5.23. プロビジョニングされたクラスターのシークレットの自動更新はサポートされていない
クラウドプロバイダーのアクセスキーを変更しても、プロビジョニングされたクラスターのアクセスキーは、namespace で更新されません。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。このような場合は、以下のコマンドを実行して、クラウドプロバイダーでアクセスキーを更新します。
Amazon Web Services (AWS)
oc patch secret {CLUSTER-NAME}-aws-creds -n {CLUSTER-NAME} --type json -p='[{"op": "add", "path": "/stringData", "value":{"aws_access_key_id": "{YOUR-NEW-ACCESS-KEY-ID}","aws_secret_access_key":"{YOUR-NEW-aws_secret_access_key}"} }]'
Google Cloud Platform (GCP)
この問題は、クラスターを破棄する際に
Invalid JWT Signature
と繰り返し表示されるログのエラーメッセージで特定することができます。ログにこのメッセージが含まれる場合は、新しい Google Cloud Provider サービスアカウント JSON キーを取得し、以下のコマンドを入力します。oc set data secret/<CLUSTER-NAME>-gcp-creds -n <CLUSTER-NAME> --from-file=osServiceAccount.json=$HOME/.gcp/osServiceAccount.json
CLUSTER-NAME
は、使用しているクラスター名に置き換えます。$HOME/.gcp/osServiceAccount.json
ファイルへのパスを、新しい Google Cloud Provider サービスアカウント JSON キーが含まれるファイルへのパスに置き換えます。Microsoft Azure
oc set data secret/{CLUSTER-NAME}-azure-creds -n {CLUSTER-NAME} --from-file=osServiceAccount.json=$HOME/.azure/osServiceAccount.json
VMware vSphere
oc patch secret {CLUSTER-NAME}-vsphere-creds -n {CLUSTER-NAME} --type json -p='[{"op": "add", "path": "/stringData", "value":{"username": "{YOUR-NEW-VMware-username}","password":"{YOUR-NEW-VMware-password}"} }]'
1.2.5.24. マネージドクラスターからのノード情報を検索で表示できない
検索で、ハブクラスターのリソース用の RBAC がマッピングされます。Red Hat Advanced Cluster Management のユーザー RBAC 設定によっては、マネージドクラスターからのノードデータが表示されない場合があります。また検索の結果は、クラスターの Nodes ページに表示される内容と異なる場合があります。
1.2.5.25. クラスターを破棄するプロセスが完了しない
マネージドクラスターを破棄してから 1 時間経過してもステータスが Destroying
のままで、クラスターが破棄されません。この問題を解決するには、以下の手順を実行します。
- クラウドに孤立したリソースがなく、マネージドクラスターに関連付けられたプロバイダーリソースがすべて消去されていることを確認します。
以下のコマンドを入力して、削除するマネージドクラスターの
ClusterDeployment
情報を開きます。oc edit clusterdeployment/<mycluster> -n <namespace>
mycluster
は、破棄するマネージドクラスターの名前に置き換えます。namespace
は、マネージドクラスターの namespace に置き換えます。-
hive.openshift.io/deprovision
ファイナライザーを削除し、クラウドのクラスターリソースを消去しようとするプロセスを強制的に停止します。 -
変更を保存して、
ClusterDeployment
が削除されていることを確認します。 以下のコマンドを実行してマネージドクラスターの namespace を手動で削除します。
oc delete ns <namespace>
namespace
は、マネージドクラスターの namespace に置き換えます。
1.2.5.26. OpenShift Container Platform Dedicated でコンソールを使用して OpenShift Container Platform マネージドクラスターをアップグレードできない
Red Hat Advanced Cluster Management コンソールを使用して、OpenShift Container Platform Dedicated 環境にある OpenShift Container Platform マネージドクラスターをアップグレードすることはできません。
1.2.5.27. ワークマネージャーのアドオン検索の詳細
特定のマネージドクラスターにある特定のリソースの検索詳細ページで問題が発生する可能性があります。マネージドクラスターの work-manager アドオンが Available
ステータスであることを確認してから検索する必要があります。
1.2.5.28. IBM Power または IBM Z システムハブクラスターとの Ansible Tower 統合は使用できない
Ansible Automation Platform Resource Operator では ppc64le
イメージまたは s390x
イメージが提供されないので、IBM Power または IBM Z システムで Red Hat Advanced Cluster Management for Kubernetes ハブクラスターが実行されている場合には、Ansible Tower 統合を使用できません。
1.2.5.29. Red Hat OpenShift Container Platform 以外のマネージドクラスターでは、LoadBalancer が有効にされている必要がある
Red Hat OpenShift Container Platform および OpenShift Container Platform 以外のクラスターの両方は Pod ログ機能をサポートしますが、OpenShift Container Platform 以外のクラスターでは、この機能を使用できるように LoadBalancer
が有効にされている必要があります。LoadBalancer
を有効にするには、以下の手順を実行します。
-
クラウドプロバイダーごとに
LoadBalancer
設定が異なります。詳細は、クラウドプロバイダーのドキュメントを参照してください。 -
managedClusterInfo
のステータスでloggingEndpoint
をチェックして、LoadBalancer
が Red Hat Advanced Cluster Management で有効にされているかどうかを確認します。 以下のコマンドを実行して、
loggingEndpoint.IP
またはloggingEndpoint.Host
に有効な IP アドレスまたはホスト名が設定されていることを確認します。oc get managedclusterinfo <clusterName> -n <clusterNamespace> -o json | jq -r '.status.loggingEndpoint'
LoadBalancer
のタイプについての詳細は、Kubernetes のドキュメント のService ページを参照してください。
1.2.5.30. アップグレード後に Cluster-proxy-addon が起動しない
バージョン 2.4.x から 2.5.0 にアップグレードした後、cluster-proxy-addon
が起動せず、cluster-proxy-addon-manager
が nil ポインター例外を発生させます。
この問題を回避するには、以下の手順を実行します。
-
cluster-proxy-addon
を無効にします。詳細は、高度な設定 を参照してください。 -
open-cluster-management
namespace からcluster-proxy-signer
シークレットを削除します。 -
cluster-proxy-addon
を有効にします。
1.2.6. アプリケーション管理の既知の問題
アプリケーションライフサイクルコンポーネントについては、次の既知の問題を参照してください。
1.2.6.1. アプリケーション ObjectBucket チャネルタイプは、許可リストと拒否リストを使用できない
subscription-admin
ロールの ObjectBucket チャネルタイプで許可リストと拒否リストを指定することはできません。他の種類のチャネルでは、サブスクリプションの許可リストと拒否リストによって、デプロイできる Kubernetes リソースとデプロイできない Kubernetes リソースが示されます。
1.2.6.2. Argo アプリケーションを 3.x OpenShift Container Platform 管理対象クラスターにデプロイできない
Infrastructure.config.openshift.io
API は 3.x では使用できないため、コンソールから Argo ApplicationSet
を 3.x OpenShift Container Platform 管理対象クラスターにデプロイすることはできません。
1.2.6.3. multicluster_operators_subscription イメージへの変更は自動的に有効にならない
マネージドクラスターで実行している application-manager
アドオンは、以前は klusterlet Operator により処理されていましたが、サブスクリプション Operator により処理されるようになりました。サブスクリプション Operator は multicluster-hub
で管理されていないため、multicluster-hub
イメージマニフェスト ConfigMap の multicluster_operators_subscription
イメージへの変更は自動的に有効になりません。
サブスクリプション Operator が使用するイメージが、multicluster-hub
イメージマニフェスト ConfigMap の multicluster_operators_subscription
イメージを変更することによってオーバーライドされた場合、マネージドクラスターの application-manager
アドオンは、サブスクリプション Operator Pod が再起動するまで新しいイメージを使用しません。。Pod を再起動する必要があります。
1.2.6.4. アプリケーショントポロジーで誤ったアプリケーションが表示される
同じ名前の ApplicationSet
が異なる Gitops インスタンスに作成されると、アプリケーショントポロジーは誤ったアプリケーションを表示します。複数の Gitops インスタンスがインストールされている場合に、各 Gitops インスタンスに同じ名前の ApplicationSets
が設定され、ApplicationSets
のトポロジーが正しく表示されません。これは、作成される ApplicationSets
の namespace をトポロジーで区別していないことが原因です。
各 Gitops インスタンスに異なる名前で ApplicationSet
を作成し、トポロジーを正しく表示できるようにします。
1.2.6.5. サブスクリプション管理者以外はポリシーリソースをデプロイできない
Red Hat Advanced Cluster Management バージョン 2.4 では、デフォルトで policy.open-cluster-management.io/v1
リソースがアプリケーションサブスクリプションによってデプロイされなくなりました。
サブスクリプション管理者は、このデフォルトの動作を変更するためにアプリケーションサブスクリプションをデプロイする必要があります。
詳細は、サブスクリプション管理者としての許可リストおよび拒否リストの作成 を参照してください。以前の Red Hat Advanced Cluster Management バージョンの既存のアプリケーションサブスクリプションによってデプロイされた policy.open-cluster-management.io/v1
リソースは、サブスクリプション管理者がアプリケーションサブスクリプションをデプロイしていない限り、ソースリポジトリーに合わせて調整されません。
1.2.6.6. アプリケーション Ansible フックのスタンドアロンモード
Ansible フックのスタンドアロンモードはサポートされていません。サブスクリプションを使用してハブクラスターに Ansible フックをデプロイするには、次のサブスクリプション YAML を使用できます。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: sub-rhacm-gitops-demo namespace: hello-openshift annotations: apps.open-cluster-management.io/github-path: myapp apps.open-cluster-management.io/github-branch: master spec: hooksecretref: name: toweraccess channel: rhacm-gitops-demo/ch-rhacm-gitops-demo placement: local: true
ただし、spec.placement.local:true
ではサブスクリプションが standalone
モードで実行されているため、この設定では Ansible インストールが作成されない可能性があります。ハブモードでサブスクリプションを作成する必要があります。
local-cluster
にデプロイする配置ルールを作成します。以下のサンプルを参照してください。apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: <towhichcluster> namespace: hello-openshift spec: clusterSelector: matchLabels: local-cluster: "true" #this points to your hub cluster
使用しているサブスクリプションで、作成した配置ルールを参照します。以下を参照してください。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: sub-rhacm-gitops-demo namespace: hello-openshift annotations: apps.open-cluster-management.io/github-path: myapp apps.open-cluster-management.io/github-branch: master spec: hooksecretref: name: toweraccess channel: rhacm-gitops-demo/ch-rhacm-gitops-demo placement: placementRef: name: <towhichcluster> kind: PlacementRule
両方を適用すると、ハブクラスターに作成された Ansible インスタンスが表示されます。
1.2.6.7. Editor ロールのアプリケーションエラー
Editor
ロールで実行するユーザーは、アプリケーションで read
または update
の権限のみが割り当てられているはずにもかかわらず、誤ってアプリケーションの create
および delete
の操作ができてしまいます。OpenShift Container Platform Operator Lifecycle Manager のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。
-
oc edit clusterrole applications.app.k8s.io-v1beta2-edit -o yaml
を実行して、アプリケーションのクラスターロールの編集を開きます。 -
verbs リストから
create
およびdelete
を削除します。 - 変更を保存します。
1.2.6.8. 配置ルールの編集ロールエラー
Editor
ロールで実行するユーザーは、配置ルールで read
または update
の権限のみが割り当てられているはずにもかかわらず、誤って create
および delete
の操作もできてしまいます。OpenShift Container Platform Operator Lifecycle Manager のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。
-
oc edit clusterrole placementrules.apps.open-cluster-management.io-v1-edit
を実行して、アプリケーションの編集クラスターロールを開きます。 -
verbs リストから
create
およびdelete
を削除します。 - 変更を保存します。
1.2.6.9. 配置ルールの更新後にアプリケーションがデプロイされない
配置ルールの更新後にアプリケーションがデプロイされない場合には、klusterlet-addon-appmgr
Pod が実行されていることを確認します。サブスクリプションコンテナーである klusterlet-addon-appmgr
は、エンドポイントクラスターで実行する必要があります。
oc get pods -n open-cluster-management-agent-addon
を実行して確認します。
また、コンソールで kind:pod cluster:yourcluster
を検索し、klusterlet-addon-appmgr
が実行中であることを確認できます。
検証できない場合は、もう一度、クラスターのインポートを試行して検証を行います。
1.2.6.10. サブスクリプション Operator が SCC を作成しない
Red Hat OpenShift Container Platform SCC の詳細は、Security Context Constraints (SCC) の管理 を参照してください。これは、マネージドクラスターで必要な追加設定です。
デプロイメントごとにセキュリティーコンテキストとサービスアカウントが異なります。サブスクリプション Operator は SCC を自動的に作成できず、管理者が Pod のパーミッションを制御します。Security Context Constraints (SCC) CR は、関連のあるサービスアカウントに適切なパーミッションを有効化して、デフォルトではない namespace で Pod を作成する必要があります。
使用している namespace で SCC CR を手動で作成するには、以下を実行します。
デプロイメントで定義したサービスアカウントを検索します。たとえば、以下の
nginx
デプロイメントを参照してください。nginx-ingress-52edb nginx-ingress-52edb-backend
使用している namespace に SCC CR を作成して、サービスアカウントに必要なパーミッションを割り当てます。以下の例を参照してください。
kind: SecurityContextConstraints
が追加されています。apiVersion: security.openshift.io/v1 defaultAddCapabilities: kind: SecurityContextConstraints metadata: name: ingress-nginx namespace: ns-sub-1 priority: null readOnlyRootFilesystem: false requiredDropCapabilities: fsGroup: type: RunAsAny runAsUser: type: RunAsAny seLinuxContext: type: RunAsAny users: - system:serviceaccount:my-operator:nginx-ingress-52edb - system:serviceaccount:my-operator:nginx-ingress-52edb-backend
1.2.6.11. アプリケーションチャネルには一意の namespace が必要
同じ namespace に複数のチャネルを作成すると、ハブクラスターでエラーが発生する可能性があります。
たとえば、namespace charts-v1
は、Helm タイプのチャネルとしてインストーラーで使用するので、charts-v1
に追加のチャネルを作成します。一意の namespace でチャネルを作成するようにしてください。すべてのチャネルには個別の namespace が必要ですが、GitHub チャネルは例外で、別 GitHub のチャネルと namespace を共有できます。
1.2.6.12. Ansible Automation Platform ジョブが失敗する
互換性のないオプションを選択すると、Ansible ジョブの実行に失敗します。Ansible Automation Platform は、-cluster-scoped
のチャネルオプションが選択されている場合にのみ機能します。これは、Ansible ジョブを実行する必要があるすべてのコンポーネントに影響します。
1.2.6.13. Ansible Automation Platform Operator によるプロキシー外の Ansible Tower へのアクセス
Ansible Automation Platform(AAP)Operator は、プロキシー対応の OpenShift Container Platform クラスター外の Ansible Tower にアクセスできません。解決するには、Ansible tower をプロキシー内にインストールします。Ansible Tower が提供するインストール手順を参照してください。
1.2.6.14. バージョン 2.4 で Helm Argo アプリケーションを編集する場合、テンプレート情報は表示されません
Helm Argo アプリケーションを作成して編集すると、YAML ファイルが正しい間、テンプレート情報は空で表示されます。エラーを修正するには、エラータ 2.4.1 にアップグレードしてください。
1.2.6.15. アプリケーション名の要件
アプリケーション名は 37 文字を超えることができません。この数を超えた場合、アプリケーションのデプロイメント時に以下のエラーが表示されます。
status: phase: PropagationFailed reason: 'Deployable.apps.open-cluster-management.io "_long_lengthy_name_" is invalid: metadata.labels: Invalid value: "_long_lengthy_name_": must be no more than 63 characters/n'
1.2.6.16. アプリケーションコンソールテーブルの制限事項
コンソールのさまざまな アプリケーション の表に対する以下の制限を確認してください。
- Overview ページの Applications の表と、 Advanced configuration ページの Subscriptions の表にある Clusters の列では、アプリケーションリソースのデプロイ先のクラスター数が表示されます。アプリケーションは、ローカルクラスターのリソースで定義されているため、実際のアプリケーションリソースがローカルクラスターにデプロイされているかどうかにかかわらず、ローカルのクラスターは検索結果に含まれます。
- Subscriptions の Advanced configuration 表にある Applications の列には、サブスクリプションを使用するアプリケーションの合計数が表示されますが、サブスクリプションが子アプリケーションをデプロイする場合には、これらも検索結果に含まれます。
- Channels の Advanced configuration 表にある Subscriptions の列には、対象のチャネルを使用するローカルクラスター上のサブスクリプション合計数が表示されます。ただし、他のサブスクリプションがデプロイするサブスクリプションは検索結果には含まれますが、ここには含まれません。
1.2.6.17. アプリケーションコンソールトポロジーのフィルターリング機能がない
2.5 では Application の Console と Topology が変更されています。コンソールの Topology ページにフィルターリング機能はありません。
1.2.6.18. ApplicationSet リソースがトポロジーにステータスを表示しない
ApplicationSet
YAML で定義された namespace とは異なる namespace にリソースをデプロイする ApplicationSet
アプリケーションを作成すると、リソースのステータスがトポロジーに表示されません。
1.2.6.19. 許可リストと拒否リストがオブジェクトストレージアプリケーションで機能しない
allow
リストおよび deny
リストの機能は、オブジェクトストレージアプリケーションのサブスクリプションでは機能しません。
1.2.6.20. ApplicationSet ウィザードがパスを自動的にフェッチしない
以前に作成した ApplicationSet
と同じ URL とブランチで新しい ApplicationSet
を作成すると、ApplicationSet ウィザードはパスを自動的にフェッチしません。
この問題を回避するには、Path フィールドにパスを手動で入力します。
1.2.7. ガバナンスの既知の問題
1.2.7.1. Red Hat Advanced Cluster Management からログアウトできない
外部アイデンティティープロバイダーを使用して Red Hat Advanced Cluster Management にログインする場合は、Red Hat Advanced Cluster Management からログアウトできない可能性があります。これは、Red Hat Advanced Cluster Management に IBM Cloud および Keycloak をアイデンティティープロバイダーとしてインストールして使用する場合に発生します。
Red Hat Advanced Cluster Management からログアウトするには、外部アイデンティティープロバイダーからログアウトしておく必要があります。
1.2.7.2. Gatekeeper Operator のインストールに失敗する
Red Hat OpenShift Container Platform バージョン 4.9 に gatekeeper Operator をインストールする場合、インストールに失敗します。OpenShift Container Platform をバージョン 4.9.0. にアップグレードする前に、gatekeeper Operator をバージョン 0.2.0 にアップグレードする必要があります。詳細は、gatekeeper および gatekeeper Operator のアップグレード を参照してください。
1.2.7.3. namespace が Terminating 状態で停止している場合に、設定ポリシーが準拠と表示される
設定ポリシーで complianceType
のパラメーターに mustnothave
、remediationAction
のパラメーターに enforce
が設定されている場合に、ポリシーは Kubernetes API に削除要求が送信されてから、準拠と表示されます。そのため、ポリシーが準拠と表示されているにも関わらず、Kubernetes オブジェクトは、Terminating
の状態のままになってしまう可能性があります。
1.2.7.4. ポリシーでデプロイされた Operator が ARM をサポートしない
ARM 環境へのインストールはサポートされますが、ポリシーを使用してデプロイされる Operator は ARM 環境をサポートしない可能性があります。Operator をインストールする以下のポリシーは ARM 環境をサポートしません。
1.2.7.5. ポリシーテンプレートの問題
設定ポリシーのポリシーテンプレートを編集すると、次の問題が発生する場合があります。
- 設定ポリシーの名前を新しい名前に変更すると、古い名前の設定ポリシーのコピーが残ります。
- ハブクラスターのポリシーから設定ポリシーを削除すると、設定ポリシーはマネージドクラスターに残りますが、その状態は提供されません。これを解決するには、ポリシーを無効にしてから再度有効にします。ポリシー全体を削除することもできます。
1.2.8. バックアップおよび復元の既知の問題
1.2.8.1. バックアップおよび復元機能が IBM Power および IBM Z で動作しない
ハブクラスターのバックアップおよび復元機能には、Data Protection (OADP) Operator の OpenShift API が必要です。OADP Operator は、IBM Power または IBM Z アーキテクチャーでは使用できません。
1.2.8.2. バックアップの競合の回避
ハブクラスターは passive から primary クラスターに戻されると、異なるクラスターが同じストレージの場所にあるデータをバックアップできます。これにより、バックアップの競合が発生します。つまり、最新のバックアップが passive ハブクラスターによって生成されたことを意味します。
BackupSchedule.cluster.open-cluster-management.io
リソースがハブクラスターで有効になっているため、passive ハブクラスターはバックアップを生成しますが、このハブクラスターは primary ハブクラスターでなくなったため、バックアップデータは書き込みできるべきではありません。以下のコマンドを実行して、バックアップの競合があるかどうかを確認します。
oc get backupschedule -A
以下のステータスが返される場合があります。
NAMESPACE NAME PHASE MESSAGE openshift-adp schedule-hub-1 BackupCollision Backup acm-resources-schedule-20220301234625, from cluster with id [be97a9eb-60b8-4511-805c-298e7c0898b3] is using the same storage location. This is a backup collision with current cluster [1f30bfe5-0588-441c-889e-eaf0ae55f941] backup. Review and resolve the collision then create a new BackupSchedule resource to resume backups from this cluster.
BackupSchedule.cluster.open-cluster-management.io
リソースの status
を BackupCollision
に設定して、バックアップの競合を回避します。BackupSchedule
リソースによって作成される Schedule.velero.io
リソースは自動的に削除されます。
バックアップの競合は、hub-backup-pod
ポリシーにより報告されます。管理者は、どのハブクラスターが対象のストレージの場所にデータを書き込んでいるかを確認する必要があります。次に、passive ハブクラスターから BackupSchedule.cluster.open-cluster-management.io
リソースを削除し、primary ハブクラスターに新しい BackupSchedule.cluster.open-cluster-management.io
リソースを再作成して、バックアップを再開します。
詳細は、クラスターのバックアップおよび復元オペレーター を参照してください。
1.2.8.3. Velero 復元の制限
以下の復元の制限を確認してください。
- 初期ハブクラスターにバックアップデータを復元する前に、新しいハブクラスターに既存のポリシーが存在する場合、データの復元先の初期ハブクラスターと新規ハブクラスターは同じにはなりません。このポリシーは、バックアップリソースで利用できないポリシーであるため、新しいハブクラスターで実行しないでください。
- Velero は既存のリソースを省略するため、新しいハブクラスターのポリシーは変更されません。したがって、ポリシーは、最初のハブクラスターでバックアップしたポリシーと同じではありません。
- ユーザーが新しいハブクラスターのバックアップを再適用する場合には、新しいハブクラスターには、アクティブなハブクラスターとは異なる設定があります。ハブクラスターに以前の復元からの既存のポリシーがあるため、復元されません。バックアップに想定された更新が含まれている場合でも、ポリシーのコンテンツは、新しいハブクラスターの Velero によって更新されません。
前述の制限に対応するために、restore.cluster.open-cluster-management.io
リソースが作成されると、クラスターのバックアップおよび復元 Operator は、Velero 復元の開始前にハブクラスターを削除して復元の準備を行う一連の手順を実行します。詳細は、復元前にハブクラスターのクリーニング を参照してください。
1.2.8.4. インポートされたマネージドクラスターが表示されない
プライマリーハブクラスターに手動でインポートされたマネージドクラスターは、パッシブハブクラスターでアクティベーションデータが復元された場合にのみ表示されます。
1.2.8.5. クラスターのバックアップおよび復元のアップグレードの制限
enableClusterBackup
パラメーターを true
に設定してクラスターを 2.4 から 2.5 にアップグレードすると、次のメッセージが表示されます。
When upgrading from version 2.4 to 2.5, cluster backup must be disabled
クラスターをアップグレードする前に、enableClusterBackup
パラメーターを false
に設定して、クラスターのバックアップおよび復元を無効にします。MultiClusterHub
リソースの components
セクションは、次の YAML ファイルのようになります。
アップグレードが完了したら、バックアップおよび復元のコンポーネントを再度有効にすることができます。以下のサンプルを参照してください。
overrides: components: - enabled: true name: multiclusterhub-repo - enabled: true name: search - enabled: true name: management-ingress - enabled: true name: console - enabled: true name: insights - enabled: true name: grc - enabled: true name: cluster-lifecycle - enabled: true name: volsync - enabled: true name: multicluster-engine - enabled: false name: cluster-proxy-addon - enabled: true <<<<<<<< name: cluster-backup separateCertificateManagement: false
OADP を手動でインストールした場合は、アップグレードする前に OADP を手動でアンインストールする必要があります。アップグレードが成功し、バックアップおよび復元が再度有効になると、OADP が自動的にインストールされます。
1.2.8.6. マネージドクラスターリソースが復元されない
local-cluster
管理対象クラスター リソースの設定を復元し、新しいハブクラスターで local-cluster
データを上書きすると、設定が正しく設定されません。リソースにはクラスター URL の詳細など、local-cluster
固有の情報が含まれているため、以前のハブクラスター local-cluster
のコンテンツはバックアップされません。
復元されたクラスターの local-cluster
リソースに関連するすべての設定変更を手動で適用する必要があります。詳細については、新しいハブクラスターの準備 を参照してください。
1.2.8.7. prepareForBackup は、Velero スケジュールが最初に作成されたときにのみ呼び出されます
prepareForBackup
関数で定義されたラベルは、スケジュールの作成後に作成されたリソースには追加されません。これは、バックアップが開始する前にラベル付けされている Red Hat OpenShift シークレットの Hive および Infrastructure Operator に影響します。
影響を受けるリソースのリストを表示します。
-
clusterDeployments
によって使用され、クラスター要求によって作成されるシークレット - クラスタープールのシークレット
-
agent-install.openshift.io/watch
およびenvironment.metal3.io
のラベルが付いたシークレット
BackupSchedule
、veleroSchedule
、または veleroTTL
の値を更新して、新しい一連のスケジュールを開始します。次に、結果のバックアップを復元に使用します。これは、バックアップの最新のリソースにラベルを付けるように定義されています。
1.2.8.8. 復元された Hive マネージドクラスターは、新しいハブクラスターに接続できない場合がある
Hive マネージドクラスターの変更またはローテーションされた認証局 (CA) のバックアップを新しいハブクラスターで復元すると、マネージドクラスターは新しいハブクラスターへの接続に失敗します。このマネージドクラスターの admin
kubeconfig
シークレット (バックアップで使用可能) が無効になっているため、接続は失敗します。
新しいハブクラスター上のマネージドクラスターの復元された admin
kubeconfig
シークレットを手動で更新する必要があります。
1.2.9. Submariner の既知の問題
1.2.9.1. 現時点で Submariner が CNI ネットワークプロバイダーとしてサポートしているのは OpenShift SDN のみ
OpenShiftSDN のみが CNI ネットワークプロバイダーとしてサポートされています。OVN は現在サポートされていません。
1.2.9.2. Submariner はワーカーノードとして、一部の Red Hat Enterprise Linux ノードをサポートしていない
カーネルバージョンが 4.18.0-359.el8.x86_64 から 4.18.0-372.11.1.el8_6.x86_64 の Red Hat Enterprise Linux ワーカー ノードを含むクラスターに Submariner をデプロイすると、アプリケーションワークロードがリモートクラスターとの通信に失敗します。
1.2.9.3. Red Hat Advanced Cluster Management で管理可能なインフラストラクチャープロバイダーは Submariner でサポートされていない場合がある
Submariner は、Red Hat Advanced Cluster Management が管理できるすべてのインフラストラクチャープロバイダーでサポートされているわけではありません。サポートされているプロバイダーの一覧は、Red Hat Advanced Cluster Management のサポートマトリックス を参照してください。
1.2.9.4. Submariner は、Red Hat Advanced Cluster Management コンソールからの Red Hat OpenStack Platform インフラストラクチャーの準備をサポートしていない
Red Hat OpenStack クラスターの自動クラウド準備は、product-title-short} コンソールの Submariner ではサポートされていません。Red Hat Advanced Cluster Management API を使用して、クラウドを手動で準備できます。
1.2.9.5. Submariner は Globalnet でヘッドレスサービスをサポートしていない
Submariner は、Globalnet でヘッドレスサービスをサポートします。ただし、clusterset.local
ドメイン名を使用して、同じクラスター内に存在するクライアントからエクスポートされたヘッドレスサービスにアクセスすると、ヘッドレスサービスに関連付けられている globalIP
がクライアントに返され、クラスター内でルーティングできません。
cluster.local
ドメイン名を使用して、ローカルのヘッドレスサービスにアクセスできます。
1.2.9.6. Submariner はエアギャップクラスターをサポートしていない
Submariner は、エアギャップ環境でプロビジョニングされたクラスターに対して検証されていません。
1.2.9.7. 多数のゲートウェイをデプロイできない
複数のゲートウェイを展開することはできません。
1.2.9.8. NAT が有効な場合、Submariner は VXLAN をサポートしない
VXLAN ケーブルドライバーを使用する Submariner は、現在、非 NAT 展開でのみサポートされています。
1.2.9.9. グローバルネットの制限
Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。