第1章 マルチクラスターエンジン Operator を使用したクラスターライフサイクルについて
マルチクラスターエンジン Operator は、OpenShift Container Platform および Red Hat Advanced Cluster Management ハブクラスターにクラスター管理機能を提供するクラスターライフサイクル Operator です。ハブクラスターから、クラスターを作成および管理し、作成したクラスターを破棄できます。クラスターを休止、再開、およびデタッチすることもできます。クラスターライフサイクル機能の詳細は、以下のドキュメントを参照してください。
ハブクラスターとマネージドクラスターの要件とサポートについては、サポートマトリクス にアクセスしてください。
情報:
- クラスターは、Hive リソースとともに OpenShift Container Platform クラスターインストーラーを使用して作成されます。OpenShift Container Platform クラスターをインストールするプロセスについての詳細は、OpenShift Container Platform ドキュメントの OpenShift Container Platform インストールの概要 を参照してください。
- OpenShift Container Platform クラスターでは、マルチクラスターエンジン Operator をクラスターライフサイクル機能のスタンドアロンクラスターマネージャーとして使用するか、Red Hat Advanced Cluster Management ハブクラスターの一部として使用できます。
- OpenShift Container Platform のみを使用している場合、Operator はサブスクリプションに含まれます。OpenShift Container Platform ドキュメントから、Kubernetes Operator 用のマルチクラスターエンジンについて を参照してください。
- Red Hat Advanced Cluster Management にサブスクライブすると、インストールとともに Operator も受信されます。Red Hat Advanced Cluster Management ハブクラスターを使用して、他の Kubernetes クラスターを作成、管理、および監視できます。Red Hat Advanced Cluster Management インストールおよびアップグレード に関するドキュメントを参照してください。
リリースイメージは、クラスターの作成時に使用する OpenShift Container Platform のバージョンです。Red Hat Advanced Cluster Management を使用して作成されたクラスターの場合、リリースイメージの自動アップグレードを有効にできます。Red Hat Advanced Cluster Management のリリースイメージの詳細は、リリースイメージ を参照してください。
クラスターライフサイクル管理アーキテクチャーのコンポーネントは、クラスターライフサイクルアーキテクチャー に含まれています。
1.1. リリースノート
現在のリリースについて学びます。
非推奨: マルチクラスターエンジン Operator 2.2 以前のバージョンはサポートされなくなりました。ドキュメントはそのまま利用できますが、エラータやその他の更新は提供されません。
ベストプラクティス: 最新バージョンにアップグレードします。
現在サポートされているリリースのいずれか、製品ドキュメントで問題が発生した場合は、Red Hat サポート にアクセスして、トラブルシューティングを行ったり、ナレッジベース の記事を表示したり、サポートチームに連絡したり、ケースを開いたりすることができます。認証情報でログインする必要があります。
Red Hat Customer Portal FAQ で、カスタマーポータルのドキュメントの詳細を確認することもできます。
このドキュメントは、特定のコンポーネントまたは機能が導入され、より新しいバージョンの OpenShift Container Platform でのみテストされない限り、サポートされる最も早い OpenShift Container Platform バージョンを参照します。
フルサポート情報については、サポートマトリックス を参照してください。ライフサイクル情報は、Red Hat OpenShift Container Platform ライフサイクルポリシー を参照してください。
1.1.1. マルチクラスターエンジン Operator を使用したクラスターライフサイクルの新機能
重要: 一部の機能およびコンポーネントは テクノロジープレビュー として指定され、リリースされます。
詳細は、本リリースの新機能を参照してください。
1.1.1.1. クラスターライフサイクル
マルチクラスターエンジン Operator とクラスターライフサイクルに関連する新機能について説明します。
- マネージドクラスターが HTTP および HTTPS プロキシーサーバー経由でハブクラスターと通信できるように、クラスタープロキシーアドオンのプロキシー設定を指定できるようになりました。詳細は、クラスタープロキシーアドオンのプロキシー設定 を参照してください。
-
ManagedServiceAccount
アドオンがデフォルトで有効になるようになりました。マルチクラスターエンジン Operator バージョン 2.4 からアップグレードする場合にアドオンを有効にする方法の詳細は、ManagedServiceAccount アドオンの有効化 を参照してください。 - テクノロジープレビュー: サーバー URL とハブクラスター API CA バンドルをカスタマイズできるようになりました。これにより、中間コンポーネントがある場合でも、マルチクラスターエンジン Operator ハブクラスターにマネージドクラスターをインポートできるようになります。詳細は、サーバー URL とハブクラスター API CA バンドルのカスタマイズ (テクノロジープレビュー) を参照してください。
- 各リクエストで HTTP/HTTPS ヘッダーとクエリーパラメーターを渡して、OS イメージを取得できるようになりました。詳細は、非接続環境での Central Infrastructure Management の有効化 を参照してください。
-
認証に自己署名証明書またはサードパーティーの CA 証明書を使用して、TLS が有効な HTTPS
osImages
を保存およびダウンロードできるようになりました。詳細は、非接続環境での Central Infrastructure Management の有効化 を参照してください。
1.1.1.2. 認証情報
- 統合されたコンソールを使用して、Cluster OS image フィールドを設定し、VMware vSphere での非接続インストール用に認証情報を作成できるようになりました。詳細は、コンソールを使用した認証情報の管理 を参照してください。
1.1.1.3. Hosted Control Plane
- テクノロジープレビュー: 非ベアメタルエージェントマシンを使用して、Hosted Control Plane クラスターをプロビジョニングできます。詳細は、非ベアメタルエージェントマシンを使用した Hosted Control Plane クラスターの設定 を参照してください。
- コンソールを使用して、ホステッドクラスターを KubeVirt プラットフォームで作成できるようになりました。詳細は、コンソールを使用したホステッドクラスターの作成 を参照してください。
- 追加のネットワークの設定、仮想マシン (VM) 用の Guaranteed CPU へのアクセス要求、およびノードプールの KubeVirt 仮想マシンのスケジュール管理を実行できるようになりました。詳細は、ノードプールの追加ネットワーク、保証された CPU、および仮想マシンスケジュールの設定 を参照してください。
1.1.1.4. Red Hat Advanced Cluster Management の統合
Red Hat Advanced Cluster Management のインストール後に可観測性を有効にすると、Grafana ダッシュボードを使用して、Hosted Control Plane クラスター容量の推定値と既存の Hosted Control Plane のリソース使用率を表示できます。詳細は、Red Hat Advanced Cluster Management の統合 を参照してください。
1.1.2. クラスターライフサイクルの既知の問題
マルチクラスターエンジン Operator を使用したクラスターライフサイクルの既知の問題を確認します。以下のリストには、本リリースの既知の問題、または以前のリリースから持ち越された既知の問題が記載されています。OpenShift Container Platform クラスターについては、OpenShift Container Platform リリースノート を参照してください。
1.1.2.1. クラスター管理
クラスターライフサイクルの既知の問題と制限は、マルチクラスターエンジン Operator のドキュメントを使用したクラスターライフサイクルの一部です。
1.1.2.1.1. nmstate の制限事項
コピーアンドペースト機能を設定することで、開発を迅速化します。assisted-installer
で copy-from-mac
機能を設定するには、nmstate
定義インターフェイスと mac-mapping
インターフェイスに mac-address
を追加する必要があります。mac-mapping
インターフェイスは、nmstate
定義インターフェイスの外部で提供されます。そのため、同じ mac-address
を 2 回指定する必要があります。
1.1.2.1.2. プリフックに問題があっても、ホステッドクラスターの作成は失敗しない
ホステッドクラスターの作成に自動化テンプレートを使用し、プリフックジョブが失敗した場合は、ホステッドクラスターの作成がまだ進行中であるように見えます。ホステッドクラスターは完全な障害状態を想定して設計されていないため、クラスターの作成を試行し続けるため、これは正常です。
1.1.2.1.3. アドオンの削除時にマネージドクラスターで必要な VolSync CSV の手動削除
ハブクラスターから VolSync ManagedClusterAddOn
を削除すると、マネージドクラスターの VolSync Operator サブスクリプションが削除されますが、クラスターサービスバージョン (CSV) は削除されません。マネージドクラスターから CSV を削除するには、VolSync を削除する各マネージドクラスターで以下のコマンドを実行します。
oc delete csv -n openshift-operators volsync-product.v0.6.0
別のバージョンの VolSync がインストールされている場合は、v0.6.0
をインストール済みバージョンに置き換えます。
1.1.2.1.4. マネージドクラスターセットを削除してもそのラベルが自動的に削除されない
ManagedClusterSet
を削除した後に、クラスターセットに関連付ける各マネージドクラスターに追加されるラベルは自動的に削除されません。削除したマネージドクラスターセットに含まれる各マネージドクラスターからラベルを手動で削除します。ラベルは cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name>
のようになります。
1.1.2.1.5. ClusterClaim エラー
ClusterPool
に対して Hive ClusterClaim
を作成し、ClusterClaimspec
ライフタイムフィールドを無効な golang 時間値に手動で設定すると、製品は不正な要求だけでなく、すべての 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.1.2.1.6. 製品チャネルが、プロビジョニングされたクラスターと同期されない
clusterimageset
は fast
チャネルに置かれますが、プロビジョニングされたクラスターは stable
チャネルにあります。現時点で、製品は channel
をプロビジョニングされた OpenShift Container Platform クラスターと同期しません。
OpenShift Container Platform コンソールで適切なチャネルに切り替えます。Administration > Cluster Settings > Details Channel の順にクリックします。
1.1.2.1.7. カスタム CA 証明書を使用したマネージドクラスターの、復元されたハブクラスターへの接続の復元は失敗する可能性がある
カスタム CA 証明書を使用してクラスターを管理したハブクラスターのバックアップを復元した後、マネージドクラスターとハブクラスター間の接続が失敗する場合があります。これは、復元されたハブクラスターで CA 証明書がバックアップされなかったためです。接続を復元するには、マネージドクラスターの namespace にあるカスタム CA 証明書情報を、復元されたハブクラスターの <managed_cluster>-admin-kubeconfig
シークレットにコピーします。
ヒント: バックアップコピーを作成する前にこの CA 証明書をハブクラスターにコピーする場合は、バックアップコピーにシークレット情報が含まれます。将来、バックアップコピーを使用して復元する場合、ハブとマネージドクラスター間の接続は自動的に完了します。
1.1.2.1.8. local-cluster が自動的に再作成されない場合がある
disableHubSelfManagement
が false
に設定されている場合、local-cluster は MulticlusterHub
Operator によって再作成されます。local-cluster をデタッチした後、local-cluster が自動的に再作成されない場合があります。
この問題を解決するには、
MulticlusterHub
によって監視されるリソースを変更します。以下の例を参照してください。oc delete deployment multiclusterhub-repo -n <namespace>
-
local-cluster を適切にデタッチするには、
MultiClusterHub
でdisableHubSelfManagement
を true に設定します。
1.1.2.1.9. オンプレミスクラスターを作成する場合は、サブネットを選択する必要がある
コンソールを使用してオンプレミスクラスターを作成する場合は、クラスターで利用可能なサブネットを選択する必要があります。必須フィールドとしてマークされていません。
1.1.2.1.10. 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.1.2.1.11. 別の名前で再インポートした後に 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.1.2.1.12. Ansible 自動化を使用したクラスタープロビジョニングがプロキシー環境で失敗する
マネージドクラスターを自動的にプロビジョニングするように設定された自動化テンプレートは、次の両方の条件が満たされた場合に失敗する可能性があります。
- ハブクラスターで、クラスター全体のプロキシーが有効になっている。
- Ansible Automation Platform には、プロキシー経由でのみアクセスできます。
1.1.2.1.13. klusterlet Operator のバージョンは、ハブクラスターと同じである必要がある
klusterlet Operator をインストールしてマネージドクラスターをインポートする場合には、klusterlet Operator のバージョンは、ハブクラスターのバージョンと同じでなければなりません。そうでないと、klusterlet Operator は動作しません。
1.1.2.1.14. マネージドクラスター namespace を手動で削除できない
マネージドクラスターの namespace を手動で削除できません。マネージドクラスター namespace は、マネージドクラスターの割り当てを解除した後に自動的に削除されます。マネージドクラスターの割り当てを解除する前に手動でマネージドクラスター namespace を削除する場合は、マネージドクラスターの削除後にマネージドクラスターに継続的な終了ステータスが表示されます。この終了マネージドクラスターを削除するには、割り当てを解除したマネージドクラスターからファイナライザーを手動で削除します。
1.1.2.1.15. ハブクラスターとマネージドクラスターのクロックが同期されない
ハブクラスターおよびマネージドクラスターの時間が同期されず、コンソールで unknown
と表示され、最数的に、数分以内に available
と表示されます。OpenShift Container Platform ハブクラスターの時間が正しく設定されていることを確認します。ノードのカスタマイズ を参照してください。
1.1.2.1.16. IBM OpenShift Container Platform Kubernetes Service クラスターの特定のバージョンのインポートはサポートされていない
IBM OpenShift Container Platform Kubernetes Service バージョン 3.11 のクラスターをインポートすることはできません。IBM OpenShift Kubernetes Service の 3.11 よりも後のバージョンはサポート対象です。
1.1.2.1.17. プロビジョニングされたクラスターのシークレットの自動更新はサポートされていない
クラウドプロバイダー側でクラウドプロバイダーのアクセスキーを変更する場合は、マルチクラスターエンジン Operator のコンソールでこのクラウドプロバイダーの対応する認証情報を更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。
1.1.2.1.18. マネージドクラスターからのノード情報を検索で表示できない
検索で、ハブクラスターのリソース用の RBAC がマッピングされます。ユーザー RBAC の設定によっては、マネージドクラスターからのノードデータが表示されない場合があります。また検索の結果は、クラスターの Nodes ページに表示される内容と異なる場合があります。
1.1.2.1.19. クラスターを破棄するプロセスが完了しない
マネージドクラスターを破棄してから 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.1.2.1.20. OpenShift Container Platform Dedicated でコンソールを使用して OpenShift Container Platform マネージドクラスターをアップグレードできない
Red Hat Advanced Cluster Management コンソールを使用して、OpenShift Container Platform Dedicated 環境にある OpenShift Container Platform マネージドクラスターをアップグレードすることはできません。
1.1.2.1.21. ワークマネージャーのアドオン検索の詳細
特定のマネージドクラスターにある特定のリソースの検索詳細ページで問題が発生する可能性があります。マネージドクラスターの work-manager アドオンが Available
ステータスであることを確認してから検索する必要があります。
1.1.2.1.22. Red Hat OpenShift Container Platform 以外のマネージドクラスターでは、アップグレード後に Pod ログ用に ManagedServiceAccount または LoadBalancer が必要となる
Red Hat Advanced Cluster Management 2.10 以降の新規インストールを使用している場合、Red Hat OpenShift Container Platform クラスターと非 OpenShift Container Platform クラスターの両方が Pod ログ機能をサポートしています。
Red Hat Advanced Cluster Management 2.9 から 2.10 にアップグレードした場合、OpenShift Container Platform 以外のマネージドクラスターで Pod ログ機能を使用するには、ManagedServiceAccount
アドオンを手動で有効にする必要があります。ManagedServiceAccount
を有効にする方法については、ManagedServiceAccount アドオン を参照してください。
または、ManagedServiceAccount
の代わりに LoadBalancer
を使用して、OpenShift Container Platform 以外のマネージドクラスターで Pod ログ機能を有効にすることもできます。
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.1.2.1.23. OpenShift Container Platform 4.10.z では、プロキシー設定を使用する Hosted Control Plane クラスターはサポートされません
OpenShift Container Platform 4.10.z でクラスター全体のプロキシー設定を使用してホスティングサービスクラスターを作成すると、nodeip-configuration.service
サービスがワーカーノードで開始されません。
1.1.2.1.24. Azure で OpenShift Container Platform 4.11 クラスターをプロビジョニングできない
Azure で OpenShift Container Platform 4.11 クラスターをプロビジョニングすると、認証 Operator のタイムアウトエラーが原因で失敗します。この問題を回避するには、install-config.yaml
ファイルで別のワーカーノードタイプを使用するか、vmNetworkingType
パラメーターを Basic
に設定します。次の install-config.yaml
の例を参照してください。
compute: - hyperthreading: Enabled name: 'worker' replicas: 3 platform: azure: type: Standard_D2s_v3 osDisk: diskSizeGB: 128 vmNetworkingType: 'Basic'
1.1.2.1.25. クライアントが iPXE スクリプトにアクセスできない
iPXE は、オープンソースのネットワークブートファームウェアです。詳細は、iPXE を参照してください。
ノードの起動時に、一部の DHCP サーバーの URL の長さ制限により、InfraEnv
カスタムリソース定義の ipxeScript
URL が切り取られ、コンソールに次のエラーメッセージが表示されます。
起動可能なデバイスがありません
この問題を回避するには、以下の手順を実行します。
自動インストールを使用して
bootArtifacts
を公開する場合は、InfraEnv
カスタムリソース定義を適用します。これは次のファイルのようになります。status: agentLabelSelector: matchLabels: infraenvs.agent-install.openshift.io: qe2 bootArtifacts: initrd: https://assisted-image-service-multicluster-engine.redhat.com/images/0000/pxe-initrd?api_key=0000000&arch=x86_64&version=4.11 ipxeScript: https://assisted-service-multicluster-engine.redhat.com/api/assisted-install/v2/infra-envs/00000/downloads/files?api_key=000000000&file_name=ipxe-script kernel: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.12/latest/rhcos-live-kernel-x86_64 rootfs: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.12/latest/rhcos-live-rootfs.x86_64.img
-
短い URL で
bootArtifacts
を公開するプロキシーサーバーを作成します。 次のコマンドを実行して、
bootArtifacts
をコピーし、プロキシーに追加します。for artifact in oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts}" | jq ". | keys[]" | sed "s/\"//g" do curl -k oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts.${artifact}}"` -o $artifact
-
ipxeScript
アーティファクトプロキシー URL をlibvirt.xml
のbootp
パラメーターに追加します。
1.1.2.1.26. Red Hat Advanced Cluster Management のアップグレード後に ClusterDeployment を削除できない
Red Hat Advanced Cluster Management 2.6 で削除された BareMetalAssets API を使用している場合、BareMetalAssets API が ClusterDeployment
にバインドされているため、Red Hat Advanced Cluster Management 2.7 にアップグレードした後に ClusterDeployment
を削除することはできません。
この問題を回避するには、以下のコマンドを実行して、Red Hat Advanced Cluster Management 2.7 にアップグレードする前に finalizers
を削除します。
oc patch clusterdeployment <clusterdeployment-name> -p '{"metadata":{"finalizers":null}}' --type=merge
1.1.2.1.27. Central Infrastructure Management サービスを使用して非接続環境にデプロイされたクラスターがインストールされない場合がある
Central Infrastructure Management サービスを使用して非接続環境でクラスターをデプロイすると、クラスターノードのインストールが開始されない場合があります。
この問題は、OpenShift Container Platform バージョン 4.12.0 から 4.12.2 に同梱されている Red Hat Enterprise Linux CoreOS ライブ ISO イメージから作成された検出 ISO イメージをクラスターが使用するために発生します。イメージには、registry.redhat.io
および registry.access.redhat.com
から取得したイメージの署名を必要とする制限付きの /etc/containers/policy.json
ファイルが含まれています。非接続環境では、ミラーリングされたイメージにミラーリングされた署名がない場合があり、その結果、クラスターノードの検出時にイメージのプルが失敗します。Agent イメージがクラスターノードとの接続に失敗するため、Assisted Service との通信が失敗します。
この問題を回避するには、/etc/containers/policy.json
ファイルを制限なしに設定する ignition オーバーライドをクラスターに適用します。ignition オーバーライドは、InfraEnv
カスタムリソース定義で設定できます。次の例は、オーバーライドを使用した InfraEnv
カスタムリソース定義を示しています。
apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: cluster namespace: cluster spec: ignitionConfigOverride: '{"ignition":{"version":"3.2.0"},"storage":{"files":[{"path":"/etc/containers/policy.json","mode":420,"overwrite":true,"contents":{"source":"data:text/plain;charset=utf-8;base64,ewogICAgImRlZmF1bHQiOiBbCiAgICAgICAgewogICAgICAgICAgICAidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIgogICAgICAgIH0KICAgIF0sCiAgICAidHJhbnNwb3J0cyI6CiAgICAgICAgewogICAgICAgICAgICAiZG9ja2VyLWRhZW1vbiI6CiAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIiI6IFt7InR5cGUiOiJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dCiAgICAgICAgICAgICAgICB9CiAgICAgICAgfQp9"}}]}}'
次の例は、作成される制限なしのファイルを示しています。
{ "default": [ { "type": "insecureAcceptAnything" } ], "transports": { "docker-daemon": { "": [ { "type": "insecureAcceptAnything" } ] } } }
この設定を変更すると、クラスターがインストールされます。
1.1.2.1.28. マネージドクラスターがデプロイ後に Pending ステータスのままになる
デフォルトのプロビジョニングプロセスは、コンバージドフローです。Bare Metal Operator (BMO) の BareMetalHost
リソースを使用してホストをライブ ISO に接続すると、Ironic Python Agent が次のアクションを実行します。
- ベアメタル installer-provisioned-infrastructure の手順を実行します。
- Assisted Installer エージェントを起動します。エージェントが残りのインストールおよびプロビジョニングプロセスを処理します。
Assisted Installer エージェントの起動が遅く、マネージドクラスターをデプロイすると、マネージドクラスターが Pending
ステータスのままになり、エージェントリソースがなくなる可能性があります。この問題は、コンバージドフローを無効にすることで回避できます。
重要: コンバージドフローを無効にすると、ライブ ISO で Assisted Installer エージェントのみが実行されるため、開いているポートの数が減り、Ironic Python Agent で有効にした以下の機能がすべて無効になります。
- プロビジョニング前のディスククリーニング
- iPXE ブートファームウェア
- BIOS 設定
コンバージドフローを無効にせずに有効または無効にするポート番号を決定するには、ネットワーク設定 を参照してください。
コンバージドフローを無効にするには、次の手順を実行します。
ハブクラスター上に次の ConfigMap を作成します。
apiVersion: v1 kind: ConfigMap metadata: name: my-assisted-service-config namespace: multicluster-engine data: ALLOW_CONVERGED_FLOW: "false" 1
- 1
- パラメーター値を "false" に設定すると、Ironic Python Agent によって有効になっている機能もすべて無効になります。
次のコマンドを実行して、ConfigMap を適用します。
oc annotate --overwrite AgentServiceConfig agent unsupported.agent-install.openshift.io/assisted-service-configmap=my-assisted-service-config
1.1.2.1.29. ManagedClusterSet API 仕様の制限
Clustersets API を使用する場合、selectorType: LaberSelector
設定がサポートされません。selectorType: ExclusiveClusterSetLabel
設定がサポートされています。
1.1.2.1.30. ハブクラスター通信の制限
ハブクラスターがマネージドクラスターにアクセスできない、またはマネージドクラスターと通信できない場合、次の制限が発生します。
- コンソールを使用して新しいマネージドクラスターを作成できません。コマンドラインインターフェイスを使用するか、コンソールで Run import commands manually オプションを使用して、マネージドクラスターを手動でインポートできます。
- コンソールを使用してアプリケーションまたはアプリケーションセットをデプロイする場合、またはマネージドクラスターを ArgoCD にインポートする場合、ハブクラスター ArgoCD コントローラーはマネージドクラスター API サーバーを呼び出します。AppSub または ArgoCD pull モデルを使用して問題を回避できます。
Pod ログのコンソールページは機能せず、以下のようなエラーメッセージが表示されます。
Error querying resource logs: Service unavailable
1.1.2.1.31. Managed Service Account アドオンの制限
managed-serviceaccount
アドオンの既知の問題と制限事項は次のとおりです。
1.1.2.1.31.1. installNamespace フィールドには値を 1 つだけ指定できる
managed-serviceaccount
アドオンを有効にする場合、ManagedClusterAddOn
リソースの installNamespace
フィールドの値として open-cluster-management-agent-addon
が必要です。その他の値は無視されます。managed-serviceaccount
アドオンエージェントは、マネージドクラスターの open-cluster-management-agent-addon
namespace に常にデプロイされます。
1.1.2.1.31.2. マネージドサービスアカウント エージェントは tolerations と nodeSelector の設定による影響を受けない
MultiClusterEngine
および MultiClusterHub
リソースに設定された tolerations
と nodeSelector
設定は、ローカルクラスターにデプロイされた managed-serviceaccount
エージェントには影響しません。マネージドサービスアカウント
アドオンは、ローカルクラスターでは必ずしも必要というわけではありません。
managed-serviceaccount
アドオンが必要な場合は、次の手順を実行することで問題を回避できます。
-
addonDeploymentConfig
カスタムリソースを作成します。 -
ローカルクラスターおよび
managed-serviceaccount
エージェントのtolerations
およびnodeSelector
の値を設定します。 -
作成した
addonDeploymentConfig
カスタムリソースを使用するように、ローカルクラスター namespace でmanaged-serviceaccount
ManagedClusterAddon
を更新します。
addonDeploymentConfig
カスタムリソースを使用してアドオンの tolerations
と nodeSelector
を設定する方法の詳細は、klusterlet アドオン の nodeSelectors と tolerations の設定を参照してください。
1.1.2.1.32. KubeVirt ホステッドクラスターの一括破棄オプションでホステッドクラスターが破棄されない
KubeVirt ホステッドクラスターのコンソールで一括破棄オプションを使用しても、KubeVirt ホステッドクラスターが破棄されません。
代わりに、行のアクションドロップダウンメニューを使用して、KubeVirt ホステッドクラスターを破棄してください。
1.1.2.1.33. クラスターキュレーターが OpenShift Container Platform Dedicated クラスターをサポートしていない
ClusterCurator
リソースを使用して OpenShift Container Platform Dedicated クラスターをアップグレードすると、クラスターキュレーターが OpenShift Container Platform Dedicated クラスターをサポートしていないため、アップグレードが失敗します。
1.1.2.1.34. カスタム Ingress ドメインが正しく適用されない
マネージドクラスターのインストール中に ClusterDeployment
リソースを使用してカスタム Ingress ドメインを指定できますが、変更はインストール後に SyncSet
リソースを使用してのみ適用されます。その結果、clusterdeployment.yaml
ファイルの spec
フィールドには、指定したカスタム Ingress ドメインが表示されますが、status
には引き続きデフォルトのドメインが表示されます。
1.1.2.2. Hosted Control Plane
1.1.2.2.1. コンソールにホステッドクラスターが Pending import として表示される
アノテーションと ManagedCluster
名が一致しない場合、コンソールはクラスターを Pending import
と表示します。クラスターはマルチクラスターエンジン Operator では使用できません。アノテーションがなく、ManagedCluster
名が HostedCluster
リソースの Infra-ID
値と一致しない場合は、同じ問題が発生します。
1.1.2.2.2. コンソールは、ホステッドクラスターにノードプールを追加する際に、同じバージョンを複数回、一覧表示する場合があります。
コンソールを使用して既存のホステッドクラスターに新規ノードプールを追加すると、同じバージョンの OpenShift Container Platform がオプションの一覧に複数回、表示される可能性があります。必要なバージョンの一覧で任意のインスタンスを選択できます。
1.1.2.2.3. Web コンソールには、ノードがクラスターから削除されインフラストラクチャー環境に戻された後でもノードがリストされます。
ノードプールが 0 ワーカーにスケールダウンされても、コンソールのホストのリストには、Ready
状態のノードが表示されます。ノードの数は、次の 2 つの方法で確認できます。
- コンソールでノードプールに移動し、ノードが 0 であることを確認します。
コマンドラインインターフェイスで、以下のコマンドを実行します。
次のコマンドを実行して、ノードプールにあるノード数が 0 個であることを確認します。
oc get nodepool -A
次のコマンドを実行して、クラスター内にあるノード数が 0 個であることを確認します。
oc get nodes --kubeconfig
- 次のコマンドを実行して、クラスターにバインドされているエージェント数が 0 と報告されていることを確認します。
oc get agents -A
1.1.2.2.4. デュアルスタックネットワーク用に設定されたホステッドクラスターで DNS の問題が発生する可能性がある
デュアルスタックネットワークを使用する環境でホステッドクラスターを作成すると、次の DNS 関連の問題が発生する可能性があります。
-
service-ca-operator
Pod のCrashLoopBackOff
状態: Pod が Hosted Control Plane 経由で Kubernetes API サーバーに到達しようとすると、kube-system
namespace のデータプレーンプロキシーがリクエストを解決できないため、Pod はサーバーに到達できません。この問題は、HAProxy セットアップでフロントエンドが IP アドレスを使用し、バックエンドが Pod が解決できない DNS 名を使用するために発生します。 -
Pod が
ContainerCreating
状態でスタックする: この問題は、openshift-service-ca-operator
が DNS Pod が DNS 解決に必要とするmetrics-tls
シークレットを生成できないために発生します。その結果、Pod は Kubernetes API サーバーを解決できません。
これらの問題を解決するには、デュアルスタックネットワーク用の DNS の設定 のガイドラインに従って DNS サーバー設定を指定します。
1.1.2.2.5. ベアメタルプラットフォームでは、エージェントリソースが Ignition に失敗することがある
ベアメタル (エージェント) プラットフォームでは、Hosted Control Plane 機能により、エージェントがイグニションのプルに使用するトークンが定期的にローテーションされます。バグにより、新しいトークンが伝播されません。その結果、少し前に作成されたエージェントリソースがある場合、Ignition のプルに失敗する可能性があります。
回避策として、エージェント仕様で、IgnitionEndpointTokenReference
プロパティーが参照するシークレットを削除し、エージェントリソースのラベルを追加または変更します。その後、システムはエージェントリソースが変更されたことを検出し、新しいトークンを使用してシークレットを再作成できます。
1.1.3. エラータの更新
マルチクラスターエンジン Operator の場合、エラータの更新はリリース時に自動的に適用されます。
重要: 参照できるように、エラータ リンクと GitHub 番号がコンテンツに追加され、内部で使用される可能性があります。ユーザーは、アクセス権が必要なリンクを利用できない可能性があります。
1.1.3.1. エラータ 2.5.6
-
同時に実行されていた 2 つのバージョンの
cluster-proxy-addon
からのアップグレード問題を修正しました。これにより、マニフェストが相互に上書きしていました。(ACM-12411) - 1 つ以上の製品コンテナーイメージに更新を配信します。
1.1.3.2. エラータ 2.5.5
-
マルチクラスターエンジン Operator バージョン 2.5.3 またはバージョン 2.5.4.にアップグレードした後、単一ノードの OpenShift マネージドクラスターが
不明
なステータスを表示する原因となっていた問題を修正します。(ACM-12712) - 1 つ以上の製品コンテナーイメージに更新を配信します。
1.1.3.3. エラータ 2.5.4
- 1 つ以上の製品コンテナーイメージに更新を配信します。
1.1.3.4. エラータ 2.5.3
-
KubeVirt 作成ウィザードに、Hosted Control Plane クラスターのデフォルトモードを
HighAvailability
モードに設定するフィールドが追加されました。(ACM-12712) - 1 つ以上の製品コンテナーイメージに更新を配信します。
1.1.3.5. エラータ 2.5.2
- バックアップ/復元シナリオを実行し、Red Hat OpenShift Data Foundation (ODF) の Regional-DR ソリューションを使用すると、データ損失が発生する可能性がある問題を修正しました。(ACM-10407)
- 1 つ以上の製品コンテナーイメージに更新を配信します。
1.1.3.6. エラータ 2.5.1
- 1 つ以上の製品コンテナーイメージに更新を配信します。
1.1.4. 非推奨とクラスターライフサイクルの削除
製品の一部が非推奨になる、またはマルチクラスターエンジン Operator から削除されるタイミングを説明します。推奨アクション および詳細にある、代わりのアクションを検討してください。これについては、現在のリリースおよび、1 つ前のリリースと 2 つ前のリリースの表に記載されています。
非推奨: マルチクラスターエンジン Operator 2.2 以前のバージョンはサポートされなくなりました。ドキュメントはそのまま利用できますが、エラータやその他の更新は提供されません。
ベストプラクティス: 最新バージョンにアップグレードします。
1.1.4.1. API の非推奨と削除
マルチクラスターエンジン Operator は、Kubernetes の API 非推奨ガイドラインに従います。そのポリシーに関する詳細は、Kubernetes の非推奨ポリシー を参照してください。マルチクラスターエンジン Operator API は、以下のタイムライン外でのみ非推奨または削除されます。
-
V1
API はすべて、12 ヶ月間またはリリース 3 回分 (いずれか長い方) の期間は一般公開され、サポート対象となります。V1 API は削除されませんが、この期間を過ぎると非推奨になる可能性があります。 -
Beta
版 API はすべて、9 ヶ月間またはリリース 3 回分 (いずれか長い方) の期間は一般公開されます。Beta 版 API は、この期間を過ぎても削除されません。 -
alpha
版 API はサポートの必要はありませんが、ユーザーにとってメリットがある場合には、非推奨または削除予定として記載される場合があります。
1.1.4.1.1. API の非推奨化
製品またはカテゴリー | 影響を受けるアイテム | バージョン | 推奨されるアクション | 詳細およびリンク |
---|---|---|---|---|
ManagedServiceAccount |
| 2.9 |
| なし |
1.1.4.1.2. API の削除
製品またはカテゴリー | 影響を受けるアイテム | バージョン | 推奨されるアクション | 詳細およびリンク |
1.1.4.2. 非推奨
非推奨 のコンポーネント、機能またはサービスはサポートされますが、使用は推奨されておらず、今後のリリースで廃止される可能性があります。以下の表に記載されている 推奨アクション と詳細の代替アクションについて検討してください。
製品またはカテゴリー | 影響を受けるアイテム | バージョン | 推奨されるアクション | 詳細およびリンク |
---|---|---|---|---|
クラスターライフサイクル | Red Hat Virtualization でのクラスターの作成 | 2.9 | なし | なし |
クラスターライフサイクル | klusterlet OLM Operator | 2.4 | なし | なし |
1.1.4.3. 削除
通常、削除 された項目は、以前のリリースで非推奨となった機能で、製品では利用できなくなっています。削除された機能には、代わりの方法を使用する必要があります。以下の表に記載されている 推奨アクション と詳細の代替アクションについて検討してください。
製品またはカテゴリー | 影響を受けるアイテム | バージョン | 推奨されるアクション | 詳細およびリンク |