Red Hat Summitクラスター
multicluster engine Operator を使用したクラスター管理の手順、リリースノート、トラブルシューティング情報を提供します。また、Red Hat Advanced Cluster Management を使用せずに multicluster engine Operator をインストールします。
概要
第1章 multicluster engine Operator を使用したクラスターライフサイクルの概要
multicluster engine Operator は、OpenShift Container Platform および Red Hat Advanced Cluster Management ハブクラスターにクラスター管理機能を提供するクラスターライフサイクル Operator です。ハブクラスターから、クラスターを作成および管理し、作成したクラスターを破棄できます。クラスターを休止、再開、およびデタッチすることもできます。
multicluster engine Operator は、Red Hat OpenShift Container Platform および Red Hat Advanced Cluster Management ハブクラスターにクラスター管理機能を提供するクラスターライフサイクル Operator です。Red Hat Advanced Cluster Management をインストールした場合、multicluster engine Operator は自動的にインストールされるため、インストールする必要はありません。multicluster engine Operator を使用したクラスターライフサイクルに関するその他の重要な情報を参照してください。
- クラスターは、Hive リソースとともに OpenShift Container Platform クラスターインストーラーを使用して作成されます。OpenShift Container Platform クラスターのインストールプロセスの詳細は OpenShift Container Platform ドキュメントの OpenShift Container Platform クラスターのインストールと設定 を参照してください。
- OpenShift Container Platform クラスターでは、multicluster engine Operator を、クラスターライフサイクル機能のスタンドアロンクラスターマネージャーとして使用することも、Red Hat Advanced Cluster Management ハブクラスターの一部として使用することもできます。
- OpenShift Container Platform のみを使用している場合、Operator はサブスクリプションに含まれます。OpenShift Container Platform ドキュメントの multicluster engine for Kubernetes Operator について を参照してください。
- Red Hat Advanced Cluster Management にサブスクライブすると、インストールとともに Operator も受信されます。Red Hat Advanced Cluster Management ハブクラスターを使用して、他の Kubernetes クラスターを作成、管理、および監視できます。
- リリースイメージは、クラスターの作成時に使用する OpenShift Container Platform のバージョンです。Red Hat Advanced Cluster Management を使用して作成されたクラスターの場合、リリースイメージの自動アップグレードを有効にできます。Red Hat Advanced Cluster Management のリリースイメージの詳細は、リリースイメージ を参照してください。
OpenShift Container Platform の Hosted Control Plane を使用すると、コントロールプレーンごとに専用の物理マシンを用意する必要なく、ホスティングクラスター上にコントロールプレーンを Pod として作成できます。OpenShift Container Platform ドキュメントの Hosted Control Plane の概要 を参照してください。
1.1. コンソールの概要
OpenShift Container Platform コンソールプラグインは OpenShift Container Platform Web コンソールで利用可能であり、統合することができます。この機能を使用するには、コンソールプラグインを有効にしておく必要があります。Infrastructure および Credentials ナビゲーション項目の一部のコンソール機能は、multicluster engine Operator によって表示されます。Red Hat Advanced Cluster Management をインストールすると、より多くのコンソール機能が表示されます。
注記: プラグインが有効になっている場合、ドロップダウンメニューから All Clusters を選択することにより、クラスタースイッチャーから OpenShift Container Platform コンソール内の Red Hat Advanced Cluster Management にアクセスできます。
- プラグインを無効にするには、OpenShift Container Platform コンソールの Administrator パースペクティブにいることを確認してください。
- ナビゲーションで Administration を探し、Cluster Settings をクリックし、続いて Configuration タブをクリックします。
-
Configuration resources のリストから、
operator.openshift.ioAPI グループが含まれる Console リソースをクリックします。この API グループには、Web コンソールのクラスター全体の設定が含まれています。 -
Console plug-ins タブをクリックします。
mceプラグインがリスト表示されます。注記: Red Hat Advanced Cluster Management がインストールされている場合は、acmとしても表示されます。 - テーブルからプラグインのステータスを変更します。しばらくすると、コンソールを更新するように求められます。
1.2. multicluster engine Operator のロールベースのアクセス制御
RBAC はコンソールレベルと API レベルで検証されます。コンソール内のアクションは、ユーザーのアクセスロールの権限に基づいて有効化/無効化できます。製品の特定ライフサイクルの RBAC の詳細は、以下のセクションを参照してください。
1.2.1. ロールの概要
クラスター別の製品リソースと、スコープに namespace が指定されている製品リソースがあります。アクセス制御に一貫性を持たせるため、クラスターのロールバインディングと、namespace のロールバインディングをユーザーに適用する必要があります。サポートされている次のロール定義の表リストを表示します。
1.2.1.1. ロール定義表
| ロール | 定義 |
|---|---|
|
|
これは OpenShift Container Platform のデフォルトのロールです。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
admin、edit、および view は OpenShift Container Platform のデフォルトロールです。これらのロールに対して namespace に限定されたバインディングが指定されているユーザーは、特定の namespace 内の |
重要:
- ユーザーは OpenShift Container Platform からプロジェクトを作成できます。これにより、namespace の管理者ロール権限が付与されます。
-
ユーザーにクラスターへのロールアクセスがない場合、クラスター名は表示されません。クラスター名は、
-の記号で表示されます。
RBAC はコンソールレベルと API レベルで検証されます。コンソール内のアクションは、ユーザーのアクセスロールの権限に基づいて有効化/無効化できます。製品の特定ライフサイクルの RBAC の詳細は、以下のセクションを参照してください。
1.2.2. クラスターライフサイクル RBAC
以下のクラスターライフサイクル RBAC 操作を確認してください。
すべてのマネージドクラスターのクラスターロールバインドを作成および管理します。たとえば、以下のコマンドを入力してクラスターロール
open-cluster-management:cluster-manager-adminにバインドするクラスターロールを作成します。oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:cluster-manager-admin --user=<username>
oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:cluster-manager-admin --user=<username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow このロールはスーパーユーザーであるため、すべてのリソースとアクションにアクセスできます。このロールを使用すると、クラスターレベルの
managedclusterリソース、マネージドクラスターを管理するリソースの namespace、namespace 内のリソースを作成できます。権限エラーを回避するために、ロールの関連付けが必要な ID のusernameを追加する必要がある場合があります。以下のコマンドを実行して、
cluster-nameという名前のマネージドクラスターのクラスターロールバインドを管理します。oc create clusterrolebinding (role-binding-name) --clusterrole=open-cluster-management:admin:<cluster-name> --user=<username>
oc create clusterrolebinding (role-binding-name) --clusterrole=open-cluster-management:admin:<cluster-name> --user=<username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow このロールを使用すると、クラスターレベルの
managedclusterリソースに読み取り/書き込みアクセスができるようになります。managedclusterはクラスターレベルのリソースで、namespace レベルのリソースではないので、このロールが必要です。以下のコマンドを入力して、クラスターロール
adminにバインドする namespace ロールを作成します。oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=admin --user=<username>
oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=admin --user=<username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow このロールでは、マネージドクラスターの namespace 内にあるリソースに対して読み取り/書き込みアクセスができるようになります。
open-cluster-management:view:<cluster-name>クラスターロールのクラスターロールバインドを作成して、cluster-nameという名前のマネージドクラスターを表示します。次のコマンドを入力します。oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:view:<cluster-name> --user=<username>
oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:view:<cluster-name> --user=<username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow このロールを使用すると、クラスターレベルの
managedclusterリソースに読み取りアクセスができるようになります。これは、managedclusterがクラスタースコープのリソースであるために必要です。以下のコマンドを入力して、クラスターロール
viewにバインドする namespace ロールを作成します。oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=view --user=<username>
oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=view --user=<username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow このロールでは、マネージドクラスターの namespace 内にあるリソースに対して読み取り専用アクセスができるようになります。
以下のコマンドを入力して、アクセス可能なマネージドクラスターの一覧を表示します。
oc get managedclusters.clusterview.open-cluster-management.io
oc get managedclusters.clusterview.open-cluster-management.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、クラスター管理者権限なしで、管理者およびユーザーが使用できます。
以下のコマンドを入力して、アクセス可能なマネージドクラスターセットの一覧を表示します。
oc get managedclustersets.clusterview.open-cluster-management.io
oc get managedclustersets.clusterview.open-cluster-management.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、クラスター管理者権限なしで、管理者およびユーザーが使用できます。
1.2.2.1. クラスタープール RBAC
以下のクラスタープール RBAC 操作を確認します。
クラスター管理者は、クラスタープールのプロビジョニングクラスターを使用して、マネージドクラスターセットを作成し、ロールをグループに追加して管理者権限をロールに付与します。以下の例を参照してください。
以下のコマンドを使用して、
server-foundation-clustersetマネージドクラスターセットにadmin権限を付与します。oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-admin:server-foundation-clusterset server-foundation-team-admin
oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-admin:server-foundation-clusterset server-foundation-team-adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを使用して、
server-foundation-clustersetマネージドクラスターセットにview権限を付与します。oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-view:server-foundation-clusterset server-foundation-team-user
oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-view:server-foundation-clusterset server-foundation-team-userCopy to Clipboard Copied! Toggle word wrap Toggle overflow
クラスタープールの namespace (
server-foundation-clusterpool) を作成します。ロール権限を付与するには、以下の例を参照してください。以下のコマンドを実行して、
server-foundation-team-adminのserver-foundation-clusterpoolにadmin権限を付与します。oc adm new-project server-foundation-clusterpool oc adm policy add-role-to-group admin server-foundation-team-admin --namespace server-foundation-clusterpool
oc adm new-project server-foundation-clusterpool oc adm policy add-role-to-group admin server-foundation-team-admin --namespace server-foundation-clusterpoolCopy to Clipboard Copied! Toggle word wrap Toggle overflow
チーム管理者として、クラスタープール namespace にクラスターセットラベル
cluster.open-cluster-management.io/clusterset=server-foundation-clustersetを使用してocp46-aws-clusterpoolという名前のクラスタープールを作成します。-
server-foundation-webhookは、クラスタープールにクラスターセットラベルがあるかどうか、またユーザーにクラスターセットのクラスタープールを作成する権限があるかどうかを確認します。 -
server-foundation-controllerは、server-foundation-team-userのserver-foundation-clusterpoolnamespace にview権限を付与します。
-
クラスタープールが作成されると、クラスタープールは
clusterdeploymentを作成します。詳細は、以下を参照してください。-
server-foundation-controllerは、server-foundation-team-adminのclusterdeploymentnamespace にadmin権限を付与します。 server-foundation-controllerは、server-foundation-team-userのclusterdeploymentnamespace にview権限を付与します。注記:
team-adminおよびteam-userには、clusterpool、clusterdeployment、およびclusterclaimへのadmin権限があります。
-
1.2.2.2. クラスターライフサイクルのコンソールおよび API RBAC の表
クラスターライフサイクルの以下のコンソールおよび API RBAC の表を表示します。
| リソース | 管理 | 編集 | 表示 |
|---|---|---|---|
| クラスター | read, update, delete | - | read |
| クラスターセット | get, update, bind, join | 編集ロールなし | get |
| マネージドクラスター | read, update, delete | 編集ロールなし | get |
| プロバイダー接続 | create, read, update, delete | - | read |
| API | 管理 | 編集 | 表示 |
|---|---|---|---|
|
この API のコマンドでは、 | create, read, update, delete | read, update | read |
|
この API のコマンドでは、 | read | read | read |
|
| update | update | |
|
この API のコマンドでは、 | create, read, update, delete | read, update | read |
|
| read | read | read |
|
この API のコマンドでは、 | create, read, update, delete | read, update | read |
|
| create, read, update, delete | read, update | read |
|
| create, read, update, delete | read, update | read |
|
| create, read, update, delete | read, update | read |
|
| create, read, update, delete | read, update | read |
|
| create, read, update, delete | read, update | read |
|
| create, read, update, delete | read, update | read |
|
| create, read, update, delete | read, update | read |
1.2.2.3. 認証情報ロールベースのアクセス制御
認証情報へのアクセスは Kubernetes で制御されます。認証情報は Kubernetes Secret として保存され、セキュリティーを確保します。以下の権限は、Red Hat Advanced Cluster Management for Kubernetes のシークレットのアクセスに関係します。
- namespace でシークレットの作成権限のあるユーザーは認証情報を作成できます。
- namespace でシークレットの読み取り権限のあるユーザーは、認証情報を表示することもできます。
-
Kubernetes ロール
adminおよびeditのあるユーザーは、シークレットの作成と編集が可能です。 -
Kubernetes クラスターロール
viewのあるユーザーは、シークレットの内容を読み取ると、サービスアカウントの認証情報にアクセスできるようになるため、シークレットを表示できません。
1.3. ネットワーク設定
接続を許可するようにネットワーク設定を設定します。
重要: 信頼できる CA バンドルを multicluster engine Operator の namespace で利用できますが、その拡張にはネットワークの変更が必要です。信頼できる CA バンドル ConfigMap は、trusted-ca-bundle のデフォルト名を使用します。この名前は、TRUSTED_CA_BUNDLE という名前の環境変数で Operator に提供すると変更できます。詳細は、Red Hat OpenShift Container Platform の ネットワーク セクションの クラスター全体のプロキシーの設定 を参照してください。
multicluster engine Operator のクラスターネットワーク要件は、次の表を参照してください。
| 方向 | ソース | 宛先 | プロトコル | ポート | 説明 |
|---|---|---|---|---|---|
| マネージドクラスターへのアウトバウンド |
ハブクラスター上の Hive と | プロビジョニングしたマネージドクラスターの Kubernetes API サーバー | HTTPS | 6443 | プロビジョニングされたマネージドクラスターの Kubernetes API サーバー |
| マネージドクラスターへのアウトバウンド | ハブクラスター上の Ironic サービス | マネージドクラスター上の Ironic Python Agent | TCP | 9999 | Ironic Python Agent が実行されているベアメタルノードと Ironic conductor サービス間の通信 |
| マネージドクラスターからの受信 | Baseboard Management Controller (ベースボード管理コントローラー: BMC) | Ironic サービスの隣の HTTP サーバー | TCP | 6180, 6183 | ベースボード管理コントローラー (BMC) は、仮想メディアのポート 6180 および 6183 にアクセスします。ブートファームウェアはポート 6180 にアクセスします |
| マネージドクラスターからの受信 | マネージドクラスター上の Ironic Python Agent | ハブクラスター上の Ironic サービス | TCP | 6385 | Ironic Python Agent とハブクラスター上の Ironic サービス間の通信 |
| マネージドクラスターからの受信 | マネージドクラスター上のクラスタープロキシーアドオンエージェント | クラスタープロキシー ANP サービス | TCP | 443 | マネージドクラスター上のクラスタープロキシーアドオンエージェントとハブクラスター上のクラスタープロキシーアドオン ANP サービス間の通信 |
| マネージドクラスターからの受信 | Klusterlet エージェントとアドオンエージェント | ハブクラスター上の Kubernetes API サーバー | HTTPS | 6443 | マネージドクラスターからの multicluster engine Operator クラスターの Kubernetes API サーバー |
注記: マネージドクラスター上の klusterlet エージェントが、直接接続するのではなく、ハブクラスター上の apiserver にアクセスするためにプロキシー設定を必要とする場合は、ハブクラスターとマネージドクラスター間のプロキシーの設定 を参照してください。
1.4. multicluster engine Operator を使用したクラスターライフサイクルのリリースノート
multicluster engine Operator によるクラスターライフサイクルの新機能と拡張機能、サポート、非推奨、削除、および修正された問題を説明します。
重要: このドキュメントに、OpenShift Container Platform のリリースノートは 含まれていません。OpenShift Container Platform クラスターは、OpenShift Container Platform リリースノート を参照してください。
非推奨: multicluster engine Operator 2.4 以前のバージョンはサポートされなくなりました。ドキュメントは引き続き利用可能になる可能性がありますが、修正された問題やその他の更新に関するエラータリリースは行われません。
ベストプラクティス: 最新バージョンにアップグレードします。
- このドキュメントでは、特定のコンポーネントまたは機能が OpenShift Container Platform のより新しいバージョンでのみデプロイおよびテストされている場合を除き、サポートされている最も古い OpenShift Container Platform バージョンを参照します。
- 完全なサポート情報は、multicluster engine Operator のサポートマトリックス を参照してください。ライフサイクルの情報は、Red Hat OpenShift Container Platform ライフサイクルポリシー を参照してください。
- 現在サポートされているリリースのいずれか、製品ドキュメントで問題が発生した場合は、Red Hat サポート にアクセスして、トラブルシューティングを行ったり、ナレッジベース の記事を表示したり、サポートチームに連絡したり、ケースを開いたりすることができます。認証情報でログインする必要があります。
- Red Hat Customer Portal FAQ で、カスタマーポータルのドキュメントの詳細を確認することもできます。
1.4.1. multicluster engine Operator を使用したクラスターライフサイクルの新機能と機能拡張
Multicluster engine for Kubernetes Operator 2.9 の新機能と拡張機能、サポート、廃止予定、削除、およびエラータリリースの修正された問題を説明します。
multicluster engine Operator バージョン 2.9 は、クラスターライフサイクル管理用の Red Hat Advanced Cluster Management バージョン 2.14 とともにリリースされています。ただし、OpenShift Container Platform ハブクラスターでスタンドアロンの multicluster engine Operator を使用することもできます。
サポートされている OpenShift Container Platform バージョンを含む詳細なサポート情報は、multicluster engine Operator のサポートマトリックス を参照してください。ライフサイクルの情報は、Red Hat OpenShift Container Platform ライフサイクルポリシー を参照してください。
さまざまなインフラストラクチャークラウドプロバイダー、プライベートクラウド、オンプレミスデータセンターにわたる Kubernetes クラスターを作成、インポート、管理、破棄するための multicluster engine Operator 機能を使用します。
重要:
- Cluster Management では、Cloud Native Computing Foundation (CNCF) Kubernetes Conformance Program を通じて認定されたすべてのプロバイダーがサポートされています。ハイブリッドクラウドマルチクラスター管理には、CNFC が認定したベンダーを選択してください。CNFC プロバイダーの使用は、次の情報を参照してください。
- Certified Kubernetes Conformance で CNFC プロバイダーがどのように認定されるかを学びます。
- CNFC サードパーティープロバイダーに関する Red Hat サポート情報は、サードパーティーコンポーネントに関する Red Hat サポート を参照するか、Red Hat サポートへのお問い合わせ を参照してください。
-
独自の CNFC 適合認定クラスターを使用する場合は、OpenShift Container Platform CLI の
ocコマンドを Kubernetes CLI コマンドのkubectlに変更する必要があります。
1.4.1.1. 各コンポーネントの新機能と機能強化
特定のコンポーネントの新機能を詳しく説明します。
注記: 一部の機能とコンポーネントは、テクノロジープレビュー として指定およびリリースされています。
重要: OpenShift Container Platform の Hosted Control Plane ドキュメントは、OpenShift Container Platform ドキュメント内にあります。Hosted Control Plane の概要 を参照してください。
multicluster engine Operator のインストールに関連する新機能と機能拡張を説明します。
-
ローカルクラスターの名前を変更できるようになりました。デフォルトでは、multicluster engine Operator を実行しているクラスターは、ローカルクラスター で自己管理するハブクラスターです。
enabledフィールドがfalseに設定され、ローカルクラスター機能が無効になっている場合は、名前を変更できます。<your-local-cluster-name>値には 34 文字以下を使用します。local-clusterリソースと namespace に変更が反映されます。
multicluster engine Operator を使用したクラスターライフサイクルの新機能と機能拡張を説明します。
-
cluster-apiコンポーネントが一般提供されるようになりました。このコンポーネントは、multicluster engine operator のインストール時に導入され、マネージドクラスターから Cluster API ライフサイクルの機能が提供されます。cluster-api-provider-awsも一般提供されるようになりました。このコンポーネントもインストール時に導入され、Hosted Control Plane を使用した Red Hat OpenShift Service on AWS のクラスターの作成、設定、管理用の Kubernetes スタイルの API を提供します。両方のコンポーネントはデフォルトで無効になっています。 -
metal3インフラストラクチャープロバイダーと OpenShift Container Platform 支援ブートストラップおよびコントロールプレーンプロバイダーを使用して、Cluster API を備えた OpenShift Container Platform マネージドクラスターをインストールできます。Cluster API を使用してマネージドクラスターをインストールする を参照してください。 -
ハブクラスターユーザートークンを使用して
kube-apiserverリソースにアクセスすることで、特定のリソースを収集し、ログを取得し、データを表示できるようになりました。詳細は、ハブクラスターユーザートークンを使用したデータの収集 を参照してください。 - 分離されたレジストリー設定が必要なマルチクラスター環境で、クラスターごとに一意のミラーレジストリーを定義できるようになりました。詳細は、各クラスターのミラーレジストリーの設定 を参照してください。
-
マネージドクラスターの自動インポートのプロセスを、1 回限りのプロセスの場合は
ImportOnlyに、継続的なプロセスの場合はImportAndSyncにカスタマイズします。詳細は、自動インポートストラテジーのカスタマイズ を参照してください。 -
中央インフラストラクチャー管理を有効にするときに、
OSImageCACertConfigMapに任意のファイル名を使用できるようになりました。詳細は、非接続環境での Central Infrastructure Management の有効化 を参照してください。
multicluster engine Operator を使用していて、後から Red Hat Advanced Cluster Management をインストールした場合は、このリリースの Red Hat Advanced Cluster Management の新機能と拡張機能 を参照してください。
1.4.2. multicluster engine Operator を使用したクラスターライフサイクルの問題を修正
デフォルトでは、エラータ リリース向けに修正された問題は、リリース時に自動的に適用されます。リリースが入手可能になれば、詳細がここに公開されます。リリースノートが記載されていない場合は、現時点で製品にエラータリリースがありません。
重要: 参考までに、Jira リンクと Jira 番号がコンテンツに追加され、内部で使用される可能性があります。ユーザーは、アクセス権が必要なリンクを利用できない可能性があります。Red Hat の エラータリリース の種類について説明します。
1.4.3. multicluster engine Operator を使用したクラスターライフサイクルの既知の問題
このリリースの multicluster engine Operator を使用したクラスターライフサイクル の既知の問題、または以前のリリースから続く既知の問題を確認してください。
クラスター管理の既知の問題と制限は、multicluster engine Operator を使用したクラスターライフサイクル ドキュメントに含まれています。Red Hat Advanced Cluster Management と 統合された multicluster engine Operator の既知の問題は、Red Hat Advanced Cluster Management のリリースノート に記載されています。
重要: このドキュメントに、OpenShift Container Platform のリリースノートは含まれていません。OpenShift Container Platform クラスターは、OpenShift Container Platform リリースノート を参照してください。
1.4.3.1. インストール
multicluster engine Operator のインストール中に発生する既知の問題と制限を説明します。
1.4.3.1.1. installNamespace フィールドには値を 1 つだけ指定できる
managed-serviceaccount アドオンを有効にする場合、ManagedClusterAddOn リソースの installNamespace フィールドの値として open-cluster-management-agent-addon が必要です。その他の値は無視されます。managed-serviceaccount アドオンエージェントは、マネージドクラスターの open-cluster-management-agent-addon namespace に常にデプロイされます。
1.4.3.2. クラスター管理
クラスターの作成、検出、インポート、削除に関する問題や、multicluster engine Operator のクラスター管理に関するその他の問題など、multicluster engine Operator を使用したクラスターライフサイクルの既知の問題を説明します。
1.4.3.2.1. cluster-api-provider-aws Webhook が Hosted Control Plane デプロイメントをブロックする
OpenShift Container Platform の Hosted Control Plane は cluster-api-provider-aws リソースと、hypershift-local-hosting コンポーネントによってインストールされた hypershift リソース間の API が競合するため、AWS のインフラストラクチャーリソースを管理できません。
AWS プラットフォームホステッドクラスターの hypershift コンポーネントを使用するには、cluster-api および cluster-api-provider-aws コンポーネントを有効に しないでください。これらのコンポーネントは、デフォルトで enabled: false に設定されています。コンポーネントを無効にした次のデフォルト設定を参照してください。
次の YAML サンプルのように、hypershift-local-hosting が有効になっている場合は、前のコンポーネントが有効になっていないことを確認します。
- configOverrides: {}
enabled: true
name: hypershift-local-hosting
- configOverrides: {}
enabled: true
name: hypershift-local-hosting1.4.3.2.2. Klusterlet アドオンは、NoExecute 効果による node-role.kubernetes.io/infra の taint を許容しません。
インフラストラクチャーノードで NoExecute 効果を持つ node-role.kubernetes.io/infra taint を使用すると、アドオン Pod がスタックする可能性があります。
この問題を回避するには、node-role.kubernetes.io/infra taint に対して NoExecute ではなく NoSchedule 効果を使用するか、インフラストラクチャーノードから node-role.kubernetes.io/infra taint を削除します。
1.4.3.2.3. nmstate の制限事項
コピーアンドペースト機能を設定することで、開発を迅速化します。assisted-installer で copy-from-mac 機能を設定するには、nmstate 定義インターフェイスと mac-mapping インターフェイスに mac-address を追加する必要があります。mac-mapping インターフェイスは、nmstate 定義インターフェイスの外部で提供されます。そのため、同じ mac-address を 2 回指定する必要があります。
1.4.3.2.4. マネージドクラスターセットを削除してもそのラベルが自動的に削除されない
ManagedClusterSet を削除した後に、クラスターセットに関連付ける各マネージドクラスターに追加されるラベルは自動的に削除されません。削除したマネージドクラスターセットに含まれる各マネージドクラスターからラベルを手動で削除します。ラベルは cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name> のようになります。
1.4.3.2.5. ClusterClaim エラー
ClusterPool に対して Hive ClusterClaim を作成し、ClusterClaimspec ライフタイムフィールドを無効な golang 時間値に手動で設定すると、製品は不正な要求だけでなく、すべての ClusterClaims を満たし、リコンサイルを停止します。
clusterclaim-controller Pod ログに次のエラーが表示されます。これは、PoolName と無効な lifetime が含まれている具体的な例です。
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|...
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.4.3.2.6. 製品チャネルが、プロビジョニングされたクラスターと同期されない
clusterimageset は fast チャネルに置かれますが、プロビジョニングされたクラスターは stable チャネルにあります。現時点で、製品は channel をプロビジョニングされた OpenShift Container Platform クラスターと同期しません。
OpenShift Container Platform コンソールで適切なチャネルに切り替えます。Administration > Cluster Settings > Details Channel の順にクリックします。
1.4.3.2.7. Ansible 自動化を使用したクラスタープロビジョニングがプロキシー環境で失敗する
マネージドクラスターを自動的にプロビジョニングするように設定された自動化テンプレートは、次の両方の条件が満たされた場合に失敗する可能性があります。
- ハブクラスターで、クラスター全体のプロキシーが有効になっている。
- Ansible Automation Platform には、プロキシー経由でのみアクセスできます。
1.4.3.2.8. マネージドクラスター namespace を手動で削除できない
マネージドクラスターの namespace を手動で削除できません。マネージドクラスター namespace は、マネージドクラスターの割り当てを解除した後に自動的に削除されます。マネージドクラスターの割り当てを解除する前に手動でマネージドクラスター namespace を削除する場合は、マネージドクラスターの削除後にマネージドクラスターに継続的な終了ステータスが表示されます。この終了マネージドクラスターを削除するには、割り当てを解除したマネージドクラスターからファイナライザーを手動で削除します。
1.4.3.2.9. プロビジョニングされたクラスターのシークレットの自動更新はサポートされていない
クラウドプロバイダー側でクラウドプロバイダーのアクセスキーを変更する場合は、multicluster engine Operator のコンソールでこのクラウドプロバイダーの対応する認証情報を更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。
1.4.3.2.10. クラスターを破棄するプロセスが完了しない
マネージドクラスターを破棄してから 1 時間経過してもステータスが Destroying のままで、クラスターが破棄されません。この問題を解決するには、以下の手順を実行します。
- クラウドに孤立したリソースがなく、マネージドクラスターに関連付けられたプロバイダーリソースがすべて消去されていることを確認します。
以下のコマンドを入力して、削除するマネージドクラスターの
ClusterDeployment情報を開きます。oc edit clusterdeployment/<mycluster> -n <namespace>
oc edit clusterdeployment/<mycluster> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow myclusterは、破棄するマネージドクラスターの名前に置き換えます。namespaceは、マネージドクラスターの namespace に置き換えます。-
hive.openshift.io/deprovisionファイナライザーを削除し、クラウドのクラスターリソースを消去しようとするプロセスを強制的に停止します。 -
変更を保存して、
ClusterDeploymentが削除されていることを確認します。 以下のコマンドを実行してマネージドクラスターの namespace を手動で削除します。
oc delete ns <namespace>
oc delete ns <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespaceは、マネージドクラスターの namespace に置き換えます。
Red Hat Advanced Cluster Management コンソールを使用して、OpenShift Container Platform Dedicated 環境にある OpenShift Container Platform マネージドクラスターをアップグレードすることはできません。
1.4.3.2.12. OpenShift Container Platform 以外のマネージドクラスターには、Pod ログ用に ManagedServiceAccount または LoadBalancer が必要です
ManagedServiceAccount とクラスタープロキシーアドオンは、Red Hat Advanced Cluster Management バージョン 2.10 以降でデフォルトで有効になっています。アップグレード後にアドオンが無効になっている場合は、ManagedServiceAccount およびクラスタープロキシーアドオンを手動で有効にして、Pod ログ機能を使用する必要があります。
ManagedServiceAccount を有効にする方法は、ManagedServiceAccount アドオン を参照してください。また、クラスタープロキシーアドオンを有効にする方法は、クラスタープロキシーアドオンの設定 を参照してください。
-
ManagedServiceAccountアドオンを有効にする方法については、ManagedServiceAccount アドオン を参照してください。 - クラスタープロキシーアドオンを有効にする方法については、クラスタープロキシーアドオンの使用 を参照してください。
1.4.3.2.13. クライアントが iPXE スクリプトにアクセスできない
iPXE は、オープンソースのネットワークブートファームウェアです。詳細は、iPXE を参照してください。
ノードの起動時に、一部の DHCP サーバーの URL の長さ制限により、InfraEnv カスタムリソース定義の ipxeScript URL が切り取られ、コンソールに次のエラーメッセージが表示されます。
起動可能なデバイスがありません
この問題を回避するには、以下の手順を実行します。
-
自動インストールを使用して
bootArtifactsを公開する場合は、InfraEnvカスタムリソース定義を適用します。これは次のファイルのようになります。
-
短い 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 $artifactfor 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 $artifactCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
ipxeScriptアーティファクトプロキシー URL をlibvirt.xmlのbootpパラメーターに追加します。
1.4.3.2.14. 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
oc patch clusterdeployment <clusterdeployment-name> -p '{"metadata":{"finalizers":null}}' --type=merge1.4.3.2.15. ManagedClusterSet API 仕様の制限
Clustersets API を使用する場合、selectorType: LaberSelector 設定がサポートされません。selectorType: ExclusiveClusterSetLabel 設定がサポートされています。
1.4.3.2.16. クラスターキュレーターが OpenShift Container Platform Dedicated クラスターをサポートしていない
ClusterCurator リソースを使用して OpenShift Container Platform Dedicated クラスターをアップグレードすると、クラスターキュレーターが OpenShift Container Platform Dedicated クラスターをサポートしていないため、アップグレードが失敗します。
1.4.3.2.17. カスタム Ingress ドメインが正しく適用されない
マネージドクラスターのインストール中に ClusterDeployment リソースを使用してカスタム Ingress ドメインを指定できますが、変更はインストール後に SyncSet リソースを使用してのみ適用されます。その結果、clusterdeployment.yaml ファイルの spec フィールドには、指定したカスタム Ingress ドメインが表示されますが、status には引き続きデフォルトのドメインが表示されます。
1.4.3.2.18. ManagedClusterAddOn のステータスが停止する
ManagedClusterAddOn で設定を定義して ClusterManagementAddon の一部の設定をオーバーライドすると、ManagedClusterAddOn が次のステータスで停止する可能性があります。
progressing... mca and work configs mismatch
progressing... mca and work configs mismatch
ManagedClusterAddOn のステータスを確認すると、設定が存在する場合でも、設定の一部に空の spec ハッシュがあります。以下の例を参照してください。
この問題を解決するには、次のコマンドを実行して ManagedClusterAddOn を削除し、ManagedClusterAddOn を再インストールして回復します。<cluster-name> は、ManagedClusterAddOn の namespace に置き換えます。<addon-name> は、ManagedClusterAddOn の名前に置き換えます。
oc -n <cluster-name> delete managedclusteraddon <addon-name>
oc -n <cluster-name> delete managedclusteraddon <addon-name>1.4.3.2.19. マネージドサービスアカウント エージェントは tolerations と nodeSelector の設定による影響を受けない
MultiClusterEngine および MultiClusterHub リソースに設定された tolerations と nodeSelector 設定は、ローカルクラスターにデプロイされた managed-serviceaccount エージェントには影響しません。マネージドサービスアカウント アドオンは、ローカルクラスターでは必ずしも必要というわけではありません。
managed-serviceaccount アドオンが必要な場合は、次の手順を実行することで問題を回避できます。
-
addonDeploymentConfigカスタムリソースを作成します。 -
ローカルクラスターおよび
managed-serviceaccountエージェントのtolerationsおよびnodeSelectorの値を設定します。 -
作成した
addonDeploymentConfigカスタムリソースを使用するように、ローカルクラスター namespace でmanaged-serviceaccountManagedClusterAddonを更新します。
addonDeploymentConfig カスタムリソースを使用してアドオンの tolerations と nodeSelector を設定する方法の詳細は、klusterlet アドオンの設定 を参照してください。
1.4.3.3. Central Infrastructure Management
Red Hat OpenShift Container Platform バージョン 4.19 より前のバージョンを使用してシングルノード OpenShift クラスターをインストールする場合、InfraEnv カスタムリソースと起動されるホストが、シングルノード OpenShift クラスターのインストールに使用するのと同じ OpenShift Container Platform バージョンを使用する必要があります。バージョンが一致しない場合はインストールが失敗します。
この問題を回避するには、Discovery ISO を使用してホストを起動する前に InfraEnv リソースを編集し、次の内容を含めます。<4.x> は、インストールする osImageVersion に置き換えます。
apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv spec: osImageVersion: "<4.x>"
apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
spec:
osImageVersion: "<4.x>"1.4.3.3.2. ホストインベントリーを使用して検出イメージで起動し、ホストを自動的に追加できない
ホストインベントリーまたは InfraEnv カスタムリソースを使用して検出イメージで起動し、ホストを自動的に追加できません。BareMetalHost リソースに以前の InfraEnv リソースを使用していて、自分でイメージを起動する場合は、新しい InfraEnv リソースを作成することで問題を回避できます。
1.4.3.3.3. BareMetalHost リソースを削除すると、ノードがシャットダウンする
ハブクラスターから BareMetalHost リソースを削除すると、ノードがシャットダウンします。ノードは手動で再び電源をオンにすることができます。
1.4.4. multicluster engine Operator を使用したクラスターライフサイクルの非推奨化と削除
製品の一部が非推奨になるタイミングや multicluster engine Operator から削除されるタイミングを説明します。推奨アクション および詳細にある、代わりのアクションを検討してください。これは、現在のリリースおよび、1 つ前のリリースと 2 つ前のリリースの表に記載されています。このリリースで該当するセクションに追加する項目がなかった場合、テーブルは削除されています。
非推奨: multicluster engine Operator 2.4 以前のバージョンはサポートされなくなりました。ドキュメントは引き続き利用可能になる可能性がありますが、修正された問題やその他の更新に関するエラータリリースは行われません。
ベストプラクティス: 最新バージョンにアップグレードします。
1.4.4.1. 製品の非推奨と削除
非推奨 のコンポーネント、機能またはサービスはサポートされますが、使用は推奨されておらず、今後のリリースで廃止される可能性があります。以下の表に記載されている 推奨アクション と詳細の代替アクションを検討してください。
| 製品またはカテゴリー | 影響を受けるアイテム | バージョン | 推奨されるアクション | 詳細およびリンク |
|---|---|---|---|---|
| API のドキュメント | multicluster engine Operator API ドキュメント | multicluster engine Operator 2.8 | ドキュメントではなく、コンソールまたはターミナルから現在のサポートされている API を確認します。 | なし |
| KlusterletConfig |
| 2.7 |
| なし |
| KlusterletConfig |
| 2.7 |
| なし |
| KlusterletConfig |
| 2.7 |
| None |
通常、削除 された項目は、以前のリリースで非推奨となった機能で、製品では利用できなくなっています。削除された機能には、代わりの方法を使用する必要があります。以下の表に記載されている 推奨アクション と詳細の代替アクションを検討してください。
| 製品またはカテゴリー | 影響を受けるアイテム | バージョン | 推奨されるアクション | 詳細およびリンク |
|---|---|---|---|---|
| クラスターライフサイクル |
| 2.9 | なし | なし |
| クラスターライフサイクル | Red Hat Virtualization でのクラスターの作成 | 2.6 | なし | なし |
| クラスターライフサイクル | Klusterlet Operator Lifecycle Manager Operator | 2.6 | なし | なし |
1.5. multicluster engine Operator のインストールとアップグレード
multicluster engine Operator は、クラスターフリートの管理を強化するソフトウェア Operator です。multicluster engine Operator は、クラウドおよびデータセンター全体の Red Hat OpenShift Container Platform および Kubernetes クラスターライフサイクル管理をサポートします。
このドキュメントでは、特定のコンポーネントまたは機能が OpenShift Container Platform のより新しいバージョンでのみデプロイおよびテストされている場合を除き、サポートされている最も古い OpenShift Container Platform バージョンを参照します。
完全なサポート情報は、multicluster engine Operator のサポートマトリックス を参照してください。ライフサイクルの情報は、Red Hat OpenShift Container Platform ライフサイクルポリシー を参照してください。
重要: Red Hat Advanced Cluster Management を使用している場合、multicluster engine for Kubernetes Operator はクラスターにすでにインストールされています。
非推奨: multicluster engine Operator 2.4 以前のバージョンはサポートされなくなりました。ドキュメントは引き続き利用可能になる可能性がありますが、修正された問題やその他の更新に関するエラータリリースは行われません。
ベストプラクティス: 最新バージョンにアップグレードします。
以下のドキュメントを参照してください。
1.5.1. オンライン接続時のインストール
multicluster engine Operator は、Operator Lifecycle Manager によってインストールされます。これは、multicluster engine Operator を含むコンポーネントのインストール、アップグレード、および削除を管理します。
必要なアクセス権: クラスター管理者
重要:
-
外部クラスターに
ManagedClusterリソースが設定されているクラスターに multicluster engine Operator をインストールできません。multicluster engine Operator をインストールする前に、外部クラスターからManagedClusterリソースを削除する必要があります。 -
OpenShift Container Platform 専用環境の場合は、
cluster-admin権限が必要です。デフォルトで、dedicated-adminロールには OpenShift Container Platform Dedicated 環境で namespace を作成するために必要な権限がありません。 - デフォルトでは、multicluster engine Operator コンポーネントは追加設定なしで OpenShift Container Platform クラスターのワーカーノードにインストールされます。OpenShift Container Platform OperatorHub Web コンソールインターフェイスを使用するか、OpenShift Container Platform CLI を使用して multicluster engine Operator をワーカーノードにインストールできます。
- OpenShift Container Platform クラスターをインフラストラクチャーノードで設定している場合は、OpenShift Container Platform CLI を使用し、追加のリソースパラメーターを指定して multicluster engine Operator をそのインフラストラクチャーノードにインストールできます。詳細は、インフラストラクチャーノードへのマルチクラスターエンジンのインストール セクションを参照してください。
OpenShift Container Platform または multicluster engine Operator で作成されていない Kubernetes クラスターをインポートする予定の場合は、イメージプルシークレットを設定する必要があります。イメージプルシークレットおよびその他の高度な設定方法は、このドキュメントの 詳細設定 セクションのオプションを参照してください。
1.5.1.1. 前提条件
multicluster engine Operator をインストールする前に、次の前提条件を確認してください。
- OpenShift Container Platform クラスターがコンソールから OperatorHub カタログ内の multicluster engine Operator にアクセスできる。
- catalog.redhat.com へのアクセスがある。
-
クラスターに外部クラスターに設定された
ManagedClusterリソースが ない。 サポートされているバージョンの OpenShift Container Platform を環境にデプロイし、OpenShift Container Platform CLI を使用してログインする。次のインストールドキュメントを参照してください。
-
OpenShift Container Platform のコマンドラインインターフェイス (CLI) は、
ocコマンドを実行できるように設定している。OpenShift Container Platform CLI のインストールおよび設定の詳細は、CLI の使用方法 を参照してください。 - namespace の作成が可能な OpenShift Container Platform のパーミッションを設定している。
- operator の依存関係にアクセスするには、インターネット接続が必要。
OpenShift Container Platform Dedicated 環境にインストールするには、以下を参照してください。
- OpenShift Container Platform Dedicated 環境が設定され、実行している。
-
エンジンのインストール先の OpenShift Container Platform Dedicated 環境での
cluster-adminがある。
- Red Hat OpenShift Container Platform に付属する Assisted Installer を使用してマネージドクラスターを作成する予定の場合は、要件について、OpenShift Container Platform ドキュメントの Assisted Installer を使用したインストールの準備 トピックを参照してください。
1.5.1.2. OpenShift Container Platform インストールの確認
レジストリー、ストレージサービスなど、サポート対象の OpenShift Container Platform バージョンがインストールされ、機能する状態である必要があります。OpenShift Container Platform のインストールの詳細は、OpenShift Container Platform のドキュメントを参照してください。
- multicluster engine Operator が OpenShift Container Platform クラスターにインストールされていないことを確認します。インストールできる multicluster engine Operator は、OpenShift Container Platform クラスターごとに 1 つだけです。インストールがない場合は、次の手順に進みます。
OpenShift Container Platform クラスターが正しく設定されていることを確認するには、以下のコマンドを使用して OpenShift Container Platform Web コンソールにアクセスします。
kubectl -n openshift-console get route console
kubectl -n openshift-console get route consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の出力例を参照してください。
console console-openshift-console.apps.new-coral.purple-chesterfield.com console https reencrypt/Redirect None
console console-openshift-console.apps.new-coral.purple-chesterfield.com console https reencrypt/Redirect NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
ブラウザーで URL を開き、結果を確認します。コンソール URL の表示が
console-openshift-console.router.default.svc.cluster.localの場合は、OpenShift Container Platform のインストール時にopenshift_master_default_subdomainを設定します。https://console-openshift-console.apps.new-coral.purple-chesterfield.comの例を参照してください。
multicluster engine Operator のインストールに進むことができます。
1.5.1.3. OperatorHub Web コンソールインターフェイスからのインストール
ベストプラクティス: OpenShift Container Platform ナビゲーションの Administrator ビューから、OpenShift Container Platform で提供される OperatorHub Web コンソールインターフェイスをインストールします。
- Operators > OperatorHub を選択して利用可能な operator のリストにアクセスし、multicluster engine for Kubernetes Operator を選択します。
-
Installをクリックします。 Operator Installation ページで、インストールのオプションを選択します。
Namespace:
- multicluster engine Operator エンジンは、独自の namespace またはプロジェクトにインストールする必要があります。
-
デフォルトでは、OperatorHub コンソールのインストールプロセスにより、
multicluster-engineという名前の namespace が作成されます。ベストプラクティス:multicluster-enginenamespace が使用可能な場合は、引き続き使用します。 -
multicluster-engineという名前の namespace が存在する場合は、別の namespace を選択してください。
- チャネル: インストールするリリースに対応するチャネルを選択します。チャネルを選択すると、指定のリリースがインストールされ、そのリリース内の今後のエラータ更新が取得されます。
承認ストラテジー: 承認ストラテジーでは、サブスクライブ先のチャネルまたはリリースに更新を適用するのに必要な人の間のやり取りを特定します。
- そのリリース内の更新が自動的に適用されるようにするには、デフォルトで選択されている Automatic を選択します。
- Manual を選択して、更新が利用可能になると通知を受け取ります。更新がいつ適用されるかについて懸念がある場合は、これがベストプラクティスになる可能性があります。
注記: 次のマイナーリリースにアップグレードするには、OperatorHub ページに戻り、最新リリースの新規チャネルを選択する必要があります。
- Install を選択して変更を適用し、Operator を作成します。
MultiClusterEngine カスタムリソースを作成するには、次のプロセスを参照してください。
- OpenShift Container Platform コンソールナビゲーションで、Installed Operators > multicluster engine for Kubernetes を選択します。
- MultiCluster Engine タブを選択します。
- Create MultiClusterEngine を選択します。
YAML ファイルのデフォルト値を更新します。このドキュメントの MultiClusterEngine advanced configuration のオプションを参照してください。
- 次の例は、エディターにコピーできるデフォルトのテンプレートを示しています。
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: {}apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: {}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Create を選択して、カスタムリソースを初期化します。multicluster engine Operator エンジンがビルドされて起動するまで、最大 10 分かかる場合があります。
MultiClusterEngine リソースが作成されると、リソースのステータスが MultiCluster Engine タブで
Availableになります。
1.5.1.4. OpenShift Container Platform CLI からのインストール
Operator の要件を満たす、multicluster engine Operator エンジンの namespace を作成します。次のコマンドを実行します。
namespaceは、multicluster engine for Kubernetes Operator の namespace の名前です。namespaceの値は、OpenShift Container Platform 環境では プロジェクト と呼ばれる場合があります。oc create namespace <namespace>
oc create namespace <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロジェクトの namespace を、作成した namespace に切り替えます。
namespaceは、ステップ 1 で作成した multicluster engine for Kubernetes Operator の名前に置き換えます。oc project <namespace>
oc project <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroupリソースを設定するために YAML ファイルを作成します。namespace ごとに割り当てることができる Operator グループは 1 つだけです。defaultはお使いの operator グループ名に置き換えます。namespaceはお使いのプロジェクトの namespace 名に置き換えます。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
OperatorGroupリソースを作成します。operator-groupは、作成した operator グループの YAML ファイル名に置き換えます。oc apply -f <path-to-file>/<operator-group>.yaml
oc apply -f <path-to-file>/<operator-group>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform サブスクリプションを設定するための YAML ファイルを作成します。ファイルは次の例のようになります。
<stable-2.x>は、使用しているサポート対象のバージョンを表すものに変更してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: インフラストラクチャーノードを設定するには、multicluster engine Operator のインフラストラクチャーノードの設定 を参照してください。
=
+ .以下のコマンドを実行して OpenShift Container Platform サブスクリプションを作成します。subscription は、作成したサブスクリプションファイル名に置き換えます。
+
oc apply -f <path-to-file>/<subscription>.yaml
oc apply -f <path-to-file>/<subscription>.yamlYAML ファイルを作成して、
MultiClusterEngineカスタムリソースを設定します。デフォルトのテンプレートは、以下の例のようになります。apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: {}apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: {}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: インフラストラクチャーノードに multicluster engine Operator をインストールする場合は、MultiClusterEngine カスタムリソースの追加設定 セクションを参照してください。
次のコマンドを実行して、
MultiClusterEngineカスタムリソースを作成します。custom-resourceは、カスタムリソースファイル名に置き換えます。oc apply -f <path-to-file>/<custom-resource>.yaml
oc apply -f <path-to-file>/<custom-resource>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のエラーで、この手順に失敗した場合でも、リソースは作成され、適用されます。リソースが作成されてから数分後にもう一度コマンドを実行します。
error: unable to recognize "./mce.yaml": no matches for kind "MultiClusterEngine" in version "operator.multicluster-engine.io/v1"
error: unable to recognize "./mce.yaml": no matches for kind "MultiClusterEngine" in version "operator.multicluster-engine.io/v1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してカスタムリソースを編集します。次のコマンドを実行した後、
MultiClusterEngineカスタムリソースステータスがstatus.phaseフィールドにAvailableとして表示されるまでに最大 10 分かかる場合があります。oc get mce -o=jsonpath='{.items[0].status.phase}'oc get mce -o=jsonpath='{.items[0].status.phase}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
multicluster engine Operator を再インストールしても Pod が起動しない場合は、再インストールに失敗する場合のトラブルシューティング で、この問題を回避する手順を参照してください。
注記:
-
ClusterRoleBindingが指定されたServiceAccountは、multicluster engine Operator と、multicluster engine Operator をインストールする namespace にアクセスできるすべてのユーザー認証情報に、クラスター管理者権限を自動的に付与します。
承認された管理コンポーネントを実行するインフラストラクチャーノードを含むように OpenShift Container Platform クラスターを設定できるようになりました。インフラストラクチャーノードでコンポーネントを実行すると、それらの管理コンポーネントを実行しているノードの OpenShift Container Platform サブスクリプションクォータの割り当てる必要がなくなります。その手順は、multicluster engine Operator のインフラストラクチャーノードの設定 を参照してください。
1.5.2. multicluster engine Operator のインフラストラクチャーノードの設定
承認された multicluster engine Operator 管理コンポーネントを実行するインフラストラクチャーノードを含むように OpenShift Container Platform クラスターを設定します。インフラストラクチャーノードでコンポーネントを実行すると、multicluster engine Operator 管理コンポーネントを実行しているノードに OpenShift Container Platform サブスクリプションクォータが割り当てられることがなくなります。
OpenShift Container Platform クラスターにインフラストラクチャーノードを追加した後に、OpenShift Container Platform CLI からのインストール 手順に従い、以下の設定を Operator Lifecycle Manager サブスクリプションおよび MultiClusterEngine カスタムリソースに追加します。
1.5.2.1. OpenShift Container Platform クラスターへのインフラストラクチャーノードの設定
OpenShift Container Platform ドキュメントの インフラストラクチャーマシンセットの作成 で説明されている手順に従ってください。インフラストラクチャーノードは、Kubernetes の taint と labels を使用して設定され、管理以外のワークロードが実行されないようにします。
multicluster engine Operator によって提供されるインフラストラクチャーノードの有効化に対応できるように、インフラストラクチャーノードに次の taints と labels が適用されていることを確認します。
1.5.2.2. Operator Lifecycle Manager サブスクリプションの設定
Operator Lifecycle Manager サブスクリプションを設定します。
Operator Lifecycle Manager サブスクリプションを適用する前に、以下の追加設定を追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アドオンを更新して、次のノードセレクターと toleration を含めます。klusterlet アドオンの設定 手順を使用する必要があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Data Foundation をストレージプロビジョナーとして使用している場合は、Container Storage Interface Pod がインフラストラクチャーノードで実行できることを確認してください。詳細は、Red Hat OpenShift Data Foundation ドキュメントの Container Storage Interface (CSI) コンポーネントの配置の管理 を参照してください。
1.5.2.3. MultiClusterEngine カスタムリソースの追加設定
MultiClusterEngine カスタムリソースを適用する前に、以下の設定を追加します。
spec:
nodeSelector:
node-role.kubernetes.io/infra: ""
spec:
nodeSelector:
node-role.kubernetes.io/infra: ""1.5.3. ネットワーク切断状態でのインストール
場合によっては、インターネットに接続されていない Red Hat OpenShift Container Platform クラスターに multicluster engine Operator をインストールする必要があります。ネットワーク接続のないエンジンにインストールする手順でも一部、オンラインインストールと同じ手順が必要になります。
インストール時にネットワークから直接パッケージにアクセスするのではなく、パッケージをダウンロードしておき、インストール時にアクセスできるようにする必要があります。
1.5.3.1. 前提条件
multicluster engine Operator をインストールする前に、次の要件を満たす必要があります。
- サポートされている OpenShift Container Platform バージョンが環境にデプロイされていて、コマンドラインインターフェイス (CLI) を使用してログインしている。
catalog.redhat.com にアクセスできる。
注記: ベアメタルクラスターを管理するには、サポートされている OpenShift Container Platform バージョンが必要です。
OpenShift Container Platform のインストール を参照してください。
- namespace の作成が可能な Red Hat OpenShift Container Platform の権限を設定している。
- Operator の依存関係をダウンロードするために、インターネット接続のあるワークステーションが必要。
1.5.3.2. OpenShift Container Platform インストールの確認
- レジストリー、ストレージサービスなど、サポート対象の OpenShift Container Platform バージョンがクラスターにインストールされ、機能する状態である必要があります。OpenShift Container Platform の詳細は、OpenShift Container Platform のドキュメント を参照してください。
接続したら、次のコマンドを使用して OpenShift Container Platform Web コンソールにアクセスして確認します。
oc -n openshift-console get route console
oc -n openshift-console get route consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の出力例を参照してください。
console console-openshift-console.apps.new-name.purple-name.com console https reencrypt/Redirect None
console console-openshift-console.apps.new-name.purple-name.com console https reencrypt/Redirect NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例のコンソール URL は
https:// console-openshift-console.apps.new-coral.purple-chesterfield.comです。ブラウザーで URL を開き、結果を確認します。コンソール URL の表示が
console-openshift-console.router.default.svc.cluster.localの場合は、OpenShift Container Platform のインストール時にopenshift_master_default_subdomainを設定します。
1.5.3.3. 非接続環境でのインストール
重要: 必要なイメージをミラーリングレジストリーにダウンロードし、非接続環境で Operator をインストールする必要があります。ダウンロードがないと、デプロイメント時に ImagePullBackOff エラーが表示される可能性があります。
非接続環境に multicluster engine Operator をインストールするには、次の手順に従います。
ミラーレジストリーを作成します。ミラーレジストリーがまだない場合は、Red Hat OpenShift Container Platform ドキュメントの 非接続環境でのミラーリング トピックの手順を実行して作成します。
ミラーレジストリーがすでにある場合は、既存のレジストリーを設定して使用できます。
注記: ベアメタルの場合のみ、
install-config.yamlファイルに、接続なしのレジストリーの証明書情報を指定する必要があります。保護された非接続レジストリー内のイメージにアクセスするには、multicluster engine Operator がレジストリーにアクセスできるように、証明書情報を指定する必要があります。- レジストリーから証明書情報をコピーします。
-
エディターで
install-config.yamlファイルを開きます。 -
additionalTrustBundle: |のエントリーを検索します。 additionalTrustBundleの行の後に証明書情報を追加します。追加後の内容は以下の例のようになります。additionalTrustBundle: | -----BEGIN CERTIFICATE----- certificate_content -----END CERTIFICATE----- sshKey: >-
additionalTrustBundle: | -----BEGIN CERTIFICATE----- certificate_content -----END CERTIFICATE----- sshKey: >-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション: インストール後にホストにアクセスできるようにする 1 つまたは複数の SSH 公開鍵を指定できます。以下の例を参照してください。
sshKey: | ssh-rsa <public-key-1> ssh-rsa <public-key-2> ssh-rsa <public-key-3>
sshKey: | ssh-rsa <public-key-1> ssh-rsa <public-key-2> ssh-rsa <public-key-3>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要: 以下のガバナンスポリシーが必要な場合は、非接続イメージレジストリーの追加ミラーが必要です。
-
Container Security Operator ポリシー:
registry.redhat.io/quayソースでイメージを見つけます。 -
Compliance Operator ポリシー:
registry.redhat.io/complianceソースでイメージを見つけます。 Gatekeeper Operator ポリシー:
registry.redhat.io/gatekeeperソースでイメージを見つけます。3 つのすべての Operator は、以下のミラー一覧を参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Container Security Operator ポリシー:
-
install-config.yamlファイルを保存します。 mce-policy.yamlという名前のImageContentSourcePolicyを含む YAML ファイルを作成します。注記: 実行中のクラスターでこれを変更すると、すべてのノードのローリング再起動が実行されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力して ImageContentSourcePolicy ファイルを適用します。
oc apply -f mce-policy.yaml
oc apply -f mce-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワーク接続されていない Operator Lifecycle Manager の Red Hat Operator とコミュニティーの Operator を有効にします。
multicluster engine Operator は、Operator Lifecycle Manager Red Hat Operator カタログに含まれています。
- Red Hat Operator カタログの非接続 Operator Lifecycle Manager を設定します。Red Hat OpenShift Container Platform ドキュメントの ネットワークが制限された環境での Operator Lifecycle Manager の使用 の手順を実行します。
- Operator Lifecycle Manager カタログからの multicluster engine operator for Kubernetes のインストールを続行します。
必要な手順は、ネットワーク接続時のオンラインインストール を参照してください。
1.5.4. ポリシーを使用した非接続クラスターのアップグレード
MultiClusterHub Operator を使用してハブクラスターコンポーネントを管理、アップグレード、およびインストールする Red Hat Advanced Cluster Management for Kubernetes ハブクラスターがある場合は、Red Hat Advanced Cluster Management のポリシーで OpenShift Update Service を使用して、非接続環境の複数のクラスターをアップグレードできます。
OpenShift Update Service は、独立した Operator およびオペランドです。マネージドクラスターの利用可能なバージョンを監視し、そのバージョンを非接続環境におけるアップグレードで利用できるようにします。OpenShift Update Service は次のアクションを実行できます。
- オフラインのクラスター向けにいつアップグレードが利用できるかを監視します。
- グラフデータファイルを使用してアップグレード用にどの更新がローカルサイトにミラーリングされているかを特定します。
- コンソールを使用して、クラスターのアップグレードが利用可能であることを通知します。
- 前提条件
- 非接続ミラーレジストリーの準備
- OpenShift Update Service の Operator のデプロイ
- グラフデータの init コンテナーの構築
- ミラーリングされたレジストリーの証明書の設定
- OpenShift Update Service インスタンスのデプロイ
- オプション: デフォルトのレジストリーをオーバーライドするポリシーのデプロイ
- 非接続カタログソースをデプロイするためのポリシーのデプロイ
- マネージドクラスターのパラメーターを変更するためのポリシーのデプロイ
- 利用可能なアップグレードの表示
- チャネルの選択
- クラスターのアップグレード
- 関連情報
外部レジストリー CA 証明書の詳細は、OpenShift Container Platform ドキュメントの イメージレジストリーアクセス用の追加トラストストアの設定 を参照してください。
1.5.4.1. 前提条件
OpenShift Update Service を使用して非接続クラスターをアップグレードするには、以下の前提条件を満たす必要があります。
- Red Hat Advanced Cluster Management がインストールされている。Red Hat Advanced Cluster Management インストールおよびアップグレード に関するドキュメントを参照してください。
- 制限付きの OLM が設定されたサポート対象の Red Hat OpenShift Container Platform バージョンで実行されているハブクラスター。制限付きの OLM の設定方法は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。制限付きの OLM を設定するときに、カタログソースイメージをメモしてください。
- ハブクラスターが管理する OpenShift Container Platform クラスター。
クラスターイメージをミラーリングできるローカルリポジトリーへのアクセス認証情報が必要です。詳細は、非接続環境のミラーリング を参照してください。
注記: アップグレードするクラスターの現在のバージョンのイメージを、ミラーリングされたイメージの 1 つとして、引き続き利用できるようにしておく必要があります。アップグレードが失敗した場合、クラスターはアップグレードを試行したときのバージョンに戻ります。
1.5.4.2. 非接続ミラーレジストリーの準備
ローカルのミラーリングレジストリーに、アップグレード前の現行のイメージと、アップグレード後のイメージの療法をミラーリングする必要があります。
イメージをミラーリングするには以下の手順を実行します。
次の例のような内容を含むスクリプトファイルを作成します。
<pull-secret>は、OpenShift Container Platform プルシークレットへのパスに置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - スクリプトを実行して、イメージのミラーリング、設定の設定、リリースイメージとリリースコンテンツの分離を行います。
1.5.4.3. OpenShift Update Service の Operator のデプロイ
OpenShift Container Platform 環境で OpenShift Update Service の Operator をデプロイするには、以下の手順を実行します。
- ハブクラスターで、OpenShift Container Platform の Operator ハブにアクセスします。
-
OpenShift Update Service Operatorを選択して Operator をデプロイし、必要に応じてデフォルト値を更新します。Operator をデプロイすると、openshift-update-serviceという名前の新しいプロジェクトが作成されます。 - Operator のインストールが完了するまで待ちます。
oc get pods コマンドを実行すると、インストールのステータスを確認できます。Operator の状態が running であることを確認します。
1.5.4.4. グラフデータの init container のビルド
OpenShift Update Service はグラフデータ情報を使用して、利用可能なアップグレードを検索します。インターネット接続環境では、OpenShift Update Service は利用可能なアップグレードのグラフデータ情報を update-service グラフデータの GitHub リポジトリー から直接取得します。
非接続環境では、init container を使用して、グラフデータをローカルリポジトリーで利用できるようにする必要があります。
以下の手順を実行して、グラフデータの init container を作成します。
次のコマンドを実行して、グラフデータ の Git リポジトリーをクローンします。
git clone https://github.com/openshift/cincinnati-graph-data
git clone https://github.com/openshift/cincinnati-graph-dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow グラフデータの
initの情報が含まれるファイルを作成します。cincinnati-operatorGitHub リポジトリーにサンプルの Dockerfile があります。-
FROM値は、OpenShift Update Service がイメージを検索する先の外部レジストリーに置き換えます。 -
RUNコマンドはディレクトリーを作成し、アップグレードファイルをパッケージ化します。 -
CMDコマンドは、パッケージファイルをローカルリポジトリーにコピーして、ファイルをデプロイメントしてアップグレードします。
-
次のコマンドを実行して
graph data init containerをビルドします。podman build -f <docker-path> -t <graph-path>:latest
podman build -f <docker-path> -t <graph-path>:latestCopy to Clipboard Copied! Toggle word wrap Toggle overflow <docker-path>は、前のステップで作成したファイルへのパスに置き換えます。<graph-path>は、ローカルのグラフデータ init container へのパスに置き換えます。次のコマンドを実行して
graph data init containerをプッシュします。podman push <graph-path>:latest --authfile=<pull-secret>.json
podman push <graph-path>:latest --authfile=<pull-secret>.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow <graph-path>は、ローカルのグラフデータ init container へのパスに置き換えます。<pull-secret>は、プルシークレットファイルへのパスに置き換えます。
オプション: podman がインストールされていない場合は、ステップ 3 と 4 の podman を docker に置き換えます。
1.5.4.5. ミラーリングされたレジストリーの証明書の設定
セキュアな外部コンテナーレジストリーを使用してミラーリングされた OpenShift Container Platform リリースイメージを保存する場合は、アップグレードグラフをビルドするために OpenShift Update Service からこのレジストリーへのアクセス権が必要です。
OpenShift Update Service Pod と連携するように CA 証明書を設定するには、以下の手順を実行します。
-
image.config.openshift.ioにある OpenShift Container Platform 外部レジストリー API を検索します。これは、外部レジストリーの CA 証明書の保存先です。詳細は、関連情報セクションの イメージレジストリーアクセス用の追加トラストストアの設定 を参照してください。 openshift-confignamespace に ConfigMap を作成し、updateservice-registryセクションに CA 証明書を追加します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow image.config.openshift.ioAPI のclusterリソースを編集して、additionalTrustedCAフィールドを作成した ConfigMap 名に設定します。次のコマンドを実行し、<trusted_ca>を新しい ConfigMap へのパスに置き換えます。oc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"<trusted_ca>"}}}' --type mergeoc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"<trusted_ca>"}}}' --type mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
image.config.openshift.io API と、openshift-config namespace に作成した ConfigMap の変更は、OpenShift Update Service Operator によって監視されています。CA 証明書が変更されると、デプロイメントが再起動されます。
1.5.4.6. OpenShift Update Service インスタンスのデプロイ
ハブクラスターへの OpenShift Update Service インスタンスのデプロイを完了すると、そのインスタンスは、クラスターアップグレード用のイメージがミラーリングされる場所に配置され、非接続のマネージドクラスターで使用できるようになります。
インスタンスをデプロイするには、以下の手順を実行します。
- Operator のデフォルトの namespace を使用しない場合は、コンソールで Administration > Namespaces に移動して変更します。
- OpenShift Container Platform コンソールの Installed Operator セクションで、OpenShift Update Service Operator を選択します。
- メニューから Create Instance を選択します。
OpenShift Update Service インスタンスからコンテンツを貼り付けます。YAML ファイルは以下のマニフェストのようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Create を選択してインスタンスを作成します。
-
ハブクラスター CLI で
oc get podsコマンドを入力し、インスタンス作成のステータスを表示します。
これには数分かかる場合があります。コマンドの結果にインスタンスと Operator が実行中であることが示されたら、プロセスは完了です。
1.5.4.7. オプション: デフォルトのレジストリーをオーバーライドするポリシーのデプロイ
次の手順は、ミラーリングされたレジストリーにリリースをミラーリングした場合にのみ適用されます。
非推奨: PlacementRule
OpenShift Container Platform にはイメージレジストリーのデフォルト値があり、この値でアップグレードパッケージの検索先を指定します。非接続環境では、リリースイメージをミラーリングするローカルイメージレジストリーへのパスに値を置き換えるポリシーを作成してください。
ポリシーを作成するには、以下の手順を実行します。
- ハブクラスターの OpenShift Container Platform 環境にログインします。
- コンソールから、Governance > Create policy を選択します。
- YAML スイッチを On に設定して、ポリシーの YAML バージョンを表示します。
- YAML コードのコンテンツをすべて削除します。
以下の YAML コンテンツをウィンドウに貼り付け、カスタムポリシーを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Enforce if supported を選択します。
- Create を選択してポリシーを作成します。
1.5.4.8. 非接続カタログソースをデプロイするためのポリシーのデプロイ
Catalogsource ポリシーをマネージドクラスターにプッシュすると、デフォルトの場所を、インターネットに接続された場所から非接続のローカルレジストリーに変更できます。
デフォルトの場所を変更するには、次の手順を実行します。
- コンソールメニューで、Governance > Create policy を選択します。
-
YAMLスイッチを On に設定して、ポリシーの YAML バージョンを表示します。 -
YAMLコードのコンテンツをすべて削除します。 以下の
YAMLコンテンツをウィンドウに貼り付け、カスタムポリシーを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Enforce if supported を選択します。
- Create を選択してポリシーを作成します。
1.5.4.9. マネージドクラスターのパラメーターを変更するためのポリシーのデプロイ
ClusterVersion ポリシーをマネージドクラスターにプッシュすると、クラスターのアップグレードの取得先となるデフォルトの場所を変更できます。
以下の手順を実行します。
マネージドクラスターから次のコマンドを実行して、ClusterVersion アップストリームパラメーターが、現在デフォルトのパブリック OpenShift Update Service オペランドになっていることを確認します。
oc get clusterversion -o yaml
oc get clusterversion -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターから次のコマンドを実行して、OpenShift Update Service オペランドへのルート URL を特定します。
oc get routes
oc get routesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 後の手順のために、結果を記録しておきます。
- ハブクラスターのコンソールメニューで、Governance > Create a policy を選択します。
-
YAMLスイッチを On に設定して、ポリシーの YAML バージョンを表示します。 -
YAMLコードのコンテンツをすべて削除します。 以下の
YAMLコンテンツをウィンドウに貼り付け、カスタムポリシーを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ハブクラスターの OpenShift Update Service オペランドへのパスに置き換えます。指定されていない場合は、すべてのクラスターが選択されます。
以下の手順を実行すると、オペランドへのパスを確認できます。
-
ハブクラスターで
oc get routes -Aコマンドを実行します。 update-serviceへのルートを確認します。オペランドへのパスは、
HOST/PORTフィールドの値です。
- Enforce if supported を選択します。
- Create を選択してポリシーを作成します。
マネージドクラスターの CLI で次のコマンドを実行して、
ClusterVersionのアップストリームパラメーターが、ローカルハブクラスターの OpenShift Update Service URL で更新されていることを確認します。oc get clusterversion -o yaml
oc get clusterversion -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 結果は、以下の内容のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.5.4.10. 利用可能なアップグレードの表示
以下の手順を実行して、マネージドクラスターで利用可能なアップグレード一覧を確認します。
- コンソールで、Infrastructure > Clusters を選択します。
- 状態が Ready のクラスターを選択します。
- Actions メニューから Upgrade cluster を選択します。
- オプションのアップグレードパスが利用可能であることを確認します。
注記: 現行バージョンがローカルのイメージリポジトリーにミラーリングされていないと、利用可能なアップグレードバージョンは表示されません。
1.5.4.11. チャネルの選択
Red Hat Advanced Cluster Management コンソールを使用して、OpenShift Container Platform でのクラスターアップグレード用のチャネルを選択できます。これらのバージョンはミラーレジストリーで利用可能である必要があります。
チャネルの選択 の手順を実行して、アップグレードチャネルを指定します。
1.5.4.12. クラスターのアップグレード
非接続レジストリーを設定すると、Red Hat Advanced Cluster Management と OpenShift Update Service が非接続レジストリーを使用して、アップグレードが利用可能かどうかを確認します。
利用可能なアップグレードが表示されない場合は、クラスターの現行のリリースイメージと、1 つ後のイメージがローカルリポジトリーにミラーリングされていることを確認します。
クラスターの現行バージョンのリリースイメージが利用できないと、アップグレードは利用できません。
以下の手順を実行してアップグレードします。
- コンソールで、Infrastructure > Clusters を選択します。
- 利用可能なアップグレードがある場合は、選択するクラスターを見つけます。
- アップグレードが利用可能な場合は、クラスターの Distribution version 列にアップグレードが利用可能であることが表示されます。
- クラスターの Options メニュー、Upgrade cluster の順に選択します。
- アップグレードのターゲットバージョン、Upgrade の順に選択します。
クラスターのアップグレードに失敗すると、Operator は通常アップグレードを数回再試行し、停止し、コンポーネントに問題があるステータスを報告します。場合によっては、アップグレードプロセスは、プロセスの完了を繰り返し試行します。アップグレードが失敗した後にクラスターを以前のバージョンにロールバックすることはサポートされていません。クラスターのアップグレードに失敗した場合は、Red Hat サポートにお問い合わせください。
1.5.4.12.1. 関連情報
外部レジストリー CA 証明書の詳細は、OpenShift Container Platform ドキュメントの イメージレジストリーアクセス用の追加トラストストアの設定 を参照してください。
1.5.5. 詳細設定
multicluster engine Operator は、必要なすべてのコンポーネントをデプロイする Operator を使用してインストールされます。multicluster engine Operator は、インストール中またはインストール後にさらに設定できます。ここでは、詳細設定オプションを説明します。
1.5.5.1. デプロイされるコンポーネント
次の属性を 1 つ以上 MultiClusterEngine カスタムリソースに追加します。
| 名前 | 説明 | 有効 |
| assisted-service | 最小限のインフラストラクチャー前提条件と包括的なプリフライト検証を使用して OpenShift Container Platform をインストールします。 | True |
| cluster-api | マネージドクラスター内からクラスター API ライフサイクルを処理する機能を提供します。 | False |
| cluster-api-provider-aws | AWS のクラスターを作成、設定、管理するための Kubernetes スタイルの API を提供します。 | False |
| cluster-api-provider-openshift-assisted-preview | Assisted Installer によるクラスターの作成、設定、管理のための Kubernetes スタイルの API を提供します。 | False |
| cluster-api-provider-metal3-preview | ベアメタルインフラストラクチャー上でのクラスターの作成、設定、管理のための Kubernetes スタイルの API を提供します。 | False |
| cluster-lifecycle | OpenShift Container Platform および Kubernetes ハブクラスターにクラスター管理機能を提供します。 | True |
| cluster-manager | クラスター環境内のさまざまなクラスター関連操作を管理します。 | True |
| cluster-proxy-addon |
リバースプロキシーサーバーを使用して、ハブクラスターとマネージドクラスター両方での | True |
| console-mce | multicluster engine Operator コンソールのプラグインを有効にします。 | True |
| discovery | OpenShift Cluster Manager 内の新しいクラスターを検出して識別します。 | True |
| hive | OpenShift Container Platform クラスターの初期設定をプロビジョニングして実行します。 | True |
| hypershift | コストと時間の効率性、クラウド間の移植性を備えた OpenShift Container Platform コントロールプレーンを大規模にホストします。 | True |
| hypershift-local-hosting | ローカルクラスター環境内でのローカルホスティング機能を有効にします。 | True |
| image-based-install-operator | インストールを完了するために、シングルノード OpenShift クラスターにサイト設定を提供します。 | False |
| local-cluster | multicluster engine Operator がデプロイされるローカルハブクラスターのインポートと自己管理を有効にします。 | True |
| managedserviceacccount | サービスアカウントをマネージドクラスターに同期し、トークンをシークレットリソースとして収集してハブクラスターに返します。 | True |
| server-foundation | マルチクラスター環境内のサーバー側操作のための基本的なサービスを提供します。 | True |
multicluster engine Operator をクラスターにインストールする場合、上記のコンポーネントすべてがデフォルトで有効になるわけではありません。
MultiClusterEngine カスタムリソースに 1 つ以上の属性を追加することで、インストール中またはインストール後に multicluster engine Operator をさらに設定できます。追加できる属性は、このまま読み進めてください。
1.5.5.2. コンソールとコンポーネントの設定
次の例では、コンポーネントを有効または無効にするために使用できる spec.overrides デフォルトテンプレートを表示します。
-
nameをコンポーネントの名前に置き換えます。
あるいは、以下のコマンドを実行します。namespace プロジェクトの名前に置き換え、name をコンポーネントの名前に置き換えます。
oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"<name>","enabled":true}}]'
oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"<name>","enabled":true}}]'1.5.5.3. local-cluster の有効化
デフォルトでは、multicluster engine Operator を実行しているクラスターは ローカルクラスター です。これは、自身を管理するハブクラスターであり、クラスターのリストでは local-cluster として指定されます。
MultiClusterEngine リソースでは、ローカルクラスター名は spec.localClusterName 値から設定されます。enabled 設定は、機能を有効にするか無効にするかを指定します。
enabled: true 設定はクラスターを local-cluster として指定しますが、enabled: false 設定は指定しません。local-cluster が enabled: true 値で有効になっている次のサンプルを参照してください。
enabled フィールドが false に設定されている場合は、local-cluster 名を変更できます。<your-local-cluster-name> 値には 34 文字以下を使用する必要があります。local-cluster が enabled: true に設定されている場合、名前を変更できません。
multicluster engine Operator を local-cluster として 指定せずに インストールするには、spec.overrides.components 設定を enabled: false に変更します。以下の YAML 例を参照してください。
1.5.5.4. カスタムイメージプルシークレット
OpenShift Container Platform または multicluster engine Operator によって作成されていない Kubernetes クラスターをインポートする予定の場合は、配布レジストリーから権限のあるコンテンツにアクセスするために、OpenShift Container Platform プルシークレット情報を含むシークレットを生成します。
OpenShift Container Platform クラスターのシークレット要件は、OpenShift Container Platform および multicluster engine for Kubernetes Operator によって自動的に解決されます。そのため、管理対象とする他のタイプの Kubernetes クラスターをインポートしない場合は、シークレットを作成する必要はありません。
重要: これらのシークレットは namespace に依存するため、エンジンに使用する namespace にいることを確認してください。
- cloud.redhat.com/openshift/install/pull-secret から Download pull secret を選択して、OpenShift Container Platform のプルシークレットファイルをダウンロードします。OpenShift Container Platform プルシークレットは Red Hat カスタマーポータル ID に関連しており、すべての Kubernetes プロバイダーで同じです。
以下のコマンドを実行してシークレットを作成します。
oc create secret generic <secret> -n <namespace> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson
oc create secret generic <secret> -n <namespace> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
secretは作成するシークレット名に置き換えます。 -
シークレットは namespace 固有であるため、
namespaceはプロジェクトの namespace に置き換えます。 -
path-to-pull-secretはダウンロードした OpenShift Container Platform のプルシークレットへのパスに置き換えます。
-
以下の例では、カスタムプルシークレットを使用する場合に使用する spec.imagePullSecret テンプレートを表示しています。secret は、プルシークレット名に置き換えます。
1.5.5.5. ターゲット namespace
MultiClusterEngine カスタムリソースで場所を指定することにより、指定された namespace にオペランドをインストールできます。この namespace は、MultiClusterEngine カスタムリソースの適用時に作成されます。
重要: ターゲット namespace が指定されていない場合、Operator は multicluster-engine namespace にインストールし、MultiClusterEngine カスタムリソース仕様で設定します。
次の例は、ターゲット namespace を指定するために使用できる spec.targetNamespace テンプレートを示しています。target を宛先 namespace の名前に置き換えます。注記: target namespace を default namespace にすることはできません。
1.5.5.6. availabilityConfig
ハブクラスターには、High と Basic の 2 つの可用性があります。デフォルトでは、ハブクラスターには High の可用性があります。これにより、ハブクラスターコンポーネントに replicaCount 2 が提供されます。これにより、フェイルオーバー時のサポートが向上しますが、Basic 可用性よりも多くのリソースを消費します。これにより、コンポーネントには replicaCount 1 が提供されます。
重要: シングルノード OpenShift クラスターで multicluster engine Operator を使用している場合は、spec.availabilityConfig を Basic に設定してください。
以下の例は、Basic の可用性のある spec.availabilityConfig テンプレートを示しています。
1.5.5.7. nodeSelector
MultiClusterEngine でノードセレクターのセットを定義して、クラスター上の特定のノードにインストールできます。次の例は、ラベル node-role.kubernetes.io/infra を持つノードに Pod を割り当てる spec.nodeSelector を示しています。
spec:
nodeSelector:
node-role.kubernetes.io/infra: ""
spec:
nodeSelector:
node-role.kubernetes.io/infra: ""Red Hat Advanced Cluster Management for Kubernetes ハブクラスターのノードセレクターのセットを定義するには、Red Hat Advanced Cluster Management ドキュメントの nodeSelector を参照してください。
1.5.5.8. tolerations
許容範囲のリストを定義して、MultiClusterEngine がクラスターで定義された特定の taint を許容できるようにすることができます。以下の例は、node-role.kubernetes.io/infra taint に一致する spec.tolerations を示しています。
spec:
tolerations:
- key: node-role.kubernetes.io/infra
effect: NoSchedule
operator: Exists
spec:
tolerations:
- key: node-role.kubernetes.io/infra
effect: NoSchedule
operator: Exists以前の infra-node toleration は、設定に toleration を指定せずにデフォルトで Pod に設定されます。設定で許容値をカスタマイズすると、このデフォルトの動作が置き換えられます。
Red Hat Advanced Cluster Management for Kubernetes ハブクラスターの toleration リストを定義するには、Red Hat Advanced Cluster Management ドキュメントの tolerations を参照してください。
1.5.5.9. ManagedServiceAccount アドオン
ManagedServiceAccount アドオンを使用すると、マネージドクラスターでサービスアカウントを作成または削除できます。このアドオンを有効にしてインストールするには、spec.overrides の MultiClusterEngine 仕様に以下を含めます。
ManagedServiceAccount アドオンは、MultiClusterEngine の作成後にコマンドラインでリソースを編集し、managedserviceaccount コンポーネントを enabled: true に設定することで有効にできます。または、次のコマンドを実行して、<multiclusterengine-name> を MultiClusterEngine リソースの名前に置き換えることもできます。
oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"managedserviceaccount","enabled":true}}]'
oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"managedserviceaccount","enabled":true}}]'1.5.6. アンインストール
multicluster engine for Kubernetes Operator のアンインストールには、カスタムリソースの削除 と 完全な Operator アンインストール という 2 つの異なるレベルのプロセスがあります。アンインストールプロセスの完了に最長 5 分かかる可能性があります。
-
カスタムリソースの削除は、最も基本的なアンインストールの種類で、
MultiClusterEngineインスタンスのカスタムリソースを削除しますが、他の必要なコンポーネントが残されたままになります。このレベルのアンインストールは、同じ設定とコンポーネントを使用して再インストールする予定の場合に役立ちます。 - 2 番目のレベルは、より完全なアンインストールで、カスタムリソース定義などのコンポーネントを除き、ほとんどの Operator コンポーネントを削除します。この手順を続行すると、カスタムリソースの削除で削除されていないコンポーネントおよびサブスクリプションがすべて削除されます。アンインストールが済むと、カスタムリソースの前に Operator を再インストールする必要があります。
1.5.6.1. 前提条件: 有効化されたサービスのデタッチ
multicluster engine for Kubernetes Operator をアンインストールする前に、そのエンジンによって管理されているすべてのクラスターをデタッチする必要があります。エラーを回避するには、エンジンによって管理されているすべてのクラスターをデタッチしてから、アンインストールを再試行してください。
マネージドクラスターがアタッチされている場合は、以下のメッセージが表示される可能性があります。
Cannot delete MultiClusterEngine resource because ManagedCluster resource(s) exist
Cannot delete MultiClusterEngine resource because ManagedCluster resource(s) existCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのデタッチの詳細は、クラスターの作成 でお使いのプロバイダーの情報を選択して、管理からのクラスターの削除 セクションを参照してください。
1.5.6.2. コマンドを使用したリソースの削除
-
まだの場合には、
ocコマンドが実行できるように、OpenShift Container Platform CLI が設定されていることを確認してください。ocコマンドの設定方法の詳細は、OpenShift Container Platform ドキュメントの OpenShift CLI の使用を開始 を参照してください。 以下のコマンドを入力してプロジェクトの namespace に移動します。namespace はお使いのプロジェクトの namespace 名に置き換えます。
oc project <namespace>
oc project <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
MultiClusterEngineカスタムリソースを削除します。oc delete multiclusterengine --all
oc delete multiclusterengine --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力して進捗を表示できます。
oc get multiclusterengine -o yaml
oc get multiclusterengine -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
次のコマンドを入力して、インストール先の namespace にある multicluster-engine の
ClusterServiceVersionを削除します。v2.x.0変数はバージョンに置き換えます。
ここに表示されている CSV バージョンは異なる場合があります。
1.5.6.3. コンソールを使用したコンポーネントの削除
Red Hat OpenShift Container Platform コンソールを使用してアンインストールする場合に、Operator を削除します。コンソールを使用してアンインストールを行うには、以下の手順を実行します。
- OpenShift Container Platform コンソールナビゲーションで、Operators > Installed Operators > multicluster engine for Kubernetes を選択します。
MultiClusterEngineカスタムリソースを削除します。- Multiclusterengine のタブを選択します。
- MultiClusterEngine カスタムリソースの Options メニューを選択します。
- Delete MultiClusterEngine を選択します。
次のセクションの手順に従って、クリーンアップスクリプトを実行します。
ヒント: 同じ multicluster engine for Kubernetes Operator バージョンを再インストールする場合は、この手順の残りのステップをスキップして、カスタムリソースを再インストールできます。
- Installed Operators に移動します。
- Options メニューから Uninstall operator を選択して、_ multicluster engine for Kubernetes_ Operator を削除してください。
1.5.6.4. アンインストールのトラブルシューティング
マルチクラスターエンジンのカスタムリソースが削除されていない場合は、クリーンアップスクリプトを実行して、残っている可能性のあるアーティファクトをすべて削除します。
以下のスクリプトをファイルにコピーします。
#!/bin/bash oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io oc delete validatingwebhookconfiguration multiclusterengines.multicluster.openshift.io oc delete mce --all
#!/bin/bash oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io oc delete validatingwebhookconfiguration multiclusterengines.multicluster.openshift.io oc delete mce --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow
詳細は、非接続環境のミラーリング を参照してください。
1.6. 認証情報の管理
multicluster engine Operator を使用して、クラウドサービスプロバイダー上で Red Hat OpenShift Container Platform クラスターを作成および管理するには、認証情報 が必要です。認証情報では、クラウドプロバイダーのアクセス情報を保存します。1 つのプロバイダーのドメインごとに独自の認証情報が必要になるのと同様に、プロバイダーアカウントごとに独自の認証情報が必要です。
クラスターの認証情報を作成して管理できます。認証情報は Kubernetes Secret として保存されます。シークレットはマネージドクラスターの namespace にコピーされ、マネージドクラスターのコントローラーがシークレットにアクセスできるようになります。認証情報が更新されると、シークレットのコピーはマネージドクラスターの namespace で自動的に更新されます。
注記: クラウドプロバイダーの認証情報のプルシークレット、SSH キー、またはベースドメインへの変更は、元の認証情報を使用してすでにプロビジョニングされているため、既存のマネージドクラスターには反映されません。
必要なアクセス権限: 編集
1.6.1. Amazon Web Services の認証情報の作成
multicluster engine Operator コンソールを使用して、Amazon Web Services (AWS) 上で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。
必要なアクセス権限: 編集
注記: この手順は、multicluster engine Operator でクラスターを作成する前に実行する必要があります。
1.6.1.1. 前提条件
認証情報を作成する前に、以下の前提条件を満たす必要があります。
- デプロイされた multicluster engine Operator ハブクラスター
- multicluster engine Operator ハブクラスターのインターネットアクセス。これは、Amazon Web Services (AWS) 上に Kubernetes クラスターを作成できるようにするために必要です。
- アクセスキー ID およびシークレットアクセスキーなど、AWS のログイン認証情報。Understanding and getting your security credentials を参照してください。
- AWS でクラスターをインストールできるようにするアカウントの権限。Configuring an AWS account は、AWS アカウントの設定を参照してください。
1.6.1.2. コンソールを使用した認証情報の管理
multicluster engine Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。
ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 利便性とセキュリティー強化のために、認証情報をホストする専用の namespace を作成します。
オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。以下の手順を参照してください。
- AWS アカウントの AWS アクセスキー ID を追加します。ID を確認するには、Log in to AWS を参照してください。
- 新しい AWS Secret Access Key の内容を提供します。
プロキシーを有効にする必要がある場合は、プロキシー情報を入力します。
-
HTTP プロキシー URL:
HTTPトラフィックのプロキシーとして使用する URL。 -
HTTPS プロキシー URL:
HTTPSトラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URLと同じ値がHTTPおよびHTTPSの両方に使用されます。 -
プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
-
HTTP プロキシー URL:
- Red Hat OpenShift プルシークレットを入力します。プルシークレットをダウンロードするには、Download your Red Hat OpenShift pull secret を参照してください。
- SSH 秘密鍵 と SSH 公開鍵 を追加し、クラスターに接続できるようにします。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。
Amazon Web Services でのクラスターの作成 または Amazon Web Services GovCloud でのクラスターの作成 の手順を完了することで、この認証情報を使用するクラスターを作成できます。
コンソールで認証情報を編集できます。このプロバイダー接続を使用してクラスターが作成された場合には、<cluster-namespace> からの <cluster-name>-aws-creds> シークレットが新規の認証情報に更新されます。
注記: クラスタープールが要求したクラスターでは、認証情報は更新されません。
認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。
1.6.1.2.1. S3 シークレットの作成
Amazon Simple Storage Service (S3) シークレットを作成するには、コンソールから次のタスクを実行します。
- Add credential > AWS > S3 Bucket をクリックします。For Hosted Control Plane の場合をクリックすると、名前とネームスペースが提供されます。
表示される次のフィールドに情報を入力します。
-
bucket name: S3 バケットの名前を追加します。 -
aws_access_key_id: AWS アカウントの AWS アクセスキー ID を追加します。AWS にログインして ID を見つけます。 -
aws_secret_access_key: 新しい AWS シークレットアクセスキーの内容を指定します。 -
Region: AWS リージョンを入力します。
-
1.6.1.3. API を使用した不透明なシークレットの作成
API を使用して Amazon Web Services の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。
注記:
- 不透明なシークレットはコンソールに表示されません。
- 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。
-
ラベルを認証情報に追加して、コンソールでシークレットを表示します。たとえば、以下の AWS S3 Bucket
oc label secretにtype=awss3およびcredentials --from-file=….が追加されます。
oc label secret hypershift-operator-oidc-provider-s3-credentials -n <your-local-cluster-name> "cluster.open-cluster-management.io/type=awss3" oc label secret hypershift-operator-oidc-provider-s3-credentials -n <your-local-cluster-name> "cluster.open-cluster-management.io/credentials=credentials="
oc label secret hypershift-operator-oidc-provider-s3-credentials -n <your-local-cluster-name> "cluster.open-cluster-management.io/type=awss3"
oc label secret hypershift-operator-oidc-provider-s3-credentials -n <your-local-cluster-name> "cluster.open-cluster-management.io/credentials=credentials="1.6.1.4. 関連情報
- Understanding and getting your security credentials を参照してください。
- AWS へのインストール を参照してください。
- AWS にログインします。
- Red Hat OpenShift プルシークレットをダウンロードします。
- キーの生成方法の詳細は、AWS のインストール設定パラメーター を参照してください。
- Amazon Web Services でのクラスターの作成 を参照してください。
- Amazon Web Services GovCloud でのクラスターの作成 を参照してください。
- Amazon Web Services の認証情報の作成 に戻ります。
1.6.2. Microsoft Azure の認証情報の作成
multicluster engine Operator コンソールを使用して、Microsoft Azure または Microsoft Azure Government 上で Red Hat OpenShift Container Platform クラスターを作成および管理するには、認証情報が必要です。
必要なアクセス権限: 編集
注記: この手順は、multicluster engine Operator を使用してクラスターを作成するための前提条件です。
1.6.2.1. 前提条件
認証情報を作成する前に、以下の前提条件を満たす必要があります。
- デプロイされた multicluster engine Operator ハブクラスター。
- multicluster engine Operator ハブクラスターのインターネットアクセス。これは、Azure 上に Kubernetes クラスターを作成できるようにするために必要です。
- ベースドメインのリソースグループおよび Azure Service Principal JSON などの Azure ログイン認証情報。ログイン認証情報を取得するには、Microsoft Azure ポータル を参照してください。
- Azure でクラスターがインストールできるようにするアカウントの権限。詳細は、How to configure Cloud Services および Azure アカウントの設定 を参照してください。
1.6.2.2. コンソールを使用した認証情報の管理
multicluster engine Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 利便性とセキュリティー強化のために、認証情報をホストする専用の namespace を作成します。
- オプション: 認証情報の ベース DNS ドメイン を追加します。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。
-
クラスターの環境が
AzurePublicCloudまたは、AzureUSGovernmentCloudであるかを選択します。この設定は Azure Government 環境とは異なるため、これが正しく設定されていることを確認します。 - Azure アカウントの ベースドメインリソースグループ名 を追加します。このエントリーは、Azure アカウントで作成したリソース名です。Azure インターフェイスで Home > DNS Zones を選択することで、ベースドメインのリソースグループ名を検索できます。ベースドメインリソースグループ名を見つけるには、Create an Azure service principal with the Azure CLI を参照してください。
クライアント ID の内容を入力します。この値は、以下のコマンドを使用してサービスプリンシパルを作成すると、
appIdプロパティーとして設定されます。az ad sp create-for-rbac --role Contributor --name <service_principal> --scopes <subscription_path>
az ad sp create-for-rbac --role Contributor --name <service_principal> --scopes <subscription_path>Copy to Clipboard Copied! Toggle word wrap Toggle overflow service_principal は、お使いのサービスプリンシパル名に置き換えます。
Client Secret を追加します。この値は、以下のコマンドを使用してサービスプリンシパルを作成すると、
passwordプロパティーとして設定されます。az ad sp create-for-rbac --role Contributor --name <service_principal> --scopes <subscription_path>
az ad sp create-for-rbac --role Contributor --name <service_principal> --scopes <subscription_path>Copy to Clipboard Copied! Toggle word wrap Toggle overflow service_principal は、お使いのサービスプリンシパル名に置き換えます。
Subscription ID を追加します。以下のコマンドの出力では、この値は、
idプロパティーになります。az account show
az account showCopy to Clipboard Copied! Toggle word wrap Toggle overflow Tenant ID を追加します。以下のコマンドの出力では、この値は、
tenantIdプロパティーになります。az account show
az account showCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーを有効にする場合は、プロキシー情報を入力します。
-
HTTP プロキシー URL:
HTTPトラフィックのプロキシーとして使用する URL。 -
HTTPS プロキシー URL:
HTTPSトラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URLと同じ値がHTTPおよびHTTPSの両方に使用されます。 -
プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
-
HTTP プロキシー URL:
- Red Hat OpenShift pull secret を入力します。プルシークレットをダウンロードするには、Download your Red Hat OpenShift pull secret を参照してください。
- クラスターへの接続に使用する SSH 秘密鍵 と SSH 公開鍵 を追加します。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。
Microsoft Azure でのクラスターの作成 の手順を実行して、この認証情報を使用するクラスターを作成します。
コンソールで認証情報を編集できます。
認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。
1.6.2.3. API を使用した不透明なシークレットの作成
コンソールの代わりに API を使用して Microsoft Azure の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。
注記:
- 不透明なシークレットはコンソールに表示されません。
- 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。
1.6.2.4. 関連情報
- Microsoft Azure Portal を参照してください。
- クラウドサービスの設定方法 を参照してください。
- Azure アカウントの設定 を参照してください。
- ベースドメインリソースグループ名を見つけるには、Create an Azure service principal with the Azure CLI を参照してください。
- Red Hat OpenShift プルシークレットをダウンロードします。
- キーを生成する方法の詳細は、クラスターノード SSH アクセス用のキーペアの生成 を参照してください。
- Microsoft Azure でのクラスターの作成 を参照してください。
- Microsoft Azure の認証情報の作成 に戻ります。
1.6.3. Google Cloud Platform の認証情報の作成
multicluster engine Operator コンソールを使用して、Google Cloud Platform (GCP) 上で Red Hat OpenShift Container Platform クラスターを作成および管理するには、認証情報が必要です。
必要なアクセス権限: 編集
注記: この手順は、multicluster engine Operator を使用してクラスターを作成するための前提条件です。
1.6.3.1. 前提条件
認証情報を作成する前に、以下の前提条件を満たす必要があります。
- デプロイされた multicluster engine Operator ハブクラスター
- multicluster engine Operator ハブクラスターのインターネットアクセス。これは、GCP 上に Kubernetes クラスターを作成できるようにするために必要です。
- ユーザーの Google Cloud Platform プロジェクト ID および Google Cloud Platform サービスアカウント JSON キーなど、GCP ログインの認証情報。Creating and managing projects を参照してください。
- GCP でクラスターがインストールできるようにするアカウントの権限。アカウントの設定方法は、GCP プロジェクトの設定 を参照してください。
1.6.3.2. コンソールを使用した認証情報の管理
multicluster engine Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。
ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 利便性とセキュリティー強化のために、認証情報をホストする専用の namespace を作成します。
オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。以下の手順を参照してください。
- GCP アカウントの Google Cloud Platform project ID を追加します。設定を取得するには、Log in to GCP を参照してください。
- Google Cloud Platform service account JSON key を追加します。サービスアカウントの JSON キーを作成するには、サービスアカウントの作成 に関するドキュメントを参照してください。GCP コンソールの手順に従います。
- 新しい Google Cloud Platform サービスアカウントの JSON キー の内容を提供します。
プロキシーを有効にする場合は、プロキシー情報を入力します。
-
HTTP プロキシー URL:
HTTPトラフィックのプロキシーとして使用する URL。 -
HTTPS プロキシー URL:
HTTPSトラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URLと同じ値がHTTPおよびHTTPSの両方に使用されます。 -
プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
-
HTTP プロキシー URL:
- Red Hat OpenShift プルシークレットを入力します。プルシークレットをダウンロードするには、Download your Red Hat OpenShift pull secret を参照してください。
- クラスターにアクセスできるように SSH 秘密鍵 と SSH 公開鍵 を追加します。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。
Google Cloud Platform でのクラスターの作成 の手順を実行することで、クラスターの作成時にこの接続を使用できます。
コンソールで認証情報を編集できます。
認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。
1.6.3.3. API を使用した不透明なシークレットの作成
コンソールの代わりに API を使用して Google Cloud Platform の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。
注記:
- 不透明なシークレットはコンソールに表示されません。
- 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。
1.6.3.4. 関連情報
- Creating and managing projects を参照してください。
- GCP プロジェクトの設定 を参照してください。
- GCP にログインします。
- サービスアカウントの JSON キーを作成するには、Create service accounts を参照してください。
- Red Hat OpenShift プルシークレットをダウンロードします。
- キーを生成する方法の詳細は、クラスターノード SSH アクセス用のキーペアの生成 を参照してください。
- Google Cloud Platform でのクラスターの作成 を参照してください。
1.6.4. VMware vSphere の認証情報の作成
multicluster engine Operator コンソールを使用して、VMware vSphere 上で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。
必要なアクセス権限: 編集
1.6.4.1. 前提条件
認証情報を作成する前に、以下の前提条件を満たす必要があります。
- multicluster engine Operator を使用してクラスターを作成する前に、VMware vSphere の認証情報を作成する必要があります。
- サポートされている OpenShift Container Platform バージョンにデプロイされたハブクラスター。
- VMware vSphere に Kubernetes クラスターを作成できるようにするハブクラスターのインターネットアクセス。
インストーラーでプロビジョニングされるインフラストラクチャーを使用する場合に OpenShift Container Platform 向けに設定された VMware vSphere ログイン認証情報および vCenter 要件。カスタマイズによる vSphere へのクラスターのインストール を参照してください。これらの認証除法には、以下の情報が含まれます。
- vCenter アカウントの権限
- クラスターリソース
- DHCP が利用できる
- 時間を同期した ESXi ホスト (例: NTP)
1.6.4.2. コンソールを使用した認証情報の管理
multicluster engine Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。
ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 利便性とセキュリティー強化のために、認証情報をホストする専用の namespace を作成します。
オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。以下の手順を参照してください。
- VMware vCenter サーバーの完全修飾ホスト名または IP アドレス を追加します。値は vCenter サーバーのルート CA 証明書に定義する必要があります。可能な場合は、完全修飾ホスト名を使用します。
- VMware vCenter のユーザー名 を追加します。
- VMware vCenter パスワード を追加します。
VMware vCenter ルート CA 証明書 を追加します。
-
VMware vCenter サーバー (
https://<vCenter_address>/certs/download.zip) からdownload.zipとして証明書をダウンロードできます。vCenter_address は、vCenter サーバーのアドレスに置き換えます。 -
download.zipのパッケージを展開します。 拡張子が
.0のcerts/<platform>ディレクトリーの証明書を使用します。ヒント:
ls certs/<platform>コマンドを使用して、お使いのプラットフォームで使用可能な全証明書を一覧表示できます。<platform>は、lin、mac、またはwinなど、お使いのプラットフォームに置き換えます。例:
certs/lin/3a343545.0ベストプラクティス:
cat certs/lin/*.0 > ca.crtコマンドを実行して、拡張子.0を持つ複数の証明書をリンクします。- VMware vSphere クラスター名 を追加します。
- VMware vSphere データセンター を追加します。
- VMware vSphere デフォルトデータストア を追加します。
- VMware vSphere ディスクタイプ を追加します。
- VMware vSphere フォルダー を追加します。
- VMware vSphere リソースプール を追加します。
-
VMware vCenter サーバー (
オフラインインストールのみ: Configuration for disconnected installation サブセクションのフィールドに必要な情報を入力します。
- Cluster OS image: この値には、Red Hat OpenShift Container Platform クラスターマシンに使用するイメージの URL が含まれます。
Image content source: この値には、オフラインのレジストリーパスが含まれます。このパスには、オフラインインストールに使用する全インストールイメージのホスト名、ポート、レジストリーパスが含まれます。たとえば、
repository.com:5000/openshift/ocp-releaseとなります。このパスは、Red Hat OpenShift Container Platform リリースイメージに対して、
install-config.yamlのイメージコンテンツソースポリシーのマッピングを作成します。たとえば、repository.com:5000は以下のimageContentSourceコンテンツを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Additional trust bundle: この値で、ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツを指定します。
注記: 非接続環境にあるハブクラスターからマネージドクラスターをデプロイして、インストール後の設定を自動的にインポートする場合は、
YAMLエディターを使用してイメージコンテンツソースポリシーをinstall-config.yamlファイルに追加します。エントリーの例を以下に示します。- mirrors: - registry.example.com:5000/rhacm2 source: registry.redhat.io/rhacm2
- mirrors: - registry.example.com:5000/rhacm2 source: registry.redhat.io/rhacm2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
プロキシーを有効にする必要がある場合は、プロキシー情報を入力します。
-
HTTP プロキシー URL:
HTTPトラフィックのプロキシーとして使用する URL。 -
HTTPS プロキシー URL:
HTTPSトラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URLと同じ値がHTTPおよびHTTPSの両方に使用されます。 -
プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
-
HTTP プロキシー URL:
- Red Hat OpenShift プルシークレットを入力します。プルシークレットをダウンロードするには、Download your Red Hat OpenShift pull secret を参照してください。
SSH 秘密鍵 と SSH 公開鍵 を追加し、クラスターに接続できるようにします。
既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。
VMware vSphere でのクラスターの作成 の手順を完了することで、この認証情報を使用するクラスターを作成できます。
コンソールで認証情報を編集できます。
認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。
1.6.4.3. API を使用した不透明なシークレットの作成
コンソールの代わりに API を使用して VMware vSphere の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。
注記:
- 不透明なシークレットはコンソールに表示されません。
- 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。
1.6.4.4. 関連情報
- カスタマイズによる vSphere へのクラスターのインストール を参照してください。
- Red Hat OpenShift プルシークレットをダウンロードします。
- 詳細は、クラスターノード SSH アクセス用のキーペアの生成 を参照してください。
- VMware vSphere でのクラスターの作成 を参照してください。
- VMware vSphere の認証情報の作成 に戻ります。
1.6.5. Red Hat OpenStack の認証情報の作成
multicluster engine Operator コンソールを使用して、サポートされている Red Hat OpenShift Container Platform クラスターを Red Hat OpenStack Platform 上でデプロイおよび管理するには、認証情報が必要です。
注記: multicluster engine Operator を使用してクラスターを作成する前に、Red Hat OpenStack Platform の認証情報を作成する必要があります。
1.6.5.1. 前提条件
認証情報を作成する前に、以下の前提条件を満たす必要があります。
- サポートされている OpenShift Container Platform バージョンにデプロイされたハブクラスター。
- Red Hat OpenStack Platform で Kubernetes クラスターを作成できるようにするハブクラスターのインターネットアクセス。
- インストーラーでプロビジョニングされるインフラストラクチャーを使用する場合に OpenShift Container Platform 向けに設定された Red Hat OpenStack Platform ログイン認証情報および Red Hat OpenStack Platform の要件。カスタマイズによる OpenStack へのクラスターのインストール を参照してください。
CloudStack API にアクセスするための
clouds.yamlファイルをダウンロードまたは作成する。clouds.yamlファイルで以下を行います。- 使用する cloud auth セクション名を決定します。
- username 行の直後に、password の行を追加します。
1.6.5.2. コンソールを使用した認証情報の管理
multicluster engine Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。
ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。セキュリティーと利便性を高めるために、認証情報をホストする専用の namespace を作成できます。
- オプション: 認証情報のベース DNS ドメインを追加できます。ベース DNS ドメインを追加すると、この認証情報を使用してクラスターを作成するときに、正しいフィールドに自動的に入力されます。
-
Red Hat OpenStack Platform の
clouds.yamlファイルの内容を追加します。パスワードを含むclouds.yamlファイルの内容で、Red Hat OpenStack Platform サーバーへの接続に必要な情報を提供します。ファイルの内容には、usernameの直後に新たに追加したパスワードを含める必要があります。 -
Red Hat OpenStack Platform クラウド名を追加します。このエントリーは、Red Hat OpenStack Platform サーバーへの通信確立に使用する
clouds.yamlの cloud セクションで指定した名前です。 -
オプション: 内部認証局を使用する設定の場合は、内部 CA 証明書 フィールドに証明書を入力して、証明書情報で
clouds.yamlを自動的に更新します。 オフラインインストールのみ: Configuration for disconnected installation サブセクションのフィールドに必要な情報を入力します。
- Cluster OS image: この値には、Red Hat OpenShift Container Platform クラスターマシンに使用するイメージの URL が含まれます。
イメージコンテンツソース: この値には、オフラインのレジストリーパスが含まれます。このパスには、オフラインインストールに使用する全インストールイメージのホスト名、ポート、レジストリーパスが含まれます。たとえば、
repository.com:5000/openshift/ocp-releaseとなります。このパスは、Red Hat OpenShift Container Platform リリースイメージに対して、
install-config.yamlのイメージコンテンツソースポリシーのマッピングを作成します。たとえば、repository.com:5000は以下のimageContentSourceコンテンツを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Additional trust bundle: この値で、ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツを指定します。
注記: 非接続環境にあるハブクラスターからマネージドクラスターをデプロイして、インストール後の設定を自動的にインポートする場合は、
YAMLエディターを使用してイメージコンテンツソースポリシーをinstall-config.yamlファイルに追加します。エントリーの例を以下に示します。- mirrors: - registry.example.com:5000/rhacm2 source: registry.redhat.io/rhacm2
- mirrors: - registry.example.com:5000/rhacm2 source: registry.redhat.io/rhacm2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
プロキシーを有効にする必要がある場合は、プロキシー情報を入力します。
-
HTTP プロキシー URL:
HTTPトラフィックのプロキシーとして使用する URL。 -
HTTPS プロキシー URL:
HTTPSトラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URLと同じ値がHTTPおよびHTTPSの両方に使用されます。 -
プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
-
HTTP プロキシー URL:
- Red Hat OpenShift プルシークレットを入力します。プルシークレットをダウンロードするには、Download your Red Hat OpenShift pull secret を参照してください。
- SSH 秘密鍵と SSH 公開鍵を追加し、クラスターに接続できるようにします。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。
- Create をクリックします。
- 新規の認証情報を確認し、Add をクリックします。認証情報を追加すると、認証情報のリストに追加されます。
Red Hat OpenStack Platform でのクラスターの作成 の手順を実行して、この認証情報を使用するクラスターを作成します。
コンソールで認証情報を編集できます。
認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。
1.6.5.3. API を使用した不透明なシークレットの作成
コンソールの代わりに API を使用して Red Hat OpenStack Platform の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。
注記:
- 不透明なシークレットはコンソールに表示されません。
- 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。
1.6.5.4. 関連情報
- カスタマイズによる OpenStack へのクラスターのインストール を参照してください。
- Red Hat OpenShift プルシークレットをダウンロードします。
- 詳細は、クラスターノード SSH アクセス用のキーペアの生成 を参照してください。
- Red Hat OpenStack Platform でのクラスターの作成 を参照してください。
- Red Hat OpenStack の認証情報の作成 に戻ります。
1.6.6. Red Hat OpenShift Cluster Manager の認証情報の作成
クラスターを検出できるように OpenShift Cluster Manager の認証情報を追加します。
必要なアクセス権限: 管理者
1.6.6.1. 前提条件
OpenShift Cluster Manager アカウントに API トークンが必要です。別のサービスアカウントを使用することもできます。
- API トークンを取得するには、OpenShift Cluster Manager API トークンのダウンロード を参照してください。
- サービスアカウントを使用するには、サービスアカウントを作成するときにクライアント ID とクライアントシークレットを取得する必要があります。この認証情報を入力して、multicluster engine for Kubernetes Operator に OpenShift Cluster Manager の認証情報を作成します。サービスアカウントの作成および管理 を参照してください。
1.6.6.2. コンソールを使用した証情報の追加
クラスター検出用の認証情報を追加する必要があります。multicluster engine Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。
- クラスターにログインします。
- 既存の認証情報オプションから選択するには、Credentials > Credential type をクリックします。
- 利便性とセキュリティー強化のために、認証情報をホストする専用の namespace を作成します。
- Add credential をクリックします。
- Red Hat OpenShift Cluster Manager オプションを選択します。
- いずれかの認証方法を選択します。
注記:
- 認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。
- 認証情報が削除されるか、OpenShift Cluster Manager API トークンの有効期限が切れるか、取り消されると、関連付けられた検出クラスターが削除されます。
1.6.7. Ansible Automation Platform の認証情報の作成
multicluster engine Operator コンソールを使用して、Red Hat Ansible Automation Platform を使用する Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。
必要なアクセス権限: 編集
注記: この手順は、自動化テンプレートを作成して、クラスターで自動化を有効にする前に、実行する必要があります。
1.6.7.1. 前提条件
認証情報を作成する前に、以下の前提条件を満たす必要があります。
- デプロイされた multicluster engine Operator ハブクラスター
- multicluster engine Operator ハブクラスターのインターネットアクセス
- Ansible Automation Platform ホスト名と OAuth トークンを含む Ansible ログイン認証情報。Ansible Automation Platform の認証情報 を参照してください。
- ハブクラスターのインストールおよび Ansible 操作をできるようにするアカウント権限。Ansible ユーザー の詳細を確認してください。
1.6.7.2. コンソールを使用した認証情報の管理
multicluster engine Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。
ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 利便性とセキュリティー強化のために、認証情報をホストする専用の namespace を作成します。
Ansible 認証情報の作成時に指定する Ansible トークンとホストの URL は、認証情報の編集時にその認証情報を使用する自動化向けに、自動で更新されます。更新は、クラスターライフサイクル、ガバナンス、およびアプリケーション管理の自動化に関連するものなど、Ansible 認証情報を使用する自動化にコピーされます。これにより、認証情報の更新後も自動化が引き続き実行されます。
コンソールで認証情報を編集できます。Ansible 認証情報は、認証情報の更新時に、対象の認証情報を使用する自動化で、自動的に更新されあす。
マネージドクラスターで実行する Ansible Automation Platform タスクの設定 の手順を完了することで、この認証情報を使用する Ansible ジョブを作成できます。
認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。
1.6.8. オンプレミス環境の認証情報の作成
コンソールを使用してオンプレミス環境で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。認証情報では、クラスターに使用される接続を指定します。
必要なアクセス権限: 編集
1.6.8.1. 前提条件
認証情報を作成する前に、以下の前提条件を満たす必要があります。
- デプロイされたハブクラスター。
- インフラストラクチャー環境に Kubernetes クラスターを作成できるようにするハブクラスターのインターネットアクセス。
- オフライン環境では、クラスター作成用のリリースイメージをコピーできるミラーレジストリーを設定している。詳細は、OpenShift Container Platform ドキュメントの 非接続環境でのミラーリング を参照してください。
- オンプレミス環境でのクラスターのインストールをサポートするアカウントの権限。
1.6.8.2. コンソールを使用した認証情報の管理
コンソールから認証情報を作成するには、コンソールで手順を完了します。
ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 利便性とセキュリティー強化のために、認証情報をホストする専用の namespace を作成します。
- 認証情報の種類に Host inventory を選択します。
- オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。DNS ドメインを追加していない場合は、クラスターの作成時に追加できます。
- Red Hat OpenShift pull secret を入力します。このプルシークレットは、クラスターを作成してこの認証情報を指定すると、自動的に入力されます。Pull secret からプルシークレットをダウンロードします。プルシークレットの詳細は、イメージプルシークレットの使用 を参照してください。
-
SSH public keyを入力します。このSSH public keyクラスターを作成してこの認証情報を指定するときにも自動的に入力されます。 - Add を選択して認証情報を作成します。
オンプレミス環境でのクラスターの作成 の手順を完了することで、この認証情報を使用するクラスターを作成できます。
認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。
1.7. クラスターライフサイクルの概要
multicluster engine Operator は、OpenShift Container Platform および Red Hat Advanced Cluster Management ハブクラスターにクラスター管理機能を提供するクラスターライフサイクル Operator です。multicluster engine Operator は、クラスターフリートの管理を強化し、クラウドとデータセンター全体の OpenShift Container Platform クラスターライフサイクル管理を支援するソフトウェア Operator です。multicluster engine Operator は、Red Hat Advanced Cluster Management の有無にかかわらず使用できます。Red Hat Advanced Cluster Management は、multicluster engine Operator を自動的にインストールし、さらにマルチクラスター機能を提供します。
以下のドキュメントを参照してください。
- クラスターライフサイクルのアーキテクチャー
- 認証情報の管理の概要
- リリースイメージ
- クラスターの作成
- クラスターのインポート
- クラスターへのアクセス
- マネージドクラスターのスケーリング
- 作成されたクラスターの休止
- クラスターのアップグレード
- クラスタープロキシーアドオンの有効化
- マネージドクラスターで実行する Ansible Automation Platform タスクの設定
- ClusterClaims
- ManagedClusterSets
- Placement
- クラスタープールの管理 (テクノロジープレビュー)
- ManagedServiceAccount の有効化
- クラスターのライフサイクルの詳細設定
- 管理からのクラスターの削除
1.7.1. クラスターライフサイクルのアーキテクチャー
クラスターライフサイクルには、ハブクラスター と マネージドクラスター の 2 種類のクラスターが必要です。
ハブクラスターは、multicluster engine Operator が自動的にインストールされる OpenShift Container Platform (または Red Hat Advanced Cluster Management) のメインクラスターです。ハブクラスターを使用して他の Kubernetes クラスターの作成、管理、および監視を行うことができます。ハブクラスターを使用してクラスターを作成できますが、ハブクラスターが管理する既存のクラスターをインポートすることもできます。
マネージドクラスターを作成すると、クラスターは Red Hat OpenShift Container Platform クラスターインストーラーと Hive リソースを使用して作成されます。OpenShift Container Platform インストーラーを使用してクラスターをインストールするプロセスの詳細は、OpenShift Container Platform ドキュメントの OpenShift Container Platform クラスターのインストールおよび設定 を参照してください。
次の図は、クラスター管理用の multicluster engine for Kubernetes Operator とともにインストールされるコンポーネントを示しています。
クラスターライフサイクル管理のアーキテクチャーのコンポーネントには、以下の項目が含まれます。
1.7.1.1. ハブクラスター
- マネージドクラスターのインポートコントローラー は、klusterlet Operator をマネージドクラスターにデプロイします。
- Hive コントローラー は、multicluster engine for Kubernetes Operator を使用して作成したクラスターをプロビジョニングします。また、Hive コントローラーは、multicluster engine for Kubernetes Operator によって作成されたマネージドクラスターを破棄します。
- クラスターキュレーターコントローラー は、マネージドクラスターの作成またはアップグレード時にクラスターインフラストラクチャー環境を設定するためのプレフックまたはポストフックとして Ansible ジョブを作成します。
- マネージドクラスターアドオンがハブクラスターで有効になると、その アドオンハブコントローラー がハブクラスターにデプロイされます。アドオンハブコントローラー は、アドオンエージェント をマネージドクラスターにデプロイします。
1.7.1.2. マネージドクラスター
- klusterlet Operator マネージドクラスターに登録およびワークコントローラーをデプロイします。
登録エージェント は、マネージドクラスターとマネージドクラスターアドオンをハブクラスターに登録します。また、登録エージェントは、マネージドクラスターとマネージドクラスターアドオンのステータスを維持します。次のアクセス許可が Clusterrole 内に自動的に作成され、マネージドクラスターがハブクラスターにアクセスできるようになります。
- エージェントは、ハブクラスターが管理する所有クラスターを取得または更新できます。
- エージェントが、ハブクラスターが管理する所有クラスターのステータスを更新できるようにします。
- エージェントが証明書をローテーションできるようにします。
-
エージェントが
coordination.k8s.ioリースをgetまたはupdateできるようにします。 -
エージェントがマネージドクラスターアドオンを
getできるようにします。 - エージェントがマネージドクラスターアドオンのステータスを更新できるようにします。
- ワークエージェント は、アドオンエージェントをマネージドクラスターに適用します。マネージドクラスターによるハブクラスターへのアクセスを許可する権限は、Clusterrole 内に自動的に作成され、エージェントはイベントをハブクラスターに送信できます。
クラスターの追加と管理を続行するには、クラスターライフサイクルの概要 を参照してください。
1.7.2. リリースイメージ
クラスターをビルドするときは、リリースイメージで指定されているバージョンの Red Hat OpenShift Container Platform を使用します。デフォルトでは、OpenShift Container Platform は clusterImageSets リソースを使用して、サポートされているリリースイメージのリストを取得します。
リリースイメージの詳細は、読み続けてください。
1.7.2.1. リリースイメージの指定
multicluster engine for Kubernetes Operator を使用してプロバイダー上にクラスターを作成する場合は、新しいクラスターに使用するリリースイメージを指定します。リリースイメージを指定するには、次のトピックを参照してください。
1.7.2.1.1. ClusterImageSets の検索
リリースイメージを参照する YAML ファイルは、acm-hive-openshift-releases GitHub リポジトリーに保持されます。これらのファイルは、コンソールで利用可能なリリースイメージのリストを作成します。これには、OpenShift Container Platform における最新の fast チャネルイメージが含まれます。
コンソールには、OpenShift Container Platform の 3 つの最新バージョンの最新リリースイメージのみが表示されます。たとえば、コンソールオプションに次のリリースイメージが表示され、<4.x> の部分が、使用している適切なリリースバージョンに変更されている場合があります。
quay.io/openshift-release-dev/ocp-release:<4.x>.1-x86_64
コンソールには最新バージョンが表示され、最新のリリースイメージを使用してクラスターを作成するのに役立ちます。特定のバージョンのクラスターを作成する必要がある場合は、古いリリースイメージバージョンも利用できます。
注記: コンソールでクラスターを作成する場合は、visible: 'true' ラベルを持つイメージのみを選択できます。ClusterImageSet リソース内のこのラベルの例は、以下の内容で提供されます。4.x.1 は、製品の最新バージョンに置き換えます。
追加のリリースイメージは保管されますが、コンソールには表示されません。利用可能なリリースイメージをすべて表示するには、次のコマンドを実行します。
oc get clusterimageset
oc get clusterimageset
リポジトリーには、clusterImageSets ディレクトリーがあります。これは、リリースイメージを操作するときに使用するディレクトリーです。clusterImageSets ディレクトリーには、次のディレクトリーがあります。
- Fast: サポート対象の各 OpenShift Container Platform バージョンのリリースイメージの内、最新バージョンを参照するファイルが含まれます。このフォルダー内のリリースイメージはテストされ、検証されており、サポートされます。
Releases: 各 OpenShift Container Platform バージョン (stable、fast、および candidate チャネル) のリリースイメージすべてを参照するファイルが含まれます。
注記: これらのリリースすべてがテストされおらず、安定版とみなされているわけではありません。
Stable: サポート対象の各 OpenShift Container Platform バージョンのリリースイメージの内、最新の安定版 2 つを参照するファイルが含まれます。
注記: デフォルトでは、リリースイメージの現在のリストは 1 時間ごとに更新されます。製品をアップグレードした後、リストに製品の新しいバージョンの推奨リリースイメージバージョンが反映されるまでに最大 1 時間かかる場合があります。
1.7.2.1.2. ClusterImageSets の設定
次のオプションを使用して ClusterImageSets を設定できます。
オプション 1: コンソールでクラスターを作成するには、使用する特定の
ClusterImageSetのイメージ参照を指定します。指定した新しいエントリーはそれぞれ保持され、将来のすべてのクラスタープロビジョニングで使用できます。次のエントリーの例を参照してください。quay.io/openshift-release-dev/ocp-release:4.6.8-x86_64
quay.io/openshift-release-dev/ocp-release:4.6.8-x86_64Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション 2: GitHub リポジトリー
acm-hive-openshift-releasesから YAML ファイルClusterImageSetsを手動で作成し、適用します。 -
オプション 3: フォークされた GitHub リポジトリーから
ClusterImageSetsの自動更新を有効にするには、cluster-image-set-controller GitHub リポジトリーのREADME.mdに従います。
1.7.2.1.3. 別のアーキテクチャーにクラスターをデプロイするためのリリースイメージの作成
両方のアーキテクチャーのファイルを持つリリースイメージを手動で作成することで、ハブクラスターのアーキテクチャーとは異なるアーキテクチャーでクラスターを作成できます。
たとえば、ppc64le、aarch64、または s390x アーキテクチャーで実行されているハブクラスターから x86_64 クラスターを作成する必要があるとします。両方のファイルセットでリリースイメージを作成する場合に、新規のリリースイメージにより OpenShift Container Platform リリースレジストリーがマルチアーキテクチャーイメージマニフェストを提供できるので、クラスターの作成は成功します。
OpenShift Container Platform では、デフォルトで複数のアーキテクチャーがサポートされます。以下の clusterImageSet を使用してクラスターをプロビジョニングできます。4.x.0 は、現在サポートされているバージョンに置き換えます。
複数のアーキテクチャーをサポートしない OpenShift Container Platform イメージのリリースイメージを作成するには、アーキテクチャータイプについて以下のような手順を実行します。
OpenShift Container Platform リリースレジストリー から、
x86_64、s390x、aarch64、およびppc64leリリースイメージを含む マニフェスト一覧 を作成します。以下のコマンド例を実行して、Quay リポジトリー から環境内の両方のアーキテクチャーのマニフェストリストをプルします。
4.x.1は、製品の最新バージョンに置き換えます。podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64 podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-ppc64le podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-s390x podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-aarch64
podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64 podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-ppc64le podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-s390x podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-aarch64Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、イメージを管理するプライベートリポジトリーにログインします。
<private-repo>は、リポジトリーへのパスに置き換えます。podman login <private-repo>
podman login <private-repo>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 環境に適用される以下のコマンドを実行して、リリースイメージマニフェストをプライベートリポジトリーに追加します。
4.x.1は、製品の最新バージョンに置き換えます。<private-repo>は、リポジトリーへのパスに置き換えます。podman push quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64 <private-repo>/ocp-release:4.x.1-x86_64 podman push quay.io/openshift-release-dev/ocp-release:4.x.1-ppc64le <private-repo>/ocp-release:4.x.1-ppc64le podman push quay.io/openshift-release-dev/ocp-release:4.x.1-s390x <private-repo>/ocp-release:4.x.1-s390x podman push quay.io/openshift-release-dev/ocp-release:4.x.1-aarch64 <private-repo>/ocp-release:4.x.1-aarch64
podman push quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64 <private-repo>/ocp-release:4.x.1-x86_64 podman push quay.io/openshift-release-dev/ocp-release:4.x.1-ppc64le <private-repo>/ocp-release:4.x.1-ppc64le podman push quay.io/openshift-release-dev/ocp-release:4.x.1-s390x <private-repo>/ocp-release:4.x.1-s390x podman push quay.io/openshift-release-dev/ocp-release:4.x.1-aarch64 <private-repo>/ocp-release:4.x.1-aarch64Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、新しい情報のマニフェストを作成します。
podman manifest create mymanifest
podman manifest create mymanifestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、両方のリリースイメージへの参照をマニフェストリストに追加します。
4.x.1は、製品の最新バージョンに置き換えます。<private-repo>は、リポジトリーへのパスに置き換えます。podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-x86_64 podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-ppc64le podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-s390x podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-aarch64
podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-x86_64 podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-ppc64le podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-s390x podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-aarch64Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マニフェストリスト内のリストを既存のマニフェストとマージします。
<private-repo>は、リポジトリーへのパスに置き換えます。4.x.1は、最新バージョンに置き換えます。podman manifest push mymanifest docker://<private-repo>/ocp-release:4.x.1
podman manifest push mymanifest docker://<private-repo>/ocp-release:4.x.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ハブクラスターで、リポジトリーのマニフェストを参照するリリースイメージを作成します。
以下の例のような情報を含む YAML ファイルを作成します。
<private-repo>は、リポジトリーへのパスに置き換えます。4.x.1は、最新バージョンに置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで以下のコマンドを実行し、変更を適用します。
<file-name>を、先の手順で作成した YAML ファイルの名前に置き換えます。oc apply -f <file-name>.yaml
oc apply -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- OpenShift Container Platform クラスターの作成時に新規リリースイメージを選択します。
- Red Hat Advanced Cluster Management コンソールを使用してマネージドクラスターをデプロイする場合は、クラスター作成プロセス時に Architecture フィールドにマネージドクラスターのアーキテクチャーを指定します。
作成プロセスでは、マージされたリリースイメージを使用してクラスターを作成します。
1.7.2.1.4. 関連情報
- リリースイメージを参照する YAML ファイルは、acm-hive-openshift-releases GitHub リポジトリーを参照してください。
-
フォークされた GitHub リポジトリーから
ClusterImageSetsの自動更新を有効にする方法は、cluster-image-set-controller GitHub リポジトリー を参照してください。
1.7.2.2. 接続環境におけるリリースイメージのカスタムリストの管理
場合によっては、すべてのクラスターに同じリリースイメージを使用する必要があります。作業を簡素化するために、リリースイメージの独自のカスタムリストを作成しておくと、クラスターの作成時にそのリストを使用できます。利用可能なリリースイメージを管理するには、以下の手順を実行します。
- acm-hive-openshift-releases GitHub をフォークします。
-
クラスターの作成時に使用できるイメージの YAML ファイルを追加します。Git コンソールまたはターミナルを使用して、イメージを
./clusterImageSets/stable/または./clusterImageSets/fast/ディレクトリーに追加します。 cluster-image-set-git-repoという名前のmulticluster-enginenamespace にConfigMapを作成します。次の例を参照してください。ただし、2.xは 2.9 に置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次の手順でフォークされたリポジトリーに変更をマージすることで、メインリポジトリーから利用可能な YAML ファイルを取得できます。
- フォークしたリポジトリーに変更をコミットし、マージします。
-
acm-hive-openshift-releasesリポジトリーのクローンを作成した後に高速リリースイメージのリストを同期するには、cluster-image-set-git-repoConfigMapの channel フィールドの値をfastに更新します。 -
安定版リリースイメージを同期して表示するには、
cluster-image-set-git-repoConfigMapの channel フィールドの値をstableに更新します。
ConfigMap を更新すると、約 1 分以内に、利用可能な安定リリースイメージのリストが現在利用可能なイメージで更新されます。
以下のコマンドを使用して、利用可能ものを表示し、デフォルトの設定を削除します。
<clusterImageSet_NAME>を正しい名前に置き換えます。oc get clusterImageSets oc delete clusterImageSet <clusterImageSet_NAME>
oc get clusterImageSets oc delete clusterImageSet <clusterImageSet_NAME>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - クラスターの作成時に、コンソールで現在利用可能なリリースイメージの一覧を表示します。
ConfigMap を通じて利用できる他のフィールドは、cluster-image-set-controller GitHub リポジトリーの README を参照してください。
1.7.2.3. 非接続環境におけるリリースイメージのカスタムリストの管理
場合によっては、ハブクラスターにインターネット接続がないときに、リリースイメージのカスタムリストを管理する必要があります。リリースイメージの独自のカスタムリストを作成しておくと、クラスターの作成時にそのリストを使用できます。非接続環境で利用可能なリリースイメージを管理するには、次の手順を実行します。
- インターネットに接続されたシステムで、acm-hive-openshift-releases GitHub リポジトリー に移動して、利用可能なクラスターイメージセットにアクセスします。
-
clusterImageSetsディレクトリーを、非接続の multicluster engine Operator クラスターにアクセスできるシステムにコピーします。 マネージドクラスターに合わせて次の手順を実行して、クラスターイメージセットを含むオフラインリポジトリーとマネージドクラスター間のマッピングを追加します。
-
OpenShift Container Platform マネージドクラスターの場合は、イメージレジストリーリポジトリーのミラーリングの設定 を参照し、
ImageContentSourcePolicyオブジェクトを使用してマッピングを完了する方法を確認します。 -
OpenShift Container Platform クラスターではないマネージドクラスターの場合は、
ManageClusterImageRegistryカスタムリソース定義を使用してイメージセットの場所を上書きします。マッピング用にクラスターを上書きする方法は、インポート用のマネージドクラスターでのレジストリーイメージの指定 を参照してください。
-
OpenShift Container Platform マネージドクラスターの場合は、イメージレジストリーリポジトリーのミラーリングの設定 を参照し、
-
コンソールまたは CLI を使用して、
clusterImageSetYAML コンテンツを手動で追加することにより、クラスターを作成するときに使用できるイメージの YAML ファイルを追加します。 残りの OpenShift Container Platform リリースイメージの
clusterImageSetYAML ファイルを、イメージの保存先の正しいオフラインリポジトリーを参照するように変更します。変更後は次の例のようになります。spec.releaseImageはリリースイメージのオフラインイメージレジストリーを使用します。リリースイメージはダイジェストによって参照されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - YAML ファイルで参照されているオフラインイメージレジストリーにイメージがロードされていることを確認します。
次のコマンドを実行して、イメージダイジェストを取得します。
oc adm release info <tagged_openshift_release_image> | grep "Pull From"
oc adm release info <tagged_openshift_release_image> | grep "Pull From"Copy to Clipboard Copied! Toggle word wrap Toggle overflow <tagged_openshift_release_image>は、サポートされている OpenShift Container Platform バージョンのタグ付きイメージに置き換えます。以下の出力例を参照してください。Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfe
Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfeCopy to Clipboard Copied! Toggle word wrap Toggle overflow イメージタグとダイジェストの詳細は、イメージストリームでのイメージの参照 を参照してください。
各 YAML ファイルに以下のコマンドを入力して、各
clusterImageSetsを作成します。oc create -f <clusterImageSet_FILE>
oc create -f <clusterImageSet_FILE>Copy to Clipboard Copied! Toggle word wrap Toggle overflow clusterImageSet_FILEを、クラスターイメージセットファイルの名前に置き換えます。以下に例を示します。oc create -f img4.11.9-x86_64.yaml
oc create -f img4.11.9-x86_64.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 追加するリソースごとにこのコマンドを実行すると、使用可能なリリースイメージのリストが表示されます。
-
または、クラスターの作成コンソールに直接イメージ URL を貼り付けることもできます。イメージ URL を追加すると、新しい
clusterImageSetsが存在しない場合に作成されます。 - クラスターの作成時に、コンソールで現在利用可能なリリースイメージの一覧を表示します。
1.7.2.4. 利用可能なリリースイメージの同期
MultiClusterHub Operator を使用してハブクラスターコンポーネントを管理、アップグレード、およびインストールする Red Hat Advanced Cluster Management ハブクラスターがある場合は、リリースイメージのリストを同期して、利用可能な最新バージョンを選択できるようします。リリースイメージは acm-hive-openshift-releases リポジトリーで入手でき、頻繁に更新されます。
1.7.2.4.1. 安定性レベル
リリースイメージの安定性には、次の表に示すように 3 つのレベルがあります。
| カテゴリー | 説明 |
|---|---|
| candidate | 最新のイメージ。テストされていないため、バグがある可能性があります。 |
| fast | 部分的にテストされたイメージですが、stable バージョンよりも安定性が低い可能性があります。 |
| stable | 完全にテストされたイメージ。これらのイメージは、クラスターを正しくインストールおよび構築できることが確認されています。 |
1.7.2.4.2. リリースイメージリストの更新
Linux または Mac オペレーティングシステムを使用してイメージのリストを更新および同期するには、次の手順を実行します。
-
インストーラーが管理する
acm-hive-openshift-releasesサブスクリプションが有効になっている場合は、MultiClusterHubリソースのdisableUpdateClusterImageSetsの値をtrueに設定してサブスクリプションを無効にします。 - acm-hive-openshift-releases GitHub リポジトリーをクローンします。
次のコマンドを実行して、サブスクリプションを削除します。
oc delete -f subscribe/subscription-fast
oc delete -f subscribe/subscription-fastCopy to Clipboard Copied! Toggle word wrap Toggle overflow candidateリリースイメージを同期して表示するには、Linux または Mac オペレーティングシステムを使用して次のコマンドを実行します。make subscribe-candidate
make subscribe-candidateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 約 1 分後に、
candidateリリースイメージの最新リストが利用可能になります。fastリリースイメージを同期して表示するには、以下のコマンドを実行します。make subscribe-fast
make subscribe-fastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 約 1 分後に、
fastリリースイメージの最新リストが利用可能になります。stableリリースイメージに接続し、Red Hat Advanced Cluster Management ハブクラスターを同期します。Linux または Mac オペレーティングシステムを使用して次のコマンドを実行します。make subscribe-stable
make subscribe-stableCopy to Clipboard Copied! Toggle word wrap Toggle overflow 利用可能な
candidate、fast、およびstableリリースイメージのリストが、現在利用可能なイメージで約 1 分ほどで更新されます。- クラスターの作成時に、Red Hat Advanced Cluster Management コンソールで現在利用可能なリリースイメージの一覧を表示します。
更新の表示を停止するには、次のコマンドを実行して、これらのチャネルのいずれかから登録を解除します。
oc delete -f subscribe/subscription-fast
oc delete -f subscribe/subscription-fastCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.3. クラスターの作成
multicluster engine Operator を使用して、複数のクラウドプロバイダーに Red Hat OpenShift Container Platform クラスターを作成する方法を説明します。
multicluster engine Operator は、OpenShift Container Platform で提供される Hive Operator を使用して、オンプレミスクラスターと Hosted Control Plane を除くすべてのプロバイダーのクラスターをプロビジョニングします。オンプレミスクラスターをプロビジョニングする場合、multicluster engine Operator は OpenShift Container Platform で提供される Central Infrastructure Management および Assisted Installer 機能を使用します。Hosted Control Plane のホステッドクラスターは、HyperShift Operator を使用してプロビジョニングされます。
1.7.3.1. CLI を使用したクラスターの作成
Multicluster engine for Kubernetes Operator は、内部の Hive コンポーネントを使用して Red Hat OpenShift Container Platform クラスターを作成します。クラスターの作成方法は、以下の情報を参照してください。
1.7.3.1.1. 前提条件
次のコマンドを実行して、ClusterImageSet リソースがハブクラスターで使用可能であることを確認します。
oc get clusterimageset -A
oc get clusterimageset -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力は次の例のような内容になります。
img4.18.4-multi-appsub quay.io/openshift-release-dev/ocp-release:4.18.4-multi img4.18.4-x86-64-appsub quay.io/openshift-release-dev/ocp-release:4.18.4-x86_64
img4.18.4-multi-appsub quay.io/openshift-release-dev/ocp-release:4.18.4-multi img4.18.4-x86-64-appsub quay.io/openshift-release-dev/ocp-release:4.18.4-x86_64Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: 各 ClusterImageSet は OpenShift Container Platform リリースイメージを参照します。ClusterImageSet リソースは、multicluster engine for Kubernetes Operator の
cluster-image-set-controllerによって設定されます。Nutanix プラットフォームを使用する場合は、
ClusterImageSetリソースのreleaseImageにx86_64アーキテクチャーを使用し、visibleラベルの値を'true'に設定します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ハブクラスターの
KubeAPIServer証明書検証ストラテジーを確認し、必要に応じてストラテジーを更新します。セットアップに応じてどのストラテジーを使用すべきかは、ハブクラスターのKubeAPIServer検証ストラテジーの設定 を参照してください。
1.7.3.1.2. ClusterDeployment を使用してクラスターを作成する
ClusterDeployment は、クラスターのライフサイクルを制御するために使用される Hive カスタムリソースです。
Using Hive のドキュメントに従って ClusterDeployment カスタムリソースを作成し、個別のクラスターを作成します。
1.7.3.1.3. ClusterPool を使用してクラスターを作成
ClusterPool は、複数のクラスターを作成するために使用される Hive カスタムリソースでもあります。
Cluster Pools のドキュメントに従って、Hive ClusterPool API でクラスターを作成します。
1.7.3.2. クラスター作成時の追加のマニフェストの設定
追加の Kubernetes リソースマニフェストは、クラスター作成のインストールプロセス中に設定できます。これは、ネットワークの設定やロードバランサーの設定など、シナリオの追加マニフェストを設定する必要がある場合に役立ちます。
1.7.3.2.1. 前提条件
追加のリソースマニフェストが含まれる config map リソースを指定する ClusterDeployment リソースへの参照を追加する。
注記: ClusterDeployment リソースと config map は同じ namespace にある必要があります。
1.7.3.2.2. 例を使用してクラスター作成中に追加のマニフェストを設定する
リソースマニフェストを含む config map を使用して追加のマニフェストを設定する場合は、次の手順を実行します。
YAML ファイルを作成し、次のサンプルコンテンツを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: サンプル
ConfigMapには、別のConfigMapリソースを含むマニフェストが含まれています。リソースマニフェストのConfigMapには、data.<resource_name>\.yamlというパターンでリソース設定を追加することにより、複数のキーを含めることができます。以下のコマンドを実行してこのファイルを適用します。
oc apply -f <filename>.yaml
oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow リソースマニフェストの
ConfigMapを参照してClusterDeploymentを使用して追加のマニフェストを設定する場合は、次の手順を実行します。YAML ファイルを作成し、次のサンプルコンテンツを追加します。リソースマニフェスト
ConfigMapはspec.provisioning.manifestsConfigMapRefで参照されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してこのファイルを適用します。
oc apply -f <filename>.yaml
oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.3.3. Amazon Web Services でのクラスターの作成
multicluster engine Operator コンソールを使用して、Amazon Web Services (AWS) 上に Red Hat OpenShift Container Platform クラスターを作成できます。
クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの AWS へのインストール でプロセスの詳細を確認してください。
1.7.3.3.1. 前提条件
AWS でクラスターを作成する前に、以下の前提条件を確認してください。
- ハブクラスターをデプロイしている。
- AWS 認証情報がある。詳細は、Amazon Web Services の認証情報の作成 を参照してください。
- AWS で設定されたドメインがある。ドメインの設定方法は、AWS へのインストール を参照してください。
- ユーザー名、パスワード、アクセスキー ID およびシークレットアクセスキーなど、Amazon Web Services (AWS) のログイン認証情報がある。Understanding and Getting Your Security Credentials を参照してください。
OpenShift Container Platform イメージのプルシークレットがある。イメージプルシークレットの使用 を参照してください。
注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、コンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。
1.7.3.3.2. AWS クラスターの作成
AWS クラスターの作成に関する次の重要な情報を参照してください。
-
クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML: On を選択して、パネルに
install-config.yamlファイルの内容を表示できます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。 - クラスターを作成すると、コントローラーはクラスターとリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。
- クラスターを 破棄 すると、namespace とその中のすべてのリソースが削除されます。
-
クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に
cluster-admin権限がない場合に、clusterset-admin権限があるクラスターセットを選択する必要があります。 -
指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの
clusterset-admin権限を受け取ってください。 -
マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを
ManagedClusterSetに割り当てない場合は、デフォルトのマネージドクラスターセットに自動的に追加されます。 - AWS アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。この名前はクラスターのホスト名で使用されます。
- このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。利用可能なイメージのリストからイメージを選択します。使用したいイメージがない場合は、使用したいイメージの URL を入力します。
ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。情報には以下のフィールドが含まれます。
- region: ノードプールが必要なリージョンを指定します。
- CPU アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および arm64 です。
- ゾーン: コントロールプレーンプールを実行する場所を指定します。より分散されているコントロールプレーンノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
- インスタンスタイプ: コントロールプレーンノードのインスタンスタイプを指定します。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
- ルートストレージ: クラスターに割り当てるルートストレージの量を指定します。
ワーカープールにワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。オプションの情報には以下のフィールドが含まれます。
- ゾーン: ワーカープールを実行する場所を指定します。より分散されているノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
- インスタンスタイプ: ワーカープールのインスタンスタイプを指定します。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
- ノード数: ワーカープールのノード数を指定します。ワーカープールを定義する場合にこの設定は必須です。
- ルートストレージ: ワーカープールに割り当てるルートストレージの量を指定します。ワーカープールを定義する場合にこの設定は必須です。
- クラスターにはネットワークの詳細が必要であり、IPv6 を使用するには複数のネットワークが必要です。Add network をクリックして、追加のネットワークを追加できます。
認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。
-
HTTP プロキシー:
HTTPトラフィックのプロキシーとして使用する URL を指定します。 -
HTTPS プロキシー:
HTTPSトラフィックに使用するセキュアなプロキシー URL を指定します。値の指定がない場合は、HTTP Proxy URLと同じ値がHTTPおよびHTTPSの両方に使用されます。 -
プロキシーサイトなし: プロキシーをバイパスする必要のあるサイトのコンマ区切りリスト。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
-
HTTP プロキシー:
1.7.3.3.3. コンソールを使用したクラスターの作成
新しいクラスターを作成するには、次の手順を参照してください。代わりに既存のクラスターを インポート する場合は、クラスターのインポート を参照してください。
注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、multicluster engine Operator で管理されるように自動的に設定されます。
- Infrastructure > Clusters に移動します。
- Clusters ページで、以下を実行します。Cluster > Create cluster をクリックし、コンソールで手順を完了します。
- 任意: コンソールに情報を入力するときにコンテンツの更新を表示するには、YAML: On を選択します。
認証情報を作成する必要がある場合は、Amazon Web Services の認証情報の作成 を参照してください。
クラスターの名前はクラスターのホスト名で使用されます。
Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。
1.7.3.3.4. 関連情報
- AWS プライベート設定情報は、AWS GovCloud クラスターの作成時に使用されます。その環境での クラスターの作成は、Amazon Web Services GovCloud でのクラスターの作成 を参照してください。
- 詳細は、AWS へのインストール を参照してください。
- リリースイメージの詳細は、リリースイメージ を参照してください。
- サポートされているインスタントタイプの詳細は、AWS 汎用インスタンス などのクラウドプロバイダーのサイトにアクセスしてください。
1.7.3.4. Amazon Web Services GovCloud でのクラスターの作成
コンソールを使用して、Amazon Web Services (AWS) または AWS GovCloud で Red Hat OpenShift Container Platform クラスターを作成できます。この手順では、AWS GovCloud でクラスターを作成する方法を説明します。AWS でクラスターを作成する手順は、Amazon Web Services でのクラスターの作成 を参照してください。
AWS GovCloud は、政府のドキュメントをクラウドに保存するために必要な追加の要件を満たすクラウドサービスを提供します。AWS GovCloud でクラスターを作成する場合、環境を準備するために追加の手順を実行する必要があります。
クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの AWS の government リージョンへのクラスターのインストール を参照して、プロセスの詳細を確認してください。以下のセクションでは、AWS GovCloud でクラスターを作成する手順を説明します。
1.7.3.4.1. 前提条件
AWS GovCloud クラスターを作成する前に、以下の前提条件を満たす必要があります。
- ユーザー名、パスワード、アクセスキー ID、およびシークレットアクセスキーなどの AWS ログイン認証情報が必要です。Understanding and Getting Your Security Credentials を参照してください。
- AWS 認証情報がある。詳細は、Amazon Web Services の認証情報の作成 を参照してください。
- AWS で設定されたドメインがある。ドメインの設定方法は、AWS へのインストール を参照してください。
- OpenShift Container Platform イメージのプルシークレットがある。イメージプルシークレットの使用 を参照してください。
- ハブクラスター用の既存の Red Hat OpenShift Container Platform クラスターを備えた Amazon Virtual Private Cloud (VPC) が必要です。この VPC は、マネージドクラスターリソースまたはマネージドクラスターサービスエンドポイントに使用される VPC とは異なる必要があります。
- マネージドクラスターリソースがデプロイされる VPC が必要です。これは、ハブクラスターまたはマネージドクラスターサービスエンドポイントに使用される VPC と同じにすることはできません。
- マネージドクラスターサービスエンドポイントを提供する 1 つ以上の VPC が必要です。これは、ハブクラスターまたはマネージドクラスターリソースに使用される VPC と同じにすることはできません。
- Classless Inter-Domain Routing (CIDR) によって指定される VPC の IP アドレスが重複しないようにしてください。
-
Hive namespace 内で認証情報を参照する
HiveConfigカスタムリソースが必要です。このカスタムリソースは、マネージドクラスターサービスエンドポイント用に作成した VPC でリソースを作成するためにアクセスできる必要があります。
注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、multicluster engine Operator コンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。
1.7.3.4.2. Hive を AWS GovCloud にデプロイするように設定します。
AWS GovCloud でのクラスターの作成は、標準の AWS でクラスターを作成することとほぼ同じですが、AWS GovCloud でクラスターの AWS PrivateLink を準備するために追加の手順を実行する必要があります。
1.7.3.4.2.1. リソースおよびエンドポイントの VPC の作成
前提条件に記載されているように、ハブクラスターが含まれる VPC に加えて、2 つの VPC が必要です。VPC を作成する具体的な手順は、Amazon Web Services ドキュメントの VPC の作成 を参照してください。
- プライベートサブネットを使用してマネージドクラスターの VPC を作成します。
- プライベートサブネットを使用して、マネージドクラスターサービスエンドポイントの 1 つ以上の VPC を作成します。リージョンの各 VPC には 255 VPC エンドポイントの制限があるため、そのリージョン内の 255 を超えるクラスターをサポートするには、複数の VPC が必要です。
各 VPC について、リージョンのサポートされるすべてのアベイラビリティーゾーンにサブネットを作成します。コントローラーの要件があるため、各サブネットには少なくとも 255 以上の使用可能な IP アドレスが必要です。
以下の例は、
us-gov-east-1リージョンに 6 つのアベイラビリティーゾーンを持つ VPC のサブネットを設定する方法を示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - すべてのハブクラスター (ハブクラスター VPC) に、ピアリング、転送ゲートウェイ、およびすべての DNS 設定が有効になっている VPC エンドポイント用に作成した VPC へのネットワーク接続があることを確認します。
- AWS GovCloud 接続に必要な AWS PrivateLink の DNS 設定を解決するために必要な VPC のリストを収集します。これには、少なくとも設定中の multicluster engine Operator インスタンスの VPC を含めます。さまざまな Hive コントローラーが存在するすべての VPC のリストを含めることもできます。
1.7.3.4.2.2. VPC エンドポイントのセキュリティーグループの設定
AWS の各 VPC エンドポイントには、エンドポイントへのアクセスを制御するためにセキュリティーグループが割り当てられます。Hive が VPC エンドポイントを作成する場合、セキュリティーグループは指定しません。VPC のデフォルトのセキュリティーグループは VPC エンドポイントに割り当てられます。VPC のデフォルトのセキュリティーグループには、VPC エンドポイントが Hive インストーラー Pod から作成されるトラフィックを許可するルールが必要です。詳細は、AWS ドキュメントの エンドポイントポリシーを使用した VPC エンドポイントへのアクセスの制御 を参照してください。
たとえば、Hive が hive-vpc (10.1.0.0/16) で実行されている場合は、VPC エンドポイントが作成される VPC のデフォルトセキュリティーグループに、10.1.0.0/16 からのイングレスを許可するルールが必要です。
1.7.3.4.2.3. AWS PrivateLink の権限の設定
AWS PrivateLink を設定するには、複数の認証情報が必要です。これらの認証情報に必要な権限は、認証情報のタイプによって異なります。
ClusterDeployment の認証情報には、以下の権限が必要です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow エンドポイント VPC アカウントの HiveConfig の認証情報
.spec.awsPrivateLink.credentialsSecretRefには、以下の権限が必要です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow VPC をプライベートホストゾーンに関連付けるために
HiveConfigカスタムリソースに指定された認証情報 (.spec.awsPrivateLink.associatedVPCs[$idx].credentialsSecretRef)。VPC が置かれているアカウントには、以下の権限が必要です。route53:AssociateVPCWithHostedZone route53:DisassociateVPCFromHostedZone ec2:DescribeVPCs
route53:AssociateVPCWithHostedZone route53:DisassociateVPCFromHostedZone ec2:DescribeVPCsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
ハブクラスターの Hive namespace 内に認証情報シークレットがあることを確認します。
HiveConfig カスタムリソースは、特定の提供される VPC でリソースを作成する権限を持つ Hive namespace 内で認証情報を参照する必要があります。AWS GovCloud での AWS クラスターのプロビジョニングに使用する認証情報がすでに Hive namespace にある場合は、別の認証情報を作成する必要はありません。AWS GovCloud での AWS クラスターのプロビジョニングに使用する認証情報がまだ Hive namespace にない場合、現在の認証情報を置き換えるか、Hive namespace に追加の認証情報を作成できます。
HiveConfig カスタムリソースには、以下の内容が含まれている必要があります。
- 指定された VPC のリソースをプロビジョニングするために必要な権限を持つ AWS GovCloud 認証情報。
OpenShift Container Platform クラスターインストールの VPC のアドレス、およびマネージドクラスターのサービスエンドポイント。
ベストプラクティス: OpenShift Container Platform クラスターのインストールおよびサービスエンドポイントに異なる VPC を使用します。
以下の例は、認証情報の内容を示しています。
AWS PrivateLink が endpointVPCInventory 一覧でサポートされているすべてのリージョンから VPC を含めることができます。コントローラーは、ClusterDeployment の要件を満たす VPC を選択します。
詳細は、Hive ドキュメント を参照してください。
1.7.3.4.3. コンソールを使用したクラスターの作成
コンソールからクラスターを作成するには、Infrastructure > Clusters > Create cluster AWS > Standalone に移動して、コンソールで手順を実行します。
注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、クラスターのインポート でインポート手順を参照してください。
AWS GovCloud クラスターを作成する場合、選択する認証情報は AWS GovCloud リージョンのリソースにアクセスできる必要があります。クラスターをデプロイするために必要な権限を持つ場合は、Hive namespace にある AWS GovCloud シークレットを使用できます。コンソールに既存の認証情報が表示されます。認証情報を作成する必要がある場合は、Amazon Web Services の認証情報の作成 を参照してください。
クラスターの名前はクラスターのホスト名で使用されます。
重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。
ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。
クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。
マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。
AWS または AWS GovCloud アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。この名前はクラスターのホスト名で使用されます。詳細は、AWS へのインストール を参照してください。
このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細は、リリースイメージ を参照してください。
ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。情報には以下のフィールドが含まれます。
-
リージョン: クラスターリソースを作成するリージョン。AWS GovCloud プロバイダーでクラスターを作成する場合、ノードプールの AWS GovCloud リージョンを含める必要があります。たとえば、
us-gov-west-1です。 - CPU アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および arm64 です。
- ゾーン: コントロールプレーンプールを実行する場所を指定します。より分散されているコントロールプレーンノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
- インスタンスタイプ: コントロールプレーンノードのインスタンスタイプを指定します。これは、以前に指定した CPU アーキテクチャー と同じにする必要があります。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
- ルートストレージ: クラスターに割り当てるルートストレージの量を指定します。
ワーカープールにワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。オプションの情報には以下のフィールドが含まれます。
- プール名: プールの一意の名前を指定します。
- ゾーン: ワーカープールを実行する場所を指定します。より分散されているノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
- インスタンスタイプ: ワーカープールのインスタンスタイプを指定します。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
- ノード数: ワーカープールのノード数を指定します。ワーカープールを定義する場合にこの設定は必須です。
- ルートストレージ: ワーカープールに割り当てるルートストレージの量を指定します。ワーカープールを定義する場合にこの設定は必須です。
クラスターにはネットワークの詳細が必要であり、IPv6 を使用するには複数のネットワークが必要です。AWS GovCloud クラスターの場合は、Machine CIDR フィールドに Hive VPC のアドレスのブロックの値を入力します。Add network をクリックして、追加のネットワークを追加できます。
認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。
-
HTTP プロキシー URL:
HTTPトラフィックのプロキシーとして使用する URL を指定します。 -
HTTPS プロキシー URL:
HTTPSトラフィックに使用するセキュアなプロキシー URL を指定します。値の指定がない場合は、HTTP Proxy URLと同じ値がHTTPおよびHTTPSの両方に使用されます。 -
プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
AWS GovCloud クラスターを作成するか、プライベート環境を使用する場合は、AMI ID およびサブネット値を使用して、AWS プライベート設定 ページのフィールドに入力します。ClusterDeployment.yaml ファイルで spec:platform:aws:privateLink:enabled の値が true に設定されていることを確認します。これは、Use private configuration を選択すると自動的に設定されます。
クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML: On を選択して、パネルに install-config.yaml ファイルの内容を表示できます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。
注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、そのクラスターは multicluster engine for Kubernetes Operator の管理下で自動的に設定されます。
Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。
クラスターにアクセスする 手順は、クラスターへのアクセスに進みます。
1.7.3.5. Microsoft Azure でのクラスターの作成
multicluster engine Operator コンソールを使用して、Microsoft Azure または Microsoft Azure Government に Red Hat OpenShift Container Platform クラスターをデプロイできます。
クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの Azure へのインストール でプロセスの詳細を確認してください。
1.7.3.5.1. 前提条件
Azure でクラスターを作成する前に、以下の前提条件を確認してください。
- ハブクラスターをデプロイしている。
- Azure 認証情報がある。詳細は、Microsoft Azure の認証情報の作成 を参照してください。
- Azure または Azure Government に設定済みドメインがある。ドメイン設定の方法は、Configuring a custom domain name for an Azure cloud service を参照してください。
- ユーザー名とパスワードなどの Azure ログイン認証情報がある。Microsoft Azure Portal を参照してください。
-
clientId、clientSecretおよびtenantIdなどの Azure サービスプリンシパルがある。azure.microsoft.com を参照してください。 - OpenShift Container Platform イメージプルシークレットがある。イメージプルシークレットの使用 を参照してください。
注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、multicluster engine Operator のコンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。
1.7.3.5.2. コンソールを使用したクラスターの作成
multicluster engine Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。
注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、クラスターのインポート でインポート手順を参照してください。
認証情報を作成する必要がある場合は、Microsoft Azure の認証情報の作成 に記載される詳細を参照してください。
クラスターの名前はクラスターのホスト名で使用されます。
重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。
ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。
クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。
マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。
Azure アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。詳細は、Configuring a custom domain name for an Azure cloud service を参照してください。この名前はクラスターのホスト名で使用されます。
このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細は、リリースイメージ を参照してください。
ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。この情報には、次のオプションフィールドが含まれます。
- リージョン: ノードプールを実行するリージョンを指定します。より分散されているコントロールプレーンノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
- CPU アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および arm64 です。
クラスターの作成後に、コントロールプレーンプールのタイプおよびルートストレージの割り当て (必須) を変更できます。
ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。
- ゾーン: ワーカープールを実行することを指定します。より分散されているノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
- インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。
Add network をクリックして、追加のネットワークを追加できます。IPv6 アドレスを使用している場合は、複数のネットワークが必要です。
認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。
-
HTTP プロキシー:
HTTPトラフィックのプロキシーとして使用する URL。 -
HTTPS プロキシー:
HTTPSトラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URLと同じ値がHTTPおよびHTTPSの両方に使用されます。 -
プロキシーなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML スイッチをクリックして On にすると、パネルに install-config.yaml ファイルの内容が表示されます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。
Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。
注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、multicluster engine Operator で管理されるように自動的に設定されます。
クラスターにアクセスする 手順は、クラスターへのアクセスに進みます。
1.7.3.6. Google Cloud Platform でのクラスターの作成
Google Cloud Platform (GCP) で Red Hat OpenShift Container Platform クラスターを作成する手順に従います。GCP の詳細は、Google Cloud Platform を参照してください。
クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの GCP へのインストール でプロセスの詳細を確認してください。
1.7.3.6.1. 前提条件
GCP でクラスターを作成する前に、次の前提条件を確認してください。
- ハブクラスターをデプロイしている。
- GCP 認証情報がある。詳細は、Google Cloud Platform の認証情報の作成 を参照してください。
- GCP に設定済みのドメインがある。ドメインの設定方法は、Setting up a custom domain を参照してください。
- ユーザー名とパスワードを含む GCP ログイン認証情報がある。
- OpenShift Container Platform イメージのプルシークレットがある。イメージプルシークレットの使用 を参照してください。
注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、multicluster engine Operator のコンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。
1.7.3.6.2. コンソールを使用したクラスターの作成
multicluster engine Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。
注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、クラスターのインポート でインポート手順を参照してください。
認証情報を作成する必要がある場合は、Google Cloud Platform の認証情報の作成 を参照してください。
クラスターの名前はクラスターのホスト名で使用されます。GCP クラスターの命名に適用される制限がいくつかあります。この制限には、名前を goog で開始しないことや、名前に google に類似する文字および数字のグループが含まれないことなどがあります。制限の完全な一覧は、Bucket naming guidelines を参照してください。
重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。
ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。
クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。
マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。
選択した GCP アカウントの認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。詳細は、Setting up a custom domain を参照してください。この名前はクラスターのホスト名で使用されます。
このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細は、リリースイメージ を参照してください。
ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。情報には以下のフィールドが含まれます。
- リージョン: コントロールプレーンプールを実行するリージョンを指定します。リージョンが近くにある場合はパフォーマンスの速度が向上しますが、リージョンの距離が離れると、より分散されます。
- CPU アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および arm64 です。
コントロールプレーンプールのインスタンスタイプを指定できます。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。
- インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。
- ノード数: ワーカープールを定義するときに必要な設定です。
ネットワークの詳細が必要であり、IPv6 アドレスを使用するには複数のネットワークが必要です。Add network をクリックして、追加のネットワークを追加できます。
認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。
-
HTTP プロキシー:
HTTPトラフィックのプロキシーとして使用する URL。 -
HTTPS プロキシー:
HTTPSトラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URLと同じ値がHTTPおよびHTTPSの両方に使用されます。 -
プロキシーサイトなし: プロキシーをバイパスする必要のあるサイトのコンマ区切りリスト。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML: On を選択して、パネルに install-config.yaml ファイルの内容を表示できます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。
Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。
注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、multicluster engine Operator で管理されるように自動的に設定されます。
クラスターにアクセスする 手順は、クラスターへのアクセスに進みます。
1.7.3.7. VMware vSphere でのクラスターの作成
multicluster engine Operator コンソールを使用して、VMware vSphere に Red Hat OpenShift Container Platform クラスターをデプロイできます。
クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順を完了した後のクラスター作成の詳細は、OpenShift Container Platform ドキュメントの VMware vSphere へのインストール を参照してください。
1.7.3.7.1. 前提条件
vSphere でクラスターを作成する前に、次の前提条件を確認してください。
- サポートされている OpenShift Container Platform バージョンにハブクラスターがデプロイされている。
- vSphere 認証情報がある。詳細は、VMware vSphere の認証情報の作成 を参照してください。
- OpenShift Container Platform イメージプルシークレットがある。イメージプルシークレットの使用 を参照してください。
デプロイする VMware インスタンスについて、以下の情報がある。
- API および Ingress インスタンスに必要な静的 IP アドレス
以下の DNS レコード。
次の API ベースドメインは静的 API VIP を指す必要があります。
api.<cluster_name>.<base_domain>
api.<cluster_name>.<base_domain>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
*.apps.<cluster_name>.<base_domain>のアプリケーションベースドメインは、Ingress 仮想 IP の静的 IP アドレスを指している必要があります。
1.7.3.7.2. コンソールを使用したクラスターの作成
multicluster engine Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。
注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、クラスターのインポート でインポート手順を参照してください。
認証情報を作成する必要がある場合は、認証情報の作成の詳細について、VMware vSphere の認証情報の作成 を参照してください。
クラスターの名前はクラスターのホスト名で使用されます。
重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。
ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。
クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。
マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。
vSphere アカウントで設定した、選択した認証情報に関連付けられているベースドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。詳細は、カスタマイズによる vSphere へのクラスターのインストール を参照してください。値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。この名前はクラスターのホスト名で使用されます。
このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細は、リリースイメージ を参照してください。
注記: サポートされている OpenShift Container Platform バージョンのリリースイメージを選択してください。
ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。この情報には、CPU アーキテクチャー フィールドが含まれます。次のフィールドの説明を表示します。
- CPU アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および arm64 です。
ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。この情報には、ソケットあたりのコア数、CPU、Memory_min MiB、GiB 単位の _Disk サイズ、および ノード数 が含まれます。
ネットワーク情報が必要です。IPv6 を使用するには、複数のネットワークが必要です。必要なネットワーク情報の一部は、次のフィールドに含まれています。
- vSphere ネットワーク名: VMware vSphere ネットワーク名を指定します。
API VIP: 内部 API 通信に使用する IP アドレスを指定します。
注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して
api.が正しく解決されるようにします。Ingress VIP: Ingress トラフィックに使用する IP アドレスを指定します。
注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して
test.apps.が正しく解決されるようにします。
Add network をクリックして、追加のネットワークを追加できます。IPv6 アドレスを使用している場合は、複数のネットワークが必要です。
認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。
-
HTTP プロキシー:
HTTPトラフィックのプロキシーとして使用する URL を指定します。 -
HTTPS プロキシー:
HTTPSトラフィックに使用するセキュアなプロキシー URL を指定します。値の指定がない場合は、HTTP Proxy URLと同じ値がHTTPおよびHTTPSの両方に使用されます。 -
プロキシーサイトなし: プロキシーをバイパスする必要のあるサイトのコンマ区切りリストを指定します。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
非接続インストールを定義するには、Disconnected installation をクリックします。VMware vSphere プロバイダーと非接続インストールを使用してクラスターを作成する際に、ミラーレジストリーにアクセスするための証明書が必要な場合は、クラスターを作成する際の認証情報または Disconnected installation セクションを設定するときに、Configuration for disconnected installation セクションの Additional trust bundle フィールドにその証明書を入力する必要があります。
Add automation template をクリックしてテンプレートを作成できます。
クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML スイッチをクリックして On にすると、パネルに install-config.yaml ファイルの内容が表示されます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。
Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。
注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、multicluster engine Operator で管理されるように自動的に設定されます。
クラスターにアクセスする 手順は、クラスターへのアクセスに進みます。
1.7.3.8. Red Hat OpenStack Platform でのクラスターの作成
multicluster engine Operator コンソールを使用して、Red Hat OpenStack Platform に Red Hat OpenShift Container Platform クラスターをデプロイできます。
クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの OpenStack へのインストール でプロセスの詳細を確認してください。
1.7.3.8.1. 前提条件
Red Hat OpenStack Platform でクラスターを作成する前に、以下の前提条件を確認してください。
- OpenShift Container Platform バージョン 4.6 以降にデプロイされたハブクラスターが必要です。
- Red Hat OpenStack Platform の認証情報がある。詳細は、Red Hat OpenStack Platform の認証情報の作成 を参照してください。
- OpenShift Container Platform イメージプルシークレットがある。イメージプルシークレットの使用 を参照してください。
デプロイする Red Hat OpenStack Platform インスタンスに関する以下の情報がある。
-
コントロールプレーンとワーカーインスタンスのフレーバー名 (例:
m1.xlarge) - Floating IP アドレスを提供する外部ネットワークのネットワーク名
- API および Ingress インスタンスに必要な静的 IP アドレス
以下の DNS レコード。
次の API ベースドメインは、API のフローティング IP アドレスを指す必要があります。
api.<cluster_name>.<base_domain>
api.<cluster_name>.<base_domain>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のアプリケーションベースドメインは、ingress:app-name のフローティング IP アドレスを指す必要があります。
*.apps.<cluster_name>.<base_domain>
*.apps.<cluster_name>.<base_domain>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
コントロールプレーンとワーカーインスタンスのフレーバー名 (例:
1.7.3.8.2. コンソールを使用したクラスターの作成
multicluster engine Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。
注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、クラスターのインポート でインポート手順を参照してください。
認証情報を作成する必要がある場合は、Red Hat OpenStack Platform の認証情報の作成 を参照してください。
クラスターの名前はクラスターのホスト名で使用されます。名前には 15 文字以上指定できません。値は、認証情報の要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。
重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。
ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。
クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。
マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。
Red Hat OpenStack Platform アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。詳細は、Red Hat OpenStack Platform ドキュメントの ドメインの管理 を参照してください。この名前はクラスターのホスト名で使用されます。
このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細は、リリースイメージ を参照してください。OpenShift Container Platform バージョン 4.6.x 以降のリリースイメージのみがサポートされます。
ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および arm64 です。
コントロールプレーンプールのインスタンスタイプを追加する必要がありますが、インスタンスの作成後にインスタンスのタイプとサイズを変更できます。
ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。
- インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。
- ノード数: ワーカープールのノード数を指定します。ワーカープールを定義する場合にこの設定は必須です。
クラスターにはネットワークの詳細が必要です。IPv4 ネットワーク用に 1 つ以上のネットワークの値を指定する必要があります。IPv6 ネットワークの場合は、複数のネットワークを定義する必要があります。
Add network をクリックして、追加のネットワークを追加できます。IPv6 アドレスを使用している場合は、複数のネットワークが必要です。
認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。
-
HTTP プロキシー:
HTTPトラフィックのプロキシーとして使用する URL を指定します。 -
HTTPS プロキシー:
HTTPSトラフィックに使用するセキュアなプロキシー URL。値が指定されていない場合、HTTP Proxyと同じ値がHTTPとHTTPSの両方に使用されます。 -
プロキシーなし: プロキシーをバイパスする必要のあるサイトのコンマ区切りリストを定義します。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
Disconnected installation をクリックして、オフラインインストールイメージを定義できます。Red Hat OpenStack Platform プロバイダーとオフラインインストールを使用してクラスターを作成する際に、ミラーレジストリーにアクセスするための証明書が必要な場合は、クラスターを作成する際の認証情報または Disconnected installation セクションを設定するときに、Configuration for disconnected installation セクションの Additional trust bundle フィールドにその証明書を入力する必要があります。
クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML スイッチをクリックして On にすると、パネルに install-config.yaml ファイルの内容が表示されます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。
内部認証局 (CA) を使用するクラスターを作成する場合、以下の手順を実行してクラスターの YAML ファイルをカスタマイズする必要があります。
レビューステップで YAML スイッチをオンにし、CA 証明書バンドルを使用してリストの上部に
Secretオブジェクトを挿入します。注記: Red Hat OpenStack Platform 環境が複数の機関によって署名された証明書を使用してサービスを提供する場合、バンドルには、必要なすべてのエンドポイントを検証するための証明書を含める必要があります。ocp3という名前のクラスターの追加は以下の例のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のように、Hive
ClusterDeploymentオブジェクトを変更して、spec.platform.openstackにcertificatesSecretRefの値を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の例では、
clouds.yamlファイルのクラウド名がopenstackであることを前提としています。
Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。
注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、multicluster engine Operator で管理されるように自動的に設定されます。
クラスターにアクセスする 手順は、クラスターへのアクセスに進みます。
1.7.3.9. オンプレミス環境でのクラスターの作成
コンソールを使用して、オンプレミスの Red Hat OpenShift Container Platform クラスターを作成できます。シングルノード OpenShift クラスター、マルチノードクラスター、コンパクトな 3 ノードクラスターを作成できます。これらのクラスターを、VMware vSphere、Red Hat OpenStack、Nutanix、外部環境、またはベアメタル環境で作成できます。
プラットフォームの値が platform=none に設定されているため、クラスターのインストール先プラットフォームとのプラットフォーム統合は行われません。シングルノード OpenShift クラスターには、コントロールプレーンサービスとユーザーワークロードをホストするノードが 1 つだけ含まれます。クラスターのリソースフットプリントを最小限に抑える場合は、この構成を使用します。
Red Hat OpenShift Container Platform で利用できる機能であるゼロタッチプロビジョニング機能を使用して、エッジリソース上に複数のシングルノード OpenShift クラスターをプロビジョニングすることもできます。ゼロタッチプロビジョニングの詳細は、OpenShift Container Platform ドキュメントの ネットワークファーエッジのクラスター を参照してください。
1.7.3.9.1. 前提条件
オンプレミス環境にクラスターを作成する前に、以下の前提条件を確認してください。
- サポートされている OpenShift Container Platform バージョンにハブクラスターがデプロイされている。
- 設定済みホストのホストインベントリーを備えた設定済みインフラストラクチャー環境がある。
- クラスターの作成に必要なイメージを取得できるように、ハブクラスターにインターネットアクセスがある (接続環境) か、インターネットに接続されている内部レジストリーまたはミラーレジストリーへの接続がある (非接続環境)。
- オンプレミス認証情報が設定されている。
- OpenShift Container Platform イメージプルシークレットがある。イメージプルシークレットの使用 を参照してください。
次の DNS レコードが必要です。
次の API ベースドメインは静的 API VIP を指す必要があります。
api.<cluster_name>.<base_domain>次のアプリケーションベースドメインは、Ingress VIP の静的 IP アドレスを指す必要があります。
*.apps.<cluster_name>.<base_domain>
-
ハブクラスターの
KubeAPIServer証明書検証ストラテジーを確認し、必要に応じてストラテジーを更新します。セットアップに応じてどのストラテジーを使用すべきかは、ハブクラスターのKubeAPIServer検証ストラテジーの設定 を参照してください。
1.7.3.9.2. コンソールを使用したクラスターの作成
コンソールからクラスターを作成するには、次の手順を実行します。
- Infrastructure > Clusters に移動します。
- Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。
- クラスターのタイプとして Host inventory を選択します。
支援インストールでは、次のオプションを使用できます。
- 既存の検出されたホストを使用する: 既存のホストインベントリーにあるホストのリストからホストを選択します。
- 新規ホストの検出: 既存のインフラストラクチャー環境にないホストを検出します。インフラストラクチャー環境にあるものを使用するのではなく、独自のホストを検出します。
認証情報を作成する必要がある場合、詳細は オンプレミス環境の認証情報の作成 を参照してください。
クラスターの名前は、クラスターのホスト名で使用されます。
重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。
注記: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。
クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。
マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。
プロバイダーアカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は上書きすると変更できますが、この設定はクラスターの作成後には変更できません。プロバイダーのベースドメインは、Red Hat OpenShift Container Platform クラスターコンポーネントへのルートの作成に使用されます。これは、クラスタープロバイダーの DNS で Start of Authority (SOA) レコードとして設定されます。
OpenShift version は、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。詳細は、リリースイメージ を参照してください。
サポート対象の OpenShift Container Platform バージョンを選択すると、Install single node OpenShift を選択するオプションが表示されます。シングルノード OpenShift クラスターには、コントロールプレーンサービスとユーザーワークロードをホストするシングルノードが含まれます。シングルノード OpenShift クラスターの作成後にノードを追加する方法の詳細は、インフラストラクチャー環境へのホストのスケーリング を参照してください。
クラスターをシングルノード OpenShift クラスターにする場合は、シングルノード OpenShift オプションを選択します。以下の手順を実行することで、シングルノードの OpenShift クラスターにワーカーを追加できます。
- コンソールから、Infrastructure > Clusters に移動し、作成したクラスターまたはアクセスするクラスターの名前を選択します。
- Actions > Add hosts を選択して、ワーカーを追加します。
注記: シングルノード OpenShift コントロールプレーンには 8 つの CPU コアが必要ですが、マルチノードコントロールプレーンクラスターのコントロールプレーンノードには 4 つの CPU コアしか必要ありません。
クラスターを確認して保存すると、クラスターはドラフトクラスターとして保存されます。Clusters ページでクラスター名を選択すると、作成プロセスを閉じてプロセスを終了することができます。
既存のホストを使用している場合は、ホストを独自に選択するか、自動的に選択するかどうかを選択します。ホストの数は、選択したノード数に基づいています。たとえば、シングルノード OpenShift クラスターではホストが 1 つだけ必要ですが、標準の 3 ノードクラスターには 3 つのホストが必要です。
このクラスターの要件を満たす利用可能なホストの場所は、ホストの場所 のリストに表示されます。ホストと高可用性設定の分散には、複数の場所を選択します。
既存のインフラストラクチャー環境がない新しいホストを検出する場合は、Discovery Image を使用したホストインベントリーへのホストの追加 の手順を実行します。
ホストがバインドされ、検証に合格したら、以下の IP アドレスを追加してクラスターのネットワーク情報を入力します。
API VIP: 内部 API 通信に使用する IP アドレスを指定します。
注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して
api.が正しく解決されるようにします。Ingress VIP: Ingress トラフィックに使用する IP アドレスを指定します。
注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して
test.apps.が正しく解決されるようにします。
Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。
Clusters ナビゲーションページで、インストールのステータスを表示できます。
クラスターにアクセスする 手順は、クラスターへのアクセスに進みます。
1.7.3.9.3. コマンドラインを使用したクラスターの作成
Central Infrastructure Management 管理コンポーネント内のアシステッドインストーラー機能を使用して、コンソールを使用せずにクラスターを作成することもできます。この手順を完了したら、生成された検出イメージからホストを起動できます。通常、手順の順序は重要ではありませんが、順序が必要な場合は注意してください。
1.7.3.9.3.1. namespace を作成します。
リソースの namespace が必要です。すべてのリソースを共有 namespace に保持すると便利です。この例では、namespace の名前に sample-namespace を使用していますが、assisted-installer 以外の任意の名前を使用できます。次のファイルを作成して適用して namespace を作成します。
apiVersion: v1 kind: Namespace metadata: name: sample-namespace
apiVersion: v1
kind: Namespace
metadata:
name: sample-namespace1.7.3.9.3.2. プルシークレットを namespace に追加する
以下のカスタムリソースを作成し、適用して プルシークレット を namespace に追加します。
- 1
- プルシークレットの内容を追加します。たとえば、これには
cloud.openshift.com、quay.io、またはregistry.redhat.io認証を含めることができます。
1.7.3.9.3.3. ClusterImageSet の生成
以下のカスタムリソースを作成して適用することで、CustomImageSet を生成してクラスターの OpenShift Container Platform のバージョンを指定します。name と releaseImage の両方について、<4.x.0> を ClusterImageSet に使用しているサポートされているバージョンに置き換えます。
注記: ハブクラスターとは異なるアーキテクチャーを持つマネージドクラスターをインストールする場合は、マルチアーキテクチャーの ClusterImageSet を作成する必要があります。詳細は、別のアーキテクチャーにクラスターをデプロイするためのリリースイメージの作成 を参照してください。
1.7.3.9.3.4. ClusterDeployment カスタムリソースを作成します。
ClusterDeployment カスタムリソース定義は、クラスターのライフサイクルを制御する API です。これは、クラスターリソースを定義する spec.ClusterInstallRef 設定で AgentClusterInstall カスタムリソースを参照します。
以下の例に基づいて ClusterDeployment カスタムリソースを作成して適用します。
- 1
AgentClusterInstallリソースの名前を使用します。- 2
- Add the pull secret to the namespace でダウンロードしたプルシークレットを使用します。
1.7.3.9.3.5. AgentClusterInstall カスタムリソースを作成します。
AgentClusterInstall カスタムリソースでは、クラスターの要件の多くを指定できます。たとえば、クラスターネットワーク設定、プラットフォーム、コントロールプレーンの数、およびワーカーノードを指定できます。
次の例のようなカスタムリソースを作成して追加します。
- 1
- クラスターが作成される環境のプラットフォームタイプを指定します。可能な値は、
BareMetal、None、VSphere、Nutanix、またはExternalです。 - 2
ClusterDeploymentリソースに使用したものと同じ名前を使用します。- 3
- Generate a ClusterImageSet で生成した
ClusterImageSetを使用します。 - 4
- 使用できる値は
1および3です。OpenShift Container Platform バージョン 4.18 以降を使用しており、platformTypeフィールドがBareMetalまたはNoneに設定されており、CPU アーキテクチャーがx86_64である場合は、4と5も使用できます。コントロールプレーンノードはワークロードを管理し、クラスターの状態を維持し、安定性を確保します。3 つ以上のノードを使用すると、フォールトトレランスと可用性が向上し、障害時のダウンタイムが短縮されます。 - 5
- インストール後にホストにアクセスできるようにする 1 つまたは複数の SSH 公開鍵を指定できます。
platformType: を External に設定する場合は、external spec を追加する必要があります。以下の例を参照してください。
1.7.3.9.3.6. オプション: NMStateConfig カスタムリソースを作成する
NMStateConfig カスタムリソースは、静的 IP アドレスなどのホストレベルのネットワーク設定がある場合にのみ必要です。NMStateConfig カスタムリソースを作成する場合は、InfraEnv カスタムリソースを作成する前にこの手順を完了する必要があります。InfraEnv カスタムリソースの spec.nmStateConfigLabelSelector の値は、NMStateConfig カスタムリソースを参照します。
次の例のような NMStateConfig カスタムリソースを作成して適用します。必要に応じて値を置き換えます。
重要:
-
InfraEnvカスタムリソースのspec.nmStateConfigLabelSelector.matchLabelsフィールドに、demo-nmstate-labelのラベル名と値を含める必要があります。 - DHCP または静的ネットワークプロトコルを使用する場合は、MAC アドレスを追加する必要があります。
spec.config フィールドに追加できる NMState の追加の例は、OpenShift Container Platform Assisted Installer ドキュメントの 追加の NMState 設定例 を参照してください。
1.7.3.9.3.7. InfraEnv カスタムリソースを作成します。
InfraEnv カスタムリソースは、検出 ISO を作成する設定を提供します。このカスタムリソース内で、プロキシー設定、Ignition オーバーライドの値を特定し、NMState ラベルを指定します。このカスタムリソースの spec.nmStateConfigLabelSelector の値は、NMStateConfig カスタムリソースを参照します。
注: オプションの NMStateConfig カスタムリソースを含める場合は、InfraEnv カスタムリソースでそちらを参照する必要があります。NMStateConfig カスタムリソースを作成する前に InfraEnv カスタムリソースを作成した場合は、InfraEnv カスタムリソースを編集して NMStateConfig カスタムリソースを参照し、参照の追加後に ISO をダウンロードします。
以下のカスタムリソースを作成して適用します。
- 1
- Create the ClusterDeployment の
clusterDeploymentリソース名を置き換えます。 - 2
- ClusterDeployment の作成 の
clusterDeploymentリソース namespace を置き換えます。
1.7.3.9.3.7.1. InfraEnv のフィールドの表
| フィールド | 任意または必須 | 説明 |
|---|---|---|
|
| 任意 | SSH 公開鍵を指定できます。指定すると、検出 ISO イメージからホストを起動するときにホストにアクセスできるようになります。 |
|
| 任意 |
ホストの静的 IP、ブリッジ、ボンディングなどの高度なネットワーク設定を統合します。ホストネットワーク設定は、選択したラベルを持つ 1 つ以上の |
|
| 任意 | proxy セクションでは、検出中にホストに必要なプロキシー設定を指定できます。 |
注記: IPv6 を使用してプロビジョニングする場合、noProxy 設定で CIDR アドレスブロックを定義することはできません。各アドレスを個別に定義する必要があります。
1.7.3.9.3.8. 検出イメージからホストを起動します。
残りの手順では、前の手順で取得した検出 ISO イメージからホストを起動する方法を説明します。
次のコマンドを実行して、namespace から検出イメージをダウンロードします。
curl --insecure -o image.iso $(kubectl -n sample-namespace get infraenvs.agent-install.openshift.io myinfraenv -o=jsonpath="{.status.isoDownloadURL}")curl --insecure -o image.iso $(kubectl -n sample-namespace get infraenvs.agent-install.openshift.io myinfraenv -o=jsonpath="{.status.isoDownloadURL}")Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 検出イメージを仮想メディア、USB ドライブ、または別の保管場所に移動し、ダウンロードしたディスカバリーイメージからホストを起動します。
Agentリソースは自動的に作成されます。これはクラスターに登録されており、検出イメージから起動したホストを表します。次のコマンドを実行して、Agentのカスタムリソースを承認し、インストールを開始します。oc -n sample-namespace patch agents.agent-install.openshift.io 07e80ea9-200c-4f82-aff4-4932acb773d4 -p '{"spec":{"approved":true}}' --type mergeoc -n sample-namespace patch agents.agent-install.openshift.io 07e80ea9-200c-4f82-aff4-4932acb773d4 -p '{"spec":{"approved":true}}' --type mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow エージェント名と UUID は、実際の値に置き換えます。
前のコマンドの出力に、
APPROVEDパラメーターの値がtrueであるターゲットクラスターのエントリーが含まれている場合、承認されたことを確認できます。
1.7.3.9.4. 関連情報
- CLI を使用して Nutanix プラットフォーム上にクラスターを作成するときに必要な追加の手順は、Red Hat OpenShift Container Platform ドキュメントの API を使用した Nutanix へのホストの追加 および Nutanix インストール後の設定 を参照してください。
- ゼロタッチプロビジョニングの詳細は、OpenShift Container Platform ドキュメントの ネットワークファーエッジのクラスター を参照してください。
- イメージプルシークレットの使用 を参照してください。
- オンプレミス環境の認証情報の作成 を参照してください。
- リリースイメージ を参照してください。
- Discovery Image を使用したホストのホストインベントリーへの追加 を参照してください。
1.7.3.10. プロキシー環境でのクラスターの作成
ハブクラスターがプロキシーサーバー経由で接続されている場合は、Red Hat OpenShift Container Platform クラスターを作成できます。クラスターを正常に作成するには、以下のいずれかの状況に該当している必要があります。
- multicluster engine Operator に、作成するマネージドクラスターとのプライベートネットワーク接続があり、マネージドクラスターがプロキシーを使用してインターネットにアクセスできる。
- マネージドクラスターはインフラストラクチャープロバイダーにあるが、ファイアウォールポートを使用することでマネージドクラスターからハブクラスターへの通信が可能になる。
プロキシーで設定されたクラスターを作成するには、以下の手順を実行します。
シークレットに保存されている
install-configYAML に次の情報を追加して、ハブクラスターでcluster-wide-proxy設定を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow usernameは、プロキシーサーバーのユーザー名に置き換えます。passwordは、プロキシーサーバーへのアクセス時に使用するパスワードに置き換えます。proxy.example.comは、プロキシーサーバーのパスに置き換えます。portは、プロキシーサーバーとの通信ポートに置き換えます。wildcard-of-domainは、プロキシーをバイパスするドメインのエントリーに置き換えます。provisioning-network/CIDRは、プロビジョニングネットワークの IP アドレスと割り当てられた IP アドレスの数 (CIDR 表記) に置き換えます。BMC-address-range/CIDRは、BMC アドレスおよびアドレス数 (CIDR 表記) に置き換えます。- クラスターの作成手順を実行してクラスターをプロビジョニングします。クラスターの作成 を参照してプロバイダーを選択します。
注: install-config YAML は、クラスターをデプロイする場合にのみ使用できます。クラスターをデプロイした後、install-config YAML に加えた新しい変更は適用されません。導入後に設定を更新するには、ポリシーを使用する必要があります。詳細は、Pod ポリシー を参照してください。
1.7.3.10.1. 関連情報
1.7.3.11. AgentClusterInstall プロキシーの設定
AgentClusterInstall プロキシーフィールドは、インストール中のプロキシー設定を決定し、作成されたクラスターにクラスター全体のプロキシーリソースを作成するために使用されます。
1.7.3.11.1. AgentClusterInstall の設定
AgentClusterInstall プロキシーを設定するには、プロキシー 設定を AgentClusterInstall リソースに追加します。httpProxy、httpsProxy、noProxy を使用した次の YAML サンプルを参照してください。
- 1
httpProxyは、HTTP リクエストのプロキシーの URL です。ユーザー名とパスワードの値は、プロキシーサーバーの認証情報に置き換えます。proxy.example.comは、プロキシーサーバーのパスに置き換えます。- 2
httpsProxyは、HTTPS リクエストのプロキシーの URL です。値を自分の認証情報に置き換えます。portは、プロキシーサーバーとの通信ポートに置き換えます。- 3
noProxyは、プロキシーを使用しないドメインと CIDR のコンマ区切りリストです。wildcard-of-domainは、プロキシーをバイパスするドメインのエントリーに置き換えます。provisioning-network/CIDRは、プロビジョニングネットワークの IP アドレスと割り当てられた IP アドレスの数 (CIDR 表記) に置き換えます。BMC-address-range/CIDRは、BMC アドレスおよびアドレス数 (CIDR 表記) に置き換えます。
1.7.3.11.2. 関連情報
1.7.4. クラスターのインポート
別の Kubernetes クラウドプロバイダーからクラスターをインポートできます。インポート後、ターゲットのクラスターが multicluster engine Operator ハブクラスターのマネージドクラスターになります。特に指定されていない限りは通常、ハブクラスターとターゲットのマネージドクラスターにアクセスできる場所で、インポートタスクを実行できます。
- ハブクラスターは 他 のハブクラスターの管理はできず、自己管理のみが可能です。ハブクラスターは、自動的にインポートして自己管理できるように設定されています。ハブクラスターは手動でインポートする必要はありません。
-
ハブクラスターを削除して再度インポートする場合は、
local-cluster:trueラベルをManagedClusterリソースに追加する必要があります。
重要: クラスターライフサイクルで、Cloud Native Computing Foundation (CNCF) Kubernetes Conformance Program を通じて認定されたすべてのプロバイダーがサポートされるようになりました。ハイブリッドクラウドマルチクラスター管理には、CNFC が認定したベンダーを選択してください。
CNFC プロバイダーの使用は、次の情報を参照してください。
- Certified Kubernetes Conformance で CNFC プロバイダーがどのように認定されるかを学びます。
- CNFC サードパーティープロバイダーに関する Red Hat サポート情報は、サードパーティーコンポーネントに関する Red Hat サポート を参照するか、Red Hat サポートへのお問い合わせ を参照してください。
-
独自の CNFC 適合認定クラスターを使用する場合は、OpenShift Container Platform CLI の
ocコマンドを Kubernetes CLI コマンドのkubectlに変更する必要があります。
クラスターを管理できるようにクラスターをインポートする方法の詳細は、次のトピックを参照してください。
必要なユーザータイプまたはアクセスレベル: クラスター管理者
1.7.4.1. コンソールを使用したマネージドクラスターのインポート
multicluster engine for Kubernetes Operator をインストールしたら、クラスターをインポートして管理できるようになります。コンソールを使用してマネージドクラスターをインポートする方法は、以下を参照してください。
1.7.4.1.1. 前提条件
- デプロイされたハブクラスター。ベアメタルクラスターをインポートする場合、サポートされている Red Hat OpenShift Container Platform バージョンにハブクラスターがインストールされている。
- 管理するクラスター。
-
base64コマンドラインツール。 -
OpenShift Container Platform によって作成されていないクラスターをインポートする場合、定義された
multiclusterhub.spec.imagePullSecret。このシークレットは、multicluster engine for Kubernetes Operator のインストール時に作成済みである可能性があります。このシークレットを定義する方法の詳細は、カスタムイメージプルシークレット を参照してください。 -
ハブクラスターの
KubeAPIServer証明書検証ストラテジーを確認し、必要に応じてストラテジーを更新します。セットアップに応じてどのストラテジーを使用すべきかは、ハブクラスターのKubeAPIServer検証ストラテジーの設定 を参照してください。
Required user type or access level: クラスター管理者
1.7.4.1.2. 新規プルシークレットの作成
新しいプルシークレットを作成する必要がある場合は、以下の手順を実行します。
- cloud.redhat.com から Kubernetes プルシークレットをダウンロードします。
- プルシークレットをハブクラスターの namespace に追加します。
次のコマンドを実行して、
open-cluster-managementnamespace に新しいシークレットを作成します。oc create secret generic pull-secret -n <open-cluster-management> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson
oc create secret generic pull-secret -n <open-cluster-management> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow open-cluster-managementをハブクラスターの namespace の名前に置き換えます。ハブクラスターのデフォルトの namespace はopen-cluster-managementです。path-to-pull-secretを、ダウンロードしたプルシークレットへのパスに置き換えます。シークレットは、インポート時にマネージドクラスターに自動的にコピーされます。
-
以前にインストールされたエージェントが、インポートするクラスターから削除されていることを確認します。エラーを回避するには、
open-cluster-management-agentおよびopen-cluster-management-agent-addonnamespace を削除する必要があります。 Red Hat OpenShift Dedicated 環境にインポートする場合には、以下の注意点を参照してください。
- ハブクラスターを Red Hat OpenShift Dedicated 環境にデプロイしている必要があります。
-
Red Hat OpenShift Dedicated のデフォルト権限は dedicated-admin ですが、namespace を作成するための権限がすべて含まれているわけではありません。multicluster engine Operator を使用してクラスターをインポートおよび管理するには、
cluster-admin権限が必要です。
-
以前にインストールされたエージェントが、インポートするクラスターから削除されていることを確認します。エラーを回避するには、
1.7.4.1.3. クラスターのインポート
利用可能なクラウドプロバイダーごとに、コンソールから既存のクラスターをインポートできます。
注記: ハブクラスターは別のハブクラスターを管理できません。ハブクラスターは、自動的にインポートおよび自己管理するように設定されるため、ハブクラスターを手動でインポートして自己管理する必要はありません。
デフォルトでは、namespace がクラスター名と namespace に使用されますが、これは変更できます。
重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。
マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、クラスターは default マネージドクラスターセットに自動的に追加されます。
クラスターを別のクラスターセットに追加する場合は、クラスターセットへの clusterset-admin 権限が必要です。クラスターのインポート時に cluster-admin 権限がない場合は、clusterset-admin 権限を持つクラスターセットを選択する必要があります。指定されたクラスターセットに適切な権限がない場合、クラスターのインポートは失敗します。選択するクラスターセットが存在しない場合は、クラスター管理者に連絡して、クラスターセットへの clusterset-admin 権限を受け取ってください。
OpenShift Container Platform Dedicated クラスターをインポートし、vendor=OpenShiftDedicated のラベルを追加してベンダーを指定しない場合、vendor=auto-detect のラベルを追加すると、managed-by=platform ラベルがクラスターに自動的に追加されます。この追加されたラベルを使用して、クラスターを OpenShift Container Platform Dedicated クラスターとして識別し、OpenShift Container Platform Dedicated クラスターをグループとして取得できます。
以下の表は、クラスターをインポートする方法を指定する インポートモード で使用できるオプションを示しています。
| import コマンドの手動実行 | Red Hat Ansible Automation Platform テンプレートなど、コンソールで情報を完了および送信した後に、提供されたコマンドをターゲットクラスターで実行してクラスターをインポートします。 |
| 既存クラスターのサーバー URL および API トークンを入力します。 | インポートするクラスターのサーバー URL および API トークンを指定します。クラスターのアップグレード時に実行する Red Hat Ansible Automation Platform テンプレートを指定できます。 |
|
|
インポートするクラスターの |
注記: Ansible Automation Platform ジョブを作成して実行するには、OperatorHub から Red Hat Ansible Automation Platform Resource Operator をインストールし、実行する必要があります。
クラスター API アドレスを設定するには、任意: Configuring the cluster API address を参照してください。
マネージドクラスター klusterlet を特定のノードで実行するように設定するには、オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。
1.7.4.1.3.1. オプション: クラスター API アドレスの設定
oc get managedcluster コマンドの実行時に表に表示される URL を設定して、クラスターの詳細ページにある Cluster API アドレス をオプションで設定します。
-
cluster-admin権限がある ID でハブクラスターにログインします。 -
ターゲットに設定されたマネージドクラスターの
kubeconfigファイルを設定します。 次のコマンドを実行して、インポートするクラスターのマネージドクラスターエントリーを編集します。
cluster -nameをマネージドクラスターの名前に置き換えます。oc edit managedcluster <cluster-name>
oc edit managedcluster <cluster-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のように、YAML ファイルの
ManagedCluster仕様にManagedClusterClientConfigsセクションを追加します。spec: hubAcceptsClient: true managedClusterClientConfigs: - url: <https://api.new-managed.dev.redhat.com>
spec: hubAcceptsClient: true managedClusterClientConfigs: - url: <https://api.new-managed.dev.redhat.com>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- URL の値を、インポートするマネージドクラスターへの外部アクセスを提供する URL に置き換えます。
1.7.4.1.3.2. オプション: 特定のノードで実行するように klusterlet を設定する
マネージドクラスターの nodeSelector と tolerations アノテーションを設定することで、マネージドクラスター klusterlet を実行するノードを指定できます。これらを設定するには、次の手順を実行します。
- コンソールのクラスターページから、更新するマネージドクラスターを選択します。
YAML コンテンツを表示するには、YAML スイッチを
Onに設定します。注記: YAML エディターは、クラスターをインポートまたは作成するときにのみ使用できます。インポートまたは作成後にマネージドクラスターの YAML 定義を編集するには、OpenShift Container Platform コマンドラインインターフェイスまたは Red Hat Advanced Cluster Management 検索機能を使用する必要があります。
-
nodeSelectorアノテーションをマネージドクラスターの YAML 定義に追加します。このアノテーションのキーは、open-cluster-management/nodeSelectorです。このアノテーションの値は、JSON 形式の文字列マップです。 tolerationsエントリーをマネージドクラスターの YAML 定義に追加します。このアノテーションのキーは、open-cluster-management/tolerationsです。このアノテーションの値は、JSON 形式の toleration リストを表します。結果の YAML は次の例のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
KlusterletConfig を使用して、マネージドクラスターの nodeSelector と tolerations を設定することもできます。これらを設定するには、次の手順を実行します。
注: KlusterletConfig を使用する場合、マネージドクラスターは、マネージドクラスターのアノテーションの設定ではなく、KlusterletConfig 設定の構成を使用します。
次のサンプル YAML の内容を適用します。必要に応じて値を置き換えます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
agent.open-cluster-management.io/klusterlet-config: `<klusterletconfigName>アノテーションをマネージドクラスターに追加し、<klusterletconfigName>をKlusterletConfigの名前に置き換えます。
1.7.4.1.4. インポートされたクラスターの削除
以下の手順を実行して、インポートされたクラスターと、マネージドクラスターで作成された open-cluster-management-agent-addon を削除します。
Clusters ページで、Actions > Detach cluster をクリックしてマネージメントからクラスターを削除します。
重要: <your-local-cluster-name> という名前のハブクラスターをデタッチしようとする場合、disableHubSelfManagement のデフォルト設定は false であり、ハブクラスターは自己管理する local-cluster であることに注意してください。この設定が原因で、ハブクラスターがデタッチされると、自身を再インポートして管理し、MultiClusterHub コントローラーがリコンサイルされます。ハブクラスターがデタッチプロセスを完了して再インポートするのに時間がかかる場合があります。プロセスが完了するのを待たずにハブクラスターを再インポートする場合は、次のコマンドを実行して multiclusterhub-operator Pod を再起動し、再インポートを高速化できます。
oc -n open-cluster-management delete -l name=multiclusterhub-operator pods
oc -n open-cluster-management delete -l name=multiclusterhub-operator pods
disableHubSelfManagement の値を true に指定して、自動的にインポートされないように、ハブクラスターの値を変更できます。詳細は、disableHubSelfManagement のトピックを参照してください。
1.7.4.1.4.1. 関連情報
- カスタムイメージプルシークレット の定義方法の詳細は、カスタムイメージプルシークレットを参照してください。
- disableHubSelfManagement トピックを参照してください。
1.7.4.2. CLI を使用したマネージドクラスターのインポート
multicluster engine for Kubernetes Operator をインストールしたら、Red Hat OpenShift Container Platform CLI を使用して、クラスターをインポートおよび管理できるようになります。自動インポートシークレットを使用するか、man コマンドを使用して、CLI でマネージドクラスターをインポートする方法は、以下のトピックを参照してください。
重要: ハブクラスターは別のハブクラスターを管理できません。ハブクラスターは、ローカルクラスター として自動的にインポートおよび管理されるようにセットアップされます。ハブクラスターは、手動でインポートして自己管理する必要はありません。ハブクラスターを削除して再度インポートする場合は、local-cluster:true ラベルを追加する必要があります。
1.7.4.2.1. 前提条件
- デプロイされたハブクラスター。ベアメタルクラスターをインポートする場合、サポートされている OpenShift Container Platform バージョンにハブクラスターがインストールされている。
- 管理する別のクラスター。
- OpenShift Container Platform CLI。OpenShift Container Platform CLI のインストールと設定は、OpenShift CLI の使用を開始する を参照してください。
-
OpenShift Container Platform によって作成されていないクラスターをインポートする場合、定義された
multiclusterhub.spec.imagePullSecret。このシークレットは、multicluster engine for Kubernetes Operator のインストール時に作成済みである可能性があります。このシークレットを定義する方法の詳細は、カスタムイメージプルシークレット を参照してください。 -
ハブクラスターの
KubeAPIServer証明書検証ストラテジーを確認し、必要に応じてストラテジーを更新します。セットアップに応じてどのストラテジーを使用すべきかは、ハブクラスターのKubeAPIServer検証ストラテジーの設定 を参照してください。
1.7.4.2.2. サポートされているアーキテクチャー
- Linux (x86_64, s390x, ppc64le)
- macOS
1.7.4.2.3. クラスターインポートの準備
CLI を使用してマネージドクラスターをインポートする前に、以下の手順を実行する必要があります。
次のコマンドを実行して、ハブクラスターにログインします。
oc login
oc loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで次のコマンドを実行して、プロジェクトおよび namespace を作成します。
<cluster_name>で定義されているクラスター名は、YAML ファイルとコマンドでクラスター namespace としても使用されます。oc new-project <cluster_name>
oc new-project <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要:
cluster.open-cluster-management.io/managedClusterラベルは、マネージドクラスターの namespace に対して自動的に追加および削除されます。手動でマネージドクラスター namespace に追加したり、削除したりしないでください。以下の内容例で
managed-cluster.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cloudおよびvendorの値をauto-detectする場合、Red Hat Advanced Cluster Management はインポートしているクラスターからクラウドおよびベンダータイプを自動的に検出します。オプションで、auto-detectの値をクラスターのクラウドおよびベンダーの値に置き換えることができます。以下の例を参照してください。cloud: Amazon vendor: OpenShift
cloud: Amazon vendor: OpenShiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、YAML ファイルを
ManagedClusterリソースに適用します。oc apply -f managed-cluster.yaml
oc apply -f managed-cluster.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
これで、自動インポートシークレットを使用してクラスターをインポートする か、手動でクラスターをインポートする のいずれかに進むことができます。
1.7.4.2.4. 自動インポートシークレットを使用したクラスターのインポート
自動インポートシークレットを使用してマネージドクラスターをインポートするには、クラスターの kubeconfig ファイルへの参照、またはクラスターの kube API サーバーとトークンのペアのいずれかの参照を含むシークレットを作成する必要があります。自動インポートシークレットを使用してクラスターをインポートするには、以下の手順を実行します。
-
インポートするマネージドクラスターの
kubeconfigファイル、または kube API サーバーおよびトークンを取得します。kubeconfigファイルまたは kube API サーバーおよびトークンの場所を特定する方法は、Kubernetes クラスターのドキュメントを参照してください。 ${CLUSTER_NAME} namespace に
auto-import-secret.yamlファイルを作成します。以下のテンプレートのようなコンテンツを使用して、
auto-import-secret.yamlという名前の YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1
- クラスター名を追加します。
- 2
kubeconfigファイルを使用している場合は、インポートするクラスターにコンテキストが設定されているkubeconfigファイルの値を追加します。- 3 4
- トークンとサーバーのペアを使用している場合は、
kubeconfigファイルの代わりにクラスターアクセストークンとクラスター API URL を追加します。以下のコマンドを実行して、<cluster_name> namespace に YAML ファイルを適用します。
oc apply -f auto-import-secret.yaml
oc apply -f auto-import-secret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: デフォルトでは、自動インポートシークレットは 1 回使用され、インポートプロセスが完了すると削除されます。自動インポートシークレットを保持する場合は、
managedcluster-import-controller.open-cluster-management.io/keeping-auto-import-secretをシークレットに追加します。これを追加するには、以下のコマンドを実行します。oc -n <cluster_name> annotate secrets auto-import-secret managedcluster-import-controller.open-cluster-management.io/keeping-auto-import-secret=""
oc -n <cluster_name> annotate secrets auto-import-secret managedcluster-import-controller.open-cluster-management.io/keeping-auto-import-secret=""Copy to Clipboard Copied! Toggle word wrap Toggle overflow インポートしたクラスターのステータス (
JOINEDおよびAVAILABLE) を確認します。ハブクラスターから以下のコマンドを実行します。oc get managedcluster <cluster_name>
oc get managedcluster <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターで以下のコマンドを実行して、マネージドクラスターにログインします。
oc login
oc loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、インポートするクラスターの Pod ステータスを検証できます。
oc get pod -n open-cluster-management-agent
oc get pod -n open-cluster-management-agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow
klusterlet アドオンのインポート に進むことができます。
1.7.4.2.5. クラスターの手動インポート
重要: import コマンドには、インポートされた各マネージドクラスターにコピーされるプルシークレット情報が含まれます。インポートしたクラスターにアクセスできるユーザーであれば誰でも、プルシークレット情報を表示することもできます。
マネージドクラスターを手動でインポートするには、以下の手順を実行します。
以下のコマンドを実行して、ハブクラスターでインポートコントローラーによって生成された
klusterlet-crd.yamlファイルを取得します。oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.crds\\.yaml} | base64 --decode > klusterlet-crd.yamloc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.crds\\.yaml} | base64 --decode > klusterlet-crd.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、ハブクラスターにインポートコントローラーによって生成された
import.yamlファイルを取得します。oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.import\\.yaml} | base64 --decode > import.yamloc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.import\\.yaml} | base64 --decode > import.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow インポートするクラスターで次の手順を実行します。
次のコマンドを入力して、インポートするマネージドクラスターにログインします。
oc login
oc loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、手順 1 で生成した
klusterlet-crd.yamlを適用します。oc apply -f klusterlet-crd.yaml
oc apply -f klusterlet-crd.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、以前に生成した
import.yamlファイルを適用します。oc apply -f import.yaml
oc apply -f import.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターから次のコマンドを実行して、インポートするマネージドクラスターの
JOINEDおよびAVAILABLEステータスを検証できます。oc get managedcluster <cluster_name>
oc get managedcluster <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
klusterlet アドオンのインポート に進むことができます。
1.7.4.2.6. klusterlet アドオンのインポート
KlusterletAddonConfig klusterlet アドオン設定を実装して、マネージドクラスターで他のアドオンを有効にします。次の手順を実行して、設定ファイルを作成して適用します。
以下の例のような YAML ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ファイルは
klusterlet-addon-config.yamlとして保存します。 以下のコマンドを実行して YAML を適用します。
oc apply -f klusterlet-addon-config.yaml
oc apply -f klusterlet-addon-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow アドオンは、インポートするマネージドクラスターのステータスが
AVAILABLEになると、インストールされます。以下のコマンドを実行して、インポートするクラスターのアドオンの Pod ステータスを検証できます。
oc get pod -n open-cluster-management-agent-addon
oc get pod -n open-cluster-management-agent-addonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.4.2.7. コマンドラインインターフェイスを使用したインポート済みクラスターの削除
コマンドラインインターフェイスを使用してマネージドクラスターを削除するには、以下のコマンドを実行します。
oc delete managedcluster <cluster_name>
oc delete managedcluster <cluster_name>
<cluster_name> をクラスターの名前に置き換えます。
1.7.4.3. エージェント登録を使用したマネージドクラスターのインポート
multicluster engine for Kubernetes Operator をインストールしたら、エージェント登録エンドポイントを使用して、クラスターをインポートおよび管理できるようになります。エージェント登録エンドポイントを使用してマネージドクラスターをインポートする方法は、次のトピックをそのまま参照してください。
1.7.4.3.1. 前提条件
- デプロイされたハブクラスター。ベアメタルクラスターをインポートする場合、サポートされている OpenShift Container Platform バージョンにハブクラスターがインストールされている。
- 管理するクラスター。
-
base64コマンドラインツール。 OpenShift Container Platform によって作成されていないクラスターをインポートする場合、定義された
multiclusterhub.spec.imagePullSecret。このシークレットは、multicluster engine for Kubernetes Operator のインストール時に作成済みである可能性があります。このシークレットを定義する方法の詳細は、カスタムイメージプルシークレット を参照してください。新規シークレットを作成する必要がある場合は、新規プルシークレットの作成 を参照してください。
1.7.4.3.2. サポートされているアーキテクチャー
- Linux (x86_64, s390x, ppc64le)
- macOS
1.7.4.3.3. クラスターのインポート
エージェント登録エンドポイントを使用してマネージドクラスターをインポートするには、次の手順を実行します。
ハブクラスターで次のコマンドを実行して、エージェント登録サーバーの URL を取得します。
export agent_registration_host=$(oc get route -n multicluster-engine agent-registration -o=jsonpath="{.spec.host}")export agent_registration_host=$(oc get route -n multicluster-engine agent-registration -o=jsonpath="{.spec.host}")Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注: ハブクラスターがクラスター全体のプロキシーを使用している場合は、マネージドクラスターがアクセスできる URL を使用していることを確認してください。
次のコマンドを実行して、cacert を取得します。
oc get configmap -n kube-system kube-root-ca.crt -o=jsonpath="{.data['ca\.crt']}" > ca.crt_oc get configmap -n kube-system kube-root-ca.crt -o=jsonpath="{.data['ca\.crt']}" > ca.crt_Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記:
kube-root-ca発行エンドポイントを使用していない場合は、kube-root-caCA の代わりにパブリックagent-registrationAPI エンドポイント CA を使用してください。次の YAML コンテンツを適用して、エージェント登録サーバーが承認するトークンを取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してトークンをエクスポートします。
export token=$(oc get secret -n multicluster-engine managed-cluster-import-agent-registration-sa-token -o=jsonpath='{.data.token}' | base64 -d)export token=$(oc get secret -n multicluster-engine managed-cluster-import-agent-registration-sa-token -o=jsonpath='{.data.token}' | base64 -d)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、自動承認を有効にし、コンテンツを
cluster-managerにパッチを適用します。oc patch clustermanager cluster-manager --type=merge -p '{"spec":{"registrationConfiguration":{"featureGates":[ {"feature": "ManagedClusterAutoApproval", "mode": "Enable"}], "autoApproveUsers":["system:serviceaccount:multicluster-engine:agent-registration-bootstrap"]}}}'oc patch clustermanager cluster-manager --type=merge -p '{"spec":{"registrationConfiguration":{"featureGates":[ {"feature": "ManagedClusterAutoApproval", "mode": "Enable"}], "autoApproveUsers":["system:serviceaccount:multicluster-engine:agent-registration-bootstrap"]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注: 自動承認を無効にして、マネージドクラスターからの証明書署名リクエストを手動で承認することもできます。
次のコマンドを実行して、マネージドクラスターに切り替え、cacert を取得します。
curl --cacert ca.crt -H "Authorization: Bearer $token" https://$agent_registration_host/agent-registration/crds/v1 | oc apply -f -
curl --cacert ca.crt -H "Authorization: Bearer $token" https://$agent_registration_host/agent-registration/crds/v1 | oc apply -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マネージドクラスターをハブクラスターにインポートします。
<clusterName>は、クラスターの名前に置き換えます。<duration>は、時間値に置き換えます。たとえば、4hなどに置き換えます。オプション:
<klusterletconfigName>は KlusterletConfig の名前に置き換えます。curl --cacert ca.crt -H "Authorization: Bearer $token" https://$agent_registration_host/agent-registration/manifests/<clusterName>?klusterletconfig=<klusterletconfigName>&duration=<duration> | oc apply -f -
curl --cacert ca.crt -H "Authorization: Bearer $token" https://$agent_registration_host/agent-registration/manifests/<clusterName>?klusterletconfig=<klusterletconfigName>&duration=<duration> | oc apply -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: 期間を設定しないと、klusterlet マニフェストの
kubeconfigブートストラップは期限切れになりません。
1.7.4.4. Central Infrastructure Management を使用してオンプレミスの Red Hat OpenShift Container Platform クラスターを手動でインポートする
multicluster engine for Kubernetes Operator をインストールしたら、管理するクラスターをインポートできるようになります。既存の OpenShift Container Platform クラスターをインポートして、ノードを追加できます。詳細は、次のトピックを引き続きお読みください。
1.7.4.4.1. 前提条件
- Central Infrastructure Management 機能を有効にします。
1.7.4.4.2. クラスターのインポート
静的ネットワークまたはベアメタルホストなしで OpenShift Container Platform クラスターを手動でインポートし、ノードを追加する準備をするには、以下の手順を実行します。
次の YAML コンテンツを適用して、インポートする OpenShift Container Platform クラスターの namespace を作成します。
apiVersion: v1 kind: Namespace metadata: name: managed-cluster
apiVersion: v1 kind: Namespace metadata: name: managed-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の YAML コンテンツを適用して、インポートしている OpenShift Container Platform クラスターに一致する ClusterImageSet が存在することを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の YAML コンテンツを適用して、イメージにアクセスするためのプルシークレットを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <pull-secret-json> をプルシークレット JSON に置き換えます。
kubeconfigを OpenShift Container Platform クラスターからハブクラスターにコピーします。次のコマンドを実行して、OpenShift Container Platform クラスターから
kubeconfigを取得します。kubeconfigがインポートされるクラスターとして設定されていることを確認します。oc get secret -n openshift-kube-apiserver node-kubeconfigs -ojson | jq '.data["lb-ext.kubeconfig"]' --raw-output | base64 -d > /tmp/kubeconfig.some-other-cluster
oc get secret -n openshift-kube-apiserver node-kubeconfigs -ojson | jq '.data["lb-ext.kubeconfig"]' --raw-output | base64 -d > /tmp/kubeconfig.some-other-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: クラスター API にカスタムドメイン経由でアクセスする場合は、まずこの
kubeconfigを編集して、certificate-authority-dataフィールドにカスタム証明書を追加し、serverフィールドをカスタムドメインに合わせて変更する必要があります。次のコマンドを実行して、
kubeconfigをハブクラスターにコピーします。kubeconfigがハブクラスターとして設定されていることを確認します。oc -n managed-cluster create secret generic some-other-cluster-admin-kubeconfig --from-file=kubeconfig=/tmp/kubeconfig.some-other-cluster
oc -n managed-cluster create secret generic some-other-cluster-admin-kubeconfig --from-file=kubeconfig=/tmp/kubeconfig.some-other-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次の YAML コンテンツを適用して、
AgentClusterInstallカスタムリソースを作成します。必要に応じて値を置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の YAML コンテンツを適用して、
ClusterDeploymentを作成します。必要に応じて値を置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の YAML コンテンツを適用することで、
InfraEnvカスタムリソースを追加して、クラスターに追加する新しいホストを検出します。必要に応じて値を置き換えます。注記: 静的 IP アドレスを使用していない場合、次の例では追加の設定が必要になる場合があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
| フィールド | 任意または必須 | 説明 |
|---|---|---|
|
| 任意 |
遅延バインディングを使用している場合、 |
|
| 任意 |
トラブルシューティングのためにノードにログインできるように、オプションの |
インポートに成功すると、ISO ファイルをダウンロードする URL が表示されます。次のコマンドを実行して ISO ファイルをダウンロードします。<url> は表示される URL に置き換えます。
注記: ベアメタルホストを使用すると、ホストの検出を自動化できます。
oc get infraenv -n managed-cluster some-other-infraenv -ojson | jq ".status.<url>" --raw-output | xargs curl -k -o /storage0/isos/some-other.iso
oc get infraenv -n managed-cluster some-other-infraenv -ojson | jq ".status.<url>" --raw-output | xargs curl -k -o /storage0/isos/some-other.isoCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション: OpenShift Container Platform クラスターで、ポリシーなどの Red Hat Advanced Cluster Management 機能を使用する場合は、
ManagedClusterリソースを作成します。ManagedClusterリソースの名前は、ClusterDeplpoymentリソースの名前と一致させてください。ManagedClusterリソースがない場合、コンソールではクラスターのステータスがdetachedになります。
1.7.4.4.3. クラスターリソースのインポート
OpenShift Container Platform マネージドクラスターを Assisted Installer によってインストールした場合、あるハブクラスターから別のハブクラスターにマネージドクラスターとそのリソースを移動できます。
元のリソースのコピーを保存し、それを新しいハブクラスターに適用し、元のリソースを削除することで、新しいハブクラスターからクラスターを管理できます。その後、新しいハブクラスターからマネージドクラスターをスケールダウンまたはスケールアップできます。
重要: インポートした OpenShift Container Platform マネージドクラスターは、Assisted Installer によってインストールされたものである場合にのみスケールダウンできます。
次のリソースをインポートできます。これらのリソースを使用してクラスターの管理を継続できます。
| リソース | 任意または必須 | 説明 |
|---|---|---|
|
| 必須 | |
|
| 任意 | フィルタークエリーを使用してエージェントを分類する場合は必須です。 |
|
| 必須 | |
|
| 任意 |
|
|
| 必須 | |
|
| 必須 | |
|
| 任意 | ホストにネットワーク設定を適用する場合は必須です。 |
|
| 必須 | |
|
| 必須 |
|
1.7.4.4.3.1. マネージドクラスターリソースの保存と適用
マネージドクラスターリソースのコピーを保存し、リソースを新しいハブクラスターに適用するには、次の手順を実行します。
次のコマンドを実行して、ソースハブクラスターからリソースを取得します。必要に応じて値を置き換えます。
oc –kubeconfig <source_hub_kubeconfig> -n <managed_cluster_name> get <resource_name> <cluster_provisioning_namespace> -oyaml > <resource_name>.yaml
oc –kubeconfig <source_hub_kubeconfig> -n <managed_cluster_name> get <resource_name> <cluster_provisioning_namespace> -oyaml > <resource_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
<resource_name>をリソースの名前に置き換えて、インポートするリソースごとにこのコマンドを繰り返し実行します。
-
次のコマンドを実行して、次のリソースから
ownerReferencesプロパティーを削除します。AgentClusterInstallyq --in-place -y 'del(.metadata.ownerReferences)' AgentClusterInstall.yaml
yq --in-place -y 'del(.metadata.ownerReferences)' AgentClusterInstall.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Secret(admin-kubeconfig)yq --in-place -y 'del(.metadata.ownerReferences)' AdminKubeconfigSecret.yaml
yq --in-place -y 'del(.metadata.ownerReferences)' AdminKubeconfigSecret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、マネージドクラスターをソースハブクラスターからデタッチします。必要に応じて値を置き換えます。
oc –kubeconfig <target_hub_kubeconfig> delete ManagedCluster <cluster_name>
oc –kubeconfig <target_hub_kubeconfig> delete ManagedCluster <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - マネージドクラスターのターゲットハブクラスターに namespace を作成します。ソースハブクラスターと同様の名前を使用します。
次のコマンドを実行して、保存したリソースをターゲットハブクラスターに個別に適用します。必要に応じて値を置き換えます。
注記: すべてのリソースを個別ではなく一括で適用する場合は、
<resource_name>.yamlを.に置き換えてください。oc –kubeconfig <target_hub_kubeconfig> apply -f <resource_name>.yaml
oc –kubeconfig <target_hub_kubeconfig> apply -f <resource_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.4.4.3.2. ソースハブクラスターからのマネージドクラスターの削除
クラスターリソースをインポートした後、次の手順を実行して、ソースハブクラスターからマネージドクラスターを削除します。
-
ClusterDeploymentカスタムリソースでspec.preserveOnDeleteパラメーターをtrueに設定し、マネージドクラスターの破棄を防止します。 - 管理からのクラスターの削除 の手順を完了します。
1.7.4.5. 自動インポートストラテジーのカスタマイズ
マネージドクラスターの自動インポート動作を、1 回限りのプロセスまたは継続的なプロセスのいずれかに設定します。次の 2 つの自動インポートストラテジーが存在します。
ImportOnly-
マネージドクラスターに
ManagedClusterImportSucceeded条件がない場合、または条件がTrueに設定されていない場合、ハブクラスターコントローラーは、klusterlet マニフェストをマネージドクラスターに適用してインポートを開始します。クラスターがハブクラスターに参加すると、ハブコントローラーは klusterlet マニフェストの適用を停止します。現在、マネージドクラスター上の klusterlet エージェントのみがハブ設定を同期し続けます。klusterlet エージェントが動作を停止すると、マニフェストが古くなり、ハブクラスター上でマネージドクラスターがUnknown状態として表示される可能性があります。その後、クラスターを手動でインポートする 必要があります。 ImportAndSync- ハブクラスターコントローラーは、マネージドクラスターが参加するまで、klusterlet マニフェストを適用します。参加後は、ハブクラスターコントローラーと klusterlet エージェントの両方が、klusterlet マニフェストをハブクラスター設定と継続的に同期し、1 つのコンポーネントの動作が停止した場合でも一貫性を確保します。
デフォルトの自動インポートストラテジーは ImportOnly です。インポートストラテジーを変更するには、multicluster engine Operator インストール namespace の import-controller-config という名前の ConfigMap オブジェクトを使用します。以下の手順を実行します。
カスタムストラテジーを設定するには、次のコマンドを実行します。
oc -n <mce_install_namespace> create configmap import-controller-config \ --from-literal=autoImportStrategy=<ImportOnly|ImportAndSync>
oc -n <mce_install_namespace> create configmap import-controller-config \ --from-literal=autoImportStrategy=<ImportOnly|ImportAndSync>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: デフォルトの multicluster engine Operator インストール namespace は
multicluster-engineです。更新されたストラテジーをクラスターバックアップに含める場合は、次のコマンドを実行して、
ConfigMapにbackup=trueラベルを追加します。oc -n <mce_install_namespace> label configmap import-controller-config \ cluster.open-cluster-management.io/backup=true
oc -n <mce_install_namespace> label configmap import-controller-config \ cluster.open-cluster-management.io/backup=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.4.6. インポート用のマネージドクラスターでのイメージレジストリーの指定
インポートしているマネージドクラスターのイメージレジストリーを上書きする必要がある場合があります。これには、ManagedClusterImageRegistry カスタムリソース定義を作成します。
ManagedClusterImageRegistry カスタムリソース定義は、namespace スコープのリソースです。
ManagedClusterImageRegistry カスタムリソース定義は、Placement が選択するマネージドクラスターのセットを指定しますが、カスタムイメージレジストリーとは異なるイメージが必要になります。マネージドクラスターが新規イメージで更新されると、識別用に各マネージドクラスターに、open-cluster-management.io/image-registry=<namespace>.<managedClusterImageRegistryName> のラベルが追加されます。
以下の例は、ManagedClusterImageRegistry カスタムリソース定義を示しています。
- 1
- マネージドクラスターのセットを選択するのと同じ namespace 内の配置の名前に置き換えます。
- 2
- カスタムイメージレジストリーからイメージをプルするために使用されるプルシークレットの名前に置き換えます。
- 3
ソースおよびミラーレジストリーのそれぞれの値をリスト表示します。mirrored-image-registry-addressおよびimage-registry-addressは、レジストリーの各ミラーおよびソース値に置き換えます。-
例 1:
registry.redhat.io/rhacm2という名前のソースイメージレジストリーをlocalhost:5000/rhacm2に、registry.redhat.io/multicluster-engineをlocalhost:5000/multicluster-engineに置き換えるには、以下の例を使用します。
-
例 1:
registries:
- mirror: localhost:5000/rhacm2/
source: registry.redhat.io/rhacm2
- mirror: localhost:5000/multicluster-engine
source: registry.redhat.io/multicluster-engine
registries:
- mirror: localhost:5000/rhacm2/
source: registry.redhat.io/rhacm2
- mirror: localhost:5000/multicluster-engine
source: registry.redhat.io/multicluster-engine例 2: ソースイメージ
registry.redhat.io/rhacm2/registration-rhel8-operatorをlocalhost:5000/rhacm2-registration-rhel8-operatorに置き換えるには、以下の例を使用します。registries: - mirror: localhost:5000/rhacm2-registration-rhel8-operator source: registry.redhat.io/rhacm2/registration-rhel8-operatorregistries: - mirror: localhost:5000/rhacm2-registration-rhel8-operator source: registry.redhat.io/rhacm2/registration-rhel8-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
重要: エージェント登録を使用してマネージドクラスターをインポートする場合は、イメージレジストリーを含む KlusterletConfig を作成する必要があります。以下の例を参照してください。必要に応じて値を置き換えます。
詳細は、エージェント登録エンドポイントを使用したマネージドクラスターのインポート を参照してください。
1.7.4.6.1. ManagedClusterImageRegistry を持つクラスターのインポート
ManagedClusterImageRegistry カスタムリソース定義でカスタマイズされるクラスターをインポートするには、以下の手順を実行します。
クラスターをインポートする必要のある namespace にプルシークレットを作成します。これらの手順では、namespace は
myNamespaceです。kubectl create secret docker-registry myPullSecret \ --docker-server=<your-registry-server> \ --docker-username=<my-name> \ --docker-password=<my-password>
$ kubectl create secret docker-registry myPullSecret \ --docker-server=<your-registry-server> \ --docker-username=<my-name> \ --docker-password=<my-password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 作成した namespace に Placement を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: Placement がクラスターを選択できるようにするには、toleration を
unreachableに指定する必要があります。ManagedClusterSetリソースを作成し、これを namespace にバインドします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace に
ManagedClusterImageRegistryカスタムリソース定義を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - コンソールからマネージドクラスターをインポートし、マネージドクラスターセットに追加します。
-
open-cluster-management.io/image-registry=myNamespace.myImageRegistryラベルをマネージドクラスターに追加した後に、マネージドクラスターで import コマンドをコピーして実行します。
1.7.5. クラスターへのアクセス
作成され、管理されている Red Hat OpenShift Container Platform クラスターにアクセスするには、以下の手順を実行します。
- コンソールから、Infrastructure > Clusters に移動し、作成したクラスターまたはアクセスするクラスターの名前を選択します。
Reveal credentials を選択し、クラスターのユーザー名およびパスワードを表示します。クラスターにログインする際に使用するため、この値を書き留めてください。
注記: インポートしたクラスターでは、Reveal credentials オプションは利用できません。
- クラスターにリンクする Console URL を選択します。
- 手順 3 で確認したユーザー ID およびパスワードを使用して、クラスターにログインします。
1.7.6. マネージドクラスターのスケーリング
作成したクラスターは、仮想マシンのサイズやノード数など、マネージドクラスターの仕様をカスタマイズおよびサイズ変更できます。インストーラーでプロビジョニングされたインフラストラクチャーをクラスターデプロイメントに使用している場合は、次のオプションを参照してください。
クラスターのデプロイメントに Central Infrastructure Management を使用している場合は、次のオプションを参照してください。
1.7.6.1. MachinePool によるスケーリング
multicluster engine Operator を使用してプロビジョニングするクラスターの場合、MachinePool リソースが自動的に作成されます。MachinePool を使用して、仮想マシンのサイズやノード数など、マネージドクラスターの仕様をさらにカスタマイズおよびサイズ変更できます。
-
MachinePoolリソースの使用は、ベアメタルクラスターではサポートされていません。 -
MachinePoolリソースは、ハブクラスター上の Kubernetes リソースで、MachineSetリソースをマネージドクラスターでグループ化します。 -
MachinePoolリソースは、ゾーンの設定、インスタンスタイプ、ルートストレージなど、マシンリソースのセットを均一に設定します。 -
MachinePoolでは、マネージドクラスターで、必要なノード数を手動で設定したり、ノードの自動スケーリングを設定したりするのに役立ちます。
1.7.6.1.1. 自動スケーリングの設定
自動スケーリングを設定すると、トラフィックが少ない場合にリソースをスケールダウンし、多くのリソースが必要な場合に十分にリソースを確保できるようにスケールアップするなど、必要に応じてクラスターに柔軟性を持たせることができます。
コンソールを使用して
MachinePoolリソースで自動スケーリングを有効にするには、以下の手順を実行します。- ナビゲーションで、Infrastructure > Clusters を選択します。
- ターゲットクラスターの名前をクリックし、Machine pools タブを選択します。
- マシンプールページのターゲットマシンプールの Options メニューから Enable autoscale を選択します。
マシンセットレプリカの最小数および最大数を選択します。マシンセットレプリカは、クラスターのノードに直接マップします。
Scale をクリックした後、変更がコンソールに反映されるまでに数分かかる場合があります。Machine pools タブの通知がある場合は、View machines をクリックしてスケーリング操作のステータスを表示できます。
コマンドラインを使用して
MachinePoolリソースで自動スケーリングを有効にするには、以下の手順を実行します。次のコマンドを入力して、マシンプールのリストを表示します。このとき、
managed-cluster-namespaceは、ターゲットのマネージドクラスターの namespace に置き換えます。oc get machinepools -n <managed-cluster-namespace>
oc get machinepools -n <managed-cluster-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力してマシンプールの YAML ファイルを編集します。
oc edit machinepool <MachinePool-resource-name> -n <managed-cluster-namespace>
oc edit machinepool <MachinePool-resource-name> -n <managed-cluster-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
MachinePool-resource-nameはMachinePoolリソースの名前に置き換えます。 -
managed-cluster-namespaceはマネージドクラスターの namespace の名前に置き換えます。
-
-
YAML ファイルから
spec.replicasフィールドを削除します。 -
spec.autoscaling.minReplicas設定およびspec.autoscaling.maxReplicasフィールドをリソース YAML に追加します。 -
レプリカの最小数を
minReplicas設定に追加します。 -
レプリカの最大数を
maxReplicas設定に追加します。 - ファイルを保存して変更を送信します。
1.7.6.1.2. 自動スケーリングの無効化
コンソールまたはコマンドラインを使用して自動スケーリングを無効にできます。
コンソールを使用して自動スケーリングを無効にするには、次の手順を実行します。
- ナビゲーションで、Infrastructure > Clusters を選択します。
- ターゲットクラスターの名前をクリックし、Machine pools タブを選択します。
- マシンプールページから、ターゲットマシンプールの Options メニューから autoscale を無効にします。
必要なマシンセットのレプリカ数を選択します。マシンセットのレプリカは、クラスター上のノードを直接マップします。
Scale をクリックした後、表示されるまでに数分かかる場合があります。Machine pools タブの通知で View machines をクリックすると、スケーリングの状態を表示できます。
コマンドラインを使用して自動スケーリングを無効にするには、以下の手順を実行します。
以下のコマンドを実行して、マシンプールのリストを表示します。
oc get machinepools -n <managed-cluster-namespace>
oc get machinepools -n <managed-cluster-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow managed-cluster-namespaceは、ターゲットのマネージドクラスターの namespace に置き換えます。以下のコマンドを入力してマシンプールの YAML ファイルを編集します。
oc edit machinepool <name-of-MachinePool-resource> -n <namespace-of-managed-cluster>
oc edit machinepool <name-of-MachinePool-resource> -n <namespace-of-managed-cluster>Copy to Clipboard Copied! Toggle word wrap Toggle overflow name-of-MachinePool-resourceは、MachinePoolリソースの名前に置き換えます。namespace-of-managed-clusterは、マネージドクラスターの namespace 名に置き換えます。-
YAML ファイルから
spec.autoscalingフィールドを削除します。 -
spec.replicasフィールドをリソース YAML に追加します。 -
replicasの設定にレプリカ数を追加します。 - ファイルを保存して変更を送信します。
1.7.6.1.3. 手動スケーリングの有効化
コンソールおよびコマンドラインから手動でスケーリングできます。
1.7.6.1.3.1. コンソールでの手動スケーリングの有効化
コンソールを使用して MachinePool リソースをスケーリングするには、次の手順を実行します。
-
有効になっている場合は、
MachinePoolの自動スケーリングを無効にします。前の手順を参照してください。 - コンソールから、Infrastructure > Clusters をクリックします。
- ターゲットクラスターの名前をクリックし、Machine pools タブを選択します。
- マシンプールページで、対象のマシンプールの Options メニューから Scale machine pool を選択します。
- 必要なマシンセットのレプリカ数を選択します。マシンセットのレプリカは、クラスター上のノードを直接マップします。Scale をクリックした後、変更がコンソールに反映されるまでに数分かかる場合があります。マシンプールタブの通知から View machines をクリックすると、スケーリング操作の状態を表示できます。
1.7.6.1.3.2. コマンドラインでの手動スケーリングの有効化
コマンドラインを使用して MachinePool リソースをスケーリングするには、次の手順を実行します。
次のコマンドを入力して、マシンプールのリストを表示します。このとき、
<managed-cluster-namespace>は、ターゲットのマネージドクラスターの namespace に置き換えます。oc get machinepools.hive.openshift.io -n <managed-cluster-namespace>
oc get machinepools.hive.openshift.io -n <managed-cluster-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力してマシンプールの YAML ファイルを編集します。
oc edit machinepool.hive.openshift.io <MachinePool-resource-name> -n <managed-cluster-namespace>
oc edit machinepool.hive.openshift.io <MachinePool-resource-name> -n <managed-cluster-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
MachinePool-resource-nameはMachinePoolリソースの名前に置き換えます。 -
managed-cluster-namespaceはマネージドクラスターの namespace の名前に置き換えます。
-
-
YAML ファイルから
spec.autoscalingフィールドを削除します。 -
YAML ファイルの
spec.replicasフィールドを必要な数のレプリカに変更します。 - ファイルを保存して変更を送信します。
1.7.6.2. OpenShift Container Platform クラスターへのワーカーノードの追加
Central Infrastructure Management を使用している場合は、実稼働環境ノードを追加することで OpenShift Container Platform クラスターをカスタマイズできます。
必要なアクセス権限: 管理者
1.7.6.2.1. 前提条件
マネージドクラスター API を信頼するために必要な新しい CA 証明書が必要です。
1.7.6.2.2. 有効な kubeconfig の作成
実稼働環境のワーカーノードを OpenShift Container Platform クラスターに追加する前に、有効な kubeconfig があるかどうかを確認する必要があります。
マネージドクラスターの API 証明書が変更された場合は、次の手順を実行して、kubeconfig を新しい CA 証明書で更新します。
次のコマンドを実行して、
clusterDeploymentのkubeconfigが有効かどうかを確認します。<kubeconfig_name>を現在のkubeconfigの名前に置き換え、<cluster_name>をクラスターの名前に置き換えます。export <kubeconfig_name>=$(oc get cd $<cluster_name> -o "jsonpath={.spec.clusterMetadata.adminKubeconfigSecretRef.name}") oc extract secret/$<kubeconfig_name> --keys=kubeconfig --to=- > original-kubeconfig oc --kubeconfig=original-kubeconfig get nodeexport <kubeconfig_name>=$(oc get cd $<cluster_name> -o "jsonpath={.spec.clusterMetadata.adminKubeconfigSecretRef.name}") oc extract secret/$<kubeconfig_name> --keys=kubeconfig --to=- > original-kubeconfig oc --kubeconfig=original-kubeconfig get nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のエラーメッセージが表示された場合は、
kubeconfigシークレットを更新する必要があります。エラーメッセージが表示されない場合は、ワーカーノードの追加 に進みます。Unable to connect to the server: tls: failed to verify certificate: x509: certificate signed by unknown authority
Unable to connect to the server: tls: failed to verify certificate: x509: certificate signed by unknown authorityCopy to Clipboard Copied! Toggle word wrap Toggle overflow kubeconfigのcertificate-authority-dataフィールドからbase64でエンコードされた証明書バンドルを取得し、次のコマンドを実行してデコードします。echo <base64 encoded blob> | base64 --decode > decoded-existing-certs.pem
echo <base64 encoded blob> | base64 --decode > decoded-existing-certs.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 元のファイルをコピーして、更新された
kubeconfigファイルを作成します。次のコマンドを実行し、<new_kubeconfig_name>を新しいkubeconfigファイルの名前に置き換えます。cp original-kubeconfig <new_kubeconfig_name>
cp original-kubeconfig <new_kubeconfig_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、デコードされた pem に新しい証明書を追加します。
cat decoded-existing-certs.pem new-ca-certificate.pem | openssl base64 -A
cat decoded-existing-certs.pem new-ca-certificate.pem | openssl base64 -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow -
テキストエディターを使用して、前のコマンドの
base64出力を新しいkubeconfigファイルのcertificate-authority-dataキーの値として追加します。 新しい
kubeconfigを使用して API をクエリーし、新しいkubeconfigが有効かどうかを確認します。以下のコマンドを実行します。<new_kubeconfig_name>を新しいkubeconfigファイルの名前に置き換えます。KUBECONFIG=<new_kubeconfig_name> oc get nodes
KUBECONFIG=<new_kubeconfig_name> oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 成功した出力を受け取った場合、
kubeconfigは有効です。次のコマンドを実行して、Red Hat Advanced Cluster Management ハブクラスターの
kubeconfigシークレットを更新します。<new_kubeconfig_name>を新しいkubeconfigファイルの名前に置き換えます。oc patch secret $original-kubeconfig --type='json' -p="[{'op': 'replace', 'path': '/data/kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'},{'op': 'replace', 'path': '/data/raw-kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'}]"oc patch secret $original-kubeconfig --type='json' -p="[{'op': 'replace', 'path': '/data/kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'},{'op': 'replace', 'path': '/data/raw-kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'}]"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.6.2.3. ワーカーノードの追加
有効な kubeconfig がある場合は、以下の手順を実行して、実稼働環境のワーカーノードを OpenShift Container Platform クラスターに追加します。
ワーカーノードとして使用するマシンを、以前にダウンロードした ISO から起動します。
注記: ワーカーノードが OpenShift Container Platform ワーカーノードの要件を満たしていることを確認してください。
次のコマンドを実行した後、エージェントが登録されるまで待ちます。
watch -n 5 "oc get agent -n managed-cluster"
watch -n 5 "oc get agent -n managed-cluster"Copy to Clipboard Copied! Toggle word wrap Toggle overflow エージェントの登録が成功すると、エージェントがリストされます。インストールのためにエージェントを承認します。これには数分かかる場合があります。
注記: エージェントがリストにない場合は、Ctrl キーと C キーを押して
watchコマンドを終了し、ワーカーノードにログインしてトラブルシューティングを行ってください。遅延バインディングを使用している場合は、次のコマンドを実行して、保留中のバインドされていないエージェントを OpenShift Container Platform クラスターに関連付けます。遅延バインディングを使用していない場合は、ステップ 5 に進みます。
oc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) |select(.spec.clusterDeploymentName==null) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"clusterDeploymentName":{"name":"some-other-cluster","namespace":"managed-cluster"}}}' --type merge agentoc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) |select(.spec.clusterDeploymentName==null) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"clusterDeploymentName":{"name":"some-other-cluster","namespace":"managed-cluster"}}}' --type merge agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、保留中のエージェントのインストールを承認します。
oc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"approved":true}}' --type merge agentoc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"approved":true}}' --type merge agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow
ワーカーノードのインストールを待ちます。ワーカーノードのインストールが完了すると、ワーカーノードは証明書署名要求 (CSR) を使用してマネージドクラスターに接続し、参加プロセスを開始します。CSR は自動的に署名されます。
1.7.6.3. マネージドクラスターへのコントロールプレーンノードの追加
問題のあるコントロールプレーンを置き換えるには、コントロールプレーンノードを正常または正常でないマネージドクラスターに追加します。
必要なアクセス権限: 管理者
1.7.6.3.1. 正常なマネージドクラスターへのコントロールプレーンノードの追加
以下の手順を実行して、コントロールプレーンノードを正常なマネージドクラスターに追加します。
- 新しいコントロールプレーンノードを追加するには、OpenShift Container Platform クラスターへのワーカーノードの追加 の手順を完了します。
Discovery ISO を使用してノードを追加する場合は、エージェントを承認する前にエージェントを
masterに設定します。以下のコマンドを実行します。oc patch agent <agent-name> -p '{"spec":{"role": "master"}}' --type=mergeoc patch agent <agent-name> -p '{"spec":{"role": "master"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: 証明書署名要求 (CSR) は自動的に承認されません。
BareMetalHostを使用してノードを追加する場合は、BareMetalHostリソースの作成時に、BareMetalHostアノテーションに次の行を追加します。bmac.agent-install.openshift.io/role: master
bmac.agent-install.openshift.io/role: masterCopy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Container Platform の Assisted Installer ドキュメントの 正常なクラスター内のコントロールプレーンノードの置き換え の手順に従います。
1.7.6.3.2. API を使用して正常なマネージドクラスターにコントロールプレーンノードを追加する
API を使用して正常なマネージドクラスターにコントロールプレーンノードを追加するには、次の手順を実行します。
次のコマンドを実行して、ハブクラスターにログインします。クラスターの名前を追加します。
oc login --token=sha256~value--server=https://api.<cluster-name>.basedomain:6443
oc login --token=sha256~value--server=https://api.<cluster-name>.basedomain:6443Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンノードとして使用するマシンを Discovery ISO から起動します。
注記: または、
BareMetalHostYAML を適用して、新しいホストをInfraEnvに適用します。エージェントの状態をチェックして、エージェントがクラスターに再度バインドする準備ができていることを確認します。次のコマンドを実行し、必要に応じて変数を置き換えます。
インベントリーを切り替えるには、次のコマンドを実行します。
<host-inventory-namespace>は自分の namespace に置き換えます。oc project <host-inventory-namespace>
oc project <host-inventory-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow エージェントの状態を取得するには、次のコマンドを実行します。
<agent-name>は、エージェントの名前に置き換えます。oc get agent <agent-name> -oyaml | grep state
oc get agent <agent-name> -oyaml | grep stateCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
出力で
stateInfo行をチェックして、ホストがクラスターにバインドする準備ができていることを確認します。
ホストのロールを
masterに設定します。Discovery ISO を使用してノードを追加する場合は、エージェントを承認し、ロールを
masterに設定します。以下のコマンドを実行します。oc patch agent <agent-name> -p '{"spec":{"approved":true,"role":"master"}}' --type=mergeoc patch agent <agent-name> -p '{"spec":{"approved":true,"role":"master"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
BareMetalHostを使用してノードを追加する場合は、BareMetalHostリソースの作成時に、BareMetalHostアノテーションに次の行を追加します。
bmac.agent-install.openshift.io/role: master
bmac.agent-install.openshift.io/role: masterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してパッチを検証します。
oc get agent
oc get agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力で、
APPROVED列の各行がtrueであること、およびROLEがmasterであることを確認します。以下の例を参照してください。NAME CLUSTER APPROVED ROLE STAGE c6e00642-0e11-1689-a79d-0e131d2c6ecf true master
NAME CLUSTER APPROVED ROLE STAGE c6e00642-0e11-1689-a79d-0e131d2c6ecf true masterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、エージェントをクラスターに追加します。
oc patch agent <agent name> -p '{"spec":{"clusterDeploymentName":{"name":"<managed-cluster-name>","namespace":"<managed-cluster-namespace>"}}}' --type=mergeoc patch agent <agent name> -p '{"spec":{"clusterDeploymentName":{"name":"<managed-cluster-name>","namespace":"<managed-cluster-namespace>"}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、エージェントがクラスターにバインドされていることを確認します。
oc get agent
oc get agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の出力例を参照してください。
NAME CLUSTER APPROVED ROLE STAGE c6e00642-0e11-1689-a79d-0e131d2c6ecf hcpagent true master
NAME CLUSTER APPROVED ROLE STAGE c6e00642-0e11-1689-a79d-0e131d2c6ecf hcpagent true masterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してエージェントのステータスを確認します。エージェントがインストールされ、クラスターに参加している間、数分待つ必要がある場合があります。
oc get agent -w
oc get agent -wCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: 証明書署名要求 (CSR) は自動的に承認されません。
エージェントが
Rebootingの段階に達したら、CSR を手動で承認する必要があります。以下の手順を実行します。次のコマンドを実行して、マネージドクラスターの
kubeconfigファイルを取得します。kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}') oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > managed-cluster.kubeconfigkubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}') oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > managed-cluster.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マネージドクラスター上で保留中の CSR を見つけます。
oc --kubeconfig managed-cluster.kubeconfig get csr | grep Pending
oc --kubeconfig managed-cluster.kubeconfig get csr | grep PendingCopy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスター内のエージェントの保留中の CSR を承認します。次のコマンドを実行し、
<csr-name>は CSR 名に置き換えます。oc --kubeconfig managed-cluster.kubeconfig adm certificate approve <csr-name>
oc --kubeconfig managed-cluster.kubeconfig adm certificate approve <csr-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
STAGE に Done と表示されたら、ホストはインストールされています。次の出力例を参照してください。
NAME CLUSTER APPROVED ROLE STAGE c6e00642-0e11-1689-a79d-0e131d2c6ecf hcpagent true master Done
NAME CLUSTER APPROVED ROLE STAGE
c6e00642-0e11-1689-a79d-0e131d2c6ecf hcpagent true master Done1.7.6.3.3. 正常でないマネージドクラスターへのコントロールプレーンノードの追加
以下の手順を実行して、コントロールプレーンノードを正常でないマネージドクラスターに追加します。
- 正常でないコントロールプレーンノードのエージェントを削除します。
- デプロイメントにゼロタッチプロビジョニングフローを使用した場合は、ベアメタルホストを削除します。
- 新規コントロールプレーンノードの OpenShift Container Platform クラスターへのワーカーノードの追加 の手順を実行します。
次のコマンドを実行して、エージェントを承認する前にエージェントを
masterに設定します。oc patch agent <AGENT-NAME> -p '{"spec":{"role": "master"}}' --type=mergeoc patch agent <AGENT-NAME> -p '{"spec":{"role": "master"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: CSR は自動的に承認されません。
- OpenShift Container Platform の Assisted Installer ドキュメントの 正常でないクラスターへのプライマリーコントロールプレーンノードのインストール の手順に従ってください。
1.7.7. 作成されたクラスターの休止
リソースを節約するために、multicluster engine Operator を使用して作成されたクラスターを休止状態にすることができます。休止状態のクラスターに必要となるリソースは、実行中のものより少なくなるので、クラスターを休止状態にしたり、休止状態を解除したりすることで、プロバイダーのコストを削減できる可能性があります。この機能は、次の環境の multicluster engine Operator によって作成されたクラスターにのみ適用されます。
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
1.7.7.1. コンソールを使用したクラスターの休止
コンソールを使用して、multicluster engine Operator によって作成されたクラスターを休止状態にするには、次の手順を実行します。
- ナビゲーションメニューから Infrastructure > Clusters を選択します。Manage clusters タブが選択されていることを確認します。
- そのクラスターの Options メニューから Hibernate cluster を選択します。注記: Hibernate cluster オプションが利用できない場合には、クラスターを休止状態にすることはできません。これは、クラスターがインポートされたものであり、multicluster engine Operator によって作成されたものでない場合に発生する可能性があります。
Clusters ページのクラスターのステータスは、プロセスが完了すると Hibernating になります。
ヒント: Clusters ページで休止するするクラスターを選択し、Actions > Hibernate clusters を選択して、複数のクラスターを休止できます。
選択したクラスターが休止状態になりました。
1.7.7.2. CLI を使用したクラスターの休止
CLI を使用して、multicluster engine Operator によって作成されたクラスターを休止状態にするには、次の手順を実行します。
以下のコマンドを入力して、休止するクラスターの設定を編集します。
oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>Copy to Clipboard Copied! Toggle word wrap Toggle overflow name-of-clusterは、休止するクラスター名に置き換えます。namespace-of-clusterは、休止するクラスターの namespace に置き換えます。-
spec.powerStateの値はHibernatingに変更します。 以下のコマンドを実行して、クラスターのステータスを表示します。
oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow name-of-clusterは、休止するクラスター名に置き換えます。namespace-of-clusterは、休止するクラスターの namespace に置き換えます。クラスターを休止するプロセスが完了すると、クラスターのタイプの値は
type=Hibernatingになります。
選択したクラスターが休止状態になりました。
1.7.7.3. コンソールを使用して休止中のクラスターの通常操作を再開する手順
コンソールを使用して、休止中のクラスターの通常操作を再開するには、以下の手順を実行します。
- ナビゲーションメニューから Infrastructure > Clusters を選択します。Manage clusters タブが選択されていることを確認します。
- 再開するクラスターの Options メニューから Resume cluster を選択します。
プロセスを完了すると、Clusters ページのクラスターのステータスは Ready になります。
ヒント: Clusters ページで、再開するクラスターを選択し、Actions > Resume cluster の順に選択して、複数のクラスターを再開できます。
選択したクラスターで通常の操作が再開されました。
1.7.7.4. CLI を使用して休止中のクラスターの通常操作を再開する手順
CLI を使用して、休止中のクラスターの通常操作を再開するには、以下の手順を実行します。
以下のコマンドを入力してクラスターの設定を編集します。
oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>Copy to Clipboard Copied! Toggle word wrap Toggle overflow name-of-clusterは、休止するクラスター名に置き換えます。namespace-of-clusterは、休止するクラスターの namespace に置き換えます。-
spec.powerStateの値をRunningに変更します。 以下のコマンドを実行して、クラスターのステータスを表示します。
oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow name-of-clusterは、休止するクラスター名に置き換えます。namespace-of-clusterは、休止するクラスターの namespace に置き換えます。クラスターの再開プロセスが完了すると、クラスターのタイプの値は
type=Runningになります。
選択したクラスターで通常の操作が再開されました。
1.7.8. クラスターのアップグレード
multicluster engine Operator で管理する Red Hat OpenShift Container Platform クラスターを作成した後、multicluster engine Operator コンソールを使用して、マネージドクラスターが使用するバージョンチャネルで利用できる最新のマイナーバージョンにこれらのクラスターをアップグレードできます。
接続された環境では、コンソールでアップグレードが必要な各クラスターに提供される通知によって、更新が自動的に識別されます。
1.7.8.1. 前提条件
そのバージョンにアップグレードするための前提条件をすべて満たしていることを確認する。コンソールでクラスターをアップグレードする前に、マネージドクラスターのバージョンチャネルを更新する必要があります。
注記: マネージドクラスターでバージョンチャネルを更新すると、multicluster engine Operator コンソールに、アップグレードに使用できる最新バージョンが表示されます。
- OpenShift Container Platform マネージドクラスターが、Ready 状態である。
重要: multicluster engine Operator コンソールを使用して、Red Hat OpenShift Dedicated 上の Red Hat OpenShift Kubernetes Service マネージドクラスターまたは OpenShift Container Platform マネージドクラスターをアップグレードすることはできません。
1.7.8.2. オンライン環境でのクラスターのアップグレード
オンライン環境でクラスターをアップグレードするには、以下の手順を実行します。
- ナビゲーションメニューから、Infrastructure > Clusters. に移動します。アップグレードが利用可能な場合は、Distribution version 列に表示されます。
- アップグレードする Ready 状態のクラスターを選択します。OpenShift Container Platform クラスターは、コンソールでのみアップグレードできます。
- Upgrade を選択します。
- 各クラスターの新しいバージョンを選択します。
- Upgrade を選択します。
クラスターのアップグレードに失敗すると、Operator は通常アップグレードを数回再試行し、停止し、コンポーネントに問題があるステータスを報告します。場合によっては、アップグレードプロセスは、プロセスの完了を繰り返し試行します。アップグレードに失敗した後にクラスターを以前のバージョンにロールバックすることはサポートされていません。クラスターのアップグレードに失敗した場合は、Red Hat サポートにお問い合わせください。
1.7.8.3. チャネルの選択
コンソールを使用して、OpenShift Container Platform でクラスターをアップグレードするためのチャネルを選択できます。チャネルを選択すると、エラータバージョンとリリースバージョンの両方で利用可能なクラスターアップグレードが自動的に通知されます。
クラスターのチャネルを選択するには、以下の手順を実行します。
- ナビゲーションメニューから Infrastructure > Clusters をクリックします。
- 変更するクラスターの名前を選択して、Cluster details ページを表示します。クラスターに別のチャネルが利用可能な場合は、編集アイコンが Channel フィールドに表示されます。
- Edit アイコンをクリックし、フィールドの設定を変更します。
- New channel フィールドでチャネルを選択します。
利用可能なチャネル更新のリマインダーは、クラスターの Cluster details ページで見つけることができます。
1.7.8.4. オフラインクラスターのアップグレード
multicluster engine Operator と OpenShift Update Service を使用し、オフライン環境でクラスターをアップグレードできます。
セキュリティー上の理由で、クラスターがインターネットに直接接続できない場合があります。このような場合は、アップグレードが利用可能なタイミングや、これらのアップグレードの処理方法を把握するのが困難になります。OpenShift Update Service を設定すると便利です。
OpenShift Update Service は、個別の Operator およびオペランドで、非接続環境で利用可能なマネージドクラスターを監視して、クラスターのアップグレードで利用できるようにします。OpenShift Update Service を設定すると、次の操作を実行できます。
- オフラインのクラスター向けにいつアップグレードが利用できるかを監視します。
- グラフデータファイルを使用してアップグレード用にどの更新がローカルサイトにミラーリングされているかを特定します。
- コンソールを使用して、クラスターのアップグレードが利用可能であることを通知します。
次のトピックでは、オフラインクラスターをアップグレードする手順を説明します。
1.7.8.4.1. 前提条件
OpenShift Update Service を使用して非接続クラスターをアップグレードするには、以下の前提条件を満たす必要があります。
制限付きの OLM が設定されたサポート対象の OpenShift Container Platform バージョンで実行されているデプロイ済みのハブクラスター。制限付きの OLM の設定方法は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
Note: 制限付きの OLM の設定時に、カタログソースイメージをメモします。
- ハブクラスターによって管理される OpenShift Container Platform クラスター
クラスターイメージをミラーリング可能なローカルレジストリーにアクセスするための認証情報。このリポジトリーを作成する方法の詳細は、非接続環境のミラーリング を参照してください。
注記: アップグレードするクラスターの現行バージョンのイメージは、ミラーリングされたイメージの 1 つとして常に利用可能でなければなりません。アップグレードに失敗すると、クラスターはアップグレード試行時のクラスターのバージョンに戻ります。
1.7.8.4.2. 非接続ミラーレジストリーの準備
ローカルのミラーリングレジストリーに、アップグレード前の現行のイメージと、アップグレード後のイメージの療法をミラーリングする必要があります。イメージをミラーリングするには以下の手順を実行します。
次の例のような内容を含むスクリプトファイルを作成します。
<4.x.z>はサポートされているバージョンに置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
path-to-pull-secretは、OpenShift Container Platform のプルシークレットへのパスに置き換えます。
スクリプトを実行して、イメージのミラーリング、設定の設定、リリースイメージとリリースコンテンツの分離を行います。
ImageContentSourcePolicyの作成時に、このスクリプトの最後の行にある出力を使用できます。
1.7.8.4.3. OpenShift Update Service の Operator のデプロイ
OpenShift Container Platform 環境で OpenShift Update Service の Operator をデプロイするには、以下の手順を実行します。
- ハブクラスターで、OpenShift Container Platform Operator のハブにアクセスします。
-
OpenShift Update Service Operatorを選択して Operator をデプロイします。必要に応じてデフォルト値を更新します。Operator をデプロイすると、openshift-cincinnatiという名前の新規プロジェクトが作成されます。 Operator のインストールが完了するまで待ちます。
OpenShift Container Platform コマンドラインで
oc get podsコマンドを入力すると、インストールのステータスを確認できます。Operator の状態がrunningであることを確認します。
1.7.8.4.4. グラフデータの init コンテナーの構築
OpenShift Update Service はグラフデータ情報を使用して、利用可能なアップグレードを判別します。オンライン環境では、OpenShift Update Service は Cincinnati グラフデータの GitHub リポジトリー から直接利用可能なアップグレードがないか、グラフデータ情報をプルします。非接続環境を設定しているため、init container を使用してローカルリポジトリーでグラフデータを利用できるようにする必要があります。以下の手順を実行して、グラフデータの init container を作成します。
以下のコマンドを入力して、グラフデータ Git リポジトリーのクローンを作成します。
git clone https://github.com/openshift/cincinnati-graph-data
git clone https://github.com/openshift/cincinnati-graph-dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow グラフデータの
initの情報が含まれるファイルを作成します。このサンプル Dockerfile は、cincinnati-operatorGitHub リポジトリーにあります。ファイルの内容は以下の例のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、以下のように設定されています。
以下のコマンドを実行して、
graph data init containerをビルドします。podman build -f <path_to_Dockerfile> -t <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container>:latest podman push <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container><2>:latest --authfile=</path/to/pull_secret>.jsonpodman build -f <path_to_Dockerfile> -t <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container>:latest1 2 podman push <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container><2>:latest --authfile=</path/to/pull_secret>.json3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記:
podmanがインストールされていない場合は、コマンドのpodmanをdockerに置き換えることもできます。
1.7.8.4.5. ミラーリングされたレジストリーの証明書の設定
セキュアな外部コンテナーレジストリーを使用してミラーリングされた OpenShift Container Platform リリースイメージを保存する場合は、アップグレードグラフをビルドするために OpenShift Update Service からこのレジストリーへのアクセス権が必要です。OpenShift Update Service Pod と連携するように CA 証明書を設定するには、以下の手順を実行します。
image.config.openshift.ioにある OpenShift Container Platform 外部レジストリー API を検索します。これは、外部レジストリーの CA 証明書の保存先です。詳細は、OpenShift Container Platform ドキュメントの イメージレジストリーアクセス用の追加トラストストアの設定 を参照してください。
-
openshift-confignamespace に ConfigMap を作成します。 キー
updateservice-registryの下に CA 証明書を追加します。OpenShift Update Service はこの設定を使用して、証明書を特定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow image.config.openshift.ioAPI のclusterリソースを編集して、additionalTrustedCAフィールドを作成した ConfigMap 名に設定します。oc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"trusted-ca"}}}' --type mergeoc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"trusted-ca"}}}' --type mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow trusted-caは、新しい ConfigMap へのパスに置き換えます。
OpenShift Update Service Operator は、変更がないか、image.config.openshift.io API と、openshift-config namespace に作成した ConfigMap を監視し、CA 証明書が変更された場合はデプロイメントを再起動します。
1.7.8.4.6. OpenShift Update Service インスタンスのデプロイ
ハブクラスターへの OpenShift Update Service インスタンスのデプロイが完了したら、このインスタンスは、クラスターのアップグレードのイメージをミラーリングして非接続マネージドクラスターに提供する場所に配置されます。インスタンスをデプロイするには、以下の手順を実行します。
デフォルトの Operator の namespace (
openshift-cincinnati) を使用しない場合は、お使いの OpenShift Update Service インスタンスの namespace を作成します。- OpenShift Container Platform ハブクラスターコンソールのナビゲーションメニューで、Administration > Namespaces を選択します。
- Create Namespace を選択します。
- namespace 名と、namespace のその他の情報を追加します。
- Create を選択して namespace を作成します。
- OpenShift Container Platform コンソールの Installed Operator セクションで、OpenShift Update Service Operator を選択します。
- メニューから Create Instance を選択します。
OpenShift Update Service インスタンスからコンテンツを貼り付けます。YAML ファイルは以下のマニフェストのようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Create を選択してインスタンスを作成します。
-
ハブクラスター CLI で
oc get podsコマンドを入力し、インスタンス作成のステータスを表示します。時間がかかる場合がありますが、コマンド結果でインスタンスと Operator が実行中である旨が表示されたらプロセスは完了です。
1.7.8.4.7. デフォルトのレジストリーの上書き (オプション)
注記: このセクションの手順は、ミラーレジストリーにリリースをミラーリングした場合にのみ該当します。
OpenShift Container Platform にはイメージレジストリーのデフォルト値があり、この値でアップグレードパッケージの検索先を指定します。オフライン環境では、オーバーライドを作成して、その値をリリースイメージをミラーリングしたローカルイメージレジストリーへのパスに置き換えることができます。
デフォルトのレジストリーを上書きするには、次の手順を実行します。
次の内容のような、
mirror.yamlという名前の YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記:
oc adm release mirrorコマンドを入力すると、ローカルミラーへのパスが分かります。マネージドクラスターのコマンドラインを使用して、次のコマンドを実行してデフォルトのレジストリーをオーバーライドします。
oc apply -f mirror.yaml
oc apply -f mirror.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.8.4.8. オフラインカタログソースのデプロイ
マネージドクラスターで、デフォルトのカタログソースをすべて無効にし、新しいカタログソースを作成します。デフォルトの場所を接続された場所からオフラインローカルレジストリーに変更するには、次の手順を実行します。
次の内容のような、
source.yamlという名前の YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
spec.imageの値を、ローカルの制約付きカタログソースイメージへのパスに置き換えます。
マネージドクラスターのコマンドラインで、次のコマンドを実行してカタログソースを変更します。
oc apply -f source.yaml
oc apply -f source.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.8.4.9. マネージドクラスターのパラメーターを変更する
マネージドクラスターの ClusterVersion リソース情報を更新して、アップグレードを取得するデフォルトの場所を変更します。
マネージドクラスターから、以下のコマンドを入力して
ClusterVersionアップストリームパラメーターがデフォルトの OpenShift Update Service オペランドであることを確認します。oc get clusterversion -o yaml
oc get clusterversion -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow サポートされているバージョンとして
4.xが設定されている場合、次のような内容が返されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターから、次のコマンドを入力して、OpenShift Update Service オペランドへのルート URL を特定します。
oc get routes
oc get routesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 後のステップのために戻り値に注意してください。
マネージドクラスターのコマンドラインで、次のコマンドを入力して
ClusterVersionリソースを編集します。oc edit clusterversion version
oc edit clusterversion versionCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.channelの値を新しいバージョンに置き換えます。spec.upstreamの値は、ハブクラスター OpenShift Update Service オペランドへのパスに置き換えます。次の手順を実行して、オペランドへのパスを決定できます。ハブクラスターで以下のコマンドを実行してください。
oc get routes -A
oc get routes -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow -
cincinnatiへのパスを見つけます。オペランドのパスは、HOST/PORTフィールドの値です。
マネージドクラスターのコマンドラインで、次のコマンドを入力して、
ClusterVersionのアップストリームパラメーターがローカルハブクラスターの OpenShift Update Service URL で更新されていることを確認します。oc get clusterversion -o yaml
oc get clusterversion -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 結果は次のような内容になります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.8.4.10. 利用可能なアップグレードの表示
Cluster ページでは、オフラインレジストリーにアップグレードがある場合、クラスターの Distribution version に、利用可能なアップグレードがあることが示されます。クラスターを選択し、Actions メニューから Upgrade clusters を選択すると、利用可能なアップグレードを表示できます。オプションのアップグレードパスが利用可能な場合は、利用可能なアップグレードがリストされます。
注記: 現行バージョンがローカルのイメージリポジトリーにミラーリングされていないと、利用可能なアップグレードバージョンは表示されません。
1.7.8.4.11. チャネルの選択
コンソールを使用して、OpenShift Container Platform バージョン 4.6 以降でクラスターをアップグレードするためのチャネルを選択できます。これらのバージョンはミラーレジストリーで利用可能である必要があります。チャネルの選択 の手順を実行して、アップグレードチャネルを指定します。
1.7.8.4.12. クラスターのアップグレード
非接続レジストリーを設定すると、multicluster engine Operator と OpenShift Update Service が非接続レジストリーを使用して、アップグレードが利用可能かどうかを判断します。利用可能なアップグレードが表示されない場合は、クラスターの現行のリリースイメージと、1 つ後のイメージがローカルリポジトリーにミラーリングされていることを確認します。クラスターの現行バージョンのリリースイメージが利用できないと、アップグレードは利用できません。
Cluster ページでは、オフラインレジストリーにアップグレードがある場合、クラスターの Distribution version に、利用可能なアップグレードがあることが示されます。イメージをアップグレードするには、Upgrade available をクリックし、アップグレードするバージョンを選択します。
マネージドクラスターは、選択したバージョンに更新されます。
クラスターのアップグレードに失敗すると、Operator は通常アップグレードを数回再試行し、停止し、コンポーネントに問題があるステータスを報告します。場合によっては、アップグレードプロセスは、プロセスの完了を繰り返し試行します。アップグレードに失敗した後にクラスターを以前のバージョンにロールバックすることはサポートされていません。クラスターのアップグレードに失敗した場合は、Red Hat サポートにお問い合わせください。
1.7.9. クラスタープロキシーアドオンの有効化
一部の環境では、マネージドクラスターはファイアウォールの背後にあり、ハブクラスター経由で直接アクセスできません。アクセスを取得するには、プロキシーアドオンを設定して、よりセキュアな接続でマネージドクラスターの kube-apiserver にアクセスできます。
重要: クラスタープロキシーアドオンを使用するには、ハブクラスターでクラスター全体のプロキシー設定を指定できません。
必要なアクセス権限: 編集
1.7.9.1. ハブクラスターとマネージドクラスターのクラスタープロキシーアドオンの設定
ハブクラスターまたはマネージドクラスターのクラスタープロキシーアドオンを設定するには、次の手順を実行します。
次の手順を実行してマネージドクラスター
kube-apiserverにアクセスするようにkubeconfigファイルを設定します。マネージドクラスターに有効なアクセストークンを指定します。
注記: サービスアカウントの対応するトークンを使用できます。デフォルトの namespace にあるデフォルトのサービスアカウントを使用することもできます。
次のコマンドを実行して、マネージドクラスターの
kubeconfigファイルをエクスポートします。export KUBECONFIG=<managed-cluster-kubeconfig>
export KUBECONFIG=<managed-cluster-kubeconfig>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod へのアクセス権があるロールをサービスアカウントに追加します。
oc create role -n default test-role --verb=list,get --resource=pods oc create rolebinding -n default test-rolebinding --serviceaccount=default:default --role=test-role
oc create role -n default test-role --verb=list,get --resource=pods oc create rolebinding -n default test-rolebinding --serviceaccount=default:default --role=test-roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、サービスアカウントトークンのシークレットを見つけます。
oc get secret -n default | grep <default-token>
oc get secret -n default | grep <default-token>Copy to Clipboard Copied! Toggle word wrap Toggle overflow default-tokenは、シークレット名に置き換えます。次のコマンドを実行して、トークンをコピーします。
export MANAGED_CLUSTER_TOKEN=$(kubectl -n default get secret <default-token> -o jsonpath={.data.token} | base64 -d)export MANAGED_CLUSTER_TOKEN=$(kubectl -n default get secret <default-token> -o jsonpath={.data.token} | base64 -d)Copy to Clipboard Copied! Toggle word wrap Toggle overflow default-tokenは、シークレット名に置き換えます。
Red Hat Advanced Cluster Management ハブクラスターで
kubeconfigファイルを設定します。次のコマンドを実行して、ハブクラスター上の現在の
kubeconfigファイルをエクスポートします。oc config view --minify --raw=true > cluster-proxy.kubeconfig
oc config view --minify --raw=true > cluster-proxy.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow エディターで
serverファイルを変更します。この例では、sedの使用時にコマンドを使用します。OSX を使用している場合は、alias sed=gsedを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、元のユーザー認証情報を削除します。
sed -i'' -e '/client-certificate-data/d' cluster-proxy.kubeconfig sed -i'' -e '/client-key-data/d' cluster-proxy.kubeconfig sed -i'' -e '/token/d' cluster-proxy.kubeconfig
sed -i'' -e '/client-certificate-data/d' cluster-proxy.kubeconfig sed -i'' -e '/client-key-data/d' cluster-proxy.kubeconfig sed -i'' -e '/token/d' cluster-proxy.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントのトークンを追加します。
sed -i'' -e '$a\ token: '"$MANAGED_CLUSTER_TOKEN"'' cluster-proxy.kubeconfig
sed -i'' -e '$a\ token: '"$MANAGED_CLUSTER_TOKEN"'' cluster-proxy.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、ターゲットマネージドクラスターのターゲット namespace にあるすべての Pod をリスト表示します。
oc get pods --kubeconfig=cluster-proxy.kubeconfig -n <default>
oc get pods --kubeconfig=cluster-proxy.kubeconfig -n <default>Copy to Clipboard Copied! Toggle word wrap Toggle overflow defaultnamespace は、使用する namespace に置き換えます。マネージドクラスター上の他のサービスにアクセスします。この機能は、マネージドクラスターが Red Hat OpenShift Container Platform クラスターの場合に利用できます。サービスは
service-serving-certificateを使用してサーバー証明書を生成する必要があります。マネージドクラスターから、以下のサービスアカウントトークンを使用します。
export PROMETHEUS_TOKEN=$(kubectl get secret -n openshift-monitoring $(kubectl get serviceaccount -n openshift-monitoring prometheus-k8s -o=jsonpath='{.secrets[0].name}') -o=jsonpath='{.data.token}' | base64 -d)export PROMETHEUS_TOKEN=$(kubectl get secret -n openshift-monitoring $(kubectl get serviceaccount -n openshift-monitoring prometheus-k8s -o=jsonpath='{.secrets[0].name}') -o=jsonpath='{.data.token}' | base64 -d)Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターから、以下のコマンドを実行して認証局をファイルに変換します。
oc get configmap kube-root-ca.crt -o=jsonpath='{.data.ca\.crt}' > hub-ca.crtoc get configmap kube-root-ca.crt -o=jsonpath='{.data.ca\.crt}' > hub-ca.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow
以下のコマンドを使用して、マネージドクラスターの Prometheus メトリックを取得します。
export SERVICE_NAMESPACE=openshift-monitoring export SERVICE_NAME=prometheus-k8s export SERVICE_PORT=9091 export SERVICE_PATH="api/v1/query?query=machine_cpu_sockets" curl --cacert hub-ca.crt $NEW_SERVER/api/v1/namespaces/$SERVICE_NAMESPACE/services/$SERVICE_NAME:$SERVICE_PORT/proxy-service/$SERVICE_PATH -H "Authorization: Bearer $PROMETHEUS_TOKEN"
export SERVICE_NAMESPACE=openshift-monitoring export SERVICE_NAME=prometheus-k8s export SERVICE_PORT=9091 export SERVICE_PATH="api/v1/query?query=machine_cpu_sockets" curl --cacert hub-ca.crt $NEW_SERVER/api/v1/namespaces/$SERVICE_NAMESPACE/services/$SERVICE_NAME:$SERVICE_PORT/proxy-service/$SERVICE_PATH -H "Authorization: Bearer $PROMETHEUS_TOKEN"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.9.2. クラスタープロキシーアドオンのプロキシー設定
マネージドクラスターが HTTP および HTTPS プロキシーサーバー経由でハブクラスターと通信できるように、クラスタープロキシーアドオンのプロキシー設定を指定できます。クラスタープロキシーアドオンエージェントがプロキシーサーバー経由でハブクラスターにアクセスする必要がある場合は、プロキシー設定が必要な可能性があります。
クラスタープロキシーアドオンのプロキシー設定を指定するには、次の手順を実行します。
ハブクラスターに
AddOnDeploymentConfigリソースを作成し、spec.proxyConfigパラメーターを追加します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 作成した
AddOnDeploymentConfigリソースを参照して、ManagedClusterAddOnリソースを更新します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.10. マネージドクラスターの kube-apiserver リソースにアクセスして、データを収集、設定、表示する
クラスタープロキシーアドオンを使用して、マネージドクラスター kube-apiserver リソースまたはマネージドクラスターサービスにアクセスし、特定のリソースを収集し、ログを取得し、コンソールでデータを表示します。3 つの異なる方法を使用して kube-apiserver にアクセスします。以下のトピックを参照してください。
必要なアクセス権限: 編集
1.7.10.1. 前提条件
- クラスタープロキシーアドオンを有効にする 必要があります。
1.7.10.2. マネージドクラスターユーザートークンを使用してデータを収集する
マネージドクラスターのユーザートークンを使用してデータを収集するには、次の手順を実行して、マネージドクラスターのデフォルトの namespace 内の Pod をリスト表示します。
次のコマンドを実行して、クラスタープロキシー URL をエクスポートします。必要に応じて値を置き換えます。
export CLUSTER_PROXY_URL=https://$(oc get route -n multicluster-engine cluster-proxy-addon-user -o=jsonpath='{.spec.host}')/<managed-cluster-name>export CLUSTER_PROXY_URL=https://$(oc get route -n multicluster-engine cluster-proxy-addon-user -o=jsonpath='{.spec.host}')/<managed-cluster-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して
ConfigMapを取得します。oc get configmap kube-root-ca.crt -o=jsonpath='{.data.ca\.crt}' > hub-ca.crtoc get configmap kube-root-ca.crt -o=jsonpath='{.data.ca\.crt}' > hub-ca.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、認証局 (CA) 証明書を転送します。
curl --cacert hub-ca.crt -H "Authorization: Bearer $TOKEN" https://$CLUSTER_PROXY_URL/api/v1/namespaces/default/pods
curl --cacert hub-ca.crt -H "Authorization: Bearer $TOKEN" https://$CLUSTER_PROXY_URL/api/v1/namespaces/default/podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: マネージドクラスターのデフォルトの namespace 内の Pod をリスト表示する権限を持つユーザートークンが必要です。
1.7.10.3. ハブクラスターユーザートークンを使用してデータを収集する
ハブクラスターユーザートークンを使用してデータを収集するには、両方のクラスターが同じユーザーを認識できるように、ターゲットハブクラスターとターゲットマネージドクラスターの両方で同じ外部アイデンティティープロバイダーを使用する必要があります。
ハブクラスター developer ユーザートークンを使用してデフォルトの namespace 内の Pod をリスト表示するには、まずマネージドクラスターで developer 用の正しい Role と RoleBinding を作成する必要があります。
Red Hat Advanced Cluster Management for Kubernetes を使用している場合は、ClusterPermission API を使用して、ハブクラスターから Role および RoleBinding オブジェクトを作成できます。
Pod の get と list 権限をユーザー developer にバインドする次の例を参照してください。
1.7.10.4. マネージドクラスターサービスを使用してデータを収集する
マネージドクラスターサービスにアクセスしてデータを収集するには、マネージドクラスターは Red Hat OpenShift Container Platform クラスターでなければなりません。また、サービスが services-serving-certificate サービスを使用してサーバー証明書を生成する必要があります。
以下の手順を実行します。
マネージドクラスターから Prometheus サービストークンを取得します。以下のコマンドを実行します。
export PROMETHEUS_TOKEN=$(kubectl get secret -n openshift-monitoring $(kubectl get serviceaccount -n openshift-monitoring prometheus-k8s -o=jsonpath='{.secrets[0].name}') -o=jsonpath='{.data.token}' | base64 -d)export PROMETHEUS_TOKEN=$(kubectl get secret -n openshift-monitoring $(kubectl get serviceaccount -n openshift-monitoring prometheus-k8s -o=jsonpath='{.secrets[0].name}') -o=jsonpath='{.data.token}' | base64 -d)Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターから Prometheus 管理クラスターメトリクスを取得します。以下のコマンドを実行します。
export SERVICE_NAMESPACE=openshift-monitoring export SERVICE_NAME=prometheus-k8s export SERVICE_PORT=9091 export SERVICE_PATH="api/v1/query?query=machine_cpu_sockets" curl --cacert hub-ca.crt $CLUSTER_PROXY_URL/api/v1/namespaces/$SERVICE_NAMESPACE/services/$SERVICE_NAME:$SERVICE_PORT/proxy-service/$SERVICE_PATH -H "Authorization: Bearer $PROMETHEUS_TOKEN"
export SERVICE_NAMESPACE=openshift-monitoring export SERVICE_NAME=prometheus-k8s export SERVICE_PORT=9091 export SERVICE_PATH="api/v1/query?query=machine_cpu_sockets" curl --cacert hub-ca.crt $CLUSTER_PROXY_URL/api/v1/namespaces/$SERVICE_NAMESPACE/services/$SERVICE_NAME:$SERVICE_PORT/proxy-service/$SERVICE_PATH -H "Authorization: Bearer $PROMETHEUS_TOKEN"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.11. マネージドクラスターで実行する Ansible Automation Platform タスクの設定
multicluster engine Operator は Red Hat Ansible Automation Platform と統合されているため、クラスターの作成またはアップグレードの前後に実行される prehook および posthook Ansible ジョブインスタンスを作成できます。クラスター破棄の prehook および posthook ジョブの設定やクラスターのスケールアクションはサポートされません。
必要なアクセス権: クラスター管理者
1.7.11.1. 前提条件
クラスターで自動化テンプレートを実行するには、次の前提条件を満たす必要があります。
- OpenShift Container Platform をインストールする。
- Ansible Automation Platform Resource Operator をインストールして、Ansible ジョブを Git サブスクリプションのライフサイクルに接続している。自動化テンプレートを使用して Ansible Automation Platform ジョブを起動する場合に最良の結果を得るには、Ansible Automation Platform ジョブテンプレートを実行時にべき等にする必要があります。Ansible Automation Platform Resource Operator は、OpenShift Container Platform OperatorHub ページから検索できます。
-
Ansible Automation Platform Resource Operator をインストールするときに、
*-cluster-scopedチャネルを選択し、all namespaces インストールモードを選択する。
1.7.11.2. コンソールを使用して、クラスターで実行するように、自動化 テンプレートを設定する
クラスターの作成時、クラスターのインポート時、またはクラスターの作成後、クラスターに使用する自動化テンプレートを指定できます。
クラスターの作成時またはインポート時にテンプレートを指定するには、Automation の手順でクラスターに適用する Ansible テンプレートを選択します。自動化テンプレートがない場合は、Add automation template をクリックして作成します。
クラスターの作成後にテンプレートを指定するには、既存のクラスターのアクションメニューで Update automation template をクリックします。Update automation template オプションを使用して、既存の自動化テンプレートを更新することもできます。
1.7.11.3. 自動化テンプレートの作成
クラスターのインストールまたはアップグレードで Ansible ジョブを開始するには、自動化テンプレートを作成して、いつジョブを実行するかを指定する必要があります。これらは、クラスターのインストールまたはアップグレード前後に実行するように設定できます。
テンプレートの作成時に Ansible テンプレートの実行に関する詳細を指定するには、コンソールで以下の手順を実行します。
- ナビゲーションから Infrastructure > Automation を選択します。
状況に適したパスを選択します。
- 新規テンプレートを作成する場合には、Create Ansible template をクリックして手順 3 に進みます。
- 既存のテンプレートを変更する場合は、変更するテンプレートの Options メニューの Edit template をクリックして、手順 5 に進みます。
- 一意のテンプレート名を入力します。名前には小文字の英数字またはハイフン (-) を指定してください。
- 新規テンプレートの認証情報を選択します。
認証情報を選択した後、すべてのジョブに使用する Ansible インベントリーを選択できます。Ansible 認証情報を Ansible テンプレートにリンクするには、以下の手順を実行します。
- ナビゲーションから Automation を選択します。認証情報にリンクされていないテンプレートの一覧内のテンプレートには、テンプレートを既存の認証情報にリンクするために使用できるリンク 認証情報へのリンク アイコンが含まれています。テンプレートと同じ namespace の認証情報のみが表示されます。
- 選択できる認証情報がない場合や、既存の認証情報を使用しない場合は、リンクするテンプレートの Options メニューから Edit template を選択します。
- 認証情報を作成する場合は、Add credential をクリックして、Ansible Automation Platform の認証情報の作成 の手順を行います。
- テンプレートと同じ namespace に認証情報を作成したら、テンプレートの編集時に Ansible Automation Platform credential フィールドで認証情報を選択します。
- クラスターをインストールする前に、Ansible ジョブを開始する場合は、Pre-install Automation templates セクションの Add an Automation template を選択します。
表示されるモーダルで
Job templateまたはWorkflow job templateを選択します。job_tags、Skip_tags、およびワークフロータイプを追加することもできます。-
Extra variables フィールドを使用して、
キー=値ペアの形式でデータをAnsibleJobリソースに渡します。 -
特殊キーの
cluster_deploymentとinstall_configは、追加の変数として自動的に渡されます。こちらには、クラスターに関する一般情報とクラスターのインストール設定に関する詳細が含まれています。
-
Extra variables フィールドを使用して、
- クラスターのインストールまたはアップグレードに追加するプリフックおよびポストフックの Ansible ジョブの名前を選択します。
- 必要に応じて、Ansible ジョブをドラッグして、順番を変更します。
-
インストール後の自動化テンプレート セクション、アップグレード前の自動化テンプレート セクション、および アップグレード後の自動化テンプレート セクションでクラスターのインストール後に開始するすべての自動化テンプレートに手順 5 〜 7 を繰り返します。クラスターをアップグレードする場合、
Extra variablesフィールドを使用して、key=valueペアの形式でAnsibleJobリソースにデータを渡すことができます。cluster_deployment特殊キーおよびinstall_config特殊キーに加えて、cluster_info特殊キーも、ManagedClusterInfoリソースからのデータを含む追加変数として自動的に渡されます。
Ansible テンプレートは、指定のアクションが起こるタイミングで、このテンプレートを指定するクラスターで実行するように設定されます。
1.7.11.4. Ansible ジョブのステータスの表示
実行中の Ansible ジョブのステータスを表示して、起動し、正常に実行されていることを確認できます。実行中の Ansible ジョブの現在のステータスを表示するには、以下の手順を実行します。
- メニューで、Infrastructure > Clusters を選択して、Clusters ページにアクセスします。
- クラスターの名前を選択して、その詳細を表示します。
クラスター情報で Ansible ジョブの最後の実行ステータスを表示します。エントリーには、以下のステータスの 1 つが表示されます。
-
インストール prehook または posthook ジョブが失敗すると、クラスターのステータスは
Failedと表示されます。 - アップグレード prehook または posthook ジョブが失敗すると、アップグレードに失敗した Distribution フィールドに警告が表示されます。
-
インストール prehook または posthook ジョブが失敗すると、クラスターのステータスは
1.7.11.5. 失敗した Ansible ジョブを再度実行する
クラスターの prehook または posthook が失敗した場合は、Clusters ページからアップグレードを再試行できます。
時間を節約するために、クラスター自動化テンプレートの一部である失敗した Ansible ポストフックのみを実行できるようになりました。アップグレード全体を再試行せずに、ポストフックのみを再度実行するには、次の手順を実行します。
次のコンテンツを
ClusterCuratorリソースのルートに追加して、インストールポストフックを再度実行します。operation: retryPosthook: installPosthook
operation: retryPosthook: installPosthookCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコンテンツを
ClusterCuratorリソースのルートに追加して、アップグレードポストフックを再度実行します。operation: retryPosthook: upgradePosthook
operation: retryPosthook: upgradePosthookCopy to Clipboard Copied! Toggle word wrap Toggle overflow
コンテンツを追加すると、Ansible ポストフックを実行するための新しいジョブが作成されます。
1.7.11.6. すべてのジョブに使用する Ansible インベントリーの指定
ClusterCurator リソースを使用して、すべてのジョブに使用する Ansible インベントリーを指定できます。以下の例を参照してください。channel と desiredUpdate を ClusterCurator の正しい値に置き換えます。
注記: サンプルリソースを使用するには、インベントリーが Ansible にすでに存在している必要があります。
コンソールから利用可能な Ansible インベントリーのリストを確認すると、インベントリーが作成されていることを確認できます。
1.7.11.7. ClusterCurator リソースから自動化ジョブ Pod へのカスタムラベルのプッシュ
ClusterCurator リソースを使用して、カスタムラベルを Cluster Curator によって作成された自動化ジョブ Pod にプッシュできます。カスタムラベルをすべてのキュレーションタイプにプッシュできます。以下の例を参照してください。
1.7.11.8. Extended Update Support (EUS) アップグレードに ClusterCurator を使用する
ClusterCurator リソースを使用すると、EUS リリース間のアップグレードをより簡単に自動で実行できます。
spec.upgrade.intermediateUpdateをClusterCuratorリソースに追加し、中間リリースの値を指定します。次のサンプルを参照してください。中間リリースは4.17.xで、desiredUpdateは4.18.xです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション:
machineconfigpoolsを一時停止すると、中間リリースをスキップしてアップグレードを迅速化できます。posthookジョブにUnpause machinepoolと入力し、prehookジョブにpause machinepoolと入力します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
EUS から EUS にアップグレードするように設定された ClusterCurator の完全な例を次に示します。
1.7.12. Ansible Automation Platform ジョブをホステッドクラスター上で実行されるように設定
Red Hat Ansible Automation Platform は multicluster engine Operator と統合されているため、ホステッドクラスターの作成または更新の前後に実行される prehook および posthook Ansible Automation Platform ジョブインスタンスを作成できます。
必要なアクセス権: クラスター管理者
1.7.12.1. 前提条件
クラスターで自動化テンプレートを実行するには、次の前提条件を満たす必要があります。
- サポートされているバージョンの OpenShift Container Platform
- Ansible Automation Platform Resource Operator をインストールして、Ansible Automation Platform ジョブを Git サブスクリプションのライフサイクルに接続する。Automation テンプレートを使用して Ansible Automation Platform ジョブを開始する場合は、実行時に Ansible Automation Platform ジョブテンプレートが冪等である。Ansible Automation Platform Resource Operator は、OpenShift Container Platform OperatorHub ページから検索できます。
1.7.12.2. Ansible Automation Platform ジョブを実行してホステッドクラスターをインストールする
ホステッドクラスターをインストールする Ansible Automation Platform ジョブを開始するには、次の手順を実行します。
pausedUntil: trueフィールドを含むHostedClusterおよびNodePoolリソースを作成します。hcp create clusterコマンドラインインターフェイスコマンドを使用する場合は、--pausedUntil: trueフラグを指定できます。以下の例を参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow HostedClusterリソースと同じ名前とHostedClusterリソースと同じ namespace で、ClusterCuratorリソースを作成します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ansible Automation Platform Tower で認証が必要な場合は、シークレットリソースを作成します。以下の例を参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.12.3. Ansible Automation Platform ジョブを実行してホステッドクラスターを更新する
ホステッドクラスターを更新する Ansible Automation Platform ジョブを実行するには、更新するホステッドクラスターの ClusterCurator リソースを編集します。以下の例を参照してください。
- 1
- サポート対象バージョンの詳細は、Hosted Control Plane を参照してください。
注: この方法でホステッドクラスターを更新すると、Hosted Control Plane とノードプールの両方が同じバージョンに更新されます。Hosted Control Plane とノードプールを別のバージョンに更新することはサポートされていません。
1.7.12.4. Ansible Automation Platform ジョブを実行してホステッドクラスターを削除する
ホステッドクラスターを削除する Ansible Automation Platform ジョブを実行するには、削除するホステッドクラスターの ClusterCurator リソースを編集します。以下の例を参照してください。
注記: AWS 上のホステッドクラスターの削除はサポートされていません。
1.7.12.5. 関連情報
-
Hosted Control Plane コマンドラインインターフェイス (
hcp) の詳細は、Hosted Control Plane コマンドラインインターフェイスのインストール を参照してください。 - サポートされているバージョンなど、ホステッドクラスターの詳細は、Hosted Control Plane の概要 を参照してください。
1.7.13. ClusterClaims
ClusterClaim は、マネージドクラスター上のカスタムリソース定義 (CRD) です。ClusterClaim は、マネージドクラスターが要求する情報の一部を表します。ClusterClaim を使用して、ターゲットクラスター上のリソースの配置を決定できます。
次の例は、YAML ファイルで指定された ClusterClaim を示しています。
次の表は、multicluster engine Operator が管理するクラスターの定義済み ClusterClaim のリストを示しています。
| 要求名 | 予約 | 変更可能 | 説明 |
|---|---|---|---|
|
| true | false | アップストリームの提案で定義された ClusterID |
|
| true | true | Kubernetes バージョン |
|
| true | false | マネージドクラスターが実行されているプラットフォーム (AWS、GCE、Equinix Metal など) |
|
| true | false | 製品名 (OpenShift、Anthos、EKS、GKE など) |
|
| false | false | OpenShift Container Platform クラスターでのみ利用できる OpenShift Container Platform 外部 ID |
|
| false | true | OpenShift Container Platform クラスターでのみ利用できる管理コンソールの URL |
|
| false | true | OpenShift Container Platform クラスターでのみ利用できる OpenShift Container Platform バージョン |
マネージドクラスターで以前の要求が削除されるか、更新されると、自動的に復元またはロールバックされます。
マネージドクラスターがハブに参加すると、マネージドクラスターで作成された ClusterClaim が、ハブクラスター上の ManagedCluster リソースのステータスと同期されます。以下に示す ManagedCluster の clusterClaims の例を参照してください。4.x は、OpenShift Container Platform のサポートされているバージョンに置き換えます。
1.7.13.1. カスタム ClusterClaims の作成
カスタム名を持つ ClusterClaim リソースをマネージドクラスターに作成すると、リソースを識別しやすくなります。カスタムの ClusterClaim リソースは、ハブクラスター上の ManagedCluster リソースのステータスと同期されます。以下のコンテンツでは、カスタマイズされた ClusterClaim リソースの定義例を示しています。
spec.value フィールドの長さは 1024 以下である必要があります。ClusterClaim リソースを作成するには clusterclaims.cluster.open-cluster-management.io リソースの create 権限が必要です。
1.7.13.2. 既存の ClusterClaim の表示
kubectl コマンドを使用して、マネージドクラスターに適用される ClusterClaim をリスト表示すると、ClusterClaim をエラーメッセージと比較することができます。
注記: clusterclaims.cluster.open-cluster-management.io のリソースに list の権限があることを確認します。
以下のコマンドを実行して、マネージドクラスターにある既存の ClusterClaim のリストを表示します。
kubectl get clusterclaims.cluster.open-cluster-management.io
kubectl get clusterclaims.cluster.open-cluster-management.io1.7.14. ManagedClusterSets
ManagedClusterSet は、マネージドクラスターのグループです。マネージドクラスターセット。すべてのマネージドクラスターへのアクセスを管理するのに役立ちます。ManagedClusterSetBinding リソースを作成して ManagedClusterSet リソースを namespace にバインドすることもできます。
各クラスターは、マネージドクラスターセットのメンバーである必要があります。ハブクラスターをインストールすると、default という名前の ManagedClusterSet リソースが作成されます。マネージドクラスターセットに割り当てられていないすべてのクラスターは、default マネージドクラスターセットに自動的に割り当てられます。default マネージドクラスターセットを削除または更新することはできません。
マネージドクラスターセットの作成および管理方法の詳細は、以下を参照してください。
1.7.14.1. ManagedClusterSet の作成
マネージドクラスターセットにマネージドクラスターをグループ化して、マネージドクラスターでのユーザーのアクセス権限を制限できます。
必要なアクセス権: クラスター管理者
ManagedClusterSet は、クラスタースコープのリソースであるため、ManagedClusterSet の作成先となるクラスターで管理者権限が必要です。マネージドクラスターは、複数の ManagedClusterSet に追加できません。マネージドクラスターセットは、multicluster engine Operator コンソールまたは CLI から作成できます。
注記: マネージドクラスターセットに追加されていないクラスタープールは、デフォルトの ManagedClusterSet リソースに追加されません。クラスターがクラスタープールから要求されると、クラスターはデフォルトの ManagedClusterSet に追加されます。
multicluster engine Operator をインストールすると、管理を容易にするために、ハブクラスターに次のリソースが自動的に作成されます。
-
globalと呼ばれるManagedClusterSet。 -
open-cluster-management-global-setという namespace。 globalと呼ばれるManagedClusterSetBindingは、globalManagedClusterSetをopen-cluster-management-global-setnamespace にバインドします。作成したマネージドクラスターは、デフォルトで
globalManagedClusterSetに属します。重要:
globalマネージドクラスターセットを削除、更新、または編集することはできません。globalマネージドクラスターセットには、すべてのマネージドクラスターが含まれます。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.14.1.1. CLI を使用した ManagedClusterSet の作成
CLI を使用してマネージドクラスターセットの定義を YAML ファイルに追加し、マネージドクラスターセットを作成します。
apiVersion: cluster.open-cluster-management.io/v1beta2 kind: ManagedClusterSet metadata: name: <cluster_set>
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
name: <cluster_set>
<cluster_set> をマネージドクラスターセットの名前に置き換えます。
1.7.14.1.2. クラスターの ManagedClusterSet への追加
ManagedClusterSet の作成後に、コンソールまたは CLI を使用してクラスターをマネージドクラスターセットに追加できます。
1.7.14.1.3. CLI を使用したクラスターの ManagedClusterSet への追加
CLI を使用してクラスターをマネージドクラスターに追加するには、以下の手順を実行します。
managedclustersets/joinの仮想サブリソースに作成できるように、RBACClusterRoleエントリーが追加されていることを確認します。注記: この権限がないと、マネージドクラスターを
ManagedClusterSetに割り当てることはできません。このエントリーが存在しない場合は、YAML ファイルに追加します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <cluster_set>をManagedClusterSetの名前に置き換えます。注記: マネージドクラスターを別の
ManagedClusterSetに移動する場合には、両方のマネージドクラスターセットで権限の設定が必要です。YAML ファイルでマネージドクラスターの定義を検索します。以下の定義例を参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster.open-cluster-management.io/clustersetパラメーターを追加し、ManagedClusterSetの名前を指定します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.14.2. ManagedClusterSet への RBAC 権限の割り当て
ハブクラスターに設定したアイデンティティープロバイダーが提供するクラスターセットに、ユーザーまたはグループを割り当てることができます。
必要なアクセス権: クラスター管理者
ManagedClusterSet API RBAC 権限レベルは、以下の表を参照してください。
| クラスターセット | アクセス権限 | 権限の作成 |
|---|---|---|
|
| マネージドクラスターセットに割り当てられたすべてのクラスターおよびクラスタープールリソースへのフルアクセス権限。 | クラスターの作成、クラスターのインポート、クラスタープールの作成権限。権限は、作成時にマネージドクラスターセットに割り当てる必要があります。 |
|
|
| クラスターの作成、クラスターのインポート、またはクラスタープールの作成を実行する権限なし。 |
|
| マネージドクラスターセットに割り当てられたすべてのクラスターおよびクラスタープールリソースに対する読み取り専用権限。 | クラスターの作成、クラスターのインポート、またはクラスタープールの作成を実行する権限なし。 |
注記: グローバルクラスターセットにクラスターセットの admin 権限を適用することはできません。
コンソールからマネージドクラスターセットにユーザーまたはグループを割り当てるには、次の手順を実行します。
- OpenShift Container Platform コンソールから、Infrastructure > Clusters に移動します。
- Cluster sets タブを選択します。
- ターゲットクラスターセットを選択します。
- Access management タブを選択します。
- Add user or group を選択します。
- アクセス権を割り当てるユーザーまたはグループを検索して選択します。
- Cluster set admin または Cluster set view ロールを選択して、選択したユーザーまたはグループに付与します。詳細は、multicluster engine Operator のロールベースのアクセス制御 の ロールの概要 を参照してください。
- Add を選択して変更を送信します。
テーブルにユーザーまたはグループが表示されます。全マネージドクラスターセットリソースの権限の割り当てがユーザーまたはグループに伝播されるまでに数秒かかる場合があります。
placement 情報は、ManagedCusterSets からの ManagedClusters のフィルタリング を参照してください。
1.7.14.3. ManagedClusterSetBinding リソースの作成
ManagedClusterSetBinding リソースは、ManagedClusterSet リソースを namespace にバインドします。同じ namespace で作成されたアプリケーションおよびポリシーは、バインドされたマネージドクラスターセットリソースに含まれるクラスターにのみアクセスできます。
namespace へのアクセス権限は、その namespace にバインドされるマネージドクラスターセットに自動的に適用されます。その namespace へのアクセス権限を持つ場合、その namespace にバインドされるマネージドクラスターセットへのアクセス権限が自動的に付与されます。マネージドクラスターセットにアクセスする権限のみがある場合、namespace の他のマネージドクラスターセットにアクセスする権限は自動的に割り当てられません。
コンソールまたはコマンドラインを使用してマネージドクラスターセットバインドを作成できます。
1.7.14.3.1. コンソールを使用した ManagedClusterSetBinding の作成
コンソールを使用して ManagedClusterSetBinding を作成するには、以下の手順を実行します。
- OpenShift Container Platform コンソールから、Infrastructure > Clusters に移動し、Cluster sets タブを選択します。
- バインドを作成するクラスターセットの名前を選択します。
- Actions > Edit namespace bindings に移動します。
- Edit namespace bindings ページで、ドロップダウンメニューからクラスターセットをバインドする namespace を選択します。
1.7.14.3.2. CLI を使用した ManagedClusterSetBinding の作成
CLI を使用して ManagedClusterSetBinding を作成するには、以下の手順を実行します。
YAML ファイルに
ManagedClusterSetBindingリソースを作成します。注記: マネージドクラスターセットバインドを作成する場合、マネージドクラスターセットバインドの名前は、バインドするマネージドクラスターセットの名前と一致する必要があります。
ManagedClusterSetBindingリソースは、以下の情報のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ターゲットのマネージドクラスターセットでのバインド権限を割り当てておく必要があります。次の
ClusterRoleリソースの例を表示します。これには、ユーザーが<cluster_set>にバインドすることを許可するルールが含まれています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.14.4. taint と toleration を使用したマネージドクラスターの配置
taint と toleration を使用して、マネージドクラスターまたはマネージドクラスターセットの placement を制御できます。taint と toleration は、特定の placement でマネージドクラスターが選択されないようにする方法を提供します。この制御は、特定のマネージドクラスターが一部の placement に含まれないようにする場合に役立ちます。taint をマネージドクラスターに、toleration を placement に追加できます。taint と toleration が一致しないと、マネージドクラスターはその placement に選択されません。
1.7.14.4.1. マネージドクラスターへの taint の追加
taint はマネージドクラスターのプロパティーで指定され、placement がマネージドクラスターまたはマネージドクラスターのセットを除外できます。
taint セクションが存在しない場合は、次の例のようなコマンドを実行して、マネージドクラスターに taint を追加できます。
oc patch managedcluster <managed_cluster_name> -p '{"spec":{"taints":[{"key": "key", "value": "value", "effect": "NoSelect"}]}}' --type=merge
oc patch managedcluster <managed_cluster_name> -p '{"spec":{"taints":[{"key": "key", "value": "value", "effect": "NoSelect"}]}}' --type=mergeまたは、次の例のようなコマンドを実行して、既存の taint に taint を追加することもできます。
oc patch managedcluster <managed_cluster_name> --type='json' -p='[{"op": "add", "path": "/spec/taints/-", "value": {"key": "key", "value": "value", "effect": "NoSelect"}}]'
oc patch managedcluster <managed_cluster_name> --type='json' -p='[{"op": "add", "path": "/spec/taints/-", "value": {"key": "key", "value": "value", "effect": "NoSelect"}}]'taint の仕様には以下のフィールドが含まれます。
-
(必須) Key: クラスターに適用される taint キー。この値は、その placement に追加される基準を満たすように、マネージドクラスターの toleration の値と一致させる必要があります。この値は確認できます。たとえば、この値は
barまたはfoo.example.com/barです。 -
(オプション) Value: taint キーの taint 値。この値は、その placement に追加される基準を満たすように、マネージドクラスターの toleration の値と一致させる必要があります。たとえば、この値は
valueとすることができます。 (必須) Effect: taint を許容しない placement における taint の効果、または placement の taint と toleration が一致しないときに何が起こるか。effect の値は、以下のいずれかの値である必要があります。
-
NoSelect: placement は、この taint を許容しない限り、クラスターを選択できません。taint の設定前に placement でクラスターが選択された場合は、クラスターは placement の決定から削除されます。 -
NoSelectIfNew: スケジューラーは、クラスターが新しい場合にそのクラスターを選択できません。プレイスメントは、taint を許容し、すでにクラスター決定にそのクラスターがある場合にのみ、そのクラスターを選択することができます。
-
-
(必須)
TimeAdded: taint を追加した時間。この値は自動的に設定されます。
1.7.14.4.2. マネージドクラスターのステータスを反映させる組み込み taint の特定
マネージドクラスターにアクセスできない場合には、クラスターを placement に追加しないでください。以下の taint は、アクセスできないマネージドクラスターに自動的に追加されます。
cluster.open-cluster-management.io/unavailable: この taint は、ステータスがFalseのManagedClusterConditionAvailableの条件がある場合にマネージドクラスターに追加されます。taint にはNoSelectと同じ効果があり、空の値を指定すると、利用不可のクラスターがスケジュールされないようにできます。この taint の例は、以下の内容のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster.open-cluster-management.io/unreachable-ManagedClusterConditionAvailableの条件のステータスがUnknownであるか、条件がない場合に、この taint はマネージドクラスターに追加されます。この taint にはNoSelectと同じ効果があり、空の値を指定すると、到達不可のクラスターがスケジュールされないようにできます。この taint の例は、以下の内容のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.14.4.3. toleration の placement への追加
toleration は placement に適用され、placement の toleration と taint が同じでないマネージドクラスターを placement から除外できます。toleration の仕様には以下のフィールドが含まれます。
- (任意) Key: キーは placement ができるように taint キーに一致します。
- (任意) Value: toleration の値は、placement を許可する toleration の taint の値と一致する必要があります。
(任意) Operator: 演算子はキーと値の関係を表します。有効な演算子は
equalとexistsです。デフォルト値はequalです。toleration は、キーが同じ場合、効果が同じ場合、さらび Operator が以下の値のいずれかである場合に、taint にマッチします。-
equal: Operator がequalで、値は taint および toleration と同じになります。 -
exists: 値のワイルドカード。これにより、placement は特定のカテゴリーのすべての taint を許容できます。
-
-
(任意) Effect: 一致する taint の効果。空のままにすると、すべての taint の効果と一致します。指定可能な値は、
NoSelectまたはNoSelectIfNewです。 -
(任意) TolerationSeconds: マネージドクラスターを新しい placement に移動する前に、taint を許容する時間の長さ (秒単位) です。effect 値が
NoSelectまたはPreferNoSelectでない場合は、このフィールドは無視されます。デフォルト値はnilで、時間制限がないことを示します。TolerationSecondsのカウント開始時刻は、クラスターのスケジュール時刻やTolerationSeconds加算時刻の値ではなく、自動的に taint のTimeAddedの値として記載されます。
以下の例は、taint が含まれるクラスターを許容する toleration を設定する方法を示しています。
この例のマネージドクラスターの taint:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow taint を許容できる placement の toleration
Copy to Clipboard Copied! Toggle word wrap Toggle overflow toleration の定義例では、
key: gpuとvalue: "true"が一致するため、placement でcluster1を選択できます。
注記: マネージドクラスターは、taint の toleration が含まれる placement に置かれる保証はありません。他の placement に同じ toleration が含まれる場合には、マネージドクラスターはそれらの placement のいずれかに置かれる可能性があります。
1.7.14.4.4. 一時的な toleration の指定
TolerationSeconds の値は、toleration が taint を許容する期間を指定します。この一時的な toleration は、マネージドクラスターがオフラインで、このクラスターにデプロイされているアプリケーションを、許容時間中に別のマネージドクラスターに転送できる場合に役立ちます。
たとえば、以下の taint を持つマネージドクラスターに到達できなくなります。
以下の例のように、TolerationSeconds の値で placement を定義すると、ワークロードは 5 分後に利用可能な別のマネージドクラスターに転送されます。
マネージドクラスターに到達できなくなると、アプリケーションが 5 分間別のマネージドクラスターに移動されます。
1.7.14.4.5. 関連情報
-
oc patchの使用方法は、OpenShift Container Platform ドキュメントの oc patch を参照してください。
1.7.14.5. ManagedClusterSet からのマネージドクラスターの削除
マネージドクラスターセットからマネージドクラスターを削除して別のマネージドクラスターセットに移動するか、セットの管理設定から削除する必要がある場合があります。コンソールまたは CLI を使用して、マネージドクラスターセットからマネージドクラスターを削除できます。
注記:
-
マネージドクラスターはすべて、マネージドクラスターセットに割り当てる必要があります。
ManagedClusterSetからマネージドクラスターを削除し、別のManagedClusterSetに割り当てない場合は、そのクラスターはdefaultのマネージドクラスターセットに自動的に追加されます。 -
Submariner アドオンがマネージドクラスターにインストールされている場合は、アドオンをアンインストールしてから、マネージドクラスターを
ManagedClusterSetから削除する必要があります。
1.7.14.5.1. コンソールを使用した ManagedClusterSet からのクラスターの削除
コンソールを使用してマネージドクラスターセットからクラスターを削除するには、次の手順を実行します。
- Infrastructure > Clusters をクリックし、Cluster sets タブが選択されていることを確認します。
- マネージドクラスターセットから削除するクラスターセットの名前を選択し、クラスターセットの詳細を表示します。
- Actions > Manage resource assignments を選択します。
Manage resource assignments ページで、クラスターセットから削除するリソースのチェックボックスをオフにします。
この手順では、すでにクラスターセットのメンバーであるリソースを削除します。マネージドクラスターの詳細を表示して、リソースがすでにクラスターセットのメンバーであるかどうかを確認できます。
注記: マネージドクラスターを別のマネージドクラスターセットに移動する場合には、マネージドクラスターセット両方で RBAC 権限の設定が必要です。
1.7.14.5.2. CLI を使用した ManagedClusterSet からのクラスターの削除
コマンドラインを使用してマネージドクラスターセットからクラスターを削除するには、以下の手順を実行します。
以下のコマンドを実行して、マネージドクラスターセットでマネージドクラスターのリストを表示します。
oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<cluster_set>
oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<cluster_set>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <cluster_set>をマネージドクラスターセットの名前に置き換えます。- 削除するクラスターのエントリーを見つけます。
削除するクラスターの YAML エントリーからラベルを削除します。ラベルの例は、以下のコードを参照してください。
labels: cluster.open-cluster-management.io/clusterset: clusterset1
labels: cluster.open-cluster-management.io/clusterset: clusterset1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
注記: マネージドクラスターを別のクラスターセットに移動する場合は、マネージドクラスターセット両方で RBAC 権限の設定が必要です。
1.7.15. Placement
placement リソースは、placement namespace にバインドされている ManagedClusterSets から ManagedClusters のセットを選択するルールを定義する、namespace スコープのリソースです。
必要なアクセス権: クラスター管理者、クラスターセット管理者
プレースメントの使用方法の詳細は、読み続けてください。
1.7.15.1. Placement の概要
マネージドクラスターを使用した配置がどのように機能するかは、次の情報を参照してください。
-
Kubernetes クラスターは、cluster スコープの
ManagedClustersとしてハブクラスターに登録されます。 -
ManagedClustersは、クラスタースコープのManagedClusterSetsに編成されます。 -
ManagedClusterSetsはワークロード namespace にバインドされます。 -
namespace スコープの placement では、潜在的な
ManagedClustersの作業セットを選択するManagedClusterSetsの一部を指定します。 -
placement は、
labelSelectorとclaimSelectorを使用して、ManagedClusterSetsからManagedClustersをフィルター処理します。 -
ManagedClustersの placement は、taint と toleration を使用して制御できます。 -
placement は、
Prioritizersスコアによってクラスターを並べ替え、そのグループから上位n個のクラスターを選択します。nはnumberOfClustersで定義できます。 - 配置では、削除するマネージドクラスターは選択されません。
注記:
-
namespace に
ManagedClusterSetBindingを作成して、その namespace にManagedClusterSetを最低でも 1 つバインドする必要があります。 -
managedclustersets/bindの仮想サブリソースのCREATEに対してロールベースのアクセスが必要です。
1.7.15.1.1. 関連情報
- 詳細は、taint と toleration を使用したマネージドクラスターの配置 を参照してください。
-
API と
Prioritizersの詳細は、Placements API を参照してください。 - placement を伴う ManagedClusters の選択 に戻ります。
1.7.15.2. ManagedCluster オブジェクトによるフィルタリング
labelSelector、claimSelector、または celSelector フィールドを使用して、フィルタリングする ManagedCluster オブジェクトを選択できます。フィルターの使用方法については、次の例を参照してください。
次の例では、
labelSelectorフィールドはvendor: OpenShiftラベルを持つクラスターのみに一致します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例では、
claimSelectorは、region.open-cluster-management.ioとus-west-1を持つクラスターのみを照合します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow また、
clusterSetsパラメーターを使用して、特定のクラスターセットからManagedClustersをフィルター処理することもできます。次の例では、claimSelectorはクラスターセットclusterset1およびclusterset2のみに一致します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
次の例では、Common Expression Language で
celSelectorフィールドを使用する 5 つの異なる方法を示します。1 つまたは複数の式を使用して、ManagedClusterオブジェクトをフィルタリングできます。
- 1
managedCluster.Status.version.kubernetesフィールドにリストされている Kubernetes バージョンでクラスターを選択します。- 2
clusterClaimsフィールドに保存されている情報に基づいてクラスターを選択します。- 3
managedClusterフィールドでは、Common Expression Language の標準マクロと標準関数を使用します。- 4
- バージョンの比較によってクラスターを選択するには、Kubernetes
semverライブラリー関数isLessThanとisGreaterThanを使用します。 - 5
- カスタマイズされた関数スコアを使用して、
AddonPlacementScoreフィールドでクラスターを選択します。
詳細は、関連情報セクションの Kubernetes の Common Expression Language を参照してください。
また、numberOfClusters パラメーターを使用して、フィルタリングする ManagedClusters の数を選択することもできます。以下の例を参照してください。
- 1
- 選択する
ManagedClustersの数を指定します。前の例では3に設定されています。
1.7.15.2.1. placement を使用して toleration を定義することで ManagedClusters をフィルタリングする
一致するテイントを使用して ManagedClusters をフィルタリングする方法は、次の例を参照してください。
デフォルトでは、次の例では、placement で
cluster1を選択できません。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster1を選択するには、許容範囲を定義する必要があります。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
tolerationSeconds パラメーターを使用して、指定した期間、一致するテイントを持つ ManagedClusters を選択することもできます。tolerationSeconds は、許容がテイントにバインドされ続ける期間を定義します。tolerationSeconds は、指定された時間が経過すると、オフラインになったクラスターにデプロイされたアプリケーションを別のマネージドクラスターに自動的に転送できます。
次の例を見て、tolerationSeconds の使用方法を学習します。
次の例では、マネージドクラスターにアクセスできなくなります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tolerationSecondsを使用して配置を定義すると、ワークロードは別の使用可能なマネージドクラスターに転送されます。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 何秒後にワークロードを転送するかを指定します。
1.7.15.2.2. アドオンのステータスに基づき ManagedClusters をフィルタリングする
デプロイされているアドオンのステータスに基づいて、プレースメント用のマネージドクラスターを選択することもできます。たとえば、マネージドクラスターで有効になっている特定のアドオンがある場合にのみ、placement にマネージドクラスターを選択できます。
placement を作成するときに、アドオンのラベルとそのステータスを指定できます。マネージドクラスターでアドオンが有効になっている場合、ラベルは ManagedCluster リソース上に自動的に作成されます。アドオンが無効になると、ラベルは自動的に削除されます。
各アドオンは、feature.open-cluster-management.io/addon-<addon_name>=<status_of_addon> の形式でラベルで表現します。
addon_name を選択したマネージドクラスターで有効にするアドオンの名前に置き換えます。
status_of_addon をマネージドクラスターが選択されている場合にアドオンに設定するステータスに置き換えます。
status_of_addon に指定できる値は、次の表を参照してください。
| 値 | 説明 |
|---|---|
|
| アドオンは有効化されており、利用可能です。 |
|
| アドオンは有効ですが、リースは継続的に更新されません。 |
|
| アドオンは有効ですが、そのアドオンのリースが見つかりません。これは、マネージドクラスターがオフライン時にも発生する可能性があります。 |
たとえば、使用可能な application-manager. アドオンは、マネージドクラスター上の次のようなラベルで表されます。
feature.open-cluster-management.io/addon-application-manager: available
feature.open-cluster-management.io/addon-application-manager: availableアドオンとそのステータスに基づいて placement を作成する方法は、次の例を参照してください。
次の placement 例には、
application-managerが有効になっているすべてのマネージドクラスターが含まれています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の placement 例には、
application-managerがavailableステータスで有効になっているすべてのマネージドクラスターが含まれています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の placement 例には、
application-managerが無効になっているすべてのマネージドクラスターが含まれています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.15.2.3. placement を使用して prioritizerPolicy を定義することで ManagedClusters の優先順位を付ける
次の例を参照して、prioritizerPolicy パラメーターと配置を使用して ManagedClusters に優先順位を付ける方法を学習します。
次の例では、割り当て可能なメモリーが最大のクラスターを選択します。
注記: Kubernetes Node Allocatable と同様に、'allocatable' は、各クラスターの Pod で利用可能なコンピュートリソースの量として定義されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例では、割り当て可能な最大の CPU とメモリーを持つクラスターを選択し、リソースの変更に敏感な配置を行います。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例では、
addOnスコアの CPU 比率が最も大きい 2 つのクラスターを選択し、配置の決定を固定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.15.2.4. 関連情報
- 詳細は、ノード割り当て可能 を参照してください。
- 他のトピックは Selecting ManagedClusters with placement に戻ります。
- Kubernetes の Common Expression Language の詳細は、Common Expression Language in Kubernetes を参照してください。
1.7.15.3. PlacementDecisions を使用して選択した ManagedClusters を確認する
ラベル cluster.open-cluster-management.io/placement={placement_name} を持つ 1 つ以上の PlacementDecision 種類が、プレースメントによって選択された ManagedClusters を表すために作成されます。
ManagedCluster を選択して PlacementDecision に追加すると、この placement を使用するコンポーネントがこの ManagedCluster にワークロードを適用する可能性があります。
ManagedCluster を選択せずに PlacementDecision から削除すると、この ManagedCluster に適用されているワークロードが削除されます。toleration を定義することで、ワークロードの削除を回避できます。
toleration の定義の詳細は、placement を使用して toleration を定義することで ManagedClusters をフィルタリングする を参照してください。
次の PlacementDecision の例を参照してください。
1.7.15.3.1. 関連情報
- API の詳細は、PlacementDecisions API を参照してください。
1.7.16. クラスタープールの管理 (テクノロジープレビュー)
クラスタープールは、Red Hat OpenShift Container Platform クラスターにオンデマンドで、スケーリングする場合に、迅速かつコスト効果を高く保ちながら、アクセスできるようにします。クラスタープールは、Amazon Web Services、Google Cloud Platform または Microsoft Azure で設定可能な数多くの OpenShift Container Platform クラスターをプロビジョニングします。このプールは、開発、継続統合、および実稼働のシナリオにおいてクラスター環境を提供したり、置き換えたりする場合に特に便利です。実行を継続するクラスターの数を指定して、すぐに要求できるようにすることができます。残りのクラスターは休止状態に保たれるため、数分以内に再開して要求できます。
ClusterClaim リソースは、クラスタープールからクラスターをチェックアウトするために使用されます。クラスター要求が作成されると、その要求にプールは実行中のクラスターを割り当てます。実行中のクラスターがない場合は、休止状態のクラスターを再開してクラスターを提供するか、新規クラスターをプロビジョニングします。クラスタープールは自動的に新しいクラスターを作成し、休止状態のクラスターを再開して、プール内で利用可能な実行中のクラスターの指定サイズおよび数を維持します。
クラスタープールを作成する手順は、クラスターの作成手順と似ています。クラスタープールのクラスターは、すぐ使用するために作成されるわけではありません。
1.7.16.1. クラスタープールの作成
クラスタープールを作成する手順は、クラスターの作成手順と似ています。クラスタープールのクラスターは、すぐ使用するために作成されるわけではありません。
必要なアクセス権限: 管理者
1.7.16.1.1. 前提条件
クラスタープールを作成する前に、次の前提条件を参照してください。
- multicluster engine Operator ハブクラスターをデプロイする必要があります。
- プロバイダー環境で Kubernetes クラスターを作成できるように、multicluster engine Operator ハブクラスターのインターネットアクセスが必要です。
- AWS、GCP、または Microsoft Azure プロバイダーのクレデンシャルが必要です。詳細は、認証情報の管理の概要 を参照してください。
- プロバイダー環境で設定済みのドメインが必要です。ドメインの設定方法は、プロバイダーのドキュメントを参照してください。
- プロバイダーのログイン認証情報が必要です。
- OpenShift Container Platform イメージプルシークレットが必要です。イメージプルシークレットの使用 を参照してください。
注記: この手順でクラスタープールを追加すると、プールからクラスターを要求するときに、multicluster engine Operator で管理するために、クラスターを自動的にインポートするようにクラスタープールが設定されます。クラスター要求を使用して管理するために、要求されたクラスターを自動的にインポートしないクラスタープールを作成する場合は、clusterClaim リソースに次のアノテーションを追加してください。
kind: ClusterClaim
metadata:
annotations:
cluster.open-cluster-management.io/createmanagedcluster: "false"
kind: ClusterClaim
metadata:
annotations:
cluster.open-cluster-management.io/createmanagedcluster: "false" - 1
- 文字列であることを示すには、
"false"という単語を引用符で囲む必要があります。
1.7.16.1.2. クラスタープールを作成する
クラスタープールを作成するには、ナビゲーションメニューで Infrastructure > Clusters を選択します。Cluster pools タブには、アクセス可能なクラスタープールがリスト表示されます。Create cluster pool を選択し、コンソールの手順を実行します。
クラスタープールに使用するインフラストラクチャー認証情報がない場合は、Add credential を選択して作成できます。
リストから既存の namespace を選択するか、作成する新規 namespace の名前を入力します。クラスタープールは、クラスターと同じ namespace に配置する必要はありません。
クラスタープールの RBAC ロールを使用して、既存クラスターセットのロール割り当てを共有する場合は、クラスターセット名を選択します。クラスタープールのクラスターセットは、クラスタープールの作成時にのみ設定できます。クラスタープールの作成後には、クラスタープールまたはクラスタープールのクラスターセットの関連付けを変更できません。クラスタープールから要求したクラスターは、クラスタープールと同じクラスターセットに自動的に追加されます。
注記: cluster admin の権限がない場合は、クラスターセットを選択する必要があります。この状況でクラスターセットの名前が含まれない場合は、禁止エラーで、クラスターセットの作成要求が拒否されます。選択できるクラスターセットがない場合は、クラスター管理者に連絡してクラスターセットを作成し、clusterset admin 権限を付与してもらいます。
cluster pool size は、クラスタープールにプロビジョニングするクラスターの数を指定し、クラスタープールの実行回数は、プールが実行を継続し、すぐに使用できるように要求できるクラスターの数を指定します。
この手順は、クラスターを作成する手順と非常に似ています。
プロバイダーに必要な固有の情報は、以下を参照してください。
1.7.16.2. クラスタープールからのクラスターの要求
ClusterClaim リソースは、クラスタープールからクラスターをチェックアウトするために使用されます。クラスターの稼働中で、クラスタープールで準備できると、要求が完了します。クラスタープールは、クラスタープールに指定された要件を維持するために、クラスタープールに新しい実行中およびハイバネートされたクラスターを自動的に作成します。
注記: クラスタープールから要求されたクラスターが不要になり、破棄されると、リソースは削除されます。クラスターはクラスタープールに戻りません。
必要なアクセス権限: 管理者
1.7.16.2.1. 前提条件
使用可能なクラスターの有無にかかわらず、クラスタープールが必要です。クラスタープールに利用可能なクラスターがある場合、利用可能なクラスターが要求されます。クラスタープールに利用可能なクラスターがない場合は、要求を満たすためにクラスターが作成されます。クラスタープールの作成方法は、クラスタープールの作成 を参照してください。
1.7.16.2.2. クラスタープールからのクラスターの要求
クラスター要求の作成時に、クラスタープールから新規クラスターを要求します。クラスターが利用可能になると、クラスターはプールからチェックアウトされます。自動インポートを無効にしていない限り、要求されたクラスターはマネージドクラスターの 1 つとして自動的にインポートされます。
以下の手順を実行してクラスターを要求します。
- ナビゲーションメニューから Infrastructure > Clusters をクリックし、Cluster pools タブを選択します。
- クラスターを要求するクラスタープールの名前を見つけ、Claim cluster を選択します。
クラスターが利用可能な場合には、クラスターが要求され、マネージドクラスター タブにすぐに表示されます。利用可能なクラスターがない場合は、休止状態のクラスターの再開や、新しいクラスターのプロビジョニングに数分かかる場合があります。この間、要求のステータスは pending です。クラスタープールをデプロイメントして、保留中の要求を表示または削除します。
要求されたクラスターは、クラスタープールにあった時に関連付けられたクラスターセットに所属します。要求時には、要求したクラスターのクラスターセットは変更できません。
注記: クラウドプロバイダー認証情報のプルシークレット、SSH キー、またはベースドメインへの変更は、元の認証情報を使用してすでにプロビジョニングされているため、クラスタープールから要求された既存のクラスターには反映されません。コンソールを使用してクラスタープール情報を編集することはできませんが、CLI インターフェイスを使用してその情報を更新することで更新できます。更新された情報を含む認証情報を使用して、新しいクラスタープールを作成することもできます。新しいプールで作成されるクラスターは、新しい認証情報で提供される設定を使用します。
1.7.16.3. クラスタープールリリースイメージの更新
クラスタープールのクラスターが一定期間、休止状態のままになると、クラスターの Red Hat OpenShift Container Platform リリースイメージがバックレベルになる可能性があります。このような場合は、クラスタープールにあるクラスターのリリースイメージのバージョンをアップグレードしてください。
必要なアクセス: 編集
クラスタープールにあるクラスターの OpenShift Container Platform リリースイメージを更新するには、以下の手順を実行します。
注記: この手順では、クラスタープールですでに要求されているクラスタープールからクラスターを更新しません。この手順を完了すると、リリースイメージの更新は、クラスタープールに関連する次のクラスターにのみ適用されます。
- この手順でリリースイメージを更新した後にクラスタープールによって作成されたクラスター。
- クラスタープールで休止状態になっているクラスター。古いリリースイメージを持つ既存の休止状態のクラスターは破棄され、新しいリリースイメージを持つ新しいクラスターがそれらを置き換えます。
- ナビゲーションメニューから Infrastructure > Clusters をクリックします。
- Cluster pools タブを選択します。
- クラスタープール の表で、更新するクラスタープールの名前を見つけます。
- 表の Cluster pools の Options メニューをクリックし、Update release image を選択します。
- このクラスタープールから今後、クラスターの作成に使用する新規リリースイメージを選択します。
クラスタープールのリリースイメージが更新されました。
ヒント: アクション 1 つで複数のクラスターのリリースイメージを更新するには、各クラスタープールのボックスを選択して Actions メニューを使用し、選択したクラスタープールのリリースイメージを更新します。
1.7.16.4. Scaling cluster pools (Technology Preview)
クラスタープールのクラスター数は、クラスタープールサイズのクラスター数を増やしたり、減らしたりして変更できます。
必要なアクセス権限: クラスターの管理者
クラスタープールのクラスター数を変更するには、以下の手順を実行します。
- ナビゲーションメニューから Infrastructure > Clusters をクリックします。
- Cluster pools タブを選択します。
- 変更するクラスタープールの Options メニューで、Scale cluster pool を選択します。
- プールサイズの値を変更します。
- オプションで、実行中のクラスターの数を更新して、要求時にすぐに利用可能なクラスター数を増減できます。
クラスタープールは、新しい値を反映するようにスケーリングされます。
1.7.16.5. クラスタープールの破棄
クラスタープールを作成し、不要になった場合は、そのクラスタープールを破棄できます。
重要: クラスター要求がないクラスタープールのみ破棄できます。
必要なアクセス権限: クラスターの管理者
クラスタープールを破棄するには、以下の手順を実行します。
- ナビゲーションメニューから Infrastructure > Clusters をクリックします。
- Cluster pools タブを選択します。
削除するクラスタープールの Options メニューで、確認ボックスに
confirmと入力して Destroy を選択します。注記:
- クラスタープールにクラスター要求がある場合、Destroy ボタンは無効になります。
- クラスタープールを含む namespace は削除されません。namespace を削除すると、これらのクラスターのクラスター要求リソースが同じ namespace で作成されるため、クラスタープールから要求されたクラスターが破棄されます。
ヒント: アクション 1 つで複数のクラスタープールを破棄するには、各クラスタープールのボックスを選択して Actions メニューを使用し、選択したクラスタープールを破棄します。
1.7.17. ManagedServiceAccount アドオンの有効化
サポートされているバージョンの multicluster engine Operator をインストールすると、ManagedServiceAccount アドオンがデフォルトで有効になります。
ManagedServiceAccount を使用すると、マネージドクラスターでサービスアカウントを作成または削除できます。
必要なアクセス権限: 編集
ManagedServiceAccount カスタムリソースがハブクラスターの <managed_cluster> namespace に作成されると、ServiceAccount がマネージドクラスターに作成されます。
TokenRequest は、マネージドクラスターの ServiceAccount を使用して、マネージドクラスターの Kubernetes API サーバーに対して行われます。トークンは、ハブクラスターの <target_managed_cluster> namespace の Secret に保存されます。
注記 トークンは期限切れになり、ローテーションされる可能性があります。トークンリクエストの詳細は、TokenRequest を参照してください。
1.7.17.1. 前提条件
- サポートされている Red Hat OpenShift Container Platform 環境がある。
- multicluster engine Operator がインストールされている。
1.7.17.2. ManagedServiceAccount の有効化
ハブクラスターとマネージドクラスターの ManagedServiceAccount アドオンを有効にするには、次の手順を実行します。
-
ハブクラスターで
ManagedServiceAccountアドオンを有効にします。詳細は、詳細設定 を参照してください。 ManagedServiceAccountアドオンをデプロイし、それをターゲットのマネージドクラスターに適用します。次の YAML ファイルを作成し、target_managed_clusterをManaged-ServiceAccountアドオンを適用するマネージドクラスターの名前に置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ファイルを適用します。
oc apply -f -
oc apply -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow これで、マネージドクラスターの
ManagedServiceAccountプラグインが有効になりました。ManagedServiceAccountを設定するには、次の手順を参照してください。次の YAML ソースを使用して
ManagedServiceAccountカスタムリソースを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
managed_serviceaccount_nameをManagedServiceAccountの名前に置き換えます。 -
target_managed_clusterを、ManagedServiceAccountを適用するマネージドクラスターの名前に置き換えます。
-
確認するには、
ManagedServiceAccountオブジェクトのステータスでtokenSecretRef属性を表示して、シークレット名と namespace を見つけます。アカウントとクラスター名を使用して次のコマンドを実行します。oc get managedserviceaccount <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
oc get managedserviceaccount <managed_serviceaccount_name> -n <target_managed_cluster> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターで作成された
ServiceAccountに接続されている取得されたトークンを含むSecretを表示します。以下のコマンドを実行します。oc get secret <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
oc get secret <managed_serviceaccount_name> -n <target_managed_cluster> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.18. クラスターのライフサイクルの詳細設定
一部のクラスター設定は、インストール中またはインストール後に設定できます。
1.7.18.1. API サーバー証明書のカスタマイズ
マネージドクラスターは、OpenShift Kube API サーバーの外部ロードバランサーとの相互接続を介してハブクラスターと通信します。デフォルトの OpenShift Kube API サーバー証明書は、OpenShift Container Platform のインストール時に内部 Red Hat OpenShift Container Platform クラスター認証局 (CA) によって発行されます。必要に応じて、証明書を追加または変更できます。
API サーバー証明書を変更すると、マネージドクラスターとハブクラスター間の通信に影響を与える可能性があります。製品をインストールする前に名前付き証明書を追加すると、マネージドクラスターがオフライン状態になる可能性がある問題を回避できます。
次のリストには、証明書の更新が必要となる場合の例がいくつか含まれています。
外部ロードバランサーのデフォルトの API サーバー証明書を独自の証明書に置き換える必要がある。OpenShift Container Platform ドキュメントの API サーバー証明書の追加 のガイダンスに従い、ホスト名
api.<cluster_name>.<base_domain>の名前付き証明書を追加して、外部ロードバランサーのデフォルトの API サーバー証明書を置き換えることができます。証明書を置き換えると、マネージドクラスターの一部がオフライン状態に移行する可能性があります。証明書のアップグレード後にクラスターがオフライン状態になった場合は、Troubleshooting imported clusters offline after certificate change のトラブルシューティング手順に従って問題を解決してください。注記: 製品をインストールする前に名前付き証明書を追加すると、クラスターがオフライン状態に移行するのを回避できます。
外部ロードバランサーの名前付き証明書の有効期限が切れているため、証明書を置き換える必要がある。中間証明書の数に関係なく、古い証明書と新しい証明書の両方が同じルート CA 証明書を共有する場合は、OpenShift Container Platform ドキュメントの API サーバー証明書の追加 のガイダンスに従って、新しい証明書の新しいシークレットを作成できます。次に、ホスト名
api.<cluster_name>.<base_domain>のサービス証明書参照をAPIServerカスタムリソース内の新しいシークレットに更新します。それ以外の場合、古い証明書と新しい証明書に異なるルート CA 証明書がある場合は、次の手順を実行して証明書を置き換えます。次の例のような
APIServerカスタムリソースを見つけます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、既存の証明書と新しい証明書の内容を含む新しいシークレットを
openshift-confignamespace に作成します。古い証明書を新しい証明書にコピーします。
cp old.crt combined.crt
cp old.crt combined.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しい証明書の内容を古い証明書のコピーに追加します。
cat new.crt >> combined.crt
cat new.crt >> combined.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 結合した証明書を適用してシークレットを作成します。
oc create secret tls combined-certs-secret --cert=combined.crt --key=old.key -n openshift-config
oc create secret tls combined-certs-secret --cert=combined.crt --key=old.key -n openshift-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
APIServerリソースを更新して、結合された証明書をservingCertificateとして参照します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 約 15 分後、新しい証明書と古い証明書の両方を含む CA バンドルがマネージドクラスターに伝播されます。
次のコマンドを入力して、新しい証明書情報のみを含む
new-cert-secretという名前の別のシークレットをopenshift-confignamespace に作成します。oc create secret tls new-cert-secret --cert=new.crt --key=new.key -n openshift-config {code}oc create secret tls new-cert-secret --cert=new.crt --key=new.key -n openshift-config {code}Copy to Clipboard Copied! Toggle word wrap Toggle overflow new-cert-secretを参照するようにservingCertificateの名前を変更して、APIServerリソースを更新します。リソースは以下の例のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 約 15 分後、古い証明書が CA バンドルから削除され、変更がマネージドクラスターに自動的に伝播されます。
注記: マネージドクラスターは、ホスト名 api.<cluster_name>.<base_domain> を使用してハブクラスターにアクセスする必要があります。他のホスト名で設定された名前付き証明書は使用できません。
1.7.18.2. ハブクラスターとマネージドクラスター間のプロキシーの設定
マネージドクラスターを multicluster engine for Kubernetes Operator に登録するには、マネージドクラスターを multicluster engine Operator ハブクラスターに転送する必要があります。場合によっては、マネージドクラスターが multicluster engine Operator ハブクラスターに直接アクセスできないことがあります。この例では、マネージドクラスターからの通信が HTTP または HTTPS プロキシーサーバー経由で multicluster engine Operator ハブクラスターにアクセスできるようにプロキシー設定を指定します。
たとえば、multicluster engine Operator ハブクラスターはパブリッククラウドにあり、マネージドクラスターはファイアウォールの背後にあるプライベートクラウド環境にあります。プライベートクラウドからの通信は、HTTP または HTTPS プロキシーサーバーのみを経由できます。
1.7.18.2.1. 前提条件
- HTTP トンネルをサポートする HTTP または HTTPS プロキシーサーバーが実行されている。(例: HTTP connect メソッド)
- HTTP または HTTPS プロキシーサーバーに到達できるマネージドクラスターがあり、プロキシーサーバーが multicluster engine Operator ハブクラスターにアクセスできる。
ハブクラスターとマネージドクラスターとの間でプロキシー設定を指定するには、以下の手順を実行します。
プロキシー設定を使用して
KlusterConfigリソースを作成します。以下の HTTP プロキシー設定を参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の HTTPS プロキシー設定を参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: HTTPS プロキシーには CA バンドルが必要です。CA バンドルとは、1 つまたは複数の CA 証明書を含む ConfigMap を指します。この ConfigMap は次のコマンドを実行すると作成できます。
oc create -n <configmap-namespace> configmap <configmap-name> --from-file=ca.crt=/path/to/ca/file
oc create -n <configmap-namespace> configmap <configmap-name> --from-file=ca.crt=/path/to/ca/fileCopy to Clipboard Copied! Toggle word wrap Toggle overflow
マネージドクラスターの作成時に、
KlusterletConfigリソースを参照するアノテーションを追加して、KlusterletConfigリソースを選択します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記:
-
multicluster engine Operator コンソールで操作する場合、YAML ビューを切り替えて、
ManagedClusterリソースにアノテーションを追加することが必要になる場合があります。 -
グローバルの
KlusterletConfigを使用して、バインドにアノテーションを使用せずにすべてのマネージドクラスターで設定を有効化できます。
-
multicluster engine Operator コンソールで操作する場合、YAML ビューを切り替えて、
1.7.18.2.2. ハブクラスターとマネージドクラスター間のプロキシーの無効化
開発が変更された場合は、HTTP または HTTPS プロキシーを無効にする必要がある場合があります。
-
ManagedClusterリソースに移動します。 -
agent.open-cluster-management.io/klusterlet-configアノテーションを削除します。
1.7.18.2.3. オプション: 特定のノードで実行するように klusterlet を設定する
Red Hat Advanced Cluster Management for Kubernetes を使用してクラスターを作成する場合、マネージドクラスターの nodeSelector および tolerations アノテーションを設定することで、マネージドクラスター klusterlet を実行するノードを指定できます。これらを設定するには、次の手順を実行します。
- コンソールのクラスターページから、更新するマネージドクラスターを選択します。
YAML コンテンツを表示するには、YAML スイッチを
Onに設定します。注記: YAML エディターは、クラスターをインポートまたは作成するときにのみ使用できます。インポートまたは作成後にマネージドクラスターの YAML 定義を編集するには、OpenShift Container Platform コマンドラインインターフェイスまたは Red Hat Advanced Cluster Management 検索機能を使用する必要があります。
-
nodeSelectorアノテーションをマネージドクラスターの YAML 定義に追加します。このアノテーションのキーは、open-cluster-management/nodeSelectorです。このアノテーションの値は、JSON 形式の文字列マップです。 tolerationsエントリーをマネージドクラスターの YAML 定義に追加します。このアノテーションのキーは、open-cluster-management/tolerationsです。このアノテーションの値は、JSON 形式の toleration リストを表します。結果の YAML は次の例のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - コンテンツを正しいノードにデプロイできるように、klusterlet アドオンの設定 を参照します。
1.7.18.3. マネージドクラスターをインポートする際のハブクラスター API サーバーのサーバー URL と CA バンドルのカスタマイズ (テクノロジープレビュー)
マネージドクラスターとハブクラスターの間に中間コンポーネントが存在する場合、multicluster engine Operator ハブクラスターにマネージドクラスターを登録できない可能性があります。中間コンポーネントの例には、仮想 IP、ロードバランサー、リバースプロキシー、API ゲートウェイなどがあります。中間コンポーネントがある場合は、マネージドクラスターをインポートするときに、ハブクラスター API サーバーのカスタムサーバー URL と CA バンドルを使用する必要があります。
1.7.18.3.1. 前提条件
- マネージドクラスターからハブクラスター API サーバーにアクセスできるように、中間コンポーネントを設定する必要があります。
中間コンポーネントがマネージドクラスターとハブクラスター API サーバー間の SSL 接続を終端する場合は、SSL 接続をブリッジし、元のリクエストからの認証情報をハブクラスター API サーバーのバックエンドに渡す必要があります。Kubernetes API サーバーのユーザー偽装機能を使用すると、SSL 接続をブリッジできます。
中間コンポーネントは、元のリクエストからクライアント証明書を抽出し、証明書サブジェクトのコモンネーム (CN) と組織 (O) を偽装ヘッダーとして追加し、変更された偽装リクエストをハブクラスター API サーバーのバックエンドに転送します。
注記: SSL 接続をブリッジすると、クラスタープロキシーアドオンが機能しなくなります。
1.7.18.3.2. サーバー URL とハブクラスター CA バンドルのカスタマイズ
マネージドクラスターをインポートするときにカスタムハブ API サーバー URL と CA バンドルを使用するには、次の手順を実行します。
カスタムのハブクラスター API サーバー URL と CA バンドルを使用して
KlusterConfigリソースを作成します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- klusterlet 設定名を追加します。
- 2
- カスタムサーバー URL を追加します。
- 3
- カスタム CA バンドル名を追加します。内部使用のために予約されている
auto-detected以外の任意の値を使用できます。 - 4
- CA バンドル ConfigMap の名前を追加します。ConfigMap を作成するには、コマンド
oc create -n <configmap-namespace> configmap <configmap-name> --from-file=ca.crt=/path/to/ca/fileを実行します。 - 5
- CA バンドル ConfigMap の namespace を追加します。
マネージドクラスターを作成するときに、リソースを参照するアノテーションを追加して
KlusterletConfigリソースを選択します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記:
-
コンソールを使用する場合は、
ManagedClusterリソースにアノテーションを追加するために、YAML ビューを有効にする必要がある場合があります。 -
グローバルの
KlusterletConfigを使用して、バインドにアノテーションを使用せずにすべてのマネージドクラスターで設定を有効化できます。
-
コンソールを使用する場合は、
1.7.18.3.3. グローバル KlusterletConfig の設定
KlusterletConfig リソースを作成し、名前を global に設定すると、グローバル KlusterletConfig 内の設定が全マネージドクラスターに自動的に適用されます。
グローバルの KlusterletConfig がある環境では、agent.open-cluster-management.io/klusterlet-config: <klusterletconfig-name> アノテーションを ManagedCluster リソースに追加することで、クラスター固有の KlusterletConfig を作成し、それをマネージドクラスターにバインドすることもできます。同じフィールドに異なる値を設定した場合、クラスター固有の KlusterletConfig の値によってグローバルの KlusterletConfig の値がオーバーライドされます。
次の例では、hubKubeAPIServerURL フィールドに、KlusterletConfig とグローバル KlusterletConfig で異なる値が設定されています。"https://api.example.test.com:6443" 値によって "https://api.example.global.com:6443" 値がオーバーライドされます。
非推奨: hubKubeAPIServerURL フィールドは非推奨です。
マネージドクラスターにバインドされたクラスター固有の KlusterletConfig がない場合、またはクラスター固有の KlusterletConfig に同じフィールドが存在しないか値がない場合には、グローバル KlusterletConfig の値が使用されます。
次の例を参照してください。ここでは、グローバル KlusterletConfig の hubKubeAPIServerURL フィールドの "example.global.com" 値が KlusterletConfig をオーバーライドします。
次の例を参照してください。ここでは、グローバル KlusterletConfig の hubKubeAPIServerURL フィールドの "example.global.com" 値が KlusterletConfig をオーバーライドします。
1.7.18.4. ハブクラスターの KubeAPIServer 検証ストラテジーの設定
マネージドクラスターは、OpenShift Container Platform KubeAPIServer の外部ロードバランサーとの相互接続を介してハブクラスターと通信します。OpenShift Container Platform をインストールすると、内部の OpenShift Container Platform クラスター認証局 (CA) がデフォルトの OpenShift Container Platform KubeAPIServer 証明書を発行します。multicluster engine for Kubernetes Operator は、証明書を自動的に検出して bootstrap-kubeconfig-secret namespace 内のマネージドクラスターに追加します。
自動的に検出された証明書が機能しない場合は、KlusterletConfig リソースでストラテジー設定を手動で設定できます。ストラテジーを手動で設定すると、ハブクラスターの KubeAPIServer 証明書の検証方法を制御できます。
ストラテジーを手動で設定する方法は、次の 3 つのストラテジーのいずれかの例を参照してください。
1.7.18.4.1. UseAutoDetectedCABundle を使用したストラテジーの設定
デフォルトの設定ストラテジーは UseAutoDetectedCABundle です。multicluster engine Operator は、ハブクラスター上の証明書を自動的に検出し、trustedCABundles リストの config map 参照に設定されている証明書を実際の CA バンドル (存在する場合) にマージします。
次の例では、ハブクラスターから自動的に検出された証明書と、new-ocp-ca config map で設定した証明書をマージし、両方をマネージドクラスターに追加します。
1.7.18.4.2. UseSystemTruststore を使用したストラテジーの設定
UseSystemTruststore を使用すると、multicluster engine Operator は証明書を検出せず、trustedCABundles パラメーターセクションで設定された証明書を無視します。この設定では、マネージドクラスターに証明書は渡されません。代わりに、マネージドクラスターは、マネージドクラスターのシステムトラストストアからの証明書を使用して、ハブクラスター API サーバーを検証します。これは、Let’s Encrypt などのパブリック CA がハブクラスター証明書を発行する場合に該当します。UseSystemTruststore を使用する次の例を参照してください。
1.7.18.4.3. UseCustomCABundles を使用したストラテジーの設定
ハブクラスター API サーバーの CA がわかっていて、multicluster engine Operator にそれを自動的に検出させない場合は、UseCustomCABundles を使用できます。このストラテジーでは、multicluster engine Operator が、設定された証明書を trustedCABundles パラメーターからマネージドクラスターに追加します。UseCustomCABundles の使用方法は、次の例を参照してください。
通常、このポリシーは各マネージドクラスターで同じです。ハブクラスター管理者は、multicluster engine Operator をインストールするとき、またはハブクラスター証明書が変更されたときに、global という名前の KlusterletConfig を設定して、各マネージドクラスターのポリシーをアクティブ化できます。以下の例を参照してください。
マネージドクラスターで別のストラテジーを使用する必要がある場合は、別の KlusterletConfig を作成し、マネージドクラスターで agent.open-cluster-management.io/klusterlet-config アノテーションを使用して特定のストラテジーを指定することもできます。以下の例を参照してください。
1.7.18.5. 関連情報
1.7.19. 管理からのクラスターの削除
multicluster engine Operator で作成された OpenShift Container Platform クラスターを管理から削除する場合は、クラスターを デタッチ または 破棄 することができます。クラスターをデタッチするとマネージメントから削除されますが、完全には削除されません。管理する場合には、もう一度インポートし直すことができます。このオプションは、クラスターが Ready 状態にある場合にだけ利用できます。
次の手順により、次のいずれかの状況でクラスターが管理から削除されます。
- すでにクラスターを削除しており、削除したクラスターを Red Hat Advanced Cluster Management から削除したいと考えています。
- クラスターを管理から削除したいが、クラスターを削除していない。
重要:
- クラスターを破棄すると、マネージメントから削除され、クラスターのコンポーネントが削除されます。
マネージドクラスターを接続解除または破棄すると、関連する namespace が自動的に削除されます。この namespace にカスタムリソースを配置しないでください。
1.7.19.1. コンソールを使用したクラスターの削除
ナビゲーションメニューから、Infrastructure > Clusters に移動し、管理から削除するクラスターの横にあるオプションメニューから Destroy cluster または Detach cluster を選択します。
ヒント: 複数のクラスターをデタッチまたは破棄するには、デタッチまたは破棄するクラスターのチェックボックスを選択して、Detach または Destroy を選択します。
重要: <your-local-cluster-name> という名前のハブクラスターをデタッチしようとする場合、disableHubSelfManagement のデフォルト設定は false であり、ハブクラスターは自己管理する local-cluster であることに注意してください。この設定が原因で、ハブクラスターはデタッチされると、自身を再インポートして管理し、MultiClusterHub コントローラーがリコンサイルされます。ハブクラスターがデタッチプロセスを完了して再インポートするのに時間がかかる場合があります。
プロセスが終了するのを待たずにハブクラスターを再インポートするには、以下のコマンドを実行して multiclusterhub-operator Pod を再起動して、再インポートの時間を短縮できます。
oc -n open-cluster-management delete -l name=multiclusterhub-operator pods
oc -n open-cluster-management delete -l name=multiclusterhub-operator pods
ネットワーク接続時のオンラインインストール で説明されているように、disableHubSelfManagement の値を true に変更して、自動的にインポートされないようにハブクラスターの値を変更できます。
1.7.19.2. コマンドラインを使用したクラスターの削除
ハブクラスターのコマンドラインを使用してマネージドクラスターをデタッチするには、以下のコマンドを実行します。
oc delete managedcluster $CLUSTER_NAME
oc delete managedcluster $CLUSTER_NAME切断後にマネージドクラスターを破棄するには、次のコマンドを実行します。
oc delete clusterdeployment <CLUSTER_NAME> -n $CLUSTER_NAME
oc delete clusterdeployment <CLUSTER_NAME> -n $CLUSTER_NAME注記:
-
マネージドクラスターの破壊を防ぐには、
ClusterDeploymentカスタムリソースでspec.preserveOnDeleteパラメーターをtrueに設定します。 disableHubSelfManagementのデフォルト設定はfalseです。falseに設定すると、ハブクラスター (local-cluster)は、デタッチされたときに自身を再インポートして管理し、MultiClusterHubコントローラーをリコンサイルします。切り離しと再インポートのプロセスには数時間かかる場合があり、ハブクラスターが完了するまでに数時間かかる場合があります。プロセスが終了するのを待たずにハブクラスターを再インポートする場合は、以下のコマンドを実行して
multiclusterhub-operatorPod を再起動して、再インポートの時間を短縮できます。oc -n open-cluster-management delete -l name=multiclusterhub-operator pods
oc -n open-cluster-management delete -l name=multiclusterhub-operator podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow disableHubSelfManagementの値をtrueに指定して、自動的にインポートされないように、ハブクラスターの値を変更できます。ネットワーク接続時のオンラインインストール を参照してください。
1.7.19.3. クラスター削除後の残りのリソースの削除
削除したマネージドクラスターにリソースが残っている場合は、残りのすべてのコンポーネントを削除するための追加の手順が必要になります。これらの追加手順が必要な場合には、以下の例が含まれます。
-
マネージドクラスターは、完全に作成される前にデタッチされ、
klusterletなどのコンポーネントはマネージドクラスターに残ります。 - マネージドクラスターをデタッチする前に、クラスターを管理していたハブが失われたり、破棄されているため、ハブからマネージドクラスターをデタッチする方法はありません。
- マネージドクラスターは、デタッチ時にオンライン状態ではありませんでした。
これらの状況の 1 つがマネージドクラスターのデタッチの試行に該当する場合は、マネージドクラスターから削除できないリソースがいくつかあります。マネージドクラスターをデタッチするには、以下の手順を実行します。
-
ocコマンドラインインターフェイスが設定されていることを確認してください。 また、マネージドクラスターに
KUBECONFIGが設定されていることを確認してください。oc get ns | grep open-cluster-management-agentを実行すると、2 つの namespace が表示されるはずです。open-cluster-management-agent Active 10m open-cluster-management-agent-addon Active 10m
open-cluster-management-agent Active 10m open-cluster-management-agent-addon Active 10mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、
klusterletカスタムリソースを削除します。oc get klusterlet | grep klusterlet | awk '{print $1}' | xargs oc patch klusterlet --type=merge -p '{"metadata":{"finalizers": []}}'oc get klusterlet | grep klusterlet | awk '{print $1}' | xargs oc patch klusterlet --type=merge -p '{"metadata":{"finalizers": []}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、残りのリソースを削除します。
oc delete namespaces open-cluster-management-agent open-cluster-management-agent-addon --wait=false oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc delete crds --wait=false oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc patch crds --type=merge -p '{"metadata":{"finalizers": []}}'oc delete namespaces open-cluster-management-agent open-cluster-management-agent-addon --wait=false oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc delete crds --wait=false oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc patch crds --type=merge -p '{"metadata":{"finalizers": []}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、namespaces と開いているすべてのクラスター管理
crdsの両方が削除されていることを確認します。oc get crds | grep open-cluster-management.io | awk '{print $1}' oc get ns | grep open-cluster-management-agentoc get crds | grep open-cluster-management.io | awk '{print $1}' oc get ns | grep open-cluster-management-agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7.19.4. クラスターの削除後の etcd データベースのデフラグ
マネージドクラスターが多数ある場合は、ハブクラスターの etcd データベースのサイズに影響を与える可能性があります。OpenShift Container Platform 4.8 では、マネージドクラスターを削除すると、ハブクラスターの etcd データベースのサイズは自動的に縮小されません。シナリオによっては、etcd データベースは領域不足になる可能性があります。etcdserver: mvcc: database space exceeded のエラーが表示されます。このエラーを修正するには、データベース履歴を圧縮し、etcd データベースのデフラグを実行して etcd データベースのサイズを縮小します。
注記: OpenShift Container Platform バージョン 4.9 以降では、etcd Operator はディスクを自動的にデフラグし、etcd 履歴を圧縮します。手動による介入は必要ありません。以下の手順は、OpenShift Container Platform 4.8 以前のバージョン向けです。
以下の手順を実行して、ハブクラスターで etcd 履歴を圧縮し、ハブクラスターで etcd データベースをデフラグします。
1.7.19.4.1. 前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
1.7.19.4.2. 手順
etcd履歴を圧縮します。次に、
etcdメンバーへのリモートシェルセッションを開きます。oc rsh -n openshift-etcd etcd-control-plane-0.example.com etcdctl endpoint status --cluster -w table
$ oc rsh -n openshift-etcd etcd-control-plane-0.example.com etcdctl endpoint status --cluster -w tableCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
etcd履歴を圧縮します。sh-4.4#etcdctl compact $(etcdctl endpoint status --write-out="json" | egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*' -m1)
sh-4.4#etcdctl compact $(etcdctl endpoint status --write-out="json" | egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*' -m1)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
compacted revision 158774421
$ compacted revision 158774421Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
etcdデータのデフラグの説明 に従って、etcdデータベースをデフラグし、NOSPACEアラームをクリアします。
1.8. Discovery サービス
OpenShift Cluster Manager から利用可能な OpenShift Container Platform クラスターを検出できます。検出後に、クラスターをインポートして管理できます。Discovery サービスは、バックエンドおよびコンソールでの用途に Discover Operator を使用します。
OpenShift Cluster Manager 認証情報が必要になります。認証情報を作成する必要がある場合は、OpenShift Cluster Manager の認証情報の作成 を参照してください。
必要なアクセス権限: 管理者
1.8.1. サービスアカウントの認証
OpenShift Cluster Manager から利用可能な OpenShift Container Platform クラスターを検出するには、サービスアカウントで認証する必要があります。OpenShift Cluster Manager オフライントークンは非推奨であることに注意してください。
前提条件
- OpenShift Cluster Manager 認証情報が必要になります。認証情報を作成する必要がある場合は、OpenShift Cluster Manager の認証情報の作成 を参照してください。
- OpenShift Cluster Manager サービスアカウントの作成については、サービスアカウント を参照してください。
1.8.1.1. 認証
サービスアカウントで認証するには、次の手順を参照してください。
-
multicluster engine Operator コンソールで、サービスアカウントの
クライアント IDとクライアントシークレットのペアとして新しい認証情報シークレットを作成します。 -
multicluster engine Operator Discovery サービスが正しく認証を行い、クラスターを検出できるように、サービスアカウントの
クライアント IDとクライアントシークレットのペアを指定します。 -
マネージドクラスターとしてインポートするために、Red Hat OpenShift Service on AWS
DiscoveredClusterリソースを設定します。開始される Red Hat OpenShift Service on AWS インポートフローは、サービスアカウントの認証情報を使用してクラスターを認証およびインポートします。
| ロール | アクセス権限 |
|---|---|
| OpenShift Cluster Manager cluster autoscaler editor | クラスターオートスケーラーで更新操作を実行します。 |
| OpenShift Cluster Manager cluster editor | クラスターに対して更新操作を実行します。 |
| OpenShift Cluster Manager cluster provisioner | クラスターに対してプロビジョニング操作を実行します。 |
| OpenShift Cluster Manager cluster viewer | クラスターで読み取り操作を実行します。 |
| OpenShift Cluster Manager IdP editor | IdP で更新操作を実行します。 |
| OpenShift Cluster Manager machine pool editor | マシンプールに対して更新操作を実行します。 |
| OpenShift Cluster Manager organization administrator | 関連する組織のクラスターで利用可能なすべての操作を実行します。 |
| Subscriptions viewer | Subscriptions リソースで読み取り操作を実行します。 |
1.8.2. コンソールでの Discovery の設定
コンソールで Discovery を設定してクラスターを検索します。クラスターで Discovery 機能を設定する場合、組織内のクラスターの検出を開始するために、DiscoveryConfig リソースを有効にして OpenShift Cluster Manager に接続する必要があります。個別の認証情報を使用して複数の DiscoveryConfig リソースを作成できます。
クラスターの検出後に、コンソールの Discovered clusters に表示されるクラスターをインポートできます。製品のコンソールを使用して検出を有効にします。
必要なアクセス権: 認証情報が作成された namespace へのアクセス権。
前提条件
- 認証情報が必要です。OpenShift Cluster Manager に接続するには、OpenShift Cluster Manager の認証情報の作成 を参照してください。
- 検出の設定に使用した namespace へのアクセス権が必要である。
1.8.2.1. 検出されたクラスターのコンソールからのインポート
他のインフラストラクチャープロバイダーによって検出されたクラスターを手動でインポートするには、次の手順を実行します。
- 既存の Clusters ページに移動し、Discovered clusters タブをクリックします。
- Discovered clusters の表から、インポートするクラスターを見つけます。
- オプションメニューから Import cluster を選択します。
- 検出クラスターの場合は、このドキュメントを使用して手動でインポートしたり、Import cluster を自動的に選択したりできます。
- 認証情報または Kubeconfig ファイルを使用して自動でインポートするには、コンテンツをコピーして貼り付けます。
- Import をクリックします。
1.8.2.2. 検出されたクラスターの表示
認証情報を設定してインポートするクラスターを検出した後に、コンソールで表示できます。
- Clusters > Discovered clusters の順にクリックします。
以下の情報が投入された表を確認してください。
- name は、OpenShift Cluster Manager で指定された表示名です。クラスターに表示名がない場合は、クラスターコンソール URL をもとに生成された名前が表示されます。OpenShift Cluster Manager でコンソール URL がない場合や手動で変更された場合には、クラスターの外部 ID が表示されます。
- Namespace は、認証情報および検出クラスターを作成した namespace です。
- type は検出されたクラスターの Red Hat OpenShift タイプです。
- Distribution version は、検出されたクラスターの Red Hat OpenShift バージョンです。
- Infrastructure provider は検出されたクラスターのクラウドプロバイダーです。
- Last active は、検出されたクラスターが最後にアクティブであった時間です。
- Created は検出クラスターが作成された時間です。
- Discovered は検出クラスターが検出された時間です。
- Cluster types は、OpenShift Container Platform や Red Hat OpenShift Service on AWS などのクラスターのプラットフォームタイプです。
- インフラストラクチャープロバイダー は、Amazon Web Services (AWS) や Microsoft Azure など、クラスターが実行されている場所によってフィルタリングします。
- 表の中にある情報はどれでも検索できます。たとえば、特定の namespace で Discovered clusters のみを表示するには、その namespace を検索します。
- Import cluster をクリックすると、マネージドクラスターを作成できます。
1.8.3. CLI を使用した Discovery の有効化
CLI を使用して Discovery を有効にし、OpenShift Cluster Manager から利用可能なクラスターを見つけます。
必要なアクセス権限: 管理者
前提条件
- OpenShift Cluster Manager に接続するための認証情報を作成する。
1.8.3.1. 検出の設定とプロセス
注記: DiscoveryConfig は discovery という名前に指定し、選択した credential と同じ namespace に作成する必要があります。以下の DiscoveryConfig のサンプルを参照してください。
-
SECRET_NAMEは、以前に設定した認証情報に置き換えます。 -
NAMESPACE_NAMEはSECRET_NAMEの namespace に置き換えます。 -
クラスターの最後のアクティビティー (日数) からの最大時間を入力します。たとえば、
lastActive: 7では、過去 7 日間にアクティブなクラスターが検出されます。 -
検出する OpenShift Container Platform クラスターのバージョンを文字列のリスト形式で入力します。注記:
openshiftVersionsリストの各エントリーは、メジャーバージョンとマイナーバージョンを指定します。たとえば、4.xを指定すると、4.x.1、4.x.2などのすべてのエラータリリースが含まれます。
1.8.3.2. 検出されたクラスターの表示
検出されたクラスターを表示するには、oc get discoveredclusters -n <namespace> を実行して、namespace は検出認証情報が存在する namespace に置き換えます。
オブジェクトは Discovery コントローラーにより作成されます。このような DiscoveredClusters は、DiscoveryConfig discoveredclusters.discovery.open-cluster-management.io API で指定したフィルターと認証情報を使用して OpenShift Cluster Manager で検出されたクラスターを表します。name の値はクラスターの外部 ID です。
1.8.4. 検出されたクラスターを管理のために有効にする
Discovery-Operator を使用して、個々のクラスターを手動でインポートすることなく、サポートされているクラスターをハブクラスターに自動的にインポートし、クラスター管理を迅速化します。
必要なアクセス権: クラスター管理者
前提条件
- Discovery がデフォルトで有効になっている。デフォルト設定を変更した場合は、Discovery を有効にする。
- Red Hat OpenShift Service on AWS コマンドラインインターフェイスを設定する。Red Hat OpenShift Service on AWS CLI ドキュメントの開始方法 を参照してください。
1.8.4.1. 検出された Red Hat OpenShift Service on AWS および Hosted Control Plane クラスターを自動的にインポートする
次の手順は Discovery-Operator を使用して、検出された Red Hat OpenShift Service on AWS および Hosted Control Plane クラスターを自動的にインポートする方法の例です。コンソールまたはコマンドラインインターフェイスからインポートできます。
コンソールからインポートします。リソースを変更し、コンソールで
importAsManagedClusterフィールドをtrueに設定する必要があります。- コンソールからハブクラスターにログインします。
- ナビゲーションメニューから Search を選択します。
- 検索バーにクエリー "DiscoveredCluster" を入力します。
-
DiscoveredClusterリソースの結果が表示されます。 DiscoveredClusterリソースに移動し、importAsManagedClusterをtrueに設定します。次の例を参照してください。importAsManagedClusterはtrueに設定し、<4.x.z>はサポートされている OpenShift Container Platform のバージョンに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
DiscoveredClusterリソースがインポートされていることを確認するために、Clusters ページに移動します。Cluster list タブからクラスターのインポートステータスを確認します。 自動再インポートを防ぐために、Discovery のマネージドクラスターをデタッチする場合は、Detach cluster オプションを選択します。
Discovery-Operatorによって、アノテーションdiscovery.open-cluster-management.io/previously-auto-imported: 'true'が追加されます。DiscoveredClusterリソースは、次の YAML のようになります。apiVersion: discovery.open-cluster-management.io/v1 kind: DiscoveredCluster metadata: annotations: discovery.open-cluster-management.io/previously-auto-imported: 'true'apiVersion: discovery.open-cluster-management.io/v1 kind: DiscoveredCluster metadata: annotations: discovery.open-cluster-management.io/previously-auto-imported: 'true'Copy to Clipboard Copied! Toggle word wrap Toggle overflow DiscoveredClusterリソースが自動的に再インポートされないことを確認するために、Discovery-Operatorログで次のメッセージを確認します。"rosa-dc"は、検出されたクラスターです。2024-06-12T14:11:43.366Z INFO reconcile Skipped automatic import for DiscoveredCluster due to existing 'discovery.open-cluster-management.io/previously-auto-imported' annotation {"Name": "rosa-dc"}2024-06-12T14:11:43.366Z INFO reconcile Skipped automatic import for DiscoveredCluster due to existing 'discovery.open-cluster-management.io/previously-auto-imported' annotation {"Name": "rosa-dc"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
注記:
DiscoveredClusterリソースを自動的に再インポートする場合は、前述のアノテーションを削除する必要があります。コマンドラインインターフェイスからインポートします。
コマンドラインインターフェイスから
DiscoveredClusterリソースを自動的にインポートします。ログイン後、次のコマンドを使用して、importAsManagedClusterパラメーターをtrueに設定します。<name>と<namespace>は、実際の名前と namespace に置き換えます。oc patch discoveredcluster <name> -n <namespace> --type='json' -p='[{"op": "replace", "path": "/spec/importAsManagedCluster", "value": true}]'oc patch discoveredcluster <name> -n <namespace> --type='json' -p='[{"op": "replace", "path": "/spec/importAsManagedCluster", "value": true}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、クラスターがマネージドクラスターとしてインポートされたことを確認します。
oc get managedcluster <name>
oc get managedcluster <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Service on AWS クラスター ID の説明を取得するには、Red Hat OpenShift Service on AWS コマンドラインインターフェイスから次のコマンドを実行します。
rosa describe cluster --cluster=<cluster-name> | grep -o ^ID:.*
rosa describe cluster --cluster=<cluster-name> | grep -o ^ID:.*Copy to Clipboard Copied! Toggle word wrap Toggle overflow
重要: 他の Kubernetes プロバイダーの場合は、これらのインフラストラクチャープロバイダーの DiscoveredCluster リソースを手動でインポートする必要があります。Kubernetes 設定を、他のタイプの DiscoveredCluster リソースに直接適用してください。DiscoveredCluster リソースから importAsManagedCluster フィールドを有効にしても、Discovery Webhook が原因でリソースがインポートされません。
1.9. ホストインベントリーの概要
multicluster engine Operator の Central Infrastructure Management 機能を使用すると、ホストインベントリーの管理とオンプレミスクラスターのインストールを利用できます。
ホストインベントリーと Central Infrastructure Management の詳細は、以下を参照してください。
- ホストインベントリーの概要
- Central Infrastructure Management サービスの有効化
- Amazon Web Services での Central Infrastructure Management の有効化
- コンソールを使用したホストインベントリーの作成
- コマンドラインインターフェイスを使用したホストインベントリーの作成
- インフラストラクチャー環境用の高度なネットワークの設定
- Discovery Image を使用したホストのホストインベントリーへの追加
- ベアメタルホストのホストインベントリーへの自動追加
- ホストインベントリーの管理
- 各クラスターのミラーレジストリーの設定
- オンプレミス環境でのクラスターの作成
- Central Infrastructure Management を使用してオンプレミスの Red Hat OpenShift Container Platform クラスターを手動でインポートする
1.9.1. ホストインベントリーの概要
Central Infrastructure Management 機能は、ライフサイクル中のベアメタルホストの管理に重点を置いた、multicluster engine Operator の Red Hat OpenShift Container Platform インストール機能です。
Assisted Installer は、エージェントを使用してターゲットホストに事前インストールされた検証を実行し、中央サービスを使用してインストールの進行状況を評価および追跡する、OpenShift Container Platform のインストール方法です。
Red Hat OpenShift のインフラストラクチャー Operator は、Assisted Installer サービスを実行するワークロードを管理およびインストールする multicluster engine Operator コンポーネントです。
コンソールを使用してホストインベントリーを作成できます。これは、オンプレミスの OpenShift Container Platform クラスターの作成に使用できるベアメタルまたは仮想マシンのプールです。クラスターは、コントロールプレーン専用のマシンを備えたスタンドアロンクラスターにすることも、コントロールプレーンがハブクラスター上の Pod として実行される Hosted Control Plane にすることもできます。
スタンドアロンクラスターは、コンソール、API、またはゼロタッチプロビジョニング (ZTP) を使用する GitOps を使用してインストールできます。詳細は、Red Hat OpenShift Container Platform ドキュメントの 非接続環境での GitOps ZTP のインストール を参照してください。
マシンは、Discovery Image で起動した後、ホストインベントリーに参加します。Discovery Image は、以下を含む Red Hat CoreOS ライブイメージです。
- 検出、検証、およびインストールタスクを実行するエージェント。
- ハブクラスター上のサービスにアクセスするために必要な設定 (該当する場合、エンドポイント、トークン、静的ネットワーク設定など)。
Discovery Image は、インフラストラクチャー環境ごとに 1 つ用意します。インフラストラクチャー環境は、共通のプロパティーセットを共有するホストのセットです。InfraEnv カスタムリソース定義は、このインフラストラクチャー環境と関連する Discovery Image を表します。InfraEnv カスタムリソースの osImageVersion フィールドを設定することで、Discovery Image に使用する Red Hat Core OS バージョンを指定できます。値を指定しない場合は、最新の Red Hat Core OS バージョンが使用されます。
ホストが起動し、エージェントがサービスに接続すると、サービスはそのホストを表すハブクラスター上に新しい Agent カスタムリソースを作成します。Agent リソースはホストインベントリーを設定します。
後でホストを OpenShift ノードとしてインベントリーにインストールできます。エージェントは、必要な設定とともにオペレーティングシステムをディスクに書き込み、ホストを再起動します。
注記: Red Hat Advanced Cluster Management および Central Infrastructure Management は、Nutanix プラットフォームをサポートするために AgentClusterInstall リソースを使用します。ただし、これを使用するには、Nutanix 仮想マシンを作成することによる追加の設定が必要です。詳細は、Assisted Installer ドキュメントの オプション: Nutanix へのインストール を参照してください。
1.9.2. Central Infrastructure Management サービスの有効化
Central Infrastructure Management サービスは、multicluster engine Operator によって提供され、OpenShift Container Platform クラスターをデプロイします。Red Hat Advanced Cluster Management をインストールし、ハブクラスターで MultiClusterHub Operator を有効にすると、central infrastructure management サービスは自動的にデプロイされますが、この場合はサービスを手動で有効にする必要があります。
以下のセクションを参照してください。
1.9.2.1. 前提条件
Central Infrastructure Management サービスを有効にする前に、次の前提条件を確認してください。
- サポートされている OpenShift Container Platform バージョンと、サポートされている Red Hat Advanced Cluster Management for Kubernetes バージョンにハブクラスターがデプロイされている。
- ハブクラスターにはインターネットアクセスが必要です。
- 非接続環境で作業している場合は、環境を作成するために必要なイメージを取得するために、インターネットに接続された内部レジストリーまたはミラーレジストリーへの接続が必要です。
- ベアメタルプロビジョニングに必要なポートが開いている。OpenShift Container Platform ドキュメントの 必須ポートが開いていることを確認する を参照してください。
- ベアメタルホストのカスタムリソース定義がある。
- OpenShift Container Platform プルシークレット がある。詳細は、イメージプルシークレットの使用 を参照してください。
- 設定済みのデフォルトのストレージクラスがある。
- 非接続環境の場合のみ、OpenShift Container Platform ドキュメントの ネットワークファーエッジのクラスター に関する手順を完了する。
1.9.2.2. ベアメタルホストのカスタムリソース定義の作成
Central Infrastructure Management サービスを有効にする前に、ベアメタルホストのカスタムリソース定義が必要です。
次のコマンドを実行して、ベアメタルホストのカスタムリソース定義がすでに存在するかどうかを確認します。
oc get crd baremetalhosts.metal3.io
oc get crd baremetalhosts.metal3.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ベアメタルホストのカスタムリソース定義がある場合、出力にはリソースが作成された日付が表示されます。
- リソースがない場合は、次のようなエラーが表示されます。
Error from server (NotFound): customresourcedefinitions.apiextensions.k8s.io "baremetalhosts.metal3.io" not found
Error from server (NotFound): customresourcedefinitions.apiextensions.k8s.io "baremetalhosts.metal3.io" not foundCopy to Clipboard Copied! Toggle word wrap Toggle overflow ベアメタルホストのカスタムリソース定義がない場合は、metal3.io_baremetalhosts.yaml ファイルをダウンロードし、次のコマンドを実行することでコンテンツを適用して、リソースを作成します。
oc apply -f
oc apply -fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.9.2.3. Provisioning リソースの作成または変更
Central Infrastructure Management サービスを有効にする前に、Provisioning リソースが必要です。
次のコマンドを実行して、
Provisioningリソースがあるかどうかを確認します。oc get provisioning
oc get provisioningCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Provisioningリソースがすでにある場合は、Provisioningリソースを変更します。 -
Provisioningリソースがない場合は、No resources foundというエラーが表示されます。Provisioningリソースの作成を続行します。
-
Provisioningリソースを変更します。すでに
Provisioningリソースがある場合は、ハブクラスターが次のいずれかのプラットフォームにインストールされている場合、リソースを変更する必要があります。- ベアメタル
- Red Hat OpenStack Platform
- VMware vSphere
ユーザープロビジョニングインフラストラクチャー (UPI) 方式とプラットフォームは
Noneですハブクラスターが別のプラットフォームにインストールされている場合は、非接続環境での Central Infrastructure Management の有効化 または 接続環境での Central Infrastructure Management の有効化 に進みます。
provisioningリソースを変更し、以下のコマンドを実行してベアメタル Operator がすべての namespace を監視できるようにします。
oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Provisioningリソースがない場合は、Provisioning リソースを作成します。次の
Provisioningリソース YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 次のコマンドを実行してコンテンツを適用します。
oc apply -f
oc apply -fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.9.2.4. 非接続環境での Central Infrastructure Management の有効化
非接続環境で Central Infrastructure Management を有効にするには、以下の手順を実行します。
インフラストラクチャー Operator と同じ namespace に
ConfigMapを作成し、ミラーレジストリーのca-bundle.crtおよびregistries.confの値を指定します。ファイルのConfigMapは次の例のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: リリースイメージはダイジェストを使用して指定されるため、
mirror-by-digest-onlyをtrueに設定する必要があります。unqualified-search-registriesのリストにあるレジストリーは、PUBLIC_CONTAINER_REGISTRIES環境変数の認証無視リストに自動的に追加されます。マネージドクラスターのプルシークレットの検証時に、指定されたレジストリーは認証を必要としません。-
すべての
osImageリクエストで送信するヘッダーとクエリーパラメーターを表すキーペアを書き込みます。両方のパラメーターが必要ない場合は、ヘッダーのみ、またはクエリーパラメーターのみのキーペアを作成します。
重要: ヘッダーとクエリーパラメーターは、HTTPS を使用する場合にのみ暗号化されます。セキュリティーの問題を避けるために、必ず HTTPS を使用してください。
headersという名前のファイルを作成し、次の例のような内容を追加します。{ "Authorization": "Basic xyz" }{ "Authorization": "Basic xyz" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow query_paramsという名前のファイルを作成し、次の例のような内容を追加します。{ "api_key": "myexampleapikey", }{ "api_key": "myexampleapikey", }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、作成したパラメーターファイルからシークレットを作成します。パラメーターファイルを 1 つだけ作成した場合は、作成しなかったファイルの引数を削除します。
oc create secret generic -n multicluster-engine os-images-http-auth --from-file=./query_params --from-file=./headers
oc create secret generic -n multicluster-engine os-images-http-auth --from-file=./query_params --from-file=./headersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 自己署名証明書またはサードパーティー CA 証明書とともに HTTPS
osImageを使用する場合は、証明書をimage-service-additional-caConfigMapに追加します。証明書を作成するには、次のコマンドを実行します。oc -n multicluster-engine create configmap image-service-additional-ca --from-file=<file-name>
oc -n multicluster-engine create configmap image-service-additional-ca --from-file=<file-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の YAML コンテンツを
agent_service_config.yamlファイルに保存して、AgentServiceConfigカスタムリソースを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1
mirror_configは、ミラーレジストリー設定の詳細が含まれるConfigMapの名前に置き換えます。- 2
- 認証を必要としないミラーレジストリーを使用している場合は、オプションの
unauthenticated_registryパラメーターを含めます。このリストのエントリーは検証されず、プルシークレットにエントリーを含める必要はありません。 - 3
img_volume_sizeは、imageStorageフィールドのボリュームのサイズに置き換えます。この値は、ベースの Red Hat Enterprise Linux CoreOS イメージを格納するために割り当てられるストレージの量を指定します。最小値は10Giですが、特にosImagesを使用して限定的に定義するのではなく、デフォルトのイメージセットを選択する場合は、ベストプラクティスとして値は少なくとも50Giを指定します。osImagesで設定されている Red Hat Enterprise Linux CoreOS の各インスタンスごとに、少なくとも2Giのイメージストレージを許可する必要があります。- 4
ocp_versionは、インストールするサポートされている OpenShift Container Platform バージョンに置き換えます。- 5
ocp_release_versionは、特定のインストールバージョン (例:49.83.2021032516400) に置き換えます。- 6
iso_urlを ISO の URL に置き換えます。ISO URL 値は rhoc で見つかります。
自己署名証明書またはサードパーティー CA 証明書を持つ HTTPS osImage を使用している場合は、OSImageCACertRef 仕様でその証明書を参照してください。
重要: 遅延バインディング機能を使用している場合は、クラスターの作成時に使用する OpenShift Container Platform リリースイメージが同じである必要があります。
assisted-service デプロイメントおよび assisted-image-service デプロイメントをチェックし、その Pod が準備ができており実行中であることを確認することで、Central Infrastructure Management サービスが正常であることを確認できます。
1.9.2.5. 接続環境での Central Infrastructure Management の有効化
接続環境で Central Infrastructure Management を有効にするには、以下の YAML コンテンツを agent_service_config.yaml ファイルに保存して、AgentServiceConfig カスタムリソースを作成します。
- 1
db_volume_sizeはdatabaseStorageフィールドのボリュームサイズに置き換えます (例:10Gi)。この値は、クラスターのデータベーステーブルやデータベースビューなどのファイルを格納するために割り当てられるストレージの量を指定します。必要な最小値は1Giです。クラスターが多い場合は、より高い値を使用する必要がある場合があります。- 2
fs_volume_sizeは、filesystemStorageフィールドのボリュームのサイズに置き換えます。たとえば、クラスターごとに200M、サポートされている OpenShift Container Platform バージョンごとに2 - 3Giなどです。必要な最小値は1Giですが、推奨される値は100Gi以上です。この値は、クラスターのログ、マニフェスト、およびkubeconfigファイルを保存するために割り当てられるストレージのサイズを指定します。クラスターが多い場合は、より高い値を使用する必要がある場合があります。- 3
img_volume_sizeは、imageStorageフィールドのボリュームのサイズに置き換えます。この値は、ベースの Red Hat Enterprise Linux CoreOS イメージを格納するために割り当てられるストレージの量を指定します。最小値は10Giですが、特にosImagesを使用して限定的に定義するのではなく、デフォルトのイメージセットを選択する場合は、ベストプラクティスとして値は少なくとも50Giを指定します。osImagesで設定されている Red Hat Enterprise Linux CoreOS の各インスタンスごとに、少なくとも2Giのイメージストレージを許可する必要があります。
osImages でカスタムイメージセットを定義する方法の詳細は 非接続環境での集中インフラストラクチャー管理の有効化 を参照してください。
Central Infrastructure Management サービスが設定されている。assisted-service と assisted-image-service デプロイメントをチェックして、Pod の準備ができ、実行されていることを確認して、正常性を検証できます。
1.9.2.6. Assisted Installer を使用して FIPS 対応クラスターをインストールする
FIPS モードのサポートされている OpenShift Container Platform クラスターをインストールする場合は、インストーラーに Red Hat Enterprise Linux バージョンを指定しないでください。
必要なアクセス: AgentServiceConfig および AgentClusterInstall リソースを編集するためのアクセス権が必要です。
1.9.2.6.1. バージョン 4.15 以前の OpenShift Container Platform クラスターをインストールする
If you install a {ocp-short} cluster version 4.15 and earlier, complete the following steps to update the `AgentServiceConfig` resource:
If you install a {ocp-short} cluster version 4.15 and earlier, complete the following steps to update the `AgentServiceConfig` resource:次のコマンドを使用して、マネージドクラスターにログインします。
oc login
oc loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow AgentServiceConfigリソースにagent-install.openshift.io/service-image-base: el8アノテーションを追加します。AgentServiceConfigリソースは、次の YAML のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.9.2.6.2. バージョン 4.16 以降の OpenShift Container Platform クラスターをインストールする
バージョン 4.16 以降の OpenShift Container Platform クラスターをインストールする場合は、次の手順を実行して AgentServiceConfig リソースを更新します。
次のコマンドを使用して、マネージドクラスターにログインします。
oc login
oc loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
AgentServiceConfigリソースにagent-install.openshift.io/service-image-base: el8アノテーションが存在する場合は、アノテーションを削除します。
1.9.2.7. 関連情報
- ゼロタッチプロビジョニングの詳細は、OpenShift Container Platform ドキュメントの ネットワークのファーエッジの課題 を参照してください。
- イメージプルシークレットの使用
1.9.3. Amazon Web Services での Central Infrastructure Management の有効化
Amazon Web Services でハブクラスターを実行していて、Central Infrastructure Management サービスを有効にする場合は、Central Infrastructure Management を Central Infrastructure Management の有効化 後に、次の手順を実行します。
ハブクラスターにログインしていることを確認し、次のコマンドを実行して、
assisted-image-serviceで設定された一意のドメインを見つけます。oc get routes --all-namespaces | grep assisted-image-service
oc get routes --all-namespaces | grep assisted-image-serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow ドメインは
assisted-image-service-multicluster-engine.apps.<yourdomain>.comのようになります。ハブクラスターにログインしていることを確認し、
NLBtypeパラメーターを使用して一意のドメインで新しいIngressControllerを作成します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
nlb-apps.<domain>.comの<domain>を<yourdomain>に置き換えて、IngressControllerのdomainパラメーターに<yourdomain>を追加します。 次のコマンドを実行して、新しい
IngressControllerを適用します。oc apply -f ingresscontroller.yaml
oc apply -f ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の手順を実行して、新しい
IngressControllerのspec.domainパラメーターの値が既存のIngressControllerと競合していないことを確認します。次のコマンドを実行して、すべての
IngressControllerを一覧表示します。oc get ingresscontroller -n openshift-ingress-operator
oc get ingresscontroller -n openshift-ingress-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 先ほど作成した
ingress-controller-with-nlbを除く各IngressControllersで次のコマンドを実行します。oc edit ingresscontroller <name> -n openshift-ingress-operator
oc edit ingresscontroller <name> -n openshift-ingress-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.domainレポートが見つからない場合は、nlb-apps.<domain>.comを除く、クラスターで公開されているすべてのルートに一致するデフォルトドメインを追加します。spec.domainレポートが提供されている場合は、指定された範囲からnlb-apps.<domain>.comルートが除外されていることを確認してください。
次のコマンドを実行して、
assisted-image-serviceルートを編集し、nlb-appsの場所を使用します。oc edit route assisted-image-service -n <namespace>
oc edit route assisted-image-service -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトの namespace は、multicluster engine Operator をインストールした場所です。
次の行を
assisted-image-serviceルートに追加します。metadata: labels: router-type: nlb name: assisted-image-servicemetadata: labels: router-type: nlb name: assisted-image-serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow assisted-image-serviceルートで、spec.hostの URL 値を見つけます。URL は次の例のようになります。assisted-image-service-multicluster-engine.apps.<yourdomain>.com
assisted-image-service-multicluster-engine.apps.<yourdomain>.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
URL 内の
appsをnlb-appsに置き換えて、新しいIngressControllerで設定されたドメインと一致させます。 Central Infrastructure Management サービスが Amazon Web Services で有効になっていることを確認するには、次のコマンドを実行して Pod が正常であることを確認します。
oc get pods -n multicluster-engine | grep assist
oc get pods -n multicluster-engine | grep assistCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
新しいホストインベントリーを作成し、ダウンロード URL が新しい
nlb-appsURL を使用していることを確認します。
1.9.4. コンソールを使用したホストインベントリーの作成
ホストインベントリー (インフラストラクチャー環境) を作成して、OpenShift Container Platform クラスターをインストールできる物理マシンまたは仮想マシンを検出できます。
1.9.4.1. 前提条件
- Central Infrastructure Management サービスを有効にする。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
1.9.4.2. ホストインベントリーの作成
コンソールを使用してホストインベントリーを作成するには、次の手順を実行します。
- コンソールから、Infrastructure > Host inventory に移動して、Create infrastructure environment をクリックします。
次の情報をホストインベントリー設定に追加します。
- 名前
-
インフラストラクチャー環境の一意の名前。コンソールを使用してインフラストラクチャー環境を作成すると、選択した名前で
InfraEnvリソースの新しい namespace も作成されます。コマンドラインインターフェイスを使用してInfraEnvリソースを作成し、コンソールでリソースを監視する場合は、namespace とInfraEnvに同じ名前を使用します。 - ネットワークタイプ
- インフラストラクチャー環境に追加するホストが DHCP を使用するか、静的ネットワークを使用するかを指定します。静的ネットワーク設定には、追加の手順が必要です。
- Location
- ホストの地理的な場所を指定します。地理的なロケーションを使用して、ホストが配置されているデータセンターを定義できます。
- ラベル
- このインフラストラクチャー環境で検出されたホストにラベルを追加できるオプションのフィールド。指定した場所はラベルのリストに自動的に追加されます。
- インフラストラクチャープロバイダーの認証情報
- インフラストラクチャープロバイダーの認証情報を選択すると、プルシークレットと SSH 公開鍵のフィールドに認証情報の情報が自動的に入力されます。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
- プルシークレット
- OpenShift Container Platform リソースにアクセスできるようにする OpenShift Container Platform プルシークレット。インフラストラクチャープロバイダーの認証情報を選択した場合、このフィールドには自動的に入力されます。
- SSH 公開鍵
ホストとの安全な通信を可能にする SSH 鍵。これを使用してホストに接続し、トラブルシューティングを行うことができます。クラスターをインストールした後は、SSH 鍵を使用してホストに接続できなくなります。通常、鍵は
id_rsa.pubファイルにあります。デフォルトのファイルパスは~/.ssh/id_rsa.pubです。SSH 公開鍵の値を含むインフラストラクチャープロバイダーの認証情報を選択した場合、このフィールドには自動的に入力されます。ホストのプロキシー設定を有効にする場合は、有効にする設定を選択し、次の情報を入力します。
- HTTP プロキシーの URL
- HTTP リクエストのプロキシーの URL
- HTTPS プロキシーの URL
- HTTP リクエストのプロキシーの URLURL は HTTP で始まる必要があります。HTTPS はサポートされていません。値を指定しない場合、デフォルトで HTTP 接続と HTTPS 接続の両方に HTTP プロキシー URL が使用されます。
- プロキシードメインなし
-
プロキシーを使用しないドメインのコンマ区切りのリスト。ドメイン名をピリオド (
.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。必要に応じて、NTP プールまたはサーバーの IP 名またはドメイン名のコンマ区切りリストを指定して、独自のネットワークタイムプロトコル (NTP) ソースを追加します。
コンソールでは使用できない詳細な設定オプションが必要な場合は、コマンドラインインターフェイスを使用したホストインベントリーの作成 に進みます。
高度な設定オプションが必要ない場合は、必要に応じて静的ネットワークの設定を続行し、インフラストラクチャー環境へのホストの追加を開始できます。
1.9.4.3. ホストインベントリーへのアクセス
ホストインベントリーにアクセスするには、コンソールで Infrastructure > Host inventory を選択します。一覧からインフラストラクチャー環境を選択し、詳細とホストを表示します。
1.9.4.4. 関連情報
ベアメタル上で Hosted Control Plane を設定するプロセスの一環としてホストインベントリーを作成した場合は、次の手順を実行します。
1.9.5. コマンドラインインターフェイスを使用したホストインベントリーの作成
ホストインベントリー (インフラストラクチャー環境) を作成して、OpenShift Container Platform クラスターをインストールできる物理マシンまたは仮想マシンを検出できます。自動化されたデプロイメントや、以下の高度な設定オプションには、コンソールの代わりにコマンドラインインターフェイスを使用します。
- 検出されたホストを既存のクラスター定義に自動的にバインドする
- Discovery Image の Ignition 設定をオーバーライドする
- iPXE の動作を制御する
- Discovery Image のカーネル引数を変更する
- 検出フェーズ中にホストに信頼させる追加の証明書を渡す
- 最新バージョンのデフォルトオプションではない、テスト用に起動する Red Hat CoreOS バージョンを選択する
1.9.5.1. 前提条件
Central Infrastructure Management サービスを有効にする。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
1.9.5.2. ホストインベントリーの作成
コマンドラインインターフェイスを使用してホストインベントリー (インフラストラクチャー環境) を作成するには、次の手順を実行します。
次のコマンドを実行して、ハブクラスターにログインします。
oc login
oc loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow リソースの namespace を作成します。
namespace.yamlという名前のファイルを作成し、次の内容を追加します。apiVersion: v1 kind: Namespace metadata: name: <your_namespace>
apiVersion: v1 kind: Namespace metadata: name: <your_namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- コンソールでインベントリーを監視するには、namespace とインフラストラクチャー環境に同じ名前を使用します。
以下のコマンドを実行して YAML コンテンツを適用します。
oc apply -f namespace.yaml
oc apply -f namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
OpenShift Container Platform プルシークレット を含む
Secretカスタムリソースを作成します。インフラストラクチャー環境を作成します。
infra-env.yamlファイルを作成し、以下の内容を追加します。必要に応じて値を置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
InfraEnv テーブルの次のフィールドの説明を参照してください。
| フィールド | 任意または必須 | 説明 |
|---|---|---|
|
| 任意 |
|
|
| 任意 |
HTTP リクエストのプロキシーの URLURL は |
|
| 任意 |
HTTP リクエストのプロキシーの URLURL は |
|
| 任意 | プロキシーを使用しない場合は、コンマで区切られたドメインおよび CIDR のリスト。 |
|
| 任意 | すべてのホストに追加するネットワークタイムプロトコル (NTP) ソース (ホスト名または IP) のリスト。これらは、DHCP などの他のオプションを使用して設定された NTP ソースに追加されます。 |
|
| 任意 | 検出フェーズ中のデバッグに使用するためにすべてのホストに追加される SSH 公開鍵。検出フェーズは、ホストを Discovery Image を起動するときです。 |
|
| 必須 | プルシークレットが含まれる Kubernetes シークレットの名前。 |
|
| 任意 |
|
|
| 任意 |
ホストの静的 IP、ブリッジ、ボンディングなどの高度なネットワーク設定を統合します。ホストネットワーク設定は、選択したラベルを持つ 1 つ以上の |
|
| 任意 |
スタンドアロンのオンプレミスクラスターを記述する既存の |
|
| 任意 |
ファイルの追加など、Red Hat CoreOS ライブイメージの Ignition 設定を変更します。必要に応じて |
|
| 任意 | サポートされている CPU アーキテクチャー x86_64、aarch64、ppc64le、または s390x のいずれかを選択します。デフォルト値は x86_64 です。 |
|
| 任意 |
起動に iPXE を使用している場合に、デフォルト値である |
|
| 任意 |
Discovery Image の起動時にカーネル引数を変更できます。 |
|
| 任意 |
PEM エンコードされた X.509 証明書バンドル。通常、ホストが再暗号化中間者 (MITM) プロキシーを備えたネットワーク内にある場合、またはコンテナーイメージレジストリーなど、他の目的でホストが証明書を信頼しなければならない場合に必要です。 |
|
| 任意 |
|
|
| 任意 |
ダウンロードする ISO ファイルの種類を選択します。 |
以下のコマンドを実行して YAML コンテンツを適用します。
oc apply -f infra-env.yaml
oc apply -f infra-env.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ホストインベントリーが作成されたことを確認するには、次のコマンドでステータスを確認します。
oc describe infraenv myinfraenv -n <your_namespace>
oc describe infraenv myinfraenv -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
重要なプロパティーのリストは次のとおりです。
-
conditions: イメージが正常に作成されたかどうかを示す標準の Kubernetes の状態。 -
isoDownloadURL: Discovery Image をダウンロードするための URL。 -
createdTime: イメージが最後に作成された時刻。InfraEnvを変更する場合は、新しいイメージをダウンロードする前にタイムスタンプが更新されていることを確認してください。
注: InfraEnv リソースを変更する場合は、createdTime プロパティーを確認して、InfraEnv が新しい Discovery Image を作成したことを確認してください。すでにホストを起動している場合は、最新の Discovery Image でホストを再起動します。
必要に応じて静的ネットワークを設定し、インフラストラクチャー環境へのホストの追加を開始することで続行できます。
1.9.5.3. 関連情報
1.9.6. インフラストラクチャー環境用の高度なネットワークの設定
1 つのインターフェイスで DHCP 以外のネットワークを必要とするホストの場合は、高度なネットワークを設定する必要があります。必要な設定には、1 つ以上のホストのネットワークを記述する NMStateConfig リソースの 1 つ以上のインスタンスの作成が含まれます。
各 NMStateConfig リソースには、InfraEnv リソースの nmStateConfigLabelSelector に一致するラベルが含まれている必要があります。nmStateConfigLabelSelector の詳細は、コマンドラインインターフェイスを使用したホストインベントリーの作成 を参照してください。
Discovery Image には、参照されているすべての NMStateConfig リソースで定義されたネットワーク設定が含まれています。起動後、各ホストは各設定をそのネットワークインターフェイスと比較し、適切な設定を適用します。
1.9.6.1. 前提条件
- Central Infrastructure Management サービスを有効にする。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
- ホストインベントリーを作成する。詳細は、コンソールを使用したホストインベントリーの作成 を参照してください。
1.9.6.2. コマンドラインインターフェイスを使用した高度なネットワークの設定
コマンドラインインターフェイスを使用してインフラストラクチャー環境の詳細ネットワークを設定するには、以下の手順を実行します。
nmstateconfig.yamlという名前のファイルを作成し、以下のテンプレートのようなコンテンツを追加します。必要に応じて値を置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
| フィールド | 任意または必須 | 説明 |
|---|---|---|
|
| 必須 | 設定しているホストに関連した名前を使用してください。 |
|
| 必須 |
namespace は、 |
|
| 必須 |
|
|
| 任意 |
|
|
| 任意 |
指定された |
注: イメージサービスは、InfraEnv プロパティーを更新するか、そのラベルセレクターに一致する NMStateConfig リソースを変更すると、新しいイメージを自動的に作成します。InfraEnv リソースの作成後に NMStateConfig リソースを追加する場合は、InfraEnv の createdTime プロパティーを確認して、InfraEnv が新しい Discovery Image を作成していることを確認してください。すでにホストを起動している場合は、最新の Discovery Image でホストを再起動します。
以下のコマンドを実行して YAML コンテンツを適用します。
oc apply -f nmstateconfig.yaml
oc apply -f nmstateconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.9.6.3. 関連情報
1.9.7. Discovery Image を使用したホストのホストインベントリーへの追加
ホストインベントリー (インフラストラクチャー環境) を作成したら、ホストを検出してインベントリーに追加できます。
インベントリーにホストを追加するには、ISO ファイルをダウンロードして各サーバーにアタッチする方法を選択します。たとえば、仮想メディアを使用したり、ISO ファイルを USB ドライブに書き込んだりして、ISO ファイルをダウンロードできます。
重要: インストールが失敗しないようにするには、インストールプロセス中は Discovery ISO メディアをデバイスに接続したままにし、各ホストがデバイスから 1 回起動するように設定します。
1.9.7.1. 前提条件
- Central Infrastructure Management サービスを有効にする。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
- ホストインベントリーを作成する。詳細は、コンソールを使用したホストインベントリーの作成 を参照してください。
1.9.7.2. コンソールを使用したホストの追加
以下の手順に従って ISO ファイルをダウンロードしてください。
- コンソールで Infrastructure > Host inventory を選択します。
- 一覧からお使いのインフラストラクチャー環境を選択します。
- Add hosts をクリックし、With Discovery ISO を選択します。
- Minimal image file または Full image file を選択します。
Generate Discovery ISO をクリックします。
注記: 起動したホストがホストインベントリーテーブルに表示されます。ホストが表示されるまでに数分かかる場合があります。
- 各ホストを承認して使用できるようにします。Actions をクリックして Approve を選択し、インベントリーテーブルからホストを選択できます。
1.9.7.3. コマンドラインインターフェイスを使用したホストの追加
isoDownloadURL プロパティー内の ISO ファイルをダウンロードするための URL は、InfraEnv リソースのステータスに含まれます。InfraEnv リソースの詳細は、コマンドラインインターフェイス を使用したホストインベントリーの作成を参照してください。
起動したホストごとに、同じ namespace に Agent リソースを作成します。
次のコマンドを実行して、
InfraEnvカスタムリソースのダウンロード URL を表示します。oc get infraenv -n <infra env namespace> <infra env name> -o jsonpath='{.status.isoDownloadURL}'oc get infraenv -n <infra env namespace> <infra env name> -o jsonpath='{.status.isoDownloadURL}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の出力を参照してください。
https://assisted-image-service-assisted-installer.apps.example-acm-hub.com/byapikey/eyJhbGciOiJFUzI1NiIsInC93XVCJ9.eyJpbmZyYV9lbnZfaWQcTA0Y38sWVjYi02MTA0LTQ4NDMtODasdkOGIxYTZkZGM5ZTUifQ.3ydTpHaXJmTasd7uDp2NvGUFRKin3Z9Qct3lvDky1N-5zj3KsRePhAM48aUccBqmucGt3g/4.17/x86_64/minimal.iso
https://assisted-image-service-assisted-installer.apps.example-acm-hub.com/byapikey/eyJhbGciOiJFUzI1NiIsInC93XVCJ9.eyJpbmZyYV9lbnZfaWQcTA0Y38sWVjYi02MTA0LTQ4NDMtODasdkOGIxYTZkZGM5ZTUifQ.3ydTpHaXJmTasd7uDp2NvGUFRKin3Z9Qct3lvDky1N-5zj3KsRePhAM48aUccBqmucGt3g/4.17/x86_64/minimal.isoCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: デフォルトでは、最小限の ISO が指定されます。
InfraEnvリソースでImageTypeをfull-isoに設定することで、完全な ISO を指定できます。詳細は、関連情報セクションの コマンドラインインターフェイスを使用したホストインベントリーの作成 を参照してください。URL を使用して ISO ファイルをダウンロードし、ISO ファイルを使用してホストを起動します。
次に、各ホストを承認する必要があります。以下の手順を参照してください。
すべての
エージェントをリスト表示するには、次のコマンドを実行します。oc get agent -n <infra env namespace>
oc get agent -n <infra env namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のような出力が得られます。
NAME CLUSTER APPROVED ROLE STAGE 24a92a6f-ea35-4d6f-9579-8f04c0d3591e false auto-assign
NAME CLUSTER APPROVED ROLE STAGE 24a92a6f-ea35-4d6f-9579-8f04c0d3591e false auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow リストで承認ステータスが
falseのエージェントを承認します。以下のコマンドを実行します。oc patch agent -n <infra env namespace> <agent name> -p '{"spec":{"approved":true}}' --type mergeoc patch agent -n <infra env namespace> <agent name> -p '{"spec":{"approved":true}}' --type mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 承認ステータスを確認するには、次のコマンドを実行します。
oc get agent -n <infra env namespace>
oc get agent -n <infra env namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 値が
trueの、次のような出力が返されます。NAME CLUSTER APPROVED ROLE STAGE 173e3a84-88e2-4fe1-967f-1a9242503bec true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 173e3a84-88e2-4fe1-967f-1a9242503bec true auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.9.7.4. HTTP または HTTPS による iPXE アーティファクトのホスティング
AgentServiceConfig カスタムリソースの spec.iPXEHTTPRoute フィールドを編集することで、iPXE アーティファクトをホストする方法を変更できます。
iPXE アーティファクトに HTTP を使用するには、フィールドを enabled に設定します。
iPXE アーティファクトに HTTPS を使用するには、フィールドを disabled に設定します。
デフォルト値は、disabled です。spec.iPXEHTTPRoute フィールドが enabled に設定されている次の例を参照してください。
値を enabled に設定すると、次のエンドポイントが HTTP 経由で公開されます。
-
assisted-serviceのapi/assisted-installer/v2/infra-envs/<id>/downloads/files?file_name=ipxe-script -
assisted-image-serviceのboot-artifacts/およびimages/<infra-env-id>/pxe-initrd
1.9.7.5. 関連情報
-
InfraEnvリソースの詳細は、コマンドラインインターフェイスを使用したホストインベントリーの作成 を参照してください。
1.9.8. ベアメタルホストのホストインベントリーへの自動追加
インフラストラクチャー環境を作成した後、ホストを検出してインベントリーに追加できます。ベアメタル Operator が各ベアメタルホストの Baseboard Management Controller (BMC) と通信するようにすることで、インフラストラクチャー環境の Discovery Image の起動を自動化できます。各ホストに対して BareMetalHost リソースと関連付けられた BMC シークレットを作成します。自動化は、インフラストラクチャー環境を参照する BareMetalHost のラベルによって設定されます。
自動化により以下のアクションが実行されます。
- インフラストラクチャー環境で表される Discovery Image を使用して、各ベアメタルホストを起動します。
- インフラストラクチャー環境または関連するネットワーク設定が更新された場合に、各ホストを最新の Discovery Image で再起動します。
-
検出時に各
Agentリソースを対応するBareMetalHostリソースに関連付けます。 -
BareMetalHostからの情報 (ホスト名、ロール、インストールディスクなど) に基づいてAgentリソースのプロパティーを更新します。 -
Agentをクラスターノードとして使用することを承認します。
1.9.8.1. 前提条件
- Central Infrastructure Management サービスを有効にする。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
- ホストインベントリーを作成する。詳細は、コンソールを使用したホストインベントリーの作成 を参照してください。
1.9.8.2. コンソールを使用したベアメタルホストの追加
コンソールを使用してベアメタルホストをホストインベントリーに自動的に追加するには、次の手順を実行します。
- コンソールで Infrastructure > Host inventory を選択します。
- 一覧からお使いのインフラストラクチャー環境を選択します。
- Add hosts をクリックし、With BMC Form を選択します。
- 必要な情報を追加し、Create をクリックします。
BMC アドレスのフォーマットの詳細は、関連情報セクションの BMC アドレス指定 を参照してください。
1.9.8.3. コマンドラインインターフェイスを使用したベアメタルホストの追加
コマンドラインインターフェイスを使用してベアメタルホストをホストインベントリーに自動的に追加するには、以下の手順を実施します。
次の YAML コンテンツを適用し、必要に応じて値を置き換えて、BMC シークレットを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- namespace は
InfraEnvの namespace と同じである必要があります。
以下の YAML コンテンツを適用し、必要に応じて値を置き換えてベアメタルホストを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- namespace は
InfraEnvの namespace と同じである必要があります。 - 2
- オプション: ホストの名前に置き換えます。
- 3
- オプション: 使用できる値は
masterおよびworkerです。 - 4
- この名前は
InfrEnvの名前と一致し、同じ namespace に存在する必要があります。 - 5
- 値を設定しない場合、
metadataの値が自動的に使用されます。 - 6
- MAC アドレスが、いずれかのホストインターフェイスの MAC アドレスと一致していることを確認します。
- 7
- BMC のアドレスを使用します。詳細は、関連情報セクションの 帯域外管理 IP アドレスのポートアクセス と BMC アドレス指定 を参照してください。
- 8
credentialsNameの値が、作成した BMC シークレットの名前と一致していることを確認してください。- 9
- オプション: インストールディスクを選択します。利用可能なルートデバイスのヒントは、BareMetalHost spec を参照してください。ホストが Discovery Image で起動され、対応する
Agentリソースが作成された後、このヒントに従ってインストールディスクが設定されます。
ホストの電源をオンにすると、イメージのダウンロードが開始されます。これには数分かかる場合があります。ホストが検出されると、Agent カスタムリソースが自動的に作成されます。
1.9.8.4. コマンドラインインターフェイスを使用したマネージドクラスターノードの削除
マネージドクラスターからマネージドクラスターノードを削除するには、サポートされている OpenShift Container Platform バージョンで実行されているハブクラスターが必要です。ノードの起動に必要な静的ネットワーク設定が利用可能である必要があります。エージェントとベアメタルホストを削除するときに、NMStateConfig リソースを削除しないようにしてください。
1.9.8.4.1. ベアメタルホストを使用したマネージドクラスターノードの削除
ハブクラスター上にベアメタルホストがあり、マネージドクラスターからマネージドクラスターノードを削除する場合は、次の手順を実行します。
削除するノードの
BareMetalHostリソースに次のアノテーションを追加します。bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: true
bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
BareMetalHostリソースを削除します。<bmh-name>は、BareMetalHostの名前に置き換えます。oc delete bmh <bmh-name>
oc delete bmh <bmh-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.9.8.4.2. ベアメタルホストを使用しないマネージドクラスターノードの削除
ハブクラスターにベアメタルホストがなく、マネージドクラスターからマネージドクラスターノードを削除する場合は、Agent 仕様から clusterDeploymentName フィールドを削除してエージェントをアンバインドするか、削除するノードに対応する Agent カスタムリソースを削除します。
ハブクラスターから Agent リソースを削除するが、マネージドクラスターからノードは削除しない場合、Agent リソースを削除する前に、そのリソースでアノテーション agent.agent-install.openshift.io/skip-spoke-cleanup を true に設定できます。
OpenShift Container Platform ドキュメントの ノードの削除 手順を参照してください。
1.9.8.5. ホストのバインドとアンバインド
Agent カスタムリソースの spec.clusterDeploymentName フィールドを設定するか、{}bmac.agent-install.openshift.io/cluster-reference ベアメタルホストアノテーションを設定することで、ホストを Red Hat OpenShift Container Platform クラスターにバインドできます。
{}bmac.agent-install.openshift.io/cluster-reference ベアメタルホストアノテーションは、OpenShift Container Platform クラスターへの接続を制御し、特定のクラスターにホストをバインドまたはアンバインドします。
{}bmac.agent-install.openshift.io/cluster-reference アノテーションは、次の 3 つの方法のいずれかで使用できます。
- ベアメタルホストでアノテーションを設定しない場合、ホストに変更は適用されません。
- アノテーションに空の文字列値を設定すると、ホストはアンバインドされます。
-
アノテーションを設定し、
<cluster-namespace>/<cluster-name>形式の文字列値を使用すると、ホストはClusterDeploymentカスタムリソースが表すクラスターにバインドされます。
注記: ホストが属する InfraEnv にすでに cluster-reference アノテーションが含まれている場合、{}bmac.agent-install.openshift.io/cluster-reference アノテーションは無視されます。
1.9.8.6. 関連情報
- ゼロタッチプロビジョニングの詳細は、OpenShift Container Platform ドキュメントの ネットワークファーエッジのクラスター を参照してください。
- ベアメタルホストを使用するために必要なポートの詳細は、OpenShift Container Platform ドキュメントの 帯域外管理 IP アドレスのポートアクセス を参照してください。
- ルートデバイスのヒントの詳細は、OpenShift Container Platform ドキュメントの インストール後の設定の概要 を参照してください。
- イメージプルシークレットの使用
- オンプレミス環境の認証情報の作成
- コンピュートマシンのスケーリングの詳細は、OpenShift Container Platform ドキュメントの コンピュートマシンセットの手動スケーリング を参照してください。
- BMC 形式のアドレス指定の詳細は、OpenShift Container Platform ドキュメントの BMC アドレス 指定を参照してください。
1.9.9. ホストインベントリーの管理
コンソールまたはコマンドラインインターフェイスを使用して、Agent リソースの編集、ホストインベントリーの管理、既存のホストの編集が可能です。
1.9.9.1. コンソールを使用したホストインベントリーの管理
Discovery ISO で正常に起動した各ホストは、ホストインベントリーの行として表示されます。コンソールを使用してホストを編集および管理できます。ホストを手動で起動し、ベアメタル Operator の自動化を使用していない場合は、使用する前にコンソールでホストを承認する必要があります。OpenShift ノードとしてインストールできるホストが Available ステータスになっています。
1.9.9.2. コマンドラインインターフェイスを使用したホストインベントリーの管理
Agent リソースは、各ホストを表します。Agent リソースで次のプロパティーを設定できます。
clusterDeploymentNameこのプロパティーは、クラスターにノードとしてインストールする場合に使用する
ClusterDeploymentの namespace および名前に設定します。任意:
roleクラスター内のホストのロールを設定します。使用できる値は、
master、worker、およびauto-assignです。デフォルト値はauto-assignです。hostnameホストのホスト名を設定します。ホストに有効なホスト名が自動的に割り当てられる場合は任意です (例: DHCP を使用)。
approvedホストを OpenShift ノードとしてインストールできるかどうかを示します。このプロパティーは、デフォルト値が
Falseのブール値です。ホストを手動で起動しており、ベアメタル Operator の自動化を使用していない場合は、ホストをインストールする前にこのプロパティーをTrueに設定する必要があります。installation_disk_idホストのインベントリーに表示されるインストールディスクの ID。
installerArgsホストの coreos-installer 引数のオーバーライドが含まれる JSON 形式の文字列。このプロパティーを使用して、カーネル引数を変更できます。構文例を以下に示します。
["--append-karg", "ip=192.0.2.2::192.0.2.254:255.255.255.0:core0.example.com:enp1s0:none", "--save-partindex", "4"]
["--append-karg", "ip=192.0.2.2::192.0.2.254:255.255.255.0:core0.example.com:enp1s0:none", "--save-partindex", "4"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow ignitionConfigOverridesホストの Ignition 設定のオーバーライドが含まれる JSON 形式の文字列。このプロパティーを使用して、ignition を使用してファイルをホストに追加できます。構文例を以下に示します。
{"ignition": "version": "3.1.0"}, "storage": {"files": [{"path": "/tmp/example", "contents": {"source": "data:text/plain;base64,aGVscGltdHJhcHBlZGluYXN3YWdnZXJzcGVj"}}]}}{"ignition": "version": "3.1.0"}, "storage": {"files": [{"path": "/tmp/example", "contents": {"source": "data:text/plain;base64,aGVscGltdHJhcHBlZGluYXN3YWdnZXJzcGVj"}}]}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow nodeLabelsホストのインストール後にノードに適用されるラベルのリスト。
Agent リソースの status には、以下のプロパティーがあります。
roleクラスター内のホストのロールを設定します。これまでに
Agentリソースでroleをしたことがある場合は、その値がstatusに表示されます。inventoryホスト上で実行されているエージェントが検出するホストプロパティーが含まれます。
progressホストのインストールの進行状況。
ntpSourcesホストの設定済みの Network Time Protocol (NTP) ソース。
conditions次の標準 Kubernetes 条件 (
TrueまたはFalse値) が含まれます。-
SpecSynced: 指定されたすべてのプロパティーが正常に適用される場合は
True。何らかのエラーが発生した場合は、False。 -
Connected: インストールサービスへのエージェント接続が禁止されていない場合は
True。エージェントがしばらくの間インストールサービスに接続していない場合はFalse。 -
RequirementsMet: ホストがインストールを開始する準備ができている場合は
True。 -
Validated: すべてのホスト検証に合格した場合は
True。 -
installed: ホストが OpenShift ノードとしてインストールされている場合は
True。 -
Bound: ホストがクラスターにバインドされている場合は
True。 -
Cleanup:
Agentリソースの削除リクエストが失敗した場合はFalse。
-
SpecSynced: 指定されたすべてのプロパティーが正常に適用される場合は
debugInfoインストールログおよびイベントをダウンロードするための URL が含まれています。
validationsInfoホストの検出後にインストールが成功したことを確認するためにエージェントが実行する検証の情報が含まれます。値が
Falseの場合は、トラブルシューティングを行ってください。installation_disk_idホストのインベントリーに表示されるインストールディスクの ID。
1.9.9.3. 関連情報
1.9.10. 各クラスターのミラーレジストリーの設定
ミラーレジストリー機能を使用して、各 AgentClusterInstall および InfraEnv リソースから専用のミラーレジストリー設定オブジェクトを参照することにより、各クラスターのカスタムレジストリーを設定および管理します。
分離されたレジストリー設定が必要なマルチクラスター環境では、クラスターごとにミラーレジストリーを設定する場合があります。
1.9.10.1. 前提条件
- Central Infrastructure Management サービスを有効にする。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
- ミラーレジストリーを設定する。
-
assisted-serviceはKubeAPIモードで実行する。
1.9.10.2. 必要なイメージのミラーリング
必要なイメージがレジストリーにミラーリングされていることを確認します。以下の手順を実行します。
次のコマンドを実行して、Red Hat OpenShift Container Platform リリースイメージをミラーリングします。
oc adm release mirror \ -a pull_secret.json \ --from=quay.io/openshift-release-dev/ocp-release:$OCP_TAG \ --to=$REGISTRY_IP:$REGISTRY_PORT/openshift-release-dev/ocp-release \ --to-release-image=$REGISTRY_IP:$REGISTRY_PORT/openshift-release-dev/ocp-release:$OCP_TAG \
oc adm release mirror \ -a pull_secret.json \ --from=quay.io/openshift-release-dev/ocp-release:$OCP_TAG \ --to=$REGISTRY_IP:$REGISTRY_PORT/openshift-release-dev/ocp-release \ --to-release-image=$REGISTRY_IP:$REGISTRY_PORT/openshift-release-dev/ocp-release:$OCP_TAG \Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: ミラーレジストリー内の OpenShift Container Platform のバージョンが、イメージセット設定内のバージョンと一致していることを確認してください。
次のコマンドを実行して、Assisted Installer イメージをミラーリングします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.9.10.3. 更新された設定でカスタムリソース定義を適用する
ミラーレジストリーを設定したら、必要なカスタムリソース定義を適用して、ミラーリングされたイメージを使用するようにクラスターを設定します。以下の手順を実行します。
-
次の内容を含む
mirror_registry.yamlという名前のConfigMapファイルを作成します。必要に応じて値を置き換えます。
-
次のコマンドを実行して
ConfigMapを適用します。
oc apply -f mirror_registry.yaml
oc apply -f mirror_registry.yamlAgentClusterInstallおよびInfraEnvカスタムリソース定義がミラーレジストリー設定を参照していることを確認します。aci.yamlとinfraenv.yaml両方に関する次の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、カスタムリソース定義を更新して適用します。
oc apply -f aci.yaml oc apply -f infraenv.yaml
oc apply -f aci.yaml oc apply -f infraenv.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.9.10.4. 関連情報
- イメージのミラーリングの詳細は、OpenShift Container Platform ドキュメントの 非接続インストールのイメージのミラーリング を参照してください。
1.10. クラスター API
Cluster API は、Kubernetes クラスターのプロビジョニング、アップグレード、管理を簡素化する宣言型 API を提供します。multicluster engine Operator は、コアとなる Cluster API コンポーネントに加え、複数のインフラストラクチャープロバイダーとブートストラッププロバイダーをインストールすることで、さまざまなユースケースとプラットフォームをサポートします。スタンドアロンの multicluster engine Operator または Red Hat Advanced Cluster Management で Cluster API を使用する方法を説明します。次のプロセスを参照してください。
1.10.1. Cluster API を使用したマネージドクラスターのインストール
metal3 インフラストラクチャープロバイダーと OpenShift Container Platform 支援ブートストラップおよびコントロールプレーンプロバイダーを使用して、Cluster API を備えた OpenShift Container Platform マネージドクラスターをインストールできます。
- `ControlPlane` はコントロールプレーンのプロパティーを定義します。
-
ClusterInfrastructureは、クラスターレベルのインフラストラクチャーの詳細を定義します。
前提条件
-
Red Hat Advanced Cluster Management インストールまたは multicluster engine Operator スタンドアロンインストールのいずれかからの
MultiClusterEngineリソースが必要です。 -
api.<cluster_name>.<base_domain>の API ベースドメインは、静的 API 仮想 IP を指している必要があります。 -
*.apps.<cluster_name>.<base_domain>のアプリケーションベースドメインは、Ingress 仮想 IP の静的 IP アドレスを指している必要があります。 -
クラスターの内部 API エンドポイント
api-int.<baseDomain>が必要です。
1.10.1.1. Cluster API を使用したワークロードのプロビジョニング
ワークロードをプロビジョニングするために必要なサービスを有効にします。デフォルトでは、
assisted-serviceが有効になっています。デフォルトでは、cluster-api-provider-metal3-preview とcluster-api-provider-openshift-assisted-previewは無効になっています。3 つのサービスがすべてenabled: trueであることを確認します。以下のコマンドを実行してリソースを編集します。oc edit multiclusterengines.multicluster.openshift.io -n multicluster-engine
oc edit multiclusterengines.multicluster.openshift.io -n multicluster-engineCopy to Clipboard Copied! Toggle word wrap Toggle overflow .spec.overridesで、assisted-serviceコンポーネント、cluster-api-provider-metal3-previewコンポーネント、cluster-api-provider-openshift-assisted-previewコンポーネントをenabled: trueに設定します。次のconfigOverrides値を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Central Infrastructure Management サービスの有効化手順は central infrastructure management サービスの有効化 を参照してください。
clusterNetwork仕様、controlPlaneRef仕様、およびinfrastructureRef仕様を使用してClusterリソースを設定します。次のClusterリソースを参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して YAML コンテンツを適用します。
oc apply -f <filename>.yaml
oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow distributionVersion、apiVIPs、および SSH キーを含むOpenshiftAssistedControlPlaneリソースを設定します。distributionVersionフィールドに OpenShift Container Platform のバージョンを指定します。注記:
distributionVersionの値は OpenShift Container Platform Releases のイメージと一致します。次の YAML リソースを参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <1>`.spec.openshiftAssistedConfigSpec.sshAuthorizedKey` は、ブート (discovery とも呼ばれる) フェーズでノードにアクセスするために使用されます。<2>`.spec.config.sshAuthorizedKey` は、プロビジョニングされた OpenShift Container Platform ノードにアクセスするために使用されます。
YAML ファイルを適用します。以下のコマンドを実行します。
oc apply -f <filename>.yaml
oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - プルシークレットがない場合は、クラスターがコンテナーレジストリーからイメージをプルできるように、プルシークレットを作成する必要があります。プルシークレットを作成するには、次の手順を実行します。
イメージをプルするための YAML ファイルを作成します。
pull-secret.yamlという名前のファイルの次の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ファイルを適用します。
oc apply -f pull-secret.yaml
oc apply -f pull-secret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ベアメタル上のクラスターのデプロイメントに関連する情報が含まれる
Metal3Clusterインフラストラクチャーリソースを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
hostは、ClusterリソースのclusterNameを持つ<clusterName>.<baseDomain>*値であり、baseDomainはOpenshiftAssistedControlPlaneリソースで定義されます。
ファイルを適用します。以下のコマンドを実行します。
oc apply -f <filename>.yaml
oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenshiftAssistedControlPlaneリソースから参照されるコントロールプレーンノードのMetal3MachineTemplateリソースを設定します。以下の YAML 例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- イメージは、
distributionVersion値と OpenShift Container Platform Releases のバージョンと一致します。 - 2
clusterNameはClusterリソースと同じ値に設定します。
ファイルを適用します。以下のコマンドを実行します。
oc apply -f <filename>.yaml
oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Metal3MachineTemplateを参照するMachineDeploymentリソースを使用してワーカーノードを設定します。以下は、YAML の例です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルを適用します。以下のコマンドを実行します。
oc apply -f <filename>.yaml
oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow MachineDeploymentで参照されるOpenshiftAssistedConfigTemplateリソースを作成します。次の YAML はワーカーノードのブートストラップ設定を定義し、Assisted Installer を使用してノードを登録するために使用されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow MachineDeploymentリソースで参照されるMetal3MachineTemplateを作成します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、YAML ファイルを保存し、クラスターをプロビジョニングします。
oc apply -f <filename>.yaml
oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのプロビジョニングステータスを確認します。
oc get cluster --namespace <cluster-namespace> <cluster-name> -o yamlを実行して、Clusterリソースのステータスを確認します。次の出力とステータスを参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get metal3cluster --namespace <cluster-namespace> <cluster-name> -o yamlコマンドを実行して、クラスターインフラストラクチャーのステータスを確認します。次の出力とステータスを参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンのステータスを確認するには、
oc get openshiftassistedcontrolplane --namespace <cluster-namespace> <cluster-name> -o yamlコマンドを実行します。次の出力とステータスを参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get machinedeployment --namespace <cluster-namespace> <cluster-name> -o yamlコマンドを実行して、マシンのデプロイメントのステータスを確認します。次の出力とステータスを参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow kubectl get machine -l cluster.x-k8s.io/cluster-name=cluster-name -n test-capi -o yamlコマンドを実行して、マシンを確認します。次の出力とステータスを参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターにアクセスします。
kubeconfigファイルを取得するには、次のコマンドを実行します。oc get secret -n test-capi cluster-name-admin-kubeconfig -o json | jq -r .data.kubeconfig | base64 --decode > kubeconfig
oc get secret -n test-capi cluster-name-admin-kubeconfig -o json | jq -r .data.kubeconfig | base64 --decode > kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
kubeconfigファイルを使用してクラスターにアクセスするには、次のコマンドを実行します。
export KUBECONFIG=$(realpath kubeconfig) oc get nodes
export KUBECONFIG=$(realpath kubeconfig) oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.11. API
非推奨: API のドキュメントは非推奨となりました。現在のサポートされている API を表示するには、コンソールの API Explorer または oc コマンドを使用します。
multicluster engine Operator を使用して、クラスターライフサイクル管理用の次の API にアクセスできます。ユーザーに必要なアクセス権: ロールが割り当てられているアクションのみを実行できます。
注: 統合コンソールからすべての API にアクセスすることもできます。local-cluster ビューから、Home > API Explorer に移動して、API グループを確認します。
詳細は、以下の各リソースに関する API のドキュメントを参照してください。
1.11.1. Clusters API
非推奨: API のドキュメントは非推奨となりました。現在のサポートされている API を表示するには、コンソールの API Explorer または oc コマンドを使用します。
1.11.1.1. 概要
このドキュメントは、multicluster engine for Kubernetes Operator の Cluster リソースに関するものです。Cluster リソースには、create、query、delete、update の 4 つの要求を使用できます。
1.11.1.1.1. URI スキーム
BasePath: /kubernetes/apis
Schemes: HTTPS
1.11.1.1.2. タグ
- cluster.open-cluster-management.io: クラスターを作成して管理します。
1.11.1.2. パス
1.11.1.2.1. 全クラスターのクエリー
GET /cluster.open-cluster-management.io/v1/managedclusters
GET /cluster.open-cluster-management.io/v1/managedclusters1.11.1.2.1.1. 説明
クラスターに対してクエリーを実行して詳細を確認します。
1.11.1.2.1.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
1.11.1.2.1.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.1.2.1.4. 消費されるアイテム
-
cluster/yaml
1.11.1.2.1.5. タグ
- cluster.open-cluster-management.io
1.11.1.2.2. クラスターの作成
POST /cluster.open-cluster-management.io/v1/managedclusters
POST /cluster.open-cluster-management.io/v1/managedclusters1.11.1.2.2.1. 説明
クラスターの作成
1.11.1.2.2.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Body |
body | 作成するクラスターを記述するパラメーター |
1.11.1.2.2.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.1.2.2.4. 消費されるアイテム
-
cluster/yaml
1.11.1.2.2.5. タグ
- cluster.open-cluster-management.io
1.11.1.2.2.6. HTTP リクエストの例
1.11.1.2.2.6.1. リクエストのボディー
1.11.1.2.3. 単一クラスターのクエリー
GET /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}
GET /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}1.11.1.2.3.1. 説明
1 つのクラスターに対してクエリーを実行して詳細を確認します。
1.11.1.2.3.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
cluster_name | 問い合わせるクラスターの名前。 | string |
1.11.1.2.3.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.1.2.3.4. タグ
- cluster.open-cluster-management.io
1.11.1.2.4. クラスターの削除
DELETE /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}
DELETE /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}1.11.1.2.4.1. 説明
単一クラスターを削除します。
1.11.1.2.4.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
cluster_name | 削除するクラスターの名前。 | string |
1.11.1.2.4.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.1.2.4.4. タグ
- cluster.open-cluster-management.io
1.11.1.3. 定義
1.11.1.3.1. クラスター
| 名前 | スキーマ |
|---|---|
|
apiVersion | string |
|
kind | string |
|
metadata | object |
|
spec |
spec
| 名前 | スキーマ |
|---|---|
|
hubAcceptsClient | bool |
|
managedClusterClientConfigs | < managedClusterClientConfigs > array |
|
leaseDurationSeconds | integer (int32) |
managedClusterClientConfigs
| 名前 | 説明 | スキーマ |
|---|---|---|
|
URL | string | |
|
CABundle | Pattern: "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$"
| string (バイト) |
1.11.2. Clustersets API (v1beta2)
非推奨: API のドキュメントは非推奨となりました。現在のサポートされている API を表示するには、コンソールの API Explorer または oc コマンドを使用します。
1.11.2.1. 概要
このドキュメントは、multicluster engine for Kubernetes Operator の Clusterset リソースに関するものです。Clusterset リソースには、create、query、delete、update の 4 つの要求を使用できます。
1.11.2.1.1. URI スキーム
BasePath: /kubernetes/apis
Schemes: HTTPS
1.11.2.1.2. タグ
- cluster.open-cluster-management.io: Clustersets を作成して管理します。
1.11.2.2. パス
1.11.2.2.1. 全 clusterset のクエリー
GET /cluster.open-cluster-management.io/v1beta2/managedclustersets
GET /cluster.open-cluster-management.io/v1beta2/managedclustersets1.11.2.2.1.1. 説明
Clustersets に対してクエリーを実行して詳細を確認します。
1.11.2.2.1.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
1.11.2.2.1.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.2.2.1.4. 消費されるアイテム
-
clusterset/yaml
1.11.2.2.1.5. タグ
- cluster.open-cluster-management.io
1.11.2.2.2. clusterset の作成
POST /cluster.open-cluster-management.io/v1beta2/managedclustersets
POST /cluster.open-cluster-management.io/v1beta2/managedclustersets1.11.2.2.2.1. 説明
Clusterset を作成します。
1.11.2.2.2.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Body |
body | 作成する clusterset を記述するパラメーター |
1.11.2.2.2.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.2.2.2.4. 消費されるアイテム
-
clusterset/yaml
1.11.2.2.2.5. タグ
- cluster.open-cluster-management.io
1.11.2.2.2.6. HTTP リクエストの例
1.11.2.2.2.6.1. リクエストのボディー
1.11.2.2.3. 単一 clusterset のクエリー
GET /cluster.open-cluster-management.io/v1beta2/managedclustersets/{clusterset_name}
GET /cluster.open-cluster-management.io/v1beta2/managedclustersets/{clusterset_name}1.11.2.2.3.1. 説明
単一の clusterset に対してクエリーを実行して詳細を確認します。
1.11.2.2.3.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
clusterset_name | 問い合わせる clusterset の名前。 | string |
1.11.2.2.3.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.2.2.3.4. タグ
- cluster.open-cluster-management.io
1.11.2.2.4. clusterset の削除
DELETE /cluster.open-cluster-management.io/v1beta2/managedclustersets/{clusterset_name}
DELETE /cluster.open-cluster-management.io/v1beta2/managedclustersets/{clusterset_name}1.11.2.2.4.1. 説明
単一 clusterset を削除します。
1.11.2.2.4.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
clusterset_name | 削除する clusterset の名前。 | string |
1.11.2.2.4.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.2.2.4.4. タグ
- cluster.open-cluster-management.io
1.11.2.3. 定義
1.11.2.3.1. Clusterset
| 名前 | スキーマ |
|---|---|
|
apiVersion | string |
|
kind | string |
|
metadata | object |
1.11.3. Clustersetbindings API (v1beta2)
非推奨: API のドキュメントは非推奨となりました。現在のサポートされている API を表示するには、コンソールの API Explorer または oc コマンドを使用します。
1.11.3.1. 概要
このドキュメントは、Kubernetes のマルチクラスターエンジンの clustersetbinding リソースを対象としています。Clustersetbinding リソースには、create、query、delete、update の 4 つの要求を使用できます。
1.11.3.1.1. URI スキーム
BasePath: /kubernetes/apis
Schemes: HTTPS
1.11.3.1.2. タグ
- cluster.open-cluster-management.io: clustersetbinding を作成して管理します。
1.11.3.2. パス
1.11.3.2.1. 全 clustersetbinding のクエリー
GET /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings
GET /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings1.11.3.2.1.1. 説明
clustersetbinding に対してクエリーを実行して詳細を確認します。
1.11.3.2.1.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
namespace | 使用する namespace (例: default) | string |
1.11.3.2.1.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.3.2.1.4. 消費されるアイテム
-
clustersetbinding/yaml
1.11.3.2.1.5. タグ
- cluster.open-cluster-management.io
1.11.3.2.2. clustersetbinding の作成
POST /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings
POST /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings1.11.3.2.2.1. 説明
clustersetbinding を作成します。
1.11.3.2.2.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
namespace | 使用する namespace (例: default) | string |
| Body |
body | 作成する clustersetbinding を記述するパラメーター |
1.11.3.2.2.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.3.2.2.4. 消費されるアイテム
-
clustersetbinding/yaml
1.11.3.2.2.5. タグ
- cluster.open-cluster-management.io
1.11.3.2.2.6. HTTP リクエストの例
1.11.3.2.2.6.1. リクエストのボディー
1.11.3.2.3. 単一 clustersetbinding のクエリー
GET /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings/{clustersetbinding_name}
GET /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings/{clustersetbinding_name}1.11.3.2.3.1. 説明
単一の clustersetbinding に対してクエリーを実行して詳細を確認します。
1.11.3.2.3.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
namespace | 使用する namespace (例: default) | string |
| Path |
clustersetbinding_name | 問い合わせる clustersetbinding の名前 | string |
1.11.3.2.3.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.3.2.3.4. タグ
- cluster.open-cluster-management.io
1.11.3.2.4. clustersetbinding の削除
DELETE /cluster.open-cluster-management.io/v1beta2/managedclustersetbindings/{clustersetbinding_name}
DELETE /cluster.open-cluster-management.io/v1beta2/managedclustersetbindings/{clustersetbinding_name}1.11.3.2.4.1. 説明
単一 clustersetbinding を削除します。
1.11.3.2.4.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
namespace | 使用する namespace (例: default) | string |
| Path |
clustersetbinding_name | 削除する clustersetbinding の名前 | string |
1.11.3.2.4.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.3.2.4.4. タグ
- cluster.open-cluster-management.io
1.11.3.3. 定義
1.11.3.3.1. Clustersetbinding
| 名前 | スキーマ |
|---|---|
|
apiVersion | string |
|
kind | string |
|
metadata | object |
|
spec |
spec
| 名前 | スキーマ |
|---|---|
|
clusterSet | string |
1.11.4. Clusterview API (v1alpha1)
非推奨: API のドキュメントは非推奨となりました。現在のサポートされている API を表示するには、コンソールの API Explorer または oc コマンドを使用します。
1.11.4.1. 概要
このドキュメントは、Kubernetes のマルチクラスターエンジンの clusterview リソースを対象としています。clusterview リソースには、アクセス可能なマネージドクラスターおよびマネージドクラスターセットのリストを表示できる CLI コマンドが含まれます。使用できる要求は、list、get、および watch の 3 つです。
1.11.4.1.1. URI スキーム
BasePath: /kubernetes/apis
Schemes: HTTPS
1.11.4.1.2. タグ
- clusterview.open-cluster-management.io: お使いの ID がアクセスできるマネージドクラスターのリストを表示します。
1.11.4.2. パス
1.11.4.2.1. マネージドクラスターの取得
GET /managedclusters.clusterview.open-cluster-management.io
GET /managedclusters.clusterview.open-cluster-management.io1.11.4.2.1.1. 説明
アクセス可能なマネージドクラスターのリストを表示します。
1.11.4.2.1.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
1.11.4.2.1.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.4.2.1.4. 消費されるアイテム
-
managedcluster/yaml
1.11.4.2.1.5. タグ
- clusterview.open-cluster-management.io
1.11.4.2.2. マネージドクラスターのリスト表示
LIST /managedclusters.clusterview.open-cluster-management.io
LIST /managedclusters.clusterview.open-cluster-management.io1.11.4.2.2.1. 説明
アクセス可能なマネージドクラスターのリストを表示します。
1.11.4.2.2.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Body |
body | マネージドクラスターをリスト表示するユーザー ID の名前 | string |
1.11.4.2.2.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.4.2.2.4. 消費されるアイテム
-
managedcluster/yaml
1.11.4.2.2.5. タグ
- clusterview.open-cluster-management.io
1.11.4.2.2.6. HTTP リクエストの例
1.11.4.2.2.6.1. リクエストのボディー
1.11.4.2.3. マネージドクラスターセットの監視
WATCH /managedclusters.clusterview.open-cluster-management.io
WATCH /managedclusters.clusterview.open-cluster-management.io1.11.4.2.3.1. 説明
アクセス可能なマネージドクラスターを確認します。
1.11.4.2.3.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
clusterview_name | 監視するユーザー ID の名前 | string |
1.11.4.2.3.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.4.2.4. マネージドクラスターセットのリスト表示
GET /managedclustersets.clusterview.open-cluster-management.io
GET /managedclustersets.clusterview.open-cluster-management.io1.11.4.2.4.1. 説明
アクセス可能なマネージドクラスターをリスト表示します。
1.11.4.2.4.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
clusterview_name | 監視するユーザー ID の名前 | string |
1.11.4.2.4.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.4.2.5. マネージドクラスターセットのリスト表示
LIST /managedclustersets.clusterview.open-cluster-management.io
LIST /managedclustersets.clusterview.open-cluster-management.io1.11.4.2.5.1. 説明
アクセス可能なマネージドクラスターをリスト表示します。
1.11.4.2.5.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
clusterview_name | 監視するユーザー ID の名前 | string |
1.11.4.2.5.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.4.2.6. マネージドクラスターセットの監視
WATCH /managedclustersets.clusterview.open-cluster-management.io
WATCH /managedclustersets.clusterview.open-cluster-management.io1.11.4.2.6.1. 説明
アクセス可能なマネージドクラスターを確認します。
1.11.4.2.6.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
clusterview_name | 監視するユーザー ID の名前 | string |
1.11.4.2.6.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.5. ManagedServiceAccount API (v1alpha1) (非推奨)
非推奨: API のドキュメントは非推奨となりました。現在のサポートされている API を表示するには、コンソールの API Explorer または oc コマンドを使用します。
1.11.5.1. 概要
このドキュメントは、multicluster engine Operator の ManagedServiceAccount リソースに関するものです。ManagedServiceAccount リソースには、create、query、delete、update の 4 つのリクエストがあります。
非推奨: v1alpha1 API は非推奨になりました。最適な結果を得るには、代わりに v1beta1 を使用します。
1.11.5.1.1. URI スキーム
BasePath: /kubernetes/apis
Schemes: HTTPS
1.11.5.1.2. タグ
-
managedserviceaccounts.authentication.open-cluster-management.io`:ManagedServiceAccountsの作成と管理
1.11.5.2. パス
1.11.5.2.1. ManagedServiceAccount を作成する
POST /authentication.open-cluster-management.io/v1beta1/managedserviceaccounts
POST /authentication.open-cluster-management.io/v1beta1/managedserviceaccounts1.11.5.2.1.1. 説明
ManagedServiceAccount を作成します。
1.11.5.2.1.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Body |
body | 作成する ManagedServiceAccount を説明するパラメーター。 | ManagedServiceAccount |
1.11.5.2.1.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.5.2.1.4. 消費されるアイテム
-
managedserviceaccount/yaml
1.11.5.2.1.5. タグ
- managedserviceaccounts.authentication.open-cluster-management.io
1.11.5.2.1.5.1. リクエストのボディー
1.11.5.2.2. 単一の ManagedServiceAccount をクエリーする
GET /authentication.open-cluster-management.io/v1beta1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}
GET /authentication.open-cluster-management.io/v1beta1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}1.11.5.2.2.1. 説明
詳細は、単一の ManagedServiceAccount を照会してください。
1.11.5.2.2.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
managedserviceaccount_name |
照会する | string |
1.11.5.2.2.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.5.2.2.4. タグ
- managedserviceaccounts.authentication.open-cluster-management.io
1.11.5.2.3. ManagedServiceAccount を削除する
DELETE /authentication.open-cluster-management.io/v1beta1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}
DELETE /authentication.open-cluster-management.io/v1beta1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}1.11.5.2.3.1. 説明
単一の ManagedServiceAccount を削除します。
1.11.5.2.3.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
managedserviceaccount_name |
削除する | string |
1.11.5.2.3.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.5.2.3.4. タグ
- managedserviceaccounts.authentication.open-cluster-management.io
1.11.5.3. 定義
1.11.5.3.1. ManagedServiceAccount
| 名前 | 説明 | スキーマ |
|---|---|---|
|
apiVersion |
| string |
|
kind | REST リソースを表す文字列の値 | string |
|
metadata |
| object |
|
spec |
|
1.11.6. MultiClusterEngine API (v1alpha1)
非推奨: API のドキュメントは非推奨となりました。現在のサポートされている API を表示するには、コンソールの API Explorer または oc コマンドを使用します。
1.11.6.1. 概要
このドキュメントは、Kubernetes のマルチクラスターエンジン用の MultiClusterEngine リソースを対象としています。MultiClusterEngine リソースには、create、query、delete、update の 4 つのリクエストがあります。
1.11.6.1.1. URI スキーム
BasePath: /kubernetes/apis
Schemes: HTTPS
1.11.6.1.2. タグ
- multiclusterengines.multicluster.openshift.io : MultiClusterEngine を作成および管理します。
1.11.6.2. パス
1.11.6.2.1. MultiClusterEngine を作成する
POST /apis/multicluster.openshift.io/v1alpha1/multiclusterengines
POST /apis/multicluster.openshift.io/v1alpha1/multiclusterengines1.11.6.2.1.1. 説明
MultiClusterEngine を作成します。
1.11.6.2.1.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Body |
body | 作成する MultiClusterEngine を説明するパラメーター。 | MultiClusterEngine |
1.11.6.2.1.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.6.2.1.4. 消費されるアイテム
-
MultiClusterEngines/yaml
1.11.6.2.1.5. タグ
- multiclusterengines.multicluster.openshift.io
1.11.6.2.1.5.1. リクエストのボディー
1.11.6.2.2. すべての MultiClusterEngine をクエリーする
GET /apis/multicluster.openshift.io/v1alpha1/multiclusterengines
GET /apis/multicluster.openshift.io/v1alpha1/multiclusterengines1.11.6.2.2.1. 説明
詳細は、マルチクラスターエンジンに問い合わせてください。
1.11.6.2.2.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
1.11.6.2.2.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.6.2.2.4. 消費されるアイテム
-
operator/yaml
1.11.6.2.2.5. タグ
- multiclusterengines.multicluster.openshift.io
1.11.6.2.3. MultiClusterEngine Operator の削除
DELETE /apis/multicluster.openshift.io/v1alpha1/multiclusterengines/{name}
DELETE /apis/multicluster.openshift.io/v1alpha1/multiclusterengines/{name}1.11.6.2.3.1. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
name | 削除するマルチクラスターエンジンの名前。 | string |
1.11.6.2.3.2. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.6.2.3.3. タグ
- multiclusterengines.multicluster.openshift.io
1.11.6.3. 定義
1.11.6.3.1. MultiClusterEngine
| 名前 | 説明 | スキーマ |
|---|---|---|
|
apiVersion | MultiClusterEngines のバージョン管理されたスキーマ。 | string |
|
kind | REST リソースを表す文字列の値 | string |
|
metadata | リソースを定義するルールを記述します。 | object |
|
spec | MultiClusterEngineSpec は、MultiClusterEngine の望ましい状態を定義します。 | 仕様のリスト を参照してください。 |
1.11.6.3.2. 仕様のリスト
| 名前 | 説明 | スキーマ |
|---|---|---|
|
nodeSelector | nodeselectors を設定します。 | map[string]string |
|
imagePullSecret | MultiClusterEngine オペランドおよびエンドポイントイメージにアクセスするためのプルシークレットをオーバーライドします。 | string |
|
tolerations | 許容範囲により、すべてのコンポーネントがあらゆる taint を許容します。 | []corev1.Toleration |
|
targetNamespace | MCE リソースが配置される場所。 | string |
1.11.7. Placements API (v1beta1)
非推奨: API のドキュメントは非推奨となりました。現在のサポートされている API を表示するには、コンソールの API Explorer または oc コマンドを使用します。
1.11.7.1. 概要
このドキュメントは、multicluster engine for Kubernetes の Placement リソースに関するものです。Placement リソースには、create、query、delete、update の 4 つの要求を使用できます。
1.11.7.1.1. URI スキーム
BasePath: /kubernetes/apis
Schemes: HTTPS
1.11.7.1.2. タグ
- cluster.open-cluster-management.io: Placement を作成して管理します。
1.11.7.2. パス
1.11.7.2.1. 全 Placement のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements1.11.7.2.1.1. 説明
Placement に対してクエリーを実行して詳細を確認します。
1.11.7.2.1.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
1.11.7.2.1.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.7.2.1.4. 消費されるアイテム
-
placement/yaml
1.11.7.2.1.5. タグ
- cluster.open-cluster-management.io
1.11.7.2.2. Placement の作成
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements1.11.7.2.2.1. 説明
Placement を作成します。
1.11.7.2.2.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Body |
body | 作成する placement を記述するパラメーター |
1.11.7.2.2.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.7.2.2.4. 消費されるアイテム
-
placement/yaml
1.11.7.2.2.5. タグ
- cluster.open-cluster-management.io
1.11.7.2.2.6. HTTP リクエストの例
1.11.7.2.2.6.1. リクエストのボディー
1.11.7.2.3. 単一の Placement のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}1.11.7.2.3.1. 説明
1 つの Placement に対してクエリーを実行して詳細を確認します。
1.11.7.2.3.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
placement_name | 問い合わせる Placement の名前 | string |
1.11.7.2.3.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.7.2.3.4. タグ
- cluster.open-cluster-management.io
1.11.7.2.4. Placement の削除
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}1.11.7.2.4.1. 説明
単一の Placement を削除します。
1.11.7.2.4.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
placement_name | 削除する Placement の名前 | string |
1.11.7.2.4.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.7.2.4.4. タグ
- cluster.open-cluster-management.io
1.11.7.3. 定義
1.11.7.3.1. Placement
| 名前 | 説明 | スキーマ |
|---|---|---|
|
apiVersion | Placement のバージョンスキーマ | string |
|
kind | REST リソースを表す文字列の値 | string |
|
metadata | Placement のメタデータ | object |
|
spec | Placement の仕様 |
spec
| 名前 | 説明 | スキーマ |
|---|---|---|
|
ClusterSets | ManagedClusters を選択する ManagedClusterSets のサブセット。空白の場合には、Placement namespace にバインドされる ManagedClusterSets から ManagedClusters が選択されます。それ以外の場合は、ManagedClusters がこのサブセットの交差部分から選択され、ManagedClusterSets は Placement namespace にバインドされます。 | string array |
|
numberOfClusters | 選択する ManagedClusters の必要数 | integer (int32) |
|
predicates | ManagedClusters を選択するクラスター述語のサブセット。条件ロジックは OR です。 | clusterPredicate アレイ |
clusterPredicate
| 名前 | 説明 | スキーマ |
|---|---|---|
|
requiredClusterSelector | ラベルおよびクラスター要求のある ManagedClusters を選択するクラスターセレクター |
clusterSelector
| 名前 | 説明 | スキーマ |
|---|---|---|
|
labelSelector | ラベル別の ManagedClusters のセレクター | object |
|
claimSelector | 要求別の ManagedClusters のセレクター |
clusterClaimSelector
| 名前 | 説明 | スキーマ |
|---|---|---|
|
matchExpressions | クラスター要求のセレクター要件のサブセット。条件ロジックは AND です。 | < オブジェクト > 配列 |
1.11.8. PlacementDecisions API (v1beta1)
非推奨: API のドキュメントは非推奨となりました。現在のサポートされている API を表示するには、コンソールの API Explorer または oc コマンドを使用します。
1.11.8.1. 概要
このドキュメントは、Kubernetes のマルチクラスターエンジンの PlacementDecision リソースを対象としています。PlacementDecision リソースには、create、query、delete、update の 4 つの要求を使用できます。
1.11.8.1.1. URI スキーム
BasePath: /kubernetes/apis
Schemes: HTTPS
1.11.8.1.2. タグ
- cluster.open-cluster-management.io: PlacementDecision を作成して管理します。
1.11.8.2. パス
1.11.8.2.1. 全 PlacementDecision のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions1.11.8.2.1.1. 説明
PlacementDecisions に対してクエリーを実行して詳細を確認します。
1.11.8.2.1.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
1.11.8.2.1.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.8.2.1.4. 消費されるアイテム
-
placementdecision/yaml
1.11.8.2.1.5. タグ
- cluster.open-cluster-management.io
1.11.8.2.2. PlacementDecision の作成
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions1.11.8.2.2.1. 説明
PlacementDecision を作成します。
1.11.8.2.2.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Body |
body | 作成する PlacementDecision を記述するパラメーター |
1.11.8.2.2.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.8.2.2.4. 消費されるアイテム
-
placementdecision/yaml
1.11.8.2.2.5. タグ
- cluster.open-cluster-management.io
1.11.8.2.2.6. HTTP リクエストの例
1.11.8.2.2.6.1. リクエストのボディー
1.11.8.2.3. 単一の PlacementDecision のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}1.11.8.2.3.1. 説明
1 つの PlacementDecision に対してクエリーを実行して詳細を確認します。
1.11.8.2.3.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
placementdecision_name | 問い合わせる PlacementDecision の名前 | string |
1.11.8.2.3.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.8.2.3.4. タグ
- cluster.open-cluster-management.io
1.11.8.2.4. PlacementDecision の削除
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}1.11.8.2.4.1. 説明
単一の PlacementDecision を削除します。
1.11.8.2.4.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
placementdecision_name | 削除する PlacementDecision の名前 | string |
1.11.8.2.4.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.8.2.4.4. タグ
- cluster.open-cluster-management.io
1.11.8.3. 定義
1.11.8.3.1. PlacementDecision
| 名前 | 説明 | スキーマ |
|---|---|---|
|
apiVersion | PlacementDecision のバージョンスキーマ | string |
|
kind | REST リソースを表す文字列の値 | string |
|
metadata | PlacementDecision のメタデータ | object |
1.11.9. KlusterletConfig API (v1alpha1)
非推奨: API のドキュメントは非推奨となりました。現在のサポートされている API を表示するには、コンソールの API Explorer または oc コマンドを使用します。
1.11.9.1. 概要
このドキュメントは、multicluster engine for Kubernetes Operator の KlusterletConfig リソースに関するものです。KlusterletConfig リソースは、Klusterlet のインストールを設定するために使用されます。使用できる要求は、create、query、delete、update の 4 つです。
1.11.9.1.1. URI スキーム
BasePath: /kubernetes/apis
Schemes: HTTPS
1.11.9.1.2. タグ
- klusterletconfigs.config.open-cluster-management.io : klusterletconfigs の作成と管理
1.11.9.2. パス
1.11.9.2.1. 全 KlusterletConfig のクエリー
GET /config.open-cluster-management.io/v1alpha1/klusterletconfigs
GET /config.open-cluster-management.io/v1alpha1/klusterletconfigs1.11.9.2.1.1. 説明
すべての KlusterletConfig に対してクエリーを実行して詳細を確認します。
1.11.9.2.1.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
1.11.9.2.1.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | KlusterletConfig yaml |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.9.2.1.4. 消費されるアイテム
-
klusterletconfig/yaml
1.11.9.2.1.5. タグ
-
klusterletconfigs.config.open-cluster-management.io
1.11.9.2.2. KlusterletConfig を作成します。
POST /config.open-cluster-management.io/v1alpha1/klusterletconfigs
POST /config.open-cluster-management.io/v1alpha1/klusterletconfigs1.11.9.2.2.1. 説明
KlusterletConfig を作成します。
1.11.9.2.2.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Body |
body | 作成する KlusterletConfig を記述するパラメーター。 |
1.11.9.2.2.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.9.2.2.4. 消費されるアイテム
-
klusterletconfig/yaml
1.11.9.2.2.5. タグ
- klusterletconfigs.config.open-cluster-management.io
1.11.9.2.2.6. HTTP リクエストの例
1.11.9.2.2.6.1. リクエストのボディー
1.11.9.2.3. 1 つの klusterletconfig のクエリー
GET /config.open-cluster-management.io/v1alpha1/klusterletconfigs/{klusterletconfig_name}
GET /config.open-cluster-management.io/v1alpha1/klusterletconfigs/{klusterletconfig_name}1.11.9.2.3.1. 説明
1 つの KlusterletConfig に対してクエリーを実行して詳細を確認します。
1.11.9.2.3.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
klusterletconfig_name | クエリーを実行する klusterletconfig の名前。 | string |
1.11.9.2.3.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 |
|
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.9.2.3.4. タグ
- klusterletconfigs.config.open-cluster-management.io
1.11.9.2.4. klusterletconfig の削除
DELETE /config.open-cluster-management.io/v1alpha1/klusterletconfigs/{klusterletconfig_name}
DELETE /config.open-cluster-management.io/v1alpha1/klusterletconfigs/{klusterletconfig_name}1.11.9.2.4.1. 説明
1 つの KlusterletConfig を削除します。
1.11.9.2.4.2. パラメーター
| 型 | 名前 | 説明 | スキーマ |
|---|---|---|---|
| Header |
COOKIE | Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。 | string |
| Path |
klusterletconfig_name | 削除する klusterletconfig の名前。 | string |
1.11.9.2.4.3. レスポンス
| HTTP コード | 説明 | スキーマ |
|---|---|---|
| 200 | 成功 | コンテンツなし |
| 403 | アクセス禁止 | コンテンツなし |
| 404 | リソースが見つからない | コンテンツなし |
| 500 | 内部サービスエラー | コンテンツなし |
| 503 | サービスが利用できない | コンテンツなし |
1.11.9.2.4.4. タグ
- klusterletconfig.authentication.open-cluster-management.io
1.11.9.3. 定義
1.11.9.3.1. klusterletconfig
| 名前 | 説明 | スキーマ |
|---|---|---|
|
apiVersion | klusterletconfig のバージョン管理されたスキーマ。 | string |
|
kind | REST リソースを表す文字列の値 | string |
|
metadata |
| object |
|
spec |
|
1.12. トラブルシューティング
トラブルシューティングガイドをご使用の前に oc adm must-gather コマンドを実行して、詳細およびログを収集し、問題のデバッグ手順を行います。詳細は、must-gather コマンドを実行したトラブルシューティング を参照してください。
また、ロールベースのアクセス権限を確認してください。詳細は、multicluster engine Operator のロールベースのアクセス制御 を参照してください。
1.12.1. 文書化されたトラブルシューティング
multicluster engine Operator のトラブルシューティングトピックのリストをご覧ください。
インストール:
インストールタスクに関する主なドキュメントを確認するには、multicluster engine Operator のインストールとアップグレード を参照してください。
クラスター管理:
クラスターの管理に関する主要なドキュメントを表示するには、クラスターライフサイクルの概要 を参照してください。
- トラブルシューティング: 既存のクラスターに Day 2 ノードを追加すると、ユーザーアクションが保留中になり失敗する
- オフラインクラスターのトラブルシューティング
- マネージドクラスターのインポート失敗に関するトラブルシューティング
- クラスターの再インポートが不明な権限エラーで失敗する
- Pending Import ステータスのクラスターのトラブルシューティング
- 証明書を変更した後のインポート済みクラスターのオフラインでのトラブルシューティング
- クラスターのステータスが offline から available に変わる場合のトラブルシューティング
- VMware vSphere でのクラスター作成のトラブルシューティング
- ステータスが Pending または Failed のクラスターのコンソールでのトラブルシューティング
- degraded 状態にある Klusterlet のトラブルシューティング
- クラスターの削除後も namespace が残る
- クラスターのインポート時の auto-import-secret-exists エラー
- Troubleshooting missing PlacementDecision after creating Placement
- Dell ハードウェアにおけるベアメタルホストの検出エラーのトラブルシューティング
- 最小限の ISO の起動失敗に関するトラブルシューティング
- Hosted Control Plane クラスターで Red Hat OpenShift Service on AWS でマネージドクラスターが Unknown になる問題トラブルシューティング
- OpenShift Container Platform バージョンが欠落しているマネージドクラスターのアップグレード試行のトラブルシューティング
- Hive および Assisted Installer クラスターでの認証局更新エラーのトラブルシューティング
1.12.2. must-gather コマンドを実行したトラブルシューティング
トラブルシューティングを開始するには、問題のデバッグを行う must-gather コマンドを実行する場合のトラブルシューティングシナリオを確認し、このコマンドの使用を開始する手順を参照してください。
必要なアクセス権: クラスター管理者
1.12.2.1. Must-gather のシナリオ
シナリオ 1: 文書化されたトラブルシューティング セクションを使用して、問題の解決策がまとめられているかどうかを確認します。このガイドは、製品の主な機能別に設定されています。
このシナリオでは、解決策がこのドキュメントにまとめられているかどうかを、このガイドで確認します。
-
シナリオ 2: 問題の解決策の手順が文書にまとめられていない場合は、
must-gatherコマンドを実行し、その出力を使用して問題をデバッグします。 -
シナリオ 3:
must-gatherコマンドの出力を使用して問題をデバッグできない場合は、出力を Red Hat サポートに共有します。
1.12.2.2. Must-gather の手順
must-gather コマンドの使用を開始するには、以下の手順を参照してください。
-
OpenShift Container Platform ドキュメントの クラスターに関するデータの収集 で、
must-gatherコマンドを確認し、必要なものをインストールします。 クラスターにログインします。通常のユースケースでは、engine クラスターにログインして、
must-gatherを実行する必要があります。注記: マネージドクラスターを確認する場合は、
cluster-scoped-resourcesディレクトリーにあるgather-managed.logファイルを検索します。<your-directory>/cluster-scoped-resources/gather-managed.log>
<your-directory>/cluster-scoped-resources/gather-managed.log>Copy to Clipboard Copied! Toggle word wrap Toggle overflow JOINED および AVAILABLE 列に
Trueが設定されていないマネージドクラスターがないかを確認します。must-gatherコマンドは、ステータスがTrueとして関連付けられていないクラスター上で、実行できます。- データとディレクトリーの収集に使用される Kubernetes イメージのマルチクラスターエンジンを追加します。以下のコマンドを実行します。
oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:v2.8 --dest-dir=<directory>
oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:v2.8 --dest-dir=<directory>指定したディレクトリーに移動し、以下のレベルに整理されている出力を確認します。
-
ピアレベル 2 つ:
cluster-scoped-resourcesとnamespaceのリソース - それぞれに対するサブレベル: クラスタースコープおよび namespace スコープの両方のリソースに対するカスタムリソース定義の API グループ。
-
それぞれに対する次のレベル:
kindでソートされた YAML ファイル
-
ピアレベル 2 つ:
1.12.2.3. 非接続環境での must-gather
非接続環境で must-gather コマンドを実行するには、次の手順を実行します。
- 非接続環境では、Red Hat Operator のカタログイメージをミラーレジストリーにミラーリングします。詳細は、ネットワーク切断状態でのインストール を参照してください。
-
次のコマンドを実行して、ミラーレジストリーからイメージを参照するログを抽出します。
sha256はｍ現在のイメージに置き換えます。
REGISTRY=registry.example.com:5000 IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel9@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8> oc adm must-gather --image=$IMAGE --dest-dir=./data
REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel9@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8>
oc adm must-gather --image=$IMAGE --dest-dir=./dataここ で製品チーム向けの Jira バグを作成できます。
1.12.3. トラブルシューティング: 既存のクラスターに Day 2 ノードを追加すると、ユーザーアクションが保留中になり失敗する
インストール中に、ゼロタッチプロビジョニング方式またはホストインベントリー作成方式を使用して、multicluster engine for Kubernetes Operator によって作成された既存のクラスターに、ノードを追加したりスケールアウトしたりすることできません。インストールプロセスは、検出フェーズでは正しく機能しますが、インストールフェーズでは失敗します。
ネットワークの設定に失敗しています。統合コンソールのハブクラスターから、Pending のユーザーアクションが表示されます。説明から、再起動ステップで失敗していることがわかります。
インストールするホストで実行されているエージェントは情報を報告できないため、失敗に関するエラーメッセージはあまり正確ではありません。
1.12.3.1. 現象: Day 2 ワーカーのインストールが失敗する
検出フェーズの後、ホストは再起動してインストールを続行しますが、ネットワークを設定できません。以下の現象およびメッセージを確認します。
統合コンソールのハブクラスターから、追加ノード上で
Pendingユーザーアクションがないか、Rebootingインジケーターが付いているかどうかを確認します。This host is pending user action. Host timed out when pulling ignition. Check the host console... Rebooting
This host is pending user action. Host timed out when pulling ignition. Check the host console... RebootingCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat OpenShift Container Platform 設定のマネージドクラスターから、既存のクラスターの
MachineConfigを確認します。MachineConfigのいずれかが次のディレクトリーにファイルを作成しているかどうかを確認します。-
/sysroot/etc/NetworkManager/system-connections/ -
/sysroot/etc/sysconfig/network-scripts/
-
-
インストールするホストの端末から、障害が発生したホストに次のメッセージが表示されているかどうかを確認します。
journalctlを使用してログメッセージを確認できます。
info: networking config is defined in the real root info: will not attempt to propagate initramfs networking
info: networking config is defined in the real root
info: will not attempt to propagate initramfs networkingログに最後のメッセージが表示された場合、現象 に記載されているフォルダーで既存のネットワーク設定がすでに見つかっているため、ネットワーク設定は伝播されません。
1.12.3.2. 問題の解決: ネットワーク設定をマージするノードを再作成します。
インストール中に適切なネットワーク設定を使用するには、次のタスクを実行します。
- ハブクラスターからノードを削除します。
- 同じようにノードをインストールするには、前のプロセスを繰り返します。
次のアノテーションを使用してノードの
BareMetalHostオブジェクトを作成します。"bmac.agent-install.openshift.io/installer-args": "[\"--append-karg\", \"coreos.force_persist_ip\"]"
"bmac.agent-install.openshift.io/installer-args": "[\"--append-karg\", \"coreos.force_persist_ip\"]"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ノードがインストールを開始します。検出フェーズの後、ノードは既存のクラスター上の変更と初期設定の間でネットワーク設定をマージします。
1.12.4. エージェントプラットフォーム上の Hosted Control Plane クラスター削除失敗のトラブルシューティング
エージェントプラットフォーム上の Hosted Control Plane クラスターを破棄すると、通常、すべてのバックエンドリソースが削除されます。マシンリソースが正しく削除されていない場合、クラスターの削除が失敗します。この場合、残りのマシンリソースを手動で削除する必要があります。
1.12.4.1. 現象: Hosted Control Plane クラスターを破棄するとエラーが発生する
エージェントプラットフォーム上の Hosted Control Plane クラスターを破棄しようとすると、hcp destroy コマンドが次のエラーで失敗します。
+
2024-02-22T09:56:19-05:00 ERROR HostedCluster deletion failed {"namespace": "clusters", "name": "hosted-0", "error": "context deadline exceeded"}
2024-02-22T09:56:19-05:00 ERROR Failed to destroy cluster {"error": "context deadline exceeded"}
2024-02-22T09:56:19-05:00 ERROR HostedCluster deletion failed {"namespace": "clusters", "name": "hosted-0", "error": "context deadline exceeded"}
2024-02-22T09:56:19-05:00 ERROR Failed to destroy cluster {"error": "context deadline exceeded"}1.12.4.2. 問題の解決: 残りのマシンリソースを手動で削除する
エージェントプラットフォーム上の Hosted Control Plane クラスターを正常に破棄するには、次の手順を実行します。
次のコマンドを実行して、残りのマシンリソースのリストを表示します。
<hosted_cluster_namespace>は、ホステッドクラスターの namespace の名前に置き換えます。oc get machine -n <hosted_cluster_namespace>
oc get machine -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の出力例を参照してください。
NAMESPACE NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION clusters-hosted-0 hosted-0-9gg8b hosted-0-nhdbp Deleting 10h <4.x.0>-rc.8
NAMESPACE NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION clusters-hosted-0 hosted-0-9gg8b hosted-0-nhdbp Deleting 10h <4.x.0>-rc.8Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マシンリソースに割り当てられている
machine.cluster.x-k8s.ioファイナライザーを削除します。oc edit machines -n <hosted_cluster_namespace>
oc edit machines -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ターミナルに
No resources foundというメッセージが表示されることを確認します。oc get agentmachine -n <hosted_cluster_namespace>
oc get agentmachine -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、エージェントプラットフォーム上の Hosted Control Plane クラスターを破棄します。
hcp destroy cluster agent --name <cluster_name>
hcp destroy cluster agent --name <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <cluster_name>は、クラスター名に置き換えます。
1.12.5. インストールステータスがインストールまたは保留中の状態のトラブルシューティング
multicluster engine Operator をインストールするときに、MultiClusterEngine が Installing フェーズのままになるか、複数の Pod が Pending ステータスのままになります。
1.12.5.1. 現象: Pending 状態で止まる
MultiClusterEngine をインストールしてから、MultiClusterEngine リソースの status.components フィールドからのコンポーネントの 1 つ以上で ProgressDeadlineExceeded と報告したまま 10 分以上経過しています。クラスターのリソース制約が問題となっている場合があります。
MultiClusterEngine がインストールされた namespace で Pod を確認します。以下のようなステータスとともに Pending と表示される場合があります。
reason: Unschedulable
message: '0/6 nodes are available: 3 Insufficient cpu, 3 node(s) had taint {node-role.kubernetes.io/master:
}, that the pod didn't tolerate.'
reason: Unschedulable
message: '0/6 nodes are available: 3 Insufficient cpu, 3 node(s) had taint {node-role.kubernetes.io/master:
}, that the pod didn't tolerate.'このような場合には、ワーカーノードにはクラスターでの製品実行に十分なリソースがありません。
1.12.5.2. 問題の解決: ワーカーノードのサイズの調整
この問題が発生した場合は、大規模なワーカーノードまたは複数のワーカーノードでクラスターを更新する必要があります。クラスターのサイジングのガイドラインは、クラスターのサイジング を参照してください。
1.12.6. 再インストールに失敗する場合のトラブルシューティング
multicluster engine Operator を再インストールすると、Pod が起動しません。
1.12.6.1. 現象: 再インストールの失敗
multicluster engine Operator をインストールした後に Pod が起動しないのは、多くの場合、multicluster engine Operator の以前のインストールからの項目が、アンインストール時に正しく削除されなかったことが原因です。
Pod はこのような場合に、インストールプロセスの完了後に起動しません。
1.12.6.2. 問題の解決: 再インストールの失敗
この問題が発生した場合は、以下の手順を実行します。
- アンインストール の手順に従い、現在のコンポーネントを削除し、アンインストールプロセスを実行します。
-
ocコマンドが実行できるように、Red Hat OpenShift Container Platform CLI が設定されていることを確認してください。ocコマンドの設定方法の詳細は、OpenShift Container Platform ドキュメントの OpenShift CLI の使用を開始 を参照してください。 次のスクリプトをファイルにコピーします。スクリプト内の
<namespace>値を、以前に multicluster engine Operator をインストールした namespace の名前に置き換えます。重要: スクリプトを実行すると namespace もクリーンアップされて削除されるため、正しい namespace を指定していることを確認してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - スクリプトを実行します。リソースが見つからないというメッセージが表示されたら、インストールを続行できます。
- インストールを実行します。ネットワーク接続時のオンラインインストール を参照してください。
1.12.7. オフラインクラスターのトラブルシューティング
クラスターのステータスがオフラインと表示される一般的な原因がいくつかあります。
1.12.7.1. 現象: クラスターのステータスがオフライン状態である
クラスターの作成手順を完了したら、Red Hat Advanced Cluster Management コンソールからアクセスできず、クラスターのステータスが offline と表示されます。
1.12.7.2. 問題の解決: クラスターのステータスがオフライン状態になっている
マネージドクラスターが利用可能かどうかを確認します。これは、Red Hat Advanced Cluster Management コンソールの Clusters エリアで確認できます。
利用不可の場合は、マネージドクラスターの再起動を試行します。
マネージドクラスターのステータスがオフラインのままの場合は、以下の手順を実行します。
-
ハブクラスターで
oc get managedcluster <cluster_name> -o yamlコマンドを実行します。<cluster_name>は、クラスター名に置き換えます。 -
status.conditionsセクションを見つけます。 -
type: ManagedClusterConditionAvailableのメッセージを確認して、問題を解決します。
-
ハブクラスターで
1.12.8. マネージドクラスターのインポート失敗に関するトラブルシューティング
クラスターのインポートに失敗した場合は、クラスターのインポートが失敗した理由を判別するためにいくつかの手順を実行できます。
1.12.8.1. 現象: インポートされたクラスターを利用できない
クラスターをインポートする手順を完了すると、コンソールからクラスターにアクセスできなくなります。
1.12.8.2. 問題の解決: インポートされたクラスターが利用できない
インポートの試行後にインポートクラスターが利用できない場合には、いくつかの理由があります。クラスターのインポートに失敗した場合は、インポートに失敗した理由が見つかるまで以下の手順を実行します。
ハブクラスターで、次のコマンドを実行して、インポートコントローラーが実行していることを確認します。
kubectl -n multicluster-engine get pods -l app=managedcluster-import-controller-v2
kubectl -n multicluster-engine get pods -l app=managedcluster-import-controller-v2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 実行中の Pod が 2 つ表示されるはずです。Pod のいずれかが実行されていない場合には、以下のコマンドを実行してログを表示して理由を判別します。
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで次のコマンドを実行して、マネージドクラスターのインポートシークレットがインポートコントローラーによって正常に生成されたかどうかを確認します。
kubectl -n <managed_cluster_name> get secrets <managed_cluster_name>-import
kubectl -n <managed_cluster_name> get secrets <managed_cluster_name>-importCopy to Clipboard Copied! Toggle word wrap Toggle overflow インポートシークレットが存在しない場合は、以下のコマンドを実行してインポートコントローラーのログエントリーを表示し、作成されていない理由を判断します。
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1 | grep importconfig-controller
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1 | grep importconfig-controllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで、マネージドクラスターが
local-clusterであるか、Hive によってプロビジョニングされているか、自動インポートシークレットがある場合は、次のコマンドを実行して、マネージドクラスターのインポートステータスを確認します。kubectl get managedcluster <managed_cluster_name> -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}' | grep ManagedClusterImportSucceededkubectl get managedcluster <managed_cluster_name> -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}' | grep ManagedClusterImportSucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow ManagedClusterImportSucceededがtrueでない場合には、コマンドの結果で失敗の理由が表示されます。- マネージドクラスターの Klusterlet ステータスが degraded 状態でないかを確認します。Klusterlet のパフォーマンスが低下した理由を特定するには、degraded 状態にある Klusterlet のトラブルシューティング を参照してください。
1.12.9. クラスターの再インポートが不明な権限エラーで失敗する
マネージドクラスターを multicluster engine Operator に再インポートするときに問題が発生した場合は、手順に従って問題をトラブルシューティングします。
1.12.9.1. 現象: クラスターの再インポートが不明な権限エラーで失敗する
multicluster engine Operator を使用して OpenShift Container Platform クラスターをプロビジョニングした後に、API サーバー証明書を変更したり、OpenShift Container Platform クラスターに追加したりすると、x509: certificate signed by unknown authority エラーでクラスターの再インポートが失敗する場合があります。
1.12.9.2. 問題の特定: クラスターの再インポートが不明な権限エラーで失敗する
マネージドクラスターの再インポートに失敗した後、次のコマンドを実行して、multicluster engine Operator ハブクラスターのインポートコントローラーログを取得します。
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 -f
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 -f次のエラーログが表示される場合は、マネージドクラスター API サーバーの証明書が変更されている可能性があります。
ERROR Reconciler error {"controller": "clusterdeployment-controller", "object": {"name":"awscluster1","namespace":"awscluster1"}, "namespace": "awscluster1", "name": "awscluster1", "reconcileID": "a2cccf24-2547-4e26-95fb-f258a6710d80", "error": "Get \"https://api.awscluster1.dev04.red-chesterfield.com:6443/api?timeout=32s\": x509: certificate signed by unknown authority"}
マネージドクラスター API サーバー証明書が変更されたかどうかを確認するには、次の手順を実行します。
次のコマンドを実行して、
your-managed-cluster-nameをマネージドクラスターの名前に置き換えて、マネージドクラスターの名前を指定します。cluster_name=<your-managed-cluster-name>
cluster_name=<your-managed-cluster-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マネージドクラスター
kubeconfigシークレット名を取得します。kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
kubeconfigを新しいファイルにエクスポートします。oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > kubeconfig.oldoc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > kubeconfig.oldCopy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=kubeconfig.old
export KUBECONFIG=kubeconfig.oldCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
kubeconfigを使用してマネージドクラスターから namespace を取得します。oc get ns
oc get nsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のメッセージのようなエラーが表示された場合は、クラスター API サーバーの証明書が変更になっており、kubeconfig ファイルが無効です。
Unable to connect to the server: x509: certificate signed by unknown authority
1.12.9.3. 問題の解決: クラスターの再インポートが不明な権限エラーで失敗する
マネージドクラスター管理者は、マネージドクラスター用に新しい有効な kubeconfig ファイルを作成する必要があります。
新しい kubeconfig を作成したら、次の手順を実行して、マネージドクラスターの新しい kubeconfig を更新します。
次のコマンドを実行して、
kubeconfigファイルパスとクラスター名を設定します。<path_to_kubeconfig>を新しいkubeconfigファイルへのパスに置き換えます。<managed_cluster_name>をマネージドクラスターの名前に置き換えます。cluster_name=<managed_cluster_name> kubeconfig_file=<path_to_kubeconfig>
cluster_name=<managed_cluster_name> kubeconfig_file=<path_to_kubeconfig>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、新しい
kubeconfigをエンコードします。kubeconfig=$(cat ${kubeconfig_file} | base64 -w0)kubeconfig=$(cat ${kubeconfig_file} | base64 -w0)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: macOS では、代わりに次のコマンドを実行します。
kubeconfig=$(cat ${kubeconfig_file} | base64)kubeconfig=$(cat ${kubeconfig_file} | base64)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、JSON パッチ
kubeconfigを定義します。kubeconfig_patch="[\{\"op\":\"replace\", \"path\":\"/data/kubeconfig\", \"value\":\"${kubeconfig}\"}, \{\"op\":\"replace\", \"path\":\"/data/raw-kubeconfig\", \"value\":\"${kubeconfig}\"}]"kubeconfig_patch="[\{\"op\":\"replace\", \"path\":\"/data/kubeconfig\", \"value\":\"${kubeconfig}\"}, \{\"op\":\"replace\", \"path\":\"/data/raw-kubeconfig\", \"value\":\"${kubeconfig}\"}]"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マネージドクラスターから管理者の
kubeconfigシークレット名を取得します。kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、管理者の
kubeconfigシークレットに新しいkubeconfigを適用します。oc -n ${cluster_name} patch secrets ${kubeconfig_secret_name} --type='json' -p="${kubeconfig_patch}"oc -n ${cluster_name} patch secrets ${kubeconfig_secret_name} --type='json' -p="${kubeconfig_patch}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.12.10. Pending Import ステータスのクラスターのトラブルシューティング
クラスターのコンソールで継続的に Pending import と表示される場合は、以下の手順を実行して問題をトラブルシューティングしてください。
1.12.10.1. 現象: ステータスが Pending Import クラスター
Red Hat Advanced Cluster Management コンソールを使用してクラスターをインポートした後に、コンソールで、クラスターのステータスが Pending import と表示されます。
1.12.10.2. 問題の特定: ステータスが Pending Import クラスター
マネージドクラスターで以下のコマンドを実行し、問題のある Kubernetes Pod 名を表示します。
kubectl get pod -n open-cluster-management-agent | grep klusterlet-agent
kubectl get pod -n open-cluster-management-agent | grep klusterlet-agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターで以下のコマンドを実行し、エラーのログエントリーを探します。
kubectl logs <klusterlet_agent_pod> -n open-cluster-management-agent
kubectl logs <klusterlet_agent_pod> -n open-cluster-management-agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow registration_agent_pod は、手順 1 で特定した Pod 名に置き換えます。
-
返された結果に、ネットワーク接続の問題があったと示すテキストがないかどうかを検索します。たとえば、
no such hostです。
1.12.10.3. 問題の解決: ステータスが Pending Import クラスター
ハブクラスターで以下のコマンドを実行して、問題のあるポート番号を取得します。
oc get infrastructure cluster -o yaml | grep apiServerURL
oc get infrastructure cluster -o yaml | grep apiServerURLCopy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターのホスト名が解決でき、ホストおよびポートへの送信接続が機能していることを確認します。
マネージドクラスターで通信が確立できない場合は、クラスターのインポートが完了していません。マネージドクラスターのクラスターステータスは、Pending import になります。
1.12.11. 証明書を変更した後のインポート済みクラスターのオフラインでのトラブルシューティング
カスタムの apiserver 証明書のインストールはサポートされますが、証明書情報を変更する前にインポートされたクラスターの 1 つまたは複数でステータスが offline になる可能性があります。
1.12.11.1. 現象: 証明書の変更後にクラスターがオフラインになる
証明書シークレットを更新する手順を完了すると、オンラインだった 1 つ以上のクラスターがコンソールに offline ステータスを表示するようになります。
1.12.11.2. 問題の特定: 証明書の変更後にクラスターがオフラインになる
カスタムの API サーバー証明書の情報を更新すると、インポートされ、新しい証明書が追加される前に稼働していたクラスターのステータスが offline になります。
オフラインのマネージドクラスターの open-cluster-management-agent namespace にある Pod のログで、証明書に問題があるとのエラーが見つかります。以下の例のようなエラーがログに表示されます。
以下の work-agent ログを参照してください。
E0917 03:04:05.874759 1 manifestwork_controller.go:179] Reconcile work test-1-klusterlet-addon-workmgr fails with err: Failed to update work status with err Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority E0917 03:04:05.874887 1 base_controller.go:231] "ManifestWorkAgent" controller failed to sync "test-1-klusterlet-addon-workmgr", err: Failed to update work status with err Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority E0917 03:04:37.245859 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManifestWork: failed to list *v1.ManifestWork: Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks?resourceVersion=607424": x509: certificate signed by unknown authority
E0917 03:04:05.874759 1 manifestwork_controller.go:179] Reconcile work test-1-klusterlet-addon-workmgr fails with err: Failed to update work status with err Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:05.874887 1 base_controller.go:231] "ManifestWorkAgent" controller failed to sync "test-1-klusterlet-addon-workmgr", err: Failed to update work status with err Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:37.245859 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManifestWork: failed to list *v1.ManifestWork: Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks?resourceVersion=607424": x509: certificate signed by unknown authority
以下の registration-agent ログを確認してください。
I0917 02:27:41.525026 1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"open-cluster-management-agent", Name:"open-cluster-management-agent", UID:"", APIVersion:"v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'ManagedClusterAvailableConditionUpdated' update managed cluster "test-1" available condition to "True", due to "Managed cluster is available"
E0917 02:58:26.315984 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1beta1.CertificateSigningRequest: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
E0917 02:58:26.598343 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true": x509: certificate signed by unknown authority
E0917 02:58:27.613963 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: failed to list *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
I0917 02:27:41.525026 1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"open-cluster-management-agent", Name:"open-cluster-management-agent", UID:"", APIVersion:"v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'ManagedClusterAvailableConditionUpdated' update managed cluster "test-1" available condition to "True", due to "Managed cluster is available"
E0917 02:58:26.315984 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1beta1.CertificateSigningRequest: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
E0917 02:58:26.598343 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true": x509: certificate signed by unknown authority
E0917 02:58:27.613963 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: failed to list *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority1.12.11.3. 問題の解決: 証明書の変更後にクラスターがオフラインになる
マネージドクラスターが local-cluster である場合、またはマネージドクラスターが multicluster engine Operator によって作成された場合は、マネージドクラスターを回復するのに 10 分以上待つ必要があります。
マネージドクラスターをすぐに回復するには、ハブクラスター上のマネージドクラスターのインポートシークレットを削除し、multicluster engine Operator を使用して回復します。以下のコマンドを実行します。
oc delete secret -n <cluster_name> <cluster_name>-import
oc delete secret -n <cluster_name> <cluster_name>-import
<cluster_name> は、回復するマネージドクラスターの名前に置き換えます。
multicluster engine Operator を使用してインポートされたマネージドクラスターを回復する場合は、次の手順を実行して、マネージドクラスターを再度インポートします。
ハブクラスターで、次のコマンドを実行してマネージドクラスターのインポートシークレットを再作成します。
oc delete secret -n <cluster_name> <cluster_name>-import
oc delete secret -n <cluster_name> <cluster_name>-importCopy to Clipboard Copied! Toggle word wrap Toggle overflow <cluster_name>を、インポートするマネージドクラスターの名前に置き換えます。ハブクラスターで、次のコマンドを実行して、マネージドクラスターのインポートシークレットを YAML ファイルに公開します。
oc get secret -n <cluster_name> <cluster_name>-import -ojsonpath='{.data.import\.yaml}' | base64 --decode > import.yamloc get secret -n <cluster_name> <cluster_name>-import -ojsonpath='{.data.import\.yaml}' | base64 --decode > import.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow <cluster_name>を、インポートするマネージドクラスターの名前に置き換えます。マネージドクラスターで、次のコマンドを実行して
import.yamlファイルを適用します。oc apply -f import.yaml
oc apply -f import.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
注記: 前の手順では、マネージドクラスターがハブクラスターから切り離されません。この手順により、必要なマニフェストがマネージドクラスターの現在の設定 (新しい証明書情報を含む) で更新されます。
1.12.12. クラスターのステータスが offline から available に変わる場合のトラブルシューティング
マネージドクラスターのステータスは、環境またはクラスターを手動で変更することなく、offline と available との間で切り替わります。
1.12.12.1. 現象: クラスターのステータスが offline から available に変わる
マネージドクラスターからハブクラスターへのネットワーク接続が不安定な場合に、マネージドクラスターのステータスが offline と available との間で順に切り替わると、ハブクラスターにより報告されます。
1.12.12.2. 問題の解決: クラスターのステータスが offline から available に変わる
この問題を解決するには、以下の手順を実行します。
次のコマンドを入力して、ハブクラスターで
ManagedClusterの仕様を編集します。oc edit managedcluster <cluster-name>
oc edit managedcluster <cluster-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-name は、マネージドクラスターの名前に置き換えます。
-
ManagedCluster仕様のleaseDurationSecondsの値を増やします。デフォルト値は 60 秒です。マネージドクラスターのオフライン猶予期間は、5 分 (leaseDurationSecondsの 5 倍) です。この値は、ネットワークの問題が発生したときに接続を維持するのに十分でない可能性があります。リースの時間を長く指定します。たとえば、leaseDurationSecondsを 240 秒に設定すると、オフライン猶予期間が 20 分間になります。
1.12.13. VMware vSphere でのクラスター作成のトラブルシューティング
VMware vSphere で Red Hat OpenShift Container Platform クラスターを作成する時に問題が発生した場合は、以下のトラブルシューティング情報を参照して、この情報のいずれかが問題に対応しているかどうかを確認します。
注記: VMware vSphere でクラスター作成プロセスが失敗した場合に、リンクが有効にならずログが表示されないことがあります。上記が発生する場合は、hive-controllers Pod のログを確認して問題を特定できます。hive-controllers ログは hive namespace にあります。
1.12.13.1. 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
1.12.13.1.1. 現象: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書 IP SAN エラーを示すエラーメッセージでクラスターに問題が発生します。
1.12.13.1.2. 問題の特定: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。
time="2020-08-07T15:27:55Z" level=error msg="Error: error setting up new vSphere SOAP client: Post https://147.1.1.1/sdk: x509: cannot validate certificate for xx.xx.xx.xx because it doesn't contain any IP SANs" time="2020-08-07T15:27:55Z" level=error
time="2020-08-07T15:27:55Z" level=error msg="Error: error setting up new vSphere SOAP client: Post https://147.1.1.1/sdk: x509: cannot validate certificate for xx.xx.xx.xx because it doesn't contain any IP SANs"
time="2020-08-07T15:27:55Z" level=error1.12.13.1.3. 問題の解決: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
認証情報の IP アドレスではなく VMware vCenter サーバー完全修飾ホスト名を使用します。また、VMware vCenter CA 証明書を更新して、IP SAN を組み込むこともできます。
1.12.13.2. 不明な証明局のエラーでマネージドクラスターの作成に失敗する
1.12.13.2.1. 現象: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書が不明な証明局により署名されているのでクラスターに問題が発生します。
1.12.13.2.2. 問題の特定: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。
Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"1.12.13.2.3. 問題の解決: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
認証情報の作成時に認証局の正しい証明書が入力されていることを確認します。
1.12.13.3. 証明書の期限切れでマネージドクラスターの作成に失敗する
1.12.13.3.1. 現象: 証明書の期限切れでマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書の期限が切れているか、有効にしていないため、クラスターに問題が発生します。
1.12.13.3.2. 問題の特定: 証明書の期限切れでマネージドクラスターの作成に失敗する
マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。
x509: certificate has expired or is not yet valid
x509: certificate has expired or is not yet valid1.12.13.3.3. 問題の解決: 証明書の期限切れでマネージドクラスターの作成に失敗する
ESXi ホストの時間が同期されていることを確認します。
1.12.13.4. タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する
1.12.13.4.1. 現象: タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、タグ付けの使用に十分な権限がないためクラスターに問題が発生します。
1.12.13.4.2. 問題の特定: タグ付けの権限が十分にないためにマネージドクラスターの作成に失敗する
マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。
1.12.13.4.3. 問題の解決: タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する
VMware vCenter が必要とするアカウントの権限が正しいことを確認します。詳細は、インストール中に削除されたイメージレジストリー を参照してください。
1.12.13.5. 無効な dnsVIP でマネージドクラスターの作成に失敗する
1.12.13.5.1. 現象: 無効な dnsVIP でマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、dnsVIP が無効であるため、クラスターに問題が発生します。
1.12.13.5.2. 問題の特定: 無効な dnsVIP でマネージドクラスターの作成に失敗する
VMware vSphere で新しいマネージドクラスターをデプロイしようとして以下のメッセージが表示されるのは、VMware Installer Provisioned Infrastructure (IPI) をサポートしない以前の OpenShift Container Platform リリースイメージを使用しているためです。
failed to fetch Master Machines: failed to load asset \\\"Install Config\\\": invalid \\\"install-config.yaml\\\" file: platform.vsphere.dnsVIP: Invalid value: \\\"\\\": \\\"\\\" is not a valid IP
failed to fetch Master Machines: failed to load asset \\\"Install Config\\\": invalid \\\"install-config.yaml\\\" file: platform.vsphere.dnsVIP: Invalid value: \\\"\\\": \\\"\\\" is not a valid IP1.12.13.5.3. 問題の解決: 無効な dnsVIP でマネージドクラスターの作成に失敗する
VMware インストーラーでプロビジョニングされるインフラストラクチャーをサポートする OpenShift Container Platform で、新しいバージョンのリリースイメージを選択します。
1.12.13.6. ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する
1.12.13.6.1. 現象: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、間違ったネットワークタイプが指定されているため、クラスターに問題が発生します。
1.12.13.6.2. 問題の特定: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する
VMware vSphere で新しいマネージドクラスターをデプロイしようとして以下のメッセージが表示されるのは、VMware Installer Provisioned Infrastructure (IPI) をサポートしない以前の OpenShift Container Platform イメージを使用しているためです。
1.12.13.6.3. 問題の解決: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する
指定の VMware クラスターに対して有効な VMware vSphere ネットワークタイプを選択します。
1.12.13.7. ディスクの変更処理のエラーでマネージドクラスターの作成に失敗する
1.12.13.7.1. 現象: ディスク変更の処理中にエラーが発生するため、VMware vSphere マネージドクラスターの追加が失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、ディスク変更処理時にエラーによりクラスターに問題が発生します。
1.12.13.7.2. 問題の特定: ディスク変更処理エラーのため、VMware vSphere マネージドクラスターの追加に失敗する
以下のようなメッセージがログに表示されます。
ERROR ERROR Error: error reconfiguring virtual machine: error processing disk changes post-clone: disk.0: ServerFaultCode: NoPermission: RESOURCE (vm-71:2000), ACTION (queryAssociatedProfile): RESOURCE (vm-71), ACTION (PolicyIDByVirtualDisk)
ERROR
ERROR Error: error reconfiguring virtual machine: error processing disk changes post-clone: disk.0: ServerFaultCode: NoPermission: RESOURCE (vm-71:2000), ACTION (queryAssociatedProfile): RESOURCE (vm-71), ACTION (PolicyIDByVirtualDisk)1.12.13.7.3. 問題の解決: ディスク変更の処理中にエラーが発生したため、VMware vSphere マネージドクラスターの追加に失敗する
VMware vSphere クライアントを使用してユーザーに プロファイル駆動型のストレージ権限 の 全権限 を割り当てます。
1.12.14. ステータスが Pending または Failed のクラスターのコンソールでのトラブルシューティング
作成したクラスターのステータスがコンソールで Pending または Failed と表示されている場合は、以下の手順を実行して問題のトラブルシューティングを実行します。
1.12.14.1. 現象: コンソールでステータスが Pending または Failed のクラスターのトラブルシューティング
コンソールを使用して新しいクラスターを作成した後、クラスターは Pending のステータスを超えて進行しないか、Failed ステータスを表示します。
1.12.14.2. 問題の特定: コンソールでステータスが Pending または Failed のクラスター
クラスターのステータスが Failed と表示される場合は、クラスターの詳細ページに移動して、提供されたログへのリンクに進みます。ログが見つからない場合や、クラスターのステータスが Pending と表示される場合は、以下の手順を実行してログを確認します。
手順 1
ハブクラスターで以下のコマンドを実行し、新規クラスターの namespace に作成した Kubernetes Pod の名前を表示します。
oc get pod -n <new_cluster_name>
oc get pod -n <new_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow new_cluster_nameは、作成したクラスター名に置き換えます。名前に
provisionの文字列が含まれる Pod が表示されていない場合は、手順 2 に進みます。タイトルにprovisionが含まれる Pod があった場合は、ハブクラスターで以下のコマンドを実行して、その Pod のログを表示します。oc logs <new_cluster_name_provision_pod_name> -n <new_cluster_name> -c hive
oc logs <new_cluster_name_provision_pod_name> -n <new_cluster_name> -c hiveCopy to Clipboard Copied! Toggle word wrap Toggle overflow new_cluster_name_provision_pod_nameは、作成したクラスター名の後にprovisionが含まれる Pod 名を指定するように置き換えます。- ログでエラーを検索してください。この問題の原因が解明する場合があります。
手順 2
名前に
provisionが含まれる Pod がない場合は、問題がプロセスの初期段階で発生しています。ログを表示するには、以下の手順を実行します。ハブクラスターで以下のコマンドを実行してください。
oc describe clusterdeployments -n <new_cluster_name>
oc describe clusterdeployments -n <new_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow new_cluster_nameは、作成したクラスター名に置き換えます。クラスターのインストールログの詳細は、Red Hat OpenShift ドキュメントの インストールログの収集 を参照してください。- リソースの Status.Conditions.Message と Status.Conditions.Reason のエントリーに問題に関する追加の情報があるかどうかを確認します。
1.12.14.3. 問題の解決: コンソールでステータスが Pending または Failed のクラスター
ログでエラーを特定した後に、エラーの解決方法を決定してから、クラスターを破棄して、作り直してください。
以下の例では、サポート対象外のゾーンを選択している可能性を示すログエラーと、解決に必要なアクションが提示されています。
No subnets provided for zones
No subnets provided for zonesクラスターの作成時に、サポートされていないリージョンにあるゾーンを 1 つ以上選択しています。問題解決用にクラスターを再作成する時に、以下のアクションの 1 つを実行します。
- リージョン内の異なるゾーンを選択します。
- 他のゾーンをリストしている場合は、サポートを提供しないゾーンを省略します。
- お使いのクラスターに、別のリージョンを選択します。
ログから問題を特定した後に、クラスターを破棄し、再作成します。
クラスターの作成に関する詳細は、クラスターの作成 を参照してください。
1.12.15. degraded 状態にある Klusterlet のトラブルシューティング
Klusterlet の状態が Degraded の場合は、マネージドクラスターの Klusterlet エージェントの状態を診断しやすくなります。Klusterlet の状態が Degraded になると、マネージドクラスターの Klusterlet エージェントで発生する可能性のあるエラーに対応する必要があります。Klusterlet の degraded の状態が True に設定されている場合は、以下の情報を参照します。
1.12.15.1. 現象: Klusterlet の状態が degraded である
マネージドクラスターに Klusterlet をデプロイすると、RegistrationDesiredDegraded または WorkDesiredDegraded 状態に True のステータスが表示されます。
1.12.15.2. 問題の特定: Klusterlet の状態が degraded である
マネージドクラスターで以下のコマンドを実行して、Klusterlet のステータスを表示します
kubectl get klusterlets klusterlet -oyaml
kubectl get klusterlets klusterlet -oyamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
RegistrationDesiredDegradedまたはWorkDesiredDegradedをチェックして、状態がTrueに設定されているかどうかを確認します。記載されている Degraded の状態は、問題の解決 に進みます。
1.12.15.3. 問題の解決: Klusterlet の状態が degraded である
ステータスが Degraded のリストおよびこれらの問題の解決方法を参照してください。
-
RegistrationDesiredDegraded状態のステータスが True で、状態の理由が BootStrapSecretMissing である場合は、open-cluster-management-agentnamespace にブートストラップシークレットを作成する必要があります。 -
RegistrationDesiredDegraded状態に True と表示され、状態の理由が BootstrapSecretError または BootstrapSecretUnauthorized である場合は、現在のブートストラップシークレットが無効です。現在のブートストラップシークレットを削除して、open-cluster-management-agentnamespace で有効なブートストラップシークレットをもう一度作成します。 -
RegistrationDesiredDegradedとWorkDesiredDegradedに True と表示され、状態の理由が HubKubeConfigSecretMissing である場合は、Klusterlet を削除して再作成します。 -
RegistrationDesiredDegradedとWorkDesiredDegradedに True と表示され、状態の理由が ClusterNameMissing、KubeConfigMissing、HubConfigSecretError、または HubConfigSecretUnauthorized である場合は、open-cluster-management-agentnamespace からハブクラスターの kubeconfig シークレットを削除します。登録エージェントは再度ブートストラップして、新しいハブクラスターの kubeconfig シークレットを取得します。 -
RegistrationDesiredDegradedに True と表示され、状態の理由が GetRegistrationDeploymentFailed または UnavailableRegistrationPod である場合は、状態のメッセージを確認して問題の詳細を取得し、解決を試みてください。 -
WorkDesiredDegradedに True と表示され、状態の理由が GetWorkDeploymentFailed または UnavailableWorkPod である場合は、状態メッセージを確認して問題の詳細を取得し、解決を試みてください。
1.12.16. クラスターの削除後も namespace が残る
マネージドクラスターを削除すると、通常 namespace はクラスターの削除プロセスの一部として削除されます。まれに namespace は一部のアーティファクトが含まれた状態で残る場合があります。このような場合は、namespace を手動で削除する必要があります。
1.12.16.1. 現象: クラスターの削除後も namespace が残る
マネージドクラスターの削除後に namespace が削除されません。
1.12.16.2. 問題の解決: クラスターの削除後も namespace が残る
namespace を手作業で削除するには、以下の手順を実行します。
次のコマンドを実行して、<cluster_name> namespace に残っているリソースのリストを作成します。
oc api-resources --verbs=list --namespaced -o name | grep -E '^secrets|^serviceaccounts|^managedclusteraddons|^roles|^rolebindings|^manifestworks|^leases|^managedclusterinfo|^appliedmanifestworks'|^clusteroauths' | xargs -n 1 oc get --show-kind --ignore-not-found -n <cluster_name>
oc api-resources --verbs=list --namespaced -o name | grep -E '^secrets|^serviceaccounts|^managedclusteraddons|^roles|^rolebindings|^manifestworks|^leases|^managedclusterinfo|^appliedmanifestworks'|^clusteroauths' | xargs -n 1 oc get --show-kind --ignore-not-found -n <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster_nameは、削除を試みたクラスターの namespace 名に置き換えます。以下のコマンドを入力してリストを編集し、ステータスが
Deleteではないリストから特定したリソースを削除します。oc edit <resource_kind> <resource_name> -n <namespace>
oc edit <resource_kind> <resource_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow resource_kindは、リソースの種類に置き換えます。resource_nameは、リソース名に置き換えます。namespaceは、リソースの namespace に置き換えます。-
メタデータで
finalizer属性の場所を特定します。 -
vi エディターの
ddコマンドを使用して、Kubernetes 以外のファイナライザーを削除します。 -
:wqコマンドを入力し、リストを保存してviエディターを終了します。 以下のコマンドを入力して namespace を削除します。
oc delete ns <cluster-name>
oc delete ns <cluster-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-nameを、削除する namespace の名前に置き換えます。
1.12.17. クラスターのインポート時の auto-import-secret-exists エラー
クラスターのインポートは、auto import secret exists というエラーメッセージで失敗します。
1.12.17.1. 現象: クラスターのインポート時の Auto-import-secret-exists エラー
管理用のハイブクラスターをインポートすると、auto-import-secret already exists というエラーが表示されます。
1.12.17.2. 問題の解決: クラスターのインポート時の Auto-import-secret-exists エラー
この問題は、以前に管理されていたクラスターをインポートしようとすると発生します。これが生じると、クラスターを再インポートしようとすると、シークレットは競合します。
この問題を回避するには、以下の手順を実行します。
既存の
auto-import-secretを手動で削除するには、ハブクラスターで以下のコマンドを実行します。oc delete secret auto-import-secret -n <cluster-namespace>
oc delete secret auto-import-secret -n <cluster-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespaceは、お使いのクラスターの namespace に置き換えます。- クラスターインポートの概要 の手順を使用して、クラスターを再度インポートします。
1.12.18. Troubleshooting missing PlacementDecision after creating Placement
Placement の作成後に PlacementDescision が生成されない場合は、手順に従って問題をトラブルシューティングしてください。
1.12.18.1. 事象: Placement の作成後に PlacementDecision が見つからない
Placement を作成した後、PlacementDescision は自動的に生成されません。
1.12.18.2. 問題の解決: Placement の作成後に PlacementDecision が見つからない
この問題を解決するには、以下の手順を実行します。
次のコマンドを実行して
Placement条件を確認します。kubectl describe placement <placement-name>
kubectl describe placement <placement-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow placement-nameをPlacementの名前に置き換えます。出力は次の例のような内容になります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PlacementMisconfiguredおよびPlacementSatisfiedのStatusの出力を確認します。-
PlacementMisconfiguredStatusが true の場合、Placementに設定エラーがあります。設定エラーの詳細とその解決方法は、含まれているメッセージを確認してください。 -
PlacementSatisfiedStatusが false の場合、Placementを満たすマネージドクラスターはありません。詳細とエラーの解決方法は、含まれているメッセージを確認してください。前の例では、placement namespace にManagedClusterSetBindingsが見つかりませんでした。
-
Eventsで各クラスターのスコアを確認して、スコアの低い一部のクラスターが選択されていない理由を確認できます。出力は次の例のような内容になります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記: 配置コントローラーはスコアを割り当て、フィルター処理された
ManagedClusterごとにイベントを生成します。クラスタースコアが変化すると、配置コントローラーは新しいイベントを生成します。
1.12.19. Dell ハードウェアにおけるベアメタルホストの検出エラーのトラブルシューティング
Dell ハードウェアでベアメタルホストの検出が失敗した場合、Integrated Dell Remote Access Controller (iDRAC) が不明な認証局からの証明書を許可しないように設定されている可能性があります。
1.12.19.1. 現象: Dell ハードウェアでのベアメタルホストの検出エラー
ベースボード管理コントローラーを使用してベアメタルホストを検出する手順を完了すると、次のようなエラーメッセージが表示されます。
ProvisioningError 51s metal3-baremetal-controller Image provisioning failed: Deploy step deploy.deploy failed with BadRequestError: HTTP POST https://<bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia returned code 400. Base.1.8.GeneralError: A general error has occurred. See ExtendedInfo for more information Extended information: [
{"Message": "Unable to mount remote share https://<ironic_address>/redfish/boot-<uuid>.iso.", 'MessageArgs': ["https://<ironic_address>/redfish/boot-<uuid>.iso"], "MessageArgs@odata.count": 1, "MessageId": "IDRAC.2.5.RAC0720", "RelatedProperties": ["#/Image"], "RelatedProperties@odata.count": 1, "Resolution": "Retry the operation.", "Severity": "Informational"}
]
ProvisioningError 51s metal3-baremetal-controller Image provisioning failed: Deploy step deploy.deploy failed with BadRequestError: HTTP POST https://<bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia returned code 400. Base.1.8.GeneralError: A general error has occurred. See ExtendedInfo for more information Extended information: [
{"Message": "Unable to mount remote share https://<ironic_address>/redfish/boot-<uuid>.iso.", 'MessageArgs': ["https://<ironic_address>/redfish/boot-<uuid>.iso"], "MessageArgs@odata.count": 1, "MessageId": "IDRAC.2.5.RAC0720", "RelatedProperties": ["#/Image"], "RelatedProperties@odata.count": 1, "Resolution": "Retry the operation.", "Severity": "Informational"}
]1.12.19.2. 問題の解決: Dell ハードウェアでのベアメタルホストの検出の失敗
iDRAC は、不明な認証局からの証明書を受け入れないように設定されています。
この問題を回避するには、次の手順を実行して、ホスト iDRAC のベースボード管理コントローラーで証明書の検証を無効にします。
- iDRAC コンソールで、Configuration > Virtual media > Remote file share に移動します。
-
Expired or invalid certificate action の値を
Yesに変更します。
1.12.20. 最小限の ISO の起動失敗に関するトラブルシューティング
最小限の ISO を起動しようとすると問題が発生する可能性があります。
1.12.20.1. 現象: 最小限の ISO が起動に失敗する
ブート画面には、ホストがルートファイルシステムイメージのダウンロードに失敗したことが示されます。
1.12.20.2. 問題の解決: 最小限の ISO が起動に失敗する
問題のトラブルシューティング方法は、Assisted Installer for OpenShift Container Platform ドキュメントの 最小限の検出 ISO の問題をトラブルシューティングする を参照してください。
1.12.21. RHCOS イメージミラーリングのトラブルシューティング
非接続環境の Red Hat OpenShift Virtualization 上の Hosted Control Plane の場合、oc-mirror で、Red Hat Enterprise Linux CoreOS (RHCOS) イメージを内部レジストリーに自動的にミラーリングできません。最初のホステッドクラスターを作成するときに、ブートイメージを内部レジストリーで利用できないため、Kubevirt 仮想マシンが起動しません。
1.12.21.1. 現象: oc-mirror で RHCOS イメージのミラーリングを試行できない
oc-mirror プラグインは、リリースペイロードから内部レジストリーに {op-system-first} イメージをミラーリングしません。
1.12.21.2. 問題の解決: oc-mirror で RHCOS イメージのミラーリングを試行できない
この問題を解決するには、RHCOS イメージを手動で内部レジストリーにミラーリングします。以下の手順を実行します。
次のコマンドを実行して内部レジストリー名を取得します。
oc get imagecontentsourcepolicy -o json | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'
oc get imagecontentsourcepolicy -o json | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してペイロードイメージを取得します。
oc get clusterversion version -ojsonpath='{.status.desired.image}'oc get clusterversion version -ojsonpath='{.status.desired.image}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホステッドクラスター上のペイロードイメージからブートイメージを含む
0000_50_installer_coreos-bootimages.yamlファイルを抽出します。<payload_image>は、ペイロードイメージの名前に置き換えます。以下のコマンドを実行します。oc image extract --file /release-manifests/0000_50_installer_coreos-bootimages.yaml <payload_image> --confirm
oc image extract --file /release-manifests/0000_50_installer_coreos-bootimages.yaml <payload_image> --confirmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して RHCOS イメージを取得します。
cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'
cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS イメージを内部レジストリーにミラーリングします。
<rhcos_image>は、RHCOS イメージに置き換えます (例:quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d9643ead36b1c026be664c9c65c11433c6cdf71bfd93ba229141d134a4a6dd94)。<internal_registry>は、内部レジストリーの名前に置き換えます (例:virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev)。以下のコマンドを実行します。oc image mirror <rhcos_image> <internal_registry>
oc image mirror <rhcos_image> <internal_registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImageDigestMirrorSetオブジェクトを定義するrhcos-boot-kubevirt.yamlという名前の YAML ファイルを作成します。次の設定例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
rhcos-boot-kubevirt.yamlファイルを適用し、ImageDigestMirrorSetオブジェクトを作成します。oc apply -f rhcos-boot-kubevirt.yaml
oc apply -f rhcos-boot-kubevirt.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.12.22. トラブルシューティング: 非ベアメタルクラスターを遅延バインディングプールに戻す
BareMetalHosts なしで遅延バインディングマネージドクラスターを使用している場合は、遅延バインディングクラスターを破棄し、ノードを Discovery ISO に戻すための追加の手動手順を実行する必要があります。
1.12.22.1. 現象: 非ベアメタルクラスターを遅延バインディングプールに戻す
BareMetalHosts のない遅延バインディングマネージドクラスターの場合、クラスター情報を削除しても、すべてのノードが自動的に Discovery ISO に戻されるわけではありません。
1.12.22.2. 問題の解決: 非ベアメタルクラスターを遅延バインディングプールに戻す
遅延バインディングを使用する非ベアメタルノードのバインドを解除するには、次の手順を実行します。
- クラスター情報を削除します。詳細は、管理からのクラスターの削除 を参照してください。
- ルートディスクをクリーンアップします。
- Discovery ISO を使用して手動で再起動します。
1.12.23. Hosted Control Plane クラスターを使用した Red Hat OpenShift Service on AWS でマネージドクラスターが Unknown になる問題のトラブルシューティング
Red Hat OpenShift Service on AWS 上のすべてのマネージドクラスターのステータスが突然 Unknown になります。
マネージドクラスターの open-cluster-management-agent namespace にある klusterlet-agent Pod のログを確認すると、次のようなエラーが表示されます。
E0809 18:45:29.450874 1 reflector.go:147] k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: Failed to watch *v1.CertificateSigningRequest: failed to list *v1.CertificateSigningRequest: Get "https://api.xxx.openshiftapps.com:443/apis/certificates.k8s.io/v1/certificatesigningrequests?limit=500&resourceVersion=0": tls: failed to verify certificate: x509: certificate signed by unknown authority
E0809 18:45:29.450874 1 reflector.go:147] k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: Failed to watch *v1.CertificateSigningRequest: failed to list *v1.CertificateSigningRequest: Get "https://api.xxx.openshiftapps.com:443/apis/certificates.k8s.io/v1/certificatesigningrequests?limit=500&resourceVersion=0": tls: failed to verify certificate: x509: certificate signed by unknown authority1.12.23.2. Red Hat OpenShift Service on AWS with Hosted Control Plane クラスターで、すべてのマネージドクラスターが Unknown ステータスになる
-
globalという名前のKlusterletConfigリソースを作成します (リソースがない場合)。 spec.hubKubeAPIServerConfig.serverVerificationStrategyをUseSystemTruststoreに設定します。以下の例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハブクラスターで次のコマンドを実行してリソースを適用します。
<filename>はファイル名に置き換えます。oc apply -f <filename>
oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターによっては、状態が回復することがあります。
Unknownステータスのままのマネージドクラスターがある場合は、このプロセスを続行します。ハブクラスターで次のコマンドを実行して、ハブクラスターから
import.yaml` ファイルをエクスポートしてデコードします。`<cluster_name>は、クラスター名に置き換えます。oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.import\.yaml} | base64 --decode > <cluster_name>-import.yamloc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.import\.yaml} | base64 --decode > <cluster_name>-import.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターで次のコマンドを実行してファイルを適用します。
oc apply -f <cluster_name>-import.yaml
oc apply -f <cluster_name>-import.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.12.24. OpenShift Container Platform バージョンが欠落しているマネージドクラスターのアップグレード試行のトラブルシューティング
コンソールでマネージドクラスターをアップグレードしようとすると、コンソールに必要な OpenShift Container Platform バージョンが表示されません。
1.12.24.1. 現象: OpenShift Container Platform バージョンが欠落している状態でマネージドクラスターをアップグレードしようとする
コンソールからマネージドクラスターをアップグレードしようとし、Cluster details ビューで Upgrade available をクリックしてドロップダウンリストから OpenShift Container Platform のバージョンを選択すると、バージョンが見つかりません。
1.12.24.2. 問題の解決: OpenShift Container Platform バージョンが欠落しているマネージドクラスターのアップグレードを試みる
以下の手順を参照してください。
マネージドクラスターの
ClusterVersionリソースのステータスに必要なバージョンが含まれていることを確認します。以下のコマンドを実行します。oc get clusterversion version -o jsonpath='{.status.availableUpdates[*].version}'oc get clusterversion version -o jsonpath='{.status.availableUpdates[*].version}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要とされるバージョンが表示されない場合、そのバージョンはこのマネージドクラスターには適用されません。
ManagedClusterInfoリソースにハブクラスターのバージョンが含まれているかどうかを確認します。以下のコマンドを実行します。oc -n <cluster_name> get managedclusterinfo <cluster_name> -o jsonpath='{.status.distributionInfo.ocp.availableUpdates[*]}'oc -n <cluster_name> get managedclusterinfo <cluster_name> -o jsonpath='{.status.distributionInfo.ocp.availableUpdates[*]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow バージョンが含まれている場合は、ハブクラスターに障害のある
ClusterCuratorリソースがあるかどうかを確認します。以下のコマンドを実行します。oc -n <cluster_name> get ClusterCurator <cluster_name> -o yaml
oc -n <cluster_name> get ClusterCurator <cluster_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ClusterCuratorリソースが存在し、そのclustercurator-job条件のステータスがFalseの場合は、ハブクラスターからClusterCuratorリソースを削除します。以下のコマンドを実行します。oc -n <cluster_name> delete ClusterCurator <cluster_name>
oc -n <cluster_name> delete ClusterCurator <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ManagedClusterInfoリソースにバージョンが含まれていない場合は、マネージドクラスターのwork-managerアドオンログを確認し、報告されたエラーを修正します。次のコマンドを実行し、Pod 名を環境内の実際の名前に置き換えます。oc -n open-cluster-management-agent-addon logs klusterlet-addon-workmgr-<your_pod_name>
oc -n open-cluster-management-agent-addon logs klusterlet-addon-workmgr-<your_pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.12.25. Hive および Assisted Installer クラスターでの認証局更新エラーのトラブルシューティング
Hive でプロビジョニングされたクラスターまたは Assisted Installer クラスターでクラスター認証局 (CA) を更新した後に表示される接続エラーメッセージをトラブルシューティングします。
1.12.25.1. 現象: Hive および Assisted Installer クラスターでの認証局更新エラー
Hive でプロビジョニングされたクラスターまたは Assisted Installer クラスターでクラスター CA をエンタープライズ CA で更新すると、ハブクラスター上の対応するクラスターデプロイメントに次の接続エラーメッセージが表示されます。
x509: certificate signed by unknown authority
x509: certificate signed by unknown authorityこの状態でクラスターをバックアップして復元しても、復元されたハブクラスターにマネージドクラスターを自動的にインポートできません。
1.12.25.2. 問題の解決: Hive および Assisted Installer クラスターでの認証局更新エラー
エラーを解決するには、次の手順を使用します。
システム内のグローバル変数を使用してカスタム CA を定義します。以下のコマンドを実行します。
export CA=<your_customized_CA>
export CA=<your_customized_CA>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、カスタマイズした CA を使用して新しいシークレットを生成します。
oc create secret generic additional-ca \ --from-literal=ca.crt="$CA" \ --namespace hive
oc create secret generic additional-ca \ --from-literal=ca.crt="$CA" \ --namespace hiveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいシークレットを使用してクラスターを更新します。追加の CA パッチを使用して次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}