1.7. Hosted Control Plane
マルチクラスターエンジン Operator クラスター管理では、スタンドアロンまたは Hosted Control Plane の 2 つの異なるコントロールプレーン設定を使用して、OpenShift Container Platform クラスターをデプロイできます。スタンドアロン設定では、専用の仮想マシンまたは物理マシンを使用して、OpenShift Container Platform のコントロールプレーンをホストします。OpenShift Container Platform の Hosted Control Plane を使用すると、コントロールプレーンごとに専用の物理マシンを必要とせずに、ホスティングクラスター上にコントロールプレーンを Pod として作成できます。
OpenShift Container Platform の Hosted Control Plane は、ベアメタルおよび Red Hat OpenShift Virtualization で、また Amazon Web Services (AWS) の テクノロジープレビュー 機能として利用できます。コントロールプレーンは、OpenShift Container Platform バージョン 4.14 以降でホスティングできます。Hosted Control Plane 機能がデフォルトで有効になりました。
1.7.1. 要件
次の表は、各プラットフォームでサポートされている OpenShift Container Platform のバージョンを示しています。この表では、ホスティング OpenShift Container Platform バージョン は、マルチクラスターエンジン Operator が有効になっている OpenShift Container Platform バージョンを指します。
| プラットフォーム | ホスティング OpenShift Container Platform のバージョン | ホステッド OpenShift Container Platform バージョン |
| ベアメタル | 4.14 | 4.14 (のみ) |
| Red Hat OpenShift Virtualization | 4.14 | 4.14 (のみ) |
| AWS (テクノロジープレビュー) | 4.11 - 4.14 | 4.14 (のみ) |
注記: Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
コントロールプレーンは、単一の namespace に含まれる Pod として実行され、Hosted Control Plane クラスターに関連付けられます。OpenShift Container Platform がこのタイプのホステッドクラスターを作成すると、コントロールプレーンから独立したワーカーノードが作成されます。
プロキシーを使用しており、Pod から Kubernetes API サーバーへのトラフィックでプロキシーを使用しないようにする場合は、デフォルトの Kubernetes API サーバーアドレス 172.20.0.1 を no_proxy リストに追加します。
Hosted Control Plane クラスターには、いくつかの利点があります。
- 専用コントロールプレーンノードをホストする必要がなくなるため、コストを節約できます。
- コントロールプレーンとワークロードを分離することで、分離が改善され、変更が必要になる設定エラーが減少します。
- コントロールプレーンノードのブートストラップの要件をなくすことで、クラスターの作成時間を短縮します。
- ターンキーデプロイメントまたは完全にカスタマイズされた OpenShift Container Platform プロビジョニングをサポートします。
Hosted Control Plane を使用するには、次のドキュメントから始めてください。
次に、使用する予定のプラットフォームに関連するドキュメントを参照してください。
- AWS での Hosted Control Plane クラスターの設定 (テクノロジープレビュー)
- ベアメタルでの Hosted Control Plane クラスターの設定
- 64 ビット x86 OpenShift Container Platform クラスターでのホスティングクラスターの設定による、IBM Power コンピュートノードの Hosted Control Plane の作成 (テクノロジープレビュー)
-
IBM Z コンピュートノード用の
x86ベアメタル上でのホスティングクラスターの設定 (テクノロジープレビュー) - OpenShift Virtualization での Hosted Control Plane クラスターの管理
- 非接続環境での Hosted Control Plane の設定
- ホステッドコントロール機能の無効化
hosted control plane の追加リソースについては、次の OpenShift Container Platform ドキュメントを参照してください。
1.7.2. Hosted Control Plane のサイジングに関するガイダンス
ホステッドクラスターのワークロードやワーカーノード数などの多くの要因が、一定数のコントロールプレーンノード内に収容できるホステッドクラスターの数に影響します。このサイジングガイドを使用して、ホステッドクラスターの容量計画に役立ちます。このガイダンスは、可用性の高い Hosted Control Plane トポロジーを前提としています。ロードベースのサイジングの例は、ベアメタルクラスターで測定されています。クラウドベースのインスタンスには、メモリーサイズなど、さまざまな制限要因が含まれる場合があります。高可用性の Hosted control plane トポロジーの詳細は、ホステッドクラスターのワークロードの分散 を参照してください。
OpenShift Container Platform バージョン 4.12.9 以降でテストされた、次の高可用性 Hosted control plane 要件を参照してください。
- 78 pods
- etcd 用の 3 つの 8 GiB PV
- 最小仮想 CPU: 約 5.5 コア
- 最小メモリー: 約 19 GiB
1.7.2.1. Pod の制限
各ノードの maxPods 設定は、コントロールプレーンノードに収容できるホステッドクラスターの数に影響します。すべてのコントロールプレーンノードの maxPods 値に注意することが重要です。高可用性の Hosted Control Plane ごとに約 75 個の Pod を計画します。
ベアメタルノードの場合、マシンに十分なリソースがある場合でも、Pod 要件を考慮すると、各ノードに約 3 つの Hosted Control Plane が使用されるため、デフォルトで maxPods 設定に 250 が指定されていることが制限要因となる可能性があります。KubeletConfig 値を設定して maxPods 値を 500 に設定すると、Hosted Control Plane の密度が増し、追加のコンピューティングリソースを活用できるようになります。詳細は、OpenShift Container Platform ドキュメントの ノードあたりの最大 Pod 数の設定 を参照してください。
1.7.2.2. 要求ベースのリソース制限
リクエストベースのリソース制限を理解するには、Hosted control plane の合計リクエスト値を考慮してください。この値を計算するには、namespace 全体の高可用性 Hosted control plane Pod すべてのリクエスト値を追加します。以下の例を参照してください。
- 高可用性 Hosted control plane ごとに 5 つの vCPU リクエスト
- 高可用性 Hosted control plane ごとに 18 GiB のメモリーリクエスト
1.7.2.3. 負荷ベースの制限
リクエストベースのサイジングでは、Hosted control plane の最大数を提供し、平均リソース使用量を満たす Burstable クラスの最小リクエスト合計に基づいて実行できるようにします。ホステッドクラスターのより高いレベルの負荷に合わせて調整されるサイジングガイダンスでは、負荷ベースのアプローチにより、API レートの増加に合わせたリソース使用量が示されます。負荷ベースのアプローチは、高い API 負荷ポイントを処理するために、各 Hosted control plane のリソース容量の範囲で構築します。
たとえば、API 負荷によるリソースのスケーリングを示すには、次のワークロード設定を考慮してください。
- KubeVirt プロバイダーを使用した、9 つのワーカー (8 vCPU、各 32 GiB) を備えたホステッドクラスター 1 つ
- ベンチマークツール: Kube-burner
ワークロードプロファイルは、次の定義に基づいて、API コントロールプレーンのストレスに焦点を当てるように設定されたクラスター密度テストです。
- namespace ごとにオブジェクトを作成し、合計 100 namespace にスケールアップする
-
churnパラメーターが有効になっているため、継続的なオブジェクトの削除と作成による追加の API ストレスが発生する -
クライアント側のスロットルを除去するために、1 秒あたりのワークロードクエリー数 (QPS) と
バースト設定が高く設定されている
リソース使用率は、ワークロードが namespace の合計数まで増加するたびに測定されます。このデータは、予想される API 負荷に基づいてコンピューティングリソースの容量を増やすための推定係数を提供します。正確な使用率は、クラスターのワークロードのタイプとペースによって異なる場合があります。
| Hosted control plane のリソース使用率のスケーリング | 仮想 CPU | メモリー (GiB) |
|---|---|---|
| デフォルトのリクエスト | 5 | 18 |
| アイドル時の使用 | 2.9 | 11.1 |
| API レートの 1000 回あたりの使用量の増加 | 9.0 | 2.5 |
このような例を使用すると、API にかかる負荷の割合を想定した負荷ベースの制限を考慮できます。この負荷の割合は、ホストされた API サーバー 3 台すべてを累計した QPS として測定されます。一般的なサイジングの目的では、1000 QPS API レートを中程度のホステッドクラスターの負荷、2000 QPS API を高程度のホステッドクラスターの負荷とみなしてください。
アクティブなホステッドクラスターの API レートを決定するには、次のメトリックを使用して、適切なホストされた namespace の 1 秒あたりのクエリー数を測定します。このメトリックは、OpenShift Container Platform Web コンソールの管理者パースペクティブから Observe
sum(rate(apiserver_request_total{namespace=~"clusters-$name*"}[2m])) by (namespace)次の例は、ワークロードおよび API レート定義の Hosted control plane リソースのスケーリングを示しています。
| QPS (API レート) | 仮想 CPU の使用量 | メモリーの使用量 (GiB) |
|---|---|---|
| 50 QPS 未満 (低) | 2.9 | 11.1 |
| 1000QPS (中) | 11.9 | 13.6 |
| 2000 QPS (高) | 20.9 | 16.1 |
Hosted Control Plane のサイジングは、コントロールプレーンの負荷と、大量の API アクティビティー、etcd アクティビティー、またはその両方を引き起こすワークロードに関係します。データベースの実行など、データプレーンの負荷に重点を置くホスト型 Pod ワークロードでは、API レートが高い可能性があります。
1.7.2.4. サイジング計算の例
この例では、次のシナリオに対してサイジングのガイダンスを提供します。
-
hypershift.openshift.io/control-planeノードとしてラベル付けされたベアメタルワーカー 3 つ -
maxPods値を 500 に設定している - 負荷ベースの制限に応じて、予想される API レートは中または約 1000 である
| 制限の説明 | サーバー 1 | サーバー 2 |
|---|---|---|
| ワーカーノード上の仮想 CPU 数 | 64 | 128 |
| ワーカーノードのメモリー (GiB) | 128 | 256 |
| ワーカーあたりの最大 Pod 数 | 500 | 500 |
| コントロールプレーンのホストに使用されるワーカーの数 | 3 | 3 |
| 最大 QPS ターゲットレート (1 秒あたりの API リクエスト) | 1000 | 1000 |
| ワーカーノードのサイズと API レートに基づいた計算値 | サーバー 1 | サーバー 2 | 計算の注記 |
| 仮想 CPU リクエストに基づくワーカーあたりの最大ホストコントロールプレーン数 | 12.8 | 25.6 | Hosted Control Plane ごとにワーカー仮想 CPU/5 合計仮想 CPU 要求の数 |
| 仮想 CPU 使用率に基づくワーカーあたりの最大 Hosted Control Plane 数 | 5.4 | 10.7 | 仮想 CPU の数 ÷ (2.9 測定されたアイドル状態の仮想 CPU 使用率 + (QPS ターゲットレート ÷ 1000) × 9.0 1000 QPS 増加あたりの測定された仮想 CPU 使用率) |
| メモリーリクエストに基づくワーカーごとの最大 Hosted Control Plane | 7.1 | 14.2 | Hosted Control Plane ごとにワーカーメモリー GiB/18 GiB の合計メモリーリクエスト |
| メモリー使用量に基づくワーカーあたりの最大 Hosted Control Plane 数 | 9.4 | 18.8 | ワーカーメモリー GiB ÷ (11.1 測定されたアイドルメモリー使用量 + (QPS ターゲットレート ÷ 1000) × 2.5 1000 QPS 増加あたりの測定されたメモリー使用量) |
| ノードごとの Pod の制限に基づくワーカーごとの最大 Hosted Control Plane | 6.7 | 6.7 |
500 |
| 前述の最大値の中の最小値 | 5.4 | 6.7 | |
| 仮想 CPU の制限要因 |
| ||
| 管理クラスター内の Hosted Control Plane の最大数 | 16 | 20 | 前述の最大 3 つのコントロールプレーンワーカーの最小数。 |
1.7.2.5. 関連情報
1.7.3. Hosted control plane コマンドラインインターフェイスのインストール
次の手順を実行して、Hosted Control Plane コマンドラインインターフェイス (hcp) をインストールできます。
- OpenShift Container Platform コンソールから、Help icon > Command Line Tools をクリックします。
- お使いのプラットフォーム用の Download hcp CLI をクリックします。
次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。
tar xvzf hcp.tar.gz
次のコマンドを実行して、バイナリーファイルを実行可能にします。
chmod +x hcp
次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。
sudo mv hcp /usr/local/bin/.
1.7.3.1. CLI を使用した Hosted Control Plane コマンドラインインターフェイスのインストール
次の手順を実行すると、CLI を使用して Hosted Control Plane コマンドラインインターフェイス (hcp) をインストールできます。
次のコマンドを実行して、
hcpバイナリーをダウンロードするための URL を取得します。oc get ConsoleCLIDownload hcp-cli-download -o json | jq -r ".spec"
次のコマンドを実行して
hcpバイナリーをダウンロードします。wget <hcp_cli_download_url> 1- 1
hcp_cli_download_urlは、前の手順で取得した URL に置き換えます。
次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。
tar xvzf hcp.tar.gz
次のコマンドを実行して、バイナリーファイルを実行可能にします。
chmod +x hcp
次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。
sudo mv hcp /usr/local/bin/.
1.7.3.2. コンテンツゲートウェイを使用した Hosted Control Plane コマンドラインインターフェイスのインストール
コンテンツゲートウェイを使用して、Hosted Control Plane コマンドラインインターフェイス (hcp) をインストールできます。以下の手順を実行します。
-
コンテンツゲートウェイ に移動し、
hcpバイナリーをダウンロードします。 次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。
tar xvzf hcp.tar.gz
次のコマンドを実行して、バイナリーファイルを実行可能にします。
chmod +x hcp
次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。
sudo mv hcp /usr/local/bin/.
hcp create cluster コマンドを使用して、ホステッドクラスターを作成および管理できるようになりました。使用可能なパラメーターをリストするには、次のコマンドを入力します。
hcp create cluster <platform> --help 1- 1
- サポートされているプラットフォームは、
aws、agent、およびkubevirtです。
1.7.4. ホステッドクラスターのワークロードの分散
OpenShift Container Platform の Hosted Control Plane を初めて使用する前に、ホステッドクラスターの Pod をインフラストラクチャーノードにスケジュールできるように、ノードを適切にラベル付けする必要があります。また、ノードのラベリングは以下の理由で重要です。
-
高可用性と適切なワークロードのデプロイメントを確保するため。たとえば、
node-role.kubernetes.io/infraラベルを設定して、OpenShift Container Platform サブスクリプションに control-plane ワークロード数が割り当てられないようにできます。 - コントロールプレーンのワークロードが管理クラスター内の他のワークロードから分離されるようにするため。
重要: ワークロードには管理クラスターを使用しないでください。ワークロードは、コントロールプレーンが実行されるノード上で実行してはなりません。
1.7.4.1. 管理クラスターノードのラベルとテイント
管理クラスター管理者は、管理クラスターノードで次のラベルとテイントを使用して、コントロールプレーンのワークロードをスケジュールします。
-
hypershift.openshift.io/control-plane: true: このラベルとテイントを使用して、Hosted Control Plane ワークロードの実行専用にノードを割り当てます。値をtrueに設定すると、コントロールプレーンノードが他のコンポーネント (管理クラスターのインフラストラクチャーコンポーネントや誤ってデプロイされたその他のワークロードなど) と共有されるのを回避できます。 -
hypershift.openshift.io/cluster: ${HostedControlPlane Namespace}: ノードを単一のホストされたクラスター専用にする場合は、このラベルとテイントを使用します。
コントロールプレーン Pod をホストするノードに以下のラベルを適用します。
-
node-role.kubernetes.io/infra: このラベルを使用して、サブスクリプションにコントロールプレーンワークロード数が割り当てられないようにします。 topology.kubernetes.io/zone: このラベルを管理クラスターノードで使用して、障害ドメイン全体に高可用性クラスターをデプロイします。ゾーンは、ゾーンが設定されているノードの場所、ラック名、またはホスト名である場合があります。たとえば、管理クラスターには、worker-1a、worker-1b、worker-2a、およびworker-2bのノードがあります。worker-1aとworker-1bノードはrack1にあり、worker-2aノードと worker-2b ノードはrack2にあります。各ラックをアベイラビリティゾーンとして使用するには、次のコマンドを入力します。oc label node/worker-1a node/worker-1b topology.kubernetes.io/zone=rack1 oc label node/worker-2a node/worker-2b topology.kubernetes.io/zone=rack2
ホステッドクラスターの Pod には許容範囲があり、スケジューラーはアフィニティールールを使用して Pod をスケジュールします。Pod は、control-plane と Pod の cluster のテイントを許容します。スケジューラーは、hypershift.openshift.io/control-plane および hypershift.openshift.io/cluster: ${HostedControlPlane Namespace} でラベル付けされたノードへの Pod のスケジューリングを優先します。
ControllerAvailabilityPolicy オプションには、HighlyAvailable を使用します。これは、Hosted Control Plane のコマンドラインインターフェイス (hcp) がデプロイするデフォルト値です。このオプションを使用する場合は、topology.kubernetes.io/zone をトポロジーキーとして設定することで、さまざまな障害ドメインにわたるホステッドクラスター内のデプロイメントごとに Pod をスケジュールできます。高可用性ではないコントロールプレーンはサポートされていません。
重要: 適切なノードのラベル付けは、Hosted Control Plane のデプロイメントの前提条件となっています。これについては、次の手順で詳しく説明します。
1.7.4.2. ホステッドクラスターのノードのラベル付け
ホステッドクラスターがその Pod をインフラストラクチャーノードにスケジュールすることを要求できるようにするには、次の例に示すように HostedCluster.spec.nodeSelector を設定します。
spec:
nodeSelector:
role.kubernetes.io/infra: ""こうすることで、各ホステッドクラスターの Hosted Control Plane が適格なインフラストラクチャーノードワークロードとなり、基盤となる OpenShift Container Platform ノードに資格を与える必要がなくなります。
1.7.4.3. 優先クラス
4 つの組み込み優先クラスは、ホステッドクラスター Pod の優先順位とプリエンプションに影響を与えます。管理クラスター内に Pod は、次の上位から下位の順序で作成できます。
-
hypershift-operator: HyperShift Operator Pod。 -
hypershift-etcd: etcd 用の Pod。 -
hypershift-api-critical: API 呼び出しとリソース許可が成功するために必要な Pod。これらの Pod には、kube-apiserver、集約 API サーバー、Web フックなどの Pod が含まれます。 -
hypershift-control-plane: API クリティカルではないものの、クラスターバージョンの Operator など、高い優先順位が必要なコントロールプレーン内の Pod。
1.7.4.4. 関連情報
Hosted Control Plane の詳細は、次のトピックを参照してください。
1.7.5. AWS での Hosted Control Plane クラスターの設定 (テクノロジープレビュー)
Hosted Control Plane を設定するには、ホスティングクラスターとホステッドクラスターが必要です。hypershift-addon マネージドクラスターアドオンを使用して既存のマネージドクラスターに HyperShift Operator をデプロイすることにより、そのクラスターをホスティングクラスターとして有効にして、ホステッドクラスターを作成し始めることができます。hypershift-addon マネージドクラスターアドオンは、マルチクラスターエンジン Operator 2.4 および Red Hat Advanced Cluster Management 2.9 ハブクラスターの local-cluster マネージドクラスターに対して、デフォルトで有効になっています。
ホストされたクラスター は、ホスティングクラスターでホストされる API エンドポイントとコントロールプレーンを含む OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。マルチクラスターエンジンの Operator コンソールまたは Hosted Control Plane のコマンドラインインターフェイス hcp を使用して、ホステッドクラスターを作成できます。ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、マルチクラスターエンジン Operator へのホストクラスターの自動インポートの無効化 を参照してください。
重要:
- マルチクラスターエンジン Operator が管理できるように、各ホストクラスターには一意の名前が必要です。
- Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
- マルチクラスターエンジン Operator が管理できるように、各ホストクラスターには一意の名前が必要です。
- ホステッドクラスターは、マルチクラスターエンジンの operator 管理クラスターの namespace には作成できません。
1.7.5.1. 前提条件
ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。
- OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.4 以降のマルチクラスターエンジン。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management を使用せずに OpenShift Container Platform OperatorHub から Operator としてインストールすることもできます。
マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。
local-clusterは、マルチクラスターエンジン Operator 2.4 以降で自動的にインポートされます。local-clusterの詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。oc get managedclusters local-cluster
- AWS コマンドラインインターフェイス
- Hosted Control Plane コマンドラインインターフェイス
Hosted Control Plane の関連資料については、次のドキュメントを参照してください。
- Hosted Control Plane 機能を無効にするか、すでに無効にしていて手動で有効にする場合は、Hosted Control Plane 機能の有効化または無効化 を参照してください。
- Red Hat Ansible Automation Platform ジョブを実行してホステッドクラスターを管理するには、ホステッドクラスターで実行するための Ansible Automation Platform ジョブの設定 を参照してください。
- SR-IOV Operator をデプロイするには、Hosted Control Plane への SR-IOV Operator のデプロイ を参照してください。
1.7.5.2. Amazon Web Services S3 バケットと S3 OIDC シークレットの作成
AWS でホステッドクラスターを作成および管理する予定の場合は、次の手順を実行します。
クラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを持つ S3 バケットを作成します。
us-east-1 リージョンにバケットを作成するには、次のコードを入力します。
BUCKET_NAME=<your_bucket_name> aws s3api create-bucket --bucket $BUCKET_NAME aws s3api delete-public-access-block --bucket $BUCKET_NAME echo '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::${BUCKET_NAME}/*" } ] }' | envsubst > policy.json aws s3api put-bucket-policy --bucket $BUCKET_NAME --policy file://policy.json- us-east-1 リージョン以外のリージョンにバケットを作成するには、次のコードを入力します。
BUCKET_NAME=your-bucket-name REGION=us-east-2 aws s3api create-bucket --bucket $BUCKET_NAME \ --create-bucket-configuration LocationConstraint=$REGION \ --region $REGION aws s3api delete-public-access-block --bucket $BUCKET_NAME echo '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::${BUCKET_NAME}/*" } ] }' | envsubst > policy.json aws s3api put-bucket-policy --bucket $BUCKET_NAME --policy file://policy.json-
HyperShift Operator 用に
hypershift-operator-oidc-provider-s3-credentialsという名前の OIDC S3 シークレットを作成します。 -
シークレットを
local-clusternamespace に保存します。 次の表を参照して、シークレットに次のフィールドが含まれていることを確認します。
フィールド名 説明 bucketHyperShift クラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを備えた S3 バケットが含まれます。
credentialsバケットにアクセスできる
defaultプロファイルの認証情報を含むファイルへの参照。デフォルトでは、HyperShift はdefaultプロファイルのみを使用してバケットを操作します。regionS3 バケットのリージョンを指定します。
次の例は、サンプルの AWS シークレットテンプレートを示しています。
oc create secret generic hypershift-operator-oidc-provider-s3-credentials --from-file=credentials=$HOME/.aws/credentials --from-literal=bucket=<s3-bucket-for-hypershift> --from-literal=region=<region> -n local-cluster
注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に
hypershift-operator-oidc-provider-s3-credentialsシークレットのバックアップを有効にするラベルを追加します。oc label secret hypershift-operator-oidc-provider-s3-credentials -n local-cluster cluster.open-cluster-management.io/backup=true
1.7.5.3. ルーティング可能なパブリックゾーンの作成
ゲストクラスター内のアプリケーションにアクセスするには、パブリックゾーンがルーティング可能である必要があります。パブリックゾーンが存在する場合は、この手順を省略します。省力しない場合は、パブリックゾーンが既存の機能に影響を及ぼします。
次のコマンドを実行して、クラスター DNS レコードのパブリックゾーンを作成します。
BASE_DOMAIN=www.example.com aws route53 create-hosted-zone --name $BASE_DOMAIN --caller-reference $(whoami)-$(date --rfc-3339=date)
1.7.5.4. 外部 DNS の有効化
Hosted control plane ではコントロールプレーンとデータプレーンが分離されているため、次の 2 つの独立した領域で DNS を設定できます。
-
次のドメインなど、ホステッドクラスター内のワークロードの Ingress:
*.apps.service-consumer-domain.com -
サービスプロバイダードメインを介した API または OAUTH エンドポイントなど、管理クラスター内のサービスエンドポイントの受信:
*.service-provider-domain.com
hostedCluster.spec.dns の入力は、ホステッドクラスター内のワークロードの Ingress を決定します。hostedCluster.spec.services.servicePublishingStrategy.route.hostname の入力は、管理クラスター内のサービスエンドポイントの Ingress を決定します。
外部 DNS は、LoadBalancer または Route の公開タイプを指定し、その公開タイプのホスト名を提供するホステッドクラスター Services の名前レコードを作成します。Private または PublicAndPrivate エンドポイントアクセスタイプを持つホステッドクラスターの場合、APIServer サービスと OAuth サービスのみがホスト名をサポートします。Private ホストクラスターの場合、DNS レコードは VPC 内の Virtual Private Cloud (VPC) エンドポイントのプライベート IP に解決されます。
Hosted control plane は、次の 4 つのサービスを公開します。
-
APIServer -
OAuthServer -
Konnectivity -
Ignition
これらの各サービスは、HostedCluster 仕様の servicePublishingStrategy を使用して公開されます。デフォルトでは、servicePublishingStrategy の LoadBalancer および Route タイプの場合、次の 2 つの方法のいずれかでサービスを公開します。
-
LoadBalancerタイプのServiceステータスにあるロードバランサーのホスト名を使用する -
Routeのstatus.hostフィールド
ただし、Hosted control plane をマネージドサービスコンテキストにデプロイメントする場合、これらの方法では、基盤となる管理クラスターの Ingress サブドメインが公開され、管理クラスターのライフサイクルとディザスターリカバリーのオプションが制限される可能性があります。
DNS 間接化が LoadBalancer および Route 公開タイプに階層化されている場合、マネージドサービスオペレーターは、サービスレベルドメインを使用してすべてのパブリックホステッドクラスターサービスを公開できます。このアーキテクチャーでは、DNS 名を新しい LoadBalancer または Route に再マッピングできますが、管理クラスターの Ingress ドメインは公開されません。Hosted control plane は、外部 DNS を使用して間接層を実現します。
管理クラスターの hypershift namespace に hypershift Operator と一緒に external-dns をデプロイできます。外部 DNS は、external-dns.alpha.kubernetes.io/hostname アノテーションを持つ Services または Routes を監視します。このアノテーションは、レコードなどの Service、または CNAME レコードなどの Route を指す DNS レコードを作成するために使用されます。
1.7.5.4.1. 前提条件
Hosted control plane の外部 DNS を設定する前に、次の前提条件を満たす必要があります。
- 指定できる外部パブリックドメイン
- AWS Route53 管理コンソールへのアクセス
1.7.5.4.2. Hosted control plane の外部 DNS の設定
Hosted control plane クラスターをサービスレベル DNS (外部 DNS) でプロビジョニングする予定の場合は、次の手順を実行します。
-
HyperShift Operator の AWS 認証情報シークレットを作成し、
local-clusternamespace でhypershift-operator-external-dns-credentialsという名前を付けます。 次の表を参照して、シークレットに必須フィールドが含まれていることを確認してください。
フィールド名 説明 任意または必須 providerサービスレベル DNS ゾーンを管理する DNS プロバイダー。
必須
domain-filterサービスレベルドメイン。
必須
credentialsすべての外部 DNS タイプをサポートする認証情報ファイル。
AWS キーを使用する場合はオプション
aws-access-key-id認証情報アクセスキー ID。
AWS DNS サービスを使用する場合はオプション
aws-secret-access-key認証情報アクセスキーのシークレット。
AWS DNS サービスを使用する場合はオプション
次の例は、サンプルの
hypershift-operator-external-dns-credentialsシークレットテンプレートを示しています。oc create secret generic hypershift-operator-external-dns-credentials --from-literal=provider=aws --from-literal=domain-filter=service.my.domain.com --from-file=credentials=<credentials-file> -n local-cluster
注記: シークレットのリカバリーバックアップは自動的に有効になりません。
hypershift-operator-external-dns-credentialsシークレットを災害復旧用にバックアップできるようにするラベルを追加するには、次のコマンドを入力します。oc label secret hypershift-operator-external-dns-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
1.7.5.4.3. パブリック DNS ホストゾーンの作成
AWS Route 53 管理コンソールで外部 DNS ドメインフィルターとして使用するパブリック DNS ホストゾーンを作成できます。
- Route 53 管理コンソールで、Create hosted zone をクリックします。
- Hosted zone configuration ページでドメイン名を入力し、タイプとして Publish hosted zone が選択されていることを確認し、Create hosted zone をクリックします。
- ゾーンが作成されたら、Records タブの Value/Route traffic to 列の値をメモします。
- メインドメインで、DNS 要求を委任ゾーンにリダイレクトするための NS レコードを作成します。Value フィールドに、前の手順でメモした値を入力します。
- Create records をクリックします。
新しいサブゾーンにテストエントリーを作成し、次の例のような
digコマンドでテストすることにより、DNS ホストゾーンが機能していることを確認します。dig +short test.user-dest-public.aws.kerberos.com 192.168.1.1
LoadBalancerサービスとRouteサービスのホスト名を設定するホストクラスターを作成するには、次のコマンドを入力します。ここで、external-dns-domainは作成したパブリックホストゾーンと一致します。hypershift create cluster aws --name=example --endpoint-access=PublicAndPrivate --external-dns-domain=service-provider-domain.com ...
この例は、ホステッドクラスターの結果として生じる services ブロックを示しています。
platform:
aws:
endpointAccess: PublicAndPrivate
...
services:
- service: APIServer
servicePublishingStrategy:
route:
hostname: api-example.service-provider-domain.com
type: Route
- service: OAuthServer
servicePublishingStrategy:
route:
hostname: oauth-example.service-provider-domain.com
type: Route
- service: Konnectivity
servicePublishingStrategy:
type: Route
- service: Ignition
servicePublishingStrategy:
type: Route
コントロールプレーンオペレーターは、Services と Routes を作成するときに、external-dns.alpha.kubernetes.io/hostname アノテーションを付けます。値は、そのタイプの servicePublishingStrategy の hostname フィールドです。コントロールプレーンオペレーターは、その名前をサービスエンドポイントに使用し、ホスト名が設定されている場合、external-dns などの DNS レコードを作成できるメカニズムが存在することを期待します。
サービスレベルの DNS 間接化を使用できるのはパブリックサービスのみです。プライベートサービスは hypershift.local プライベートゾーンを使用します。特定のエンドポイントアクセスタイプに対してプライベートなサービスに hostname を設定することは無効です。
次の表は、サービスとエンドポイントの組み合わせに対して hostname を設定することが有効な場合を示しています。
| サービス | Public | PublicAndPrivate | Private |
|---|---|---|---|
|
| Y | Y | N |
|
| Y | Y | N |
|
| Y | N | N |
|
| Y | N | N |
1.7.5.4.4. コマンドラインインターフェイスと外部 DNS を使用したクラスターのデプロイ
外部パブリックホストゾーンがすでに存在する場合は、hypershift operator と external-dns operator をデプロイする必要があります。次のコマンドを入力して、external-dns Operator が実行中であり、内部フラグがパブリックホストゾーンを指していることを確認します。
export KUBECONFIG=<path_to_management_cluster_kubeconfig>
export AWS_CREDS=~/.aws/credentials
export REGION=<region>
hypershift create cluster aws \
--aws-creds ${AWS_CREDS} \
--instance-type m6i.xlarge \
--region ${REGION} \
--auto-repair \
--generate-ssh \
--name <cluster_name> \
--namespace clusters \
--base-domain service-consumer-domain.com \ 1
--node-pool-replicas 2 \
--pull-secret ${HOME}/pull_secret.json \
--release-image quay.io/openshift-release-dev/ocp-release:4.12.0-ec.3-x86_64 \
--external-dns-domain=service-provider-domain.com \ 2
--endpoint-access=PublicAndPrivate 31.7.5.5. AWS PrivateLink の有効化
PrivateLink を使用して AWS プラットフォームで Hosted Control Plane クラスターをプロビジョニングする予定の場合は、次の手順を実行します。
-
HyperShift Operator の AWS 認証情報シークレットを作成し、
hypershift-operator-private-link-credentialsという名前を付けます。シークレットは、ホスティングクラスターとして使用されるマネージドクラスターの namespace であるマネージドクラスター namespace に存在する必要があります。local-clusterを使用した場合は、local-clusternamespace にシークレットを作成します シークレットに必要なフィールドが含まれることを確認するには、以下の表を参照してください。
フィールド名
説明
任意または必須
regionPrivate Link で使用するリージョン
必須
aws-access-key-id認証情報アクセスキー ID。
必須
aws-secret-access-key認証情報アクセスキーのシークレット。
必須
次の例は、サンプルの
hypershift-operator-private-link-credentialsシークレットテンプレートを示しています。oc create secret generic hypershift-operator-private-link-credentials --from-literal=aws-access-key-id=<aws-access-key-id> --from-literal=aws-secret-access-key=<aws-secret-access-key> --from-literal=region=<region> -n local-cluster
注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に
hypershift-operator-private-link-credentialsシークレットのバックアップを有効にするラベルを追加します。oc label secret hypershift-operator-private-link-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
1.7.5.6. ホステッドクラスターのディザスタリカバリー
Hosted Control Plane は、マルチクラスターエンジン Operator ハブクラスター上で実行されます。データプレーンは、選択した別のプラットフォーム上で実行されます。マルチクラスターエンジンの operator ハブクラスターを災害から復旧する場合、ホストされているコントロールプレーンも復旧する必要がある場合があります。
Hosted Control Plane クラスターをバックアップし、別のクラスターに復元する方法は、AWS リージョン内のホステッドクラスターのディザスターリカバリー を参照してください。
重要: ホステッドクラスターの障害復旧は AWS でのみ利用できます。
1.7.5.7. ホステッドクラスターの AWS へのデプロイ
Hosted Control Plane マンドラインインターフェイス (hcp) を設定し、local-cluster ホスティングクラスターとして有効にしたら、次の手順を実行して、AWS にホステッドクラスターをデプロイできます。プライベートホストクラスターをデプロイするには、AWS でのプライベートホストクラスターのデプロイ を参照してください。
環境変数を次のように設定し、必要に応じて変数を認証情報に置き換えます。
export REGION=us-east-1 export CLUSTER_NAME=clc-name-hs1 export INFRA_ID=clc-name-hs1 export BASE_DOMAIN=dev09.red-chesterfield.com export AWS_CREDS=$HOME/name-aws export PULL_SECRET=/Users/username/pull-secret.txt export BUCKET_NAME=acmqe-hypershift export BUCKET_REGION=us-east-1
CLUSTER_NAMEとINFRA_IDの値が同じであることを確認してください。そうしないと、クラスターが Kubernetes Operator コンソールのマルチクラスターエンジンに正しく表示されない可能性があります。各変数の説明を表示するには、次のコマンドを実行します。hcp create cluster aws --help
- ハブクラスターにログインしていることを確認します。
次のコマンドを実行して、ホステッドクラスターを作成します。
hcp create cluster aws \ --name $CLUSTER_NAME \ --infra-id $INFRA_ID \ --base-domain $BASE_DOMAIN \ --aws-creds $AWS_CREDS \ --pull-secret $PULL_SECRET \ --region $REGION \ --generate-ssh \ --node-pool-replicas 3 \ --namespace <hypershift-hosting-service-cluster>注記: デフォルトでは、
HostedClusterとNodePoolのすべてのカスタムリソースがclustersnamespace に作成されます。--namespace <namespace>パラメーターを指定すると、選択した namespace にHostedClusterおよびNodePoolカスタムリソースが作成されます。以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。
oc get hostedclusters -n <hypershift-hosting-service-cluster>
以下のコマンドを実行してノードプールを確認できます。
oc get nodepools --namespace clusters
1.7.5.8. AWS 上の複数のゾーンにホステッドクラスターを作成する
次のコマンドを入力して、パブリックゾーンの BASE_DOMAIN を指定してクラスターを作成します。
REGION=us-east-1
ZONES=us-east-1a,us-east-1b
CLUSTER_NAME=example
BASE_DOMAIN=example.com
AWS_CREDS="$HOME/.aws/credentials"
PULL_SECRET="$HOME/pull-secret"
hcp create cluster aws \
--name $CLUSTER_NAME \
--node-pool-replicas=3 \
--base-domain $BASE_DOMAIN \
--pull-secret $PULL_SECRET \
--aws-creds $AWS_CREDS \
--region $REGION \
--zones $ZONES 1- 1
--zonesフラグは、--regionフラグで指定されたリージョン内のアベイラビリティーゾーンを指定する必要があります。
指定したゾーンごとに、次のインフラストラクチャーが作成されます。
- パブリックサブネット
- プライベートサブネット
- NAT ゲートウェイ
- プライベートルートテーブル (パブリックルートテーブルはパブリックサブネット間で共有されます)
ゾーンごとに 1 つの NodePool リソースが作成されます。ノードプール名の末尾にはゾーン名が付けられます。ゾーンのプライベートサブネットは spec.platform.aws.subnet.id に設定されます。
1.7.5.8.1. AWS でホストされたクラスターを作成するための認証情報の提供
hcp create cluster aws コマンドを使用してホステッドクラスターを作成する場合は、クラスターのインフラストラクチャーリソースを作成する権限が割り当てられた AWS アカウント認証情報を指定する必要があります。インフラストラクチャーリソースの例としては、VPC、サブネット、NAT ゲートウェイなどがあります。AWS 認証情報は、--aws-creds フラグを使用する方法と、マルチクラスターエンジン Operator からの AWS クラウドプロバイダーのシークレットを使用する方法の 2 つの方法で指定できます。
1.7.5.8.1.1. --aws-creds フラグを使用した認証情報の指定
--aws-creds フラグを使用して認証情報を指定する場合は、そのフラグを AWS 認証情報ファイルパスの値に使用します。
以下の例を参照してください。
hcp create cluster aws \ --name $CLUSTER_NAME \ --node-pool-replicas=3 \ --base-domain $BASE_DOMAIN \ --pull-secret $PULL_SECRET \ --aws-creds $AWS_CREDS \ --region $REGION \
1.7.5.8.1.2. AWS クラウドプロバイダーシークレットを使用した認証情報の提供
multicluster engine Operator からの AWS クラウドプロバイダーのシークレットを使用して認証情報を指定する場合、シークレットの形式は次のとおりです。
apiVersion: v1 metadata: name: my-aws-cred 1 namespace: clusters 2 type: Opaque kind: Secret stringData: ssh-publickey: # Value ssh-privatekey: # Value pullSecret: # Value, required baseDomain: # Value, required aws_secret_access_key: # Value, required aws_access_key_id: # Value, required
- 1
- シークレットには SSH 鍵、プルシークレット、ベースドメイン、および AWS 認証情報が含まれているため、
--secret-creds <my_aws_cred>フラグを指定してhcp create cluster awsコマンドを使用できます。<my_aws_cred>はクラウドプロバイダーのシークレット名に置き換えます。 - 2
- シークレットがデフォルトの
クラスターnamespace にない場合は、namespace を指定する必要があります。たとえば、--secret-creds <my_aws_cred> --namespace <name_of_namespace>などです。
このシークレットを使用すると、以下のフラグはオプションです。これらのフラグを --secret-creds <my_aws_cred> フラグと合わせて指定すると、クラウドプロバイダーのシークレットの値よりも優先されます。
-
--aws-creds -
--base-domain -
--pull-secret -
--ssh-key
- {mce-shortF} コンソールを使用してシークレットを作成するには、ナビゲーションメニューから Credentials を選択し、コンソールで認証情報の作成手順に従います。
コマンドラインでシークレットを作成するには、次のコマンドを入力します。
$ oc create secret generic <my_secret> -n <namespace> --from-literal=baseDomain='your.domain.com' --from-literal=aws_access_key_id='your-aws-access-key' --from-literal=aws_secret_access_key='your-aws-secret-key' --from-literal=pullSecret='{"auths":{"cloud.openshift.com":{"auth":"auth-info", "email":"xx@redhat.com"}, "quay.io":{"auth":"auth-info", "email":"xx@redhat.com"} } }' --from-literal=ssh-publickey='your-ssh-publickey' --from-literal=ssh-privatekey='your-ssh-privatekey'
1.7.5.8.2. 関連情報
ホステッドクラスターに AWS Elastic File Service (EFS) CSI Driver Operator をインストールする手順は、セキュリティートークンサービスを使用した AWS EFS CSI Driver Operator の設定 を参照してください。
1.7.5.9. ARM64 OpenShift Container Platform クラスターで Hosted Control Plane を有効にする (テクノロジープレビュー)
ARM64 でホストされるコントロールプレーンを有効にして、管理クラスター環境で OpenShift Container Platform ARM64 データプレーンと連携できるようにすることができます。この機能は、AWS 上の Hosted Control Plane でのみ利用できます。
1.7.5.9.1. 前提条件
64 ビット ARM インフラストラクチャーにインストールされた OpenShift Container Platform クラスターが必要です。詳細は、OpenShift クラスターの作成: AWS (ARM) を参照してください。
1.7.5.9.2. ARM64 OpenShift Container Platform クラスター上でホステッドクラスターを実行する
ARM64 OpenShift Container Platform クラスター上でホステッドクラスターを実行するには、次の手順を完了します。
デフォルトのリリースイメージをマルチアーキテクチャーリリースイメージでオーバーライドするホステッドクラスターを作成します。
たとえば、Hosted Control Plane コマンドラインインターフェイス (
hcp) を介して、次のコマンドを入力します。クラスター名、ノードプールレプリカ、ベースドメイン、プルシークレット、AWS 認証情報、およびリージョンを実際の情報に置き換えます。hcp create cluster aws \ --name $CLUSTER_NAME \ --node-pool-replicas=$NODEPOOL_REPLICAS \ --base-domain $BASE_DOMAIN \ --pull-secret $PULL_SECRET \ --aws-creds $AWS_CREDS \ --region $REGION \ --release-image quay.io/openshift-release-dev/ocp-release:4.13.0-rc.0-multi
この例では、
--node-pool-replicasフラグを使用してデフォルトのNodePoolオブジェクトを追加します。64 ビット x_86
NodePoolオブジェクトをホステッドクラスターに追加します。たとえば、Hosted Control Plane (
hcp) コマンドラインインターフェイスを使用して、次のコマンドを入力します。クラスター名、ノードプール名、ノードプールレプリカを実際の情報に置き換えるよう注意してください。hcp create nodepool aws \ --cluster-name $CLUSTER_NAME \ --name $NODEPOOL_NAME \ --node-count=$NODEPOOL_REPLICAS
1.7.5.9.3. AWS がホストするクラスターでの ARM NodePool オブジェクトの作成
同じ Hosted Control Plane から、64 ビット ARM および AMD64 上のアプリケーションワークロード (NodePool オブジェクト) をスケジュールできます。これを行うには、NodePool 仕様で Arch フィールドを定義し、NodePool オブジェクトに必要なプロセッサーアーキテクチャーを設定します。arch フィールドの有効な値は次のとおりです。
-
arm64 -
amd64
arch フィールドの値を指定しない場合は、デフォルトで amd64 値が使用されます。
AWS 上のホストされたクラスター上に ARM NodePool オブジェクトを作成するには、次の手順を実行します。
HostedClusterカスタムリソースで使用するマルチアーキテクチャーイメージがあることを確認してください。マルチアーキテクチャーの夜間イメージには https://multi.ocp.releases.ci.openshift.org/ でアクセスできます。マルチアーキテクチャーの夜間イメージは次の例のようになります。
% oc image info quay.io/openshift-release-dev/ocp-release-nightly@sha256:9b992c71f77501678c091e3dc77c7be066816562efe3d352be18128b8e8fce94 -a ~/pull-secrets.json error: the image is a manifest list and contains multiple images - use --filter-by-os to select from: OS DIGEST linux/amd64 sha256:c9dc4d07788ebc384a3d399a0e17f80b62a282b2513062a13ea702a811794a60 linux/ppc64le sha256:c59c99d6ff1fe7b85790e24166cfc448a3c2ac3ef3422fce3c7259e48d2c9aab linux/s390x sha256:07fcd16d5bee95196479b1e6b5b3b8064dd5359dac75e3d81f0bd4be6b8fe208 linux/arm64 sha256:1d93a6beccc83e2a4c56ecfc37e921fe73d8964247c1a3ec34c4d66f175d9b3d
Hosted Control Plane のコマンドラインインターフェイス (
hcp) で次のコマンドを入力して、NodePoolオブジェクトをレンダリングします。hcp create nodepool aws --cluster-name $CLUSTER_NAME --name $ARM64_NODEPOOL_NAME --node-count=$NODEPOOL_REPLICAS --render > arm_nodepool_spec.yml
このコマンドは、次の例に示すように、
NodePoolオブジェクトの CPU アーキテクチャーを指定する YAML ファイルを作成します。apiVersion: hypershift.openshift.io/v1beta1 kind: NodePool metadata: creationTimestamp: null name: hypershift-arm-us-east-1a namespace: clusters spec: arch: amd64 clusterName: hypershift-arm management: autoRepair: false upgradeType: Replace nodeDrainTimeout: 0s platform: aws: instanceProfile: hypershift-arm-2m289-worker instanceType: m5.large rootVolume: size: 120 type: gp3 securityGroups: - id: sg-064ea63968d258493 subnet: id: subnet-02c74cf1cf1e7413f type: AWS release: image: quay.io/openshift-release-dev/ocp-release-nightly@sha256:390a33cebc940912a201a35ca03927ae5b058fbdae9626f7f4679786cab4fb1c replicas: 3 status: replicas: 0次のコマンドを入力して、YAML ファイルの
arch値とinstanceType値を変更します。このコマンドでは、ARM インスタンスタイプはm6g.largeですが、どの ARM インスタンスタイプでも機能します。sed 's/arch: amd64/arch: arm64/g; s/instanceType: m5.large/instanceType: m6g.large/g' arm_nodepool_spec.yml > temp.yml && mv temp.yml arm_nodepool_spec.yml
次のコマンドを入力して、レンダリングされた YAML ファイルをホステッドクラスターに適用します。
oc apply -f arm_nodepool_spec.yml
1.7.5.10. ホステッドクラスターへのアクセス
ホステッドクラスターには、kubeconfig ファイルと kubeadmin 認証情報をリソースから直接取得するか、hypershift コマンドラインインターフェイスを使用して kubeconfig ファイルを生成して、アクセスできます。
リソースから
kubeconfigファイルと認証情報を直接取得し、ホステッドクラスターにアクセスするには、Hosted control plane クラスターのアクセスシークレットを理解しておく必要があります。シークレットは、ホステッドクラスター (ホスティング) namespace に保存されます。ホステッドクラスター (ホスティング) namespace にはホステッドクラスターリソースが含まれており、Hosted Control Plane namespace では Hosted Control Plane が実行されます。シークレット名の形式は次のとおりです。
-
kubeconfigシークレット:<hostingNamespace>-<name>-admin-kubeconfig(clusters-hypershift-demo-admin-kubeconfig) kubeadminパスワードシークレット:<hostingNamespace>-<name>-kubeadmin-password(clusters-hypershift-demo-kubeadmin-password)kubeconfigシークレットには Base64 でエンコードされたkubeconfigフィールドが含まれており、これをデコードしてファイルに保存し、次のコマンドで使用できます。oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
kubeadminパスワードシークレットも Base64 でエンコードされます。これをデコードし、そのパスワードを使用して、ホステッドクラスターの API サーバーまたはコンソールにログインできます。-
hypershiftCLI を使用してホステッドクラスターにアクセスし、kubeconfigファイルを生成するには、次の手順を実行します。次のコマンドを入力して、
kubeconfigファイルを生成します。hcp create kubeconfig --namespace ${CLUSTERS_NAMESPACE} --name ${HOSTED_CLUSTER_NAME} > ${HOSTED_CLUSTER_NAME}.kubeconfigkubeconfigファイルを保存した後、次のコマンド例を入力して、ホステッドクラスターにアクセスできます。oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
1.7.5.10.1. 関連情報
ホステッドクラスターへのアクセス後に、ノードプールをスケーリングしたり、ホステッドクラスターのノード自動スケーリングを有効にしたりできます。詳細は、以下のトピックを参照してください。
ホステッドクラスターのノード調整を設定するには、次のトピックを参照してください。
1.7.5.11. プライベートのホステッドクラスターを AWS にデプロイする (テクノロジープレビュー)
Hosted Control Plane (hcp) コマンドラインインターフェイスを設定し、ローカルクラスターを ホスティングクラスターとして有効にすると、ホステッドクラスターまたはプライベートのホステッドクラスターを AWS にデプロイできます。パブリックのホステッドクラスターを AWS にデプロイするには、AWS でのホステッドクラスターのデプロイ を参照してください。
デフォルトでは、Hosted Control Plane のゲストクラスターは、パブリック DNS および管理クラスターのデフォルトルーターを通じてパブリックにアクセスできます。
AWS のプライベートクラスターの場合、ゲストクラスターとのすべての通信は AWS PrivateLink 経由で行われます。AWS でプライベートクラスターをサポートするように Hosted Control Plane を設定するには、次の手順を実行します。
重要: パブリッククラスターは任意のリージョンに作成できますが、プライベートクラスターは --aws-private-region で指定されたリージョンにのみ作成できます。
1.7.5.11.1. 前提条件
AWS のプライベートホストクラスターを有効にするには、まず AWS PrivateLink を有効にする必要があります。詳細は、AWS PrivateLink の有効化 を参照してください。
1.7.5.11.2. AWS 上でプライベートホストクラスターを作成する
次のコマンドを入力して、プライベートクラスター IAM ポリシードキュメントを作成します。
cat << EOF >> policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateVpcEndpointServiceConfiguration", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:DeleteVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServicePermissions", "ec2:ModifyVpcEndpointServicePermissions", "ec2:CreateTags", "elasticloadbalancing:DescribeLoadBalancers" ], "Resource": "\*" } ] }次のコマンドを入力して、AWS で IAM ポリシーを作成します。
aws iam create-policy --policy-name=hypershift-operator-policy --policy-document=file://policy.json
次のコマンドを入力して、
hypershift-operatorIAM ユーザーを作成します。aws iam create-user --user-name=hypershift-operator
次のコマンドを入力して、ポリシーを
hypershift-operatorユーザーにアタッチします。$POLICY_ARNは、作成したポリシーの ARN に置き換えます。aws iam attach-user-policy --user-name=hypershift-operator --policy-arn=$POLICY_ARN
次のコマンドを入力して、ユーザーの IAM アクセスキーを作成します。
aws iam create-access-key --user-name=hypershift-operator
次のコマンドを入力して、プライベートホストクラスターを作成します。必要に応じて、変数を実際の値に置き換えます。
CLUSTER_NAME=example BASE_DOMAIN=example.com AWS_CREDS="$HOME/.aws/credentials" PULL_SECRET="$HOME/pull-secret" hcp create cluster aws \ --name $CLUSTER_NAME \ --node-pool-replicas=3 \ --base-domain $BASE_DOMAIN \ --pull-secret $PULL_SECRET \ --aws-creds $AWS_CREDS \ --region $REGION \ --endpoint-access Private 1- 1
--endpoint-accessフラグは、クラスターがパブリックかプライベートかを指定します。
クラスターの API エンドポイントには、プライベート DNS ゾーンを通じてアクセスできます。
-
api.$CLUSTER_NAME.hypershift.local -
*.apps.$CLUSTER_NAME.hypershift.local
1.7.5.11.3. AWS 上のプライベートホスティングクラスターへのアクセス
プライベートクラスターにアクセスするには、踏み台を使用します。
次のコマンドを入力して要塞インスタンスを起動します。
$SSH_KEYは踏み台に接続するための認証情報に置き換えます。hypershift create bastion aws --aws-creds=$AWS_CREDS --infra-id=$INFRA_ID --region=$REGION --ssh-key-file=$SSH_KEY
次のコマンドを入力して、クラスターノードプール内のノードのプライベート IP を検索します。
aws ec2 describe-instances --filter="Name=tag:kubernetes.io/cluster/$INFRA_ID,Values=owned" | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") | .PrivateIpAddress'
次のコマンドを入力して、ノードにコピーできるクラスターの
kubeconfigファイルを作成します。hcp create kubeconfig > $CLUSTER_KUBECONFIG
次のコマンドを入力して、
create bastionコマンドから出力された IP を使用して踏み台を介していずれかのノードに SSH 接続します。ssh -o ProxyCommand="ssh ec2-user@$BASTION_IP -W %h:%p" core@$NODE_IP
SSH シェルから、次のコマンドを入力して、
kubeconfigファイルの内容をノード上のファイルにコピーします。cat << EOF >> kubeconfig <paste kubeconfig contents> export KUBECONFIG=$PWD/kubeconfig
SSH シェルから、ゲストクラスターのステータスを確認するか、次の例に示すように他の
ocコマンドを実行します。oc get clusteroperators oc get clusterversion
1.7.5.11.4. 関連情報
AWS でのパブリックホステッドクラスターのデプロイの詳細は、AWS でのホステッドクラスターのデプロイ を参照してください。
1.7.5.12. AWS インフラストラクチャーと Hosted Control Plane の IAM 権限の管理 (テクノロジープレビュー)
AWS で Red Hat OpenShift Container Platform のホストされているコントロールプレーンを使用する場合、インフラストラクチャーの要件はセットアップに応じて異なります。
1.7.5.12.1. 前提条件
Hosted Control Plane クラスターを作成する前に、Hosted Control Plane を設定する必要があります。詳細は、AWS での Hosted Control Plane クラスターの設定 (テクノロジープレビュー) を参照してください。
1.7.5.12.2. AWS インフラストラクチャーの要件
AWS で Hosted Control Plane を使用する場合、インフラストラクチャー要件は次のカテゴリーに当てはまります。
- 任意の AWS アカウントの HyperShift Operator に必要なマネージド外のインフラストラクチャー
- ホステッドクラスターの AWS アカウント内の事前に必要な管理対象外インフラストラクチャー
- 管理 AWS アカウント内の Hosted Control Plane によって管理されるインフラストラクチャー
- ホステッドクラスターの AWS アカウント内の Hosted Control Plane によって管理されるインフラストラクチャー
- ホステッドクラスターの Kubernetes 管理インフラストラクチャー AWS アカウント
Prerequired とは、Hosted Control Plane が適切に動作するために AWS インフラストラクチャーが必要であることを意味します。Unmanaged とは、Operator またはコントローラーがインフラストラクチャーを作成しないことを意味します。次のセクションには、AWS リソースの作成に関する詳細が含まれています。
1.7.5.12.2.1. 任意の AWS アカウントの HyperShift Operator に必要なマネージド外のインフラストラクチャー
任意の AWS アカウントは、ホストされるコントロールプレーンサービスのプロバイダーに依存します。
自己管理型の Hosted Control Plane では、クラスターサービスプロバイダーが AWS アカウントを制御します。クラスターサービスプロバイダー は、クラスターコントロールプレーンをホストする管理者であり、アップタイムを行います。管理対象の Hosted Control Plane では、AWS アカウントは Red Hat に属します。
HyperShift Operator の必須の非管理インフラストラクチャーでは、管理クラスター AWS アカウントに次のインフラストラクチャー要件が適用されます。
1 つの S3 バケット
- OpenID Connect (OIDC)
ルート 53 のホステッドゾーン
- ホステッドクラスターのプライベートおよびパブリックエントリーをホストするドメイン
1.7.5.12.2.2. ホステッドクラスターの AWS アカウントで事前に必要なマネージド外のインフラストラクチャー
インフラストラクチャーが事前に必要であり、ホステッドクラスター AWS アカウントで管理されていない場合、すべてのアクセスモードのインフラストラクチャー要件は次のとおりです。
- 1 つの VPC
- 1 つの DHCP オプション
2 つのサブネット
- 内部データプレーンサブネットであるプライベートサブネット
- データプレーンからインターネットへのアクセスを可能にするパブリックサブネット
- 1 つのインターネットゲートウェイ
- 1 つの Elastic IP
- 1 つの NAT ゲートウェイ
- 1 つのセキュリティーグループ (ワーカーノード)
- 2 つのルートテーブル (1 つはプライベート、もう 1 つはパブリック)
- 2 つの Route 53 のホステッドゾーン
次の項目に対する十分なクォータ:
- パブリックホステッドクラスター用の 1 つの Ingress サービスロードバランサー
- プライベートホストクラスター用の 1 つのプライベートリンクエンドポイント
注記: プライベートリンクネットワーキングが機能するには、ホステッドクラスター AWS アカウントのエンドポイントゾーンが、管理クラスター AWS アカウントのサービスエンドポイントによって解決されるインスタンスのゾーンと一致する必要があります。AWS では、ゾーン名は us-east-2b などのエイリアスであり、異なるアカウントの同じゾーンにマップされるとは限りません。そのため、プライベートリンクが機能するには、管理クラスターのリージョンのすべてのゾーンにサブネットまたはワーカーが必要です。
1.7.5.12.2.3. 管理 AWS アカウント内の Hosted Control Plane 管理インフラストラクチャー
インフラストラクチャーが管理 AWS アカウントの Hosted Control Plane によって管理されている場合、インフラストラクチャーの要件は、クラスターがパブリック、プライベート、またはその組み合わせであるかによって異なります。
パブリッククラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。
ネットワークロードバランサー: ロードバランサー Kube API サーバー
- Kubernetes がセキュリティーグループを作成する
ボリューム
- etcd 用 (高可用性に応じて 1 つまたは 3 つ)
- OVN-Kube 用
プライベートクラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。
- ネットワークロードバランサー: ロードバランサーのプライベートルーター
- エンドポイントサービス (プライベートリンク)
パブリッククラスターとプライベートクラスターを持つアカウントの場合、インフラストラクチャー要件は次のとおりです。
- ネットワークロードバランサー: ロードバランサーのパブリックルーター
- ネットワークロードバランサー: ロードバランサーのプライベートルーター
- エンドポイントサービス (プライベートリンク)
Volumes:
- etcd の場合 (高可用性に応じて 1 つまたは 3 つ)
- OVN-Kube の場合
1.7.5.12.2.4. ホステッドクラスター内の Hosted Control Plane 管理インフラストラクチャー AWS アカウント
インフラストラクチャーがホステッドクラスター AWS アカウントの Hosted Control Plane によって管理されている場合、インフラストラクチャー要件は、クラスターがパブリック、プライベート、またはその組み合わせであるかによって異なります。
パブリッククラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。
-
ノードプールには、
RoleとRolePolicyが定義された EC2 インスタンスが必要です。
プライベートクラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。
- アベイラビリティーゾーンごとに 1 つのプライベートリンクエンドポイント
- ノードプールの EC2 インスタンス
パブリッククラスターとプライベートクラスターを持つアカウントの場合、インフラストラクチャー要件は次のとおりです。
- アベイラビリティーゾーンごとに 1 つのプライベートリンクエンドポイント
- ノードプールの EC2 インスタンス
1.7.5.12.2.5. ホステッドクラスターの Kubernetes 管理インフラストラクチャー AWS アカウント
Kubernetes がホステッドクラスター AWS アカウントでインフラストラクチャーを管理する場合、インフラストラクチャー要件は次のとおりです。
- デフォルトの Ingress 用のネットワークロードバランサー
- レジストリー用の S3 バケット
1.7.5.12.3. Identity and Access Management (IAM) 権限
Hosted Control Plane のコンテキストでは、コンシューマーが Amazon Resource Name (ARN) ロールを作成する役割を果たします。コンシューマー は、アクセス許可ファイルを生成する自動プロセスです。コンシューマーはコマンドラインインターフェイスまたは OpenShift Cluster Manager である可能性があります。Hosted Control Plane は、最小特権コンポーネントの原則を尊重する粒度を有効にしようとします。つまり、すべてのコンポーネントが独自のロールを使用して AWS オブジェクトを操作または作成し、ロールは製品が正常に機能するために必要なものに限定されます。
コマンドラインインターフェイスで ARN ロールを作成する方法の例は、「AWS インフラストラクチャーと IAM リソースを個別に作成する」を参照してください。
ホステッドクラスターは ARN ロールを入力として受け取り、コンシューマーは各コンポーネントの AWS 権限設定を作成します。その結果、コンポーネントは STS および事前設定された OIDC IDP を通じて認証できるようになります。
次のロールは、コントロールプレーン上で実行され、データプレーン上で動作する、Hosted Control Plane の一部のコンポーネントによって消費されます。
-
controlPlaneOperatorARN -
imageRegistryARN -
ingressARN -
kubeCloudControllerARN -
nodePoolManagementARN -
storageARN -
networkARN
次の例は、ホステッドクラスターからの IAM ロールへの参照を示しています。
...
endpointAccess: Public
region: us-east-2
resourceTags:
- key: kubernetes.io/cluster/example-cluster-bz4j5
value: owned
rolesRef:
controlPlaneOperatorARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-control-plane-operator
imageRegistryARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-openshift-image-registry
ingressARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-openshift-ingress
kubeCloudControllerARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-cloud-controller
networkARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-cloud-network-config-controller
nodePoolManagementARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-node-pool
storageARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-aws-ebs-csi-driver-controller
type: AWS
...Hosted Control Plane が使用するロールを次の例に示します。
ingressARN{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "elasticloadbalancing:DescribeLoadBalancers", "tag:GetResources", "route53:ListHostedZones" ], "Resource": "\*" }, { "Effect": "Allow", "Action": [ "route53:ChangeResourceRecordSets" ], "Resource": [ "arn:aws:route53:::PUBLIC_ZONE_ID", "arn:aws:route53:::PRIVATE_ZONE_ID" ] } ] }imageRegistryARN{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket", "s3:DeleteBucket", "s3:PutBucketTagging", "s3:GetBucketTagging", "s3:PutBucketPublicAccessBlock", "s3:GetBucketPublicAccessBlock", "s3:PutEncryptionConfiguration", "s3:GetEncryptionConfiguration", "s3:PutLifecycleConfiguration", "s3:GetLifecycleConfiguration", "s3:GetBucketLocation", "s3:ListBucket", "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": "\*" } ] }storageARN{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AttachVolume", "ec2:CreateSnapshot", "ec2:CreateTags", "ec2:CreateVolume", "ec2:DeleteSnapshot", "ec2:DeleteTags", "ec2:DeleteVolume", "ec2:DescribeInstances", "ec2:DescribeSnapshots", "ec2:DescribeTags", "ec2:DescribeVolumes", "ec2:DescribeVolumesModifications", "ec2:DetachVolume", "ec2:ModifyVolume" ], "Resource": "\*" } ] }networkARN{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:DescribeInstanceStatus", "ec2:DescribeInstanceTypes", "ec2:UnassignPrivateIpAddresses", "ec2:AssignPrivateIpAddresses", "ec2:UnassignIpv6Addresses", "ec2:AssignIpv6Addresses", "ec2:DescribeSubnets", "ec2:DescribeNetworkInterfaces" ], "Resource": "\*" } ] }kubeCloudControllerARN{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeRegions", "ec2:DescribeRouteTables", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVolumes", "ec2:CreateSecurityGroup", "ec2:CreateTags", "ec2:CreateVolume", "ec2:ModifyInstanceAttribute", "ec2:ModifyVolume", "ec2:AttachVolume", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateRoute", "ec2:DeleteRoute", "ec2:DeleteSecurityGroup", "ec2:DeleteVolume", "ec2:DetachVolume", "ec2:RevokeSecurityGroupIngress", "ec2:DescribeVpcs", "elasticloadbalancing:AddTags", "elasticloadbalancing:AttachLoadBalancerToSubnets", "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer", "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateLoadBalancerPolicy", "elasticloadbalancing:CreateLoadBalancerListeners", "elasticloadbalancing:ConfigureHealthCheck", "elasticloadbalancing:DeleteLoadBalancer", "elasticloadbalancing:DeleteLoadBalancerListeners", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeLoadBalancerAttributes", "elasticloadbalancing:DetachLoadBalancerFromSubnets", "elasticloadbalancing:DeregisterInstancesFromLoadBalancer", "elasticloadbalancing:ModifyLoadBalancerAttributes", "elasticloadbalancing:RegisterInstancesWithLoadBalancer", "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer", "elasticloadbalancing:AddTags", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:DeleteListener", "elasticloadbalancing:DeleteTargetGroup", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeLoadBalancerPolicies", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetHealth", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:ModifyTargetGroup", "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:SetLoadBalancerPoliciesOfListener", "iam:CreateServiceLinkedRole", "kms:DescribeKey" ], "Resource": [ "\*" ], "Effect": "Allow" } ] }nodePoolManagementARN{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:AllocateAddress", "ec2:AssociateRouteTable", "ec2:AttachInternetGateway", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateInternetGateway", "ec2:CreateNatGateway", "ec2:CreateRoute", "ec2:CreateRouteTable", "ec2:CreateSecurityGroup", "ec2:CreateSubnet", "ec2:CreateTags", "ec2:DeleteInternetGateway", "ec2:DeleteNatGateway", "ec2:DeleteRouteTable", "ec2:DeleteSecurityGroup", "ec2:DeleteSubnet", "ec2:DeleteTags", "ec2:DescribeAccountAttributes", "ec2:DescribeAddresses", "ec2:DescribeAvailabilityZones", "ec2:DescribeImages", "ec2:DescribeInstances", "ec2:DescribeInternetGateways", "ec2:DescribeNatGateways", "ec2:DescribeNetworkInterfaces", "ec2:DescribeNetworkInterfaceAttribute", "ec2:DescribeRouteTables", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:DescribeVpcAttribute", "ec2:DescribeVolumes", "ec2:DetachInternetGateway", "ec2:DisassociateRouteTable", "ec2:DisassociateAddress", "ec2:ModifyInstanceAttribute", "ec2:ModifyNetworkInterfaceAttribute", "ec2:ModifySubnetAttribute", "ec2:ReleaseAddress", "ec2:RevokeSecurityGroupIngress", "ec2:RunInstances", "ec2:TerminateInstances", "tag:GetResources", "ec2:CreateLaunchTemplate", "ec2:CreateLaunchTemplateVersion", "ec2:DescribeLaunchTemplates", "ec2:DescribeLaunchTemplateVersions", "ec2:DeleteLaunchTemplate", "ec2:DeleteLaunchTemplateVersions" ], "Resource": [ "\*" ], "Effect": "Allow" }, { "Condition": { "StringLike": { "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com" } }, "Action": [ "iam:CreateServiceLinkedRole" ], "Resource": [ "arn:*:iam::*:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing" ], "Effect": "Allow" }, { "Action": [ "iam:PassRole" ], "Resource": [ "arn:*:iam::*:role/*-worker-role" ], "Effect": "Allow" } ] }controlPlaneOperatorARN{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateVpcEndpoint", "ec2:DescribeVpcEndpoints", "ec2:ModifyVpcEndpoint", "ec2:DeleteVpcEndpoints", "ec2:CreateTags", "route53:ListHostedZones" ], "Resource": "\*" }, { "Effect": "Allow", "Action": [ "route53:ChangeResourceRecordSets", "route53:ListResourceRecordSets" ], "Resource": "arn:aws:route53:::%s" } ] }
1.7.5.12.4. AWS インフラストラクチャーと IAM リソースを個別に作成する
デフォルトでは、hcp create cluster aws コマンドは、ホステッドクラスターを使用してクラウドインフラストラクチャーを作成し、それを適用します。クラウドインフラストラクチャー部分を個別に作成して、hcp create cluster aws コマンドをクラスターの作成のみに使用したり、クラスターを適用する前に変更できるようにレンダリングしたりすることができます。
クラウドインフラストラクチャー部分を個別に作成するには、AWS インフラストラクチャーを作成し、AWS Identity and Access (IAM) リソースを作成し、クラスターを作成する必要があります。
1.7.5.12.4.1. AWS インフラストラクチャーの作成
AWS インフラストラクチャーを作成するには、次のコマンドを入力します。
hypershift create infra aws --name CLUSTER_NAME \ 1 --aws-creds AWS_CREDENTIALS_FILE \ 2 --base-domain BASEDOMAIN \ 3 --infra-id INFRA_ID \ 4 --region REGION \ 5 --output-file OUTPUT_INFRA_FILE 6
- 1
CLUSTER_NAMEを、作成しているホステッドクラスターの名前に置き換えます。この値は、クラスターの Route 53 プライベートのホステッドゾーンを作成するために使用されます。- 2
AWS_CREDENTIALS_FILEを、VPC、サブネット、NAT ゲートウェイなどのクラスターのインフラストラクチャーリソースを作成する権限を持つ AWS 認証情報ファイルの名前に置き換えます。この値は、ワーカーが存在するゲストクラスターの AWS アカウントに対応する必要があります。- 3
BASEDOMAINを、ホステッドクラスター Ingress に使用する予定のベースドメインの名前に置き換えます。この値は、レコードを作成できる Route 53 パブリックゾーンに対応している必要があります。- 4
INFRA_IDをタグを使用してインフラストラクチャーを識別する一意の名前に置き換えます。この値は、Kubernetes のクラウドコントローラーマネージャーとクラスター API マネージャーによってクラスターのインフラストラクチャーを識別するために使用されます。通常、この値はクラスターの名前 (CLUSTER_NAME) に接尾辞を追加したものです。- 5
REGIONをクラスターのインフラストラクチャーを作成するリージョンに置き換えます。- 6
OUTPUT_INFRA_FILEをインフラストラクチャーの ID を JSON 形式で保存するファイルの名前に置き換えます。このファイルをhcp create cluster awsコマンドへの入力として使用し、HostedClusterリソースとNodePoolリソースのフィールドに値を設定できます。
コマンドを入力すると、次のリソースが作成されます。
- 1 つの VPC
- 1 つの DHCP オプション
- 1 つのプライベートサブネット
- 1 つのパブリックサブネット
- 1 つのインターネットゲートウェイ
- 1 つの NAT ゲートウェイ
- ワーカーノード用の 1 つのセキュリティーグループ
- 2 つのルートテーブル: 1 つはプライベート、もう 1 つはパブリック
- 2 つのプライベートホストゾーン: クラスター Ingress 用に 1 つ、PrivateLink 用に 1 つ (プライベートクラスターを作成する場合)
これらのリソースにはすべて、kubernetes.io/cluster/INFRA_ID=owned タグが含まれています。ここで、INFRA_ID はコマンドで指定した値です。
1.7.5.12.4.2. AWS IAM リソースの作成
AWS IAM リソースを作成するには、次のコマンドを入力します。
hypershift create iam aws --infra-id INFRA_ID \ 1 --aws-creds AWS_CREDENTIALS_FILE \ 2 --oidc-storage-provider-s3-bucket-name OIDC_BUCKET_NAME \ 3 --oidc-storage-provider-s3-region OIDC_BUCKET_REGION \ 4 --region REGION \ 5 --public-zone-id PUBLIC_ZONE_ID \ 6 --private-zone-id PRIVATE_ZONE_ID \ 7 --local-zone-id LOCAL_ZONE_ID \ 8 --output-file OUTPUT_IAM_FILE 9
- 1
INFRA_IDをcreate infra awsコマンドで指定したのと同じ ID に置き換えます。この値は、ホステッドクラスターに関連付けられている IAM リソースを識別します。- 2
AWS_CREDENTIALS_FILEをロールなどの IAM リソースを作成する権限を持つ AWS 認証情報ファイルの名前に置き換えます。このファイルは、インフラストラクチャーを作成するために指定した認証情報ファイルと同じである必要はありませんが、同じ AWS アカウントに対応している必要があります。- 3
OIDC_BUCKET_NAMEを、OIDC ドキュメントを保存するバケットの名前に置き換えます。このバケットは、Hosted Control Plane をインストールするための前提条件として作成されました。バケットの名前は、このコマンドによって作成される OIDC プロバイダーの URL を構築するために使用されます。- 4
OIDC_BUCKET_REGIONを、OIDC バケットが存在するリージョンに置き換えます。- 5
REGIONをクラスターのインフラストラクチャーが配置されているリージョンに置き換えます。この値は、ホステッドクラスターに属するマシンのワーカーインスタンスプロファイルを作成するために使用されます。- 6
PUBLIC_ZONE_IDをゲストクラスターのパブリックゾーンの ID に置き換えます。この値は、Ingress Operator のポリシーを作成するために使用されます。この値はcreate infra awsコマンドによって生成されるOUTPUT_INFRA_FILEで確認できます。- 7
PRIVATE_ZONE_IDをゲストクラスターのプライベートゾーンの ID に置き換えます。この値は、Ingress Operator のポリシーを作成するために使用されます。この値はcreate infra awsコマンドによって生成されるOUTPUT_INFRA_FILEで確認できます。- 8
LOCAL_ZONE_IDは、プライベートクラスターの作成時にゲストクラスターのローカルゾーンの ID に置き換えます。この値は、コントロールプレーンオペレーターのポリシーを作成するために使用され、PrivateLink エンドポイントのレコードを管理できるようになります。この値はcreate infra awsコマンドによって生成されるOUTPUT_INFRA_FILEで確認できます。- 9
OUTPUT_IAM_FILEを IAM リソースの ID を JSON 形式で保存するファイルの名前に置き換えます。その後、このファイルをhcp create cluster awsコマンドへの入力として使用して、HostedClusterリソースとNodePoolリソースのフィールドに値を設定できます。
コマンドを入力すると、次のリソースが作成されます。
- 1 つの OIDC プロバイダー。STS 認証を有効にするために必要です。
- 7 つのロール。Kubernetes コントローラーマネージャー、クラスター API プロバイダー、レジストリーなど、プロバイダーと対話するコンポーネントごとに分かれています。
- 1 つのインスタンスプロファイル。クラスターのすべてのワーカーインスタンスに割り当てられるプロファイルです。
1.7.5.12.4.3. クラスターの作成
クラスターを作成するには、次のコマンドを入力します。
hcp create cluster aws \
--infra-id INFRA_ID \ 1
--name CLUSTER_NAME \ 2
--aws-creds AWS_CREDENTIALS \ 3
--pull-secret PULL_SECRET_FILE \ 4
--generate-ssh \ 5
--node-pool-replicas 3- 1
INFRA_IDをcreate infra awsコマンドで指定したのと同じ ID に置き換えます。この値は、ホステッドクラスターに関連付けられている IAM リソースを識別します。- 2
CLUSTER_NAMEをcreate infra awsコマンドで指定したのと同じ名前に置き換えます。- 3
AWS_CREDENTIALSをcreate infra awsコマンドで指定したのと同じ値に置き換えます。- 4
PULL_SECRET_FILEを有効な OpenShift Container Platform プルシークレットを含むファイルの名前に置き換えます。- 5
--generate-sshフラグはオプションですが、ワーカーに SSH 接続する必要がある場合に含めるとよいでしょう。SSH キーが生成され、ホステッドクラスターと同じ名 namespace にシークレットとして保存されます。
コマンドに --render フラグを追加して、クラスターに適用する前にリソースを編集できるファイルに出力をリダイレクトすることもできます。
コマンドを実行すると、次のリソースがクラスターに適用されます。
- namespace
- プルシークレットを含むシークレット
-
HostedCluster -
NodePool - コントロールプレーンコンポーネントの 3 つの AWS STS シークレット
-
--generate-sshフラグを指定した場合は、1 つの SSH キーシークレット。
1.7.5.13. AWS でのホステッドクラスターの破棄
ホステッドクラスターとそのマネージドクラスターリソースを破棄するには、次の手順を実行します。
次のコマンドを実行して、multicluster engine Operator のマネージドクラスターリソースを削除します。
oc delete managedcluster <cluster_name>
cluster_nameはクラスターの名前に置き換えます。次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。
hcp destroy cluster aws --name <cluster_name> --infra-id <infra_id> --aws-creds <aws-credentials> --base-domain <base_domain>
必要に応じて名前を置き換えます。
1.7.6. ベアメタルでの Hosted Control Plane クラスターの設定
ホスティングクラスターとして機能するようにクラスターを設定することで、Hosted Control Plane をデプロイメントできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。ホスティングクラスターは 管理 クラスターとも呼ばれます。
注記: 管理クラスターは、マネージド クラスターとは異なります。マネージドクラスターは、ハブクラスターが管理するクラスターです。
Hosted control plane 機能がデフォルトで有効になりました。
multicluster engine operator 2.4 は、管理されるハブクラスターであるデフォルトの local-cluster と、ホスティングクラスターとしてのハブクラスターのみをサポートします。Red Hat Advanced Cluster Management 2.9 では、local-cluster としても知られるマネージドハブクラスターをホスティングクラスターとして使用できます。
ホストされたクラスター は、ホスティングクラスターでホストされる API エンドポイントとコントロールプレーンを含む OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。マルチクラスターエンジンの Operator コンソールまたは Hosted Control Plane のコマンドラインインターフェイス hcp を使用して、ホステッドクラスターを作成できます。ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、マルチクラスターエンジン Operator へのホストクラスターの自動インポートの無効化 を参照してください。
重要:
- マルチクラスターエンジン Operator が管理できるように、各ホストクラスターには一意の名前が必要です。
- Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
- マルチクラスターエンジン Operator が管理できるように、各ホストクラスターには一意の名前が必要です。
- ホステッドクラスターは、マルチクラスターエンジンの operator 管理クラスターの namespace には作成できません。
- エージェントプラットフォームを使用して、Hosted Control Plane をベアメタルでプロビジョニングできます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。central infrastructure management の概要は、central infrastructure management の有効化 を参照してください。
-
各ベアメタルホストは、central infrastructure management が提供する検出イメージを使用して開始する必要があります。ホストは手動で起動することも、
Cluster-Baremetal-Operatorを使用して自動化することもできます。各ホストが起動すると、エージェントプロセスが実行され、ホストの詳細が検出され、インストールが完了します。Agentカスタムリソースは、各ホストを表します。 - エージェントプラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane (HCP) namespace に Agent Cluster API プロバイダーをインストールします。
- ノードプールをスケールアップすると、マシンが作成されます。Cluster API プロバイダーは、承認され、検証に合格し、現在使用されておらず、ノードプールの仕様で指定されている要件を満たすエージェントを見つけます。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
- ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。クラスターを再利用する前に、Discovery Image を使用してクラスターを再起動し、ノード数を更新する必要があります。
- Hosted control plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、OpenShift Container Platform ドキュメントの 推奨される etcd プラクティス および 論理ボリュームマネージャーストレージを使用した永続ストレージ を参照してください。
1.7.6.1. 前提条件
ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。
- OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.2 以降のマルチクラスターエンジンが必要です。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。OpenShift Container Platform OperatorHub から Operator として Red Hat Advanced Cluster Management を使用せずに、マルチクラスターエンジン Operator をインストールすることもできます。
マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。
local-clusterは、マルチクラスターエンジン Operator 2.2 以降で自動的にインポートされます。local-clusterの詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。oc get managedclusters local-cluster
- Central Infrastructure Management を有効にする必要があります。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
- Hosted control plane コマンドラインインターフェイスをインストールする 必要があります。
1.7.6.2. ベアメタルのファイアウォールとポートの要件
ポートが管理クラスター、コントロールプレーン、ホストクラスター間で通信できるように、ファイアウォールとポートの要件を満たしていることを確認します。
kube-apiserverサービスはデフォルトでポート 6443 で実行され、コントロールプレーンコンポーネント間の通信には ingress アクセスが必要です。-
NodePort公開ストラテジーを使用する場合は、kube-apiserverサービスに割り当てられたノードポートが公開されていることを確認してください。 - MetalLB ロードバランシングを使用する場合は、ロードバランサーの IP アドレスに使用される IP 範囲への ingress アクセスを許可します。
-
-
NodePort公開ストラテジーを使用する場合は、ignition-serverおよびOauth-server設定にファイアウォールルールを使用します。 konnectivityエージェントは、ホステッドクラスター上で双方向通信を可能にするリバーストンネルを確立し、ポート 6443 でクラスター API サーバーアドレスへの egress アクセスを必要とします。この egress アクセスを使用すると、エージェントはkube-apiserverサービスにアクセスできます。- クラスター API サーバーのアドレスが内部 IP アドレスの場合は、ワークロードサブネットからポート 6443 の IP アドレスへのアクセスを許可します。
- アドレスが外部 IP アドレスの場合は、ノードからその外部 IP アドレスにポート 6443 で送信できるように許可します。
- デフォルトのポート 6443 を変更する場合は、その変更を反映するようにルールを調整します。
- クラスター内で実行されるワークロードに必要なポートがすべて開いていることを確認してください。
- ファイアウォールルール、セキュリティーグループ、またはその他のアクセス制御を使用して、必要なソースだけにアクセスを制限します。必要な場合を除き、ポートを公開しないでください。
- 実稼働環境の場合は、ロードバランサーを使用して、単一の IP アドレスによるアクセスを簡素化します。
1.7.6.3. ベアメタルインフラストラクチャーの要件
エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャーに関して次の要件があります。
- Agent: Agent は、Discovery イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングされる準備ができているホストを表します。
- DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。
ベアメタル上の Hosted Control Plane の関連資料については、次のドキュメントを参照してください。
- etcd および LVM ストレージの推奨事項の詳細は、推奨される etcd プラクティス および 論理ボリュームマネージャーストレージを使用した永続ストレージ を参照してください。
- 非接続環境でベアメタル上に Hosted Control Plane を設定するには、非接続環境での Hosted Control Plane の設定 を参照してください。
- Hosted Control Plane 機能を無効にするか、すでに無効にしていて手動で有効にする場合は、Hosted Control Plane 機能の有効化または無効化 を参照してください。
- Red Hat Ansible Automation Platform ジョブを実行してホステッドクラスターを管理するには、ホステッドクラスターで実行するための Ansible Automation Platform ジョブの設定 を参照してください。
- SR-IOV Operator をデプロイするには、Hosted Control Plane への SR-IOV Operator のデプロイ を参照してください。
- この自動インポート機能を無効にする場合は、マルチクラスターエンジン Operator へのホストクラスターの自動インポートの無効化 を参照してください。
1.7.6.4. ベアメタルでの DNS の設定
ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達できる宛先を指す api.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN} に、DNS エントリーが存在する必要があります。
DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。
次の DNS 設定の例を参照してください。
api.example.krnl.es. IN A 192.168.122.20 api.example.krnl.es. IN A 192.168.122.21 api.example.krnl.es. IN A 192.168.122.22 api-int.example.krnl.es. IN A 192.168.122.20 api-int.example.krnl.es. IN A 192.168.122.21 api-int.example.krnl.es. IN A 192.168.122.22 `*`.apps.example.krnl.es. IN A 192.168.122.23
IPv6 ネットワークで非接続環境の DNS を設定する場合は、次の DNS 設定の例を参照してください。
api.example.krnl.es. IN A 2620:52:0:1306::5 api.example.krnl.es. IN A 2620:52:0:1306::6 api.example.krnl.es. IN A 2620:52:0:1306::7 api-int.example.krnl.es. IN A 2620:52:0:1306::5 api-int.example.krnl.es. IN A 2620:52:0:1306::6 api-int.example.krnl.es. IN A 2620:52:0:1306::7 `*`.apps.example.krnl.es. IN A 2620:52:0:1306::10
デュアルスタックネットワークの非接続環境で DNS を設定する場合は、IPv4 と IPv6 の両方の DNS エントリーを含めるようにしてください。次の DNS 設定の例を参照してください。
host-record=api-int.hub-dual.dns.base.domain.name,192.168.126.10 host-record=api.hub-dual.dns.base.domain.name,192.168.126.10 address=/apps.hub-dual.dns.base.domain.name/192.168.126.11 dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,192.168.126.20 dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,192.168.126.21 dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,192.168.126.22 dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,192.168.126.25 dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,192.168.126.26 host-record=api-int.hub-dual.dns.base.domain.name,2620:52:0:1306::2 host-record=api.hub-dual.dns.base.domain.name,2620:52:0:1306::2 address=/apps.hub-dual.dns.base.domain.name/2620:52:0:1306::3 dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,[2620:52:0:1306::5] dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,[2620:52:0:1306::6] dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,[2620:52:0:1306::7] dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,[2620:52:0:1306::8] dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,[2620:52:0:1306::9]
次に、ベアメタルに Hosted Control Plane の ホストインベントリーを作成 します。
1.7.6.5. ベアメタルでのホステッドクラスターの作成
ベアメタルでホステッドクラスターを作成するか、インポートできます。ホステッドクラスターをインポートする手順は、ホステッドクラスターのインポート を参照してください。
ホステッドコントロールプレーン namespace を作成するには、次のコマンドを実行します。
oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>
<hosted_cluster_namespace>を、ホストされたクラスターの namespace 名 (例:clusters) に置き換えます。<hosted_cluster_name>は、ホステッドクラスターの名前に置き換えます。クラスターにデフォルトのストレージクラスが設定されていることを確認します。そうしないと、保留中の PVC が表示される場合があります。以下のコマンドを実行します。
hcp create cluster agent \ --name=<hosted_cluster_name> \ 1 --pull-secret=<path_to_pull_secret> \ 2 --agent-namespace=<hosted_control_plane_namespace> \ 3 --base-domain=<basedomain> \ 4 --api-server-address=api.<hosted_cluster_name>.<basedomain> \ --etcd-storage-class=<etcd_storage_class> \ 5 --ssh-key <path_to_ssh_public_key> \ 6 --namespace <hosted_cluster_namespace> \ 7 --control-plane-availability-policy SingleReplica \ --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> 8- 1
- ホステッドクラスターの名前を指定します (例:
example)。 - 2
- プルシークレットへのパスを指定します (例:
/user/name/pullsecret)。 - 3
- Hosted Control Plane namespace を指定します (例:
clusters-example)。oc get agent -n <hosted_control_plane_namespace>コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。 - 4
- ベースドメインを指定します (例:
krnl.es)。 - 5
- etcd ストレージクラス名を指定します (例:
lvm-storageclass)。 - 6
- SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは
~/.ssh/id_rsa.pubです。 - 7
- ホストされたクラスターの namespace を指定します。
- 8
- 使用するサポートされている OpenShift Container Platform のバージョンを指定します (例:
4.14.0-x86_64)。非接続環境を使用している場合は、<ocp_release_image>をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
しばらくしてから、次のコマンドを入力して、Hosted Control Plane の Pod が稼働中であることを確認します。
oc -n <hosted_control_plane_namespace> get pods
以下の出力例を参照してください。
NAME READY STATUS RESTARTS AGE capi-provider-7dcf5fc4c4-nr9sq 1/1 Running 0 4m32s catalog-operator-6cd867cc7-phb2q 2/2 Running 0 2m50s certified-operators-catalog-884c756c4-zdt64 1/1 Running 0 2m51s cluster-api-f75d86f8c-56wfz 1/1 Running 0 4m32s
1.7.6.5.1. コンソールを使用してベアメタル上にホストされたクラスターを作成する
- OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。コンソールを開く手順については、OpenShift Container Platform ドキュメントの Web コンソールへのアクセス を参照してください。
- コンソールヘッダーで、All Clusters が選択されていることを確認します。
- Infrastructure > Clusters をクリックします。
Create cluster > Host inventory > Hosted control plane をクリックします。
Create cluster ページが表示されます。
Create cluster ページでプロンプトに従い、クラスター、ノードプール、ネットワーク、および自動化に関する詳細を入力します。
注: クラスターに関する詳細を入力する際には、次のヒントが役立つ場合があります。
- 事前定義された値を使用してコンソールのフィールドに自動的に値を入力する場合は、ホストインベントリーの認証情報を作成できます。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
- Cluster details ページのプルシークレットは、OpenShift Container Platform リソースへのアクセスに使用する OpenShift Container Platform プルシークレットです。ホストインベントリー認証情報を選択した場合は、プルシークレットが自動的に入力されます。
- Node pools ページでは、namespace にノードプールのホストが含まれます。コンソールを使用してホストインベントリーを作成した場合、コンソールは専用の namespace を作成します。
-
Networking ページで、API サーバー公開ストラテジーを選択します。ホステッドクラスターの API サーバーは、既存のロードバランサーを使用するか、
NodePortタイプのサービスとして公開できます。API サーバーに到達できる宛先を指すapi.<hosted_cluster_name>.<basedomain>設定の DNS エントリーが存在する必要があります。このエントリーとして、管理クラスター内のノードの 1 つを指すレコード、または受信トラフィックを Ingress Pod にリダイレクトするロードバランサーを指すレコードを指定できます。
エントリーを確認し、Create をクリックします。
Hosted cluster ビューが表示されます。
- Hosted cluster ビューでホストされたクラスターのデプロイメントを監視します。ホストされたクラスターに関する情報が表示されない場合は、All Clusters が選択されていることを確認し、クラスター名をクリックします。
- コントロールプレーンコンポーネントの準備が整うまで待ちます。このプロセスには数分かかる場合があります。
- ノードプールのステータスを表示するには、NodePool セクションまでスクロールします。ノードをインストールするプロセスには約 10 分かかります。Nodes をクリックして、ノードがホストされたクラスターに参加したかどうかを確認することもできます。
1.7.6.5.2. ミラーレジストリーを使用してベアメタル上にホストされたクラスターを作成する
ミラーレジストリーを使用して、hcp create cluster コマンドで --image-content-sources フラグを指定して、ベアメタル上にホステッドクラスターを作成できます。以下の手順を実行します。
YAML ファイルを作成して、イメージコンテンツソースポリシー (ICSP) を定義します。以下の例を参照してください。
- mirrors: - brew.registry.redhat.io source: registry.redhat.io - mirrors: - brew.registry.redhat.io source: registry.stage.redhat.io - mirrors: - brew.registry.redhat.io source: registry-proxy.engineering.redhat.com
-
ファイルを
icsp.yamlとして保存します。このファイルにはミラーレジストリーが含まれます。 ミラーレジストリーを使用してホステッドクラスターを作成するには、次のコマンドを実行します。
hcp create cluster agent \ --name=<hosted_cluster_name> \ 1 --pull-secret=<path_to_pull_secret> \ 2 --agent-namespace=<hosted_control_plane_namespace> \ 3 --base-domain=<basedomain> \ 4 --api-server-address=api.<hosted_cluster_name>.<basedomain> \ --image-content-sources icsp.yaml \ 5 --ssh-key <path_to_ssh_key> \ 6 --namespace <hosted_cluster_namespace> \ 7 --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> 8- 1
- ホステッドクラスターの名前を指定します (例:
example)。 - 2
- プルシークレットへのパスを指定します (例:
/user/name/pullsecret)。 - 3
- Hosted Control Plane namespace を指定します (例:
clusters-example)。oc get agent -n <hosted-control-plane-namespace>コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。 - 4
- ベースドメインを指定します (例:
krnl.es)。 - 5
- ICSP およびミラーレジストリーを定義する
icsp.yamlファイルを指定します。 - 6
- SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは
~/.ssh/id_rsa.pubです。 - 7
- ホストされたクラスターの namespace を指定します。
- 8
- 使用するサポートされている OpenShift Container Platform のバージョンを指定します (例:
4.14.0-x86_64)。非接続環境を使用している場合は、<ocp_release_image>をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
1.7.6.5.3. 関連情報
- コンソールでホステッドクラスターを作成するときに再利用できる認証情報を作成するには、オンプレミス環境の認証情報の作成 を参照してください。
- ホステッドクラスターをインポートするには、Hosted Control Plane クラスターの手動インポート を参照してください。
- ホステッドクラスターにアクセスするには、ホステッドクラスターへのアクセス を参照してください。
- OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
1.7.6.6. ホステッドクラスター作成の確認
デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。
次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。
oc extract -n kni21 secret/kni21-admin-kubeconfig --to=- > kubeconfig-kni21 # kubeconfig
kubeconfig を使用して、ホステッドクラスターのクラスター Operator を表示します。以下のコマンドを入力します。
oc get co --kubeconfig=kubeconfig-kni21
以下の出力例を参照してください。
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.10.26 True False False 2m38s csi-snapshot-controller 4.10.26 True False False 4m3s dns 4.10.26 True False False 2m52s image-registry 4.10.26 True False False 2m8s ingress 4.10.26 True False False 22m kube-apiserver 4.10.26 True False False 23m kube-controller-manager 4.10.26 True False False 23m kube-scheduler 4.10.26 True False False 23m kube-storage-version-migrator 4.10.26 True False False 4m52s monitoring 4.10.26 True False False 69s network 4.10.26 True False False 4m3s node-tuning 4.10.26 True False False 2m22s openshift-apiserver 4.10.26 True False False 23m openshift-controller-manager 4.10.26 True False False 23m openshift-samples 4.10.26 True False False 2m15s operator-lifecycle-manager 4.10.26 True False False 22m operator-lifecycle-manager-catalog 4.10.26 True False False 23m operator-lifecycle-manager-packageserver 4.10.26 True False False 23m service-ca 4.10.26 True False False 4m41s storage 4.10.26 True False False 4m43s
次のコマンドを入力して、ホステッドクラスター上で実行中の Pod を表示することもできます。
oc get pods -A --kubeconfig=kubeconfig-kni21
以下の出力例を参照してください。
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system konnectivity-agent-khlqv 0/1 Running 0 3m52s kube-system konnectivity-agent-nrbvw 0/1 Running 0 4m24s kube-system konnectivity-agent-s5p7g 0/1 Running 0 4m14s kube-system kube-apiserver-proxy-asus3-vm1.kni.schmaustech.com 1/1 Running 0 5m56s kube-system kube-apiserver-proxy-asus3-vm2.kni.schmaustech.com 1/1 Running 0 6m37s kube-system kube-apiserver-proxy-asus3-vm3.kni.schmaustech.com 1/1 Running 0 6m17s openshift-cluster-node-tuning-operator cluster-node-tuning-operator-798fcd89dc-9cf2k 1/1 Running 0 20m openshift-cluster-node-tuning-operator tuned-dhw5p 1/1 Running 0 109s openshift-cluster-node-tuning-operator tuned-dlp8f 1/1 Running 0 110s openshift-cluster-node-tuning-operator tuned-l569k 1/1 Running 0 109s openshift-cluster-samples-operator cluster-samples-operator-6b5bcb9dff-kpnbc 2/2 Running 0 20m openshift-cluster-storage-operator cluster-storage-operator-5f784969f5-vwzgz 1/1 Running 1 (113s ago) 20m openshift-cluster-storage-operator csi-snapshot-controller-6b7687b7d9-7nrfw 1/1 Running 0 3m8s openshift-cluster-storage-operator csi-snapshot-controller-6b7687b7d9-csksg 1/1 Running 0 3m9s openshift-cluster-storage-operator csi-snapshot-controller-operator-7f4d9fc5b8-hkvrk 1/1 Running 0 20m openshift-cluster-storage-operator csi-snapshot-webhook-6759b5dc8b-7qltn 1/1 Running 0 3m12s openshift-cluster-storage-operator csi-snapshot-webhook-6759b5dc8b-f8bqk 1/1 Running 0 3m12s openshift-console-operator console-operator-8675b58c4c-flc5p 1/1 Running 1 (96s ago) 20m openshift-console console-5cbf6c7969-6gk6z 1/1 Running 0 119s openshift-console downloads-7bcd756565-6wj5j 1/1 Running 0 4m3s openshift-dns-operator dns-operator-77d755cd8c-xjfbn 2/2 Running 0 21m openshift-dns dns-default-jwjkz 2/2 Running 0 113s openshift-dns dns-default-kfqnh 2/2 Running 0 113s openshift-dns dns-default-xlqsm 2/2 Running 0 113s openshift-dns node-resolver-jzxnd 1/1 Running 0 110s openshift-dns node-resolver-xqdr5 1/1 Running 0 110s openshift-dns node-resolver-zl6h4 1/1 Running 0 110s openshift-image-registry cluster-image-registry-operator-64fcfdbf5-r7d5t 1/1 Running 0 20m openshift-image-registry image-registry-7fdfd99d68-t9pq9 1/1 Running 0 53s openshift-image-registry node-ca-hkfnr 1/1 Running 0 56s openshift-image-registry node-ca-vlsdl 1/1 Running 0 56s openshift-image-registry node-ca-xqnsw 1/1 Running 0 56s openshift-ingress-canary ingress-canary-86z6r 1/1 Running 0 4m13s openshift-ingress-canary ingress-canary-8jhxk 1/1 Running 0 3m52s openshift-ingress-canary ingress-canary-cv45h 1/1 Running 0 4m24s openshift-ingress router-default-6bb8944f66-z2lxr 1/1 Running 0 20m openshift-kube-storage-version-migrator-operator kube-storage-version-migrator-operator-56b57b4844-p9zgp 1/1 Running 1 (2m16s ago) 20m openshift-kube-storage-version-migrator migrator-58bb4d89d5-5sl9w 1/1 Running 0 3m30s openshift-monitoring alertmanager-main-0 6/6 Running 0 100s openshift-monitoring cluster-monitoring-operator-5bc5885cd4-dwbc4 2/2 Running 0 20m openshift-monitoring grafana-78f798868c-wd84p 3/3 Running 0 94s openshift-monitoring kube-state-metrics-58b8f97f6c-6kp4v 3/3 Running 0 104s openshift-monitoring node-exporter-ll7cp 2/2 Running 0 103s openshift-monitoring node-exporter-tgsqg 2/2 Running 0 103s openshift-monitoring node-exporter-z99gr 2/2 Running 0 103s openshift-monitoring openshift-state-metrics-677b9fb74f-qqp6g 3/3 Running 0 104s openshift-monitoring prometheus-adapter-f69fff5f9-7tdn9 0/1 Running 0 17s openshift-monitoring prometheus-k8s-0 6/6 Running 0 93s openshift-monitoring prometheus-operator-6b9d4fd9bd-tqfcx 2/2 Running 0 2m2s openshift-monitoring telemeter-client-74d599658c-wqw5j 3/3 Running 0 101s openshift-monitoring thanos-querier-64c8757854-z4lll 6/6 Running 0 98s openshift-multus multus-additional-cni-plugins-cqst9 1/1 Running 0 6m14s openshift-multus multus-additional-cni-plugins-dbmkj 1/1 Running 0 5m56s openshift-multus multus-additional-cni-plugins-kcwl9 1/1 Running 0 6m14s openshift-multus multus-admission-controller-22cmb 2/2 Running 0 3m52s openshift-multus multus-admission-controller-256tn 2/2 Running 0 4m13s openshift-multus multus-admission-controller-mz9jm 2/2 Running 0 4m24s openshift-multus multus-bxgvr 1/1 Running 0 6m14s openshift-multus multus-dmkdc 1/1 Running 0 6m14s openshift-multus multus-gqw2f 1/1 Running 0 5m56s openshift-multus network-metrics-daemon-6cx4x 2/2 Running 0 5m56s openshift-multus network-metrics-daemon-gz4jp 2/2 Running 0 6m13s openshift-multus network-metrics-daemon-jq9j4 2/2 Running 0 6m13s openshift-network-diagnostics network-check-source-8497dc8f86-cn4nm 1/1 Running 0 5m59s openshift-network-diagnostics network-check-target-d8db9 1/1 Running 0 5m58s openshift-network-diagnostics network-check-target-jdbv8 1/1 Running 0 5m58s openshift-network-diagnostics network-check-target-zzmdv 1/1 Running 0 5m55s openshift-network-operator network-operator-f5b48cd67-x5dcz 1/1 Running 0 21m openshift-sdn sdn-452r2 2/2 Running 0 5m56s openshift-sdn sdn-68g69 2/2 Running 0 6m openshift-sdn sdn-controller-4v5mv 2/2 Running 0 5m56s openshift-sdn sdn-controller-crscc 2/2 Running 0 6m1s openshift-sdn sdn-controller-fxtn9 2/2 Running 0 6m1s openshift-sdn sdn-n5jm5 2/2 Running 0 6m openshift-service-ca-operator service-ca-operator-5bf7f9d958-vnqcg 1/1 Running 1 (2m ago) 20m openshift-service-ca service-ca-6c54d7944b-v5mrw 1/1 Running 0 3m8s
1.7.6.7. ホステッドクラスターの NodePool オブジェクトのスケーリング
NodePool オブジェクトをスケーリングして、ホステッドクラスターにノードを追加します。
NodePoolオブジェクトを 2 つのノードにスケーリングします。oc -n <cluster-namespace> scale nodepool <nodepool-name> --replicas 2
Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で状態を通過します。
-
binding -
discovering -
insufficient -
installing -
installing-in-progress -
added-to-existing-cluster
-
以下のコマンドを入力します。
oc -n <hosted-control-plane-namespace> get agent
以下の出力例を参照してください。
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assign
以下のコマンドを入力します。
oc -n <hosted-control-plane-namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'以下の出力例を参照してください。
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
エージェントが
added-to-existing-cluster状態に達したら、次のコマンドを入力して、OpenShift Container Platform ノードが表示されることを確認します。oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
以下の出力例を参照してください。
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8f
Cluster Operator は、ワークロードをノードに追加することによって調整を開始します。
次のコマンドを入力して、
NodePoolオブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。oc -n <hosted-control-plane-namespace> get machines
以下の出力例を参照してください。
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hypercluster1-c96b6f675-m5vch hypercluster1-b2qhl ocp-worker-1 agent://da503cf1-a347-44f2-875c-4960ddb04091 Running 15m 4.12z hypercluster1-c96b6f675-tl42p hypercluster1-b2qhl ocp-worker-2 agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6 Running 15m 4.12z
clusterversion調整プロセスは最終的に、Ingress および Console クラスター Operator のみが欠落しているポイントに到達します。以下のコマンドを入力します。
oc --kubeconfig <hosted-cluster-name>.kubeconfig get clusterversion,co
以下の出力例を参照してください。
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version False True 40m Unable to apply 4.12z: the cluster operator console has not yet successfully rolled out NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/console 4.12z False False False 11m RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused clusteroperator.config.openshift.io/csi-snapshot-controller 4.12z True False False 10m clusteroperator.config.openshift.io/dns 4.12z True False False 9m16s clusteroperator.config.openshift.io/image-registry 4.12z True False False 9m5s clusteroperator.config.openshift.io/ingress 4.12z True False True 39m The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing) clusteroperator.config.openshift.io/insights 4.12z True False False 11m clusteroperator.config.openshift.io/kube-apiserver 4.12z True False False 40m clusteroperator.config.openshift.io/kube-controller-manager 4.12z True False False 40m clusteroperator.config.openshift.io/kube-scheduler 4.12z True False False 40m clusteroperator.config.openshift.io/kube-storage-version-migrator 4.12z True False False 10m clusteroperator.config.openshift.io/monitoring 4.12z True False False 7m38s clusteroperator.config.openshift.io/network 4.12z True False False 11m clusteroperator.config.openshift.io/openshift-apiserver 4.12z True False False 40m clusteroperator.config.openshift.io/openshift-controller-manager 4.12z True False False 40m clusteroperator.config.openshift.io/openshift-samples 4.12z True False False 8m54s clusteroperator.config.openshift.io/operator-lifecycle-manager 4.12z True False False 40m clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog 4.12z True False False 40m clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver 4.12z True False False 40m clusteroperator.config.openshift.io/service-ca 4.12z True False False 11m clusteroperator.config.openshift.io/storage 4.12z True False False 11m
1.7.6.7.1. ノードプールの追加
名前、レプリカの数、およびエージェントラベルセレクターなどの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。
ノードプールを作成するには、次の情報を入力します。この例では、ノードプールは
"size" : "medium"ラベルの付いたエージェントを使用します。export NODEPOOL_NAME=${CLUSTER_NAME}-extra-cpu export WORKER_COUNT="2" hcp create nodepool agent \ --cluster-name $CLUSTER_NAME \ --name $NODEPOOL_NAME \ --node-count $WORKER_COUNT \ --agentLabelSelector '{"matchLabels": {"size": "medium"}}'clustersnamespace 内のnodepoolリソースをリスト表示して、ノードプールのステータスを確認します。oc get nodepools --namespace clusters
しばらくしてから、次のコマンドを入力してノードプールのステータスを確認できます。
oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
次のコマンドを入力して、ノードプールが予期したステータスになっていることを確認します。
oc get nodepools --namespace clusters
1.7.6.8. ベアメタル上のホステッドクラスターでの Ingress の処理
すべての OpenShift Container Platform クラスターには、外部 DNS レコードが関連付けられていると想定されるデフォルトのアプリケーション Ingress コントローラーがセットアップされています。たとえば、ベースドメイン krnl.es で example という名前の HyperShift クラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es がルーティング可能であると予想することができます。
*.apps のロードバランサーとワイルドカード DNS レコードをセットアップできます。このプロセスでは、MetalLB をデプロイし、Ingress デプロイメントにルーティングする新しいロードバランサーサービスを設定し、ワイルドカード DNS エントリーをロードバランサー IP アドレスに割り当てる必要があります。
LoadBalancer タイプのサービスを作成するときに、MetalLB がサービスの外部 IP アドレスを追加するように、
MetalLBをセットアップします。MetalLB Operator の設定を含む YAML ファイルを作成します。
apiVersion: v1 kind: Namespace metadata: name: metallb labels: openshift.io/cluster-monitoring: "true" annotations: workload.openshift.io/allowed: management --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: metallb-operator-operatorgroup namespace: metallb --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: metallb-operator namespace: metallb spec: channel: "stable" name: metallb-operator source: redhat-operators sourceNamespace: openshift-marketplace-
ファイルを
metallb-operator-config.yamlとして保存します。 - 以下のコマンドを入力して設定を適用します。
oc apply -f metallb-operator-config.yaml
Operator の実行後、MetalLB インスタンスを作成します。
MetalLB インスタンスの設定を含む YAML ファイルを作成します。
apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb
-
ファイルを
metallb-instance-config.yamlとして保存します。 - 次のコマンドを入力して、MetalLB インスタンスを作成します。
oc apply -f metallb-instance-config.yaml
2 つのリソースを作成して MetalLB Operator を設定します。
-
単一の IP アドレスを持つ
IPAddressPoolリソース。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。 IPAddressPoolリソースが BGP プロトコルを通じて提供するロードバランサーの IP アドレスをアドバタイズするためのBGPアドバタイズリソース。重要: 環境のアドレスと一致するように
INGRESS_IP環境変数を変更します。設定を含む YAML ファイルを作成します。
export INGRESS_IP=192.168.122.23 apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: ingress-public-ip namespace: metallb spec: protocol: layer2 autoAssign: false addresses: - ${INGRESS_IP}-${INGRESS_IP} --- apiVersion: metallb.io/v1beta1 kind: BGPAdvertisement metadata: name: ingress-public-ip namespace: metallb spec: ipAddressPools: - ingress-public-ip-
ファイルを
ipaddresspool-bgpadvertisement-config.yamlとして保存します。 - 次のコマンドを入力してリソースを作成します。
oc apply -f ipaddresspool-bgpadvertisement-config.yaml
-
単一の IP アドレスを持つ
以下の手順に従って、MetalLB を介して OpenShift Container Platform ルーターを公開します。
YAML ファイルを作成して、Ingress トラフィックを Ingress デプロイメントにルーティングする LoadBalancer サービスをセットアップします。
kind: Service apiVersion: v1 metadata: annotations: metallb.universe.tf/address-pool: ingress-public-ip name: metallb-ingress namespace: openshift-ingress spec: ports: - name: http protocol: TCP port: 80 targetPort: 80 - name: https protocol: TCP port: 443 targetPort: 443 selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default type: LoadBalancer-
ファイルを
metallb-loadbalancer-service.yamlとして保存します。 次のコマンドを入力して、YAML ファイルから設定を適用します。
oc apply -f metallb-loadbalancer-service.yaml
次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。
curl -kI https://console-openshift-console.apps.example.krnl.es HTTP/1.1 200 OK
clusterversionとclusteroperatorの値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,co以下の出力例を参照してください。
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.12z True False 3m32s Cluster version is 4.12z NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/console 4.12z True False False 3m50s clusteroperator.config.openshift.io/csi-snapshot-controller 4.12z True False False 25m clusteroperator.config.openshift.io/dns 4.12z True False False 23m clusteroperator.config.openshift.io/image-registry 4.12z True False False 23m clusteroperator.config.openshift.io/ingress 4.12z True False False 53m clusteroperator.config.openshift.io/insights 4.12z True False False 25m clusteroperator.config.openshift.io/kube-apiserver 4.12z True False False 54m clusteroperator.config.openshift.io/kube-controller-manager 4.12z True False False 54m clusteroperator.config.openshift.io/kube-scheduler 4.12z True False False 54m clusteroperator.config.openshift.io/kube-storage-version-migrator 4.12z True False False 25m clusteroperator.config.openshift.io/monitoring 4.12z True False False 21m clusteroperator.config.openshift.io/network 4.12z True False False 25m clusteroperator.config.openshift.io/openshift-apiserver 4.12z True False False 54m clusteroperator.config.openshift.io/openshift-controller-manager 4.12z True False False 54m clusteroperator.config.openshift.io/openshift-samples 4.12z True False False 23m clusteroperator.config.openshift.io/operator-lifecycle-manager 4.12z True False False 54m clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog 4.12z True False False 54m clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver 4.12z True False False 54m clusteroperator.config.openshift.io/service-ca 4.12z True False False 25m clusteroperator.config.openshift.io/storage 4.12z True False False 25m
1.7.6.8.1. 関連情報
- MetalLB の詳細は、OpenShift Container Platform ドキュメントの MetalLB および MetalLB Operator について を参照してください。
1.7.6.9. ホステッドクラスターのノード自動スケーリングの有効化
ホステッドクラスターにさらに容量が必要で、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいワーカーノードをインストールできます。
自動スケーリングを有効にするには、次のコマンドを入力します。この場合、ノードの最小数は 2 で、最大数は 5 です。追加できるノードの最大数は、プラットフォームによって制限される場合があります。たとえば、エージェントプラットフォームを使用する場合、ノードの最大数は使用可能なエージェントの数によって制限されます。
oc -n ${CLUSTERS_NAMESPACE} patch nodepool ${HOSTED_CLUSTER_NAME} --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'追加の容量が必要ないまま 10 分が経過すると、ワーカーノードが削除されます。エージェントプラットフォームでは、エージェントは廃止され、再利用できます。
新しいノードを必要とするワークロードを作成します。
次の例に示すように、ワークロード設定を含む YAML ファイルを作成します。
apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: reversewords name: reversewords namespace: default spec: replicas: 40 selector: matchLabels: app: reversewords strategy: {} template: metadata: creationTimestamp: null labels: app: reversewords spec: containers: - image: quay.io/mavazque/reversewords:latest name: reversewords resources: requests: memory: 2Gi status: {}-
ファイルを
workload-config.yamlとして保存します。 - 以下のコマンドを入力して、YAML を適用します。
oc apply -f workload-config.yaml
次のコマンドを入力してノードを確認すると、新しいノードが出力に表示されます。この例では、
ocp-worker-0がクラスターに追加されています。oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes以下の出力例を参照してください。
NAME STATUS ROLES AGE VERSION ocp-worker-0 Ready worker 35s v1.24.0+3882f8f ocp-worker-1 Ready worker 40m v1.24.0+3882f8f ocp-worker-2 Ready worker 41m v1.24.0+3882f8f
ノードを削除するには、次のコマンドを入力してワークロードを削除します。
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig -n default delete deployment reversewords10 分間待機し、次のコマンドを入力してノードが削除されたことを確認します。
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes以下の出力例を参照してください。
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 51m v1.24.0+3882f8f ocp-worker-2 Ready worker 52m v1.24.0+3882f8f
1.7.6.9.1. ホストされたクラスターのノードの自動スケーリングを無効にする
ノードの自動スケーリングを無効にするには、次のコマンドを入力します。
oc -n ${CLUSTERS_NAMESPACE} patch nodepool ${HOSTED_CLUSTER_NAME} --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": $SOME_INT_VALUE_FOR_SCALING_TO}]'
このコマンドは、YAML ファイルから "spec.autoScaling"` を削除し、"spec.replicas" を追加し、"spec.replicas" を指定した値に設定します。
1.7.6.10. ベアメタル上のホステッドクラスターの破棄
コンソールを使用して、ベアメタルホステッドクラスターを破棄できます。ベアメタル上のホステッドクラスターを破壊するには、次の手順を実行します。
- コンソールで、Infrastructure > Clusters に移動します。
- Clusters ページで、破棄するクラスターを選択します。
- Actions メニューで Destroy clusters を選択し、クラスターを削除します。
1.7.6.10.1. コマンドラインを使用したベアメタル上でのホステッドクラスターの破棄
ホステッドクラスターとそのマネージドクラスターリソースを破棄するには、次の手順を実行します。
次のコマンドを実行して、multicluster engine Operator のマネージドクラスターリソースを削除します。
oc delete managedcluster <cluster_name>
cluster_nameはクラスターの名前に置き換えます。次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。
hcp destroy cluster agent --name <cluster_name>
必要に応じて名前を置き換えます。
1.7.7. 64 ビット x86 OpenShift Container Platform クラスターでのホスティングクラスターの設定による、IBM Power コンピュートノードの hosted control plane の作成 (テクノロジープレビュー)
テクノロジープレビュー: IBM Power (ppc64le) コンピュートノード用の 64 ビット x86 ベアメタル上でのホスティングクラスターの設定のサポートには制限があります。
ホスティングクラスターとして機能するようにクラスターを設定することで、Hosted Control Plane をデプロイメントできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。ホスティングクラスターは 管理 クラスターとも呼ばれます。
注:management クラスターは マネージド クラスターではありません。マネージドクラスターは、ハブクラスターが管理するクラスターです。
multicluster engine operator 2.4 は、管理されるハブクラスターであるデフォルトの local-cluster と、ホスティングクラスターとしてのハブクラスターのみをサポートします。
重要:
- エージェントプラットフォームを使用して、Hosted Control Plane をベアメタルでプロビジョニングできます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。中央インフラストラクチャー管理サービスの概要については、ホストインベントリーの作成 を参照してください。
- 各 IBM Power システムホストは、中央インフラストラクチャー管理が提供する Discovery イメージを使用して起動する必要があります。各ホストが起動すると、エージェントプロセスが実行されてホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。
- Agent プラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。
- ノードプールをスケールアップすると、マシンが作成されます。Cluster API プロバイダーは、承認され、検証に合格し、現在使用されておらず、ノードプールの仕様で指定されている要件を満たすエージェントを見つけます。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
- ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。クラスターを再利用する前に、Discovery イメージを使用してクラスターを再起動し、ノード数を更新する必要があります。
1.7.7.1. 前提条件
ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。
- OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.4 以降のマルチクラスターエンジン。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。OpenShift Container Platform OperatorHub から Operator として Red Hat Advanced Cluster Management を使用せずに、マルチクラスターエンジン Operator をインストールすることもできます。
マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。
local-clusterは、マルチクラスターエンジン Operator 2.4 以降で自動的にインポートされます。local-clusterの詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。oc get managedclusters local-cluster
- HyperShift Operator を実行するには、3 つ以上のワーカーノードを含むホスティングクラスターが必要です。
- Central Infrastructure Management サービスが有効である。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
- Hosted Control Plane コマンドラインインターフェイスをインストールする。Hosted Control Plane コマンドラインインターフェイスのインストール を参照してください。
1.7.7.2. IBM Power インフラストラクチャーの要件
エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャーとして次のものが必要です。
- Agents: Agent は Discovery イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングする準備ができているホストを表します。
- DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。
1.7.7.3. IBM Power 設定ドキュメント
前提条件を満たしたら、次のトピックを参照して、ベアメタル上に Hosted Control Plane を設定します。
1.7.7.4. InfraEnv リソースにエージェントを追加する
エージェントを追加するには、ライブ ISO で開始するようにマシンを手動で設定できます。
-
ライブ ISO をダウンロードし、それを使用してホスト (ベアメタルまたは VM) を起動します。ライブ ISO の URL は、
InfraEnvリソースのstatus.isoDownloadURLフィールドにあります。起動時に、ホストは Assisted Service と通信し、InfraEnvリソースと同じ namespace にエージェントとして登録します。 エージェントとそのプロパティーの一部を一覧表示するには、次のコマンドを入力します。
oc -n <hosted-control-plane-namespace> get agents
以下の出力例を参照してください。
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assign
各エージェントが作成された後、オプションでその
install_disk_idとhostnameを仕様に設定し、次のコマンドを入力してエージェントを承認できます。oc -n <hosted-control-plane-namespace> patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type merge oc -n <hosted-control-plane-namespace> patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type mergeエージェントの使用が承認されていることを確認するには、次のコマンドを入力して出力を確認します。
oc -n <hosted-control-plane-namespace> get agents
以下の出力例を参照してください。
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assign
1.7.7.5. IBM Power での Hosted Control Plane の DNS の設定
ホステッドクラスターの API サーバーが公開されます。API サーバーに到達可能な宛先を指す api.<hosted_cluster_name>.<base-domain> エントリーの DNS エントリーが存在する必要があります。
DNS エントリーは、Hosted control plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。
エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。
次の DNS 設定例を参照してください。
$ cat /var/named/<example.krnl.es.zone>
以下の出力例を参照してください。
$ TTL 900
@ IN SOA bastion.example.krnl.es.com. hostmaster.example.krnl.es.com. (
2019062002
1D 1H 1W 3H )
IN NS bastion.example.krnl.es.com.
;
;
api IN A 1xx.2x.2xx.1xx 1
api-int IN A 1xx.2x.2xx.1xx
;
;
*.apps.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN} IN A 1xx.2x.2xx.1xx
;
;EOF- 1
- このレコードは、Hosted Control Plane の受信トラフィックと送信トラフィックを処理する API ロードバランサーの IP アドレスを参照します。
IBM Power の場合、エージェントの IP アドレスに対応する IP アドレスを追加します。
compute-0 IN A 1xx.2x.2xx.1yy compute-1 IN A 1xx.2x.2xx.1yy
1.7.7.6. IBM Power コンピューティングノード用の 64 ビット x86 ベアメタル上への Hosted Control Plane 用の InfraEnv リソース作成
InfraEnv は、ライブ ISO を開始しているホストがエージェントとして参加できる環境です。この場合、エージェントは Hosted Control Plane と同じ namespace に作成されます。
InfraEnv リソースを作成するには、次の手順を実行します。
設定を含む YAML ファイルを作成します。以下の例を参照してください。
apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: ${HOSTED_CLUSTER_NAME} namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE} spec: cpuArchitecture: ppc64le pullSecretRef: name: pull-secret sshAuthorizedKey: ${SSH_PUB_KEY}-
ファイルを
infraenv-config.yamlとして保存します。 次のコマンドを入力して設定を適用します。
oc apply -f infraenv-config.yaml
URL を取得してライブ ISO をダウンロードし、IBM Power マシンがエージェントとして参加できるようにするには、以下のコマンドを入力します。
oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json
1.7.7.7. IBM Power 上のホステッドクラスターの NodePool オブジェクトのスケーリング
NodePool オブジェクトは、ホステッドクラスターの作成時に作成されます。NodePool オブジェクトをスケーリングすることで、Hosted Control Plane にさらに多くのコンピュートノードを追加できます。
次のコマンドを実行して、
NodePoolオブジェクトを 2 つのノードにスケーリングします。oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で移行フェーズを通過します。
-
binding -
discovering -
insufficient -
installing -
installing-in-progress -
added-to-existing-cluster
-
次のコマンドを実行して、スケールされた特定のエージェントのステータスを確認します。
oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'以下の出力を参照してください。
BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
次のコマンドを実行して、移行フェーズを表示します。
oc -n <hosted_control_plane_namespace> get agent
以下の出力を参照してください。
NAME CLUSTER APPROVED ROLE STAGE 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d hosted-forwarder true auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hosted-forwarder true auto-assign
次のコマンドを実行して、ホステッドクラスターにアクセスするための
kubeconfigファイルを生成します。hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
エージェントが
added-to-existing-cluster状態に達したら、次のコマンドを入力して、OpenShift Container Platform ノードが表示されることを確認します。oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
以下の出力を参照してください。
NAME STATUS ROLES AGE VERSION worker-zvm-0.hostedn.example.com Ready worker 5m41s v1.24.0+3882f8f worker-zvm-1.hostedn.example.com Ready worker 6m3s v1.24.0+3882f8f
次のコマンドを入力して、
NodePoolオブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
以下の出力を参照してください。
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hosted-forwarder-79558597ff-5tbqp hosted-forwarder-crqq5 worker-zvm-0.hostedn.example.com agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d Running 41h 4.14.0 hosted-forwarder-79558597ff-lfjfk hosted-forwarder-crqq5 worker-zvm-1.hostedn.example.com agent://5e498cd3-542c-e54f-0c58-ed43e28b568a Running 41h 4.14.0
次のコマンドを実行して、クラスターのバージョンとクラスター Operator のステータスを確認します。
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
以下の出力を参照してください。
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.14.0 True False 40h Cluster version is 4.14.0 NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/console 4.14.0 True False False 40h clusteroperator.config.openshift.io/csi-snapshot-controller 4.14.0 True False False 2d2h clusteroperator.config.openshift.io/dns 4.14.0 True False False 40h clusteroperator.config.openshift.io/image-registry 4.14.0 True False False 40h clusteroperator.config.openshift.io/ingress 4.14.0 True False False 2d2h clusteroperator.config.openshift.io/insights 4.14.0 True False False 40h clusteroperator.config.openshift.io/kube-apiserver 4.14.0 True False False 2d2h clusteroperator.config.openshift.io/kube-controller-manager 4.14.0 True False False 2d2h clusteroperator.config.openshift.io/kube-scheduler 4.14.0 True False False 2d2h clusteroperator.config.openshift.io/kube-storage-version-migrator 4.14.0 True False False 40h clusteroperator.config.openshift.io/monitoring 4.14.0 True False False 40h clusteroperator.config.openshift.io/network 4.14.0 True False False 40h clusteroperator.config.openshift.io/node-tuning 4.14.0 True False False 40h clusteroperator.config.openshift.io/openshift-apiserver 4.14.0 True False False 2d2h clusteroperator.config.openshift.io/openshift-controller-manager 4.14.0 True False False 2d2h clusteroperator.config.openshift.io/openshift-samples 4.14.0 True False False 40h clusteroperator.config.openshift.io/operator-lifecycle-manager 4.14.0 True False False 2d2h clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog 4.14.0 True False False 2d2h clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver 4.14.0 True False False 2d2h clusteroperator.config.openshift.io/service-ca 4.14.0 True False False 40h clusteroperator.config.openshift.io/storage 4.14.0 True False False 2d2h
1.7.8. IBM Z コンピュートノード用の x86 ベアメタル上でのホスティングクラスターの設定 (テクノロジープレビュー)
テクノロジープレビュー: IBM Z (390x) コンピューティングノード用の x86 ベアメタル上でのホスティングクラスターの設定は、サポートが限定されたテクノロジープレビューステータスにあります。
ホスティングクラスターとして機能するようにクラスターを設定することで、Hosted control plane をデプロイメントできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。ホスティングクラスターは 管理 クラスターとも呼ばれます。
注:management クラスターは マネージド クラスターではありません。マネージドクラスターは、ハブクラスターが管理するクラスターです。
hypershift アドオンを使用してマネージドクラスターをホスティングクラスターに変換し、そのクラスターに HyperShift Operator をデプロイできます。その後、ホステッドクラスターの作成を開始できます。
multicluster engine operator 2.4 は、管理されるハブクラスターであるデフォルトの local-cluster と、ホスティングクラスターとしてのハブクラスターのみをサポートします。
重要:
- IBM Z は ISO ブートをサポートしていません。
- エージェントプラットフォームを使用して、Hosted control plane をベアメタルでプロビジョニングできます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。Central Infrastructure Management サービスの概要は、Kube API - Getting Started Guide を参照してください。
- 各 IBM Z システムホストは、Central Infrastructure Management によって提供される PXE イメージを使用して起動する必要があります。各ホストが起動すると、エージェントプロセスが実行されてホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。
- Agent プラットフォームでホステッドクラスターを作成すると、HyperShift Operator は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。
- ノードプールをスケールアップすると、マシンが作成されます。Cluster API プロバイダーは、承認され、検証に合格し、現在使用されておらず、ノードプールの仕様で指定されている要件を満たすエージェントを見つけます。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
- ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。クラスターを再利用する前に、PXE イメージを使用してクラスターを起動し、ノード数を更新する必要があります。
1.7.8.1. 前提条件
- OpenShift Container Platform クラスターに Kubernetes Operator バージョン 2.4 以降のマルチクラスターエンジンをインストールする。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。OpenShift Container Platform OperatorHub から Operator として Red Hat Advanced Cluster Management を使用せずに、マルチクラスターエンジン Operator をインストールすることもできます。
マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。
local-clusterは、マルチクラスターエンジン Operator 2.4 以降で自動的にインポートされます。local-clusterの詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。oc get managedclusters local-cluster
- HyperShift Operator を実行するために 3 つ以上のワーカーノードを含むホスティングクラスターがある。
- Central Infrastructure Management サービスが有効である。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
- Hosted Control Plane コマンドラインインターフェイスをインストールする。Hosted Control Plane コマンドラインインターフェイスのインストール を参照してください。
1.7.8.2. IBM Z インフラストラクチャーの要件
エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャーとして次のものが必要です。
- Agents: Agent は Discovery イメージまたは PXE イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングする準備ができているホストを表します。
- DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。
Hosted Control Plane 機能はデフォルトで有効になっています。機能を無効にした後、手動で有効にする場合、または機能を無効にする必要がある場合は、Hosted Control Plane 機能の有効化または無効化 を参照してください。
1.7.8.3. IBM Z 設定ドキュメント
前提条件を満たしたら、次のトピックを参照して、ベアメタル上に Hosted Control Plane を設定します。
1.7.8.4. IBM Z エージェントを InfraEnv リソースに追加する (テクノロジープレビュー)
IBM Z 環境にエージェントを追加するには、追加の手順が必要です。これについては、このセクションで詳しく説明します。
注: 特に明記されていない限り、これらの手順は、IBM Z および IBM LinuxONE 上の z/VM と RHEL KVM の両方のインストールに適用されます。
1.7.8.4.1. KVM を使用した IBM Z のエージェントの追加
KVM を使用する IBM Z の場合は、次のコマンドを実行して、InfraEnv リソースからダウンロードした PXE イメージを使用して IBM Z 環境を開始します。エージェントが作成されると、ホストは Assisted Service と通信し、管理クラスター上の InfraEnv リソースと同じ namespace に登録します。
virt-install \ --name "<vm_name>" \ --autostart \ --ram=16384 \ --cpu host \ --vcpus=4 \ --location "<path_to_kernel_initrd_image>,kernel=kernel.img,initrd=initrd.img" \ --disk <qcow_image_path> \ --network network:macvtap-net,mac=<mac_address> \ --graphics none \ --noautoconsole \ --wait=-1 \ --extra-args "rd.neednet=1 nameserver=<nameserver> coreos.live.rootfs_url=http://<http_server>/rootfs.img random.trust_cpu=on rd.luks.options=discard ignition.firstboot ignition.platform.id=metal console=tty1 console=ttyS1,115200n8 coreos.inst.persistent-kargs=console=tty1 console=ttyS1,115200n8"
1.7.8.4.2. z/VM を使用した IBM からのエージェントの追加
InfraEnv リソースからダウンロードした PXE イメージを使用して IBM Z 環境を開始するには、以下の手順を実行します。エージェントが作成されると、ホストは Assisted Service と通信し、管理クラスター上の InfraEnv リソースと同じ namespace に登録します。
パラメーターファイルを更新して、
rootfs_url、network_adaptor、およびdisk_typeの値を追加します。以下のパラメーターファイルの例を参照してください。
rd.neednet=1 \ console=ttysclp0 \ coreos.live.rootfs_url=<rootfs_url> \ ip=<IP_guest_vm>::<nameserver>:255.255.255.0::<network_adaptor>:none \ nameserver=<nameserver> \ zfcp.allow_lun_scan=0 \ 1 rd.znet=qeth,<network_adaptor_range>,layer2=1 \ rd.<disk_type>=<storage> random.trust_cpu=on \ 2 rd.luks.options=discard \ ignition.firstboot ignition.platform.id=metal \ console=tty1 console=ttyS1,115200n8 \ coreos.inst.persistent-kargs="console=tty1 console=ttyS1,115200n8
次のコマンドを実行して、
initrd、カーネルイメージ、およびパラメーターファイルをゲスト VM に移動します。vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>
vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename
vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>
ゲスト VM コンソールから次のコマンドを実行します。
cp ipl c
エージェントとそのプロパティーをリスト表示するには、次のコマンドを入力します。
oc -n <hosted_control_plane_namespace> get agents
以下の出力例を参照してください。
NAME CLUSTER APPROVED ROLE STAGE 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a auto-assign
次のコマンドを実行してエージェントを承認します。オプション: 仕様でエージェント ID
<installation_disk_id>と<hostname>を設定できます。oc -n <hosted_control_plane_namespace> patch agent 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-zvm-0.hostedn.example.com"}}' --type merge次のコマンドを実行して、エージェントが承認されていることを確認します。
oc -n <hosted_control_plane_namespace> get agents
以下の出力例を参照してください。
NAME CLUSTER APPROVED ROLE STAGE 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d true auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a true auto-assign
IBM z/VM の場合は、前の手順でパッチを適用したエージェントを編集し、
仕様セクションのinstallerArgs設定を次のように更新します。installerArgs: --append-karg rd.neednet=1 \ --append-karg ip=<IP_guest_vm>::<nameserver>:255.255.255.0:<hostname>:<network_adaptor>:none \ --append-karg nameserver=<nameserver> \ --append-karg rd.znet=qeth,<network_adaptor_range>,layer2=1 \ --append-karg rd.<storage_type>=<storage>
1.7.8.5. IBM Z を使用した Hosted control plane の DNS の設定
ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達可能な宛先を指す api.<hosted_cluster_name>.<base-domain> の DNS エントリーが存在する必要があります。
DNS エントリーは、Hosted control plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。
エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。
次の DNS 設定例を参照してください。
$ cat /var/named/<example.krnl.es.zone>
以下の出力例を参照してください。
$ TTL 900
@ IN SOA bastion.example.krnl.es.com. hostmaster.example.krnl.es.com. (
2019062002
1D 1H 1W 3H )
IN NS bastion.example.krnl.es.com.
;
;
api IN A 1xx.2x.2xx.1xx 1
api-int IN A 1xx.2x.2xx.1xx
;
;
*.apps IN A 1xx.2x.2xx.1xx
;
;EOF- 1
- このレコードは、Hosted Control Plane の受信トラフィックと送信トラフィックを処理する API ロードバランサーの IP アドレスを参照します。
IBM z/VM の場合、エージェントの IP アドレスに対応する IP アドレスを追加します。
compute-0 IN A 1xx.2x.2xx.1yy compute-1 IN A 1xx.2x.2xx.1yy
1.7.8.6. IBM Z コンピューティングノードの x86 ベアメタル上への Hosted Control Plane 用の InfraEnv リソース作成
InfraEnv は、PXE イメージを使用して起動されるホストがエージェントとして参加できる環境です。この場合、エージェントは Hosted Control Plane と同じ namespace に作成されます。
InfraEnv リソースを作成するには、次の手順を参照してください。
設定を含む YAML ファイルを作成します。以下の例を参照してください。
apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: ${HOSTED_CLUSTER_NAME} namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE} spec: cpuArchitecture: s390x pullSecretRef: name: pull-secret sshAuthorizedKey: ${SSH_PUB_KEY}-
ファイルを
infraenv-config.yamlとして保存します。 次のコマンドを入力して設定を適用します。
oc apply -f infraenv-config.yaml
initrd.img、kernel.img、またはrootfs.imgなどの PXE イメージをダウンロードする URL を取得するには、次のコマンドを入力します。このイメージは、IBM Z マシンがエージェントとして参加できるようにします。oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json
1.7.8.7. IBM Z 上のホステッドクラスターの NodePool オブジェクトのスケーリング
NodePool オブジェクトは、ホステッドクラスターの作成時に作成されます。NodePool オブジェクトをスケーリングすることで、Hosted Control Plane にさらに多くのコンピュートノードを追加できます。
次のコマンドを実行して、
NodePoolオブジェクトを 2 つのノードにスケーリングします。oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で移行フェーズを通過します。
-
binding -
discovering -
insufficient -
installing -
installing-in-progress -
added-to-existing-cluster
-
次のコマンドを実行して、スケールされた特定のエージェントのステータスを確認します。
oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'以下の出力を参照してください。
BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
次のコマンドを実行して、移行フェーズを表示します。
oc -n <hosted_control_plane_namespace> get agent
以下の出力を参照してください。
NAME CLUSTER APPROVED ROLE STAGE 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d hosted-forwarder true auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hosted-forwarder true auto-assign
次のコマンドを実行して、ホステッドクラスターにアクセスするための
kubeconfigファイルを生成します。hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
エージェントが
added-to-existing-cluster状態に達したら、次のコマンドを入力して、OpenShift Container Platform ノードが表示されることを確認します。oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
以下の出力を参照してください。
NAME STATUS ROLES AGE VERSION worker-zvm-0.hostedn.example.com Ready worker 5m41s v1.24.0+3882f8f worker-zvm-1.hostedn.example.com Ready worker 6m3s v1.24.0+3882f8f
Cluster Operator は、ワークロードをノードに追加することによって調整を開始します。
次のコマンドを入力して、
NodePoolオブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
以下の出力を参照してください。
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hosted-forwarder-79558597ff-5tbqp hosted-forwarder-crqq5 worker-zvm-0.hostedn.example.com agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d Running 41h 4.14.0 hosted-forwarder-79558597ff-lfjfk hosted-forwarder-crqq5 worker-zvm-1.hostedn.example.com agent://5e498cd3-542c-e54f-0c58-ed43e28b568a Running 41h 4.14.0
次のコマンドを実行して、クラスターのバージョンを確認します。
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
以下の出力を参照してください。
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.14.0-ec.2 True False 40h Cluster version is 4.14.0-ec.2
以下のコマンドを実行して、クラスター Operator のステータスを確認します。
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
以下の出力を参照してください。
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.14.2 True False False 5h34m csi-snapshot-controller 4.14.2 True False False 5h47m dns 4.14.2 True False False 5h35m image-registry 4.14.2 True False False 5h34m ingress 4.14.2 True False False 5h46m insights 4.14.2 True False False 5h35m kube-apiserver 4.14.2 True False False 5h47m kube-controller-manager 4.14.2 True False False 5h47m kube-scheduler 4.14.2 True False False 5h47m kube-storage-version-migrator 4.14.2 True False False 5h35m monitoring 4.14.2 True False False 5h34m network 4.14.2 True False False 5h34m node-tuning 4.14.2 True False False 5h35m openshift-apiserver 4.14.2 True False False 5h47m openshift-controller-manager 4.14.2 True False False 5h47m openshift-samples 4.14.2 True False False 5h34m operator-lifecycle-manager 4.14.2 True False False 5h47m operator-lifecycle-manager-catalog 4.14.2 True False False 5h47m operator-lifecycle-manager-packageserver 4.14.2 True False False 5h47m service-ca 4.14.2 True False False 5h35m storage 4.14.2 True False False 5h47m
1.7.9. OpenShift Virtualization での Hosted control plane クラスターの管理
Hosted Control Plane と Red Hat OpenShift Virtualization を使用すると、KubeVirt 仮想マシンによってホストされるワーカーノードを含む OpenShift Container Platform クラスターを作成できます。OpenShift Virtualization 上の Hosted Control Plane には、次のようないくつかの利点があります。
- Hosted Control Plane とホステッドクラスターを同じ基盤となるベアメタルインフラストラクチャーにまとめることで、リソースの使用率が向上する
- Hosted Control Plane とホステッドクラスターを分離して強力な分離を実現する
- ベアメタルノードのブートストラッププロセスを排除することで、クラスターのプロビジョニング時間を短縮する
- 同じベース OpenShift Container Platform クラスターで多くのリリースを管理する
Hosted Control Plane 機能はデフォルトで有効になっています。
Hosted Control Plane のコマンドラインインターフェイス (hcp) を使用して、OpenShift Container Platform のホストされるクラスターを作成できます。ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、マルチクラスターエンジン Operator へのホストクラスターの自動インポートの無効化 を参照してください。
重要:
- Hosted control plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
- マルチクラスターエンジン Operator が管理できるように、各ホストクラスターには一意の名前が必要です。
- ホステッドクラスターは、マルチクラスターエンジンの operator 管理クラスターの namespace には作成できません。
- Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、OpenShift Container Platform ドキュメントの 推奨される etcd プラクティス および 論理ボリュームマネージャーストレージを使用した永続ストレージ を参照してください。
1.7.9.1. 前提条件
OpenShift Virtualization 上に OpenShift Container Platform クラスターを作成するには、以下の前提条件を満たす必要があります。
-
KUBECONFIG環境変数で指定された OpenShift Container Platform クラスター、バージョン 4.14 以降への管理者アクセスが必要です。 OpenShift Container Platform ホスティングクラスターでは、次の DNS に示すように、ワイルドカード DNS ルートが有効になっている必要があります。
oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'- OpenShift Container Platform ホスティングクラスターには、OpenShift Virtualization バージョン 4.14 以降がインストールされている必要があります。詳細は、Web コンソールを使用した OpenShift Virtualization のインストール を参照してください。
- OpenShift Container Platform ホスティングクラスターは、デフォルトの Pod ネットワーク CNI として OVNKubernetes を使用して設定する必要があります。
OpenShift Container Platform ホスティングクラスターにはデフォルトのストレージクラスが必要です。詳細は、「インストール後のストレージ設定」を参照してください。次の例は、デフォルトのストレージクラスを設定する方法を示しています。
oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'-
quay.io/openshift-release-devリポジトリーの有効なプルシークレットファイルが必要です。詳細は、ユーザーがプロビジョニングしたインフラストラクチャーを使用して x86_64 プラットフォームに OpenShift をインストールする を参照してください。 - Hosted Control Plane コマンドラインインターフェイスをインストールする 必要があります。
- クラスターをプロビジョニングする前に、ロードバランサーを設定する必要があります。詳細は、オプション: MetalLB の設定 を参照してください。
- ネットワークパフォーマンスを最適化するには、KubeVirt 仮想マシンをホストする OpenShift Container Platform クラスターで 9000 以上のネットワーク最大伝送単位 (MTU) を使用します。低い MTU 設定を使用すると、ネットワーク遅延とホストされる Pod のスループットに影響があります。MTU が 9000 以上の場合にのみ、ノードプールでマルチキューを有効にします。
マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。
local-clusterは、マルチクラスターエンジン Operator 2.4 以降で自動的にインポートされます。local-clusterの詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。oc get managedclusters local-cluster
1.7.9.2. ファイアウォールのポートの要件
管理クラスター、コントロールプレーン、ホステッドクラスター間でポートが通信できるように、ファイアウォールとポートの要件を満たしていることを確認します。
kube-apiserverサービスはデフォルトでポート 6443 で実行され、コントロールプレーンコンポーネント間の通信には ingress アクセスが必要です。-
NodePort公開ストラテジーを使用する場合は、kube-apiserverサービスに割り当てられたノードポートが公開されていることを確認してください。 - MetalLB ロードバランシングを使用する場合は、ロードバランサーの IP アドレスに使用される IP 範囲への ingress アクセスを許可します。
-
-
NodePort公開ストラテジーを使用する場合は、ignition-serverおよびOauth-server設定にファイアウォールルールを使用します。 konnectivityエージェントは、ホステッドクラスター上で双方向通信を可能にするリバーストンネルを確立し、ポート 6443 でクラスター API サーバーアドレスへの egress アクセスを必要とします。この egress アクセスを使用すると、エージェントはkube-apiserverサービスにアクセスできます。- クラスター API サーバーのアドレスが内部 IP アドレスの場合は、ワークロードサブネットからポート 6443 の IP アドレスへのアクセスを許可します。
- アドレスが外部 IP アドレスの場合は、ノードからその外部 IP アドレスにポート 6443 で送信できるように許可します。
- デフォルトのポート 6443 を変更する場合は、その変更を反映するようにルールを調整します。
- クラスター内で実行されるワークロードに必要なポートがすべて開いていることを確認してください。
- ファイアウォールルール、セキュリティーグループ、またはその他のアクセス制御を使用して、必要なソースだけにアクセスを制限します。必要な場合を除き、ポートを公開しないでください。
- 実稼働環境の場合は、ロードバランサーを使用して、単一の IP アドレスによるアクセスを簡素化します。
Red Hat OpenShift Virtualization 上の Hosted Control Plane に関する関連資料は、次のドキュメントを参照してください。
- etcd および LVM ストレージの推奨事項の詳細は、推奨される etcd プラクティス および 論理ボリュームマネージャーストレージを使用した永続ストレージ を参照してください。
- 非接続環境で Red Hat OpenShift Virtualization に Hosted Control Plane を設定するには、非接続環境での Hosted Control Plane の設定 を参照してください。
- Hosted Control Plane 機能を無効にするか、すでに無効にしていて手動で有効にする場合は、Hosted Control Plane 機能の有効化または無効化 を参照してください。
- Red Hat Ansible Automation Platform ジョブを実行してホステッドクラスターを管理するには、ホステッドクラスターで実行するための Ansible Automation Platform ジョブの設定 を参照してください。
1.7.9.3. KubeVirt プラットフォームを使用したホステッドクラスターの作成
OpenShift Container Platform 4.14 以降では、KubeVirt を使用してクラスターを作成でき、外部インフラストラクチャーを使用して作成することも可能です。KubeVirt を使用した作成プロセスの詳細は、以下をご覧ください。
1.7.9.3.1. ホストされたクラスターの作成
ホステッドクラスターを作成するには、環境変数と Hosted control plane コマンドラインインターフェイス (
hcp) を使用します。export CLUSTER_NAME=example export PULL_SECRET="$HOME/pull-secret" export MEM="6Gi" export CPU="2" export WORKER_COUNT="2" export ETCD_STORAGE="lvm-storageclass" hcp create cluster kubevirt \ --name $CLUSTER_NAME \ --node-pool-replicas $WORKER_COUNT \ --pull-secret $PULL_SECRET \ --memory $MEM \ --cores $CPU \ --etcd-storage-class=${ETCD_STORAGE}必要に応じて値を置き換えます。
注記:
--release-imageフラグを使用して、特定の OpenShift Container Platform リリースでホステッドクラスターをセットアップできます。--node-pool-replicasフラグに従って、2 つの仮想マシンワーカーレプリカを持つクラスターに対してデフォルトのノードプールが作成されます。しばらくすると、次のコマンドを入力して、ホストされているコントロールプレーン Pod が実行されていることを確認できます。
oc -n clusters-$CLUSTER_NAME get pods
以下の出力例を参照してください。
NAME READY STATUS RESTARTS AGE capi-provider-5cc7b74f47-n5gkr 1/1 Running 0 3m catalog-operator-5f799567b7-fd6jw 2/2 Running 0 69s certified-operators-catalog-784b9899f9-mrp6p 1/1 Running 0 66s cluster-api-6bbc867966-l4dwl 1/1 Running 0 66s . . . redhat-operators-catalog-9d5fd4d44-z8qqk 1/1 Running 0 66s
KubeVirt 仮想マシンによってサポートされるワーカーノードを含むホステッドクラスターは、通常、完全にプロビジョニングされるまでに 10 ~ 15 分かかります。
ホステッドクラスターのステータスを確認するには、次のコマンドを入力して、対応する
HostedClusterリソースを確認します。oc get --namespace clusters hostedclusters
完全にプロビジョニングされた
HostedClusterオブジェクトを示す以下の出力例を参照してください。NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters example 4.14.0 example-admin-kubeconfig Completed True False The hosted control plane is available
- ホステッドクラスターへのアクセス の説明に従って、ホステッドクラスターにアクセスします。
1.7.9.3.2. 外部インフラストラクチャーを使用したホステッドクラスターの作成
デフォルトでは、HyperShift Operator は、ホステッドクラスターのコントロールプレーン Pod と、同じクラスター内の KubeVirt ワーカー VM の両方をホストします。外部インフラストラクチャー機能を使用すると、ワーカーノード VM をコントロールプレーン Pod とは別のクラスターに配置できます。
- 管理クラスター は HyperShift Operator を実行し、ホステッドクラスターのコントロールプレーン Pod をホストする OpenShift Container Platform クラスターです。
- インフラストラクチャークラスター は、ホステッドクラスターの KubeVirt ワーカー VM を実行する OpenShift Container Platform クラスターです。
- デフォルトでは、管理クラスターは VM をホストするインフラストラクチャークラスターとしても機能します。ただし、外部インフラストラクチャーの場合、管理クラスターとインフラストラクチャークラスターは異なります。
1.7.9.3.2.1. 外部インフラストラクチャーの前提条件
- KubeVirt ノードをホストする外部インフラストラクチャークラスター上に namespace が必要です。
-
外部インフラストラクチャークラスター用の
kubeconfigファイルが必要です。
1.7.9.3.2.2. hcp コマンドラインインターフェイスを使用したホステッドクラスターの作成
hcp コマンドラインインターフェイスを使用して、ホステッドクラスターを作成できます。
KubeVirt ワーカー VM をインフラストラクチャークラスターに配置するには、次の例に示すように、
--infra-kubeconfig-fileおよび--infra-namespace引数を使用します。export CLUSTER_NAME=example export PULL_SECRET="$HOME/pull-secret" export MEM="6Gi" export CPU="2" export WORKER_COUNT="2" hcp create cluster kubevirt \ --name $CLUSTER_NAME \ --node-pool-replicas $WORKER_COUNT \ --pull-secret $PULL_SECRET \ --memory $MEM \ --cores $CPU \ --infra-namespace=clusters-example \ --infra-kubeconfig-file=$HOME/external-infra-kubeconfig
このコマンドを入力すると、コントロールプレーン Pod は HyperShift Operator が実行される管理クラスターでホストされ、KubeVirt VM は別のインフラストラクチャークラスターでホストされます。
- ホステッドクラスターへのアクセス の説明に従って、ホステッドクラスターにアクセスします。
1.7.9.4. デフォルトの Ingress と DNS の動作
すべての OpenShift Container Platform クラスターにはデフォルトのアプリケーション Ingress コントローラーが含まれており、これにはワイルドカード DNS レコードが関連付けられている必要があります。デフォルトでは、HyperShift KubeVirt プロバイダーを使用して作成されたホステッドクラスターは、自動的に KubeVirt 仮想マシンが実行される OpenShift Container Platform クラスターのサブドメインになります。
たとえば、OpenShift Container Platform クラスターには次のデフォルトの Ingress DNS エントリーがある可能性があります。
*.apps.mgmt-cluster.example.com
その結果、guest という名前が付けられ、その基礎となる OpenShift Container Platform クラスター上で実行される KubeVirt ホステッドクラスターには、次のデフォルト Ingress が設定されます。
*.apps.guest.apps.mgmt-cluster.example.com
デフォルトの Ingress DNS が適切に機能するには、KubeVirt 仮想マシンをホストするクラスターでワイルドカード DNS ルートを許可する必要があります。この動作は、以下のコマンドを入力して設定できます。
oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'注: デフォルトのホステッドクラスター Ingress を使用する場合は、接続はポート 443 経由の HTTPS トラフィックに制限されます。ポート 80 経由のプレーン HTTP トラフィックは拒否されます。この制限は、デフォルトの Ingress の動作にのみ適用されます。
1.7.9.4.1. Ingress と DNS の動作のカスタマイズ
デフォルトの Ingress および DNS 動作を使用しない場合は、作成時に一意のベースドメインを使用して KubeVirt ホステッドクラスターを設定できます。このオプションでは、作成時に手動の設定手順が必要であり、クラスターの作成、ロードバランサーの作成、およびワイルドカード DNS 設定の 3 つの主要な手順が含まれます。
1.7.9.4.1.1. 基本ドメインを指定するホステッドクラスターのデプロイ
基本ドメインを指定するホステッドクラスターを作成するには、次のコマンドを入力します。
export CLUSTER_NAME=example 1 export PULL_SECRET="$HOME/pull-secret" export MEM="6Gi" export CPU="2" export WORKER_COUNT="2" export BASE_DOMAIN=hypershift.lab 2 hcp create cluster kubevirt \ --name $CLUSTER_NAME \ --node-pool-replicas $WORKER_COUNT \ --pull-secret $PULL_SECRET \ --memory $MEM \ --cores $CPU \ --base-domain $BASE_DOMAIN
その結果、クラスター名とベースドメイン、またはこの例に示すように
.apps.example.hypershift.labに対して設定された Ingress ワイルドカードを持つホステッドクラスターが作成されます。ホステッドクラスターはデプロイメントを完了せず、Partialステータスのままです。基本ドメインを設定したため、必要な DNS レコードとロードバランサーが適切に配置されていることを確認する必要があります。以下のコマンドを入力します。
oc get --namespace clusters hostedclusters
以下の出力例を参照してください。
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example example-admin-kubeconfig Partial True False The hosted control plane is available
次のコマンドを入力してクラスターにアクセスします。
hcp create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig
oc --kubeconfig $CLUSTER_NAME-kubeconfig get co
以下の出力例を参照してください。
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.14.0 False False False 30m RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host . . . ingress 4.14.0 True False True 28m The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
次の手順では、出力内のエラーを修正します。
注記: クラスターがベアメタル上にある場合、ロードバランサーサービスをセットアップできるように MetalLB が必要になる場合があります。詳細は、オプション: MetalLB の設定 を参照してください。
1.7.9.4.1.2. ロードバランサーのセットアップ
KubeVirt VM にルーティングするロードバランサーをセットアップし、ワイルドカード DNS エントリーをロードバランサーの IP アドレスに割り当てます。Ingress トラフィックを KubeVirt VM にルーティングするロードバランサーサービスを作成する必要があります。ホステッドクラスター Ingress を公開する NodePort サービスがすでに存在するため、ノードポートをエクスポートし、それらのポートを対象とするロードバランサーサービスを作成できます。
次のコマンドを入力して、ノードポートをエクスポートします。
export HTTP_NODEPORT=$(oc --kubeconfig $CLUSTER_NAME-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}') export HTTPS_NODEPORT=$(oc --kubeconfig $CLUSTER_NAME-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')次のコマンドを入力して、ロードバランサーサービスを作成します。
oc apply -f - apiVersion: v1 kind: Service metadata: labels: app: $CLUSTER_NAME name: $CLUSTER_NAME-apps namespace: clusters-$CLUSTER_NAME spec: ports: - name: https-443 port: 443 protocol: TCP targetPort: ${HTTPS_NODEPORT} - name: http-80 port: 80 protocol: TCP targetPort: ${HTTP_NODEPORT} selector: kubevirt.io: virt-launcher type: LoadBalancer
1.7.9.4.1.3. ワイルドカード DNS の設定
ロードバランサーサービスの外部 IP を参照するワイルドカード DNS レコードまたは CNAME を設定します。
次のコマンドを入力して、外部 IP をエクスポートします。
export EXTERNAL_IP=$(oc -n clusters-$CLUSTER_NAME get service $CLUSTER_NAME-apps -o jsonpath='{.status.loadBalancer.ingress[0].ip}')$EXTERNAL_IPパスに格納されている IP を参照するワイルドカード DNS エントリーを設定します。次の DNS エントリーの例を表示します。*.apps.<hosted-cluster-name\>.<base-domain\>.
DNS エントリーは、クラスターの内部と外部にルーティングできる必要があります。外部 IP 値が
192.168.20.30であるクラスターのステップ 1 の入力例を使用すると、DNS 解決は次の例のようになります。dig +short test.apps.example.hypershift.lab 192.168.20.30
次のコマンドを入力して、ホステッドクラスターのステータスを確認し、
PartialからCompletedに移行したことを確認します。oc get --namespace clusters hostedclusters
以下の出力例を参照してください。
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example 4.14.0 example-admin-kubeconfig Completed True False The hosted control plane is available
1.7.9.4.1.4. 関連情報
1.7.9.5. オプション: MetalLB の設定
MetalLB などのロードバランサーを使用する必要があります。次の例は、MetalLB をインストールした後に設定する手順を示しています。MetalLB のインストールの詳細は、OpenShift Container Platform ドキュメントの MetalLB Operator のインストール を参照してください。
MetalLBリソースインスタンスを作成します。oc create -f - apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system
ノードネットワーク内で使用可能な IP アドレスの範囲を使用してアドレスプールを作成します。次の IP アドレス範囲を、ネットワーク内で使用可能な IP アドレスの未使用のプールに置き換えます。以下のコマンドを入力します。
oc create -f - apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: metallb namespace: metallb-system spec: addresses: - 192.168.216.32-192.168.216.122
L2 プロトコルを使用してアドレスプールをアドバタイズします。以下のコマンドを入力します。
oc create -f - apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: l2advertisement namespace: metallb-system spec: ipAddressPools: - metallb
1.7.9.5.1. 関連情報
- MetalLB の詳細は、MetalLB Operator のインストール を参照してください。
1.7.9.6. ノードプールのスケーリング
oc scaleコマンドを使用して、ノードプールを手動でスケーリングできます。NODEPOOL_NAME=${CLUSTER_NAME}-work NODEPOOL_REPLICAS=5 oc scale nodepool/$NODEPOOL_NAME --namespace clusters --replicas=$NODEPOOL_REPLICASしばらくしてから、次のコマンドを入力して、ノードプールのステータスを確認します。
oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
以下の出力例を参照してください。
NAME STATUS ROLES AGE VERSION example-9jvnf Ready worker 97s v1.27.4+18eadca example-n6prw Ready worker 116m v1.27.4+18eadca example-nc6g4 Ready worker 117m v1.27.4+18eadca example-thp29 Ready worker 4m17s v1.27.4+18eadca example-twxns Ready worker 88s v1.27.4+18eadca
1.7.9.6.1. ノードプールの追加
名前、レプリカの数、およびメモリーや CPU 要件などの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。
ノードプールを作成するには、次の情報を入力します。この例では、ノードプールには VM に割り当てられたより多くの CPU があります。
export NODEPOOL_NAME=${CLUSTER_NAME}-extra-cpu export WORKER_COUNT="2" export MEM="6Gi" export CPU="4" export DISK="16" hcp create nodepool kubevirt \ --cluster-name $CLUSTER_NAME \ --name $NODEPOOL_NAME \ --node-count $WORKER_COUNT \ --memory $MEM \ --cores $CPU --root-volume-size $DISKclustersnamespace 内のノードプールリソースをリストして、nodepoolプールのステータスを確認します。oc get nodepools --namespace clusters
以下の出力例を参照してください。
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE example example 5 5 False False 4.14.0 example-extra-cpu example 2 False False True True Minimum availability requires 2 replicas, current 0 available
しばらくしてから、次のコマンドを入力してノードプールのステータスを確認できます。
oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
以下の出力例を参照してください。
NAME STATUS ROLES AGE VERSION example-9jvnf Ready worker 97s v1.27.4+18eadca example-n6prw Ready worker 116m v1.27.4+18eadca example-nc6g4 Ready worker 117m v1.27.4+18eadca example-thp29 Ready worker 4m17s v1.27.4+18eadca example-twxns Ready worker 88s v1.27.4+18eadca example-extra-cpu-zh9l5 Ready worker 2m6s v1.27.4+18eadca example-extra-cpu-zr8mj Ready worker 102s v1.27.4+18eadca
次のコマンドを入力して、ノードプールが予期したステータスになっていることを確認します。
oc get nodepools --namespace clusters
以下の出力例を参照してください。
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE example example 5 5 False False 4.14.0 example-extra-cpu example 2 2 False False 4.14.0 Delete a HostedCluster
1.7.9.6.1.1. 関連情報
- OpenShift Virtualization での Hosted Control Plane クラスターの管理
- このトピックの最初の ノードプールのスケーリング に戻ります。
1.7.9.7. OpenShift Virtualization でのホステッドクラスターの作成の検証
ホステッドクラスターが正常に作成されたことを確認するには、次の手順を完了します。
次のコマンドを入力して、
HostedClusterリソースがcompleted状態に移行したことを確認します。oc get --namespace clusters hostedclusters ${CLUSTER_NAME}以下の出力例を参照してください。
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters example 4.12.2 example-admin-kubeconfig Completed True False The hosted control plane is available
次のコマンドを入力して、ホステッドクラスター内のすべてのクラスターオペレーターがオンラインであることを確認します。
hcp create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig
oc get co --kubeconfig=$CLUSTER_NAME-kubeconfig
以下の出力例を参照してください。
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.12.2 True False False 2m38s csi-snapshot-controller 4.12.2 True False False 4m3s dns 4.12.2 True False False 2m52s image-registry 4.12.2 True False False 2m8s ingress 4.12.2 True False False 22m kube-apiserver 4.12.2 True False False 23m kube-controller-manager 4.12.2 True False False 23m kube-scheduler 4.12.2 True False False 23m kube-storage-version-migrator 4.12.2 True False False 4m52s monitoring 4.12.2 True False False 69s network 4.12.2 True False False 4m3s node-tuning 4.12.2 True False False 2m22s openshift-apiserver 4.12.2 True False False 23m openshift-controller-manager 4.12.2 True False False 23m openshift-samples 4.12.2 True False False 2m15s operator-lifecycle-manager 4.12.2 True False False 22m operator-lifecycle-manager-catalog 4.12.2 True False False 23m operator-lifecycle-manager-packageserver 4.12.2 True False False 23m service-ca 4.12.2 True False False 4m41s storage 4.12.2 True False False 4m43s
1.7.9.8. OpenShift Virtualization での Hosted Control Plane のストレージの設定
高度な設定が提供されていない場合、デフォルトのストレージクラスが KubeVirt 仮想マシン (VM) イメージ、KubeVirt CSI マッピング、および etcd ボリュームに使用されます。
1.7.9.8.1. KubeVirt CSI ストレージクラスのマッピング
KubeVirt CSI では、ReadWriteMany アクセスモードを持つインフラストラクチャーストレージクラスをホステッドクラスターに公開することができます。インフラストラクチャークラスターストレージクラスからホステッドクラスターストレージクラスへのこのマッピングは、クラスターの作成時に hcp コマンドラインインターフェイスと --infra-storage-class-mapping 引数を使用して設定できます。
インフラストラクチャーストレージクラスをホステッドストレージクラスにマップするには、次の例を参照してください。この例では、infra-sc1 および infra-sc2 という 2 つのインフラストラクチャーストレージクラスを guest-sc1 および guest-sc2 というホステッドストレージクラスにマップする方法を示します。--infra-storage-class-mapping 引数は、create コマンド内で複数回使用できます。
export CLUSTER_NAME=example export PULL_SECRET="$HOME/pull-secret" export MEM="6Gi" export CPU="2" export WORKER_COUNT="2" hcp create cluster kubevirt \ --name $CLUSTER_NAME \ --node-pool-replicas $WORKER_COUNT \ --pull-secret $PULL_SECRET \ --memory $MEM \ --cores $CPU \ --infra-storage-class-mapping=infra-sc1/guest-sc1 \ --infra-storage-class-mapping=infra-sc2/guest-sc2
ホステッドクラスターを作成すると、guest-sc1 および guest-sc2 ストレージクラスがホステッドクラスター内で表示されます。これらのストレージクラスのいずれかを使用するホステッドクラスター内に PVC を作成すると、KubeVirt CSI はクラスターの作成時に設定したインフラストラクチャーストレージクラスマッピングを使用してそのボリュームをプロビジョニングします。
注記: KubeVirt CSI は、ReadWriteMany (RWX) アクセスが可能なインフラストラクチャーストレージクラスのマッピングのみをサポートします。
1.7.9.8.2. KubeVirt VM ルートボリュームの設定
クラスターの作成時に、hcp コマンドラインインターフェイスと --root-volume-storage-class 引数を使用して、KubeVirt VM ルートボリュームのホストに使用されるストレージクラスを設定できます。--root-volume-size 引数を使用して、ボリュームのサイズを設定できます。
KubeVirt VM のカスタムストレージクラスとボリュームサイズを設定するには、次の例を参照してください。この例では、結果は、ocs-storagecluster-ceph-rdb ストレージクラスによってホストされる 64Gi PVC 上でホストされる VM を含むホステッドクラスターになります。
export CLUSTER_NAME=example export PULL_SECRET="$HOME/pull-secret" export MEM="6Gi" export CPU="2" export WORKER_COUNT="2" hcp create cluster kubevirt \ --name $CLUSTER_NAME \ --node-pool-replicas $WORKER_COUNT \ --pull-secret $PULL_SECRET \ --memory $MEM \ --cores $CPU \ --root-volume-storage-class ocs-storagecluster-ceph-rbd \ --root-volume-size 64
1.7.9.8.3. KubeVirt VM イメージキャッシュの有効化
KubeVirt イメージキャッシュは、クラスターの起動時間とストレージ使用率の両方を最適化するために使用できる高度な機能です。この機能には、スマートクローン作成と ReadWriteMany アクセスモードが可能なストレージクラスの使用が必要です。スマートクローン作成の詳細は、smart-cloning を使用したデータボリュームのクローン作成 を参照してください。
イメージのキャッシュは次のように機能します。
- VM イメージは、ホステッドクラスターに関連付けられた PVC にインポートされます。
- その PVC の一意のクローンは、クラスターにワーカーノードとして追加されるすべての KubeVirt VM に対して作成されます。
イメージキャッシュを使用すると、イメージのインポートが 1 つだけ必要になるため、VM の起動時間が短縮されます。ストレージクラスがコピーオンライトクローン作成をサポートしている場合、クラスター全体のストレージ使用量をさらに削減できます。
イメージキャッシュを有効にするには、次の例に示すように、クラスターの作成中に hcp コマンドラインインターフェイスと --root-volume-cache-strategy=PVC 引数を使用します。
export CLUSTER_NAME=example export PULL_SECRET="$HOME/pull-secret" export MEM="6Gi" export CPU="2" export WORKER_COUNT="2" hcp create cluster kubevirt \ --name $CLUSTER_NAME \ --node-pool-replicas $WORKER_COUNT \ --pull-secret $PULL_SECRET \ --memory $MEM \ --cores $CPU \ --root-volume-cache-strategy=PVC
1.7.9.8.4. etcd ストレージの設定
クラスターの作成時に、hcp コマンドラインインターフェイスと --etcd-storage-class 引数を使用して、etcd データのホストに使用されるストレージクラスを設定できます。--etcd-storage-class 引数を指定しない場合は、デフォルトのストレージクラスが使用されます。
etcd のストレージクラスを設定するには、次の例を参照してください。
export CLUSTER_NAME=example
export PULL_SECRET="$HOME/pull-secret"
export MEM="6Gi"
export CPU="2"
export WORKER_COUNT="2"
export ETCD_STORAGE="lvm-storageclass"
hcp create cluster kubevirt \
--name $CLUSTER_NAME \
--node-pool-replicas $WORKER_COUNT \
--pull-secret $PULL_SECRET \
--memory $MEM \
--cores $CPU \
--etcd-storage-class=${ETCD_STORAGE}1.7.9.8.4.1. 関連情報
1.7.9.9. OpenShift Virtualization 上のホステッドクラスターの破棄
ホステッドクラスターとそのマネージドクラスターリソースを破棄するには、次の手順を実行します。
次のコマンドを実行して、multicluster engine Operator のマネージドクラスターリソースを削除します。
oc delete managedcluster <cluster_name>
cluster_nameはクラスターの名前に置き換えます。次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。
hcp destroy cluster kubevirt --name $CLUSTER_NAME
必要に応じて名前を置き換えます。
1.7.10. 非接続環境での Hosted Control Plane の設定
Hosted Control Plane のコンテキストでは、非接続環境は、インターネットに接続されておらず、Hosted Control Plane をベースとして使用する OpenShift Container Platform デプロイメントです。
テクノロジープレビュー: IPv4 または IPv6 ネットワークを使用して、ベアメタルプラットフォーム上の非接続環境に Hosted Control Plane をデプロイメントできます。さらに、非接続環境の Hosted Control Plane は、テクノロジープレビュー機能としてデュアルスタックネットワークで使用できます。Red Hat OpenShift Virtualization プラットフォームを使用する場合は、オフライン環境の Hosted Control Plane がテクノロジープレビュー機能として利用できます。
1.7.10.1. 非接続環境のアーキテクチャー
Hosted Control Plane をベアメタルでプロビジョニングする場合はエージェントプラットフォームを使用できます。エージェントプラットフォームと multicluster engine Operator は連携して、オフラインのデプロイメントを可能にします。エージェントプラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。central infrastructure management の概要は、central infrastructure management の有効化 を参照してください。
以下の図は、非接続環境のアーキテクチャーの例を示しています。
- TLS サポートを備えたレジストリー証明書のデプロイメント、Web サーバー、DNS などのインフラストラクチャーサービスを設定して、非接続デプロイメントが確実に機能するようにします。
openshift-confignamespace に config map を作成します。この例では、config map の名前はregistry-configになります。config map の内容はレジストリー CA 証明書です。config map の data フィールドには、次のキーと値が含まれている必要があります。-
キー:
<registry_dns_domain_name>..<port>(例:registry.hypershiftdomain.lab..5000:)ポートを指定するときは、レジストリー DNS ドメイン名の後に..を配置するようにしてください。 - 値: 証明書の内容
config map の作成に関する詳細は、IPv4 ネットワークの TLS 証明書の設定 を参照してください。
-
キー:
-
images.config.openshift.ioカスタムリソース (CR) に、name: registry-configという値を持つadditionalTrustedCAフィールドを追加します。 multicluster-enginenamespace に config map を作成します。次のサンプル設定を参照してください。apiVersion: v1 kind: ConfigMap metadata: name: custom-registries namespace: multicluster-engine labels: app: assisted-service data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- ... ... ... -----END CERTIFICATE----- registries.conf: | unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] [[registry]] prefix = "" location = "registry.redhat.io/openshift4" mirror-by-digest-only = true [[registry.mirror]] location = "registry.ocp-edge-cluster-0.qe.lab.redhat.com:5000/openshift4" [[registry]] prefix = "" location = "registry.redhat.io/rhacm2" mirror-by-digest-only = true ... ...-
マルチクラスターエンジン Operator namespace では、
multiclusterengineCR を作成します。これにより、Agent アドオンとhypershift-addonアドオンの両方が有効になります。切断されたデプロイメントでの動作を変更するには、マルチクラスターエンジン Operator namespace に config map が含まれている必要があります。namespace には、multicluster-engine、assisted-service、およびhypershift-addon-managerPod も含まれます。 ホステッドクラスターのデプロイに必要なオブジェクトを作成します。これには次のコンポーネントが含まれます。
- シークレット: シークレットには、プルシークレット、SSH キー、etcd 暗号化キーが含まれます。
- config map: config map には、プライベートレジストリーの CA 証明書が含まれています。
-
HostedCluster:HostedClusterリソースは、ホストされたクラスターの設定を定義します。 -
NodePool:NodePoolリソースは、データプレーンに使用するマシンを参照するノードプールを識別します。
-
ホステッドクラスターオブジェクトを作成した後、HyperShift Operator は、コントロールプレーン Pod に対応するために
HostedControlPlanenamespace を確立します。この namespace は、エージェント、ベアメタルホスト (BMH)、InfraEnvリソースなどのコンポーネントもホストします。その後、InfraEnvリソースを作成し、ISO の作成後に、ベースボード管理コントローラー (BMC) 認証情報を含む BMH とそのシークレットを作成します。 -
openshift-machine-apinamespace の Metal3 Operator は、新しい BMH を検査します。次に、Metal3 Operator は、Multi-Cluster Engine Operator の namespace のAgentServiceConfigCR を通じて指定された設定済みのLiveISOおよびRootFSの値を使用して、BMC に接続して BMC を起動しようとします。 -
ホストされたクラスターオブジェクトを作成すると、HyperShift Operator は
HostedControlPlanenamespace にコントロールプレーン Pod を作成します。HostedControlPlanenamespace は、Agent、ベアメタルホスト、InfraEnvリソースなどのコンポーネントもホストします。 -
InfraEnvリソースを作成します。ISO イメージを生成した後、ベースボード管理コントローラー (BMC) の認証情報を含むベアメタルホストとそのシークレットを作成します。openshift-machine-apinamespace の Metal3 Operator は、新しいベアメタルホストを検査します。 -
マルチクラスターエンジン Operator namespace の
AgentServiceConfigCR を介してLiveISOおよびRootFS値を指定し、Metal3 Operator で BMC に接続し、起動します。 -
HostedClusterリソースのワーカーノードが準備状態になると、Agent コンテナーが自動的に起動します。 -
NodePoolリソースを、HostedClusterリソースのワーカーノードの数に合わせてスケーリングします。 - デプロイメントプロセスが完了するまで数分待機します。
1.7.10.2. 前提条件
オフライン環境で Hosted Control Plane を設定するには、次の前提条件を満たす必要があります。
- CPU: 提供される CPU の数によって、同時に実行できるホストクラスターの数が決まります。通常、3 つのノードの場合、各ノードに 16 個の CPU を使用します。最小限の開発では、3 つのノードの場合、各ノードに 12 個の CPU を使用できます。
- メモリー: RAM の量は、ホストできるホストクラスターの数に影響します。各ノードに 48 GB の RAM を使用します。最小限の開発であれば、18 GB の RAM で十分です。
ストレージ: マルチクラスターエンジン Operator には SSD ストレージを使用します。
- 管理クラスター: 250 GB。
- レジストリー: 必要なレジストリーストレージは、ホストされるリリース、Operator、およびイメージの数によって異なります。500 GB が必要になる場合があります。ホストされたクラスターをホストするディスクとは別にすることを推奨します。
- Web サーバー: 必要な Web サーバーストレージは、ホストされる ISO とイメージの数によって異なります。500 GB 必要になる場合があります。
実稼働環境: 実稼働環境の場合、管理クラスター、レジストリー、および Web サーバーを異なるディスク上に分離します。本番環境では次の設定例を参照してください。
- レジストリー: 2 TB
- 管理クラスター: 500 GB
- Web サーバー:2TB
1.7.10.3. OpenShift Container Platform リリースイメージダイジェストの抽出
タグ付けされたイメージを使用して、OpenShift Container Platform リリースイメージダイジェストを抽出できます。以下の手順を実行します。
次のコマンドを実行して、イメージダイジェストを取得します。
oc adm release info <tagged_openshift_release_image> | grep "Pull From"
<tagged_openshift_release_image>を、サポートされている OpenShift Container Platform バージョンのタグ付きイメージに置き換えます (例:quay.io/openshift-release-dev/ocp-release:4.14.0-x8_64)。以下の出力例を参照してください。
Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfe
イメージタグとダイジェストの詳細は、OpenShift Container Platform ドキュメントの イメージストリームでのイメージの参照 を参照してください。
1.7.10.3.1. 関連情報
1.7.10.4. オフライン環境でのユーザーワークロードの監視
hypershift-addon マネージドクラスターアドオンは、HyperShift Operator の --enable-uwm-telemetry-remote-write オプションを有効にします。このオプションを有効にすると、ユーザーワークロードの監視が有効になり、コントロールプレーンから Telemetry メトリックをリモートで書き込むことができるようになります。
インターネットに接続されていない OpenShift Container Platform クラスターにマルチクラスターエンジン Operator をインストールした場合、次のコマンドを入力して HyperShift Operator のユーザーワークロードモニタリング機能を実行しようとすると、この機能はエラーで失敗します。
oc get events -n hypershift
エラーの例を以下に示します。
LAST SEEN TYPE REASON OBJECT MESSAGE 4m46s Warning ReconcileError deployment/operator Failed to ensure UWM telemetry remote write: cannot get telemeter client secret: Secret "telemeter-client" not found
このエラーを回避するには、local-cluster namespace に config map を作成して、ユーザーワークロード監視オプションを無効にする必要があります。アドオンを有効にする前または後に config map を作成できます。アドオンエージェントは、HyperShift Operator を再設定します。
次の config map を作成します。
kind: ConfigMap apiVersion: v1 metadata: name: hypershift-operator-install-flags namespace: local-cluster data: installFlagsToAdd: "" installFlagsToRemove: "--enable-uwm-telemetry-remote-write"
1.7.10.4.1. Hosted control plane 機能のステータス確認
マルチクラスターエンジン Operator 2.4 以降では、Hosted control plane 機能はデフォルトで有効になっています。
この機能が無効になっており、有効にする場合は、次のコマンドを入力します。
multiclusterengineは、マルチクラスターエンジン Operator インスタンスの名前に置き換えます。oc patch mce <multiclusterengine> --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'この機能を有効にすると、
hypershift-addonマネージドクラスターアドオンがlocal-clusterマネージドクラスターにインストールされ、アドオンエージェントはマルチクラスターエンジン Operator ハブクラスターに HyperShift Operator をインストールします。次のコマンドを入力して、
hypershift-addonマネージドクラスターアドオンがインストールされていることを確認します。oc get managedclusteraddons -n local-cluster hypershift-addon
結果の出力を確認します。
NAME AVAILABLE DEGRADED PROGRESSING hypershift-addon True False
このプロセス時のタイムアウトを回避するには、以下のコマンドを入力します。
oc wait --for=condition=Degraded=True managedclusteraddons/hypershift-addon -n local-cluster --timeout=5m
oc wait --for=condition=Available=True managedclusteraddons/hypershift-addon -n local-cluster --timeout=5m
プロセスが完了すると、
hypershift-addonマネージドクラスターアドオンと HyperShift Operator がインストールされ、local-clusterマネージドクラスターがホステッドクラスターをホストおよび管理できるようになります。
1.7.10.4.2. インフラストラクチャーノード上で実行する hypershift-addon マネージドクラスターアドオンの設定
デフォルトでは、hypershift-addon マネージドクラスターアドオンに対してノード配置設定は指定されていません。インフラストラクチャーノード上でアドオンを実行することを検討してください。そうすることで、サブスクリプション数に対する請求コストの発生や、個別のメンテナンスおよび管理タスクの発生を防ぐことができます。
- ハブクラスターにログインします。
次のコマンドを入力して、
hypershift-addon-deploy-configアドオンデプロイメント設定仕様を開いて編集します。oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine
以下の例のように、
nodePlacementフィールドを仕様に追加します。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: AddOnDeploymentConfig metadata: name: hypershift-addon-deploy-config namespace: multicluster-engine spec: nodePlacement: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: NoSchedule key: node-role.kubernetes.io/infra operator: Exists-
変更を保存します。
hypershift-addonマネージドクラスターアドオンは、新規および既存のマネージドクラスターのインフラストラクチャーノードにデプロイされます。
1.7.10.5. IPv4 ネットワーク上での Hosted Control Plane の設定
IPv4 は、Hosted Control Plane を非接続環境にデプロイメントするための最も単純なネットワーク設定の 1 つです。IPv4 範囲では、IPv6 またはデュアルスタック設定よりも必要な外部コンポーネントが少なくなります。
IPv4 ネットワーク上で Hosted Control Plane を設定するプロセスには、次の手順が含まれます。これについては、以下のセクションで詳しく説明します。
- IPv4 ネットワーク用のハイパーバイザーを設定する
- IPv4 ネットワークの DNS を設定する
- IPv4 ネットワーク用のレジストリーをデプロイする
- IPv4 ネットワークの管理クラスターを設定する
- IPv4 ネットワーク用の Web サーバーを設定する
- IPv4 ネットワークのイメージミラーリングを設定する
- IPv4 ネットワーク用のマルチクラスターエンジン Operator をデプロイする
- IPv4 ネットワークの TLS 証明書を設定する
- IPv4 ネットワークのホステッドクラスターをデプロイする
- IPv4 ネットワークのデプロイメントを終了する
1.7.10.5.1. IPv4 ネットワーク用のハイパーバイザーを設定する
以下の情報は、仮想マシン環境にのみ適用されます。
1.7.10.5.1.1. 仮想 OpenShift Container Platform クラスターのパッケージへのアクセスおよびデプロイ
仮想 OpenShift Container Platform 管理クラスターをデプロイするには、以下のコマンドを入力して必要なパッケージにアクセスします。
sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y
次のコマンドを入力して、Podman サービスを有効にして起動します。
systemctl enable --now podman
kcliを使用して OpenShift Container Platform 管理クラスターおよびその他の仮想コンポーネントをデプロイするには、以下のコマンドを入力してハイパーバイザーをインストールおよび設定します。sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
sudo usermod -aG qemu,libvirt $(id -un)
sudo newgrp libvirt
sudo systemctl enable --now libvirtd
sudo dnf -y copr enable karmab/kcli
sudo dnf -y install kcli
sudo kcli create pool -p /var/lib/libvirt/images default
kcli create host kvm -H 127.0.0.1 local
sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
kcli create network -c 192.168.122.0/24 default
1.7.10.5.1.2. ネットワークマネージャーディスパッチャーの有効化
ネットワークマネージャーのディスパッチャーを有効にして、仮想マシンが必要なドメイン、ルート、およびレジストリーを解決できるようにします。ネットワークマネージャーディスパッチャーを有効にするには、
/etc/NetworkManager/dispatcher.d/ディレクトリーに次の内容を含むforcednsという名前のスクリプトを作成し、環境に合わせて必要に応じて値を置き換えます。#!/bin/bash export IP="192.168.126.1" 1 export BASE_RESOLV_CONF="/run/NetworkManager/resolv.conf" if ! [[ `grep -q "$IP" /etc/resolv.conf` ]]; then export TMP_FILE=$(mktemp /etc/forcedns_resolv.conf.XXXXXX) cp $BASE_RESOLV_CONF $TMP_FILE chmod --reference=$BASE_RESOLV_CONF $TMP_FILE sed -i -e "s/dns.base.domain.name//" -e "s/search /& dns.base.domain.name /" -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE 2 mv $TMP_FILE /etc/resolv.conf fi echo "ok"
ファイルを作成したら、次のコマンドを入力してパーミッションを追加します。
chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
-
スクリプトを実行し、出力が
okを返すことを確認します。
1.7.10.5.1.3. BMC アクセスの設定
仮想マシンのベースボード管理コントローラー (BMC) をシミュレートするように
ksushyを設定します。次のコマンドを入力します。sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
kcli create sushy-service --ssl --port 9000
sudo systemctl daemon-reload
systemctl enable --now ksushy
次のコマンドを入力して、サービスが正しく機能しているかどうかをテストします。
systemctl status ksushy
1.7.10.5.1.4. 接続を許可するためのハイパーバイザーシステムの設定
開発環境で作業している場合は、環境内の各種仮想ネットワークを介したさまざまなタイプの接続を許可するようにハイパーバイザーシステムを設定します。
注: 実稼働環境で作業している場合は、安全な環境を維持するために、firewalld サービスの適切なルールを確立し、SELinux ポリシーを設定する必要があります。
SELinux の場合は、次のコマンドを入力します。
sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0
firewalldの場合は、次のコマンドを入力します。systemctl disable --now firewalld
libvirtdの場合は、以下のコマンドを入力します。systemctl restart libvirtd
systemctl enable --now libvirtd
次に、環境に合わせて DNS を設定します。
1.7.10.5.1.5. 関連情報
-
kcli, の詳細は、公式の kcli ドキュメント を参照してください。
1.7.10.5.2. IPv4 ネットワークの DNS を設定する
この手順は、仮想環境とベアメタル環境の両方で、オフライン環境とオンライン環境の両方で必須です。仮想環境とベアメタル環境の主な違いは、リソースを設定する場所にあります。ベアメタル環境では、dnsmasq のような軽量のソリューションではなく、Bind のようなソリューションを使用してください。
- 仮想環境で IPv4 ネットワークの DNS を設定するには、デフォルトの Ingress と DNS の動作 を参照してください。
- ベアメタル上で IPv4 ネットワークの DNS を設定するには、ベアメタル上での DNS の設定 を参照してください。
次にレジストリーをデプロイします。
1.7.10.5.3. IPv4 ネットワーク用のレジストリーをデプロイする
開発環境の場合は、Podman コンテナーを使用して、小規模な自己ホスト型レジストリーをデプロイします。実稼働環境では、Red Hat Quay、Nexus、Artifactory などのエンタープライズでホストされるレジストリーを使用します。
Podman を使用して小規模なレジストリーをデプロイするには、以下の手順を実行します。
特権ユーザーとして
${HOME}ディレクトリーにアクセスし、次のスクリプトを作成します。#!/usr/bin/env bash set -euo pipefail PRIMARY_NIC=$(ls -1 /sys/class/net | grep -v podman | head -1) export PATH=/root/bin:$PATH export PULL_SECRET="/root/baremetal/hub/openshift_pull.json" 1 if [[ ! -f $PULL_SECRET ]];then echo "Pull Secret not found, exiting..." exit 1 fi dnf -y install podman httpd httpd-tools jq skopeo libseccomp-devel export IP=$(ip -o addr show $PRIMARY_NIC | head -1 | awk '{print $4}' | cut -d'/' -f1) REGISTRY_NAME=registry.$(hostname --long) REGISTRY_USER=dummy REGISTRY_PASSWORD=dummy KEY=$(echo -n $REGISTRY_USER:$REGISTRY_PASSWORD | base64) echo "{\"auths\": {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\", \"email\": \"sample-email@domain.ltd\"}}}" > /root/disconnected_pull.json mv ${PULL_SECRET} /root/openshift_pull.json.old jq ".auths += {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\",\"email\": \"sample-email@domain.ltd\"}}" < /root/openshift_pull.json.old > $PULL_SECRET mkdir -p /opt/registry/{auth,certs,data,conf} cat <<EOF > /opt/registry/conf/config.yml version: 0.1 log: fields: service: registry storage: cache: blobdescriptor: inmemory filesystem: rootdirectory: /var/lib/registry delete: enabled: true http: addr: :5000 headers: X-Content-Type-Options: [nosniff] health: storagedriver: enabled: true interval: 10s threshold: 3 compatibility: schema1: enabled: true EOF openssl req -newkey rsa:4096 -nodes -sha256 -keyout /opt/registry/certs/domain.key -x509 -days 3650 -out /opt/registry/certs/domain.crt -subj "/C=US/ST=Madrid/L=San Bernardo/O=Karmalabs/OU=Guitar/CN=$REGISTRY_NAME" -addext "subjectAltName=DNS:$REGISTRY_NAME" cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/ update-ca-trust extract htpasswd -bBc /opt/registry/auth/htpasswd $REGISTRY_USER $REGISTRY_PASSWORD podman create --name registry --net host --security-opt label=disable --replace -v /opt/registry/data:/var/lib/registry:z -v /opt/registry/auth:/auth:z -v /opt/registry/conf/config.yml:/etc/docker/registry/config.yml -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v /opt/registry/certs:/certs:z -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key docker.io/library/registry:latest [ "$?" == "0" ] || !! systemctl enable --now registry- 1
PULL_SECRETの場所は、設定に適した場所に置き換えます。
スクリプトファイル
registry.shという名前を指定して保存します。スクリプトを実行すると、以下の情報がプルされます。- ハイパーバイザーのホスト名に基づくレジストリー名
- 必要な認証情報およびユーザーアクセスの詳細
次のように実行フラグを追加して、パーミッションを調整します。
chmod u+x ${HOME}/registry.shパラメーターを指定せずにスクリプトを実行するには、以下のコマンドを入力します。
${HOME}/registry.shこのスクリプトはサーバーを起動します。
このスクリプトは、管理目的で
systemdサービスを使用します。スクリプトを管理する必要がある場合は、以下のコマンドを使用できます。systemctl status
systemctl start
systemctl stop
レジストリーのルートフォルダーは /opt/registry ディレクトリー内にあり、次のサブディレクトリーが含まれています。
-
certsには TLS 証明書が含まれます。 -
authには認証情報が含まれます。 -
dataにはレジストリーイメージが含まれます。 -
confにはレジストリー設定が含まれています。
1.7.10.5.4. IPv4 ネットワークの管理クラスターの設定
OpenShift Container Platform 管理クラスターを設定するには、dev-scripts を使用できます。または、仮想マシンをベースにしている場合は、kcli ツールを使用できます。以下は、kcli ツールに固有のものです。
ハイパーバイザーで使用するために適切なネットワークの準備が完了していることを確認します。ネットワークは、管理クラスターとホステッドクラスターの両方をホストします。以下の
kcliコマンドを入力します。kcli create network -c 192.168.125.0/24 -P dhcp=false -P dns=false --domain dns.base.domain.name ipv4
ここでは、以下のようになります。
-
-cは、ネットワークの CIDR を指定します。 -
-p dhcp=falseは、設定したdnsmasqによって処理される DHCP を無効にするようにネットワークを設定します。 -
-P dns=false は、DNS を無効にするようにネットワークを設定します。これも、設定したdnsmasqによって処理されます。 -
--domainは、検索するドメインを設定します。 -
dns.base.domain.nameは DNS ベースドメイン名です。 -
ipv4は、作成するネットワークの名前です。
-
ネットワークを作成したら、以下の出力を確認します。
[root@hypershiftbm ~]# kcli list network Listing Networks... +---------+--------+---------------------+-------+------------------+------+ | Network | Type | Cidr | Dhcp | Domain | Mode | +---------+--------+---------------------+-------+------------------+------+ | default | routed | 192.168.122.0/24 | True | default | nat | | ipv4 | routed | 192.168.125.0/24 | False | dns.base.domain.name | nat | | ipv6 | routed | 2620:52:0:1306::/64 | False | dns.base.domain.name | nat | +---------+--------+---------------------+-------+------------------+------+
[root@hypershiftbm ~]# kcli info network ipv4 Providing information about network ipv4... cidr: 192.168.125.0/24 dhcp: false domain: dns.base.domain.name mode: nat plan: kvirt type: routed
OpenShift Container Platform 管理クラスターをデプロイできるように、プルシークレットと
kcliプランファイルが配置されていることを確認します。-
プルシークレットが
kcliプランと同じフォルダーにあり、プルシークレットファイルの名前がopenshift_pull.jsonであることを確認します。 -
OpenShift Container Platform 定義を含む
kcliプランをmgmt-compact-hub-ipv4.yamlファイルに追加します。ご使用の環境に合わせてファイルの内容を更新してください。
plan: hub-ipv4 force: true version: nightly tag: "4.14.0-0.nightly-2023-08-29-102237" cluster: "hub-ipv4" domain: dns.base.domain.name api_ip: 192.168.125.10 ingress_ip: 192.168.125.11 disconnected_url: registry.dns.base.domain.name:5000 disconnected_update: true disconnected_user: dummy disconnected_password: dummy disconnected_operators_version: v4.14 disconnected_operators: - name: metallb-operator - name: lvms-operator channels: - name: stable-4.13 disconnected_extra_images: - quay.io/user-name/trbsht:latest - quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3 - registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10 dualstack: false disk_size: 200 extra_disks: [200] memory: 48000 numcpus: 16 ctlplanes: 3 workers: 0 manifests: extra-manifests metal3: true network: ipv4 users_dev: developer users_devpassword: developer users_admin: admin users_adminpassword: admin metallb_pool: ipv4-virtual-network metallb_ranges: - 192.168.125.150-192.168.125.190 metallb_autoassign: true apps: - users - lvms-operator - metallb-operator vmrules: - hub-bootstrap: nets: - name: ipv4 mac: aa:aa:aa:aa:02:10 - hub-ctlplane-0: nets: - name: ipv4 mac: aa:aa:aa:aa:02:01 - hub-ctlplane-1: nets: - name: ipv4 mac: aa:aa:aa:aa:02:02 - hub-ctlplane-2: nets: - name: ipv4 mac: aa:aa:aa:aa:02:03-
プルシークレットが
管理クラスターをプロビジョニングするには、以下のコマンドを入力します。
kcli create cluster openshift --pf mgmt-compact-hub-ipv4.yaml
1.7.10.5.4.1. 関連情報
-
kcliプランファイルのパラメーターの詳細は、kcli公式ドキュメントの parameters.yml の作成 を参照してください。
1.7.10.5.5. IPv4 ネットワーク用の Web サーバーを設定する
ホステッドクラスターとしてデプロイする OpenShift Container Platform リリースに関連付けられた Red Hat Enterprise Linux CoreOS (RHCOS) イメージをホストするには、追加の Web サーバーを設定する必要があります。
Web サーバーを設定するには、以下の手順を実行します。
以下のコマンドを入力して、使用する OpenShift Container Platform リリースから
openshift-installバイナリーを展開します。oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"次のスクリプトを実行します。このスクリプトは、
/opt/srvディレクトリーにフォルダーを作成します。このフォルダーには、ワーカーノードをプロビジョニングするための RHCOS イメージが含まれています。#!/bin/bash WEBSRV_FOLDER=/opt/srv ROOTFS_IMG_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.pxe.rootfs.location')" 1 LIVE_ISO_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location')" 2 mkdir -p ${WEBSRV_FOLDER}/images curl -Lk ${ROOTFS_IMG_URL} -o ${WEBSRV_FOLDER}/images/${ROOTFS_IMG_URL##*/} curl -Lk ${LIVE_ISO_URL} -o ${WEBSRV_FOLDER}/images/${LIVE_ISO_URL##*/} chmod -R 755 ${WEBSRV_FOLDER}/* ## Run Webserver podman ps --noheading | grep -q websrv-ai if [[ $? == 0 ]];then echo "Launching Registry pod..." /usr/bin/podman run --name websrv-ai --net host -v /opt/srv:/usr/local/apache2/htdocs:z quay.io/alosadag/httpd:p8080 fi
ダウンロードが完了すると、コンテナーが実行され、Web サーバー上でイメージをホストします。このコンテナーは公式 HTTPd イメージのバリエーションを使用しているので、IPv6 ネットワークでの動作も可能になります。
1.7.10.5.6. IPv4 ネットワークのイメージミラーリングを設定する
イメージミラーリングは、registry.redhat.com や quay.io などの外部レジストリーからイメージを取得し、プライベートレジストリーに保存するプロセスです。
1.7.10.5.6.1. ミラーリングプロセスの完了
注: ミラーリングプロセスは、レジストリーサーバーの実行後に開始してください。
次の手順では、ImageSetConfiguration オブジェクトを使用するバイナリーである、oc-mirror ツールが使用されます。このファイルで、以下の情報を指定できます。
-
ミラーリングする OpenShift Container Platform バージョン。バージョンは
quay.ioにあります。 - ミラーリングする追加の Operator。パッケージは個別に選択します。
- リポジトリーに追加する追加のイメージ。
イメージのミラーリングを設定するには、以下の手順を実行します。
-
${HOME}/.docker/config.jsonファイルが、ミラーリング元のレジストリーとイメージのプッシュ先のプライベートレジストリーで更新されていることを確認します。 次の例を使用して、ミラーリングに使用する
ImageSetConfigurationオブジェクトを作成します。環境に合わせて必要に応じて値を置き換えます。apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: registry: imageURL: registry.dns.base.domain.name:5000/openshift/release/metadata:latest 1 mirror: platform: channels: - name: candidate-4.14 minVersion: 4.14.0-ec.1 maxVersion: 4.14.0-ec.3 type: ocp graph: true additionalImages: - name: quay.io/karmab/origin-keepalived-ipfailover:latest - name: quay.io/karmab/kubectl:latest - name: quay.io/karmab/haproxy:latest - name: quay.io/karmab/mdns-publisher:latest - name: quay.io/karmab/origin-coredns:latest - name: quay.io/karmab/curl:latest - name: quay.io/karmab/kcli:latest - name: quay.io/user-name/trbsht:latest - name: quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3 - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14 packages: - name: lvms-operator - name: local-storage-operator - name: odf-csi-addons-operator - name: odf-operator - name: mcg-operator - name: ocs-operator - name: metallb-operator - name: kubevirt-hyperconverged- 1
dns.base.domain.nameは DNS ベースドメイン名に置き換えます。
次のコマンドを入力して、ミラーリングプロセスを開始します。
oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}ミラーリングプロセスが完了すると、
oc-mirror-workspace/results-XXXXXX/という名前の新しいフォルダーが作成されます。このフォルダーには、ICSP と、ホステッドクラスターに適用するカタログソースが含まれます。oc adm release mirrorコマンドを使用して、OpenShift Container Platform のナイトリーバージョンまたは CI バージョンをミラーリングします。以下のコマンドを入力します。REGISTRY=registry.$(hostname --long):5000 oc adm release mirror \ --from=registry.ci.openshift.org/ocp/release:4.14.0-0.nightly-2023-08-29-102237 \ --to=${REGISTRY}/openshift/release \ --to-release-image=${REGISTRY}/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237- 非接続ネットワークへのインストール の手順に従って、最新の multicluster engine Operator イメージをミラーリングします。
1.7.10.5.6.2. 管理クラスターでのオブジェクトの適用
ミラーリングプロセスが完了したら、管理クラスターに 2 つのオブジェクトを適用する必要があります。
- イメージコンテンツソースポリシー (ICSP) またはイメージダイジェストミラーセット (IDMS)
- カタログソース
oc-mirror ツールを使用すると、出力アーティファクトは oc-mirror-workspace/results-XXXXXX/ という名前のフォルダーに保存されます。
ICSP または IDMS は、ノードを再起動せずに、各ノードで kubelet を再起動する MachineConfig 変更を開始します。ノードが READY としてマークされたら、新しく生成されたカタログソースを適用する必要があります。
カタログソースは、カタログイメージのダウンロードや処理を行い、そのイメージに含まれるすべての PackageManifests を取得するなど、openshift-marketplace Operator でアクションを開始します。
新しいソースを確認するには、新しい
CatalogSourceをソースとして使用して次のコマンドを実行します。oc get packagemanifest
アーティファクトを適用するには、次の手順を実行します。
次のコマンドを入力して、ImageContentSourcePolicy (ICSP) または IDMS アーティファクトを作成します。
oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
- ノードの準備が完了するまで待ってから、次のコマンドを入力します。
oc apply -f catalogSource-XXXXXXXX-index.yaml
OLM カタログをミラーリングし、ホステッドクラスターがミラーを指すように設定します。
管理(デフォルト) OLMCatalogPlacement モードを使用する場合、OLM カタログに使用されるイメージストリームは、管理クラスター上の ICSP からのオーバーライド情報で自動的に修正されません。-
OLM カタログが元の名前とタグを使用して内部レジストリーに適切にミラーリングされている場合は、
hypershift.openshift.io/olm-catalogs-is-registry-overridesアノテーションをHostedClusterリソースに追加します。形式は"sr1=dr1,sr2=dr2" です。ソースレジストリーの文字列はキーで、宛先のレジストリーは値になります。 OLM カタログイメージストリームメカニズムをバイパスするには、
HostedClusterリソースで次の 4 つのアノテーションを使用して、OLM Operator カタログに使用する 4 つのイメージのアドレスを直接指定します。-
hypershift.openshift.io/certified-operators-catalog-image -
hypershift.openshift.io/community-operators-catalog-image -
hypershift.openshift.io/redhat-marketplace-catalog-image -
hypershift.openshift.io/redhat-operators-catalog-image
この場合、イメージストリームは作成されないため、Operator の更新を取り込むために内部ミラーの更新時に、アノテーションの値を更新する必要があります。
-
注: 上書きメカニズムが必要な場合は、4 つのデフォルトのカタログソースの値 4 つすべてが必要です。
-
OLM カタログが元の名前とタグを使用して内部レジストリーに適切にミラーリングされている場合は、
1.7.10.5.6.3. 関連情報
- 仮想環境で作業している場合は、ミラーリングを設定した後、OpenShift Virtualization 上の Hosted Control Plane の前提条件 を満たしていることを確認してください。
- OpenShift Container Platform のナイトリーバージョンまたは CI バージョンのミラーリングの詳細は、oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング を参照してください。
1.7.10.5.7. IPv4 ネットワーク用のマルチクラスターエンジン Operator をデプロイする
マルチクラスターエンジン Operator は、プロバイダー間でクラスターをデプロイメントする場合に重要な役割を果たします。Red Hat Advanced Cluster Management をすでにインストールしている場合は、マルチクラスターエンジン Operator は自動的にインストールされるため、インストールする必要はありません。
マルチクラスターエンジン Operator がインストールされていない場合は、次のドキュメントを参照して、前提条件とインストール手順を確認してください。
1.7.10.5.7.1. AgentServiceConfig リソースのデプロイ
AgentServiceConfig カスタムリソースは、マルチクラスターエンジン Operator の一部である Assisted Service アドオンの重要なコンポーネントです。このコンポーネントは、ベアメタルクラスターをデプロイメントします。アドオンが有効な場合に、AgentServiceConfig リソースをデプロイしてアドオンを設定します。
AgentServiceConfig リソースの設定に加えて、マルチクラスターエンジン Operator が非接続環境で適切に機能するように、追加の config map を含める必要があります。
次の config map を追加してカスタムレジストリーを設定します。これには、デプロイメントをカスタマイズするための非接続環境の情報が含まれています。
--- apiVersion: v1 kind: ConfigMap metadata: name: custom-registries namespace: multicluster-engine labels: app: assisted-service data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- registries.conf: | unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] [[registry]] prefix = "" location = "registry.redhat.io/openshift4" mirror-by-digest-only = true [[registry.mirror]] location = "registry.dns.base.domain.name:5000/openshift4" 1 [[registry]] prefix = "" location = "registry.redhat.io/rhacm2" mirror-by-digest-only = true ... ...- 1
dns.base.domain.nameは DNS ベースドメイン名に置き換えます。
オブジェクトには、以下の 2 つのフィールドが含まれます。
- カスタム CA: このフィールドには、デプロイメントのさまざまなプロセスに読み込まれる認証局 (CA) が含まれます。
-
レジストリー:
Registries.confフィールドには、元のソースレジストリーではなくミラーレジストリーから使用する必要があるイメージと namespace に関する情報が含まれています。
次の例に示すように、
AssistedServiceConfigオブジェクトを追加して、Assisted Service を設定します。--- apiVersion: agent-install.openshift.io/v1beta1 kind: AgentServiceConfig metadata: annotations: unsupported.agent-install.openshift.io/assisted-service-configmap: assisted-service-config 1 name: agent namespace: multicluster-engine spec: mirrorRegistryRef: name: custom-registries 2 databaseStorage: storageClassName: lvms-vg1 accessModes: - ReadWriteOnce resources: requests: storage: 10Gi filesystemStorage: storageClassName: lvms-vg1 accessModes: - ReadWriteOnce resources: requests: storage: 20Gi osImages: 3 - cpuArchitecture: x86_64 openshiftVersion: "4.14" rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live-rootfs.x86_64.img 4 url: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live.x86_64.iso version: 414.92.202308281054-0- 1
metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"]アノテーションは、Operator が動作をカスタマイズするために使用する config map 名を参照します。- 2
spec.mirrorRegistryRef.nameアノテーションは、Assisted Service Operator が使用する非接続のレジストリー情報を含む config map を指します。この config map は、デプロイメントプロセス中にこれらのリソースを追加します。- 3
spec.osImagesフィールドには、この Operator がデプロイできるさまざまなバージョンが含まれています。このフィールドは必須です。この例では、RootFSファイルとLiveISOファイルがすでにダウンロードされていることを前提としています。- 4
rootFSUrl フィールドとurlフィールドで、dns.base.domain.nameを DNS ベースドメイン名に置き換えます。
すべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに適用し、これらのオブジェクトをデプロイします。起動するには、以下のコマンドを実行します。
oc apply -f agentServiceConfig.yaml
このコマンドは、次の出力例に示すように、2 つの Pod をトリガーします。
assisted-image-service-0 1/1 Running 2 11d 1 assisted-service-668b49548-9m7xw 2/2 Running 5 11d 2
1.7.10.5.8. IPv4 ネットワークの TLS 証明書を設定する
オフライン環境で Hosted Control Plane を設定するプロセスに、いくつかの TLS 証明書が関与します。認証局 (CA) を管理クラスターに追加するには、OpenShift Container Platform コントロールプレーンおよびワーカーノード内の以下のファイルの内容を変更する必要があります。
-
/etc/pki/ca-trust/extracted/pem/ -
/etc/pki/ca-trust/source/anchors -
/etc/pki/tls/certs/
CA を管理クラスターに追加するには、次の手順を実行します。
-
OpenShift Container Platform の公式ドキュメントの CA バンドルの更新 の手順を完了します。この方法には、CA を OpenShift Container Platform ノードにデプロイする
image-registry-operatorの使用が含まれます。 この方法が実際の状況に該当しない場合は、管理クラスター内の
openshift-confignamespace にuser-ca-bundleという名前の config map が含まれているかどうかを確認してください。namespace にその config map が含まれている場合は、次のコマンドを入力します。
## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE> export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${REGISTRY_CERT_PATH}namespace にその config map が含まれていない場合は、以下のコマンドを入力します。
## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE> export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt export TMP_FILE=$(mktemp) oc get cm -n openshift-config user-ca-bundle -ojsonpath='{.data.ca-bundle\.crt}' > ${TMP_FILE} echo >> ${TMP_FILE} echo \#registry.$(hostname --long) >> ${TMP_FILE} cat ${REGISTRY_CERT_PATH} >> ${TMP_FILE} oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${TMP_FILE} --dry-run=client -o yaml | kubectl apply -f -
1.7.10.5.9. IPv4 ネットワークのホステッドクラスターをデプロイする
ホステッドクラスターは、コントロールプレーンと API エンドポイントが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。
Red Hat Advanced Cluster Management のコンソールを使用してホステッドクラスターを作成できますが、次の手順ではマニフェストを使用するため、関連するアーティファクトをより柔軟に変更できます。
1.7.10.5.9.1. ホステッドクラスターオブジェクトのデプロイ
この手順では、次の値が使用されます。
-
HostedCluster name:
hosted-ipv4 -
HostedCluster namespace:
clusters -
Disconnected:
true -
Network stack:
IPv4
通常、HyperShift Operator は HostedControlPlane namespace を作成します。ただし、この場合は、HyperShift Operator が HostedCluster オブジェクトの調整を開始する前に、すべてのオブジェクトを含める必要があります。その後、Operator が調整プロセスを開始すると、所定の場所にあるすべてのオブジェクトを見つけることができます。
namespace に関する次の情報を含めて、YAML ファイルを作成します。
--- apiVersion: v1 kind: Namespace metadata: creationTimestamp: null name: clusters-hosted-ipv4 spec: {} status: {} --- apiVersion: v1 kind: Namespace metadata: creationTimestamp: null name: clusters spec: {} status: {}config map とシークレットに関する次の情報を含む YAML ファイルを作成し、
HostedClusterデプロイメントに追加します。--- apiVersion: v1 data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- kind: ConfigMap metadata: name: user-ca-bundle namespace: clusters --- apiVersion: v1 data: .dockerconfigjson: xxxxxxxxx kind: Secret metadata: creationTimestamp: null name: hosted-ipv4-pull-secret namespace: clusters --- apiVersion: v1 kind: Secret metadata: name: sshkey-cluster-hosted-ipv4 namespace: clusters stringData: id_rsa.pub: ssh-rsa xxxxxxxxx --- apiVersion: v1 data: key: nTPtVBEt03owkrKhIdmSW8jrWRxU57KO/fnZa8oaG0Y= kind: Secret metadata: creationTimestamp: null name: hosted-ipv4-etcd-encryption-key namespace: clusters type: OpaqueRBAC ロールを含む YAML ファイルを作成し、Assisted Service エージェントが Hosted Control Plane と同じ
HostedControlPlanenamespace に配置し、引き続きクラスター API で管理されるようにします。apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: capi-provider-role namespace: clusters-hosted-ipv4 rules: - apiGroups: - agent-install.openshift.io resources: - agents verbs: - '*'
HostedClusterオブジェクトに関する情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。apiVersion: hypershift.openshift.io/v1beta1 kind: HostedCluster metadata: name: hosted-ipv4 namespace: clusters spec: additionalTrustBundle: name: "user-ca-bundle" olmCatalogPlacement: guest imageContentSources: 1 - source: quay.io/openshift-release-dev/ocp-v4.0-art-dev mirrors: - registry.dns.base.domain.name:5000/openshift/release - source: quay.io/openshift-release-dev/ocp-release mirrors: - registry.dns.base.domain.name:5000/openshift/release-images - mirrors: ... ... autoscaling: {} controllerAvailabilityPolicy: SingleReplica dns: baseDomain: dns.base.domain.name etcd: managed: storage: persistentVolume: size: 8Gi restoreSnapshotURL: null type: PersistentVolume managementType: Managed fips: false networking: clusterNetwork: - cidr: 10.132.0.0/14 networkType: OVNKubernetes serviceNetwork: - cidr: 172.31.0.0/16 platform: agent: agentNamespace: clusters-hosted-ipv4 type: Agent pullSecret: name: hosted-ipv4-pull-secret release: image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237 secretEncryption: aescbc: activeKey: name: hosted-ipv4-etcd-encryption-key type: aescbc services: - service: APIServer servicePublishingStrategy: nodePort: address: api.hosted-ipv4.dns.base.domain.name type: NodePort - service: OAuthServer servicePublishingStrategy: nodePort: address: api.hosted-ipv4.dns.base.domain.name type: NodePort - service: OIDC servicePublishingStrategy: nodePort: address: api.hosted-ipv4.dns.base.domain.name type: NodePort - service: Konnectivity servicePublishingStrategy: nodePort: address: api.hosted-ipv4.dns.base.domain.name type: NodePort - service: Ignition servicePublishingStrategy: nodePort: address: api.hosted-ipv4.dns.base.domain.name type: NodePort sshKey: name: sshkey-cluster-hosted-ipv4 status: controlPlaneEndpoint: host: "" port: 0dns.base.domain.nameは DNS ベースドメイン名です。- 1
imageContentSourcesセクションには、ホステッドクラスター内のユーザーワークロードのミラー参照が含まれます。
OpenShift Container Platform リリースの HyperShift Operator リリースを指すアノテーションを
HostedClusterオブジェクトに追加します。次のコマンドを入力して、イメージペイロードを取得します。
oc adm release info registry.dns.base.domain.name:5000/openshift-release-dev/ocp-release:4.14.0-rc.1-x86_64 | grep hypershift
dns.base.domain.nameは DNS ベースドメイン名です。以下の出力を参照してください。
hypershift sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
OpenShift Container Platform Images namespace を使用して、次のコマンドを入力してダイジェストを確認します。
podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
dns.base.domain.nameは DNS ベースドメイン名です。以下の出力を参照してください。
podman pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8 Trying to pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8... Getting image source signatures Copying blob d8190195889e skipped: already exists Copying blob c71d2589fba7 skipped: already exists Copying blob d4dc6e74b6ce skipped: already exists Copying blob 97da74cc6d8f skipped: already exists Copying blob b70007a560c9 done Copying config 3a62961e6e done Writing manifest to image destination Storing signatures 3a62961e6ed6edab46d5ec8429ff1f41d6bb68de51271f037c6cb8941a007fde
注:
HostedClusterオブジェクトに設定されるリリースイメージでは、タグではなくダイジェストを使用する必要があります (例:quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c47a0)。YAML ファイルで定義したすべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに対して適用して作成します。起動するには、以下のコマンドを実行します。
oc apply -f 01-4.14-hosted_cluster-nodeport.yaml
Hosted Control Plane の出力を参照してください。
NAME READY STATUS RESTARTS AGE capi-provider-5b57dbd6d5-pxlqc 1/1 Running 0 3m57s catalog-operator-9694884dd-m7zzv 2/2 Running 0 93s cluster-api-f98b9467c-9hfrq 1/1 Running 0 3m57s cluster-autoscaler-d7f95dd5-d8m5d 1/1 Running 0 93s cluster-image-registry-operator-5ff5944b4b-648ht 1/2 Running 0 93s cluster-network-operator-77b896ddc-wpkq8 1/1 Running 0 94s cluster-node-tuning-operator-84956cd484-4hfgf 1/1 Running 0 94s cluster-policy-controller-5fd8595d97-rhbwf 1/1 Running 0 95s cluster-storage-operator-54dcf584b5-xrnts 1/1 Running 0 93s cluster-version-operator-9c554b999-l22s7 1/1 Running 0 95s control-plane-operator-6fdc9c569-t7hr4 1/1 Running 0 3m57s csi-snapshot-controller-785c6dc77c-8ljmr 1/1 Running 0 77s csi-snapshot-controller-operator-7c6674bc5b-d9dtp 1/1 Running 0 93s csi-snapshot-webhook-5b8584875f-2492j 1/1 Running 0 77s dns-operator-6874b577f-9tc6b 1/1 Running 0 94s etcd-0 3/3 Running 0 3m39s hosted-cluster-config-operator-f5cf5c464-4nmbh 1/1 Running 0 93s ignition-server-6b689748fc-zdqzk 1/1 Running 0 95s ignition-server-proxy-54d4bb9b9b-6zkg7 1/1 Running 0 95s ingress-operator-6548dc758b-f9gtg 1/2 Running 0 94s konnectivity-agent-7767cdc6f5-tw782 1/1 Running 0 95s kube-apiserver-7b5799b6c8-9f5bp 4/4 Running 0 3m7s kube-controller-manager-5465bc4dd6-zpdlk 1/1 Running 0 44s kube-scheduler-5dd5f78b94-bbbck 1/1 Running 0 2m36s machine-approver-846c69f56-jxvfr 1/1 Running 0 92s oauth-openshift-79c7bf44bf-j975g 2/2 Running 0 62s olm-operator-767f9584c-4lcl2 2/2 Running 0 93s openshift-apiserver-5d469778c6-pl8tj 3/3 Running 0 2m36s openshift-controller-manager-6475fdff58-hl4f7 1/1 Running 0 95s openshift-oauth-apiserver-dbbc5cc5f-98574 2/2 Running 0 95s openshift-route-controller-manager-5f6997b48f-s9vdc 1/1 Running 0 95s packageserver-67c87d4d4f-kl7qh 2/2 Running 0 93s
ホステッドクラスターの出力を確認します。
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters hosted-ipv4 hosted-admin-kubeconfig Partial True False The hosted control plane is available
次に、NodePool オブジェクトを作成します。
1.7.10.5.9.2. ホステッドクラスターの NodePool オブジェクトの作成
NodePool は、ホステッドクラスターに関連付けられたスケーラブルなワーカーノードのセットです。NodePool マシンアーキテクチャーは特定のプール内で一貫性を保ち、コントロールプレーンのマシンアーキテクチャーから独立しています。
NodePoolオブジェクトに関する次の情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。apiVersion: hypershift.openshift.io/v1beta1 kind: NodePool metadata: creationTimestamp: null name: hosted-ipv4 namespace: clusters spec: arch: amd64 clusterName: hosted-ipv4 management: autoRepair: false 1 upgradeType: InPlace 2 nodeDrainTimeout: 0s platform: type: Agent release: image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237 3 replicas: 0 status: replicas: 0 4- 1
- ノードが削除された場合、ノードは再作成されないため、
autoRepairフィールドはfalseに設定されます。 - 2
upgradeTypeはInPlaceに設定されます。これは、アップグレード中に同じベアメタルノードが再利用されることを示します。- 3
- この
NodePoolに含まれるすべてのノードは、OpenShift Container Platform バージョン4.14.0-0.nightly-2023-08-29-102237に基づいています。dns.base.domain.nameは DNS ベースドメイン名に置き換えます。 - 4
replicasの値は0に設定されているため、必要に応じてスケールを変更できます。すべての手順が完了するまで、NodePoolレプリカを 0 に保つことが重要です。
次のコマンドを入力して、
NodePoolオブジェクトを作成します。oc apply -f 02-nodepool.yaml
出力を参照してください。
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters hosted-ipv4 hosted 0 False False 4.14.0-0.nightly-2023-08-29-102237
次に、InfraEnv リソースを作成します。
1.7.10.5.9.3. ホステッドクラスターの InfraEnv リソースの作成
InfraEnv リソースは、pullSecretRef や sshAuthorizedKey などの重要な詳細を含む Assisted Service オブジェクトです。これらの詳細は、ホステッドクラスター用にカスタマイズされた Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージを作成するために使用されます。
InfraEnvリソースに関する次の情報を含めて YAML ファイルを作成し、必要に応じて値を置き換えます。--- apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: hosted-ipv4 namespace: clusters-hosted-ipv4 spec: pullSecretRef: 1 name: pull-secret sshAuthorizedKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDk7ICaUE+/k4zTpxLk4+xFdHi4ZuDi5qjeF52afsNkw0w/glILHhwpL5gnp5WkRuL8GwJuZ1VqLC9EKrdmegn4MrmUlq7WTsP0VFOZFBfq2XRUxo1wrRdor2z0Bbh93ytR+ZsDbbLlGngXaMa0Vbt+z74FqlcajbHTZ6zBmTpBVq5RHtDPgKITdpE1fongp7+ZXQNBlkaavaqv8bnyrP4BWahLP4iO9/xJF9lQYboYwEEDzmnKLMW1VtCE6nJzEgWCufACTbxpNS7GvKtoHT/OVzw8ArEXhZXQUS1UY8zKsX2iXwmyhw5Sj6YboA8WICs4z+TrFP89LmxXY0j6536TQFyRz1iB4WWvCbH5n6W+ABV2e8ssJB1AmEy8QYNwpJQJNpSxzoKBjI73XxvPYYC/IjPFMySwZqrSZCkJYqQ023ySkaQxWZT7in4KeMu7eS2tC+Kn4deJ7KwwUycx8n6RHMeD8Qg9flTHCv3gmab8JKZJqN3hW1D378JuvmIX4V0= 2
次のコマンドを入力して、
InfraEnvリソースを作成します。oc apply -f 03-infraenv.yaml
以下の出力を参照してください。
NAMESPACE NAME ISO CREATED AT clusters-hosted-ipv4 hosted 2023-09-11T15:14:10Z
次に、ワーカーノードを作成します。
1.7.10.5.9.4. ホステッドクラスター用のワーカーノードの作成
ベアメタルプラットフォームで作業している場合、BareMetalHost の詳細が正しく設定されていることを確認するためにワーカーノードを作成することが重要です。
仮想マシンを使用している場合は、次の手順を実行して、Metal3 Operator が使用する空のワーカーノードを作成できます。これには、kcli を使用します。
ワーカーノードを作成するのが初めてではない場合は、まず以前の設定を削除する必要があります。これには、次のコマンドを入力してプランを削除します。
kcli delete plan hosted-ipv4
-
プランを削除するかどうかを確認するプロンプトが表示されたら、
yと入力します。 - プランが削除されたことを示すメッセージが表示されることを確認します。
-
プランを削除するかどうかを確認するプロンプトが表示されたら、
次のコマンドを入力して仮想マシンを作成します。
kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv4 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv4\", \"mac\": \"aa:aa:aa:aa:02:11\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0211 -P name=hosted-ipv4-worker0kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv4 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv4\", \"mac\": \"aa:aa:aa:aa:02:12\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0212 -P name=hosted-ipv4-worker1kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv4 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv4\", \"mac\": \"aa:aa:aa:aa:02:13\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0213 -P name=hosted-ipv4-worker2systemctl restart ksushy
ここでは、以下のようになります。
-
start=Falseは、仮想マシン (VM) が作成時に自動的に起動しないことを意味します。 -
uefi_legacy=trueは、以前の UEFI 実装との互換性を確保するために UEFI レガシーブートを使用することを意味します。 -
plan=hosted-dualは、マシンのグループをクラスターとして識別するプラン名を示します。 -
memory=8192およびnumcpus=16は、RAM や CPU などの仮想マシンのリソースを指定するパラメーターです。 -
disks=[200,200]は、VM 内に 2 つのシンプロビジョニングディスクを作成していることを示します。 -
nets=[{"name": "dual", "mac": "aa:aa:aa:aa:02:13"}]は、接続するネットワーク名やプライマリーインターフェイスの MAC アドレスなど、ネットワークの詳細です。 -
restart ksushyは、ksushyツールを再起動して、追加した VM をツールが確実に検出できるようにします。
-
結果の出力を確認します。
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+ | Name | Status | Ip | Source | Plan | Profile | +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+ | hosted-worker0 | down | | | hosted-ipv4 | kvirt | | hosted-worker1 | down | | | hosted-ipv4 | kvirt | | hosted-worker2 | down | | | hosted-ipv4 | kvirt | +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
次に、ホステッドクラスターのベアメタルホストを作成します。
1.7.10.5.9.5. ホステッドクラスターのベアメタルホスト作成
ベアメタルホスト は、物理的な詳細と論理詳細を含む openshift-machine-api オブジェクトで、Metal3 Operator によって識別できるようになっています。これらの詳細は、agents と呼ばれる他の Assisted Service オブジェクトに関連付けられています。
重要: ベアメタルホストと移行先ノードを作成する前に、仮想マシンを作成する必要があります。
ベアメタルホストを作成するには、以下の手順を実行します。
次の情報を使用して YAML ファイルを作成します。
注記: ベアメタルホストの認証情報を保持するシークレットが 1 つ以上あるため、ワーカーノードごとに少なくとも 2 つのオブジェクトを作成する必要があります。
--- apiVersion: v1 kind: Secret metadata: name: hosted-ipv4-worker0-bmc-secret namespace: clusters-hosted-ipv4 data: password: YWRtaW4= username: YWRtaW4= type: Opaque --- apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: hosted-ipv4-worker0 namespace: clusters-hosted-ipv4 labels: infraenvs.agent-install.openshift.io: hosted-ipv4 1 annotations: inspect.metal3.io: disabled bmac.agent-install.openshift.io/hostname: hosted-ipv4-worker0 2 spec: automatedCleaningMode: disabled 3 bmc: disableCertificateVerification: true 4 address: redfish-virtualmedia://[192.168.125.1]:9000/redfish/v1/Systems/local/hosted-ipv4-worker0 5 credentialsName: hosted-ipv4-worker0-bmc-secret 6 bootMACAddress: aa:aa:aa:aa:02:11 7 online: true 8- 1
infraenvs.agent-install.openshift.ioは、Assisted Installer オブジェクトとBareMetalHostオブジェクト間のリンクとして機能します。- 2
bmac.agent-install.openshift.io/hostnameは、デプロイメント中に採用されるノード名を表します。- 3
automatedCleaningModeは、ノードが Metal3 Operator によって消去されるのを防ぎます。- 4
disableCertificateVerificationはtrueに設定され、クライアントから証明書の検証がバイパスされます。- 5
addressは、ワーカーノードのベースボード管理コントローラー (BMC) アドレスを示します。- 6
credentialsNameは、ユーザーとパスワードの認証情報が保存されるシークレットを指します。- 7
bootMACAddressは、ノードの起動元のインターフェイス MACAddress を示します。- 8
onlineは、BareMetalHostオブジェクトが作成された後のノードの状態を定義します。
次のコマンドを入力して、
BareMetalHostオブジェクトをデプロイします。oc apply -f 04-bmh.yaml
プロセス中に、次の出力が確認できます。
この出力は、プロセスがノードに到達しようとしていることを示しています。
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 registering true 2s clusters-hosted hosted-worker1 registering true 2s clusters-hosted hosted-worker2 registering true 2s
この出力は、ノードが起動していることを示しています。
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 provisioning true 16s clusters-hosted hosted-worker1 provisioning true 16s clusters-hosted hosted-worker2 provisioning true 16s
- この出力は、ノードが正常に起動したことを示しています。
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 provisioned true 67s clusters-hosted hosted-worker1 provisioned true 67s clusters-hosted hosted-worker2 provisioned true 67s
ノードが起動したら、次の例に示すように、namespace のエージェントに注目してください。
NAMESPACE NAME CLUSTER APPROVED ROLE STAGE clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411 true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412 true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413 true auto-assign
エージェントは、インストールに使用できるノードを表します。ホステッドクラスターにノードを割り当てるには、ノードプールをスケールアップします。
1.7.10.5.9.6. ノードプールのスケールアップ
ベアメタルホストを作成すると、そのステータスが Registering Provisioning、Provisioned に変わります。ノードは、エージェントの LiveISO と、agent という名前のデフォルトの Pod で始まります。このエージェントは、Assisted Service Operator から OpenShift Container Platform ペイロードをインストールする指示を受け取ります。
ノードプールをスケールアップするには、次のコマンドを入力します。
oc -n clusters scale nodepool hosted-ipv4 --replicas 3
スケーリングプロセスが完了すると、エージェントがホステッドクラスターに割り当てられていることがわかります。
NAMESPACE NAME CLUSTER APPROVED ROLE STAGE clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411 hosted true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412 hosted true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413 hosted true auto-assign
また、ノードプールレプリカが設定されていることにも注意してください。
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters hosted hosted 3 False False 4.14.0-0.nightly-2023-08-29-102237 Minimum availability requires 3 replicas, current 0 available
- ノードがクラスターに参加するまで待ちます。プロセス中に、エージェントはステージとステータスに関する最新情報を提供します。
次に、ホステッドクラスターのデプロイメントを監視します。
1.7.10.5.10. IPv4 ネットワーク用のホステッドクラスターのデプロイメントの完了
ホステッドクラスターのデプロイメントは、コントロールプレーンとデータプレーンの 2 つの観点から監視できます。
1.7.10.5.10.1. コントロールプレーンの監視
ホステッドクラスターのデプロイメント中に、次のコマンドを入力してコントロールプレーンを監視できます。
export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
watch "oc get pod -n hypershift;echo;echo;oc get pod -n clusters-hosted-ipv4;echo;echo;oc get bmh -A;echo;echo;oc get agent -A;echo;echo;oc get infraenv -A;echo;echo;oc get hostedcluster -A;echo;echo;oc get nodepool -A;echo;echo;"
これらのコマンドは、次のアーティファクトに関する情報を提供します。
- HyperShift Operator
-
HostedControlPlanePod - ベアメタルホスト
- エージェント
-
InfraEnvリソース -
HostedClusterおよびNodePoolリソース
1.7.10.5.10.2. データプレーンの監視
デプロイメントプロセス中に Operator がどのように進行しているかを監視するには、次のコマンドを入力します。
oc get secret -n clusters-hosted-ipv4 admin-kubeconfig -o jsonpath='{.data.kubeconfig}' |base64 -d > /root/hc_admin_kubeconfig.yamlexport KUBECONFIG=/root/hc_admin_kubeconfig.yaml
watch "oc get clusterversion,nodes,co"
これらのコマンドは、次のアーティファクトに関する情報を提供します。
- クラスターのバージョン
- ノード (特にノードがクラスターに参加したかどうかについて)
- クラスター Operator
1.7.10.6. IPv6 ネットワーク上での Hosted Control Plane の設定
IPv6 ネットワーク設定は、現在 disconnected として指定されます。この指定の主な理由は、リモートレジストリーが IPv6 では機能しないためです。
IPv6 ネットワーク上で Hosted Control Plane を設定するプロセスには、次の手順が含まれます。これについては、以下のセクションで詳しく説明します。
- IPv6 ネットワーク用のハイパーバイザーを設定する
- IPv6 ネットワークの DNS を設定する
- IPv6 ネットワーク用のレジストリーをデプロイする
- IPv6 ネットワークの管理クラスターを設定する
- IPv6 ネットワーク用の Web サーバーを設定する
- IPv6 ネットワークのイメージミラーリングを設定する
- IPv6 ネットワーク用のマルチクラスターエンジン Operator をデプロイする
- IPv6 ネットワークの TLS 証明書を設定する
- IPv6 ネットワークのホステッドクラスターをデプロイする
- IPv6 ネットワークのデプロイメントを終了する
1.7.10.6.1. IPv6 ネットワーク用のハイパーバイザーを設定する
以下の情報は、仮想マシン環境にのみ適用されます。
1.7.10.6.1.1. 仮想 OpenShift Container Platform クラスターのパッケージへのアクセスおよびデプロイ
仮想 OpenShift Container Platform 管理クラスターをデプロイするには、以下のコマンドを入力して必要なパッケージにアクセスします。
sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y
次のコマンドを入力して、Podman サービスを有効にして起動します。
systemctl enable --now podman
kcliを使用して OpenShift Container Platform 管理クラスターおよびその他の仮想コンポーネントをデプロイするには、以下のコマンドを入力してハイパーバイザーをインストールおよび設定します。sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
sudo usermod -aG qemu,libvirt $(id -un)
sudo newgrp libvirt
sudo systemctl enable --now libvirtd
sudo dnf -y copr enable karmab/kcli
sudo dnf -y install kcli
sudo kcli create pool -p /var/lib/libvirt/images default
kcli create host kvm -H 127.0.0.1 local
sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
kcli create network -c 192.168.122.0/24 default
1.7.10.6.1.2. ネットワークマネージャーディスパッチャーの有効化
ネットワークマネージャーのディスパッチャーを有効にして、仮想マシンが必要なドメイン、ルート、およびレジストリーを解決できるようにします。ネットワークマネージャーディスパッチャーを有効にするには、
/etc/NetworkManager/dispatcher.d/ディレクトリーに次の内容を含むforcednsという名前のスクリプトを作成し、環境に合わせて必要に応じて値を置き換えます。#!/bin/bash export IP="2620:52:0:1306::1" 1 export BASE_RESOLV_CONF="/run/NetworkManager/resolv.conf" if ! [[ `grep -q "$IP" /etc/resolv.conf` ]]; then export TMP_FILE=$(mktemp /etc/forcedns_resolv.conf.XXXXXX) cp $BASE_RESOLV_CONF $TMP_FILE chmod --reference=$BASE_RESOLV_CONF $TMP_FILE sed -i -e "s/dns.base.domain.name//" -e "s/search /& dns.base.domain.name /" -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE 2 mv $TMP_FILE /etc/resolv.conf fi echo "ok"
ファイルを作成したら、次のコマンドを入力してパーミッションを追加します。
chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
-
スクリプトを実行し、出力が
okを返すことを確認します。
1.7.10.6.1.3. BMC アクセスの設定
仮想マシンのベースボード管理コントローラー (BMC) をシミュレートするように
ksushyを設定します。次のコマンドを入力します。sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
kcli create sushy-service --ssl --ipv6 --port 9000
sudo systemctl daemon-reload
systemctl enable --now ksushy
次のコマンドを入力して、サービスが正しく機能しているかどうかをテストします。
systemctl status ksushy
1.7.10.6.1.4. 接続を許可するためのハイパーバイザーシステムの設定
開発環境で作業している場合は、環境内の各種仮想ネットワークを介したさまざまなタイプの接続を許可するようにハイパーバイザーシステムを設定します。
注: 実稼働環境で作業している場合は、安全な環境を維持するために、firewalld サービスの適切なルールを確立し、SELinux ポリシーを設定する必要があります。
SELinux の場合は、次のコマンドを入力します。
sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0
firewalldの場合は、次のコマンドを入力します。systemctl disable --now firewalld
libvirtdの場合は、以下のコマンドを入力します。systemctl restart libvirtd
systemctl enable --now libvirtd
次に、環境に合わせて DNS を設定します。
1.7.10.6.1.5. 関連情報
-
kcli, の詳細は、公式の kcli ドキュメント を参照してください。
1.7.10.6.2. IPv6 ネットワークの DNS を設定する
この手順は、仮想環境とベアメタル環境の両方で、オフライン環境とオンライン環境の両方で必須です。仮想環境とベアメタル環境の主な違いは、リソースを設定する場所にあります。ベアメタル環境では、dnsmasq のような軽量のソリューションではなく、Bind のようなソリューションを使用してください。
- 仮想環境で IPv6 ネットワークの DNS を設定するには、デフォルトの Ingress と DNS の動作 を参照してください。
- ベアメタル上で IPv6 ネットワークの DNS を設定するには、ベアメタル上での DNS の設定 を参照してください。
次にレジストリーをデプロイします。
1.7.10.6.3. IPv6 ネットワーク用のレジストリーをデプロイする
開発環境の場合は、Podman コンテナーを使用して、小規模な自己ホスト型レジストリーをデプロイします。実稼働環境では、Red Hat Quay、Nexus、Artifactory などのエンタープライズでホストされるレジストリーを使用します。
Podman を使用して小規模なレジストリーをデプロイするには、以下の手順を実行します。
特権ユーザーとして
${HOME}ディレクトリーにアクセスし、次のスクリプトを作成します。#!/usr/bin/env bash set -euo pipefail PRIMARY_NIC=$(ls -1 /sys/class/net | grep -v podman | head -1) export PATH=/root/bin:$PATH export PULL_SECRET="/root/baremetal/hub/openshift_pull.json" 1 if [[ ! -f $PULL_SECRET ]];then echo "Pull Secret not found, exiting..." exit 1 fi dnf -y install podman httpd httpd-tools jq skopeo libseccomp-devel export IP=$(ip -o addr show $PRIMARY_NIC | head -1 | awk '{print $4}' | cut -d'/' -f1) REGISTRY_NAME=registry.$(hostname --long) REGISTRY_USER=dummy REGISTRY_PASSWORD=dummy KEY=$(echo -n $REGISTRY_USER:$REGISTRY_PASSWORD | base64) echo "{\"auths\": {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\", \"email\": \"sample-email@domain.ltd\"}}}" > /root/disconnected_pull.json mv ${PULL_SECRET} /root/openshift_pull.json.old jq ".auths += {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\",\"email\": \"sample-email@domain.ltd\"}}" < /root/openshift_pull.json.old > $PULL_SECRET mkdir -p /opt/registry/{auth,certs,data,conf} cat <<EOF > /opt/registry/conf/config.yml version: 0.1 log: fields: service: registry storage: cache: blobdescriptor: inmemory filesystem: rootdirectory: /var/lib/registry delete: enabled: true http: addr: :5000 headers: X-Content-Type-Options: [nosniff] health: storagedriver: enabled: true interval: 10s threshold: 3 compatibility: schema1: enabled: true EOF openssl req -newkey rsa:4096 -nodes -sha256 -keyout /opt/registry/certs/domain.key -x509 -days 3650 -out /opt/registry/certs/domain.crt -subj "/C=US/ST=Madrid/L=San Bernardo/O=Karmalabs/OU=Guitar/CN=$REGISTRY_NAME" -addext "subjectAltName=DNS:$REGISTRY_NAME" cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/ update-ca-trust extract htpasswd -bBc /opt/registry/auth/htpasswd $REGISTRY_USER $REGISTRY_PASSWORD podman create --name registry --net host --security-opt label=disable --replace -v /opt/registry/data:/var/lib/registry:z -v /opt/registry/auth:/auth:z -v /opt/registry/conf/config.yml:/etc/docker/registry/config.yml -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v /opt/registry/certs:/certs:z -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key docker.io/library/registry:latest [ "$?" == "0" ] || !! systemctl enable --now registry- 1
PULL_SECRETの場所は、設定に適した場所に置き換えます。
スクリプトファイル
registry.shという名前を指定して保存します。スクリプトを実行すると、以下の情報がプルされます。- ハイパーバイザーのホスト名に基づくレジストリー名
- 必要な認証情報およびユーザーアクセスの詳細
次のように実行フラグを追加して、パーミッションを調整します。
chmod u+x ${HOME}/registry.shパラメーターを指定せずにスクリプトを実行するには、以下のコマンドを入力します。
${HOME}/registry.shこのスクリプトはサーバーを起動します。
このスクリプトは、管理目的で
systemdサービスを使用します。スクリプトを管理する必要がある場合は、以下のコマンドを使用できます。systemctl status
systemctl start
systemctl stop
レジストリーのルートフォルダーは /opt/registry ディレクトリー内にあり、次のサブディレクトリーが含まれています。
-
certsには TLS 証明書が含まれます。 -
authには認証情報が含まれます。 -
dataにはレジストリーイメージが含まれます。 -
confにはレジストリー設定が含まれています。
1.7.10.6.4. IPv6 ネットワークの管理クラスターの設定
OpenShift Container Platform 管理クラスターを設定するには、dev-scripts を使用できます。または、仮想マシンをベースにしている場合は、kcli ツールを使用できます。以下は、kcli ツールに固有のものです。
ハイパーバイザーで使用するために適切なネットワークの準備が完了していることを確認します。ネットワークは、管理クラスターとホステッドクラスターの両方をホストします。以下の
kcliコマンドを入力します。kcli create network -c 2620:52:0:1305::0/64 -P dhcp=false -P dns=false --domain dns.base.domain.name --nodhcp ipv6
ここでは、以下のようになります。
-
-cは、ネットワークの CIDR を指定します。 -
-p dhcp=falseは、設定したdnsmasqによって処理される DHCP を無効にするようにネットワークを設定します。 -
-P dns=false は、DNS を無効にするようにネットワークを設定します。これも、設定したdnsmasqによって処理されます。 -
--domainは、検索するドメインを設定します。 -
dns.base.domain.nameは DNS ベースドメイン名です。 -
ipv6は、作成するネットワークの名前です。
-
ネットワークを作成したら、以下の出力を確認します。
[root@hypershiftbm ~]# kcli list network Listing Networks... +---------+--------+---------------------+-------+------------------+------+ | Network | Type | Cidr | Dhcp | Domain | Mode | +---------+--------+---------------------+-------+------------------+------+ | default | routed | 192.168.122.0/24 | True | default | nat | | ipv4 | routed | 192.168.125.0/24 | False | dns.base.domain.name | nat | | ipv4 | routed | 2620:52:0:1305::/64 | False | dns.base.domain.name | nat | +---------+--------+---------------------+-------+------------------+------+
[root@hypershiftbm ~]# kcli info network ipv6 Providing information about network ipv6... cidr: 2620:52:0:1305::/64 dhcp: false domain: dns.base.domain.name mode: nat plan: kvirt type: routed
OpenShift Container Platform 管理クラスターをデプロイできるように、プルシークレットと
kcliプランファイルが配置されていることを確認します。-
プルシークレットが
kcliプランと同じフォルダーにあり、プルシークレットファイルの名前がopenshift_pull.jsonであることを確認します。 -
OpenShift Container Platform 定義を含む
kcliプランをmgmt-compact-hub-ipv6.yamlファイルに追加します。ご使用の環境に合わせてファイルの内容を更新してください。
plan: hub-ipv6 force: true version: nightly tag: "4.14.0-0.nightly-2023-08-29-102237" cluster: "hub-ipv6" ipv6: true domain: dns.base.domain.name api_ip: 2620:52:0:1305::2 ingress_ip: 2620:52:0:1305::3 disconnected_url: registry.dns.base.domain.name:5000 disconnected_update: true disconnected_user: dummy disconnected_password: dummy disconnected_operators_version: v4.14 disconnected_operators: - name: metallb-operator - name: lvms-operator channels: - name: stable-4.13 disconnected_extra_images: - quay.io/user-name/trbsht:latest - quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3 - registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10 dualstack: false disk_size: 200 extra_disks: [200] memory: 48000 numcpus: 16 ctlplanes: 3 workers: 0 manifests: extra-manifests metal3: true network: ipv6 users_dev: developer users_devpassword: developer users_admin: admin users_adminpassword: admin metallb_pool: ipv6-virtual-network metallb_ranges: - 2620:52:0:1305::150-2620:52:0:1305::190 metallb_autoassign: true apps: - users - lvms-operator - metallb-operator vmrules: - hub-bootstrap: nets: - name: ipv6 mac: aa:aa:aa:aa:03:10 - hub-ctlplane-0: nets: - name: ipv6 mac: aa:aa:aa:aa:03:01 - hub-ctlplane-1: nets: - name: ipv6 mac: aa:aa:aa:aa:03:02 - hub-ctlplane-2: nets: - name: ipv6 mac: aa:aa:aa:aa:03:03-
プルシークレットが
管理クラスターをプロビジョニングするには、以下のコマンドを入力します。
kcli create cluster openshift --pf mgmt-compact-hub-ipv6.yaml
1.7.10.6.4.1. 関連情報
-
kcliプランファイルのパラメーターの詳細は、kcli公式ドキュメントの parameters.yml の作成 を参照してください。
1.7.10.6.5. IPv6 ネットワーク用の Web サーバーを設定する
ホステッドクラスターとしてデプロイする OpenShift Container Platform リリースに関連付けられた Red Hat Enterprise Linux CoreOS (RHCOS) イメージをホストするには、追加の Web サーバーを設定する必要があります。
Web サーバーを設定するには、以下の手順を実行します。
以下のコマンドを入力して、使用する OpenShift Container Platform リリースから
openshift-installバイナリーを展開します。oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"次のスクリプトを実行します。このスクリプトは、
/opt/srvディレクトリーにフォルダーを作成します。このフォルダーには、ワーカーノードをプロビジョニングするための RHCOS イメージが含まれています。#!/bin/bash WEBSRV_FOLDER=/opt/srv ROOTFS_IMG_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.pxe.rootfs.location')" 1 LIVE_ISO_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location')" 2 mkdir -p ${WEBSRV_FOLDER}/images curl -Lk ${ROOTFS_IMG_URL} -o ${WEBSRV_FOLDER}/images/${ROOTFS_IMG_URL##*/} curl -Lk ${LIVE_ISO_URL} -o ${WEBSRV_FOLDER}/images/${LIVE_ISO_URL##*/} chmod -R 755 ${WEBSRV_FOLDER}/* ## Run Webserver podman ps --noheading | grep -q websrv-ai if [[ $? == 0 ]];then echo "Launching Registry pod..." /usr/bin/podman run --name websrv-ai --net host -v /opt/srv:/usr/local/apache2/htdocs:z quay.io/alosadag/httpd:p8080 fi
ダウンロードが完了すると、コンテナーが実行され、Web サーバー上でイメージをホストします。このコンテナーは公式 HTTPd イメージのバリエーションを使用しているので、IPv6 ネットワークでの動作も可能になります。
1.7.10.6.6. IPv6 ネットワークのイメージミラーリングを設定する
イメージミラーリングは、registry.redhat.com や quay.io などの外部レジストリーからイメージを取得し、プライベートレジストリーに保存するプロセスです。
1.7.10.6.6.1. ミラーリングプロセスの完了
注: ミラーリングプロセスは、レジストリーサーバーの実行後に開始してください。
次の手順では、ImageSetConfiguration オブジェクトを使用するバイナリーである、oc-mirror ツールが使用されます。このファイルで、以下の情報を指定できます。
-
ミラーリングする OpenShift Container Platform バージョン。バージョンは
quay.ioにあります。 - ミラーリングする追加の Operator。パッケージは個別に選択します。
- リポジトリーに追加する追加のイメージ。
イメージのミラーリングを設定するには、以下の手順を実行します。
-
${HOME}/.docker/config.jsonファイルが、ミラーリング元のレジストリーとイメージのプッシュ先のプライベートレジストリーで更新されていることを確認します。 次の例を使用して、ミラーリングに使用する
ImageSetConfigurationオブジェクトを作成します。環境に合わせて必要に応じて値を置き換えます。apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: registry: imageURL: registry.dns.base.domain.name:5000/openshift/release/metadata:latest 1 mirror: platform: channels: - name: candidate-4.14 minVersion: 4.14.0-ec.1 maxVersion: 4.14.0-ec.3 type: ocp graph: true additionalImages: - name: quay.io/karmab/origin-keepalived-ipfailover:latest - name: quay.io/karmab/kubectl:latest - name: quay.io/karmab/haproxy:latest - name: quay.io/karmab/mdns-publisher:latest - name: quay.io/karmab/origin-coredns:latest - name: quay.io/karmab/curl:latest - name: quay.io/karmab/kcli:latest - name: quay.io/user-name/trbsht:latest - name: quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3 - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14 packages: - name: lvms-operator - name: local-storage-operator - name: odf-csi-addons-operator - name: odf-operator - name: mcg-operator - name: ocs-operator - name: metallb-operator- 1
dns.base.domain.nameは DNS ベースドメイン名に置き換えます。
次のコマンドを入力して、ミラーリングプロセスを開始します。
oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}ミラーリングプロセスが完了すると、
oc-mirror-workspace/results-XXXXXX/という名前の新しいフォルダーが作成されます。このフォルダーには、ICSP と、ホステッドクラスターに適用するカタログソースが含まれます。oc adm release mirrorコマンドを使用して、OpenShift Container Platform のナイトリーバージョンまたは CI バージョンをミラーリングします。以下のコマンドを入力します。REGISTRY=registry.$(hostname --long):5000 oc adm release mirror \ --from=registry.ci.openshift.org/ocp/release:4.14.0-0.nightly-2023-08-29-102237 \ --to=${REGISTRY}/openshift/release \ --to-release-image=${REGISTRY}/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237- 非接続ネットワークへのインストール の手順に従って、最新の multicluster engine Operator イメージをミラーリングします。
1.7.10.6.6.2. 管理クラスターでのオブジェクトの適用
ミラーリングプロセスが完了したら、管理クラスターに 2 つのオブジェクトを適用する必要があります。
- イメージコンテンツソースポリシー (ICSP) またはイメージダイジェストミラーセット (IDMS)
- カタログソース
oc-mirror ツールを使用すると、出力アーティファクトは oc-mirror-workspace/results-XXXXXX/ という名前のフォルダーに保存されます。
ICSP または IDMS は、ノードを再起動せずに、各ノードで kubelet を再起動する MachineConfig 変更を開始します。ノードが READY としてマークされたら、新しく生成されたカタログソースを適用する必要があります。
カタログソースは、カタログイメージのダウンロードや処理を行い、そのイメージに含まれるすべての PackageManifests を取得するなど、openshift-marketplace Operator でアクションを開始します。
新しいソースを確認するには、新しい
CatalogSourceをソースとして使用して次のコマンドを実行します。oc get packagemanifest
アーティファクトを適用するには、次の手順を実行します。
次のコマンドを入力して、ICSP または IDMS アーティファクトを作成します。
oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
- ノードの準備が完了するまで待ってから、次のコマンドを入力します。
oc apply -f catalogSource-XXXXXXXX-index.yaml
1.7.10.6.6.3. 関連情報
- 仮想環境で作業している場合は、ミラーリングを設定した後、OpenShift Virtualization 上の Hosted Control Plane の前提条件 を満たしていることを確認してください。
- OpenShift Container Platform のナイトリーバージョンまたは CI バージョンのミラーリングの詳細は、oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング を参照してください。
1.7.10.6.7. IPv6 ネットワーク用のマルチクラスターエンジン Operator をデプロイする
マルチクラスターエンジン Operator は、プロバイダー間でクラスターをデプロイメントする場合に重要な役割を果たします。Red Hat Advanced Cluster Management をすでにインストールしている場合は、マルチクラスターエンジン Operator は自動的にインストールされるため、インストールする必要はありません。
マルチクラスターエンジン Operator がインストールされていない場合は、次のドキュメントを参照して、前提条件とインストール手順を確認してください。
1.7.10.6.7.1. AgentServiceConfig リソースのデプロイ
AgentServiceConfig カスタムリソースは、マルチクラスターエンジン Operator の一部である Assisted Service アドオンの重要なコンポーネントです。このコンポーネントは、ベアメタルクラスターをデプロイメントします。アドオンが有効な場合に、AgentServiceConfig リソースをデプロイしてアドオンを設定します。
AgentServiceConfig リソースの設定に加えて、マルチクラスターエンジン Operator が非接続環境で適切に機能するように、追加の config map を含める必要があります。
次の config map を追加してカスタムレジストリーを設定します。これには、デプロイメントをカスタマイズするための非接続環境の情報が含まれています。
--- apiVersion: v1 kind: ConfigMap metadata: name: custom-registries namespace: multicluster-engine labels: app: assisted-service data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- registries.conf: | unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] [[registry]] prefix = "" location = "registry.redhat.io/openshift4" mirror-by-digest-only = true [[registry.mirror]] location = "registry.dns.base.domain.name:5000/openshift4" 1 [[registry]] prefix = "" location = "registry.redhat.io/rhacm2" mirror-by-digest-only = true ... ...- 1
dns.base.domain.nameは DNS ベースドメイン名に置き換えます。
オブジェクトには、以下の 2 つのフィールドが含まれます。
- カスタム CA: このフィールドには、デプロイメントのさまざまなプロセスに読み込まれる認証局 (CA) が含まれます。
-
レジストリー:
Registries.confフィールドには、元のソースレジストリーではなくミラーレジストリーから使用する必要があるイメージと namespace に関する情報が含まれています。
次の例に示すように、
AssistedServiceConfigオブジェクトを追加して、Assisted Service を設定します。--- apiVersion: agent-install.openshift.io/v1beta1 kind: AgentServiceConfig metadata: annotations: unsupported.agent-install.openshift.io/assisted-service-configmap: assisted-service-config 1 name: agent namespace: multicluster-engine spec: mirrorRegistryRef: name: custom-registries 2 databaseStorage: storageClassName: lvms-vg1 accessModes: - ReadWriteOnce resources: requests: storage: 10Gi filesystemStorage: storageClassName: lvms-vg1 accessModes: - ReadWriteOnce resources: requests: storage: 20Gi osImages: 3 - cpuArchitecture: x86_64 openshiftVersion: "4.14" rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live-rootfs.x86_64.img 4 url: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live.x86_64.iso version: 414.92.202308281054-0- 1
metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"]アノテーションは、Operator が動作をカスタマイズするために使用する config map 名を参照します。- 2
spec.mirrorRegistryRef.nameアノテーションは、Assisted Service Operator が使用する非接続のレジストリー情報を含む config map を指します。この config map は、デプロイメントプロセス中にこれらのリソースを追加します。- 3
spec.osImagesフィールドには、この Operator がデプロイできるさまざまなバージョンが含まれています。このフィールドは必須です。この例では、RootFSファイルとLiveISOファイルがすでにダウンロードされていることを前提としています。- 4
rootFSUrl フィールドとurlフィールドで、dns.base.domain.nameを DNS ベースドメイン名に置き換えます。
すべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに適用し、これらのオブジェクトをデプロイします。起動するには、以下のコマンドを実行します。
oc apply -f agentServiceConfig.yaml
このコマンドは、次の出力例に示すように、2 つの Pod をトリガーします。
assisted-image-service-0 1/1 Running 2 11d 1 assisted-service-668b49548-9m7xw 2/2 Running 5 11d 2
1.7.10.6.8. IPv6 ネットワークの TLS 証明書を設定する
オフライン環境で Hosted Control Plane を設定するプロセスに、いくつかの TLS 証明書が関与します。認証局 (CA) を管理クラスターに追加するには、OpenShift Container Platform コントロールプレーンおよびワーカーノード内の以下のファイルの内容を変更する必要があります。
-
/etc/pki/ca-trust/extracted/pem/ -
/etc/pki/ca-trust/source/anchors -
/etc/pki/tls/certs/
CA を管理クラスターに追加するには、次の手順を実行します。
-
OpenShift Container Platform の公式ドキュメントの CA バンドルの更新 の手順を完了します。この方法には、CA を OpenShift Container Platform ノードにデプロイする
image-registry-operatorの使用が含まれます。 この方法が実際の状況に該当しない場合は、管理クラスター内の
openshift-confignamespace にuser-ca-bundleという名前の config map が含まれているかどうかを確認してください。namespace にその config map が含まれている場合は、次のコマンドを入力します。
## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE> export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${REGISTRY_CERT_PATH}namespace にその config map が含まれていない場合は、以下のコマンドを入力します。
## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE> export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt export TMP_FILE=$(mktemp) oc get cm -n openshift-config user-ca-bundle -ojsonpath='{.data.ca-bundle\.crt}' > ${TMP_FILE} echo >> ${TMP_FILE} echo \#registry.$(hostname --long) >> ${TMP_FILE} cat ${REGISTRY_CERT_PATH} >> ${TMP_FILE} oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${TMP_FILE} --dry-run=client -o yaml | kubectl apply -f -
1.7.10.6.9. IPv6 ネットワークのホステッドクラスターをデプロイする
ホステッドクラスターは、コントロールプレーンと API エンドポイントが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。
Red Hat Advanced Cluster Management のコンソールを使用してホステッドクラスターを作成できますが、次の手順ではマニフェストを使用するため、関連するアーティファクトをより柔軟に変更できます。
1.7.10.6.9.1. ホステッドクラスターオブジェクトのデプロイ
この手順では、次の値が使用されます。
-
HostedCluster name:
hosted-ipv6 -
HostedCluster namespace:
clusters -
Disconnected:
true -
Network stack:
IPv6
通常、HyperShift Operator は HostedControlPlane namespace を作成します。ただし、この場合は、HyperShift Operator が HostedCluster オブジェクトの調整を開始する前に、すべてのオブジェクトを含める必要があります。その後、Operator が調整プロセスを開始すると、所定の場所にあるすべてのオブジェクトを見つけることができます。
namespace に関する次の情報を含めて、YAML ファイルを作成します。
--- apiVersion: v1 kind: Namespace metadata: creationTimestamp: null name: clusters-hosted-ipv6 spec: {} status: {} --- apiVersion: v1 kind: Namespace metadata: creationTimestamp: null name: clusters spec: {} status: {}config map とシークレットに関する次の情報を含む YAML ファイルを作成し、
HostedClusterデプロイメントに追加します。--- apiVersion: v1 data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- kind: ConfigMap metadata: name: user-ca-bundle namespace: clusters --- apiVersion: v1 data: .dockerconfigjson: xxxxxxxxx kind: Secret metadata: creationTimestamp: null name: hosted-ipv6-pull-secret namespace: clusters --- apiVersion: v1 kind: Secret metadata: name: sshkey-cluster-hosted-ipv6 namespace: clusters stringData: id_rsa.pub: ssh-rsa xxxxxxxxx --- apiVersion: v1 data: key: nTPtVBEt03owkrKhIdmSW8jrWRxU57KO/fnZa8oaG0Y= kind: Secret metadata: creationTimestamp: null name: hosted-ipv6-etcd-encryption-key namespace: clusters type: OpaqueRBAC ロールを含む YAML ファイルを作成し、Assisted Service エージェントが Hosted Control Plane と同じ
HostedControlPlanenamespace に配置し、引き続きクラスター API で管理されるようにします。apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: capi-provider-role namespace: clusters-hosted-ipv6 rules: - apiGroups: - agent-install.openshift.io resources: - agents verbs: - '*'
HostedClusterオブジェクトに関する情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。apiVersion: hypershift.openshift.io/v1beta1 kind: HostedCluster metadata: name: hosted-ipv6 namespace: clusters annotations: hypershift.openshift.io/control-plane-operator-image: registry.ocp-edge-cluster-0.qe.lab.redhat.com:5005/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8 spec: additionalTrustBundle: name: "user-ca-bundle" olmCatalogPlacement: guest imageContentSources: 1 - source: quay.io/openshift-release-dev/ocp-v4.0-art-dev mirrors: - registry.dns.base.domain.name:5000/openshift/release - source: quay.io/openshift-release-dev/ocp-release mirrors: - registry.dns.base.domain.name:5000/openshift/release-images - mirrors: ... ... autoscaling: {} controllerAvailabilityPolicy: SingleReplica dns: baseDomain: dns.base.domain.name etcd: managed: storage: persistentVolume: size: 8Gi restoreSnapshotURL: null type: PersistentVolume managementType: Managed fips: false networking: clusterNetwork: - cidr: 10.132.0.0/14 networkType: OVNKubernetes serviceNetwork: - cidr: 172.31.0.0/16 platform: agent: agentNamespace: clusters-hosted-ipv6 type: Agent pullSecret: name: hosted-ipv6-pull-secret release: image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237 secretEncryption: aescbc: activeKey: name: hosted-ipv6-etcd-encryption-key type: aescbc services: - service: APIServer servicePublishingStrategy: nodePort: address: api.hosted-ipv6.dns.base.domain.name type: NodePort - service: OAuthServer servicePublishingStrategy: nodePort: address: api.hosted-ipv6.dns.base.domain.name type: NodePort - service: OIDC servicePublishingStrategy: nodePort: address: api.hosted-ipv6.dns.base.domain.name type: NodePort - service: Konnectivity servicePublishingStrategy: nodePort: address: api.hosted-ipv6.dns.base.domain.name type: NodePort - service: Ignition servicePublishingStrategy: nodePort: address: api.hosted-ipv6.dns.base.domain.name type: NodePort sshKey: name: sshkey-cluster-hosted-ipv6 status: controlPlaneEndpoint: host: "" port: 0dns.base.domain.nameは DNS ベースドメイン名です。- 1
imageContentSourcesセクションには、ホステッドクラスター内のユーザーワークロードのミラー参照が含まれます。
OpenShift Container Platform リリースの HyperShift Operator リリースを指すアノテーションを
HostedClusterオブジェクトに追加します。次のコマンドを入力して、イメージペイロードを取得します。
oc adm release info registry.dns.base.domain.name:5000/openshift-release-dev/ocp-release:4.14.0-rc.1-x86_64 | grep hypershift
dns.base.domain.nameは DNS ベースドメイン名です。以下の出力を参照してください。
hypershift sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
OpenShift Container Platform Images namespace を使用して、次のコマンドを入力してダイジェストを確認します。
podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
dns.base.domain.nameは DNS ベースドメイン名です。以下の出力を参照してください。
podman pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8 Trying to pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8... Getting image source signatures Copying blob d8190195889e skipped: already exists Copying blob c71d2589fba7 skipped: already exists Copying blob d4dc6e74b6ce skipped: already exists Copying blob 97da74cc6d8f skipped: already exists Copying blob b70007a560c9 done Copying config 3a62961e6e done Writing manifest to image destination Storing signatures 3a62961e6ed6edab46d5ec8429ff1f41d6bb68de51271f037c6cb8941a007fde
注:
HostedClusterオブジェクトに設定されるリリースイメージでは、タグではなくダイジェストを使用する必要があります (例:quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c47a0)。YAML ファイルで定義したすべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに対して適用して作成します。起動するには、以下のコマンドを実行します。
oc apply -f 01-4.14-hosted_cluster-nodeport.yaml
Hosted Control Plane の出力を参照してください。
NAME READY STATUS RESTARTS AGE capi-provider-5b57dbd6d5-pxlqc 1/1 Running 0 3m57s catalog-operator-9694884dd-m7zzv 2/2 Running 0 93s cluster-api-f98b9467c-9hfrq 1/1 Running 0 3m57s cluster-autoscaler-d7f95dd5-d8m5d 1/1 Running 0 93s cluster-image-registry-operator-5ff5944b4b-648ht 1/2 Running 0 93s cluster-network-operator-77b896ddc-wpkq8 1/1 Running 0 94s cluster-node-tuning-operator-84956cd484-4hfgf 1/1 Running 0 94s cluster-policy-controller-5fd8595d97-rhbwf 1/1 Running 0 95s cluster-storage-operator-54dcf584b5-xrnts 1/1 Running 0 93s cluster-version-operator-9c554b999-l22s7 1/1 Running 0 95s control-plane-operator-6fdc9c569-t7hr4 1/1 Running 0 3m57s csi-snapshot-controller-785c6dc77c-8ljmr 1/1 Running 0 77s csi-snapshot-controller-operator-7c6674bc5b-d9dtp 1/1 Running 0 93s csi-snapshot-webhook-5b8584875f-2492j 1/1 Running 0 77s dns-operator-6874b577f-9tc6b 1/1 Running 0 94s etcd-0 3/3 Running 0 3m39s hosted-cluster-config-operator-f5cf5c464-4nmbh 1/1 Running 0 93s ignition-server-6b689748fc-zdqzk 1/1 Running 0 95s ignition-server-proxy-54d4bb9b9b-6zkg7 1/1 Running 0 95s ingress-operator-6548dc758b-f9gtg 1/2 Running 0 94s konnectivity-agent-7767cdc6f5-tw782 1/1 Running 0 95s kube-apiserver-7b5799b6c8-9f5bp 4/4 Running 0 3m7s kube-controller-manager-5465bc4dd6-zpdlk 1/1 Running 0 44s kube-scheduler-5dd5f78b94-bbbck 1/1 Running 0 2m36s machine-approver-846c69f56-jxvfr 1/1 Running 0 92s oauth-openshift-79c7bf44bf-j975g 2/2 Running 0 62s olm-operator-767f9584c-4lcl2 2/2 Running 0 93s openshift-apiserver-5d469778c6-pl8tj 3/3 Running 0 2m36s openshift-controller-manager-6475fdff58-hl4f7 1/1 Running 0 95s openshift-oauth-apiserver-dbbc5cc5f-98574 2/2 Running 0 95s openshift-route-controller-manager-5f6997b48f-s9vdc 1/1 Running 0 95s packageserver-67c87d4d4f-kl7qh 2/2 Running 0 93s
ホステッドクラスターの出力を確認します。
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters hosted-ipv6 hosted-admin-kubeconfig Partial True False The hosted control plane is available
次に、NodePool オブジェクトを作成します。
1.7.10.6.9.2. ホステッドクラスターの NodePool オブジェクトの作成
NodePool は、ホステッドクラスターに関連付けられたスケーラブルなワーカーノードのセットです。NodePool マシンアーキテクチャーは特定のプール内で一貫性を保ち、コントロールプレーンのマシンアーキテクチャーから独立しています。
NodePoolオブジェクトに関する次の情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。apiVersion: hypershift.openshift.io/v1beta1 kind: NodePool metadata: creationTimestamp: null name: hosted-ipv6 namespace: clusters spec: arch: amd64 clusterName: hosted-ipv6 management: autoRepair: false 1 upgradeType: InPlace 2 nodeDrainTimeout: 0s platform: type: Agent release: image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237 3 replicas: 0 status: replicas: 0 4- 1
- ノードが削除された場合、ノードは再作成されないため、
autoRepairフィールドはfalseに設定されます。 - 2
upgradeTypeはInPlaceに設定されます。これは、アップグレード中に同じベアメタルノードが再利用されることを示します。- 3
- この
NodePoolに含まれるすべてのノードは、OpenShift Container Platform バージョン4.14.0-0.nightly-2023-08-29-102237に基づいています。dns.base.domain.nameは DNS ベースドメイン名に置き換えます。 - 4
replicasの値は0に設定されているため、必要に応じてスケールを変更できます。すべての手順が完了するまで、NodePoolレプリカを 0 に保つことが重要です。
次のコマンドを入力して、
NodePoolオブジェクトを作成します。oc apply -f 02-nodepool.yaml
出力を参照してください。
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters hosted-ipv6 hosted 0 False False 4.14.0-0.nightly-2023-08-29-102237
次に、InfraEnv リソースを作成します。
1.7.10.6.9.3. ホステッドクラスターの InfraEnv リソースの作成
InfraEnv リソースは、pullSecretRef や sshAuthorizedKey などの重要な詳細を含む Assisted Service オブジェクトです。これらの詳細は、ホステッドクラスター用にカスタマイズされた Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージを作成するために使用されます。
InfraEnvリソースに関する次の情報を含めて YAML ファイルを作成し、必要に応じて値を置き換えます。--- apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: hosted-ipv6 namespace: clusters-hosted-ipv6 spec: pullSecretRef: 1 name: pull-secret sshAuthorizedKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDk7ICaUE+/k4zTpxLk4+xFdHi4ZuDi5qjeF52afsNkw0w/glILHhwpL5gnp5WkRuL8GwJuZ1VqLC9EKrdmegn4MrmUlq7WTsP0VFOZFBfq2XRUxo1wrRdor2z0Bbh93ytR+ZsDbbLlGngXaMa0Vbt+z74FqlcajbHTZ6zBmTpBVq5RHtDPgKITdpE1fongp7+ZXQNBlkaavaqv8bnyrP4BWahLP4iO9/xJF9lQYboYwEEDzmnKLMW1VtCE6nJzEgWCufACTbxpNS7GvKtoHT/OVzw8ArEXhZXQUS1UY8zKsX2iXwmyhw5Sj6YboA8WICs4z+TrFP89LmxXY0j6536TQFyRz1iB4WWvCbH5n6W+ABV2e8ssJB1AmEy8QYNwpJQJNpSxzoKBjI73XxvPYYC/IjPFMySwZqrSZCkJYqQ023ySkaQxWZT7in4KeMu7eS2tC+Kn4deJ7KwwUycx8n6RHMeD8Qg9flTHCv3gmab8JKZJqN3hW1D378JuvmIX4V0= 2
次のコマンドを入力して、
InfraEnvリソースを作成します。oc apply -f 03-infraenv.yaml
以下の出力を参照してください。
NAMESPACE NAME ISO CREATED AT clusters-hosted-ipv6 hosted 2023-09-11T15:14:10Z
次に、ワーカーノードを作成します。
1.7.10.6.9.4. ホステッドクラスター用のワーカーノードの作成
ベアメタルプラットフォームで作業している場合、BareMetalHost の詳細が正しく設定されていることを確認するためにワーカーノードを作成することが重要です。
仮想マシンを使用している場合は、次の手順を実行して、Metal3 Operator が使用する空のワーカーノードを作成できます。これには、kcli ツールを使用します。
ワーカーノードを作成するのが初めてではない場合は、まず以前の設定を削除する必要があります。これには、次のコマンドを入力してプランを削除します。
kcli delete plan hosted-ipv6
-
プランを削除するかどうかを確認するプロンプトが表示されたら、
yと入力します。 - プランが削除されたことを示すメッセージが表示されることを確認します。
-
プランを削除するかどうかを確認するプロンプトが表示されたら、
次のコマンドを入力して仮想マシンを作成します。
kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv6 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv6\", \"mac\": \"aa:aa:aa:aa:02:11\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0211 -P name=hosted-ipv6-worker0kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv6 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv6\", \"mac\": \"aa:aa:aa:aa:02:12\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0212 -P name=hosted-ipv6-worker1kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv6 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv6\", \"mac\": \"aa:aa:aa:aa:02:13\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0213 -P name=hosted-ipv6-worker2systemctl restart ksushy
ここでは、以下のようになります。
-
start=Falseは、仮想マシン (VM) が作成時に自動的に起動しないことを意味します。 -
uefi_legacy=trueは、以前の UEFI 実装との互換性を確保するために UEFI レガシーブートを使用することを意味します。 -
plan=hosted-dualは、マシンのグループをクラスターとして識別するプラン名を示します。 -
memory=8192およびnumcpus=16は、RAM や CPU などの仮想マシンのリソースを指定するパラメーターです。 -
disks=[200,200]は、VM 内に 2 つのシンプロビジョニングディスクを作成していることを示します。 -
nets=[{"name": "dual", "mac": "aa:aa:aa:aa:02:13"}]は、接続するネットワーク名やプライマリーインターフェイスの MAC アドレスなど、ネットワークの詳細です。 -
restart ksushyは、ksushyツールを再起動して、追加した VM をツールが確実に検出できるようにします。
-
結果の出力を確認します。
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+ | Name | Status | Ip | Source | Plan | Profile | +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+ | hosted-worker0 | down | | | hosted-ipv6 | kvirt | | hosted-worker1 | down | | | hosted-ipv6 | kvirt | | hosted-worker2 | down | | | hosted-ipv6 | kvirt | +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
次に、ホステッドクラスターのベアメタルホストを作成します。
1.7.10.6.9.5. ホステッドクラスターのベアメタルホスト作成
ベアメタルホスト は、物理的な詳細と論理詳細を含む openshift-machine-api オブジェクトで、Metal3 Operator によって識別できるようになっています。これらの詳細は、agents と呼ばれる他の Assisted Service オブジェクトに関連付けられています。
重要: ベアメタルホストと移行先ノードを作成する前に、仮想マシンを作成する必要があります。
ベアメタルホストを作成するには、以下の手順を実行します。
次の情報を使用して YAML ファイルを作成します。
注記: ベアメタルホストの認証情報を保持するシークレットが 1 つ以上あるため、ワーカーノードごとに少なくとも 2 つのオブジェクトを作成する必要があります。
--- apiVersion: v1 kind: Secret metadata: name: hosted-ipv6-worker0-bmc-secret namespace: clusters-hosted-ipv6 data: password: YWRtaW4= username: YWRtaW4= type: Opaque --- apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: hosted-ipv6-worker0 namespace: clusters-hosted-ipv6 labels: infraenvs.agent-install.openshift.io: hosted-ipv6 1 annotations: inspect.metal3.io: disabled bmac.agent-install.openshift.io/hostname: hosted-ipv6-worker0 2 spec: automatedCleaningMode: disabled 3 bmc: disableCertificateVerification: true 4 address: redfish-virtualmedia://[192.168.125.1]:9000/redfish/v1/Systems/local/hosted-ipv6-worker0 5 credentialsName: hosted-ipv6-worker0-bmc-secret 6 bootMACAddress: aa:aa:aa:aa:03:11 7 online: true 8- 1
infraenvs.agent-install.openshift.ioは、Assisted Installer オブジェクトとBareMetalHostオブジェクト間のリンクとして機能します。- 2
bmac.agent-install.openshift.io/hostnameは、デプロイメント中に採用されるノード名を表します。- 3
automatedCleaningModeは、ノードが Metal3 Operator によって消去されるのを防ぎます。- 4
disableCertificateVerificationはtrueに設定され、クライアントから証明書の検証がバイパスされます。- 5
addressは、ワーカーノードのベースボード管理コントローラー (BMC) アドレスを示します。- 6
credentialsNameは、ユーザーとパスワードの認証情報が保存されるシークレットを指します。- 7
bootMACAddressは、ノードの起動元のインターフェイス MAC アドレスを示します。- 8
onlineは、BareMetalHostオブジェクトが作成された後のノードの状態を定義します。
次のコマンドを入力して、
BareMetalHostオブジェクトをデプロイします。oc apply -f 04-bmh.yaml
プロセス中に、次の出力が確認できます。
この出力は、プロセスがノードに到達しようとしていることを示しています。
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 registering true 2s clusters-hosted hosted-worker1 registering true 2s clusters-hosted hosted-worker2 registering true 2s
この出力は、ノードが起動していることを示しています。
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 provisioning true 16s clusters-hosted hosted-worker1 provisioning true 16s clusters-hosted hosted-worker2 provisioning true 16s
- この出力は、ノードが正常に起動したことを示しています。
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 provisioned true 67s clusters-hosted hosted-worker1 provisioned true 67s clusters-hosted hosted-worker2 provisioned true 67s
ノードが起動したら、次の例に示すように、namespace のエージェントに注目してください。
NAMESPACE NAME CLUSTER APPROVED ROLE STAGE clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411 true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412 true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413 true auto-assign
エージェントは、インストールに使用できるノードを表します。ホステッドクラスターにノードを割り当てるには、ノードプールをスケールアップします。
1.7.10.6.9.6. ノードプールのスケールアップ
ベアメタルホストを作成すると、そのステータスが Registering Provisioning、Provisioned に変わります。ノードは、エージェントの LiveISO と、agent という名前のデフォルトの Pod で始まります。このエージェントは、Assisted Service Operator から OpenShift Container Platform ペイロードをインストールする指示を受け取ります。
ノードプールをスケールアップするには、次のコマンドを入力します。
oc -n clusters scale nodepool hosted-ipv6 --replicas 3
スケーリングプロセスが完了すると、エージェントがホステッドクラスターに割り当てられていることがわかります。
NAMESPACE NAME CLUSTER APPROVED ROLE STAGE clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0211 hosted true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0212 hosted true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0213 hosted true auto-assign
また、ノードプールレプリカが設定されていることにも注意してください。
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters hosted hosted 3 False False 4.14.0-0.nightly-2023-08-29-102237 Minimum availability requires 3 replicas, current 0 available
- ノードがクラスターに参加するまで待ちます。プロセス中に、エージェントはステージとステータスに関する最新情報を提供します。
次に、ホステッドクラスターのデプロイメントを監視します。
1.7.10.6.10. IPv6 ネットワークのホステッドクラスターのデプロイメントを完了する
ホステッドクラスターのデプロイメントは、コントロールプレーンとデータプレーンの 2 つの観点から監視できます。
1.7.10.6.10.1. コントロールプレーンの監視
ホステッドクラスターのデプロイメント中に、次のコマンドを入力してコントロールプレーンを監視できます。
export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
watch "oc get pod -n hypershift;echo;echo;oc get pod -n clusters-hosted-ipv4;echo;echo;oc get bmh -A;echo;echo;oc get agent -A;echo;echo;oc get infraenv -A;echo;echo;oc get hostedcluster -A;echo;echo;oc get nodepool -A;echo;echo;"
これらのコマンドは、次のアーティファクトに関する情報を提供します。
- HyperShift Operator
-
HostedControlPlanePod - ベアメタルホスト
- エージェント
-
InfraEnvリソース -
HostedClusterおよびNodePoolリソース
1.7.10.6.10.2. データプレーンの監視
デプロイメントプロセス中に Operator がどのように進行しているかを監視するには、次のコマンドを入力します。
oc get secret -n clusters-hosted-ipv4 admin-kubeconfig -o jsonpath='{.data.kubeconfig}' |base64 -d > /root/hc_admin_kubeconfig.yamlexport KUBECONFIG=/root/hc_admin_kubeconfig.yaml
watch "oc get clusterversion,nodes,co"
これらのコマンドは、次のアーティファクトに関する情報を提供します。
- クラスターのバージョン
- ノード (特にノードがクラスターに参加したかどうかについて)
- クラスター Operator
1.7.10.7. デュアルスタックネットワーク上での Hosted Control Plane の設定 (テクノロジープレビュー)
デュアルスタックネットワーク設定は、現在 disconnected として指定されます。この指定の主な理由は、リモートレジストリーが IPv6 では機能しないためです。
デュアルスタックネットワーク上で Hosted Control Plane を設定するプロセスには、次の手順が含まれます。これについては、以下のセクションで詳しく説明します。
- デュアルスタックネットワーク用のハイパーバイザーの設定
- デュアルスタックネットワーク用の DNS の設定
- デュアルスタックネットワーク用のレジストリーのデプロイ
- デュアルスタックネットワークの管理クラスターの設定
- デュアルスタックネットワーク用の Web サーバーの設定
- デュアルスタックネットワークのイメージミラーリングの設定
- デュアルスタックネットワーク用の multicluster engine Operator のデプロイ
- デュアルスタックネットワークの TLS 証明書の設定
- デュアルスタックネットワーク用のホステッドクラスターのデプロイ
- デュアルスタックネットワークのデプロイメントの終了
1.7.10.7.1. デュアルスタックネットワーク用のハイパーバイザーの設定
以下の情報は、仮想マシン環境にのみ適用されます。
1.7.10.7.1.1. 仮想 OpenShift Container Platform クラスターのパッケージへのアクセスおよびデプロイ
仮想 OpenShift Container Platform 管理クラスターをデプロイするには、以下のコマンドを入力して必要なパッケージにアクセスします。
sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y
次のコマンドを入力して、Podman サービスを有効にして起動します。
systemctl enable --now podman
kcliを使用して OpenShift Container Platform 管理クラスターおよびその他の仮想コンポーネントをデプロイするには、以下のコマンドを入力してハイパーバイザーをインストールおよび設定します。sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
sudo usermod -aG qemu,libvirt $(id -un)
sudo newgrp libvirt
sudo systemctl enable --now libvirtd
sudo dnf -y copr enable karmab/kcli
sudo dnf -y install kcli
sudo kcli create pool -p /var/lib/libvirt/images default
kcli create host kvm -H 127.0.0.1 local
sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
kcli create network -c 192.168.122.0/24 default
1.7.10.7.1.2. ネットワークマネージャーディスパッチャーの有効化
ネットワークマネージャーのディスパッチャーを有効にして、仮想マシンが必要なドメイン、ルート、およびレジストリーを解決できるようにします。ネットワークマネージャーディスパッチャーを有効にするには、
/etc/NetworkManager/dispatcher.d/ディレクトリーに次の内容を含むforcednsという名前のスクリプトを作成し、環境に合わせて必要に応じて値を置き換えます。#!/bin/bash export IP="192.168.126.1" 1 export BASE_RESOLV_CONF="/run/NetworkManager/resolv.conf" if ! [[ `grep -q "$IP" /etc/resolv.conf` ]]; then export TMP_FILE=$(mktemp /etc/forcedns_resolv.conf.XXXXXX) cp $BASE_RESOLV_CONF $TMP_FILE chmod --reference=$BASE_RESOLV_CONF $TMP_FILE sed -i -e "s/dns.base.domain.name//" -e "s/search /& dns.base.domain.name /" -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE 2 mv $TMP_FILE /etc/resolv.conf fi echo "ok"
ファイルを作成したら、次のコマンドを入力してパーミッションを追加します。
chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
-
スクリプトを実行し、出力が
okを返すことを確認します。
1.7.10.7.1.3. BMC アクセスの設定
仮想マシンのベースボード管理コントローラー (BMC) をシミュレートするように
ksushyを設定します。次のコマンドを入力します。sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
kcli create sushy-service --ssl --ipv6 --port 9000
sudo systemctl daemon-reload
systemctl enable --now ksushy
次のコマンドを入力して、サービスが正しく機能しているかどうかをテストします。
systemctl status ksushy
1.7.10.7.1.4. 接続を許可するためのハイパーバイザーシステムの設定
開発環境で作業している場合は、環境内の各種仮想ネットワークを介したさまざまなタイプの接続を許可するようにハイパーバイザーシステムを設定します。
注: 実稼働環境で作業している場合は、安全な環境を維持するために、firewalld サービスの適切なルールを確立し、SELinux ポリシーを設定する必要があります。
SELinux の場合は、次のコマンドを入力します。
sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0
firewalldの場合は、次のコマンドを入力します。systemctl disable --now firewalld
libvirtdの場合は、以下のコマンドを入力します。systemctl restart libvirtd
systemctl enable --now libvirtd
次に、環境に合わせて DNS を設定します。
1.7.10.7.1.5. 関連情報
-
kcli, の詳細は、公式の kcli ドキュメント を参照してください。
1.7.10.7.2. デュアルスタックネットワーク用の DNS の設定
この手順は、仮想環境とベアメタル環境の両方で、オフライン環境とオンライン環境の両方で必須です。仮想環境とベアメタル環境の主な違いは、リソースを設定する場所にあります。仮想以外の環境では、dnsmasq のような軽量のソリューションではなく、Bind のようなソリューションを使用してください。
- デュアルスタックで IPv6 ネットワークの DNS を設定するには、デフォルトの ingress と DNS の動作 を参照してください。
- ベアメタル上のデュアルスタックネットワーク用に DNS を設定するには、ベアメタル上の DNS の設定 を参照してください。
次にレジストリーをデプロイします。
1.7.10.7.3. デュアルスタックネットワーク用のレジストリーのデプロイ
開発環境の場合は、Podman コンテナーを使用して、小規模な自己ホスト型レジストリーをデプロイします。実稼働環境では、Red Hat Quay、Nexus、Artifactory などのエンタープライズでホストされるレジストリーをデプロイします。
Podman を使用して小規模なレジストリーをデプロイするには、以下の手順を実行します。
特権ユーザーとして
${HOME}ディレクトリーにアクセスし、次のスクリプトを作成します。#!/usr/bin/env bash set -euo pipefail PRIMARY_NIC=$(ls -1 /sys/class/net | grep -v podman | head -1) export PATH=/root/bin:$PATH export PULL_SECRET="/root/baremetal/hub/openshift_pull.json" 1 if [[ ! -f $PULL_SECRET ]];then echo "Pull Secret not found, exiting..." exit 1 fi dnf -y install podman httpd httpd-tools jq skopeo libseccomp-devel export IP=$(ip -o addr show $PRIMARY_NIC | head -1 | awk '{print $4}' | cut -d'/' -f1) REGISTRY_NAME=registry.$(hostname --long) REGISTRY_USER=dummy REGISTRY_PASSWORD=dummy KEY=$(echo -n $REGISTRY_USER:$REGISTRY_PASSWORD | base64) echo "{\"auths\": {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\", \"email\": \"sample-email@domain.ltd\"}}}" > /root/disconnected_pull.json mv ${PULL_SECRET} /root/openshift_pull.json.old jq ".auths += {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\",\"email\": \"sample-email@domain.ltd\"}}" < /root/openshift_pull.json.old > $PULL_SECRET mkdir -p /opt/registry/{auth,certs,data,conf} cat <<EOF > /opt/registry/conf/config.yml version: 0.1 log: fields: service: registry storage: cache: blobdescriptor: inmemory filesystem: rootdirectory: /var/lib/registry delete: enabled: true http: addr: :5000 headers: X-Content-Type-Options: [nosniff] health: storagedriver: enabled: true interval: 10s threshold: 3 compatibility: schema1: enabled: true EOF openssl req -newkey rsa:4096 -nodes -sha256 -keyout /opt/registry/certs/domain.key -x509 -days 3650 -out /opt/registry/certs/domain.crt -subj "/C=US/ST=Madrid/L=San Bernardo/O=Karmalabs/OU=Guitar/CN=$REGISTRY_NAME" -addext "subjectAltName=DNS:$REGISTRY_NAME" cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/ update-ca-trust extract htpasswd -bBc /opt/registry/auth/htpasswd $REGISTRY_USER $REGISTRY_PASSWORD podman create --name registry --net host --security-opt label=disable --replace -v /opt/registry/data:/var/lib/registry:z -v /opt/registry/auth:/auth:z -v /opt/registry/conf/config.yml:/etc/docker/registry/config.yml -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v /opt/registry/certs:/certs:z -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key docker.io/library/registry:latest [ "$?" == "0" ] || !! systemctl enable --now registry- 1
PULL_SECRETの場所は、設定に適した場所に置き換えます。
スクリプトファイル
registry.shという名前を指定して保存します。スクリプトを実行すると、以下の情報がプルされます。- ハイパーバイザーのホスト名に基づくレジストリー名
- 必要な認証情報およびユーザーアクセスの詳細
次のように実行フラグを追加して、パーミッションを調整します。
chmod u+x ${HOME}/registry.shパラメーターを指定せずにスクリプトを実行するには、以下のコマンドを入力します。
${HOME}/registry.shこのスクリプトはサーバーを起動します。
このスクリプトは、管理目的で
systemdサービスを使用します。スクリプトを管理する必要がある場合は、以下のコマンドを使用できます。systemctl status
systemctl start
systemctl stop
レジストリーのルートフォルダーは /opt/registry ディレクトリー内にあり、次のサブディレクトリーが含まれています。
-
certsには TLS 証明書が含まれます。 -
authには認証情報が含まれます。 -
dataにはレジストリーイメージが含まれます。 -
confにはレジストリー設定が含まれています。
1.7.10.7.4. デュアルスタックネットワークの管理クラスターの設定
OpenShift Container Platform 管理クラスターを設定するには、dev-scripts を使用できます。または、仮想マシンをベースにしている場合は、kcli ツールを使用できます。以下は、kcli ツールに固有のものです。
ハイパーバイザーで使用するために適切なネットワークの準備が完了していることを確認します。ネットワークは、管理クラスターとホステッドクラスターの両方をホストします。以下の
kcliコマンドを入力します。kcli create network -c 192.168.126.0/24 -P dhcp=false -P dns=false -d 2620:52:0:1306::0/64 --domain dns.base.domain.name --nodhcp dual
ここでは、以下のようになります。
-
-cは、ネットワークの CIDR を指定します。 -
-p dhcp=falseは、設定したdnsmasqによって処理される DHCP を無効にするようにネットワークを設定します。 -
-P dns=false は、DNS を無効にするようにネットワークを設定します。これも、設定したdnsmasqによって処理されます。 -
--domainは、検索するドメインを設定します。 -
dns.base.domain.nameは DNS ベースドメイン名です。 -
dualは、作成するネットワークの名前です。
-
ネットワークを作成したら、以下の出力を確認します。
[root@hypershiftbm ~]# kcli list network Listing Networks... +---------+--------+---------------------+-------+------------------+------+ | Network | Type | Cidr | Dhcp | Domain | Mode | +---------+--------+---------------------+-------+------------------+------+ | default | routed | 192.168.122.0/24 | True | default | nat | | ipv4 | routed | 2620:52:0:1306::/64 | False | dns.base.domain.name | nat | | ipv4 | routed | 192.168.125.0/24 | False | dns.base.domain.name | nat | | ipv6 | routed | 2620:52:0:1305::/64 | False | dns.base.domain.name | nat | +---------+--------+---------------------+-------+------------------+------+
[root@hypershiftbm ~]# kcli info network ipv6 Providing information about network ipv6... cidr: 2620:52:0:1306::/64 dhcp: false domain: dns.base.domain.name mode: nat plan: kvirt type: routed
OpenShift Container Platform 管理クラスターをデプロイできるように、プルシークレットと
kcliプランファイルが配置されていることを確認します。-
プルシークレットが
kcliプランと同じフォルダーにあり、プルシークレットファイルの名前がopenshift_pull.jsonであることを確認します。 -
OpenShift Container Platform 定義を含む
kcliプランをmgmt-compact-hub-dual.yamlファイルに追加します。ご使用の環境に合わせてファイルの内容を更新してください。
plan: hub-dual force: true version: nightly tag: "4.14.0-0.nightly-2023-08-29-102237" cluster: "hub-dual" dualstack: true domain: dns.base.domain.name api_ip: 192.168.126.10 ingress_ip: 192.168.126.11 service_networks: - 172.30.0.0/16 - fd02::/112 cluster_networks: - 10.132.0.0/14 - fd01::/48 disconnected_url: registry.dns.base.domain.name:5000 disconnected_update: true disconnected_user: dummy disconnected_password: dummy disconnected_operators_version: v4.14 disconnected_operators: - name: metallb-operator - name: lvms-operator channels: - name: stable-4.13 disconnected_extra_images: - quay.io/user-name/trbsht:latest - quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3 - registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10 dualstack: true disk_size: 200 extra_disks: [200] memory: 48000 numcpus: 16 ctlplanes: 3 workers: 0 manifests: extra-manifests metal3: true network: dual users_dev: developer users_devpassword: developer users_admin: admin users_adminpassword: admin metallb_pool: dual-virtual-network metallb_ranges: - 192.168.126.150-192.168.126.190 metallb_autoassign: true apps: - users - lvms-operator - metallb-operator vmrules: - hub-bootstrap: nets: - name: ipv6 mac: aa:aa:aa:aa:10:07 - hub-ctlplane-0: nets: - name: ipv6 mac: aa:aa:aa:aa:10:01 - hub-ctlplane-1: nets: - name: ipv6 mac: aa:aa:aa:aa:10:02 - hub-ctlplane-2: nets: - name: ipv6 mac: aa:aa:aa:aa:10:03-
プルシークレットが
管理クラスターをプロビジョニングするには、以下のコマンドを入力します。
kcli create cluster openshift --pf mgmt-compact-hub-dual.yaml
次に、Web サーバーを設定します。
1.7.10.7.4.1. 関連情報
-
kcliプランファイルのパラメーターの詳細は、kcli公式ドキュメントの parameters.yml の作成 を参照してください。
1.7.10.7.5. デュアルスタックネットワーク用の Web サーバーの設定
ホステッドクラスターとしてデプロイする OpenShift Container Platform リリースに関連付けられた Red Hat Enterprise Linux CoreOS (RHCOS) イメージをホストするには、追加の Web サーバーを設定する必要があります。
Web サーバーを設定するには、以下の手順を実行します。
以下のコマンドを入力して、使用する OpenShift Container Platform リリースから
openshift-installバイナリーを展開します。oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"次のスクリプトを実行します。このスクリプトは、
/opt/srvディレクトリーにフォルダーを作成します。このフォルダーには、ワーカーノードをプロビジョニングするための RHCOS イメージが含まれています。#!/bin/bash WEBSRV_FOLDER=/opt/srv ROOTFS_IMG_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.pxe.rootfs.location')" 1 LIVE_ISO_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location')" 2 mkdir -p ${WEBSRV_FOLDER}/images curl -Lk ${ROOTFS_IMG_URL} -o ${WEBSRV_FOLDER}/images/${ROOTFS_IMG_URL##*/} curl -Lk ${LIVE_ISO_URL} -o ${WEBSRV_FOLDER}/images/${LIVE_ISO_URL##*/} chmod -R 755 ${WEBSRV_FOLDER}/* ## Run Webserver podman ps --noheading | grep -q websrv-ai if [[ $? == 0 ]];then echo "Launching Registry pod..." /usr/bin/podman run --name websrv-ai --net host -v /opt/srv:/usr/local/apache2/htdocs:z quay.io/alosadag/httpd:p8080 fi
ダウンロードが完了すると、コンテナーが実行され、Web サーバー上でイメージをホストします。このコンテナーは公式 HTTPd イメージのバリエーションを使用しているので、IPv6 ネットワークでの動作も可能になります。
1.7.10.7.6. デュアルスタックネットワークのイメージミラーリングの設定
イメージミラーリングは、registry.redhat.com や quay.io などの外部レジストリーからイメージを取得し、プライベートレジストリーに保存するプロセスです。
1.7.10.7.6.1. ミラーリングプロセスの完了
注: ミラーリングプロセスは、レジストリーサーバーの実行後に開始してください。
次の手順では、ImageSetConfiguration オブジェクトを使用するバイナリーである、oc-mirror ツールが使用されます。このファイルで、以下の情報を指定できます。
-
ミラーリングする OpenShift Container Platform バージョン。バージョンは
quay.ioにあります。 - ミラーリングする追加の Operator。パッケージは個別に選択します。
- リポジトリーに追加する追加のイメージ。
イメージのミラーリングを設定するには、以下の手順を実行します。
-
${HOME}/.docker/config.jsonファイルが、ミラーリング元のレジストリーとイメージのプッシュ先のプライベートレジストリーで更新されていることを確認します。 次の例を使用して、ミラーリングに使用する
ImageSetConfigurationオブジェクトを作成します。環境に合わせて必要に応じて値を置き換えます。apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: registry: imageURL: registry.dns.base.domain.name:5000/openshift/release/metadata:latest mirror: platform: channels: - name: candidate-4.14 minVersion: 4.14.0-ec.1 maxVersion: 4.14.0-ec.3 type: ocp graph: true additionalImages: - name: quay.io/karmab/origin-keepalived-ipfailover:latest - name: quay.io/karmab/kubectl:latest - name: quay.io/karmab/haproxy:latest - name: quay.io/karmab/mdns-publisher:latest - name: quay.io/karmab/origin-coredns:latest - name: quay.io/karmab/curl:latest - name: quay.io/karmab/kcli:latest - name: quay.io/user-name/trbsht:latest - name: quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3 - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14 packages: - name: lvms-operator - name: local-storage-operator - name: odf-csi-addons-operator - name: odf-operator - name: mcg-operator - name: ocs-operator - name: metallb-operator次のコマンドを入力して、ミラーリングプロセスを開始します。
oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}ミラーリングプロセスが完了すると、
oc-mirror-workspace/results-XXXXXX/という名前の新しいフォルダーが作成されます。このフォルダーには、ICSP と、ホステッドクラスターに適用するカタログソースが含まれます。oc adm release mirrorコマンドを使用して、OpenShift Container Platform のナイトリーバージョンまたは CI バージョンをミラーリングします。以下のコマンドを入力します。REGISTRY=registry.$(hostname --long):5000 oc adm release mirror \ --from=registry.ci.openshift.org/ocp/release:4.14.0-0.nightly-2023-08-29-102237 \ --to=${REGISTRY}/openshift/release \ --to-release-image=${REGISTRY}/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237- 非接続ネットワークへのインストール の手順に従って、最新の multicluster engine Operator イメージをミラーリングします。
1.7.10.7.6.2. 管理クラスターでのオブジェクトの適用
ミラーリングプロセスが完了したら、管理クラスターに 2 つのオブジェクトを適用する必要があります。
- イメージコンテンツソースポリシー (ICSP) またはイメージダイジェストミラーセット (IDMS)
- カタログソース
oc-mirror ツールを使用すると、出力アーティファクトは oc-mirror-workspace/results-XXXXXX/ という名前のフォルダーに保存されます。
ICSP または IDMS は、ノードを再起動せずに、各ノードで kubelet を再起動する MachineConfig 変更を開始します。ノードが READY としてマークされたら、新しく生成されたカタログソースを適用する必要があります。
カタログソースは、カタログイメージのダウンロードや処理を行い、そのイメージに含まれるすべての PackageManifests を取得するなど、openshift-marketplace Operator でアクションを開始します。
新しいソースを確認するには、新しい
CatalogSourceをソースとして使用して次のコマンドを実行します。oc get packagemanifest
アーティファクトを適用するには、次の手順を実行します。
次のコマンドを入力して、ICSP または IDMS アーティファクトを作成します。
oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
- ノードの準備が完了するまで待ってから、次のコマンドを入力します。
oc apply -f catalogSource-XXXXXXXX-index.yaml
次に、マルチクラスターエンジン Operator をデプロイします。
1.7.10.7.6.3. 関連情報
- 仮想環境で作業している場合は、ミラーリングを設定した後、OpenShift Virtualization 上の Hosted Control Plane の前提条件 を満たしていることを確認してください。
- OpenShift Container Platform のナイトリーバージョンまたは CI バージョンのミラーリングの詳細は、oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング を参照してください。
1.7.10.7.7. デュアルスタックネットワーク用のマルチクラスターエンジン Operator のデプロイ
マルチクラスターエンジン Operator は、プロバイダー間でクラスターをデプロイメントする場合に重要な役割を果たします。Red Hat Advanced Cluster Management をすでにインストールしている場合は、マルチクラスターエンジン Operator は自動的にインストールされるため、インストールする必要はありません。
マルチクラスターエンジン Operator がインストールされていない場合は、次のドキュメントを参照して、前提条件とインストール手順を確認してください。
1.7.10.7.7.1. AgentServiceConfig リソースのデプロイ
AgentServiceConfig カスタムリソースは、マルチクラスターエンジン Operator の一部である Assisted Service アドオンの重要なコンポーネントです。このコンポーネントは、ベアメタルクラスターをデプロイメントします。アドオンが有効な場合に、AgentServiceConfig リソースをデプロイしてアドオンを設定します。
AgentServiceConfig リソースの設定に加えて、マルチクラスターエンジン Operator が非接続環境で適切に機能するように、追加の config map を含める必要があります。
次の config map を追加してカスタムレジストリーを設定します。これには、デプロイメントをカスタマイズするための非接続環境の情報が含まれています。
--- apiVersion: v1 kind: ConfigMap metadata: name: custom-registries namespace: multicluster-engine labels: app: assisted-service data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- registries.conf: | unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] [[registry]] prefix = "" location = "registry.redhat.io/openshift4" mirror-by-digest-only = true [[registry.mirror]] location = "registry.dns.base.domain.name:5000/openshift4" 1 [[registry]] prefix = "" location = "registry.redhat.io/rhacm2" mirror-by-digest-only = true ... ...- 1
dns.base.domain.nameは DNS ベースドメイン名に置き換えます。
オブジェクトには、以下の 2 つのフィールドが含まれます。
- カスタム CA: このフィールドには、デプロイメントのさまざまなプロセスに読み込まれる認証局 (CA) が含まれます。
-
レジストリー:
Registries.confフィールドには、元のソースレジストリーではなくミラーレジストリーから使用する必要があるイメージと namespace に関する情報が含まれています。
次の例に示すように、
AssistedServiceConfigオブジェクトを追加して、Assisted Service を設定します。--- apiVersion: agent-install.openshift.io/v1beta1 kind: AgentServiceConfig metadata: annotations: unsupported.agent-install.openshift.io/assisted-service-configmap: assisted-service-config 1 name: agent namespace: multicluster-engine spec: mirrorRegistryRef: name: custom-registries 2 databaseStorage: storageClassName: lvms-vg1 accessModes: - ReadWriteOnce resources: requests: storage: 10Gi filesystemStorage: storageClassName: lvms-vg1 accessModes: - ReadWriteOnce resources: requests: storage: 20Gi osImages: 3 - cpuArchitecture: x86_64 openshiftVersion: "4.14" rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live-rootfs.x86_64.img 4 url: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live.x86_64.iso version: 414.92.202308281054-0- 1
metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"]アノテーションは、Operator が動作をカスタマイズするために使用する config map 名を参照します。- 2
spec.mirrorRegistryRef.nameアノテーションは、Assisted Service Operator が使用する非接続のレジストリー情報を含む config map を指します。この config map は、デプロイメントプロセス中にこれらのリソースを追加します。- 3
spec.osImagesフィールドには、この Operator がデプロイできるさまざまなバージョンが含まれています。このフィールドは必須です。この例では、RootFSファイルとLiveISOファイルがすでにダウンロードされていることを前提としています。- 4
rootFSUrl フィールドとurlフィールドで、dns.base.domain.nameを DNS ベースドメイン名に置き換えます。
すべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに適用し、これらのオブジェクトをデプロイします。起動するには、以下のコマンドを実行します。
oc apply -f agentServiceConfig.yaml
このコマンドは、次の出力例に示すように、2 つの Pod をトリガーします。
assisted-image-service-0 1/1 Running 2 11d 1 assisted-service-668b49548-9m7xw 2/2 Running 5 11d 2
1.7.10.7.8. デュアルスタックネットワークの TLS 証明書の設定
オフライン環境で Hosted Control Plane を設定するプロセスに、いくつかの TLS 証明書が関与します。認証局 (CA) を管理クラスターに追加するには、OpenShift Container Platform コントロールプレーンおよびワーカーノード内の以下のファイルの内容を変更する必要があります。
-
/etc/pki/ca-trust/extracted/pem/ -
/etc/pki/ca-trust/source/anchors -
/etc/pki/tls/certs/
CA を管理クラスターに追加するには、次の手順を実行します。
-
OpenShift Container Platform の公式ドキュメントの CA バンドルの更新 の手順を完了します。この方法には、CA を OpenShift Container Platform ノードにデプロイする
image-registry-operatorの使用が含まれます。 この方法が実際の状況に該当しない場合は、管理クラスター内の
openshift-confignamespace にuser-ca-bundleという名前の config map が含まれているかどうかを確認してください。namespace にその config map が含まれている場合は、次のコマンドを入力します。
## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE> export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${REGISTRY_CERT_PATH}namespace にその config map が含まれていない場合は、以下のコマンドを入力します。
## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE> export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt export TMP_FILE=$(mktemp) oc get cm -n openshift-config user-ca-bundle -ojsonpath='{.data.ca-bundle\.crt}' > ${TMP_FILE} echo >> ${TMP_FILE} echo \#registry.$(hostname --long) >> ${TMP_FILE} cat ${REGISTRY_CERT_PATH} >> ${TMP_FILE} oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${TMP_FILE} --dry-run=client -o yaml | kubectl apply -f -
1.7.10.7.9. デュアルスタックネットワーク用のホステッドクラスターのデプロイ
ホステッドクラスターは、コントロールプレーンと API エンドポイントが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。
Red Hat Advanced Cluster Management のコンソールを使用してホステッドクラスターを作成できますが、次の手順ではマニフェストを使用するため、関連するアーティファクトをより柔軟に変更できます。
1.7.10.7.9.1. ホステッドクラスターオブジェクトのデプロイ
この手順では、次の値が使用されます。
-
HostedCluster name:
hosted-dual -
HostedCluster namespace:
clusters -
Disconnected:
true -
Network stack:
Dual
通常、HyperShift Operator は HostedControlPlane namespace を作成します。ただし、この場合は、HyperShift Operator が HostedCluster オブジェクトの調整を開始する前に、すべてのオブジェクトを含める必要があります。その後、Operator が調整プロセスを開始すると、所定の場所にあるすべてのオブジェクトを見つけることができます。
namespace に関する次の情報を含めて、YAML ファイルを作成します。
--- apiVersion: v1 kind: Namespace metadata: creationTimestamp: null name: clusters-hosted-dual spec: {} status: {} --- apiVersion: v1 kind: Namespace metadata: creationTimestamp: null name: clusters spec: {} status: {}config map とシークレットに関する次の情報を含む YAML ファイルを作成し、
HostedClusterデプロイメントに追加します。--- apiVersion: v1 data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- kind: ConfigMap metadata: name: user-ca-bundle namespace: clusters --- apiVersion: v1 data: .dockerconfigjson: xxxxxxxxx kind: Secret metadata: creationTimestamp: null name: hosted-dual-pull-secret namespace: clusters --- apiVersion: v1 kind: Secret metadata: name: sshkey-cluster-hosted-dual namespace: clusters stringData: id_rsa.pub: ssh-rsa xxxxxxxxx --- apiVersion: v1 data: key: nTPtVBEt03owkrKhIdmSW8jrWRxU57KO/fnZa8oaG0Y= kind: Secret metadata: creationTimestamp: null name: hosted-dual-etcd-encryption-key namespace: clusters type: OpaqueRBAC ロールを含む YAML ファイルを作成し、Assisted Service エージェントが Hosted Control Plane と同じ
HostedControlPlanenamespace に配置し、引き続きクラスター API で管理されるようにします。apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: capi-provider-role namespace: clusters-hosted-dual rules: - apiGroups: - agent-install.openshift.io resources: - agents verbs: - '*'
HostedClusterオブジェクトに関する情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。apiVersion: hypershift.openshift.io/v1beta1 kind: HostedCluster metadata: name: hosted-dual namespace: clusters spec: additionalTrustBundle: name: "user-ca-bundle" olmCatalogPlacement: guest imageContentSources: 1 - source: quay.io/openshift-release-dev/ocp-v4.0-art-dev mirrors: - registry.dns.base.domain.name:5000/openshift/release 2 - source: quay.io/openshift-release-dev/ocp-release mirrors: - registry.dns.base.domain.name:5000/openshift/release-images - mirrors: ... ... autoscaling: {} controllerAvailabilityPolicy: SingleReplica dns: baseDomain: dns.base.domain.name etcd: managed: storage: persistentVolume: size: 8Gi restoreSnapshotURL: null type: PersistentVolume managementType: Managed fips: false networking: clusterNetwork: - cidr: 10.132.0.0/14 - cidr: fd01::/48 networkType: OVNKubernetes serviceNetwork: - cidr: 172.31.0.0/16 - cidr: fd02::/112 platform: agent: agentNamespace: clusters-hosted-dual type: Agent pullSecret: name: hosted-dual-pull-secret release: image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237 secretEncryption: aescbc: activeKey: name: hosted-dual-etcd-encryption-key type: aescbc services: - service: APIServer servicePublishingStrategy: nodePort: address: api.hosted-dual.dns.base.domain.name type: NodePort - service: OAuthServer servicePublishingStrategy: nodePort: address: api.hosted-dual.dns.base.domain.name type: NodePort - service: OIDC servicePublishingStrategy: nodePort: address: api.hosted-dual.dns.base.domain.name type: NodePort - service: Konnectivity servicePublishingStrategy: nodePort: address: api.hosted-dual.dns.base.domain.name type: NodePort - service: Ignition servicePublishingStrategy: nodePort: address: api.hosted-dual.dns.base.domain.name type: NodePort sshKey: name: sshkey-cluster-hosted-dual status: controlPlaneEndpoint: host: "" port: 0OpenShift Container Platform リリースの HyperShift Operator リリースを指すアノテーションを
HostedClusterオブジェクトに追加します。次のコマンドを入力して、イメージペイロードを取得します。
oc adm release info registry.dns.base.domain.name:5000/openshift-release-dev/ocp-release:4.14.0-rc.1-x86_64 | grep hypershift
dns.base.domain.nameは DNS ベースドメイン名です。以下の出力を参照してください。
hypershift sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
OpenShift Container Platform Images namespace を使用して、次のコマンドを入力してダイジェストを確認します。
podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
dns.base.domain.nameは DNS ベースドメイン名です。以下の出力を参照してください。
podman pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8 Trying to pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8... Getting image source signatures Copying blob d8190195889e skipped: already exists Copying blob c71d2589fba7 skipped: already exists Copying blob d4dc6e74b6ce skipped: already exists Copying blob 97da74cc6d8f skipped: already exists Copying blob b70007a560c9 done Copying config 3a62961e6e done Writing manifest to image destination Storing signatures 3a62961e6ed6edab46d5ec8429ff1f41d6bb68de51271f037c6cb8941a007fde
注:
HostedClusterオブジェクトに設定されるリリースイメージでは、タグではなくダイジェストを使用する必要があります (例:quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c47a0)。YAML ファイルで定義したすべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに対して適用して作成します。起動するには、以下のコマンドを実行します。
oc apply -f 01-4.14-hosted_cluster-nodeport.yaml
Hosted Control Plane の出力を参照してください。
NAME READY STATUS RESTARTS AGE capi-provider-5b57dbd6d5-pxlqc 1/1 Running 0 3m57s catalog-operator-9694884dd-m7zzv 2/2 Running 0 93s cluster-api-f98b9467c-9hfrq 1/1 Running 0 3m57s cluster-autoscaler-d7f95dd5-d8m5d 1/1 Running 0 93s cluster-image-registry-operator-5ff5944b4b-648ht 1/2 Running 0 93s cluster-network-operator-77b896ddc-wpkq8 1/1 Running 0 94s cluster-node-tuning-operator-84956cd484-4hfgf 1/1 Running 0 94s cluster-policy-controller-5fd8595d97-rhbwf 1/1 Running 0 95s cluster-storage-operator-54dcf584b5-xrnts 1/1 Running 0 93s cluster-version-operator-9c554b999-l22s7 1/1 Running 0 95s control-plane-operator-6fdc9c569-t7hr4 1/1 Running 0 3m57s csi-snapshot-controller-785c6dc77c-8ljmr 1/1 Running 0 77s csi-snapshot-controller-operator-7c6674bc5b-d9dtp 1/1 Running 0 93s csi-snapshot-webhook-5b8584875f-2492j 1/1 Running 0 77s dns-operator-6874b577f-9tc6b 1/1 Running 0 94s etcd-0 3/3 Running 0 3m39s hosted-cluster-config-operator-f5cf5c464-4nmbh 1/1 Running 0 93s ignition-server-6b689748fc-zdqzk 1/1 Running 0 95s ignition-server-proxy-54d4bb9b9b-6zkg7 1/1 Running 0 95s ingress-operator-6548dc758b-f9gtg 1/2 Running 0 94s konnectivity-agent-7767cdc6f5-tw782 1/1 Running 0 95s kube-apiserver-7b5799b6c8-9f5bp 4/4 Running 0 3m7s kube-controller-manager-5465bc4dd6-zpdlk 1/1 Running 0 44s kube-scheduler-5dd5f78b94-bbbck 1/1 Running 0 2m36s machine-approver-846c69f56-jxvfr 1/1 Running 0 92s oauth-openshift-79c7bf44bf-j975g 2/2 Running 0 62s olm-operator-767f9584c-4lcl2 2/2 Running 0 93s openshift-apiserver-5d469778c6-pl8tj 3/3 Running 0 2m36s openshift-controller-manager-6475fdff58-hl4f7 1/1 Running 0 95s openshift-oauth-apiserver-dbbc5cc5f-98574 2/2 Running 0 95s openshift-route-controller-manager-5f6997b48f-s9vdc 1/1 Running 0 95s packageserver-67c87d4d4f-kl7qh 2/2 Running 0 93s
ホステッドクラスターの出力を確認します。
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters hosted-dual hosted-admin-kubeconfig Partial True False The hosted control plane is available
次に、NodePool オブジェクトを作成します。
1.7.10.7.9.2. ホステッドクラスターの NodePool オブジェクトの作成
NodePool は、ホステッドクラスターに関連付けられたスケーラブルなワーカーノードのセットです。NodePool マシンアーキテクチャーは特定のプール内で一貫性を保ち、コントロールプレーンのマシンアーキテクチャーから独立しています。
NodePoolオブジェクトに関する次の情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。apiVersion: hypershift.openshift.io/v1beta1 kind: NodePool metadata: creationTimestamp: null name: hosted-dual namespace: clusters spec: arch: amd64 clusterName: hosted-dual management: autoRepair: false 1 upgradeType: InPlace 2 nodeDrainTimeout: 0s platform: type: Agent release: image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237 3 replicas: 0 status: replicas: 0 4- 1
- ノードが削除された場合、ノードは再作成されないため、
autoRepairフィールドはfalseに設定されます。 - 2
upgradeTypeはInPlaceに設定されます。これは、アップグレード中に同じベアメタルノードが再利用されることを示します。- 3
- この
NodePoolに含まれるすべてのノードは、OpenShift Container Platform バージョン4.14.0-0.nightly-2023-08-29-102237に基づいています。dns.base.domain.nameの値は、実際の DNS ベースドメイン名に置き換えます。 - 4
replicasの値は0に設定されているため、必要に応じてスケールを変更できます。すべての手順が完了するまで、NodePoolレプリカを 0 に保つことが重要です。
次のコマンドを入力して、
NodePoolオブジェクトを作成します。oc apply -f 02-nodepool.yaml
出力を参照してください。
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters hosted-dual hosted 0 False False 4.14.0-0.nightly-2023-08-29-102237
次に、InfraEnv リソースを作成します。
1.7.10.7.9.3. ホステッドクラスターの InfraEnv リソースの作成
InfraEnv リソースは、pullSecretRef や sshAuthorizedKey などの重要な詳細を含む Assisted Service オブジェクトです。これらの詳細は、ホステッドクラスター用にカスタマイズされた Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージを作成するために使用されます。
InfraEnvリソースに関する次の情報を含めて YAML ファイルを作成し、必要に応じて値を置き換えます。--- apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: hosted-dual namespace: clusters-hosted-dual spec: pullSecretRef: 1 name: pull-secret sshAuthorizedKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDk7ICaUE+/k4zTpxLk4+xFdHi4ZuDi5qjeF52afsNkw0w/glILHhwpL5gnp5WkRuL8GwJuZ1VqLC9EKrdmegn4MrmUlq7WTsP0VFOZFBfq2XRUxo1wrRdor2z0Bbh93ytR+ZsDbbLlGngXaMa0Vbt+z74FqlcajbHTZ6zBmTpBVq5RHtDPgKITdpE1fongp7+ZXQNBlkaavaqv8bnyrP4BWahLP4iO9/xJF9lQYboYwEEDzmnKLMW1VtCE6nJzEgWCufACTbxpNS7GvKtoHT/OVzw8ArEXhZXQUS1UY8zKsX2iXwmyhw5Sj6YboA8WICs4z+TrFP89LmxXY0j6536TQFyRz1iB4WWvCbH5n6W+ABV2e8ssJB1AmEy8QYNwpJQJNpSxzoKBjI73XxvPYYC/IjPFMySwZqrSZCkJYqQ023ySkaQxWZT7in4KeMu7eS2tC+Kn4deJ7KwwUycx8n6RHMeD8Qg9flTHCv3gmab8JKZJqN3hW1D378JuvmIX4V0= 2
次のコマンドを入力して、
InfraEnvリソースを作成します。oc apply -f 03-infraenv.yaml
以下の出力を参照してください。
NAMESPACE NAME ISO CREATED AT clusters-hosted-dual hosted 2023-09-11T15:14:10Z
次に、ワーカーノードを作成します。
1.7.10.7.9.4. ホステッドクラスター用のワーカーノードの作成
ベアメタルプラットフォームで作業している場合、BareMetalHost の詳細が正しく設定されていることを確認するためにワーカーノードを作成することが重要です。
仮想マシンを使用している場合は、次の手順を実行して、Metal3 Operator が使用する空のワーカーノードを作成できます。これには、kcli ツールを使用します。
ワーカーノードを作成するのが初めてではない場合は、まず以前の設定を削除する必要があります。これには、次のコマンドを入力してプランを削除します。
kcli delete plan hosted-dual
-
プランを削除するかどうかを確認するプロンプトが表示されたら、
yと入力します。 - プランが削除されたことを示すメッセージが表示されることを確認します。
-
プランを削除するかどうかを確認するプロンプトが表示されたら、
次のコマンドを入力して仮想マシンを作成します。
kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-dual -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"dual\", \"mac\": \"aa:aa:aa:aa:11:01\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1101 -P name=hosted-dual-worker0kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-dual -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"dual\", \"mac\": \"aa:aa:aa:aa:11:02\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1102 -P name=hosted-dual-worker1kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-dual -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"dual\", \"mac\": \"aa:aa:aa:aa:11:03\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1103 -P name=hosted-dual-worker2systemctl restart ksushy
ここでは、以下のようになります。
-
start=Falseは、仮想マシン (VM) が作成時に自動的に起動しないことを意味します。 -
uefi_legacy=trueは、以前の UEFI 実装との互換性を確保するために UEFI レガシーブートを使用することを意味します。 -
plan=hosted-dualは、マシンのグループをクラスターとして識別するプラン名を示します。 -
memory=8192およびnumcpus=16は、RAM や CPU などの仮想マシンのリソースを指定するパラメーターです。 -
disks=[200,200]は、VM 内に 2 つのシンプロビジョニングディスクを作成していることを示します。 -
nets=[{"name": "dual", "mac": "aa:aa:aa:aa:02:13"}]は、接続するネットワーク名やプライマリーインターフェイスの MAC アドレスなど、ネットワークの詳細です。 -
restart ksushyは、ksushyツールを再起動して、追加した VM をツールが確実に検出できるようにします。
-
結果の出力を確認します。
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+ | Name | Status | Ip | Source | Plan | Profile | +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+ | hosted-worker0 | down | | | hosted-dual | kvirt | | hosted-worker1 | down | | | hosted-dual | kvirt | | hosted-worker2 | down | | | hosted-dual | kvirt | +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
次に、ホステッドクラスターのベアメタルホストを作成します。
1.7.10.7.9.5. ホステッドクラスターのベアメタルホスト作成
ベアメタルホスト は、物理的な詳細と論理詳細を含む openshift-machine-api オブジェクトで、Metal3 Operator によって識別できるようになっています。これらの詳細は、agents と呼ばれる他の Assisted Service オブジェクトに関連付けられています。
重要: ベアメタルホストと移行先ノードを作成する前に、仮想マシンを作成する必要があります。
ベアメタルホストを作成するには、以下の手順を実行します。
次の情報を使用して YAML ファイルを作成します。
注記: ベアメタルホストの認証情報を保持するシークレットが 1 つ以上あるため、ワーカーノードごとに少なくとも 2 つのオブジェクトを作成する必要があります。
--- apiVersion: v1 kind: Secret metadata: name: hosted-dual-worker0-bmc-secret namespace: clusters-hosted-dual data: password: YWRtaW4= username: YWRtaW4= type: Opaque --- apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: hosted-dual-worker0 namespace: clusters-hosted-dual labels: infraenvs.agent-install.openshift.io: hosted-dual 1 annotations: inspect.metal3.io: disabled bmac.agent-install.openshift.io/hostname: hosted-dual-worker0 2 spec: automatedCleaningMode: disabled 3 bmc: disableCertificateVerification: true 4 address: redfish-virtualmedia://[192.168.126.1]:9000/redfish/v1/Systems/local/hosted-dual-worker0 5 credentialsName: hosted-dual-worker0-bmc-secret 6 bootMACAddress: aa:aa:aa:aa:02:11 7 online: true 8- 1
infraenvs.agent-install.openshift.ioは、Assisted Installer オブジェクトとBareMetalHostオブジェクト間のリンクとして機能します。- 2
bmac.agent-install.openshift.io/hostnameは、デプロイメント中に採用されるノード名を表します。- 3
automatedCleaningModeは、ノードが Metal3 Operator によって消去されるのを防ぎます。- 4
disableCertificateVerificationはtrueに設定され、クライアントから証明書の検証がバイパスされます。- 5
addressは、ワーカーノードのベースボード管理コントローラー (BMC) アドレスを示します。- 6
credentialsNameは、ユーザーとパスワードの認証情報が保存されるシークレットを指します。- 7
bootMACAddressは、ノードの起動元のインターフェイス MAC アドレスを示します。- 8
onlineは、BareMetalHostオブジェクトが作成された後のノードの状態を定義します。
次のコマンドを入力して、
BareMetalHostオブジェクトをデプロイします。oc apply -f 04-bmh.yaml
プロセス中に、次の出力が確認できます。
この出力は、プロセスがノードに到達しようとしていることを示しています。
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 registering true 2s clusters-hosted hosted-worker1 registering true 2s clusters-hosted hosted-worker2 registering true 2s
この出力は、ノードが起動していることを示しています。
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 provisioning true 16s clusters-hosted hosted-worker1 provisioning true 16s clusters-hosted hosted-worker2 provisioning true 16s
- この出力は、ノードが正常に起動したことを示しています。
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 provisioned true 67s clusters-hosted hosted-worker1 provisioned true 67s clusters-hosted hosted-worker2 provisioned true 67s
ノードが起動したら、次の例に示すように、namespace のエージェントに注目してください。
NAMESPACE NAME CLUSTER APPROVED ROLE STAGE clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411 true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412 true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413 true auto-assign
エージェントは、インストールに使用できるノードを表します。ホステッドクラスターにノードを割り当てるには、ノードプールをスケールアップします。
1.7.10.7.9.6. ノードプールのスケールアップ
ベアメタルホストを作成すると、そのステータスが Registering Provisioning、Provisioned に変わります。ノードは、エージェントの LiveISO と、agent という名前のデフォルトの Pod で始まります。このエージェントは、Assisted Service Operator から OpenShift Container Platform ペイロードをインストールする指示を受け取ります。
ノードプールをスケールアップするには、次のコマンドを入力します。
oc -n clusters scale nodepool hosted-dual --replicas 3
スケーリングプロセスが完了すると、エージェントがホステッドクラスターに割り当てられていることがわかります。
NAMESPACE NAME CLUSTER APPROVED ROLE STAGE clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411 hosted true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412 hosted true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413 hosted true auto-assign
また、ノードプールレプリカが設定されていることにも注意してください。
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters hosted hosted 3 False False 4.14.0-0.nightly-2023-08-29-102237 Minimum availability requires 3 replicas, current 0 available
- ノードがクラスターに参加するまで待ちます。プロセス中に、エージェントはステージとステータスに関する最新情報を提供します。
次に、ホステッドクラスターのデプロイメントを監視します。
1.7.10.7.10. デュアルスタックネットワークのホステッドクラスターデプロイメントの終了
ホステッドクラスターのデプロイメントは、コントロールプレーンとデータプレーンの 2 つの観点から監視できます。
1.7.10.7.10.1. コントロールプレーンの監視
ホステッドクラスターのデプロイメント中に、次のコマンドを入力してコントロールプレーンを監視できます。
export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
watch "oc get pod -n hypershift;echo;echo;oc get pod -n clusters-hosted-ipv4;echo;echo;oc get bmh -A;echo;echo;oc get agent -A;echo;echo;oc get infraenv -A;echo;echo;oc get hostedcluster -A;echo;echo;oc get nodepool -A;echo;echo;"
これらのコマンドは、次のアーティファクトに関する情報を提供します。
- HyperShift Operator
-
HostedControlPlanePod - ベアメタルホスト
- エージェント
-
InfraEnvリソース -
HostedClusterおよびNodePoolリソース
1.7.10.7.10.2. データプレーンの監視
デプロイメントプロセス中に Operator がどのように進行しているかを監視するには、次のコマンドを入力します。
oc get secret -n clusters-hosted-ipv4 admin-kubeconfig -o jsonpath='{.data.kubeconfig}' |base64 -d > /root/hc_admin_kubeconfig.yamlexport KUBECONFIG=/root/hc_admin_kubeconfig.yaml
watch "oc get clusterversion,nodes,co"
これらのコマンドは、次のアーティファクトに関する情報を提供します。
- クラスターのバージョン
- ノード (特にノードがクラスターに参加したかどうかについて)
- クラスター Operator
1.7.11. Hosted Control Plane クラスターの手動インポート
ホステッドクラスターは、Hosted Control Plane が使用可能になった後、マルチクラスターエンジン Operator に自動的にインポートされます。ホステッドクラスターを手動でインポートする場合は、次の手順を実行します。
- Infrastructure > Clusters をクリックし、インポートするホステッドクラスターを選択します。
Import hosted cluster をクリックします。
注記: 検出された ホステッドクラスターについては、コンソールからインポートすることもできますが、クラスターはアップグレード可能な状態である必要があります。Hosted Control Plane を使用できないため、ホステッドクラスターがアップグレード可能な状態ではない場合、クラスターへのインポートは無効になります。Import をクリックして、プロセスを開始します。クラスターが更新を受信している間、ステータスは
Importingであり、その後、Readyに変わります。
1.7.11.1. Hosted Control Plane クラスターの AWS での手動インポート
次の手順を実行することで、コマンドラインインターフェイスを使用して、ホストされているコントロールプレーンクラスターを AWS にインポートすることもできます。
以下のサンプル YAML ファイルを使用して、
ManagedClusterリソースを作成します。apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: annotations: import.open-cluster-management.io/hosting-cluster-name: local-cluster import.open-cluster-management.io/klusterlet-deploy-mode: Hosted open-cluster-management/created-via: hypershift labels: cloud: auto-detect cluster.open-cluster-management.io/clusterset: default name: <cluster_name> vendor: OpenShift name: <cluster_name> spec: hubAcceptsClient: true leaseDurationSeconds: 60<cluster_name>は、ホステッドクラスターの名前に置き換えます。以下のコマンドを実行してリソースを適用します。
oc apply -f <file_name>
<file_name> を、直前の手順で作成した YAML ファイル名に置き換えます。
以下のサンプル YAML ファイルを使用して、
KlusterletAddonConfigリソースを作成します。これは、Red Hat Advanced Cluster Management にのみ適用されます。マルチクラスターエンジン Operator のみをインストールした場合は、この手順を省略します。apiVersion: agent.open-cluster-management.io/v1 kind: KlusterletAddonConfig metadata: name: <cluster_name> namespace: <cluster_name> spec: clusterName: <cluster_name> clusterNamespace: <cluster_name> clusterLabels: cloud: auto-detect vendor: auto-detect applicationManager: enabled: true certPolicyController: enabled: true iamPolicyController: enabled: true policyController: enabled: true searchCollector: enabled: false<cluster_name>は、ホステッドクラスターの名前に置き換えます。以下のコマンドを実行してリソースを適用します。
oc apply -f <file_name>
<file_name> を、直前の手順で作成した YAML ファイル名に置き換えます。
インポートプロセスが完了すると、ホステッドクラスターがコンソールに表示されます。以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。
oc get managedcluster <cluster_name>
1.7.11.2. 関連情報
- ホステッドクラスターの自動インポートを無効にする手順は、マルチクラスターエンジン Operator へのホステッドクラスターの自動インポートの無効化 を参照してください。
1.7.11.3. ホステッドクラスターのマルチクラスターエンジン Operator への自動インポートを無効にする
マルチクラスターエンジン Operator 2.4 以降では、コントロールプレーンが使用可能になった後、ホステッドクラスターがマルチクラスターエンジン Operator に自動的にインポートされます。Red Hat Advanced Cluster Management がインストールされている場合は、すべての Red Hat Advanced Cluster Management アドオンも有効になります。自動インポートを無効にしても、以前にインポートされたホステッドクラスターは影響を受けません。マルチクラスターエンジンオペレーター 2.4 にアップグレードし、自動インポートが有効になっている場合、コントロールプレーンが使用可能な場合、インポートされていないすべてのホストクラスターが自動的にインポートされます。
必要に応じて、ホステッドクラスターの自動インポートを無効にすることができます。自動インポートが無効になっている場合、新しく作成されたホステッドクラスターのみが自動的にインポートされません。すでにインポートされているホステッドクラスターは影響を受けません。コンソールを使用するか、ManagedCluster および KlusterletAddonConfig カスタムリソースを作成することにより、クラスターを手動でインポートすることもできます。手動インポートの詳細は、Hosted control plane クラスターの手動インポート を参照してください。
ホステッドクラスターの自動インポートを無効にするには、次の手順を実行します。
ハブクラスターで、次のコマンドを入力して、multicluster engine Operator がインストールされている namespace の
AddonDeploymentConfigリソースにあるhypershift-addon-deploy-config仕様を開きます。oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine
次の例に示すように、
spec.customizedVariablesセクションで、値が"true"のautoImportDisabled変数を追加します。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: AddOnDeploymentConfig metadata: name: hypershift-addon-deploy-config namespace: multicluster-engine spec: customizedVariables: - name: hcMaxNumber value: "80" - name: hcThresholdNumber value: "60" - name: autoImportDisabled value: "true"-
自動インポートを再度有効にするには、
autoImportDisabled変数の値を"false"に設定するか、AddonDeploymentConfigリソースから変数を削除します。
1.7.11.3.1. 関連情報
ホステッドクラスターを手動でインポートする手順は、Hosted Control Plane クラスターの手動インポート を参照してください。
1.7.12. Hosted Control Plane 機能の有効化または無効化
Hosted Control Plane 機能と hypershift-addon マネージドクラスターアドオンは、デフォルトで有効になっています。機能を無効にする場合、または機能を無効にして手動で有効にする必要がある場合は、次の手順を参照してください。
1.7.12.1. Hosted Control Plane 機能を手動での有効化
次のコマンドを実行して、以下の機能を有効にすることができます。
oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}' 1- 1
- デフォルトの
MultiClusterEngineリソースインスタンス名はmulticlusterengineですが、$ oc get mceコマンドを実行し、クラスターからMultiClusterEngine名を取得できます。
次のコマンドを実行して、
hypershiftおよびhypershift-local-hosting機能がMultiClusterEngineカスタムリソースで有効になっていることを確認します。oc get mce multiclusterengine -o yaml 1- 1
- デフォルトの
MultiClusterEngineリソースインスタンス名はmulticlusterengineですが、$ oc get mceコマンドを実行し、クラスターからMultiClusterEngine名を取得できます。
出力は以下の例のようになります。
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: overrides: components: - name: hypershift enabled: true - name: hypershift-local-hosting enabled: true
1.7.12.1.1. local-cluster の hypershift-addon マネージドクラスターアドオンを手動で有効にする
Hosted Control Plane 機能を有効にすると、hypershift-addon マネージドクラスターアドオンが自動的に有効になります。hypershift-addon マネージドクラスターアドオンを手動で有効にする必要がある場合は、次の手順を実行して hypershift-addon を使用し、HyperShift Operator を local-cluster にインストールします。
以下の例のようなファイルを作成して、
ManagedClusterAddonHyperShift アドオンを作成します。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ManagedClusterAddOn metadata: name: hypershift-addon namespace: local-cluster spec: installNamespace: open-cluster-management-agent-addon
以下のコマンドを実行してこのファイルを適用します。
oc apply -f <filename>
filenameは、作成したファイル名に置き換えます。以下のコマンドを実行して、
hypershift-addonがインストールされていることを確認します。oc get managedclusteraddons -n local-cluster hypershift-addon
アドオンがインストールされている場合、出力は以下の例のようになります。
NAME AVAILABLE DEGRADED PROGRESSING hypershift-addon True
HyperShift アドオンがインストールされ、ホスティングクラスターを使用してホステッドクラスターを作成および管理できるようになります。
1.7.12.2. Hosted Control Plane 機能の無効化
HyperShift Operator をアンインストールして、Hosted Control Plane を無効にすることができます。Hosted Control Plane クラスター機能を無効にする場合は、Hosted Control Plane クラスターの管理 トピックで説明されているとおり、マルチクラスターエンジン Operator でホステッドクラスターとマネージドクラスターリソースを破棄する必要があります。
1.7.12.2.1. HyperShift Operator のアンインストール
HyperShift Operator をアンインストールし、local-cluster から hypershift-addon を無効にするには、以下の手順を実行します。
以下のコマンドを実行して、ホステッドクラスターが実行されていないことを確認します。
oc get hostedcluster -A
重要: ホステッドクラスターが実行されている場合、
hypershift-addonが無効になっていても、HyperShift Operator はアンインストールされません。以下のコマンドを実行して
hypershift-addonを無効にします。oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}' 1- 1
- デフォルトの
MultiClusterEngineリソースインスタンス名はmulticlusterengineですが、$ oc get mceコマンドを実行し、クラスターからMultiClusterEngine名を取得できます。
注記:
hypershift-addonを無効にした後、マルチクラスターエンジン Operator コンソールからlocal-clusterのhypershift-addonを無効にすることもできます。
1.7.12.2.2. Hosted Control Plane 機能の無効化
Hosted Control Plane 機能を無効にする前に、まず HyperShift Operator をアンインストールする必要があります。次のコマンドを実行して、Hosted Control Plane 機能を無効にします。
oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": false}]}}}' 1- 1
- デフォルトの
MultiClusterEngineリソースインスタンス名はmulticlusterengineですが、$ oc get mceコマンドを実行し、クラスターからMultiClusterEngine名を取得できます。
次のコマンドを実行すると、MultiClusterEngine カスタムリソースで hypershift および hypershift-local-hosting 機能が無効になっていることを確認できます。
oc get mce multiclusterengine -o yaml 1- 1
- デフォルトの
MultiClusterEngineリソースインスタンス名はmulticlusterengineですが、$ oc get mceコマンドを実行し、クラスターからMultiClusterEngine名を取得できます。
hypershift と hypershift-local-hosting の enabled: フラグが false に設定されている次の例を参照してください。
apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
name: multiclusterengine
spec:
overrides:
components:
- name: hypershift
enabled: false
- name: hypershift-local-hosting
enabled: false