Red Hat Advanced Cluster Management for Kubernetes

マネージドクラスターのセットを選択するのと同じ namespace 内の配置の名前に置き換えます。

カスタムイメージレジストリーからイメージをプルするために使用されるプルシークレットの名前に置き換えます。

ソース および ミラー レジストリーのそれぞれの値をリスト表示します。mirrored-image-registry-address および image-registry-address は、レジストリーの各 ミラー および ソース 値に置き換えます。

例 1: registry.redhat.io/rhacm2 という名前のソースイメージレジストリーを localhost:5000/rhacm2 に、registry.redhat.io/multicluster-engine を localhost:5000/multicluster-engine に置き換えるには、以下の例を使用します。

registries:
- mirror: localhost:5000/rhacm2/
    source: registry.redhat.io/rhacm2
- mirror: localhost:5000/multicluster-engine
    source: registry.redhat.io/multicluster-engine

registries:
- mirror: localhost:5000/rhacm2/
    source: registry.redhat.io/rhacm2
- mirror: localhost:5000/multicluster-engine
    source: registry.redhat.io/multicluster-engine

Copy to Clipboard

Toggle word wrap

例 2: ソースイメージ registry.redhat.io/rhacm2/registration-rhel8-operator を localhost:5000/rhacm2-registration-rhel8-operator に置き換えるには、以下の例を使用します。

registries:
- mirror: localhost:5000/rhacm2-registration-rhel8-operator
    source: registry.redhat.io/rhacm2/registration-rhel8-operator

registries:
- mirror: localhost:5000/rhacm2-registration-rhel8-operator
    source: registry.redhat.io/rhacm2/registration-rhel8-operator

Copy to Clipboard

Toggle word wrap

重要: エージェント登録を使用してマネージドクラスターをインポートする場合は、イメージレジストリーを含む KlusterletConfig を作成する必要があります。以下の例を参照してください。必要に応じて値を置き換えます。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: <klusterletconfigName>
spec:
  pullSecret:
    namespace: <pullSecretNamespace>
    name: <pullSecretName>
  registries:
    - mirror: <mirrored-image-registry-address>
      source: <image-registry-address>
    - mirror: <mirrored-image-registry-address>
      source: <image-registry-address>

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: <klusterletconfigName>
spec:
  pullSecret:
    namespace: <pullSecretNamespace>
    name: <pullSecretName>
  registries:
    - mirror: <mirrored-image-registry-address>
      source: <image-registry-address>
    - mirror: <mirrored-image-registry-address>
      source: <image-registry-address>

Copy to Clipboard

Toggle word wrap

詳細は、エージェント登録エンドポイントを使用したマネージドクラスターのインポートを参照してください。

1.5.5.5.1. ManagedClusterImageRegistry を持つクラスターのインポート
リンクのコピー

ManagedClusterImageRegistry カスタムリソース定義でカスタマイズされるクラスターをインポートするには、以下の手順を実行します。

クラスターをインポートする必要のある namespace にプルシークレットを作成します。これらの手順では、namespace は myNamespace です。

kubectl create secret docker-registry myPullSecret \
  --docker-server=<your-registry-server> \
  --docker-username=<my-name> \
  --docker-password=<my-password>

$ kubectl create secret docker-registry myPullSecret \
  --docker-server=<your-registry-server> \
  --docker-username=<my-name> \
  --docker-password=<my-password>

Copy to Clipboard

Toggle word wrap

作成した namespace に Placement を作成します。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: myPlacement
  namespace: myNamespace
spec:
  clusterSets:
  - myClusterSet
  tolerations:
  - key: "cluster.open-cluster-management.io/unreachable"
    operator: Exists

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: myPlacement
  namespace: myNamespace
spec:
  clusterSets:
  - myClusterSet
  tolerations:
  - key: "cluster.open-cluster-management.io/unreachable"
    operator: Exists

Copy to Clipboard

Toggle word wrap

注記: Placement がクラスターを選択できるようにするには、toleration を unreachable に指定する必要があります。

ManagedClusterSet リソースを作成し、これを namespace にバインドします。

apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: myClusterSet

---
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  name: myClusterSet
  namespace: myNamespace
spec:
  clusterSet: myClusterSet

apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: myClusterSet

---
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  name: myClusterSet
  namespace: myNamespace
spec:
  clusterSet: myClusterSet

Copy to Clipboard

Toggle word wrap

namespace に ManagedClusterImageRegistry カスタムリソース定義を作成します。

apiVersion: imageregistry.open-cluster-management.io/v1alpha1
kind: ManagedClusterImageRegistry
metadata:
  name: myImageRegistry
  namespace: myNamespace
spec:
  placementRef:
    group: cluster.open-cluster-management.io
    resource: placements
    name: myPlacement
  pullSecret:
    name: myPullSecret
  registry: myRegistryAddress

apiVersion: imageregistry.open-cluster-management.io/v1alpha1
kind: ManagedClusterImageRegistry
metadata:
  name: myImageRegistry
  namespace: myNamespace
spec:
  placementRef:
    group: cluster.open-cluster-management.io
    resource: placements
    name: myPlacement
  pullSecret:
    name: myPullSecret
  registry: myRegistryAddress

Copy to Clipboard

Toggle word wrap

コンソールからマネージドクラスターをインポートし、マネージドクラスターセットに追加します。
open-cluster-management.io/image-registry=myNamespace.myImageRegistry ラベルをマネージドクラスターに追加した後に、マネージドクラスターで import コマンドをコピーして実行します。

1.5.6. クラスターへのアクセス
リンクのコピー

作成され、管理されている Red Hat OpenShift Container Platform クラスターにアクセスするには、以下の手順を実行します。

コンソールから、Infrastructure > Clusters に移動し、作成したクラスターまたはアクセスするクラスターの名前を選択します。
Reveal credentials を選択し、クラスターのユーザー名およびパスワードを表示します。クラスターにログインする際に使用するため、この値を書き留めてください。
注記: インポートしたクラスターでは、Reveal credentials オプションは利用できません。
クラスターにリンクする Console URL を選択します。
手順 3 で確認したユーザー ID およびパスワードを使用して、クラスターにログインします。

1.5.7. マネージドクラスターのスケーリング
リンクのコピー

作成したクラスターは、仮想マシンのサイズやノード数など、マネージドクラスターの仕様をカスタマイズおよびサイズ変更できます。インストーラーでプロビジョニングされたインフラストラクチャーをクラスターデプロイメントに使用している場合は、次のオプションを参照してください。

MachinePool によるスケーリング

クラスターのデプロイメントに Central Infrastructure Management を使用している場合は、次のオプションを参照してください。

OpenShift Container Platform クラスターへのワーカーノードの追加
マネージドクラスターへのコントロールプレーンノードの追加

1.5.7.1. MachinePool によるスケーリング
リンクのコピー

multicluster engine Operator を使用してプロビジョニングするクラスターの場合、MachinePool リソースが自動的に作成されます。MachinePool を使用して、仮想マシンのサイズやノード数など、マネージドクラスターの仕様をさらにカスタマイズおよびサイズ変更できます。

MachinePool リソースの使用は、ベアメタルクラスターではサポートされていません。
MachinePool リソースは、ハブクラスター上の Kubernetes リソースで、MachineSet リソースをマネージドクラスターでグループ化します。
MachinePool リソースは、ゾーンの設定、インスタンスタイプ、ルートストレージなど、マシンリソースのセットを均一に設定します。
MachinePool では、マネージドクラスターで、必要なノード数を手動で設定したり、ノードの自動スケーリングを設定したりするのに役立ちます。

1.5.7.1.1. 自動スケーリングの設定
リンクのコピー

自動スケーリングを設定すると、トラフィックが少ない場合にリソースをスケールダウンし、多くのリソースが必要な場合に十分にリソースを確保できるようにスケールアップするなど、必要に応じてクラスターに柔軟性を持たせることができます。

コンソールを使用して MachinePool リソースで自動スケーリングを有効にするには、以下の手順を実行します。
1. ナビゲーションで、Infrastructure > Clusters を選択します。
2. ターゲットクラスターの名前をクリックし、Machine pools タブを選択します。
3. マシンプールページのターゲットマシンプールの Options メニューから Enable autoscale を選択します。
4. マシンセットレプリカの最小数および最大数を選択します。マシンセットレプリカは、クラスターのノードに直接マップします。
  Scale をクリックした後、変更がコンソールに反映されるまでに数分かかる場合があります。Machine pools タブの通知がある場合は、View machines をクリックしてスケーリング操作のステータスを表示できます。
コマンドラインを使用して MachinePool リソースで自動スケーリングを有効にするには、以下の手順を実行します。
1. 次のコマンドを入力して、マシンプールのリストを表示します。このとき、managed-cluster-namespace は、ターゲットのマネージドクラスターの namespace に置き換えます。
  oc get machinepools -n <managed-cluster-namespace>
  Copy to Clipboard Toggle word wrap
2. 以下のコマンドを入力してマシンプールの YAML ファイルを編集します。
  oc edit machinepool <MachinePool-resource-name> -n <managed-cluster-namespace>
  Copy to Clipboard Toggle word wrap
  - MachinePool-resource-name は MachinePool リソースの名前に置き換えます。
  - managed-cluster-namespace はマネージドクラスターの namespace の名前に置き換えます。
3. YAML ファイルから spec.replicas フィールドを削除します。
4. spec.autoscaling.minReplicas 設定および spec.autoscaling.maxReplicas フィールドをリソース YAML に追加します。
5. レプリカの最小数を minReplicas 設定に追加します。
6. レプリカの最大数を maxReplicas 設定に追加します。
7. ファイルを保存して変更を送信します。

1.5.7.1.2. 自動スケーリングの無効化
リンクのコピー

コンソールまたはコマンドラインを使用して自動スケーリングを無効にできます。

コンソールを使用して自動スケーリングを無効にするには、次の手順を実行します。
1. ナビゲーションで、Infrastructure > Clusters を選択します。
2. ターゲットクラスターの名前をクリックし、Machine pools タブを選択します。
3. マシンプールページから、ターゲットマシンプールの Options メニューから autoscale を無効にします。
4. 必要なマシンセットのレプリカ数を選択します。マシンセットのレプリカは、クラスター上のノードを直接マップします。
  Scale をクリックした後、表示されるまでに数分かかる場合があります。Machine pools タブの通知で View machines をクリックすると、スケーリングの状態を表示できます。
コマンドラインを使用して自動スケーリングを無効にするには、以下の手順を実行します。
1. 以下のコマンドを実行して、マシンプールのリストを表示します。
  oc get machinepools -n <managed-cluster-namespace>
  Copy to Clipboard Toggle word wrap
  managed-cluster-namespace は、ターゲットのマネージドクラスターの namespace に置き換えます。
2. 以下のコマンドを入力してマシンプールの YAML ファイルを編集します。
  oc edit machinepool <name-of-MachinePool-resource> -n <namespace-of-managed-cluster>
  Copy to Clipboard Toggle word wrap
  name-of-MachinePool-resource は、MachinePool リソースの名前に置き換えます。
  namespace-of-managed-cluster は、マネージドクラスターの namespace 名に置き換えます。
3. YAML ファイルから spec.autoscaling フィールドを削除します。
4. spec.replicas フィールドをリソース YAML に追加します。
5. replicas の設定にレプリカ数を追加します。
6. ファイルを保存して変更を送信します。

1.5.7.1.3. 手動スケーリングの有効化
リンクのコピー

コンソールおよびコマンドラインから手動でスケーリングできます。

1.5.7.1.3.1. コンソールでの手動スケーリングの有効化
リンクのコピー

コンソールを使用して MachinePool リソースをスケーリングするには、次の手順を実行します。

有効になっている場合は、MachinePool の自動スケーリングを無効にします。前の手順を参照してください。
コンソールから、Infrastructure > Clusters をクリックします。
ターゲットクラスターの名前をクリックし、Machine pools タブを選択します。
マシンプールページで、対象のマシンプールの Options メニューから Scale machine pool を選択します。
必要なマシンセットのレプリカ数を選択します。マシンセットのレプリカは、クラスター上のノードを直接マップします。Scale をクリックした後、変更がコンソールに反映されるまでに数分かかる場合があります。マシンプールタブの通知から View machines をクリックすると、スケーリング操作の状態を表示できます。

1.5.7.1.3.2. コマンドラインでの手動スケーリングの有効化
リンクのコピー

コマンドラインを使用して MachinePool リソースをスケーリングするには、次の手順を実行します。

次のコマンドを入力して、マシンプールのリストを表示します。このとき、<managed-cluster-namespace> は、ターゲットのマネージドクラスターの namespace に置き換えます。
```
oc get machinepools -n <managed-cluster-namespace>
```
```
oc get machinepools -n <managed-cluster-namespace>
```
Copy to Clipboard Toggle word wrap
以下のコマンドを入力してマシンプールの YAML ファイルを編集します。
```
oc edit machinepool <MachinePool-resource-name> -n <managed-cluster-namespace>
```
```
oc edit machinepool <MachinePool-resource-name> -n <managed-cluster-namespace>
```
Copy to Clipboard Toggle word wrap
- MachinePool-resource-name は MachinePool リソースの名前に置き換えます。
- managed-cluster-namespace はマネージドクラスターの namespace の名前に置き換えます。
YAML ファイルから spec.autoscaling フィールドを削除します。
YAML ファイルの spec.replicas フィールドを必要な数のレプリカに変更します。
ファイルを保存して変更を送信します。

1.5.7.2. OpenShift Container Platform クラスターへのワーカーノードの追加
リンクのコピー

Central Infrastructure Management を使用している場合は、実稼働環境ノードを追加することで OpenShift Container Platform クラスターをカスタマイズできます。

必要なアクセス権限: 管理者

前提条件
有効な kubeconfig の作成
ワーカーノードの追加

1.5.7.2.1. 前提条件
リンクのコピー

マネージドクラスター API を信頼するために必要な新しい CA 証明書が必要です。

1.5.7.2.2. 有効な kubeconfig の作成
リンクのコピー

実稼働環境のワーカーノードを OpenShift Container Platform クラスターに追加する前に、有効な kubeconfig があるかどうかを確認する必要があります。

マネージドクラスターの API 証明書が変更された場合は、次の手順を実行して、kubeconfig を新しい CA 証明書で更新します。

次のコマンドを実行して、clusterDeployment の kubeconfig が有効かどうかを確認します。<kubeconfig_name> を現在の kubeconfig の名前に置き換え、<cluster_name> をクラスターの名前に置き換えます。

export <kubeconfig_name>=$(oc get cd $<cluster_name> -o "jsonpath={.spec.clusterMetadata.adminKubeconfigSecretRef.name}")
oc extract secret/$<kubeconfig_name> --keys=kubeconfig --to=- > original-kubeconfig
oc --kubeconfig=original-kubeconfig get node

export <kubeconfig_name>=$(oc get cd $<cluster_name> -o "jsonpath={.spec.clusterMetadata.adminKubeconfigSecretRef.name}")
oc extract secret/$<kubeconfig_name> --keys=kubeconfig --to=- > original-kubeconfig
oc --kubeconfig=original-kubeconfig get node

Copy to Clipboard

Toggle word wrap

次のエラーメッセージが表示された場合は、kubeconfig シークレットを更新する必要があります。エラーメッセージが表示されない場合は、ワーカーノードの追加に進みます。
```
Unable to connect to the server: tls: failed to verify certificate: x509: certificate signed by unknown authority
```
```
Unable to connect to the server: tls: failed to verify certificate: x509: certificate signed by unknown authority
```
Copy to Clipboard Toggle word wrap
kubeconfig の certificate-authority-data フィールドから base64 でエンコードされた証明書バンドルを取得し、次のコマンドを実行してデコードします。
```
echo <base64 encoded blob> | base64 --decode > decoded-existing-certs.pem
```
```
echo <base64 encoded blob> | base64 --decode > decoded-existing-certs.pem
```
Copy to Clipboard Toggle word wrap
元のファイルをコピーして、更新された kubeconfig ファイルを作成します。次のコマンドを実行し、<new_kubeconfig_name> を新しい kubeconfig ファイルの名前に置き換えます。
```
cp original-kubeconfig <new_kubeconfig_name>
```
```
cp original-kubeconfig <new_kubeconfig_name>
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、デコードされた pem に新しい証明書を追加します。
```
cat decoded-existing-certs.pem new-ca-certificate.pem | openssl base64 -A
```
```
cat decoded-existing-certs.pem new-ca-certificate.pem | openssl base64 -A
```
Copy to Clipboard Toggle word wrap
テキストエディターを使用して、前のコマンドの base64 出力を新しい kubeconfig ファイルの certificate-authority-data キーの値として追加します。
新しい kubeconfig を使用して API をクエリーし、新しい kubeconfig が有効かどうかを確認します。以下のコマンドを実行します。<new_kubeconfig_name> を新しい kubeconfig ファイルの名前に置き換えます。
```
KUBECONFIG=<new_kubeconfig_name> oc get nodes
```
```
KUBECONFIG=<new_kubeconfig_name> oc get nodes
```
Copy to Clipboard Toggle word wrap
成功した出力を受け取った場合、kubeconfig は有効です。

次のコマンドを実行して、Red Hat Advanced Cluster Management ハブクラスターの kubeconfig シークレットを更新します。<new_kubeconfig_name> を新しい kubeconfig ファイルの名前に置き換えます。

oc patch secret $original-kubeconfig --type='json' -p="[{'op': 'replace', 'path': '/data/kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'},{'op': 'replace', 'path': '/data/raw-kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'}]"

oc patch secret $original-kubeconfig --type='json' -p="[{'op': 'replace', 'path': '/data/kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'},{'op': 'replace', 'path': '/data/raw-kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'}]"

Copy to Clipboard

Toggle word wrap

1.5.7.2.3. ワーカーノードの追加
リンクのコピー

有効な kubeconfig がある場合は、以下の手順を実行して、実稼働環境のワーカーノードを OpenShift Container Platform クラスターに追加します。

ワーカーノードとして使用するマシンを、以前にダウンロードした ISO から起動します。
注記: ワーカーノードが OpenShift Container Platform ワーカーノードの要件を満たしていることを確認してください。
次のコマンドを実行した後、エージェントが登録されるまで待ちます。
```
watch -n 5 "oc get agent -n managed-cluster"
```
```
watch -n 5 "oc get agent -n managed-cluster"
```
Copy to Clipboard Toggle word wrap
エージェントの登録が成功すると、エージェントがリストされます。インストールのためにエージェントを承認します。これには数分かかる場合があります。
注記: エージェントがリストにない場合は、Ctrl キーと C キーを押して watch コマンドを終了し、ワーカーノードにログインしてトラブルシューティングを行ってください。

遅延バインディングを使用している場合は、次のコマンドを実行して、保留中のバインドされていないエージェントを OpenShift Container Platform クラスターに関連付けます。遅延バインディングを使用していない場合は、ステップ 5 に進みます。

oc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) |select(.spec.clusterDeploymentName==null) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"clusterDeploymentName":{"name":"some-other-cluster","namespace":"managed-cluster"}}}' --type merge agent

oc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) |select(.spec.clusterDeploymentName==null) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"clusterDeploymentName":{"name":"some-other-cluster","namespace":"managed-cluster"}}}' --type merge agent

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、保留中のエージェントのインストールを承認します。

oc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"approved":true}}' --type merge agent

oc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"approved":true}}' --type merge agent

Copy to Clipboard

Toggle word wrap

ワーカーノードのインストールを待ちます。ワーカーノードのインストールが完了すると、ワーカーノードは証明書署名要求 (CSR) を使用してマネージドクラスターに接続し、参加プロセスを開始します。CSR は自動的に署名されます。

1.5.7.3. マネージドクラスターへのコントロールプレーンノードの追加
リンクのコピー

問題のあるコントロールプレーンを置き換えるには、コントロールプレーンノードを正常または正常でないマネージドクラスターに追加します。

必要なアクセス権限: 管理者

1.5.7.3.1. 正常なマネージドクラスターへのコントロールプレーンノードの追加
リンクのコピー

以下の手順を実行して、コントロールプレーンノードを正常なマネージドクラスターに追加します。

新規コントロールプレーンノードの OpenShift Container Platform クラスターへのワーカーノードの追加の手順を実行します。
Discovery ISO を使用してノードを追加する場合は、エージェントを承認する前にエージェントを master に設定します。以下のコマンドを実行します。
```
oc patch agent <AGENT-NAME> -p '{"spec":{"role": "master"}}' --type=merge
```
```
oc patch agent <AGENT-NAME> -p '{"spec":{"role": "master"}}' --type=merge
```
Copy to Clipboard Toggle word wrap
注記: CSR は自動的に承認されません。
BareMetalHost を使用してノードを追加する場合は、BareMetalHost リソースの作成時に、BareMetalHost アノテーションに次の行を追加します。
```
    bmac.agent-install.openshift.io/role: master
```
```
    bmac.agent-install.openshift.io/role: master
```
Copy to Clipboard Toggle word wrap
OpenShift Container Platform の Assisted Installer ドキュメントの正常なクラスターへのプライマリーコントロールプレーンノードのインストールの手順に従ってください。

1.5.7.3.2. 正常でないマネージドクラスターへのコントロールプレーンノードの追加
リンクのコピー

以下の手順を実行して、コントロールプレーンノードを正常でないマネージドクラスターに追加します。

正常でないコントロールプレーンノードのエージェントを削除します。
デプロイメントにゼロタッチプロビジョニングフローを使用した場合は、ベアメタルホストを削除します。
新規コントロールプレーンノードの OpenShift Container Platform クラスターへのワーカーノードの追加の手順を実行します。
次のコマンドを実行して、エージェントを承認する前にエージェントを master に設定します。
```
oc patch agent <AGENT-NAME> -p '{"spec":{"role": "master"}}' --type=merge
```
```
oc patch agent <AGENT-NAME> -p '{"spec":{"role": "master"}}' --type=merge
```
Copy to Clipboard Toggle word wrap
注記: CSR は自動的に承認されません。
OpenShift Container Platform の Assisted Installer ドキュメントの正常でないクラスターへのプライマリーコントロールプレーンノードのインストールの手順に従ってください。

1.5.8. 作成されたクラスターの休止
リンクのコピー

リソースを節約するために、multicluster engine Operator を使用して作成されたクラスターを休止状態にすることができます。休止状態のクラスターに必要となるリソースは、実行中のものより少なくなるので、クラスターを休止状態にしたり、休止状態を解除したりすることで、プロバイダーのコストを削減できる可能性があります。この機能は、次の環境の multicluster engine Operator によって作成されたクラスターにのみ適用されます。

Amazon Web Services
Microsoft Azure
Google Cloud Platform

1.5.8.1. コンソールを使用したクラスターの休止
リンクのコピー

コンソールを使用して、multicluster engine Operator によって作成されたクラスターを休止状態にするには、次の手順を実行します。

ナビゲーションメニューから Infrastructure > Clusters を選択します。Manage clusters タブが選択されていることを確認します。
そのクラスターの Options メニューから Hibernate cluster を選択します。注記: Hibernate cluster オプションが利用できない場合には、クラスターを休止状態にすることはできません。これは、クラスターがインポートされたものであり、multicluster engine Operator によって作成されたものでない場合に発生する可能性があります。

Clusters ページのクラスターのステータスは、プロセスが完了すると Hibernating になります。

ヒント: Clusters ページで休止するするクラスターを選択し、Actions > Hibernate clusters を選択して、複数のクラスターを休止できます。

選択したクラスターが休止状態になりました。

1.5.8.2. CLI を使用したクラスターの休止
リンクのコピー

CLI を使用して、multicluster engine Operator によって作成されたクラスターを休止状態にするには、次の手順を実行します。

以下のコマンドを入力して、休止するクラスターの設定を編集します。
```
oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
```
```
oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
```
Copy to Clipboard Toggle word wrap
name-of-cluster は、休止するクラスター名に置き換えます。
namespace-of-cluster は、休止するクラスターの namespace に置き換えます。
spec.powerState の値は Hibernating に変更します。
以下のコマンドを実行して、クラスターのステータスを表示します。
```
oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
```
```
oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
```
Copy to Clipboard Toggle word wrap
name-of-cluster は、休止するクラスター名に置き換えます。
namespace-of-cluster は、休止するクラスターの namespace に置き換えます。
クラスターを休止するプロセスが完了すると、クラスターのタイプの値は type=Hibernating になります。

選択したクラスターが休止状態になりました。

1.5.8.3. コンソールを使用して休止中のクラスターの通常操作を再開する手順
リンクのコピー

コンソールを使用して、休止中のクラスターの通常操作を再開するには、以下の手順を実行します。

ナビゲーションメニューから Infrastructure > Clusters を選択します。Manage clusters タブが選択されていることを確認します。
再開するクラスターの Options メニューから Resume cluster を選択します。

プロセスを完了すると、Clusters ページのクラスターのステータスは Ready になります。

ヒント: Clusters ページで、再開するクラスターを選択し、Actions > Resume cluster の順に選択して、複数のクラスターを再開できます。

選択したクラスターで通常の操作が再開されました。

1.5.8.4. CLI を使用して休止中のクラスターの通常操作を再開する手順
リンクのコピー

CLI を使用して、休止中のクラスターの通常操作を再開するには、以下の手順を実行します。

以下のコマンドを入力してクラスターの設定を編集します。
```
oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
```
```
oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
```
Copy to Clipboard Toggle word wrap
name-of-cluster は、休止するクラスター名に置き換えます。
namespace-of-cluster は、休止するクラスターの namespace に置き換えます。
spec.powerState の値を Running に変更します。
以下のコマンドを実行して、クラスターのステータスを表示します。
```
oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
```
```
oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
```
Copy to Clipboard Toggle word wrap
name-of-cluster は、休止するクラスター名に置き換えます。
namespace-of-cluster は、休止するクラスターの namespace に置き換えます。
クラスターの再開プロセスが完了すると、クラスターのタイプの値は type=Running になります。

選択したクラスターで通常の操作が再開されました。

1.5.9. クラスターのアップグレード
リンクのコピー

multicluster engine Operator で管理する Red Hat OpenShift Container Platform クラスターを作成した後、multicluster engine Operator コンソールを使用して、マネージドクラスターが使用するバージョンチャネルで利用できる最新のマイナーバージョンにこれらのクラスターをアップグレードできます。

接続された環境では、コンソールでアップグレードが必要な各クラスターに提供される通知によって、更新が自動的に識別されます。

注記:

メジャーバージョンへのアップグレードには、そのバージョンへのアップグレードの前提条件をすべて満たしていることを確認する必要があります。コンソールでクラスターをアップグレードする前に、マネージドクラスターのバージョンチャネルを更新する必要があります。

マネージドクラスターでバージョンチャネルを更新すると、マルチクラスターエンジン Operator コンソールに、アップグレードに使用できる最新バージョンが表示されます。

このアップグレードの手法は、ステータスが Ready の OpenShift Container Platform のマネージドクラスタークラスターでだけ使用できます。

重要: マルチクラスターエンジン Operator コンソールを使用して、Red Hat OpenShift Kubernetes Service マネージドクラスターまたは OpenShift Container Platform マネージドクラスターを Red Hat OpenShift Dedicated でアップグレードすることはできません。

オンライン環境でクラスターをアップグレードするには、以下の手順を実行します。

ナビゲーションメニューから Infrastructure > Clusters に移動します。アップグレードが利用可能な場合には、Distribution version の列に表示されます。
アップグレードする Ready 状態のクラスターを選択します。クラスターはコンソールを使用してアップグレードされる OpenShift Container Platform クラスターである必要があります。
Upgrade を選択します。
各クラスターの新しいバージョンを選択します。
Upgrade を選択します。

クラスターのアップグレードに失敗すると、Operator は通常アップグレードを数回再試行し、停止し、コンポーネントに問題があるステータスを報告します。場合によっては、アップグレードプロセスは、プロセスの完了を繰り返し試行します。アップグレードに失敗した後にクラスターを以前のバージョンにロールバックすることはサポートされていません。クラスターのアップグレードに失敗した場合は、Red Hat サポートにお問い合わせください。

1.5.9.1. チャネルの選択
リンクのコピー

コンソールを使用して、OpenShift Container Platform でクラスターをアップグレードするためのチャネルを選択できます。チャネルを選択すると、エラータバージョンとリリースバージョンの両方で利用可能なクラスターアップグレードが自動的に通知されます。

クラスターのチャネルを選択するには、以下の手順を実行します。

ナビゲーションメニューから Infrastructure > Clusters をクリックします。
変更するクラスターの名前を選択して、Cluster details ページを表示します。クラスターに別のチャネルが利用可能な場合は、編集アイコンが Channel フィールドに表示されます。
編集アイコンをクリックして、フィールドの設定を変更します。
New channel フィールドでチャネルを選択します。

利用可能なチャネル更新のリマインダーは、クラスターの Cluster details ページで見つけることができます。

1.5.9.2. オフラインクラスターのアップグレード
リンクのコピー

マルチクラスターエンジン Operator と Red Hat OpenShift Update Service を使用し、オフライン環境でクラスターをアップグレードできます。

セキュリティー上の理由で、クラスターがインターネットに直接接続できない場合があります。このような場合は、アップグレードが利用可能なタイミングや、これらのアップグレードの処理方法を把握するのが困難になります。OpenShift Update Service を設定すると便利です。

OpenShift Update Service は、個別の Operator およびオペランドで、非接続環境で利用可能なマネージドクラスターを監視して、クラスターのアップグレードで利用できるようにします。OpenShift Update Service の設定後に、以下のアクションを実行できます。

オフラインのクラスター向けにいつアップグレードが利用できるかを監視します。
グラフデータファイルを使用してアップグレード用にどの更新がローカルサイトにミラーリングされているかを特定します。
コンソールを使用して、クラスターのアップグレードが利用可能であることを通知します。

次のトピックでは、オフラインクラスターをアップグレードする手順を説明します。

前提条件
非接続ミラーレジストリーの準備
OpenShift Update Service の Operator のデプロイ
グラフデータの init コンテナーの構築
ミラーリングされたレジストリーの証明書の設定
OpenShift Update Service インスタンスのデプロイ
デフォルトのレジストリーの上書き (オプション)
オフラインカタログソースのデプロイ
マネージドクラスターのパラメーターを変更する
利用可能なアップグレードの表示
チャネルの選択
クラスターのアップグレード

1.5.9.2.1. 前提条件
リンクのコピー

OpenShift Update Service を使用して非接続クラスターをアップグレードするには、以下の前提条件を満たす必要があります。

制限付き OLM が設定された Red Hat OpenShift Container Platform バージョン 4.13 以降で実行されているデプロイ済みハブクラスター。制限付きの OLM の設定方法については、ネットワークが制限された環境での Operator Lifecycle Manager の使用を参照してください。
Note: 制限付きの OLM の設定時に、カタログソースイメージをメモします。
ハブクラスターによって管理される OpenShift Container Platform クラスター
クラスターイメージをミラーリング可能なローカルレジストリーにアクセスするための認証情報。このリポジトリーを作成する方法の詳細は、非接続インストールミラーリングを参照してください。
注記: アップグレードするクラスターの現行バージョンのイメージは、ミラーリングされたイメージの 1 つとして常に利用可能でなければなりません。アップグレードに失敗すると、クラスターはアップグレード試行時のクラスターのバージョンに戻ります。

1.5.9.2.2. 非接続ミラーレジストリーの準備
リンクのコピー

ローカルのミラーリングレジストリーに、アップグレード前の現行のイメージと、アップグレード後のイメージの療法をミラーリングする必要があります。イメージをミラーリングするには以下の手順を実行します。

以下の例のような内容を含むスクリプトファイルを作成します。

UPSTREAM_REGISTRY=quay.io
PRODUCT_REPO=openshift-release-dev
RELEASE_NAME=ocp-release
OCP_RELEASE=4.12.2-x86_64
LOCAL_REGISTRY=$(hostname):5000
LOCAL_SECRET_JSON=/path/to/pull/secret 

oc adm -a ${LOCAL_SECRET_JSON} release mirror \
--from=${UPSTREAM_REGISTRY}/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
--to=${LOCAL_REGISTRY}/ocp4 \
--to-release-image=${LOCAL_REGISTRY}/ocp4/release:${OCP_RELEASE}

UPSTREAM_REGISTRY=quay.io
PRODUCT_REPO=openshift-release-dev
RELEASE_NAME=ocp-release
OCP_RELEASE=4.12.2-x86_64
LOCAL_REGISTRY=$(hostname):5000
LOCAL_SECRET_JSON=/path/to/pull/secret



oc adm -a ${LOCAL_SECRET_JSON} release mirror \
--from=${UPSTREAM_REGISTRY}/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
--to=${LOCAL_REGISTRY}/ocp4 \
--to-release-image=${LOCAL_REGISTRY}/ocp4/release:${OCP_RELEASE}

Copy to Clipboard

Toggle word wrap

1: path-to-pull-secret は、OpenShift Container Platform のプルシークレットへのパスに置き換えます。

スクリプトを実行して、イメージのミラーリング、設定の設定、リリースイメージとリリースコンテンツの分離を行います。
ImageContentSourcePolicy の作成時に、このスクリプトの最後の行にある出力を使用できます。

1.5.9.2.3. OpenShift Update Service の Operator のデプロイ
リンクのコピー

OpenShift Container Platform 環境で OpenShift Update Service の Operator をデプロイするには、以下の手順を実行します。

ハブクラスターで、OpenShift Container Platform Operator のハブにアクセスします。
Red Hat OpenShift Update Service Operator を選択して Operator をデプロイします。必要に応じてデフォルト値を更新します。Operator をデプロイすると、openshift-cincinnati という名前の新規プロジェクトが作成されます。
Operator のインストールが完了するまで待ちます。
OpenShift Container Platform コマンドラインで oc get pods コマンドを入力すると、インストールのステータスを確認できます。Operator の状態が running であることを確認します。

1.5.9.2.4. グラフデータの init コンテナーの構築
リンクのコピー

OpenShift Update Service はグラフデータ情報を使用して、利用可能なアップグレードを判別します。オンライン環境では、OpenShift Update Service は Cincinnati グラフデータの GitHub リポジトリーから直接利用可能なアップグレードがないか、グラフデータ情報をプルします。非接続環境を設定しているため、init container を使用してローカルリポジトリーでグラフデータを利用できるようにする必要があります。以下の手順を実行して、グラフデータの init container を作成します。

以下のコマンドを入力して、グラフデータ Git リポジトリーのクローンを作成します。
```
git clone https://github.com/openshift/cincinnati-graph-data
```
```
git clone https://github.com/openshift/cincinnati-graph-data
```
Copy to Clipboard Toggle word wrap
グラフデータの init の情報が含まれるファイルを作成します。このサンプル Dockerfile は、cincinnati-operator GitHub リポジトリーにあります。ファイルの内容は以下の例のようになります。
```
FROM registry.access.redhat.com/ubi8/ubi:8.1 

RUN curl -L -o cincinnati-graph-data.tar.gz https://github.com/openshift/cincinnati-graph-data/archive/master.tar.gz 

RUN mkdir -p /var/lib/cincinnati/graph-data/ 

CMD exec /bin/bash -c "tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/
cincinnati/graph-data/ --strip-components=1"  
```
```
FROM registry.access.redhat.com/ubi8/ubi:8.1 
```
1
```
RUN curl -L -o cincinnati-graph-data.tar.gz https://github.com/openshift/cincinnati-graph-data/archive/master.tar.gz 
```
2
```
RUN mkdir -p /var/lib/cincinnati/graph-data/ 
```
3
```
CMD exec /bin/bash -c "tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/
cincinnati/graph-data/ --strip-components=1"  
```
4
Copy to Clipboard Toggle word wrap
この例では、以下のように設定されています。
1
FROM 値は、OpenShift Update Service がイメージを検索する先の外部レジストリーに置き換えます。
2 3
RUN コマンドはディレクトリーを作成し、アップグレードファイルをパッケージ化します。
4
CMD コマンドは、パッケージファイルをローカルリポジトリーにコピーして、ファイルをデプロイメントしてアップグレードします。
以下のコマンドを実行して、graph data init container をビルドします。
```
podman build -f <path_to_Dockerfile> -t <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container>:latest  
podman push <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container><2>:latest --authfile=</path/to/pull_secret>.json 
```
```
podman build -f <path_to_Dockerfile> -t <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container>:latest 
```
1
```
 
```
2
```
podman push <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container><2>:latest --authfile=</path/to/pull_secret>.json 
```
3
Copy to Clipboard Toggle word wrap
1
path_to_Dockerfile を、直前の手順で作成したファイルへのパスに置き換えます。
2
${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container は、ローカルグラフデータ init container へのパスに置き換えます。
3
/path/to/pull_secret は、プルシークレットへのパスに置き換えます。
注記: podman がインストールされていない場合は、コマンドの podman を docker に置き換えることもできます。

1.5.9.2.5. ミラーリングされたレジストリーの証明書の設定
リンクのコピー

セキュアな外部コンテナーレジストリーを使用してミラーリングされた OpenShift Container Platform リリースイメージを保存する場合は、アップグレードグラフをビルドするために OpenShift Update Service からこのレジストリーへのアクセス権が必要です。OpenShift Update Service Pod と連携するように CA 証明書を設定するには、以下の手順を実行します。

image.config.openshift.io にある OpenShift Container Platform 外部レジストリー API を検索します。これは、外部レジストリーの CA 証明書の保存先です。
詳細は、OpenShift Container Platform ドキュメントのイメージレジストリーアクセス用の追加のトラストストアの設定を参照してください。
openshift-config namespace に ConfigMap を作成します。

キー updateservice-registry の下に CA 証明書を追加します。OpenShift Update Service はこの設定を使用して、証明書を特定します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: trusted-ca
data:
  updateservice-registry: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

apiVersion: v1
kind: ConfigMap
metadata:
  name: trusted-ca
data:
  updateservice-registry: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

Copy to Clipboard

Toggle word wrap

image.config.openshift.io API の cluster リソースを編集して、additionalTrustedCA フィールドを作成した ConfigMap 名に設定します。
```
oc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"trusted-ca"}}}' --type merge
```
```
oc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"trusted-ca"}}}' --type merge
```
Copy to Clipboard Toggle word wrap
trusted-ca は、新しい ConfigMap へのパスに置き換えます。

OpenShift Update Service Operator は、変更がないか、image.config.openshift.io API と、openshift-config namespace に作成した ConfigMap を監視し、CA 証明書が変更された場合はデプロイメントを再起動します。

1.5.9.2.6. OpenShift Update Service インスタンスのデプロイ
リンクのコピー

ハブクラスターへの OpenShift Update Service インスタンスのデプロイが完了したら、このインスタンスは、クラスターのアップグレードのイメージをミラーリングして非接続マネージドクラスターに提供する場所に配置されます。インスタンスをデプロイするには、以下の手順を実行します。

デフォルトの Operator の namespace (openshift-cincinnati) を使用しない場合は、お使いの OpenShift Update Service インスタンスの namespace を作成します。
1. OpenShift Container Platform ハブクラスターコンソールのナビゲーションメニューで、Administration > Namespaces を選択します。
2. Create Namespace を選択します。
3. namespace 名と、namespace のその他の情報を追加します。
4. Create を選択して namespace を作成します。
OpenShift Container Platform コンソールの Installed Operators セクションで、Red Hat OpenShift Update Service Operator を選択します。
メニューから Create Instance を選択します。

OpenShift Update Service インスタンスからコンテンツを貼り付けます。YAML ファイルは以下のマニフェストのようになります。

apiVersion: cincinnati.openshift.io/v1beta2
kind: Cincinnati
metadata:
  name: openshift-update-service-instance
  namespace: openshift-cincinnati
spec:
  registry: <registry_host_name>:<port> 
  replicas: 1
  repository: ${LOCAL_REGISTRY}/ocp4/release
  graphDataImage: '<host_name>:<port>/cincinnati-graph-data-container'

apiVersion: cincinnati.openshift.io/v1beta2
kind: Cincinnati
metadata:
  name: openshift-update-service-instance
  namespace: openshift-cincinnati
spec:
  registry: <registry_host_name>:<port>


  replicas: 1
  repository: ${LOCAL_REGISTRY}/ocp4/release
  graphDataImage: '<host_name>:<port>/cincinnati-graph-data-container'

Copy to Clipboard

Toggle word wrap

1: spec.registry の値は、イメージの非接続環境にあるローカルレジストリーへのパスに置き換えます。
2: spec.graphDataImage の値は、グラフデータ init container へのパスに置き換えます。これは、podman push コマンドを使用して、グラフデータ init container をプッシュする時に使用した値と同じです。

Create を選択してインスタンスを作成します。
ハブクラスター CLI で oc get pods コマンドを入力し、インスタンス作成のステータスを表示します。時間がかかる場合がありますが、コマンド結果でインスタンスと Operator が実行中である旨が表示されたらプロセスは完了です。

1.5.9.2.7. デフォルトのレジストリーの上書き (オプション)
リンクのコピー

注記: このセクションの手順は、ミラーレジストリーにリリースをミラーリングした場合にのみ該当します。

OpenShift Container Platform にはイメージレジストリーのデフォルト値があり、この値でアップグレードパッケージの検索先を指定します。オフライン環境では、オーバーライドを作成して、その値をリリースイメージをミラーリングしたローカルイメージレジストリーへのパスに置き換えることができます。

デフォルトのレジストリーを上書きするには、次の手順を実行します。

次の内容のような、mirror.yaml という名前の YAML ファイルを作成します。

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: <your-local-mirror-name>
spec:
  repositoryDigestMirrors:
    - mirrors:
        - <your-registry>
      source: registry.redhat.io

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: <your-local-mirror-name>


spec:
  repositoryDigestMirrors:
    - mirrors:
        - <your-registry>


      source: registry.redhat.io

Copy to Clipboard

Toggle word wrap

1: your-local-mirror-name をローカルミラーの名前に置き換えます。
2: your-registry をローカルミラーリポジトリーへのパスに置き換えます。

注記: oc adm release mirror コマンドを入力すると、ローカルミラーへのパスが分かります。

マネージドクラスターのコマンドラインを使用して、次のコマンドを実行してデフォルトのレジストリーをオーバーライドします。
```
oc apply -f mirror.yaml
```
```
oc apply -f mirror.yaml
```
Copy to Clipboard Toggle word wrap

1.5.9.2.8. オフラインカタログソースのデプロイ
リンクのコピー

マネージドクラスターで、デフォルトのカタログソースをすべて無効にし、新しいカタログソースを作成します。デフォルトの場所を接続された場所からオフラインローカルレジストリーに変更するには、次の手順を実行します。

次の内容のような、source.yaml という名前の YAML ファイルを作成します。

apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true

---
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: my-operator-catalog
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: '<registry_host_name>:<port>/olm/redhat-operators:v1'
  displayName: My Operator Catalog
  publisher: grpc

apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true

---
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: my-operator-catalog
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: '<registry_host_name>:<port>/olm/redhat-operators:v1'


  displayName: My Operator Catalog
  publisher: grpc

Copy to Clipboard

Toggle word wrap

1: spec.image の値を、ローカルの制約付きカタログソースイメージへのパスに置き換えます。

マネージドクラスターのコマンドラインで、次のコマンドを実行してカタログソースを変更します。
```
oc apply -f source.yaml
```
```
oc apply -f source.yaml
```
Copy to Clipboard Toggle word wrap

1.5.9.2.9. マネージドクラスターのパラメーターを変更する
リンクのコピー

マネージドクラスターの ClusterVersion リソース情報を更新して、アップグレードを取得するデフォルトの場所を変更します。

マネージドクラスターから、以下のコマンドを入力して ClusterVersion アップストリームパラメーターがデフォルトの OpenShift Update Service オペランドであることを確認します。

oc get clusterversion -o yaml

oc get clusterversion -o yaml

Copy to Clipboard

Toggle word wrap

返される内容は以下のようになります。

apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.13
    upstream: https://api.openshift.com/api/upgrades_info/v1/graph

apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.13
    upstream: https://api.openshift.com/api/upgrades_info/v1/graph

Copy to Clipboard

Toggle word wrap

ハブクラスターから、次のコマンドを入力して、OpenShift Update Service オペランドへのルート URL を特定します。
```
oc get routes
```
```
oc get routes
```
Copy to Clipboard Toggle word wrap
後のステップのために戻り値に注意してください。
マネージドクラスターのコマンドラインで、次のコマンドを入力して ClusterVersion リソースを編集します。
```
oc edit clusterversion version
```
```
oc edit clusterversion version
```
Copy to Clipboard Toggle word wrap
spec.channel の値を新しいバージョンに置き換えます。
spec.upstream の値は、ハブクラスター OpenShift Update Service オペランドへのパスに置き換えます。次の手順を実行して、オペランドへのパスを決定できます。
1. ハブクラスターで以下のコマンドを実行してください。
  oc get routes -A
  Copy to Clipboard Toggle word wrap
2. cincinnati へのパスを見つけます。オペランドのパスは、HOST/PORT フィールドの値です。

マネージドクラスターのコマンドラインで、次のコマンドを入力して、ClusterVersion のアップストリームパラメーターがローカルハブクラスターの OpenShift Update Service URL で更新されていることを確認します。

oc get clusterversion -o yaml

oc get clusterversion -o yaml

Copy to Clipboard

Toggle word wrap

結果は次のような内容になります。

apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.13
    upstream: https://<hub-cincinnati-uri>/api/upgrades_info/v1/graph

apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.13
    upstream: https://<hub-cincinnati-uri>/api/upgrades_info/v1/graph

Copy to Clipboard

Toggle word wrap

1.5.9.2.10. 利用可能なアップグレードの表示
リンクのコピー

Cluster ページでは、オフラインレジストリーにアップグレードがある場合、クラスターの Distribution version に、利用可能なアップグレードがあることが示されます。クラスターを選択し、Actions メニューから Upgrade clusters を選択すると、利用可能なアップグレードを表示できます。オプションのアップグレードパスが利用可能な場合は、利用可能なアップグレードがリストされます。

注記: 現行バージョンがローカルのイメージリポジトリーにミラーリングされていないと、利用可能なアップグレードバージョンは表示されません。

1.5.9.2.11. チャネルの選択
リンクのコピー

コンソールを使用して、OpenShift Container Platform バージョン 4.6 以降でクラスターをアップグレードするためのチャネルを選択できます。これらのバージョンはミラーレジストリーで利用可能である必要があります。チャネルの選択の手順を実行して、アップグレードチャネルを指定します。

1.5.9.2.12. クラスターのアップグレード
リンクのコピー

非接続レジストリーを設定すると、multicluster engine Operator と OpenShift Update Service が非接続レジストリーを使用して、アップグレードが利用可能かどうかを判断します。利用可能なアップグレードが表示されない場合は、クラスターの現行のリリースイメージと、1 つ後のイメージがローカルリポジトリーにミラーリングされていることを確認します。クラスターの現行バージョンのリリースイメージが利用できないと、アップグレードは利用できません。

Cluster ページでは、オフラインレジストリーにアップグレードがある場合、クラスターの Distribution version に、利用可能なアップグレードがあることが示されます。イメージをアップグレードするには、Upgrade available をクリックし、アップグレードするバージョンを選択します。

マネージドクラスターは、選択したバージョンに更新されます。

1.5.10. クラスタープロキシーアドオンの使用
リンクのコピー

一部の環境では、マネージドクラスターはファイアウォールの背後にあり、ハブクラスターから直接アクセスすることはできません。アクセスを取得するには、プロキシーアドオンを設定してマネージドクラスターの kube-apiserver にアクセスし、よりセキュアな接続を提供できます。

重要: ハブクラスター上にクラスター全体のプロキシー設定を配置しないようにしてください。

必要なアクセス権限: 編集

ハブクラスターとマネージドクラスターのクラスタープロキシーアドオンを設定するには、次の手順を実行します。

次の手順を実行してマネージドクラスター kube-apiserver にアクセスするように kubeconfig ファイルを設定します。

マネージドクラスターに有効なアクセストークンを指定します。
注記: サービスアカウントの対応するトークンを使用できます。デフォルトの namespace にあるデフォルトのサービスアカウントを使用することもできます。
1. 次のコマンドを実行して、マネージドクラスターの kubeconfig ファイルをエクスポートします。
  export KUBECONFIG=<managed-cluster-kubeconfig>
  Copy to Clipboard Toggle word wrap
2. 次のコマンドを実行して、Pod へのアクセス権があるロールをサービスアカウントに追加します。
  oc create role -n default test-role --verb=list,get --resource=pods oc create rolebinding -n default test-rolebinding --serviceaccount=default:default --role=test-role
  Copy to Clipboard Toggle word wrap
3. 次のコマンドを実行して、サービスアカウントトークンのシークレットを見つけます。
  oc get secret -n default | grep <default-token>
  Copy to Clipboard Toggle word wrap
  default-token は、シークレット名に置き換えます。
4. 次のコマンドを実行して、トークンをコピーします。
  export MANAGED_CLUSTER_TOKEN=$(kubectl -n default get secret <default-token> -o jsonpath={.data.token} | base64 -d)
  Copy to Clipboard Toggle word wrap
  default-token は、シークレット名に置き換えます。

Red Hat Advanced Cluster Management ハブクラスターで kubeconfig ファイルを設定します。

次のコマンドを実行して、ハブクラスター上の現在の kubeconfig ファイルをエクスポートします。
```
oc config view --minify --raw=true > cluster-proxy.kubeconfig
```
```
oc config view --minify --raw=true > cluster-proxy.kubeconfig
```
Copy to Clipboard Toggle word wrap

エディターで server ファイルを変更します。この例では、sed の使用時にコマンドを使用します。OSX を使用している場合は、alias sed=gsed を実行します。

export TARGET_MANAGED_CLUSTER=<managed-cluster-name>

export NEW_SERVER=https://$(oc get route -n multicluster-engine cluster-proxy-addon-user -o=jsonpath='{.spec.host}')/$TARGET_MANAGED_CLUSTER

sed -i'' -e '/server:/c\    server: '"$NEW_SERVER"'' cluster-proxy.kubeconfig

export CADATA=$(oc get configmap -n openshift-service-ca kube-root-ca.crt -o=go-template='{{index .data "ca.crt"}}' | base64)

sed -i'' -e '/certificate-authority-data:/c\    certificate-authority-data: '"$CADATA"'' cluster-proxy.kubeconfig

export TARGET_MANAGED_CLUSTER=<managed-cluster-name>

export NEW_SERVER=https://$(oc get route -n multicluster-engine cluster-proxy-addon-user -o=jsonpath='{.spec.host}')/$TARGET_MANAGED_CLUSTER

sed -i'' -e '/server:/c\    server: '"$NEW_SERVER"'' cluster-proxy.kubeconfig

export CADATA=$(oc get configmap -n openshift-service-ca kube-root-ca.crt -o=go-template='{{index .data "ca.crt"}}' | base64)

sed -i'' -e '/certificate-authority-data:/c\    certificate-authority-data: '"$CADATA"'' cluster-proxy.kubeconfig

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、元のユーザー認証情報を削除します。

sed -i'' -e '/client-certificate-data/d' cluster-proxy.kubeconfig
sed -i'' -e '/client-key-data/d' cluster-proxy.kubeconfig
sed -i'' -e '/token/d' cluster-proxy.kubeconfig

sed -i'' -e '/client-certificate-data/d' cluster-proxy.kubeconfig
sed -i'' -e '/client-key-data/d' cluster-proxy.kubeconfig
sed -i'' -e '/token/d' cluster-proxy.kubeconfig

Copy to Clipboard

Toggle word wrap

サービスアカウントのトークンを追加します。

sed -i'' -e '$a\    token: '"$MANAGED_CLUSTER_TOKEN"'' cluster-proxy.kubeconfig

sed -i'' -e '$a\    token: '"$MANAGED_CLUSTER_TOKEN"'' cluster-proxy.kubeconfig

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、ターゲットマネージドクラスターのターゲット namespace にあるすべての Pod をリスト表示します。
```
oc get pods --kubeconfig=cluster-proxy.kubeconfig -n <default>
```
```
oc get pods --kubeconfig=cluster-proxy.kubeconfig -n <default>
```
Copy to Clipboard Toggle word wrap
default namespace は、使用する namespace に置き換えます。
マネージドクラスター上の他のサービスにアクセスします。この機能は、マネージドクラスターが Red Hat OpenShift Container Platform クラスターの場合に利用できます。サービスは service-serving-certificate を使用してサーバー証明書を生成する必要があります。
- マネージドクラスターから、以下のサービスアカウントトークンを使用します。
  export PROMETHEUS_TOKEN=$(kubectl get secret -n openshift-monitoring $(kubectl get serviceaccount -n openshift-monitoring prometheus-k8s -o=jsonpath='{.secrets[0].name}') -o=jsonpath='{.data.token}' | base64 -d)
  Copy to Clipboard Toggle word wrap
- ハブクラスターから、以下のコマンドを実行して認証局をファイルに変換します。
  oc get configmap kube-root-ca.crt -o=jsonpath='{.data.ca\.crt}' > hub-ca.crt
  Copy to Clipboard Toggle word wrap

以下のコマンドを使用して、マネージドクラスターの Prometheus メトリックを取得します。

export SERVICE_NAMESPACE=openshift-monitoring
export SERVICE_NAME=prometheus-k8s
export SERVICE_PORT=9091
export SERVICE_PATH="api/v1/query?query=machine_cpu_sockets"
curl --cacert hub-ca.crt $NEW_SERVER/api/v1/namespaces/$SERVICE_NAMESPACE/services/$SERVICE_NAME:$SERVICE_PORT/proxy-service/$SERVICE_PATH -H "Authorization: Bearer $PROMETHEUS_TOKEN"

export SERVICE_NAMESPACE=openshift-monitoring
export SERVICE_NAME=prometheus-k8s
export SERVICE_PORT=9091
export SERVICE_PATH="api/v1/query?query=machine_cpu_sockets"
curl --cacert hub-ca.crt $NEW_SERVER/api/v1/namespaces/$SERVICE_NAMESPACE/services/$SERVICE_NAME:$SERVICE_PORT/proxy-service/$SERVICE_PATH -H "Authorization: Bearer $PROMETHEUS_TOKEN"

Copy to Clipboard

Toggle word wrap

1.5.10.1. クラスタープロキシーアドオンのプロキシー設定
リンクのコピー

マネージドクラスターが HTTP および HTTPS プロキシーサーバー経由でハブクラスターと通信できるように、クラスタープロキシーアドオンのプロキシー設定を指定できます。クラスタープロキシーアドオンエージェントがプロキシーサーバー経由でハブクラスターにアクセスする必要がある場合は、プロキシー設定が必要な可能性があります。

クラスタープロキシーアドオンのプロキシー設定を指定するには、次の手順を実行します。

ハブクラスターに AddOnDeploymentConfig リソースを作成し、spec.proxyConfig パラメーターを追加します。以下の例を参照してください。
```
apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: <name> 
  namespace: <namespace> 
spec:
  agentInstallNamespace: open-cluster-managment-agent-addon
  proxyConfig:
    httpsProxy: "http://<username>:<password>@<ip>:<port>" 
    noProxy: ".cluster.local,.svc,172.30.0.1" 
    caBundle: <value> 
```
```
apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: <name> 
```
1
```
  namespace: <namespace> 
```
2
```
spec:
  agentInstallNamespace: open-cluster-managment-agent-addon
  proxyConfig:
    httpsProxy: "http://<username>:<password>@<ip>:<port>" 
```
3
```
    noProxy: ".cluster.local,.svc,172.30.0.1" 
```
4
```
    caBundle: <value> 
```
5
Copy to Clipboard Toggle word wrap
1
アドオンのデプロイメント設定名を追加します。
2
マネージドクラスター名を追加します。
3
HTTP プロキシーまたは HTTPS プロキシーのいずれかを指定します。
4
kube-apiserver の IP アドレスを追加します。IP アドレスを取得するには、マネージドクラスターで oc -n default describe svc kubernetes | grep IP: コマンドを実行します。
5
httpsProxy フィールドで HTTPS プロキシーを指定する場合は、プロキシーサーバー CA バンドルを設定します。

作成した AddOnDeploymentConfig リソースを参照して、ManagedClusterAddOn リソースを更新します。以下の例を参照してください。

apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  name: cluster-proxy
  namespace: <namespace> 
spec:
installNamespace: open-cluster-managment-addon
configs:
  group: addon.open-cluster-management.io
  resource: AddonDeploymentConfig
  name: <name> 
  namespace: <namespace>

apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  name: cluster-proxy
  namespace: <namespace>


spec:
installNamespace: open-cluster-managment-addon
configs:
  group: addon.open-cluster-management.io
  resource: AddonDeploymentConfig
  name: <name>


  namespace: <namespace>

Copy to Clipboard

Toggle word wrap

マネージドクラスター名を追加します。

アドオンのデプロイメント設定名を追加します。

マネージドクラスター名を追加します。

open-cluster-managment-addon namespace 内のクラスタープロキシーエージェント Pod に、マネージドクラスターの HTTPS_PROXY または NO_PROXY 環境変数があるかどうかを確認して、プロキシー設定を確認します。

1.5.11. マネージドクラスターで実行する Ansible Automation Platform タスクの設定
リンクのコピー

multicluster engine Operator は Red Hat Ansible Automation Platform と統合されているため、クラスターの作成またはアップグレードの前後に実行される prehook および posthook Ansible ジョブインスタンスを作成できます。クラスター破棄の prehook および posthook ジョブの設定やクラスターのスケールアクションはサポートされません。

必要なアクセス権: クラスター管理者

前提条件
コンソールを使用して、クラスターで実行するように、自動化テンプレートを設定する
自動化テンプレートの作成
Ansible ジョブのステータスの表示

1.5.11.1. 前提条件
リンクのコピー

クラスターで自動化テンプレートを実行するには、次の前提条件を満たす必要があります。

OpenShift Container Platform 4.13 以降
Ansible Automation Platform Resource Operator をインストールして、Ansible ジョブを Git サブスクリプションのライフサイクルに接続している。自動化テンプレートを使用して Ansible Automation Platform ジョブを起動する場合に最良の結果を得るには、Ansible Automation Platform ジョブテンプレートを実行時にべき等にする必要があります。Ansible Automation Platform Resource Operator は、OpenShift Container Platform OperatorHub ページから検索できます。

1.5.11.2. コンソールを使用して、クラスターで実行するように、自動化テンプレートを設定する
リンクのコピー

クラスターの作成時、クラスターのインポート時、またはクラスターの作成後、クラスターに使用する自動化テンプレートを指定できます。

クラスターの作成時またはインポート時にテンプレートを指定するには、Automation の手順でクラスターに適用する Ansible テンプレートを選択します。自動化テンプレートがない場合は、Add automation template をクリックして作成します。

クラスターの作成後にテンプレートを指定するには、既存のクラスターのアクションメニューで Update automation template をクリックします。Update automation template オプションを使用して、既存の自動化テンプレートを更新することもできます。

1.5.11.3. 自動化テンプレートの作成
リンクのコピー

クラスターのインストールまたはアップグレードで Ansible ジョブを開始するには、自動化テンプレートを作成して、いつジョブを実行するかを指定する必要があります。これらは、クラスターのインストールまたはアップグレード前後に実行するように設定できます。

テンプレートの作成時に Ansible テンプレートの実行に関する詳細を指定するには、コンソールで以下の手順を実行します。

ナビゲーションから Infrastructure > Automation を選択します。
状況に適したパスを選択します。
- 新規テンプレートを作成する場合には、Create Ansible template をクリックして手順 3 に進みます。
- 既存のテンプレートを変更する場合は、変更するテンプレートの Options メニューの Edit template をクリックして、手順 5 に進みます。
一意のテンプレート名を入力します。名前には小文字の英数字またはハイフン (-) を指定してください。
新規テンプレートの認証情報を選択します。
認証情報を選択した後、すべてのジョブに使用する Ansible インベントリーを選択できます。Ansible 認証情報を Ansible テンプレートにリンクするには、以下の手順を実行します。
1. ナビゲーションから Automation を選択します。認証情報にリンクされていないテンプレートの一覧内のテンプレートには、テンプレートを既存の認証情報にリンクするために使用できるリンク 認証情報へのリンク アイコンが含まれています。テンプレートと同じ namespace の認証情報のみが表示されます。
2. 選択できる認証情報がない場合や、既存の認証情報を使用しない場合は、リンクするテンプレートの Options メニューから Edit template を選択します。
3. 認証情報を作成する場合は、Add credential をクリックして、Ansible Automation Platform の認証情報の作成の手順を行います。
4. テンプレートと同じ namespace に認証情報を作成したら、テンプレートの編集時に Ansible Automation Platform credential フィールドで認証情報を選択します。
クラスターをインストールする前に、Ansible ジョブを開始する場合は、Pre-install Automation templates セクションの Add an Automation template を選択します。
表示されるモーダルで Job template または Workflow job template を選択します。job_tags、Skip_tags、およびワークフロータイプを追加することもできます。
- Extra variables フィールドを使用して、キー=値 ペアの形式でデータを AnsibleJob リソースに渡します。
- 特殊キーの cluster_deployment と install_config は、追加の変数として自動的に渡されます。こちらには、クラスターに関する一般情報とクラスターのインストール設定に関する詳細が含まれています。
クラスターのインストールまたはアップグレードに追加するプリフックおよびポストフックの Ansible ジョブの名前を選択します。
必要に応じて、Ansible ジョブをドラッグして、順番を変更します。
インストール後の自動化テンプレート セクション、アップグレード前の自動化テンプレート セクション、および アップグレード後の自動化テンプレート セクションでクラスターのインストール後に開始するすべての自動化テンプレートに手順 5 〜 7 を繰り返します。クラスターをアップグレードする場合、Extra variables フィールドを使用して、key=value ペアの形式で AnsibleJob リソースにデータを渡すことができます。cluster_deployment 特殊キーおよび install_config 特殊キーに加えて、cluster_info 特殊キーも、ManagedClusterInfo リソースからのデータを含む追加変数として自動的に渡されます。

Ansible テンプレートは、指定のアクションが起こるタイミングで、このテンプレートを指定するクラスターで実行するように設定されます。

1.5.11.4. Ansible ジョブのステータスの表示
リンクのコピー

実行中の Ansible ジョブのステータスを表示して、起動し、正常に実行されていることを確認できます。実行中の Ansible ジョブの現在のステータスを表示するには、以下の手順を実行します。

メニューで、Infrastructure > Clusters を選択して、Clusters ページにアクセスします。
クラスターの名前を選択して、その詳細を表示します。
クラスター情報で Ansible ジョブの最後の実行ステータスを表示します。エントリーには、以下のステータスの 1 つが表示されます。
- インストール prehook または posthook ジョブが失敗すると、クラスターのステータスは Failed と表示されます。
- アップグレード prehook または posthook ジョブが失敗すると、アップグレードに失敗した Distribution フィールドに警告が表示されます。

1.5.11.5. 失敗した Ansible ジョブを再度実行する
リンクのコピー

クラスターの prehook または posthook が失敗した場合は、Clusters ページからアップグレードを再試行できます。

時間を節約するために、クラスター自動化テンプレートの一部である失敗した Ansible ポストフックのみを実行できるようになりました。アップグレード全体を再試行せずに、ポストフックのみを再度実行するには、次の手順を実行します。

次のコンテンツを ClusterCurator リソースのルートに追加して、インストールポストフックを再度実行します。
```
operation:
  retryPosthook: installPosthook
```
```
operation:
  retryPosthook: installPosthook
```
Copy to Clipboard Toggle word wrap
次のコンテンツを ClusterCurator リソースのルートに追加して、アップグレードポストフックを再度実行します。
```
operation:
  retryPosthook: upgradePosthook
```
```
operation:
  retryPosthook: upgradePosthook
```
Copy to Clipboard Toggle word wrap

コンテンツを追加すると、Ansible ポストフックを実行するための新しいジョブが作成されます。

1.5.11.6. すべてのジョブに使用する Ansible インベントリーの指定
リンクのコピー

ClusterCurator リソースを使用して、すべてのジョブに使用する Ansible インベントリーを指定できます。以下の例を参照してください。channel と desiredUpdate を ClusterCurator の正しい値に置き換えます。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: test-inno
  namespace: test-inno
spec:
  desiredCuration: upgrade
  destroy: {}
  install: {}
  scale: {}
  upgrade:
    channel: stable-4.13
    desiredUpdate: 4.13.1
    monitorTimeout: 150
    posthook:
    - extra_vars: {}
      clusterName: test-inno
      type: post_check
      name: ACM Upgrade Checks
    prehook:
    - extra_vars: {}
      clusterName: test-inno
      type: pre_check
      name: ACM Upgrade Checks
    towerAuthSecret: awx
    inventory: Demo Inventory

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: test-inno
  namespace: test-inno
spec:
  desiredCuration: upgrade
  destroy: {}
  install: {}
  scale: {}
  upgrade:
    channel: stable-4.13
    desiredUpdate: 4.13.1
    monitorTimeout: 150
    posthook:
    - extra_vars: {}
      clusterName: test-inno
      type: post_check
      name: ACM Upgrade Checks
    prehook:
    - extra_vars: {}
      clusterName: test-inno
      type: pre_check
      name: ACM Upgrade Checks
    towerAuthSecret: awx
    inventory: Demo Inventory

Copy to Clipboard

Toggle word wrap

注記: サンプルリソースを使用するには、インベントリーが Ansible にすでに存在している必要があります。

コンソールから利用可能な Ansible インベントリーのリストを確認すると、インベントリーが作成されていることを確認できます。

1.5.12. Ansible Automation Platform ジョブをホステッドクラスター上で実行されるように設定
リンクのコピー

Red Hat Ansible Automation Platform は multicluster engine Operator と統合されているため、ホステッドクラスターの作成または更新の前後に実行される prehook および posthook Ansible Automation Platform ジョブインスタンスを作成できます。

必要なアクセス権: クラスター管理者

前提条件
Ansible Automation Platform ジョブを実行してホステッドクラスターをインストールする
Ansible Automation Platform ジョブを実行してホステッドクラスターを更新する
Ansible Automation Platform ジョブを実行してホステッドクラスターを削除する

1.5.12.1. 前提条件
リンクのコピー

クラスターで自動化テンプレートを実行するには、次の前提条件を満たす必要があります。

OpenShift Container Platform 4.14 以降
Ansible Automation Platform Resource Operator をインストールして、Ansible Automation Platform ジョブを Git サブスクリプションのライフサイクルに接続する。Automation テンプレートを使用して Ansible Automation Platform ジョブを開始する場合は、実行時に Ansible Automation Platform ジョブテンプレートが冪等である。Ansible Automation Platform Resource Operator は、OpenShift Container Platform OperatorHub ページから検索できます。

1.5.12.2. Ansible Automation Platform ジョブを実行してホステッドクラスターをインストールする
リンクのコピー

ホステッドクラスターをインストールする Ansible Automation Platform ジョブを開始するには、次の手順を実行します。

pausedUntil: true フィールドを含む HostedCluster および NodePool リソースを作成します。hcp create cluster コマンドラインインターフェイスコマンドを使用する場合は、--pausedUntil: true フラグを指定できます。

以下の例を参照してください。

apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  name: my-cluster
  namespace: clusters
spec:
  pausedUntil: 'true'
...

apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  name: my-cluster
  namespace: clusters
spec:
  pausedUntil: 'true'
...

Copy to Clipboard

Toggle word wrap

apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  name: my-cluster-us-east-2
  namespace: clusters
spec:
  pausedUntil: 'true'
...

apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  name: my-cluster-us-east-2
  namespace: clusters
spec:
  pausedUntil: 'true'
...

Copy to Clipboard

Toggle word wrap

HostedCluster リソースと同じ名前と HostedCluster リソースと同じ namespace で、ClusterCurator リソースを作成します。以下の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: install
  install:
    jobMonitorTimeout: 5
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: install
  install:
    jobMonitorTimeout: 5
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess

Copy to Clipboard

Toggle word wrap

Ansible Automation Platform Tower で認証が必要な場合は、シークレットリソースを作成します。以下の例を参照してください。

apiVersion: v1
kind: Secret
metadata:
  name: toweraccess
  namespace: clusters
stringData:
  host: https://my-tower-domain.io
  token: ANSIBLE_TOKEN_FOR_admin

apiVersion: v1
kind: Secret
metadata:
  name: toweraccess
  namespace: clusters
stringData:
  host: https://my-tower-domain.io
  token: ANSIBLE_TOKEN_FOR_admin

Copy to Clipboard

Toggle word wrap

1.5.12.3. Ansible Automation Platform ジョブを実行してホステッドクラスターを更新する
リンクのコピー

ホステッドクラスターを更新する Ansible Automation Platform ジョブを実行するには、更新するホステッドクラスターの ClusterCurator リソースを編集します。以下の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: upgrade
  upgrade:
    desiredUpdate: 4.14.1 
    monitorTimeout: 120
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: upgrade
  upgrade:
    desiredUpdate: 4.14.1


    monitorTimeout: 120
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess

Copy to Clipboard

Toggle word wrap

1: サポート対象バージョンの詳細は、Hosted Control Plane を参照してください。

注: この方法でホステッドクラスターを更新すると、Hosted Control Plane とノードプールの両方が同じバージョンに更新されます。Hosted Control Plane とノードプールを別のバージョンに更新することはサポートされていません。

1.5.12.4. Ansible Automation Platform ジョブを実行してホステッドクラスターを削除する
リンクのコピー

ホステッドクラスターを削除する Ansible Automation Platform ジョブを実行するには、削除するホステッドクラスターの ClusterCurator リソースを編集します。以下の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: destroy
  destroy:
    jobMonitorTimeout: 5
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: destroy
  destroy:
    jobMonitorTimeout: 5
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess

Copy to Clipboard

Toggle word wrap

注記: AWS 上のホステッドクラスターの削除はサポートされていません。

1.5.12.5. 関連情報
リンクのコピー

Hosted Control Plane コマンドラインインターフェイス (hcp) の詳細は、Hosted Control Plane コマンドラインインターフェイスのインストールを参照してください。
サポートされているバージョンなど、ホステッドクラスターの詳細は、Hosted Control Plane を参照してください。

1.5.13. ClusterClaims
リンクのコピー

ClusterClaim は、マネージドクラスター上のカスタムリソース定義 (CRD) です。ClusterClaim は、マネージドクラスターが要求する情報の一部を表します。ClusterClaim を使用して、ターゲットクラスターでのリソースの Placement を解除できます。

以下の例は、YAML ファイルで特定された ClusterClaim を示しています。

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ClusterClaim
metadata:
  name: id.openshift.io
spec:
  value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ClusterClaim
metadata:
  name: id.openshift.io
spec:
  value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c

Copy to Clipboard

Toggle word wrap

次の表は、マルチクラスターエンジン Operator が管理するクラスターにある可能性がある定義済みの ClusterClaim を示しています。

Expand

要求名	予約	変更可能	説明
`id.k8s.io`	true	false	アップストリームの提案で定義された ClusterID
`kubeversion.open-cluster-management.io`	true	true	Kubernetes バージョン
`platform.open-cluster-management.io`	true	false	AWS、GCE、Equinix Metal など、マネージドクラスターが稼働しているプラットフォーム
`product.open-cluster-management.io`	true	false	OpenShift、Anthos、EKS、および GKE などの製品名
`id.openshift.io`	false	false	OpenShift Container Platform クラスターでのみ利用できる OpenShift Container Platform 外部 ID
`consoleurl.openshift.io`	false	true	OpenShift Container Platform クラスターでのみ利用できる管理コンソールの URL
`version.openshift.io`	false	true	OpenShift Container Platform クラスターでのみ利用できる OpenShift Container Platform バージョン

マネージドクラスターで以前の要求が削除されるか、更新されると、自動的に復元またはロールバックされます。

マネージドクラスターがハブに参加すると、マネージドクラスターで作成された ClusterClaim は、ハブの ManagedCluster リソースのステータスと同期されます。ClusterClaims のマネージドクラスターは、以下の例のようになります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  labels:
    cloud: Amazon
    clusterID: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
    installer.name: multiclusterhub
    installer.namespace: open-cluster-management
    name: cluster1
    vendor: OpenShift
  name: cluster1
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
status:
  allocatable:
    cpu: '15'
    memory: 65257Mi
  capacity:
    cpu: '18'
    memory: 72001Mi
  clusterClaims:
    - name: id.k8s.io
      value: cluster1
    - name: kubeversion.open-cluster-management.io
      value: v1.18.3+6c42de8
    - name: platform.open-cluster-management.io
      value: AWS
    - name: product.open-cluster-management.io
      value: OpenShift
    - name: id.openshift.io
      value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
    - name: consoleurl.openshift.io
      value: 'https://console-openshift-console.apps.xxxx.dev04.red-chesterfield.com'
    - name: version.openshift.io
      value: '4.13'
  conditions:
    - lastTransitionTime: '2020-10-26T07:08:49Z'
      message: Accepted by hub cluster admin
      reason: HubClusterAdminAccepted
      status: 'True'
      type: HubAcceptedManagedCluster
    - lastTransitionTime: '2020-10-26T07:09:18Z'
      message: Managed cluster joined
      reason: ManagedClusterJoined
      status: 'True'
      type: ManagedClusterJoined
    - lastTransitionTime: '2020-10-30T07:20:20Z'
      message: Managed cluster is available
      reason: ManagedClusterAvailable
      status: 'True'
      type: ManagedClusterConditionAvailable
  version:
    kubernetes: v1.18.3+6c42de8

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  labels:
    cloud: Amazon
    clusterID: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
    installer.name: multiclusterhub
    installer.namespace: open-cluster-management
    name: cluster1
    vendor: OpenShift
  name: cluster1
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
status:
  allocatable:
    cpu: '15'
    memory: 65257Mi
  capacity:
    cpu: '18'
    memory: 72001Mi
  clusterClaims:
    - name: id.k8s.io
      value: cluster1
    - name: kubeversion.open-cluster-management.io
      value: v1.18.3+6c42de8
    - name: platform.open-cluster-management.io
      value: AWS
    - name: product.open-cluster-management.io
      value: OpenShift
    - name: id.openshift.io
      value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
    - name: consoleurl.openshift.io
      value: 'https://console-openshift-console.apps.xxxx.dev04.red-chesterfield.com'
    - name: version.openshift.io
      value: '4.13'
  conditions:
    - lastTransitionTime: '2020-10-26T07:08:49Z'
      message: Accepted by hub cluster admin
      reason: HubClusterAdminAccepted
      status: 'True'
      type: HubAcceptedManagedCluster
    - lastTransitionTime: '2020-10-26T07:09:18Z'
      message: Managed cluster joined
      reason: ManagedClusterJoined
      status: 'True'
      type: ManagedClusterJoined
    - lastTransitionTime: '2020-10-30T07:20:20Z'
      message: Managed cluster is available
      reason: ManagedClusterAvailable
      status: 'True'
      type: ManagedClusterConditionAvailable
  version:
    kubernetes: v1.18.3+6c42de8

Copy to Clipboard

Toggle word wrap

1.5.13.1. 既存の ClusterClaim の表示
リンクのコピー

kubectl コマンドを使用して、マネージドクラスターに適用される ClusterClaim をリスト表示できます。これは、ClusterClaim をエラーメッセージと比較する場合に便利です。

注記: clusterclaims.cluster.open-cluster-management.io のリソースに list の権限があることを確認します。

以下のコマンドを実行して、マネージドクラスターにある既存の ClusterClaim のリストを表示します。

kubectl get clusterclaims.cluster.open-cluster-management.io

kubectl get clusterclaims.cluster.open-cluster-management.io

Copy to Clipboard

Toggle word wrap

1.5.13.2. カスタム ClusterClaims の作成
リンクのコピー

ClusterClaim は、マネージドクラスターでカスタム名を使用して作成できるため、簡単に識別できます。カスタム ClusterClaim は、ハブクラスターの ManagedCluster リソースのステータスと同期されます。以下のコンテンツでは、カスタマイズされた ClusterClaim の定義例を示しています。

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ClusterClaim
metadata:
  name: <custom_claim_name>
spec:
  value: <custom_claim_value>

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ClusterClaim
metadata:
  name: <custom_claim_name>
spec:
  value: <custom_claim_value>

Copy to Clipboard

Toggle word wrap

spec.value フィールドの最大長は 1024 です。ClusterClaim を作成するには clusterclaims.cluster.open-cluster-management.io リソースの create 権限が必要です。

1.5.14. ManagedClusterSets
リンクのコピー

ManagedClusterSet は、マネージドクラスターのグループです。マネージドクラスターセット。すべてのマネージドクラスターへのアクセスを管理するのに役立ちます。ManagedClusterSetBinding リソースを作成して ManagedClusterSet リソースを namespace にバインドすることもできます。

各クラスターは、マネージドクラスターセットのメンバーである必要があります。ハブクラスターをインストールすると、default という名前の ManagedClusterSet リソースが作成されます。マネージドクラスターセットに割り当てられていないすべてのクラスターは、default マネージドクラスターセットに自動的に割り当てられます。default マネージドクラスターセットを削除または更新することはできません。

マネージドクラスターセットの作成および管理方法の詳細は、以下を参照してください。

ManagedClusterSet の作成
ManagedClusterSets への RBAC 権限の割り当て
ManagedClusterSetBinding リソースの作成
ManagedClusterSet からのクラスターの削除

1.5.14.1. ManagedClusterSet の作成
リンクのコピー

マネージドクラスターセットにマネージドクラスターをグループ化して、マネージドクラスターでのユーザーのアクセス権限を制限できます。

必要なアクセス権: クラスター管理者

ManagedClusterSet は、クラスタースコープのリソースであるため、ManagedClusterSet の作成先となるクラスターで管理者権限が必要です。マネージドクラスターは、複数の ManagedClusterSet に追加できません。マネージドクラスターセットは、multicluster engine Operator コンソールまたは CLI から作成できます。

注記: マネージドクラスターセットに追加されていないクラスタープールは、デフォルトの ManagedClusterSet リソースに追加されません。クラスターがクラスタープールから要求されると、クラスターはデフォルトの ManagedClusterSet に追加されます。

マネージドクラスターを作成すると、管理を容易にするために次のものが自動的に作成されます。

global と呼ばれる ManagedClusterSet。
open-cluster-management-global-set という namespace。
global と呼ばれる ManagedClusterSetBinding は、global ManagedClusterSet を open-cluster-management-global-set namespace にバインドします。
重要: global マネージドクラスターセットを削除、更新、または編集することはできません。global マネージドクラスターセットには、すべてのマネージドクラスターが含まれます。以下の例を参照してください。
```
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  name: global
  namespace: open-cluster-management-global-set
spec:
  clusterSet: global
```
```
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  name: global
  namespace: open-cluster-management-global-set
spec:
  clusterSet: global
```
Copy to Clipboard Toggle word wrap

1.5.14.1.1. CLI を使用した ManagedClusterSet の作成
リンクのコピー

CLI を使用してマネージドクラスターセットの定義を YAML ファイルに追加し、マネージドクラスターセットを作成します。

apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: <cluster_set>

apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: <cluster_set>

Copy to Clipboard

Toggle word wrap

<cluster_set> をマネージドクラスターセットの名前に置き換えます。

1.5.14.1.2. クラスターの ManagedClusterSet への追加
リンクのコピー

ManagedClusterSet の作成後に、コンソールまたは CLI を使用してクラスターをマネージドクラスターセットに追加できます。

1.5.14.1.3. CLI を使用したクラスターの ManagedClusterSet への追加
リンクのコピー

CLI を使用してクラスターをマネージドクラスターに追加するには、以下の手順を実行します。

managedclustersets/join の仮想サブリソースに作成できるように、RBAC ClusterRole エントリーが追加されていることを確認します。
注記: この権限がないと、マネージドクラスターを ManagedClusterSet に割り当てることはできません。このエントリーが存在しない場合は、YAML ファイルに追加します。以下の例を参照してください。
```
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: clusterrole1
rules:
  - apiGroups: ["cluster.open-cluster-management.io"]
    resources: ["managedclustersets/join"]
    resourceNames: ["<cluster_set>"]
    verbs: ["create"]
```
```
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: clusterrole1
rules:
  - apiGroups: ["cluster.open-cluster-management.io"]
    resources: ["managedclustersets/join"]
    resourceNames: ["<cluster_set>"]
    verbs: ["create"]
```
Copy to Clipboard Toggle word wrap
<cluster_set> を ManagedClusterSet の名前に置き換えます。
注記: マネージドクラスターを別の ManagedClusterSet に移動する場合には、両方のマネージドクラスターセットで権限の設定が必要です。

YAML ファイルでマネージドクラスターの定義を検索します。以下の定義例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: <cluster_name>
spec:
  hubAcceptsClient: true

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: <cluster_name>
spec:
  hubAcceptsClient: true

Copy to Clipboard

Toggle word wrap

cluster.open-cluster-management.io/clusterset パラメーターを追加し、ManagedClusterSet の名前を指定します。以下の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: <cluster_name>
  labels:
    cluster.open-cluster-management.io/clusterset: <cluster_set>
spec:
  hubAcceptsClient: true

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: <cluster_name>
  labels:
    cluster.open-cluster-management.io/clusterset: <cluster_set>
spec:
  hubAcceptsClient: true

Copy to Clipboard

Toggle word wrap

1.5.14.2. ManagedClusterSet への RBAC 権限の割り当て
リンクのコピー

ハブクラスターに設定したアイデンティティープロバイダーが提供するクラスターセットに、ユーザーまたはグループを割り当てることができます。

必要なアクセス権: クラスター管理者

ManagedClusterSet API RBAC 権限レベルは、以下の表を参照してください。

Expand

クラスターセット	アクセス権限	権限の作成
`admin`	マネージドクラスターセットに割り当てられたすべてのクラスターおよびクラスタープールリソースへのフルアクセス権限。	クラスターの作成、クラスターのインポート、クラスタープールの作成権限。権限は、作成時にマネージドクラスターセットに割り当てる必要があります。
`bind`	`ManagedClusterSetBinding` を作成してクラスターセットを namespace にバインドするアクセス許可。ユーザーまたはグループには、ターゲット namespace で `ManagedClusterSetBinding` を作成する権限も必要です。マネージドクラスターセットに割り当てられた、すべてのクラスターおよびクラスタープールリソースに対する読み取り専用の権限。	クラスターの作成、クラスターのインポート、またはクラスタープールの作成を実行する権限なし。
`view`	マネージドクラスターセットに割り当てられたすべてのクラスターおよびクラスタープールリソースに対する読み取り専用権限。	クラスターの作成、クラスターのインポート、またはクラスタープールの作成を実行する権限なし。

注記: グローバルクラスターセットにクラスターセットの admin 権限を適用することはできません。

コンソールからマネージドクラスターセットにユーザーまたはグループを割り当てるには、次の手順を実行します。

OpenShift Container Platform コンソールから、Infrastructure > Clusters に移動します。
Cluster sets タブを選択します。
ターゲットクラスターセットを選択します。
Access management タブを選択します。
Add user or group を選択します。
アクセス権を割り当てるユーザーまたはグループを検索して選択します。
Cluster set admin または Cluster set view ロールを選択して、選択したユーザーまたはグループに付与します。詳細は、multicluster engine Operator のロールベースのアクセス制御の ロールの概要 を参照してください。
Add を選択して変更を送信します。

テーブルにユーザーまたはグループが表示されます。全マネージドクラスターセットリソースの権限の割り当てがユーザーまたはグループに伝播されるまでに数秒かかる場合があります。

placement 情報は、ManagedCusterSets からの ManagedClusters のフィルタリングを参照してください。

1.5.14.3. ManagedClusterSetBinding リソースの作成
リンクのコピー

ManagedClusterSetBinding リソースは、ManagedClusterSet リソースを namespace にバインドします。同じ namespace で作成されたアプリケーションおよびポリシーは、バインドされたマネージドクラスターセットリソースに含まれるクラスターにのみアクセスできます。

namespace へのアクセス権限は、その namespace にバインドされるマネージドクラスターセットに自動的に適用されます。その namespace へのアクセス権限を持つ場合、その namespace にバインドされるマネージドクラスターセットへのアクセス権限が自動的に付与されます。マネージドクラスターセットにアクセスする権限のみがある場合、namespace の他のマネージドクラスターセットにアクセスする権限は自動的に割り当てられません。

コンソールまたはコマンドラインを使用してマネージドクラスターセットバインドを作成できます。

1.5.14.3.1. コンソールを使用した ManagedClusterSetBinding の作成
リンクのコピー

コンソールを使用して ManagedClusterSetBinding を作成するには、以下の手順を実行します。

OpenShift Container Platform コンソールから、Infrastructure > Clusters に移動し、Cluster sets タブを選択します。
バインドを作成するクラスターセットの名前を選択します。
Actions > Edit namespace bindings に移動します。
Edit namespace bindings ページで、ドロップダウンメニューからクラスターセットをバインドする namespace を選択します。

1.5.14.3.2. CLI を使用した ManagedClusterSetBinding の作成
リンクのコピー

CLI を使用して ManagedClusterSetBinding を作成するには、以下の手順を実行します。

YAML ファイルに ManagedClusterSetBinding リソースを作成します。
注記: マネージドクラスターセットバインドを作成する場合、マネージドクラスターセットバインドの名前は、バインドするマネージドクラスターセットの名前と一致する必要があります。ManagedClusterSetBinding リソースは、以下の情報のようになります。
```
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  namespace: <namespace>
  name: <cluster_name>
spec:
  clusterSet: <cluster_set>
```
```
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  namespace: <namespace>
  name: <cluster_name>
spec:
  clusterSet: <cluster_set>
```
Copy to Clipboard Toggle word wrap

ターゲットのマネージドクラスターセットでのバインド権限を割り当てておく必要があります。次の ClusterRole リソースの例を表示します。これには、ユーザーが <cluster_set> にバインドすることを許可するルールが含まれています。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <clusterrole>
rules:
  - apiGroups: ["cluster.open-cluster-management.io"]
    resources: ["managedclustersets/bind"]
    resourceNames: ["<cluster_set>"]
    verbs: ["create"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <clusterrole>
rules:
  - apiGroups: ["cluster.open-cluster-management.io"]
    resources: ["managedclustersets/bind"]
    resourceNames: ["<cluster_set>"]
    verbs: ["create"]

Copy to Clipboard

Toggle word wrap

1.5.14.4. taint と toleration を使用したマネージドクラスターの配置
リンクのコピー

taint と toleration を使用して、マネージドクラスターまたはマネージドクラスターセットの placement を制御できます。taint と toleration は、特定の placement でマネージドクラスターが選択されないようにする方法を提供します。この制御は、特定のマネージドクラスターが一部の placement に含まれないようにする場合に役立ちます。taint をマネージドクラスターに、toleration を placement に追加できます。taint と toleration が一致しないと、マネージドクラスターはその placement に選択されません。

1.5.14.4.1. マネージドクラスターへの taint の追加
リンクのコピー

taint はマネージドクラスターのプロパティーで指定され、placement がマネージドクラスターまたはマネージドクラスターのセットを除外できます。以下の例のようなコマンドを入力して、taint をマネージドクラスターに追加できます。

oc taint ManagedCluster <managed_cluster_name> key=value:NoSelect

oc taint ManagedCluster <managed_cluster_name> key=value:NoSelect

Copy to Clipboard

Toggle word wrap

taint の仕様には以下のフィールドが含まれます。

(必須) Key: クラスターに適用される taint キー。この値は、その placement に追加される基準を満たすように、マネージドクラスターの toleration の値と一致させる必要があります。この値は確認できます。たとえば、この値は bar または foo.example.com/bar です。
(オプション) Value: taint キーの taint 値。この値は、その placement に追加される基準を満たすように、マネージドクラスターの toleration の値と一致させる必要があります。たとえば、この値は value とすることができます。
(必須) Effect: taint を許容しない placement における taint の効果、または placement の taint と toleration が一致しないときに何が起こるか。effect の値は、以下のいずれかの値である必要があります。
- NoSelect: placement は、この taint を許容しない限り、クラスターを選択できません。taint の設定前に placement でクラスターが選択された場合は、クラスターは placement の決定から削除されます。
- NoSelectIfNew: スケジューラーは、クラスターが新しい場合にそのクラスターを選択できません。プレイスメントは、taint を許容し、すでにクラスター決定にそのクラスターがある場合にのみ、そのクラスターを選択することができます。
(必須) TimeAdded: taint を追加した時間。この値は自動的に設定されます。

1.5.14.4.2. マネージドクラスターのステータスを反映させる組み込み taint の特定
リンクのコピー

マネージドクラスターにアクセスできない場合には、クラスターを placement に追加しないでください。以下の taint は、アクセスできないマネージドクラスターに自動的に追加されます。

cluster.open-cluster-management.io/unavailable: この taint は、ステータスが False の ManagedClusterConditionAvailable の条件がある場合にマネージドクラスターに追加されます。taint には NoSelect と同じ効果があり、空の値を指定すると、利用不可のクラスターがスケジュールされないようにできます。この taint の例は、以下の内容のようになります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
 name: cluster1
spec:
 hubAcceptsClient: true
 taints:
   - effect: NoSelect
     key: cluster.open-cluster-management.io/unavailable
     timeAdded: '2022-02-21T08:11:54Z'

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
 name: cluster1
spec:
 hubAcceptsClient: true
 taints:
   - effect: NoSelect
     key: cluster.open-cluster-management.io/unavailable
     timeAdded: '2022-02-21T08:11:54Z'

Copy to Clipboard

Toggle word wrap

cluster.open-cluster-management.io/unreachable - ManagedClusterConditionAvailable の条件のステータスが Unknown であるか、条件がない場合に、この taint はマネージドクラスターに追加されます。この taint には NoSelect と同じ効果があり、空の値を指定すると、到達不可のクラスターがスケジュールされないようにできます。この taint の例は、以下の内容のようになります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'

Copy to Clipboard

Toggle word wrap

1.5.14.4.3. toleration の placement への追加
リンクのコピー

toleration は placement に適用され、placement の toleration と taint が同じでないマネージドクラスターを placement から除外できます。toleration の仕様には以下のフィールドが含まれます。

(任意) Key: キーは placement ができるように taint キーに一致します。
(任意) Value: toleration の値は、placement を許可する toleration の taint の値と一致する必要があります。
(任意) Operator: 演算子はキーと値の関係を表します。有効な演算子は equal と exists です。デフォルト値は equal です。toleration は、キーが同じ場合、効果が同じ場合、さらび Operator が以下の値のいずれかである場合に、taint にマッチします。
- equal: Operator が equal で、値は taint および toleration と同じになります。
- exists: 値のワイルドカード。これにより、placement は特定のカテゴリーのすべての taint を許容できます。
(任意) Effect: 一致する taint の効果。空のままにすると、すべての taint の効果と一致します。指定可能な値は、NoSelect または NoSelectIfNew です。
(任意) TolerationSeconds: マネージドクラスターを新しい placement に移動する前に、taint を許容する時間の長さ (秒単位) です。effect 値が NoSelect または PreferNoSelect でない場合は、このフィールドは無視されます。デフォルト値は nil で、時間制限がないことを示します。TolerationSeconds のカウント開始時刻は、クラスターのスケジュール時刻や TolerationSeconds 加算時刻の値ではなく、自動的に taint の TimeAdded の値として記載されます。

以下の例は、taint が含まれるクラスターを許容する toleration を設定する方法を示しています。

この例のマネージドクラスターの taint:

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: gpu
      value: "true"
      timeAdded: '2022-02-21T08:11:06Z'

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: gpu
      value: "true"
      timeAdded: '2022-02-21T08:11:06Z'

Copy to Clipboard

Toggle word wrap

taint を許容できる placement の toleration

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement1
  namespace: default
spec:
  tolerations:
    - key: gpu
      value: "true"
      operator: Equal

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement1
  namespace: default
spec:
  tolerations:
    - key: gpu
      value: "true"
      operator: Equal

Copy to Clipboard

Toggle word wrap

toleration の定義例では、key: gpu と value: "true" が一致するため、placement で cluster1 を選択できます。

注記: マネージドクラスターは、taint の toleration が含まれる placement に置かれる保証はありません。他の placement に同じ toleration が含まれる場合には、マネージドクラスターはそれらの placement のいずれかに置かれる可能性があります。

1.5.14.4.4. 一時的な toleration の指定
リンクのコピー

TolerationSeconds の値は、toleration が taint を許容する期間を指定します。この一時的な toleration は、マネージドクラスターがオフラインで、このクラスターにデプロイされているアプリケーションを、許容時間中に別のマネージドクラスターに転送できる場合に役立ちます。

たとえば、以下の taint を持つマネージドクラスターに到達できなくなります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'

Copy to Clipboard

Toggle word wrap

以下の例のように、TolerationSeconds の値で placement を定義すると、ワークロードは 5 分後に利用可能な別のマネージドクラスターに転送されます。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: demo4
  namespace: demo1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
      tolerationSeconds: 300

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: demo4
  namespace: demo1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
      tolerationSeconds: 300

Copy to Clipboard

Toggle word wrap

マネージドクラスターに到達できなくなると、アプリケーションが 5 分間別のマネージドクラスターに移動されます。

1.5.14.5. ManagedClusterSet からのマネージドクラスターの削除
リンクのコピー

マネージドクラスターセットからマネージドクラスターを削除して別のマネージドクラスターセットに移動するか、セットの管理設定から削除する必要がある場合があります。コンソールまたは CLI を使用して、マネージドクラスターセットからマネージドクラスターを削除できます。

注記:

マネージドクラスターはすべて、マネージドクラスターセットに割り当てる必要があります。ManagedClusterSet からマネージドクラスターを削除し、別の ManagedClusterSet に割り当てない場合は、そのクラスターは default のマネージドクラスターセットに自動的に追加されます。
Submariner アドオンがマネージドクラスターにインストールされている場合は、アドオンをアンインストールしてから、マネージドクラスターを ManagedClusterSet から削除する必要があります。

1.5.14.5.1. コンソールを使用した ManagedClusterSet からのクラスターの削除
リンクのコピー

コンソールを使用してマネージドクラスターセットからクラスターを削除するには、次の手順を実行します。

Infrastructure > Clusters をクリックし、Cluster sets タブが選択されていることを確認します。
マネージドクラスターセットから削除するクラスターセットの名前を選択し、クラスターセットの詳細を表示します。
Actions > Manage resource assignments を選択します。
Manage resource assignments ページで、クラスターセットから削除するリソースのチェックボックスをオフにします。
この手順では、すでにクラスターセットのメンバーであるリソースを削除します。マネージドクラスターの詳細を表示して、リソースがすでにクラスターセットのメンバーであるかどうかを確認できます。

注記: マネージドクラスターを別のマネージドクラスターセットに移動する場合には、マネージドクラスターセット両方で RBAC 権限の設定が必要です。

1.5.14.5.2. CLI を使用した ManagedClusterSet からのクラスターの削除
リンクのコピー

コマンドラインを使用してマネージドクラスターセットからクラスターを削除するには、以下の手順を実行します。

以下のコマンドを実行して、マネージドクラスターセットでマネージドクラスターのリストを表示します。
```
oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<cluster_set>
```
```
oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<cluster_set>
```
Copy to Clipboard Toggle word wrap
<cluster_set> をマネージドクラスターセットの名前に置き換えます。
削除するクラスターのエントリーを見つけます。
削除するクラスターの YAML エントリーからラベルを削除します。ラベルの例は、以下のコードを参照してください。
```
labels:
   cluster.open-cluster-management.io/clusterset: clusterset1
```
```
labels:
   cluster.open-cluster-management.io/clusterset: clusterset1
```
Copy to Clipboard Toggle word wrap

注記: マネージドクラスターを別のクラスターセットに移動する場合は、マネージドクラスターセット両方で RBAC 権限の設定が必要です。

1.5.15. Placement
リンクのコピー

placement リソースは、placement namespace にバインドされている ManagedClusterSets から ManagedClusters のセットを選択するルールを定義する、namespace スコープのリソースです。

必要なアクセス権: クラスター管理者、クラスターセット管理者

プレースメントの使用方法の詳細は、読み続けてください。

Placement の概要
ManagedCusterSet からの ManagedClusters のフィルタリング
PlacementDecisions を使用して選択した ManagedClusters を確認する

1.5.15.1. Placement の概要
リンクのコピー

マネージドクラスターを使用した配置がどのように機能するかは、次の情報を参照してください。

Kubernetes クラスターは、cluster スコープの ManagedClusters としてハブクラスターに登録されます。
ManagedClusters は、クラスタースコープの ManagedClusterSets に編成されます。
ManagedClusterSets はワークロード namespace にバインドされます。
namespace スコープの placement では、潜在的な ManagedClusters の作業セットを選択する ManagedClusterSets の一部を指定します。
placement は、labelSelector と claimSelector を使用して、ManagedClusterSets から ManagedClusters をフィルター処理します。
ManagedClusters の placement は、taint と toleration を使用して制御できます。
Placements は、要件によってクラスターをランク付けし、そこからクラスターのサブセットを選択します。

注記:

namespace に ManagedClusterSetBinding を作成して、その namespace に ManagedClusterSet を最低でも 1 つバインドする必要があります。
managedclustersets/bind の仮想サブリソースの CREATE に対してロールベースのアクセスが必要です。

1.5.15.1.1. 関連情報
リンクのコピー

詳細は、taint と toleration を使用したマネージドクラスターの配置を参照してください。
API の詳細は、Placements API を参照してください。
placement を伴う ManagedClusters の選択に戻ります。

1.5.15.2. ManagedClusterSets からの ManagedClusters のフィルタリング
リンクのコピー

labelSelector または claimSelector を使用して、フィルタリングする ManagedClusters を選択できます。両方のフィルターの使用方法は、次の例を参照してください。

次の例では、labelSelector はラベル vendor: OpenShift を持つクラスターのみを照合します。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            vendor: OpenShift

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            vendor: OpenShift

Copy to Clipboard

Toggle word wrap

次の例では、claimSelector は、region.open-cluster-management.io と us-west-1 を持つクラスターのみを照合します。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        claimSelector:
          matchExpressions:
            - key: region.open-cluster-management.io
              operator: In
              values:
                - us-west-1

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        claimSelector:
          matchExpressions:
            - key: region.open-cluster-management.io
              operator: In
              values:
                - us-west-1

Copy to Clipboard

Toggle word wrap

また、clusterSets パラメーターを使用して、特定のクラスターセットから ManagedClusters をフィルター処理することもできます。次の例では、claimSelector はクラスターセット clusterset1 および clusterset2 のみに一致します。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  clusterSets:
    - clusterset1
    - clusterset2
  predicates:
    - requiredClusterSelector:
        claimSelector:
          matchExpressions:
            - key: region.open-cluster-management.io
              operator: In
              values:
                - us-west-1

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  clusterSets:
    - clusterset1
    - clusterset2
  predicates:
    - requiredClusterSelector:
        claimSelector:
          matchExpressions:
            - key: region.open-cluster-management.io
              operator: In
              values:
                - us-west-1

Copy to Clipboard

Toggle word wrap

また、numberOfClusters パラメーターを使用して、フィルタリングする ManagedClusters の数を選択することもできます。以下の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 3 
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            vendor: OpenShift
        claimSelector:
          matchExpressions:
            - key: region.open-cluster-management.io
              operator: In
              values:
                - us-west-1

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 3


  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            vendor: OpenShift
        claimSelector:
          matchExpressions:
            - key: region.open-cluster-management.io
              operator: In
              values:
                - us-west-1

Copy to Clipboard

Toggle word wrap

1: 選択する ManagedClusters の数を指定します。前の例では 3 に設定されています。

1.5.15.2.1. placement を使用して許容範囲を定義することによる ManagedClusters のフィルタリング
リンクのコピー

一致するテイントを使用して ManagedClusters をフィルタリングする方法は、次の例を参照してください。

デフォルトでは、次の例では、placement で cluster1 を選択できません。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: gpu
      value: "true"
      timeAdded: '2022-02-21T08:11:06Z'

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: gpu
      value: "true"
      timeAdded: '2022-02-21T08:11:06Z'

Copy to Clipboard

Toggle word wrap

cluster1 を選択するには、許容範囲を定義する必要があります。以下の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  tolerations:
    - key: gpu
      value: "true"
      operator: Equal

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  tolerations:
    - key: gpu
      value: "true"
      operator: Equal

Copy to Clipboard

Toggle word wrap

tolerationSeconds パラメーターを使用して、指定した期間、一致するテイントを持つ ManagedClusters を選択することもできます。tolerationSeconds は、許容がテイントにバインドされ続ける期間を定義します。tolerationSeconds は、指定された時間が経過すると、オフラインになったクラスターにデプロイされたアプリケーションを別のマネージドクラスターに自動的に転送できます。

次の例を見て、tolerationSeconds の使用方法を学習します。

次の例では、マネージドクラスターにアクセスできなくなります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'

Copy to Clipboard

Toggle word wrap

tolerationSeconds を使用して配置を定義すると、ワークロードは別の使用可能なマネージドクラスターに転送されます。以下の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
      tolerationSeconds: 300

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
      tolerationSeconds: 300

Copy to Clipboard

Toggle word wrap

1: 何秒後にワークロードを転送するかを指定します。

1.5.15.2.2. 配置を使用して prioritizerPolicy を定義することによる ManagedClusters の優先順位付け
リンクのコピー

次の例を参照して、prioritizerPolicy パラメーターと配置を使用して ManagedClusters に優先順位を付ける方法を学習します。

次の例では、割り当て可能なメモリーが最大のクラスターを選択します。

注記: Kubernetes Node Allocatable と同様に、'allocatable' は、各クラスターの Pod で利用可能なコンピュートリソースの量として定義されます。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 1
  prioritizerPolicy:
    configurations:
      - scoreCoordinate:
          builtIn: ResourceAllocatableMemory

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 1
  prioritizerPolicy:
    configurations:
      - scoreCoordinate:
          builtIn: ResourceAllocatableMemory

Copy to Clipboard

Toggle word wrap

次の例では、割り当て可能な最大の CPU とメモリーを持つクラスターを選択し、リソースの変更に敏感な配置を行います。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 1
  prioritizerPolicy:
    configurations:
      - scoreCoordinate:
          builtIn: ResourceAllocatableCPU
        weight: 2
      - scoreCoordinate:
          builtIn: ResourceAllocatableMemory
        weight: 2

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 1
  prioritizerPolicy:
    configurations:
      - scoreCoordinate:
          builtIn: ResourceAllocatableCPU
        weight: 2
      - scoreCoordinate:
          builtIn: ResourceAllocatableMemory
        weight: 2

Copy to Clipboard

Toggle word wrap

次の例では、addOn スコアの CPU 比率が最も大きい 2 つのクラスターを選択し、配置の決定を固定します。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 2
  prioritizerPolicy:
    mode: Exact
    configurations:
      - scoreCoordinate:
          builtIn: Steady
        weight: 3
      - scoreCoordinate:
          type: AddOn
          addOn:
            resourceName: default
            scoreName: cpuratio

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 2
  prioritizerPolicy:
    mode: Exact
    configurations:
      - scoreCoordinate:
          builtIn: Steady
        weight: 3
      - scoreCoordinate:
          type: AddOn
          addOn:
            resourceName: default
            scoreName: cpuratio

Copy to Clipboard

Toggle word wrap

1.5.15.2.3. アドオンのステータスに基づいた ManagedClusters のフィルタリング
リンクのコピー

デプロイされているアドオンのステータスに基づいて、プレースメント用のマネージドクラスターを選択することもできます。たとえば、マネージドクラスターで有効になっている特定のアドオンがある場合にのみ、placement にマネージドクラスターを選択できます。

placement を作成するときに、アドオンのラベルとそのステータスを指定できます。マネージドクラスターでアドオンが有効になっている場合、ラベルは ManagedCluster リソース上に自動的に作成されます。アドオンが無効になると、ラベルは自動的に削除されます。

各アドオンは、feature.open-cluster-management.io/addon-<addon_name>=<status_of_addon> の形式でラベルで表現します。

addon_name を選択したマネージドクラスターで有効にするアドオンの名前に置き換えます。

status_of_addon をマネージドクラスターが選択されている場合にアドオンに設定するステータスに置き換えます。

status_of_addon に指定できる値は、次の表を参照してください。

Expand

値	説明
`available`	アドオンは有効化されており、利用可能です。
`unhealthy`	アドオンは有効ですが、リースは継続的に更新されません。
`unreachable`	アドオンは有効ですが、そのアドオンのリースが見つかりません。これは、マネージドクラスターがオフライン時にも発生する可能性があります。

たとえば、使用可能な application-manager. アドオンは、マネージドクラスター上の次のようなラベルで表されます。

feature.open-cluster-management.io/addon-application-manager: available

feature.open-cluster-management.io/addon-application-manager: available

Copy to Clipboard

Toggle word wrap

アドオンとそのステータスに基づいて placement を作成する方法は、次の例を参照してください。

次の placement 例には、application-manager が有効になっているすべてのマネージドクラスターが含まれています。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement1
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchExpressions:
            - key: feature.open-cluster-management.io/addon-application-manager
              operator: Exists

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement1
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchExpressions:
            - key: feature.open-cluster-management.io/addon-application-manager
              operator: Exists

Copy to Clipboard

Toggle word wrap

次の placement 例には、application-manager が available ステータスで有効になっているすべてのマネージドクラスターが含まれています。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement2
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            "feature.open-cluster-management.io/addon-application-manager": "available"

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement2
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            "feature.open-cluster-management.io/addon-application-manager": "available"

Copy to Clipboard

Toggle word wrap

次の placement 例には、application-manager が無効になっているすべてのマネージドクラスターが含まれています。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement3
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchExpressions:
            - key: feature.open-cluster-management.io/addon-application-manager
              operator: DoesNotExist

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement3
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchExpressions:
            - key: feature.open-cluster-management.io/addon-application-manager
              operator: DoesNotExist

Copy to Clipboard

Toggle word wrap

1.5.15.2.4. 関連情報
リンクのコピー

詳細は、ノード割り当て可能を参照してください。
他のトピックは Selecting ManagedClusters with placement に戻ります。

1.5.15.3. PlacementDecisions を使用した選択した ManagedClusters の確認
リンクのコピー

ラベル cluster.open-cluster-management.io/placement={placement_name} を持つ 1 つ以上の PlacementDecision 種類が、プレースメントによって選択された ManagedClusters を表すために作成されます。

ManagedCluster が選択され、PlacementDecision に追加された場合、この配置を使用するコンポーネントがこの ManagedCluster にワークロードを適用する可能性があります。ManagedCluster が選択されなくなり、PlacementDecision から削除されると、この ManagedCluster に適用されているワークロードが削除されます。API の詳細は、PlacementDecisions API を参照してください。

次の PlacementDecision の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: PlacementDecision
metadata:
  labels:
    cluster.open-cluster-management.io/placement: placement1
  name: placement1-kbc7q
  namespace: ns1
  ownerReferences:
    - apiVersion: cluster.open-cluster-management.io/v1beta1
      blockOwnerDeletion: true
      controller: true
      kind: Placement
      name: placement1
      uid: 05441cf6-2543-4ecc-8389-1079b42fe63e
status:
  decisions:
    - clusterName: cluster1
      reason: ''
    - clusterName: cluster2
      reason: ''
    - clusterName: cluster3
      reason: ''

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: PlacementDecision
metadata:
  labels:
    cluster.open-cluster-management.io/placement: placement1
  name: placement1-kbc7q
  namespace: ns1
  ownerReferences:
    - apiVersion: cluster.open-cluster-management.io/v1beta1
      blockOwnerDeletion: true
      controller: true
      kind: Placement
      name: placement1
      uid: 05441cf6-2543-4ecc-8389-1079b42fe63e
status:
  decisions:
    - clusterName: cluster1
      reason: ''
    - clusterName: cluster2
      reason: ''
    - clusterName: cluster3
      reason: ''

Copy to Clipboard

Toggle word wrap

1.5.15.3.1. 関連情報
リンクのコピー

詳細は、PlacementDecisions API を参照してください。

1.5.16. クラスタープールの管理 (テクノロジープレビュー)
リンクのコピー

クラスタープールは、Red Hat OpenShift Container Platform クラスターにオンデマンドで、スケーリングする場合に、迅速かつコスト効果を高く保ちながら、アクセスできるようにします。クラスタープールは、Amazon Web Services、Google Cloud Platform または Microsoft Azure で設定可能な数多くの OpenShift Container Platform クラスターをプロビジョニングします。このプールは、開発、継続統合、および実稼働のシナリオにおいてクラスター環境を提供したり、置き換えたりする場合に特に便利です。実行を継続するクラスターの数を指定して、すぐに要求できるようにすることができます。残りのクラスターは休止状態に保たれるため、数分以内に再開して要求できます。

ClusterClaim リソースは、クラスタープールからクラスターをチェックアウトするために使用されます。クラスター要求が作成されると、その要求にプールは実行中のクラスターを割り当てます。実行中のクラスターがない場合は、休止状態のクラスターを再開してクラスターを提供するか、新規クラスターをプロビジョニングします。クラスタープールは自動的に新しいクラスターを作成し、休止状態のクラスターを再開して、プール内で利用可能な実行中のクラスターの指定サイズおよび数を維持します。

クラスタープールの作成
クラスタープールからのクラスターの要求
クラスタープールリリースイメージの更新
クラスタープールのスケーリング
クラスタープールの破棄

クラスタープールを作成する手順は、クラスターの作成手順と似ています。クラスタープールのクラスターは、すぐ使用するために作成されるわけではありません。

1.5.16.1. クラスタープールの作成
リンクのコピー

必要なアクセス権限: 管理者

1.5.16.1.1. 前提条件
リンクのコピー

クラスタープールを作成する前に、次の前提条件を参照してください。

multicluster engine Operator ハブクラスターをデプロイする必要があります。
プロバイダー環境で Kubernetes クラスターを作成できるように、multicluster engine Operator ハブクラスターのインターネットアクセスが必要です。
AWS、GCP、または Microsoft Azure プロバイダーのクレデンシャルが必要です。詳細は、認証情報の管理の概要を参照してください。
プロバイダー環境で設定済みのドメインが必要です。ドメインの設定方法は、プロバイダーのドキュメントを参照してください。
プロバイダーのログイン認証情報が必要です。
OpenShift Container Platform イメージプルシークレットが必要です。イメージプルシークレットの使用を参照してください。

注意: この手順でクラスタープールを追加すると、プールからクラスターを要求するときに、マルチクラスターエンジン Operator によって管理されるクラスターが自動的にインポートされるように設定されます。クラスター要求で管理用に、要求されたクラスターを自動的にインポートしないようにクラスタープールを作成する場合には、clusterClaim 理 s−すを以下ののテーションに追加します。

kind: ClusterClaim
metadata:
  annotations:
    cluster.open-cluster-management.io/createmanagedcluster: "false"

kind: ClusterClaim
metadata:
  annotations:
    cluster.open-cluster-management.io/createmanagedcluster: "false"

Copy to Clipboard

Toggle word wrap

1: 文字列であることを示すには、"false" という単語を引用符で囲む必要があります。

1.5.16.1.2. クラスタープールを作成する
リンクのコピー

クラスタープールを作成するには、ナビゲーションメニューで Infrastructure > Clusters を選択します。Cluster pools タブには、アクセス可能なクラスタープールがリスト表示されます。Create cluster pool を選択し、コンソールの手順を実行します。

クラスタープールに使用するインフラストラクチャー認証情報がない場合は、Add credential を選択して作成できます。

リストから既存の namespace を選択するか、作成する新規 namespace の名前を入力します。クラスタープールは、クラスターと同じ namespace に配置する必要はありません。

クラスタープールの RBAC ロールを使用して、既存クラスターセットのロール割り当てを共有する場合は、クラスターセット名を選択します。クラスタープールのクラスターセットは、クラスタープールの作成時にのみ設定できます。クラスタープールの作成後には、クラスタープールまたはクラスタープールのクラスターセットの関連付けを変更できません。クラスタープールから要求したクラスターは、クラスタープールと同じクラスターセットに自動的に追加されます。

注記: cluster admin の権限がない場合は、クラスターセットを選択する必要があります。この状況でクラスターセットの名前が含まれない場合は、禁止エラーで、クラスターセットの作成要求が拒否されます。選択できるクラスターセットがない場合は、クラスター管理者に連絡してクラスターセットを作成し、clusterset admin 権限を付与してもらいます。

cluster pool size は、クラスタープールにプロビジョニングするクラスターの数を指定し、クラスタープールの実行回数は、プールが実行を継続し、すぐに使用できるように要求できるクラスターの数を指定します。

この手順は、クラスターを作成する手順と非常に似ています。

プロバイダーに必要な固有の情報は、以下を参照してください。

Amazon Web Services でのクラスターの作成
Google Cloud Platform でのクラスターの作成
Microsoft Azure でのクラスターの作成

1.5.16.2. クラスタープールからのクラスターの要求
リンクのコピー

ClusterClaim リソースは、クラスタープールからクラスターをチェックアウトするために使用されます。クラスターの稼働中で、クラスタープールで準備できると、要求が完了します。クラスタープールは、クラスタープールに指定された要件を維持するために、クラスタープールに新しい実行中およびハイバネートされたクラスターを自動的に作成します。

注記: クラスタープールから要求されたクラスターが不要になり、破棄されると、リソースは削除されます。クラスターはクラスタープールに戻りません。

必要なアクセス権限: 管理者

1.5.16.2.1. 前提条件
リンクのコピー

クラスタープールからクラスターを要求する前に、以下を利用意する必要があります。

利用可能なクラスターのある/ないクラスタープール。クラスタープールに利用可能なクラスターがある場合、利用可能なクラスターが要求されます。クラスタープールに利用可能なクラスターがない場合は、要求を満たすためにクラスターが作成されます。クラスタープールの作成方法は、クラスタープールの作成を参照してください。

1.5.16.2.2. クラスタープールからのクラスターの要求
リンクのコピー

クラスター要求の作成時に、クラスタープールから新規クラスターを要求します。クラスターが利用可能になると、クラスターはプールからチェックアウトされます。自動インポートを無効にしていない限り、要求されたクラスターはマネージドクラスターの 1 つとして自動的にインポートされます。

以下の手順を実行してクラスターを要求します。

ナビゲーションメニューから Infrastructure > Clusters をクリックし、Cluster pools タブを選択します。
クラスターを要求するクラスタープールの名前を見つけ、Claim cluster を選択します。

クラスターが利用可能な場合には、クラスターが要求され、マネージドクラスター タブにすぐに表示されます。利用可能なクラスターがない場合は、休止状態のクラスターの再開や、新しいクラスターのプロビジョニングに数分かかる場合があります。この間、要求のステータスは pending です。クラスタープールをデプロイメントして、保留中の要求を表示または削除します。

要求されたクラスターは、クラスタープールにあった時に関連付けられたクラスターセットに所属します。要求時には、要求したクラスターのクラスターセットは変更できません。

注記: クラウドプロバイダー認証情報のプルシークレット、SSH キー、またはベースドメインへの変更は、元の認証情報を使用してすでにプロビジョニングされているため、クラスタープールから要求された既存のクラスターには反映されません。コンソールを使用してクラスタープール情報を編集することはできませんが、CLI インターフェイスを使用してその情報を更新することで更新できます。更新された情報を含む認証情報を使用して、新しいクラスタープールを作成することもできます。新しいプールで作成されるクラスターは、新しい認証情報で提供される設定を使用します。

1.5.16.3. クラスタープールリリースイメージの更新
リンクのコピー

クラスタープールのクラスターが一定期間、休止状態のままになると、クラスターの Red Hat OpenShift Container Platform リリースイメージがバックレベルになる可能性があります。このような場合は、クラスタープールにあるクラスターのリリースイメージのバージョンをアップグレードしてください。

必要なアクセス: 編集

クラスタープールにあるクラスターの OpenShift Container Platform リリースイメージを更新するには、以下の手順を実行します。

注記: この手順では、クラスタープールですでに要求されているクラスタープールからクラスターを更新しません。この手順を完了すると、リリースイメージの更新は、クラスタープールに関連する次のクラスターにのみ適用されます。

この手順でリリースイメージを更新した後にクラスタープールによって作成されたクラスター。
クラスタープールで休止状態になっているクラスター。古いリリースイメージを持つ既存の休止状態のクラスターは破棄され、新しいリリースイメージを持つ新しいクラスターがそれらを置き換えます。

ナビゲーションメニューから Infrastructure > Clusters をクリックします。
Cluster pools タブを選択します。
クラスタープール の表で、更新するクラスタープールの名前を見つけます。
表の Cluster pools の Options メニューをクリックし、Update release image を選択します。
このクラスタープールから今後、クラスターの作成に使用する新規リリースイメージを選択します。

クラスタープールのリリースイメージが更新されました。

ヒント: アクション 1 つで複数のクラスターのリリースイメージを更新するには、各クラスタープールのボックスを選択して Actions メニューを使用し、選択したクラスタープールのリリースイメージを更新します。

1.5.16.4. Scaling cluster pools (Technology Preview)
リンクのコピー

クラスタープールのクラスター数は、クラスタープールサイズのクラスター数を増やしたり、減らしたりして変更できます。

必要なアクセス権限: クラスターの管理者

クラスタープールのクラスター数を変更するには、以下の手順を実行します。

ナビゲーションメニューから Infrastructure > Clusters をクリックします。
Cluster pools タブを選択します。
変更するクラスタープールの Options メニューで、Scale cluster pool を選択します。
プールサイズの値を変更します。
オプションで、実行中のクラスターの数を更新して、要求時にすぐに利用可能なクラスター数を増減できます。

クラスタープールは、新しい値を反映するようにスケーリングされます。

1.5.16.5. クラスタープールの破棄
リンクのコピー

クラスタープールを作成し、不要になった場合は、そのクラスタープールを破棄できます。

重要: クラスター要求がないクラスタープールのみ破棄できます。

必要なアクセス権限: クラスターの管理者

クラスタープールを破棄するには、以下の手順を実行します。

ナビゲーションメニューから Infrastructure > Clusters をクリックします。
Cluster pools タブを選択します。
削除するクラスタープールの Options メニューで、確認ボックスに confirm と入力して Destroy を選択します。
注記:
- クラスタープールにクラスター要求がある場合、Destroy ボタンは無効になります。
- クラスタープールを含む namespace は削除されません。namespace を削除すると、これらのクラスターのクラスター要求リソースが同じ namespace で作成されるため、クラスタープールから要求されたクラスターが破棄されます。

ヒント: アクション 1 つで複数のクラスタープールを破棄するには、各クラスタープールのボックスを選択して Actions メニューを使用し、選択したクラスタープールを破棄します。

1.5.17. ManagedServiceAccount アドオンの有効化
リンクのコピー

マルチクラスターエンジン Operator バージョン 2.5 以降をインストールすると、ManagedServiceAccount アドオンがデフォルトで有効になります。ハブクラスターをマルチクラスターエンジン Operator バージョン 2.4 からアップグレードし、アップグレード前に ManagedServiceAccount アドオンを有効にしていなかった場合は、アドオンを手動で有効にする必要があります。

ManagedServiceAccount を使用すると、マネージドクラスターでサービスアカウントを作成または削除できます。

必要なアクセス権限: 編集

ManagedServiceAccount カスタムリソースがハブクラスターの <managed_cluster> namespace に作成されると、ServiceAccount がマネージドクラスターに作成されます。

TokenRequest は、マネージドクラスターの ServiceAccount を使用して、マネージドクラスターの Kubernetes API サーバーに対して行われます。トークンは、ハブクラスターの <target_managed_cluster> namespace の Secret に保存されます。

注記トークンは期限切れになり、ローテーションされる可能性があります。トークンリクエストの詳細は、TokenRequest を参照してください。

1.5.17.1. 前提条件
リンクのコピー

お使いの環境に Red Hat OpenShift Container Platform バージョン 4.13 以降をインストールし、コマンドラインインターフェイス (CLI) でログインしている。
マルチクラスターエンジン Operator がインストールされている必要がある。

1.5.17.2. ManagedServiceAccount の有効化
リンクのコピー

ハブクラスターとマネージドクラスターの ManagedServiceAccount アドオンを有効にするには、次の手順を実行します。

ハブクラスターで ManagedServiceAccount アドオンを有効にします。詳細は、詳細設定を参照してください。

ManagedServiceAccount アドオンをデプロイし、それをターゲットのマネージドクラスターに適用します。次の YAML ファイルを作成し、target_managed_cluster を Managed-ServiceAccount アドオンを適用するマネージドクラスターの名前に置き換えます。

apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  name: managed-serviceaccount
  namespace: <target_managed_cluster>
spec:
  installNamespace: open-cluster-management-agent-addon

apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  name: managed-serviceaccount
  namespace: <target_managed_cluster>
spec:
  installNamespace: open-cluster-management-agent-addon

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、ファイルを適用します。
```
oc apply -f -
```
```
oc apply -f -
```
Copy to Clipboard Toggle word wrap
これで、マネージドクラスターの ManagedServiceAccount プラグインが有効になりました。ManagedServiceAccount を設定するには、次の手順を参照してください。

次の YAML ソースを使用して ManagedServiceAccount カスタムリソースを作成します。

apiVersion: authentication.open-cluster-management.io/v1alpha1
kind: ManagedServiceAccount
metadata:
  name: <managedserviceaccount_name>
  namespace: <target_managed_cluster>
spec:
  rotation: {}

apiVersion: authentication.open-cluster-management.io/v1alpha1
kind: ManagedServiceAccount
metadata:
  name: <managedserviceaccount_name>
  namespace: <target_managed_cluster>
spec:
  rotation: {}

Copy to Clipboard

Toggle word wrap

managed_serviceaccount_name を ManagedServiceAccount の名前に置き換えます。
target_managed_cluster を、ManagedServiceAccount を適用するマネージドクラスターの名前に置き換えます。

確認するには、ManagedServiceAccount オブジェクトのステータスで tokenSecretRef 属性を表示して、シークレット名と namespace を見つけます。アカウントとクラスター名を使用して次のコマンドを実行します。
```
oc get managedserviceaccount <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
```
```
oc get managedserviceaccount <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
```
Copy to Clipboard Toggle word wrap
マネージドクラスターで作成された ServiceAccount に接続されている取得されたトークンを含む Secret を表示します。以下のコマンドを実行します。
```
oc get secret <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
```
```
oc get secret <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
```
Copy to Clipboard Toggle word wrap

1.5.18. クラスターのライフサイクルの詳細設定
リンクのコピー

一部のクラスター設定は、インストール中またはインストール後に設定できます。

1.5.18.1. API サーバー証明書のカスタマイズ
リンクのコピー

マネージドクラスターは、OpenShift Kube API サーバーの外部ロードバランサーとの相互接続を介してハブクラスターと通信します。デフォルトの OpenShift Kube API サーバー証明書は、OpenShift Container Platform のインストール時に内部 Red Hat OpenShift Container Platform クラスター認証局 (CA) によって発行されます。必要に応じて、証明書を追加または変更できます。

API サーバー証明書を変更すると、マネージドクラスターとハブクラスター間の通信に影響を与える可能性があります。製品をインストールする前に名前付き証明書を追加すると、マネージドクラスターがオフライン状態になる可能性がある問題を回避できます。

次のリストには、証明書の更新が必要となる場合の例がいくつか含まれています。

外部ロードバランサーのデフォルトの API サーバー証明書を独自の証明書に置き換える必要がある。OpenShift Container Platform ドキュメントの API サーバー証明書の追加 のガイダンスに従い、ホスト名 api.<cluster_name>.<base_domain> の名前付き証明書を追加して、外部ロードバランサーのデフォルトの API サーバー証明書を置き換えることができます。証明書を置き換えると、マネージドクラスターの一部がオフライン状態に移行する可能性があります。証明書のアップグレード後にクラスターがオフライン状態になった場合は、Troubleshooting imported clusters offline after certificate change のトラブルシューティング手順に従って問題を解決してください。
注記: 製品をインストールする前に名前付き証明書を追加すると、クラスターがオフライン状態に移行するのを回避できます。
外部ロードバランサーの名前付き証明書の有効期限が切れているため、証明書を置き換える必要がある。中間証明書の数に関係なく、古い証明書と新しい証明書の両方が同じルート CA 証明書を共有する場合は、OpenShift Container Platform ドキュメントの API サーバー証明書の追加 のガイダンスに従って、新しい証明書の新しいシークレットを作成できます。次に、ホスト名 api.<cluster_name>.<base_domain> のサービス証明書参照を APIServer カスタムリソース内の新しいシークレットに更新します。それ以外の場合、古い証明書と新しい証明書に異なるルート CA 証明書がある場合は、次の手順を実行して証明書を置き換えます。
1. 次の例のような APIServer カスタムリソースを見つけます。
  apiVersion: config.openshift.io/v1 kind: APIServer metadata: name: cluster spec: audit: profile: Default servingCerts: namedCertificates: - names: - api.mycluster.example.com servingCertificate: name: old-cert-secret
  Copy to Clipboard Toggle word wrap
2. 次のコマンドを実行して、既存の証明書と新しい証明書の内容を含む新しいシークレットを openshift-config namespace に作成します。
  1. 古い証明書を新しい証明書にコピーします。
    
    cp old.crt combined.crt
    
    Copy to Clipboard Toggle word wrap
  2. 新しい証明書の内容を古い証明書のコピーに追加します。
    
    cat new.crt >> combined.crt
    
    Copy to Clipboard Toggle word wrap
  3. 結合した証明書を適用してシークレットを作成します。
    
    oc create secret tls combined-certs-secret --cert=combined.crt --key=old.key -n openshift-config
    
    Copy to Clipboard Toggle word wrap
3. APIServer リソースを更新して、結合された証明書を servingCertificate として参照します。
  apiVersion: config.openshift.io/v1 kind: APIServer metadata: name: cluster spec: audit: profile: Default servingCerts: namedCertificates: - names: - api.mycluster.example.com servingCertificate: name: combined-cert-secret
  Copy to Clipboard Toggle word wrap
4. 約 15 分後、新しい証明書と古い証明書の両方を含む CA バンドルがマネージドクラスターに伝播されます。
5. 次のコマンドを入力して、新しい証明書情報のみを含む new-cert-secret という名前の別のシークレットを openshift-config namespace に作成します。
  oc create secret tls new-cert-secret --cert=new.crt --key=new.key -n openshift-config {code}
  Copy to Clipboard Toggle word wrap
6. new-cert-secret を参照するように servingCertificate の名前を変更して、APIServer リソースを更新します。リソースは以下の例のようになります。
  apiVersion: config.openshift.io/v1 kind: APIServer metadata: name: cluster spec: audit: profile: Default servingCerts: namedCertificates: - names: - api.mycluster.example.com servingCertificate: name: new-cert-secret
  Copy to Clipboard Toggle word wrap
  約 15 分後、古い証明書が CA バンドルから削除され、変更がマネージドクラスターに自動的に伝播されます。

注記: マネージドクラスターは、ホスト名 api.<cluster_name>.<base_domain> を使用してハブクラスターにアクセスする必要があります。他のホスト名で設定された名前付き証明書は使用できません。

1.5.18.2. ハブクラスターとマネージドクラスター間のプロキシーの設定
リンクのコピー

マネージドクラスターを multicluster engine for Kubernetes Operator に登録するには、マネージドクラスターを multicluster engine Operator ハブクラスターに転送する必要があります。場合によっては、マネージドクラスターが multicluster engine Operator ハブクラスターに直接アクセスできないことがあります。この例では、マネージドクラスターからの通信が HTTP または HTTPS プロキシーサーバー経由で multicluster engine Operator ハブクラスターにアクセスできるようにプロキシー設定を指定します。

たとえば、multicluster engine Operator ハブクラスターはパブリッククラウドにあり、マネージドクラスターはファイアウォールの背後にあるプライベートクラウド環境にあります。プライベートクラウドからの通信は、HTTP または HTTPS プロキシーサーバーのみを経由できます。

1.5.18.2.1. 前提条件
リンクのコピー

HTTP トンネルをサポートする HTTP または HTTPS プロキシーサーバーが実行されている。(例: HTTP connect メソッド)
HTTP または HTTPS プロキシーサーバーに到達できるマネージドクラスターがあり、プロキシーサーバーが multicluster engine Operator ハブクラスターにアクセスできる。

ハブクラスターとマネージドクラスターとの間でプロキシー設定を指定するには、以下の手順を実行します。

プロキシー設定を使用して KlusterConfig リソースを作成します。

以下の HTTP プロキシー設定を参照してください。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: http-proxy
spec:
  hubKubeAPIServerProxyConfig:
    httpProxy: "http://<username>:<password>@<ip>:<port>"

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: http-proxy
spec:
  hubKubeAPIServerProxyConfig:
    httpProxy: "http://<username>:<password>@<ip>:<port>"

Copy to Clipboard

Toggle word wrap

以下の HTTPS プロキシー設定を参照してください。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: https-proxy
spec:
  hubKubeAPIServerProxyConfig:
    httpsProxy: "https://<username>:<password>@<ip>:<port>"
    caBundle: <user-ca-bundle>

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: https-proxy
spec:
  hubKubeAPIServerProxyConfig:
    httpsProxy: "https://<username>:<password>@<ip>:<port>"
    caBundle: <user-ca-bundle>

Copy to Clipboard

Toggle word wrap

注: HTTPS プロキシーサーバーを設定する場合は、CA 証明書が必要です。HTTP プロキシーと HTTPS プロキシーの両方が指定されている場合は、HTTPS プロキシーが使用されます。

マネージドクラスターの作成時に、KlusterletConfig リソースを参照するアノテーションを追加して、KlusterletConfig リソースを選択します。以下の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    agent.open-cluster-management.io/klusterlet-config: <klusterlet-config-name>
  name:<managed-cluster-name>
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    agent.open-cluster-management.io/klusterlet-config: <klusterlet-config-name>
  name:<managed-cluster-name>
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60

Copy to Clipboard

Toggle word wrap

注: マルチクラスターエンジンの operator コンソールで操作する場合は、YAML ビューを切り替えて ManagedCluster リソースにアノテーションを追加する必要がある場合があります。

1.5.18.2.2. ハブクラスターとマネージドクラスター間のプロキシーの無効化
リンクのコピー

開発が変更された場合は、HTTP または HTTPS プロキシーを無効にする必要がある場合があります。

ManagedCluster リソースに移動します。
アノテーション agent.open-cluster-management.io/klusterlet-config を削除します。

1.5.18.2.3. オプション: 特定のノードで実行するように klusterlet を設定する
リンクのコピー

Red Hat Advanced Cluster Management for Kubernetes を使用してクラスターを作成する場合、マネージドクラスターの nodeSelector および tolerations アノテーションを設定することで、マネージドクラスター klusterlet を実行するノードを指定できます。これらを設定するには、次の手順を実行します。

コンソールのクラスターページから、更新するマネージドクラスターを選択します。
YAML コンテンツを表示するには、YAML スイッチを On に設定します。
注記: YAML エディターは、クラスターをインポートまたは作成するときにのみ使用できます。インポートまたは作成後にマネージドクラスターの YAML 定義を編集するには、OpenShift Container Platform コマンドラインインターフェイスまたは Red Hat Advanced Cluster Management 検索機能を使用する必要があります。
nodeSelector アノテーションをマネージドクラスターの YAML 定義に追加します。このアノテーションのキーは、open-cluster-management/nodeSelector です。このアノテーションの値は、JSON 形式の文字列マップです。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    open-cluster-management/nodeSelector: '{"dedicated":"acm"}'
    open-cluster-management/tolerations: '[{"key":"dedicated","operator":"Equal","value":"acm","effect":"NoSchedule"}]'

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    open-cluster-management/nodeSelector: '{"dedicated":"acm"}'
    open-cluster-management/tolerations: '[{"key":"dedicated","operator":"Equal","value":"acm","effect":"NoSchedule"}]'

Copy to Clipboard

Toggle word wrap

1.5.18.3. マネージドクラスターをインポートする際のハブクラスター API サーバーのサーバー URL と CA バンドルのカスタマイズ (テクノロジープレビュー)
リンクのコピー

マネージドクラスターとハブクラスターの間に中間コンポーネントが存在する場合、multicluster engine Operator ハブクラスターにマネージドクラスターを登録できない可能性があります。中間コンポーネントの例には、仮想 IP、ロードバランサー、リバースプロキシー、API ゲートウェイなどがあります。中間コンポーネントがある場合は、マネージドクラスターをインポートするときに、ハブクラスター API サーバーのカスタムサーバー URL と CA バンドルを使用する必要があります。

1.5.18.3.1. 前提条件
リンクのコピー

マネージドクラスターからハブクラスター API サーバーにアクセスできるように、中間コンポーネントを設定する必要があります。
中間コンポーネントがマネージドクラスターとハブクラスター API サーバー間の SSL 接続を終端する場合は、SSL 接続をブリッジし、元のリクエストからの認証情報をハブクラスター API サーバーのバックエンドに渡す必要があります。Kubernetes API サーバーのユーザー偽装機能を使用すると、SSL 接続をブリッジできます。
中間コンポーネントは、元のリクエストからクライアント証明書を抽出し、証明書サブジェクトのコモンネーム (CN) と組織 (O) を偽装ヘッダーとして追加し、変更された偽装リクエストをハブクラスター API サーバーのバックエンドに転送します。
注記: SSL 接続をブリッジすると、クラスタープロキシーアドオンが機能しなくなります。

1.5.18.3.2. サーバー URL とハブクラスター CA バンドルのカスタマイズ
リンクのコピー

マネージドクラスターをインポートするときにカスタムハブ API サーバー URL と CA バンドルを使用するには、次の手順を実行します。

カスタムのハブクラスター API サーバー URL と CA バンドルを使用して KlusterConfig リソースを作成します。以下の例を参照してください。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: 
spec:
  hubKubeAPIServerURL: "https://api.example.com:6443" 
  hubKubeAPIServerCABundle: "LS0tLS1CRU...LS0tCg=="

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name:


spec:
  hubKubeAPIServerURL: "https://api.example.com:6443"


  hubKubeAPIServerCABundle: "LS0tLS1CRU...LS0tCg=="

Copy to Clipboard

Toggle word wrap

1: klusterlet 設定名を追加します。
2: カスタムサーバー URL を追加します。
3: カスタム CA バンドルを追加します。

マネージドクラスターを作成するときに、リソースを参照するアノテーションを追加して KlusterletConfig リソースを選択します。以下の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    agent.open-cluster-management.io/klusterlet-config: 
  name: 
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    agent.open-cluster-management.io/klusterlet-config:


  name:


spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60

Copy to Clipboard

Toggle word wrap

1: klusterlet 設定名を追加します。
2: クラスター名を追加します。

注記: コンソールを使用する場合は、ManagedCluster リソースにアノテーションを追加するために、YAML ビューを有効にする必要がある場合があります。

1.5.18.4. 関連情報
リンクのコピー

API サーバー証明書の追加
証明書を変更した後のインポート済みクラスターのオフラインでのトラブルシューティング
クラスタープロキシーアドオンのプロキシー設定

1.5.19. 管理からのクラスターの削除
リンクのコピー

multicluster engine Operator で作成された OpenShift Container Platform クラスターを管理から削除する場合は、クラスターを デタッチ または破棄することができます。クラスターをデタッチするとマネージメントから削除されますが、完全には削除されません。管理する場合には、もう一度インポートし直すことができます。このオプションは、クラスターが Ready 状態にある場合にだけ利用できます。

次の手順により、次のいずれかの状況でクラスターが管理から削除されます。

すでにクラスターを削除しており、削除したクラスターを Red Hat Advanced Cluster Management から削除したいと考えています。
クラスターを管理から削除したいが、クラスターを削除していない。

重要:

クラスターを破棄すると、マネージメントから削除され、クラスターのコンポーネントが削除されます。
マネージドクラスターを接続解除または破棄すると、関連する namespace が自動的に削除されます。この namespace にカスタムリソースを配置しないでください。

1.5.19.1. コンソールを使用したクラスターの削除
リンクのコピー

ナビゲーションメニューから、Infrastructure > Clusters に移動し、管理から削除するクラスターの横にあるオプションメニューから Destroy cluster または Detach cluster を選択します。

ヒント: 複数のクラスターをデタッチまたは破棄するには、デタッチまたは破棄するクラスターのチェックボックスを選択して、Detach または Destroy を選択します。

注記: local-cluster と呼ばれる管理対象時にハブクラスターをデタッチしようとすると、disableHubSelfManagement のデフォルト設定が false かどうかを確認してください。この設定が原因で、ハブクラスターはデタッチされると、自身を再インポートして管理し、MultiClusterHub コントローラーが調整されます。ハブクラスターがデタッチプロセスを完了して再インポートするのに時間がかかる場合があります。

プロセスが終了するのを待たずにハブクラスターを再インポートするには、以下のコマンドを実行して multiclusterhub-operator Pod を再起動して、再インポートの時間を短縮できます。

oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`

oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`

Copy to Clipboard

Toggle word wrap

ネットワーク接続時のオンラインインストールで説明されているように、disableHubSelfManagement の値を true に変更して、自動的にインポートされないようにハブクラスターの値を変更できます。

1.5.19.2. コマンドラインを使用したクラスターの削除
リンクのコピー

ハブクラスターのコマンドラインを使用してマネージドクラスターをデタッチするには、以下のコマンドを実行します。

oc delete managedcluster $CLUSTER_NAME

oc delete managedcluster $CLUSTER_NAME

Copy to Clipboard

Toggle word wrap

切断後にマネージドクラスターを破棄するには、次のコマンドを実行します。

oc delete clusterdeployment <CLUSTER_NAME> -n $CLUSTER_NAME

oc delete clusterdeployment <CLUSTER_NAME> -n $CLUSTER_NAME

Copy to Clipboard

Toggle word wrap

注記:

マネージドクラスターの破壊を防ぐには、ClusterDeployment カスタムリソースで spec.preserveOnDelete パラメーターを true に設定します。
disableHubSelfManagement のデフォルト設定は false です。false`setting causes the hub cluster, also called `local-cluster 切り離されたときに再インポートして管理し、MultiClusterHub コントローラーを調整します。
切り離しと再インポートのプロセスには数時間かかる場合があり、ハブクラスターが完了するまでに数時間かかる場合があります。プロセスが終了するのを待たずにハブクラスターを再インポートする場合は、以下のコマンドを実行して multiclusterhub-operator Pod を再起動して、再インポートの時間を短縮できます。
```
oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`
```
```
oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`
```
Copy to Clipboard Toggle word wrap
disableHubSelfManagement の値を true に指定して、自動的にインポートされないように、ハブクラスターの値を変更できます。ネットワーク接続時のオンラインインストールを参照してください。

1.5.19.3. クラスター削除後の残りのリソースの削除
リンクのコピー

削除したマネージドクラスターにリソースが残っている場合は、残りのすべてのコンポーネントを削除するための追加の手順が必要になります。これらの追加手順が必要な場合には、以下の例が含まれます。

マネージドクラスターは、完全に作成される前にデタッチされ、klusterlet などのコンポーネントはマネージドクラスターに残ります。
マネージドクラスターをデタッチする前に、クラスターを管理していたハブが失われたり、破棄されているため、ハブからマネージドクラスターをデタッチする方法はありません。
マネージドクラスターは、デタッチ時にオンライン状態ではありませんでした。

これらの状況の 1 つがマネージドクラスターのデタッチの試行に該当する場合は、マネージドクラスターから削除できないリソースがいくつかあります。マネージドクラスターをデタッチするには、以下の手順を実行します。

oc コマンドラインインターフェイスが設定されていることを確認してください。
また、マネージドクラスターに KUBECONFIG が設定されていることを確認してください。
oc get ns | grep open-cluster-management-agent を実行すると、2 つの namespace が表示されるはずです。
```
open-cluster-management-agent         Active   10m
open-cluster-management-agent-addon   Active   10m
```
```
open-cluster-management-agent         Active   10m
open-cluster-management-agent-addon   Active   10m
```
Copy to Clipboard Toggle word wrap

次のコマンドを使用して、klusterlet カスタムリソースを削除します。

oc get klusterlet | grep klusterlet | awk '{print $1}' | xargs oc patch klusterlet --type=merge -p '{"metadata":{"finalizers": []}}'

oc get klusterlet | grep klusterlet | awk '{print $1}' | xargs oc patch klusterlet --type=merge -p '{"metadata":{"finalizers": []}}'

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、残りのリソースを削除します。

oc delete namespaces open-cluster-management-agent open-cluster-management-agent-addon --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc delete crds --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc patch crds --type=merge -p '{"metadata":{"finalizers": []}}'

oc delete namespaces open-cluster-management-agent open-cluster-management-agent-addon --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc delete crds --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc patch crds --type=merge -p '{"metadata":{"finalizers": []}}'

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、namespaces と開いているすべてのクラスター管理 crds の両方が削除されていることを確認します。

oc get crds | grep open-cluster-management.io | awk '{print $1}'
oc get ns | grep open-cluster-management-agent

oc get crds | grep open-cluster-management.io | awk '{print $1}'
oc get ns | grep open-cluster-management-agent

Copy to Clipboard

Toggle word wrap

1.5.19.4. クラスターの削除後の etcd データベースのデフラグ
リンクのコピー

マネージドクラスターが多数ある場合は、ハブクラスターの etcd データベースのサイズに影響を与える可能性があります。OpenShift Container Platform 4.8 では、マネージドクラスターを削除すると、ハブクラスターの etcd データベースのサイズは自動的に縮小されません。シナリオによっては、etcd データベースは領域不足になる可能性があります。etcdserver: mvcc: database space exceeded のエラーが表示されます。このエラーを修正するには、データベース履歴を圧縮し、etcd データベースのデフラグを実行して etcd データベースのサイズを縮小します。

注記: OpenShift Container Platform バージョン 4.9 以降では、etcd Operator はディスクを自動的にデフラグし、etcd 履歴を圧縮します。手動による介入は必要ありません。以下の手順は、OpenShift Container Platform 4.8 以前のバージョン向けです。

以下の手順を実行して、ハブクラスターで etcd 履歴を圧縮し、ハブクラスターで etcd データベースをデフラグします。

1.5.19.4.1. 前提条件
リンクのコピー

OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。

1.5.19.4.2. 手順
リンクのコピー

etcd 履歴を圧縮します。

次に、etcd メンバーへのリモートシェルセッションを開きます。

oc rsh -n openshift-etcd etcd-control-plane-0.example.com etcdctl endpoint status --cluster -w table

$ oc rsh -n openshift-etcd etcd-control-plane-0.example.com etcdctl endpoint status --cluster -w table

Copy to Clipboard

Toggle word wrap

以下のコマンドを実行して etcd 履歴を圧縮します。

sh-4.4#etcdctl compact $(etcdctl endpoint status --write-out="json" |  egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*' -m1)

sh-4.4#etcdctl compact $(etcdctl endpoint status --write-out="json" |  egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*' -m1)

Copy to Clipboard

Toggle word wrap

出力例

compacted revision 158774421

$ compacted revision 158774421

Copy to Clipboard

Toggle word wrap

etcd データのデフラグの説明に従って、etcd データベースをデフラグし、NOSPACE アラームをクリアします。

1.6. Discovery サービスの概要
リンクのコピー

OpenShift Cluster Manager で利用可能な OpenShift 4 クラスターを検出できます。検出後に、クラスターをインポートして管理できます。Discovery サービスは、バックエンドおよびコンソールでの用途に Discover Operator を使用します。

OpenShift Cluster Manager 認証情報が必要になります。認証情報を作成する必要がある場合は、Red Hat OpenShift Cluster Manager の認証情報の作成を参照してください。

必要なアクセス権限: 管理者

コンソールでの Discovery の設定
CLI を使用した検出機能の設定

1.6.1. コンソールでの検出の設定
リンクのコピー

製品のコンソールを使用して検出を有効にします。

必要なアクセス権: 認証情報が作成された namespace へのアクセス権。

1.6.1.1. 前提条件
リンクのコピー

認証情報が必要です。OpenShift Cluster Manager に接続するには、Red Hat OpenShift Cluster Manager の認証情報の作成を参照してください。

1.6.1.2. 検出の設定
リンクのコピー

コンソールで検出を設定し、クラスターを検索します。個別の認証情報を使用して複数の DiscoveryConfig リソースを作成できます。コンソールの指示に従います。

1.6.1.3. 検出されたクラスターの表示
リンクのコピー

認証情報を設定してインポートするクラスターを検出した後に、コンソールで表示できます。

Clusters > Discovered clusters の順にクリックします。
以下の情報が投入された表を確認してください。
- name は、OpenShift Cluster Manager で指定された表示名です。クラスターに表示名がない場合は、クラスターコンソール URL をもとに生成された名前が表示されます。OpenShift Cluster Manager でコンソール URL がない場合や手動で変更された場合には、クラスターの外部 ID が表示されます。
- Namespace は、認証情報および検出クラスターを作成した namespace です。
- type は検出されたクラスターの Red Hat OpenShift タイプです。
- Distribution version は、検出されたクラスターの Red Hat OpenShift バージョンです。
- Infrastructure provider は検出されたクラスターのクラウドプロバイダーです。
- Last active は、検出されたクラスターが最後にアクティブであった時間です。
- Created は検出クラスターが作成された時間です。
- Discovered は検出クラスターが検出された時間です。
表の中にある情報はどれでも検索できます。たとえば、特定の namespace で Discovered clusters のみを表示するには、その namespace を検索します。
Import cluster をクリックすると、マネージドクラスターを作成できます。検出クラスターのインポートを参照してください。

1.6.1.4. 検出クラスターのインポート
リンクのコピー

クラスターの検出後に、コンソールの Discovered clusters に表示されるクラスターをインポートできます。

1.6.1.5. 前提条件
リンクのコピー

検出の設定に使用した namespace へのアクセス権が必要である。

1.6.1.6. 検出クラスターのインポート
リンクのコピー

既存の Clusters ページに移動し、Discovered clusters タブをクリックします。
Discovered clusters の表から、インポートするクラスターを見つけます。
オプションメニューから Import cluster を選択します。
検出クラスターの場合は、このドキュメントを使用して手動でインポートしたり、Import cluster を自動的に選択したりできます。
認証情報または Kubeconfig ファイルを使用して自動でインポートするには、コンテンツをコピーして貼り付けます。
Import をクリックします。

1.6.2. CLI を使用した検出の有効化
リンクのコピー

CLI を使用して検出を有効にし、Red Hat OpenShift Cluster Manager が入手できるクラスターを見つけます。

必要なアクセス権限: 管理者

1.6.2.1. 前提条件
リンクのコピー

Red Hat OpenShift Cluster Manager に接続するための認証情報を作成している。

1.6.2.2. 検出の設定とプロセス
リンクのコピー

注記: DiscoveryConfig は discovery という名前に指定し、選択した credential と同じ namespace に作成する必要があります。以下の DiscoveryConfig のサンプルを参照してください。

apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveryConfig
metadata:
  name: discovery
  namespace: <NAMESPACE_NAME>
spec:
  credential: <SECRET_NAME>
  filters:
    lastActive: 7
    openshiftVersions:
    - "4.13"

apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveryConfig
metadata:
  name: discovery
  namespace: <NAMESPACE_NAME>
spec:
  credential: <SECRET_NAME>
  filters:
    lastActive: 7
    openshiftVersions:
    - "4.13"

Copy to Clipboard

Toggle word wrap

SECRET_NAME は、以前に設定した認証情報に置き換えます。
NAMESPACE_NAME は SECRET_NAME の namespace に置き換えます。
クラスターの最後のアクティビティー (日数) からの最大時間を入力します。たとえば、lastActive: 7 では、過去 7 日間にアクティブなクラスターが検出されます。
Red Hat OpenShift クラスターのバージョンを入力して、文字列の一覧として検出します。注記: openshiftVersions 一覧に含まれるエントリーはすべて、OpenShift のメジャーバージョンとマイナーバージョンを指定します。たとえば、"4.11" には OpenShift バージョン 4.11 のすべてのパッチリリース (4.11.1、4.11.2 など) が含まれます。

1.6.2.3. 検出されたクラスターの表示
リンクのコピー

検出されたクラスターを表示するには、oc get discoveredclusters -n <namespace> を実行して、namespace は検出認証情報が存在する namespace に置き換えます。

1.6.2.3.1. DiscoveredClusters
リンクのコピー

オブジェクトは Discovery コントローラーにより作成されます。このような DiscoveredClusters は、DiscoveryConfig discoveredclusters.discovery.open-cluster-management.io API で指定したフィルターと認証情報を使用して OpenShift Cluster Manager で検出されたクラスターを表します。name の値はクラスターの外部 ID です。

apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveredCluster
metadata:
  name: fd51aafa-95a8-41f7-a992-6fb95eed3c8e
  namespace: <NAMESPACE_NAME>
spec:
  activity_timestamp: "2021-04-19T21:06:14Z"
  cloudProvider: vsphere
  console: https://console-openshift-console.apps.qe1-vmware-pkt.dev02.red-chesterfield.com
  creation_timestamp: "2021-04-19T16:29:53Z"
  credential:
    apiVersion: v1
    kind: Secret
    name: <SECRET_NAME>
    namespace: <NAMESPACE_NAME>
  display_name: qe1-vmware-pkt.dev02.red-chesterfield.com
  name: fd51aafa-95a8-41f7-a992-6fb95eed3c8e
  openshiftVersion: 4.13
  status: Stale

apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveredCluster
metadata:
  name: fd51aafa-95a8-41f7-a992-6fb95eed3c8e
  namespace: <NAMESPACE_NAME>
spec:
  activity_timestamp: "2021-04-19T21:06:14Z"
  cloudProvider: vsphere
  console: https://console-openshift-console.apps.qe1-vmware-pkt.dev02.red-chesterfield.com
  creation_timestamp: "2021-04-19T16:29:53Z"
  credential:
    apiVersion: v1
    kind: Secret
    name: <SECRET_NAME>
    namespace: <NAMESPACE_NAME>
  display_name: qe1-vmware-pkt.dev02.red-chesterfield.com
  name: fd51aafa-95a8-41f7-a992-6fb95eed3c8e
  openshiftVersion: 4.13
  status: Stale

Copy to Clipboard

Toggle word wrap

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 バージョンを指します。

Expand

プラットフォーム	ホスティング OpenShift Container Platform のバージョン	ホステッド OpenShift Container Platform バージョン
ベアメタル	4.14 - 4.15	4.14 - 4.15 のみ
Red Hat OpenShift Virtualization	4.14 - 4.15	4.14 - 4.15 のみ
AWS (テクノロジープレビュー)	4.11 - 4.15	4.14 - 4.15 のみ

注記: 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 を使用するには、次のドキュメントから始めてください。

Hosted Control Plane のサイジングに関するガイダンス
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 の設定
ホステッドコントロール機能の無効化

追加のネットワーク、Guaranteed CPU、およびノードプールの仮想マシンスケジューリングを設定するには、次のドキュメントを参照してください。

追加のネットワーク、Guaranteed CPU、およびノードプールの仮想マシンのスケジュールを設定する

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 の最大数は、Pod からの Hosted Control Plane CPU およびメモリー要求に基づいて計算されます。

可用性の高い Hosted Control Plane は、5 つの仮想 CPU と 18 GB のメモリーを要求する 78 個の Pod で構成されています。これらのベースライン数値は、クラスターワーカーノードのリソース容量と比較され、Hosted Control Plane の最大数を推定します。

1.7.2.3. 負荷ベースの制限
リンクのコピー

クラスターがホストできる Hosted Control Plane の最大数は、Hosted Control Plane の Kubernetes API サーバーに何らかのワークロードが配置されたときの Hosted Control Plane Pod の CPU とメモリーの使用量に基づいて計算されます。

次の方法を使用して、ワークロードの増加に伴う Hosted Control Plane のリソース使用量を測定しました。

KubeVirt プラットフォームを使用し、それぞれ 8 つの仮想 CPU と 32 GiB を使用する 9 つのワーカーを持つホステッドクラスター
次の定義に基づいて、API コントロールプレーンのストレスに重点を置くように設定されたワークロードテストプロファイル:
- 各 namespace にオブジェクトを作成し、合計 100 の namespace まで拡張しました。
- オブジェクトの継続的な削除と作成により、API のストレスを増加させます。
- ワークロードの 1 秒あたりのクエリー数 (QPS) とバースト設定を高く設定して、クライアント側のスロットリングを排除します。

負荷が 1000 QPS 増加すると、Hosted Control Plane のリソース使用量が、仮想 CPU 9 個分およびメモリー 2.5 GB 分増加します。

一般的なサイズ設定の目的で、中程度 のホストクラスター負荷である 1000 QPS API レートと、重いホストクラスター負荷である 2000 QPS API レートを検討してください。

注記: このテストは、予想される API 負荷に基づいてコンピューティングリソースの使用率を高めるための推定係数を提供します。正確な使用率は、クラスターのワークロードのタイプとペースによって異なる場合があります。

Expand

表1.8 負荷の表
Hosted Control Plane のリソース使用量のスケーリング	仮想 CPU	メモリー (GiB)
負荷がないときのリソース使用量	2.9	11.1
1000 QPS でのリソース使用量	9.0	2.5

負荷が 1000 QPS 増加すると、Hosted Control Plane のリソース使用量が、仮想 CPU 9 個分およびメモリー 2.5 GB 分増加します。

一般的なサイジングが目的の場合は、1000 QPS API レートを中程度のホステッドクラスターの負荷、2000 QPS API を高程度のホステッドクラスターの負荷とみなしてください。

次の例は、ワークロードおよび API レート定義の Hosted Control Plane リソースのスケーリングを示しています。

Expand

表1.9 API レートの表
QPS (API レート)	仮想 CPU の使用量	メモリーの使用量 (GiB)
低負荷 (50 QPS 未満)	2.9	11.1
中負荷 (1000 QPS)	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 である

Expand

表1.10 入力の制限
制限の説明	サーバー 1	サーバー 2
ワーカーノード上の仮想 CPU 数	64	128
ワーカーノードのメモリー (GiB)	128	256
ワーカーあたりの最大 Pod 数	500	500
コントロールプレーンのホストに使用されるワーカーの数	3	3
最大 QPS ターゲットレート (1 秒あたりの API リクエスト)	1000	1000

Expand

表1.11 サイジング計算の例
ワーカーノードのサイズと 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 `maxPod`/Hosted Control Plane あたり 75 Pod
前述の最大値の中の最小値	5.4	6.7
	仮想 CPU の制限要因	`maxPods` の制限要因
管理クラスター内の Hosted Control Plane の最大数	16	20	前述の最大 3 つのコントロールプレーンワーカーの最小数。

Expand

表1.12 Hosted Control Plane の容量メトリクス
名前	説明
`mce_hs_addon_request_based_hcp_capacity_gauge`	高可用性 Hosted Control Plane リソース要求に基づいて、クラスターがホストできる Hosted Control Plane の推定最大数。
`mce_hs_addon_low_qps_based_hcp_capacity_gauge`	すべての Hosted Control Plane がクラスターの Kube API サーバーに約 50 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。
`mce_hs_addon_medium_qps_based_hcp_capacity_gauge`	すべての Hosted Control Plane がクラスターの Kube API サーバーに約 1000 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。
`mce_hs_addon_high_qps_based_hcp_capacity_gauge`	すべての Hosted Control Plane がクラスターの Kube API サーバーに約 2000 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。
`mce_hs_addon_average_qps_based_hcp_capacity_gauge`	Hosted Control Plane の既存の平均 QPS に基づいて、クラスターがホストできる Hosted Control Plane の推定最大数。アクティブな Hosted Control Plane がない場合は、QPS が低くなることが予想されます。

1.7.2.5. 関連情報
リンクのコピー

ホステッドクラスターのワークロードの分散
ノードあたりの Pod の最大数の設定
リソース使用率測定のオーバーライド

1.7.3. リソース使用率測定のオーバーライド
リンクのコピー

リソース使用率のベースライン測定セットは、クラスターごとに異なる場合があります。詳細は、Hosted Control Plane のサイズガイダンス を参照してください。

クラスターのワークロードの種類とペースに基づいて、リソース使用率の測定をオーバーライドできます。以下の手順を実行します。

次のコマンドを実行して、ConfigMap リソースを作成します。
```
oc create -f <your-config-map-file.yaml>
```
```
oc create -f <your-config-map-file.yaml>
```
Copy to Clipboard Toggle word wrap
<your-config-map-file.yaml> は hcp-sizing-baseline config map を含む YAML ファイルの名前に置き換えます。

local-cluster namespace に hcp-sizing-baseline config map を作成し、オーバーライドする測定値を指定します。config map は、次の YAML ファイルのようになります。

kind: ConfigMap
apiVersion: v1
metadata:
  name: hcp-sizing-baseline
  namespace: local-cluster
data:
  incrementalCPUUsagePer1KQPS: "9.0"
  memoryRequestPerHCP: "18"
  minimumQPSPerHCP: "50.0"

kind: ConfigMap
apiVersion: v1
metadata:
  name: hcp-sizing-baseline
  namespace: local-cluster
data:
  incrementalCPUUsagePer1KQPS: "9.0"
  memoryRequestPerHCP: "18"
  minimumQPSPerHCP: "50.0"

Copy to Clipboard

Toggle word wrap

以下のコマンドを実行して hypershift-addon-agent デプロイメントを削除し、hypershift-addon-agent Pod を再起動します。
```
oc delete deployment hypershift-addon-agent -n open-cluster-management-agent-addon
```
```
oc delete deployment hypershift-addon-agent -n open-cluster-management-agent-addon
```
Copy to Clipboard Toggle word wrap

hypershift-addon-agent Pod ログを監視します。次のコマンドを実行して、オーバーライドされた測定値が config map 内で更新されていることを確認します。

oc logs hypershift-addon-agent -n open-cluster-management-agent-addon

oc logs hypershift-addon-agent -n open-cluster-management-agent-addon

Copy to Clipboard

Toggle word wrap

ログは以下の出力のようになります。

2024-01-05T19:41:05.392Z	INFO	agent.agent-reconciler	agent/agent.go:793	setting cpuRequestPerHCP to 5
2024-01-05T19:41:05.392Z	INFO	agent.agent-reconciler	agent/agent.go:802	setting memoryRequestPerHCP to 18
2024-01-05T19:53:54.070Z	INFO	agent.agent-reconciler	agent/hcp_capacity_calculation.go:141	The worker nodes have 12.000000 vCPUs
2024-01-05T19:53:54.070Z	INFO	agent.agent-reconciler	agent/hcp_capacity_calculation.go:142	The worker nodes have 49.173369 GB memory

2024-01-05T19:41:05.392Z	INFO	agent.agent-reconciler	agent/agent.go:793	setting cpuRequestPerHCP to 5
2024-01-05T19:41:05.392Z	INFO	agent.agent-reconciler	agent/agent.go:802	setting memoryRequestPerHCP to 18
2024-01-05T19:53:54.070Z	INFO	agent.agent-reconciler	agent/hcp_capacity_calculation.go:141	The worker nodes have 12.000000 vCPUs
2024-01-05T19:53:54.070Z	INFO	agent.agent-reconciler	agent/hcp_capacity_calculation.go:142	The worker nodes have 49.173369 GB memory

Copy to Clipboard

Toggle word wrap

オーバーライドされた測定値が hcp-sizing-baseline config map で適切に更新されない場合、hypershift-addon-agent Pod ログに次のエラーメッセージが表示されることがあります。

2024-01-05T19:53:54.052Z	ERROR	agent.agent-reconciler	agent/agent.go:788	failed to get configmap from the hub. Setting the HCP sizing baseline with default values.	{"error": "configmaps \"hcp-sizing-baseline\" not found"}

2024-01-05T19:53:54.052Z	ERROR	agent.agent-reconciler	agent/agent.go:788	failed to get configmap from the hub. Setting the HCP sizing baseline with default values.	{"error": "configmaps \"hcp-sizing-baseline\" not found"}

Copy to Clipboard

Toggle word wrap

1.7.3.1. メトリクスサービスモニタリングの無効化
リンクのコピー

hypershift-addon マネージドクラスターアドオンを有効にすると、メトリクスサービスモニタリングがデフォルトで設定され、OpenShift Container Platform モニタリングが hypershift-addon からメトリクスを収集できるようになります。次の手順を実行して、メトリクスサービスの監視を無効化できます。

次のコマンドを実行して、ハブクラスターにログインします。
```
oc login
```
```
oc login
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、hypershift-addon-deploy-config アドオンデプロイメント設定仕様を開いて編集します。
```
oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine
```
```
oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine
```
Copy to Clipboard Toggle word wrap

次の例に示すように、disableMetrics=true カスタマイズ変数を仕様に追加します。

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: disableMetrics
    value: "true"

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: disableMetrics
    value: "true"

Copy to Clipboard

Toggle word wrap

変更を保存します。カスタマイズ変数 disableMetrics=true は、新規および既存の hypershift-addon マネージドクラスターアドオンの両方のメトリクスサービス監視設定を無効にします。

1.7.3.2. 関連情報
リンクのコピー

Hosted Control Plane のサイジングに関するガイダンス

1.7.4. Hosted Control Plane コマンドラインインターフェイスのインストール
リンクのコピー

次の手順を実行して、Hosted Control Plane コマンドラインインターフェイス (hcp) をインストールできます。

OpenShift Container Platform コンソールから、Help icon > Command Line Tools をクリックします。
お使いのプラットフォーム用の Download hcp CLI をクリックします。
次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。
```
tar xvzf hcp.tar.gz
```
```
tar xvzf hcp.tar.gz
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、バイナリーファイルを実行可能にします。
```
chmod +x hcp
```
```
chmod +x hcp
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。
```
sudo mv hcp /usr/local/bin/.
```
```
sudo mv hcp /usr/local/bin/.
```
Copy to Clipboard Toggle word wrap

hcp create cluster コマンドを使用して、ホステッドクラスターを作成および管理できるようになりました。使用可能なパラメーターをリストするには、次のコマンドを入力します。

hcp create cluster <platform> --help

hcp create cluster <platform> --help

Copy to Clipboard

Toggle word wrap

1: サポートされているプラットフォームは、aws、agent、および kubevirt です。

1.7.4.1. CLI を使用した Hosted Control Plane コマンドラインインターフェイスのインストール
リンクのコピー

次の手順を実行すると、CLI を使用して Hosted Control Plane コマンドラインインターフェイス (hcp) をインストールできます。

次のコマンドを実行して、hcp バイナリーをダウンロードするための URL を取得します。
```
oc get ConsoleCLIDownload hcp-cli-download -o json | jq -r ".spec"
```
```
oc get ConsoleCLIDownload hcp-cli-download -o json | jq -r ".spec"
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して hcp バイナリーをダウンロードします。
```
wget <hcp_cli_download_url> 
```
```
wget <hcp_cli_download_url> 
```
1
Copy to Clipboard Toggle word wrap
1
hcp_cli_download_url は、前の手順で取得した URL に置き換えます。
次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。
```
tar xvzf hcp.tar.gz
```
```
tar xvzf hcp.tar.gz
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、バイナリーファイルを実行可能にします。
```
chmod +x hcp
```
```
chmod +x hcp
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。
```
sudo mv hcp /usr/local/bin/.
```
```
sudo mv hcp /usr/local/bin/.
```
Copy to Clipboard Toggle word wrap

1.7.4.2. コンテンツゲートウェイを使用した Hosted Control Plane コマンドラインインターフェイスのインストール
リンクのコピー

コンテンツゲートウェイを使用して、Hosted Control Plane コマンドラインインターフェイス (hcp) をインストールできます。以下の手順を実行します。

コンテンツゲートウェイに移動し、hcp バイナリーをダウンロードします。
次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。
```
tar xvzf hcp.tar.gz
```
```
tar xvzf hcp.tar.gz
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、バイナリーファイルを実行可能にします。
```
chmod +x hcp
```
```
chmod +x hcp
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。
```
sudo mv hcp /usr/local/bin/.
```
```
sudo mv hcp /usr/local/bin/.
```
Copy to Clipboard Toggle word wrap

hcp create cluster <platform> --help

hcp create cluster <platform> --help

Copy to Clipboard

Toggle word wrap

1: サポートされているプラットフォームは、aws、agent、および kubevirt です。

1.7.5. ホステッドクラスターのワークロードの分散
リンクのコピー

OpenShift Container Platform の Hosted Control Plane を使い始める前に、ホスト型クラスター Pod をインフラストラクチャーノードにスケジュールするためにノードにラベルを付ける必要があります。

ノードのラベル付けにより、次の機能が保証されます。

高可用性と適切なワークロードのデプロイメント。たとえば、node-role.kubernetes.io/infra ラベルを設定して、OpenShift Container Platform サブスクリプションに control-plane ワークロード数が割り当てられないようにできます。
コントロールプレーンのワークロードを管理クラスター内の他のワークロードから分離します。

重要: ワークロードには管理クラスターを使用しないでください。ワークロードは、コントロールプレーンが実行されるノード上で実行してはなりません。

1.7.5.1. 管理クラスターノードのラベルとテイント
リンクのコピー

管理クラスター管理者は、管理クラスターノードで次のラベルとテイントを使用して、コントロールプレーンのワークロードをスケジュールします。

hypershift.openshift.io/control-plane: true: このラベルとテイントを使用して、Hosted Control Plane ワークロードの実行専用にノードを割り当てます。true を設定すると、コントロールプレーンノードを他のコンポーネントと共有することがなくなります。
hypershift.openshift.io/cluster: <hosted-control-plane-namespace>: ノードを単一のホストされたクラスター専用にする場合は、このラベルとテイントを使用します。

コントロールプレーン Pod をホストするノードに以下のラベルを適用します。

node-role.kubernetes.io/infra: このラベルを使用して、サブスクリプションにコントロールプレーンワークロード数が割り当てられないようにします。
topology.kubernetes.io/zone: このラベルを管理クラスターノードで使用して、障害ドメイン全体に高可用性クラスターをデプロイします。ゾーンは、ゾーンが設定されているノードの場所、ラック名、またはホスト名である場合があります。

各ラックを管理クラスターノードのアベイラビリティーゾーンとして使用するには、次のコマンドを入力します。

oc label node/<management_node1_name> node/<management_node2_name> topology.kubernetes.io/zone=<rack_name>

oc label node/<management_node1_name> node/<management_node2_name> topology.kubernetes.io/zone=<rack_name>

Copy to Clipboard

Toggle word wrap

ホステッドクラスターの Pod には許容範囲があり、スケジューラーはアフィニティールールを使用して Pod をスケジュールします。スケジューラーは、hypershift.openshift.io/control-plane および hypershift.openshift.io/cluster: <hosted_control_plane_namespace> でラベル付けされたノードへの Pod のスケジューリングを優先します。

ControllerAvailabilityPolicy オプションには、HighlyAvailable を使用します。これは、Hosted Control Plane のコマンドラインインターフェイス (hcp) がデプロイメントするデフォルト値です。このオプションを使用する場合は、topology.kubernetes.io/zone をトポロジーキーとして設定することで、さまざまな障害ドメインにわたるホステッドクラスター内のデプロイメントごとに Pod をスケジュールできます。高可用性ではないコントロールプレーンはサポートされていません。

1.7.5.2. ホステッドクラスターのノードのラベル付け
リンクのコピー

重要: Hosted Control Plane をデプロイする前に、ノードにラベルを追加する必要があります。

ホストされたクラスターで実行している Pod をインフラストラクチャーノードにスケジュールするには、HostedCluster カスタムリソース (CR) に role.kubernetes.io/infra: "" ラベルを追加します。以下の例を参照してください。

  spec:
    nodeSelector:
      role.kubernetes.io/infra: ""

  spec:
    nodeSelector:
      role.kubernetes.io/infra: ""

Copy to Clipboard

Toggle word wrap

1.7.5.3. 優先クラス
リンクのコピー

4 つの組み込み優先クラスは、ホステッドクラスター Pod の優先順位とプリエンプションに影響を与えます。管理クラスター内に Pod は、次の上位から下位の順序で作成できます。

hypershift-operator: HyperShift Operator Pod。
hypershift-etcd: etcd 用の Pod。
hypershift-api-critical: API 呼び出しとリソース許可が成功するために必要な Pod。この優先クラスには、kube-apiserver (集約された API サーバー) や Web フックなどの Pod が含まれます。
hypershift-control-plane : API クリティカルではないものの、クラスターバージョンの Operator など、高い優先順位が必要なコントロールプレーン内の Pod。

1.7.5.4. 関連情報
リンクのコピー

Hosted Control Plane の詳細は、次のトピックを参照してください。

ベアメタルでの Hosted Control Plane クラスターの設定
OpenShift Virtualization での Hosted Control Plane クラスターの管理
AWS での Hosted Control Plane クラスターの設定 (テクノロジープレビュー)

1.7.6. AWS での Hosted Control Plane クラスターの設定 (テクノロジープレビュー)
リンクのコピー

Hosted Control Plane を設定するには、ホスティングクラスターとホステッドクラスターが必要です。hypershift-addon マネージドクラスターアドオンを使用して既存のマネージドクラスターに HyperShift Operator をデプロイすることにより、そのクラスターをホスティングクラスターとして有効にして、ホステッドクラスターを作成し始めることができます。hypershift-addon マネージドクラスターアドオンは、マルチクラスターエンジン Operator 2.5 および Red Hat Advanced Cluster Management 2.10 ハブクラスターの local-cluster マネージドクラスターに対してデフォルトで有効になっています。

ホストされたクラスター は、ホスティングクラスターでホストされる API エンドポイントとコントロールプレーンを含む OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。マルチクラスターエンジンの Operator コンソールまたは Hosted Control Plane のコマンドラインインターフェイス hcp を使用して、ホステッドクラスターを作成できます。ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、マルチクラスターエンジン Operator へのホストクラスターの自動インポートの無効化 を参照してください。

重要:

各ホステッドクラスターに、クラスター全体で一意の名前が必要です。マルチクラスターエンジン Operator によってホストクラスターを管理するには、ホストクラスター名を既存のマネージドクラスターと同じにすることはできません。
ホステッドクラスター名として clusters を使用しないでください。
Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
ホステッドクラスターは、マルチクラスターエンジンの operator 管理クラスターの namespace には作成できません。

1.7.6.1. 前提条件
リンクのコピー

ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。

OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.5 以降のマルチクラスターエンジン。マルチクラスターエンジン 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.5 以降で自動的にインポートされます。local-cluster の詳細については、詳細設定を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。
```
oc get managedclusters local-cluster
```
```
oc get managedclusters local-cluster
```
Copy to Clipboard Toggle word wrap
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.6.2. Amazon Web Services S3 バケットと S3 OIDC シークレットの作成
リンクのコピー

AWS でホステッドクラスターを作成および管理する予定の場合は、次の手順を実行します。

クラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを持つ S3 バケットを作成します。

us-east-1 リージョンにバケットを作成するには、次のコードを入力します。

aws s3api create-bucket --bucket <your-bucket-name>
aws s3api delete-public-access-block --bucket <your-bucket-name>
echo '{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<your-bucket-name>/*"
        }
    ]
}' | envsubst > policy.json
aws s3api put-bucket-policy --bucket <your-bucket-name> --policy file://policy.json

aws s3api create-bucket --bucket <your-bucket-name>
aws s3api delete-public-access-block --bucket <your-bucket-name>
echo '{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<your-bucket-name>/*"
        }
    ]
}' | envsubst > policy.json
aws s3api put-bucket-policy --bucket <your-bucket-name> --policy file://policy.json

Copy to Clipboard

Toggle word wrap

us-east-1 リージョン以外のリージョンにバケットを作成するには、次のコードを入力します。

aws s3api create-bucket --bucket <your-bucket-name> \
  --create-bucket-configuration LocationConstraint=<region> \
  --region <region>
aws s3api delete-public-access-block --bucket <your-bucket-name>
echo '{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<your-bucket-name>/*"
        }
    ]
}' | envsubst > policy.json
aws s3api put-bucket-policy --bucket <your-bucket-name> --policy file://policy.json

aws s3api create-bucket --bucket <your-bucket-name> \
  --create-bucket-configuration LocationConstraint=<region> \
  --region <region>
aws s3api delete-public-access-block --bucket <your-bucket-name>
echo '{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<your-bucket-name>/*"
        }
    ]
}' | envsubst > policy.json
aws s3api put-bucket-policy --bucket <your-bucket-name> --policy file://policy.json

Copy to Clipboard

Toggle word wrap

HyperShift Operator 用に hypershift-operator-oidc-provider-s3-credentials という名前の OIDC S3 シークレットを作成します。
シークレットを local-cluster namespace に保存します。

次の表を参照して、シークレットに次のフィールドが含まれていることを確認します。

Expand

フィールド名	説明
`bucket`	ホステッドクラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを備えた S3 バケットが含まれています。
`credentials`	バケットにアクセスできる `default` プロファイルの認証情報を含むファイルへの参照。デフォルトでは、HyperShift は `default` プロファイルのみを使用して `バケット` を操作します。
`region`	S3 バケットのリージョンを指定します。

次の例は、サンプルの AWS シークレットテンプレートを示しています。

oc create secret generic hypershift-operator-oidc-provider-s3-credentials --from-file=credentials=<path>/.aws/credentials --from-literal=bucket=<s3-bucket-for-hypershift> --from-literal=region=<region> -n local-cluster

oc create secret generic hypershift-operator-oidc-provider-s3-credentials --from-file=credentials=<path>/.aws/credentials --from-literal=bucket=<s3-bucket-for-hypershift> --from-literal=region=<region> -n local-cluster

Copy to Clipboard

Toggle word wrap

注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に 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

oc label secret hypershift-operator-oidc-provider-s3-credentials -n local-cluster cluster.open-cluster-management.io/backup=true

Copy to Clipboard

Toggle word wrap

1.7.6.3. ルーティング可能なパブリックゾーンの作成
リンクのコピー

ゲストクラスター内のアプリケーションにアクセスするには、パブリックゾーンがルーティング可能である必要があります。パブリックゾーンが存在する場合は、この手順を省略します。省力しない場合は、パブリックゾーンが既存の機能に影響を及ぼします。

次のコマンドを実行して、クラスター DNS レコードのパブリックゾーンを作成します。

aws route53 create-hosted-zone --name <your-basedomain> --caller-reference $(whoami)-$(date --rfc-3339=date)

aws route53 create-hosted-zone --name <your-basedomain> --caller-reference $(whoami)-$(date --rfc-3339=date)

Copy to Clipboard

Toggle word wrap

your-basedomain をベースドメインに置き換えます (例: www.example.com)。

1.7.6.4. 外部 DNS の有効化
リンクのコピー

Hosted Control Plane では、コントロールプレーンとデータプレーンが分離されています。DNS は、次の 2 つの独立した領域で設定できます。

次のドメインなど、ホステッドクラスター内のワークロードの 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 は、次のサービスを公開します。

APIServer
OAuthServer
Konnectivity
Ignition
OVNSbDb
OIDC

これらのサービスは、HostedCluster 仕様の servicePublishingStrategy フィールドを使用して公開できます。デフォルトでは、servicePublishingStrategy の LoadBalancer および Route タイプの場合、次のいずれかの方法でサービスを公開できます。

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 レコードを作成するために使用されます。

外部 DNS はクラウド環境でのみ使用できます。その他の環境では、DNS とサービスを手動で設定する必要があります。

外部 DNS の詳細は、外部 DNS を参照してください。

1.7.6.4.1. 前提条件
リンクのコピー

Hosted Control Plane の外部 DNS を設定する前に、次の前提条件を満たす必要があります。

外部のパブリックドメインを作成している
AWS Route53 Management コンソールにアクセスできる。

1.7.6.4.2. Hosted Control Plane の外部 DNS の設定
リンクのコピー

Hosted Control Plane クラスターをサービスレベル DNS (外部 DNS) でプロビジョニングする場合は、次の手順を実行します。

HyperShift Operator の AWS 認証情報シークレットを作成し、local-cluster namespace で hypershift-operator-external-dns-credentials という名前を付けます。

次の表を参照して、シークレットに必須フィールドが含まれていることを確認してください。

Expand

フィールド名	説明	任意または必須
`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=<domain_name> --from-file=credentials=<path_to_aws_credentials_file> -n local-cluster

oc create secret generic hypershift-operator-external-dns-credentials --from-literal=provider=aws --from-literal=domain-filter=<domain_name> --from-file=credentials=<path_to_aws_credentials_file> -n local-cluster

Copy to Clipboard

Toggle word wrap

注記: シークレットのリカバリーバックアップは自動的に有効になりません。障害復旧のためにシークレットをバックアップするには、次のコマンドを入力して hypershift-Operator-external-dns-credentials を追加します。

oc label secret hypershift-operator-external-dns-credentials -n local-cluster cluster.open-cluster-management.io/backup=""

oc label secret hypershift-operator-external-dns-credentials -n local-cluster cluster.open-cluster-management.io/backup=""

Copy to Clipboard

Toggle word wrap

1.7.6.4.3. パブリック DNS ホストゾーンの作成
リンクのコピー

パブリック DNS ホストゾーンは、パブリックホステッドクラスターを作成するために、External DNS Operator によって使用されます。

外部 DNS ドメインフィルターとして使用するパブリック DNS ホストゾーンを作成できます。AWS Route 53 管理コンソールで次の手順を実行します。

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
```
```
dig +short test.user-dest-public.aws.kerberos.com
192.168.1.1
```
Copy to Clipboard Toggle word wrap
LoadBalancer および Route サービスのホスト名を設定するホストクラスターを作成するには、次のコマンドを入力します。
```
hcp create cluster aws --name=<hosted_cluster_name> --endpoint-access=PublicAndPrivate --external-dns-domain=<public_hosted_zone> ...
```
```
hcp create cluster aws --name=<hosted_cluster_name> --endpoint-access=PublicAndPrivate --external-dns-domain=<public_hosted_zone> ...
```
Copy to Clipboard Toggle word wrap
<public_hosted_zone> は、作成したパブリックホストゾーンに置き換えます。

この例は、ホステッドクラスターの結果として生じる 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

  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

Copy to Clipboard

Toggle word wrap

Control Plane Operator は、Services と Routes リソースを作成し、external-dns.alpha.kubernetes.io/hostname のアノテーションを付けます。Services と Routes の場合、Control Plane Operator は、サービスエンドポイントの servicePublishingStrategy フィールドの hostname パラメーターの値を使用します。DNS レコードを作成するには、external-dns デプロイメントなどのメカニズムを使用できます。

サービスレベルの DNS 間接化をパブリックサービスにのみ設定できます。プライベートサービスは hypershift.local プライベートゾーンを使用するため、hostname を設定できません。

次の表は、サービスとエンドポイントの組み合わせに対して hostname を設定することが有効な場合を示しています。

Expand

サービス	Public	PublicAndPrivate	Private
`APIServer`	Y	Y	N
`OAuthServer`	Y	Y	N
`Konnectivity`	Y	N	N
`Ignition`	Y	N	N

1.7.6.4.4. コマンドラインインターフェイスと外部 DNS を使用したクラスターのデプロイ
リンクのコピー

PublicAndPrivate または Public 公開ストラテジーを使用してホストされたクラスターを作成するには、管理クラスターで次のアーティファクトが設定されている必要があります。

パブリック DNS ホストゾーン
External DNS Operator
HyperShift Operator

コマンドラインインターフェイスを使用してホストされたクラスターをデプロイするには、次の手順を実行します。

管理クラスターにアクセスするには、次のコマンドを入力します。
```
export KUBECONFIG=<path_to_management_cluster_kubeconfig>
```
```
export KUBECONFIG=<path_to_management_cluster_kubeconfig>
```
Copy to Clipboard Toggle word wrap

次のコマンドを入力して、外部 DNS Operator が実行されていることを確認します。

oc get pod -n hypershift -lapp=external-dns

oc get pod -n hypershift -lapp=external-dns

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                            READY   STATUS    RESTARTS   AGE
external-dns-7c89788c69-rn8gp   1/1     Running   0          40s

NAME                            READY   STATUS    RESTARTS   AGE
external-dns-7c89788c69-rn8gp   1/1     Running   0          40s

Copy to Clipboard

Toggle word wrap

外部 DNS を使用してホストされたクラスターを作成するには、次のコマンドを入力します。

hypershift create cluster aws \
    --aws-creds <path_to_aws_credentials_file> \ 
    --instance-type <instance_type> \ 
    --region <region> \ 
    --auto-repair \
    --generate-ssh \
    --name <hosted_cluster_name> \ 
    --namespace clusters \
    --base-domain <service_consumer_domain> \ 
    --node-pool-replicas <node_replica_count> \ 
    --pull-secret <path_to_your_pull_secret> \ 
    --release-image quay.io/openshift-release-dev/ocp-release:<ocp_release_image> \ 
    --external-dns-domain=<service_provider_domain> \ 
    --endpoint-access=PublicAndPrivate

hypershift create cluster aws \
    --aws-creds <path_to_aws_credentials_file> \


    --instance-type <instance_type> \


    --region <region> \


    --auto-repair \
    --generate-ssh \
    --name <hosted_cluster_name> \


    --namespace clusters \
    --base-domain <service_consumer_domain> \


    --node-pool-replicas <node_replica_count> \


    --pull-secret <path_to_your_pull_secret> \


    --release-image quay.io/openshift-release-dev/ocp-release:<ocp_release_image> \


    --external-dns-domain=<service_provider_domain> \


    --endpoint-access=PublicAndPrivate

Copy to Clipboard

Toggle word wrap

1: AWS 認証情報ファイルへのパスを指定します (例: /user/name/.aws/credentials)。
2: インスタンスタイプを指定します (例: m6i.xlarge)。
3: AWS リージョンを指定します (例: us-east-1)。
4: ホストされたクラスター名を指定します (例: my-external-aws)。
5: サービスコンシューマーが所有するパブリックホストゾーンを指定します (例: service-consumer-domain.com)。
6: ノードのレプリカ数を指定します (例: 2)。
7: プルシークレットファイルへのパスを指定します。
8: 使用するサポートされている OpenShift Container Platform のバージョンを指定します (例: 4.14.0-x86_64)。
9: サービスプロバイダーが所有するパブリックホストゾーンを指定します (例: service-provider-domain.com)。
10: PublicAndPrivate として設定します。外部 DNS は、Public または PublicAndPrivate 設定でのみ使用できます。

1.7.6.5. AWS PrivateLink の有効化
リンクのコピー

PrivateLink を使用して AWS プラットフォームで Hosted Control Plane クラスターをプロビジョニングする予定の場合は、次の手順を実行します。

HyperShift Operator の AWS 認証情報シークレットを作成し、hypershift-operator-private-link-credentials という名前を付けます。シークレットは、ホスティングクラスターとして使用されるマネージドクラスターの namespace であるマネージドクラスター namespace に存在する必要があります。local-cluster を使用した場合は、local-cluster namespace にシークレットを作成します

シークレットに必要なフィールドが含まれることを確認するには、以下の表を参照してください。

Expand

フィールド名	説明	任意または必須
`region`	Private 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

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

Copy to Clipboard

Toggle word wrap

注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に hypershift-operator-private-link-credentials シークレットのバックアップを有効にするラベルを追加します。

oc label secret hypershift-operator-private-link-credentials -n local-cluster cluster.open-cluster-management.io/backup=""

oc label secret hypershift-operator-private-link-credentials -n local-cluster cluster.open-cluster-management.io/backup=""

Copy to Clipboard

Toggle word wrap

1.7.6.6. ホステッドクラスターのディザスタリカバリー
リンクのコピー

Hosted Control Plane は、マルチクラスターエンジン Operator ハブクラスター上で実行されます。データプレーンは、選択した別のプラットフォーム上で実行されます。マルチクラスターエンジンの operator ハブクラスターを災害から復旧する場合、ホストされているコントロールプレーンも復旧する必要がある場合があります。

Hosted Control Plane クラスターをバックアップし、別のクラスターに復元する方法は、AWS リージョン内のホステッドクラスターのディザスターリカバリーを参照してください。

重要: ホステッドクラスターの障害復旧は AWS でのみ利用できます。

1.7.6.7. ホステッドクラスターの AWS へのデプロイ
リンクのコピー

Hosted Control Plane マンドラインインターフェイス (hcp) を設定し、local-cluster ホスティングクラスターとして有効にしたら、次の手順を実行して、AWS にホステッドクラスターをデプロイできます。プライベートホストクラスターをデプロイするには、AWS でのプライベートホストクラスターのデプロイ を参照してください。

各変数の説明を表示するには、次のコマンドを実行します。
```
hcp create cluster aws --help
```
```
hcp create cluster aws --help
```
Copy to Clipboard Toggle word wrap
ハブクラスターにログインしていることを確認します。

次のコマンドを実行して、ホステッドクラスターを作成します。

hcp create cluster aws \
    --name <hosted_cluster_name> \ 
    --infra-id <infra_id> \ 
    --base-domain <basedomain> \ 
    --aws-creds <path_to_aws_creds> \ 
    --pull-secret <path_to_pull_secret> \ 
    --region <region> \ 
    --generate-ssh \
    --node-pool-replicas <node_pool_replica_count> \ 
    --namespace <hosted_cluster_namespace>

hcp create cluster aws \
    --name <hosted_cluster_name> \


    --infra-id <infra_id> \


    --base-domain <basedomain> \


    --aws-creds <path_to_aws_creds> \


    --pull-secret <path_to_pull_secret> \


    --region <region> \


    --generate-ssh \
    --node-pool-replicas <node_pool_replica_count> \


    --namespace <hosted_cluster_namespace>

Copy to Clipboard

Toggle word wrap

ホステッドクラスターの名前を指定します (例: example)。<hosted_cluster_name> と <infra_id> の値が同じであることを確認してください。そうしないと、クラスターが Kubernetes Operator コンソールのマルチクラスターエンジンに正しく表示されない可能性があります。

インフラストラクチャーの名前を指定します (例: clc-name-hs1)。

ベースドメインを指定します (例: dev09.red-chesterfield.com)。

4

AWS 認証情報ファイルへのパスを指定します (例: /user/name/.aws/credentials)。

5

プルシークレットへのパスを指定します (例: /user/name/pullsecret)。

6

AWS リージョン名を指定します (例: us-east-1)。

7

ノードプールのレプリカ数を指定します (例: 2)。

8

ホストされたクラスターの namespace を指定します (例: clusters)。

注記: デフォルトでは、HostedCluster と NodePool のすべてのカスタムリソースが clusters namespace に作成されます。--namespace <namespace> パラメーターを指定すると、選択した namespace に HostedCluster および NodePool カスタムリソースが作成されます。

以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。
```
oc get hostedclusters -n <hosted_cluster_namespace>
```
```
oc get hostedclusters -n <hosted_cluster_namespace>
```
Copy to Clipboard Toggle word wrap
以下のコマンドを実行してノードプールを確認できます。

oc get nodepools --namespace <hosted_cluster_namespace>

oc get nodepools --namespace <hosted_cluster_namespace>

Copy to Clipboard

Toggle word wrap

1.7.6.8. AWS 上の複数のゾーンにホステッドクラスターを作成する
リンクのコピー

次のコマンドを入力して、パブリックゾーンのベースドメインを指定してクラスターを作成します。

hcp create cluster aws \
--name <hosted-cluster-name> \ 
--node-pool-replicas=<node-pool-replica-count> \ 
--base-domain <basedomain> \ 
--pull-secret <path-to-pull-secret> \ 
--aws-creds <path-to-aws-credentials> \ 
--region <region> \ 
--zones <zones>

hcp create cluster aws \
--name <hosted-cluster-name> \


--node-pool-replicas=<node-pool-replica-count> \


--base-domain <basedomain> \


--pull-secret <path-to-pull-secret> \


--aws-creds <path-to-aws-credentials> \


--region <region> \


--zones <zones>

Copy to Clipboard

Toggle word wrap

1: ホストされているクラスターの名前を指定します (例: example)。
2: ノードプールのレプリカ数を指定します (例: 2)。
3: ベースドメインを指定します (例: example.com)。
4: プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
5: AWS 認証情報ファイルへのパスを指定します (例: /user/name/.aws/credentials)。
6: AWS リージョン名を指定します (例: us-east-1)。
7: AWS リージョン内のアベイラビリティーゾーンを指定します (例: us-east-1a、us-east-1b)。

指定したゾーンごとに、次のインフラストラクチャーが作成されます。

パブリックサブネット
プライベートサブネット
NAT ゲートウェイ
プライベートルートテーブル (パブリックルートテーブルはパブリックサブネット間で共有されます)

ゾーンごとに 1 つの NodePool リソースが作成されます。ノードプール名の末尾にはゾーン名が付けられます。ゾーンのプライベートサブネットは spec.platform.aws.subnet.id に設定されます。

1.7.6.8.1. AWS でホストされたクラスターを作成するための認証情報の提供
リンクのコピー

hcp create cluster aws コマンドを使用してホステッドクラスターを作成する場合は、クラスターのインフラストラクチャーリソースを作成する権限が割り当てられた AWS アカウント認証情報を指定する必要があります。インフラストラクチャーリソースの例としては、VPC、サブネット、NAT ゲートウェイなどがあります。AWS 認証情報は、--aws-creds フラグを使用する方法と、マルチクラスターエンジン Operator からの AWS クラウドプロバイダーのシークレットを使用する方法の 2 つの方法で指定できます。

1.7.6.8.1.1. --aws-creds フラグを使用した認証情報の指定
リンクのコピー

--aws-creds フラグを使用して認証情報を指定する場合は、そのフラグを AWS 認証情報ファイルパスの値に使用します。

以下の例を参照してください。

hcp create cluster aws \
--name <hosted-cluster-name> \ 
--node-pool-replicas=<node-pool-replica-count> \ 
--base-domain <basedomain> \ 
--pull-secret <path-to-pull-secret> \ 
--aws-creds <path-to-aws-credentials> \ 
--region <region>

hcp create cluster aws \
--name <hosted-cluster-name> \


--node-pool-replicas=<node-pool-replica-count> \


--base-domain <basedomain> \


--pull-secret <path-to-pull-secret> \


--aws-creds <path-to-aws-credentials> \


--region <region>

Copy to Clipboard

Toggle word wrap

1: ホストされているクラスターの名前を指定します (例: example)。
2: ノードプールのレプリカ数を指定します (例: 2)。
3: ベースドメインを指定します (例: example.com)。
4: プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
5: AWS 認証情報ファイルへのパスを指定します (例: /user/name/.aws/credentials)。
6: AWS リージョン名を指定します (例: us-east-1)。

1.7.6.8.1.2. AWS クラウドプロバイダーシークレットを使用した認証情報の提供
リンクのコピー

シークレットには、SSH キー、プルシークレット、ベースドメイン、AWS 認証情報が含まれます。したがって、--secret-creds フラグを指定した hcp create cluster aws コマンドを使用して、AWS 認証情報を提供できます。以下の例を参照してください。

hcp create cluster aws \
--name <hosted-cluster-name> \ 
--region <region> \ 
--namespace <hosted-cluster-namespace> \ 
--secret-creds <my-aws-cred>

hcp create cluster aws \
--name <hosted-cluster-name> \


--region <region> \


--namespace <hosted-cluster-namespace> \


--secret-creds <my-aws-cred>

Copy to Clipboard

Toggle word wrap

1: ホストされているクラスターの名前を指定します (例: example)。
2: AWS リージョン名を指定します (例: us-east-1)。
3: シークレットがデフォルトの clusters namespace にない場合は、ホストされているクラスター namespace を指定します。
4: AWS シークレット名を指定します (例: my-aws-cred)。

このシークレットを使用すると、以下のフラグはオプションです。これらのフラグを --secret-creds フラグと合わせて指定すると、クラウドプロバイダーのシークレットの値よりも優先されます。

--aws-creds
--base-domain
--pull-secret
--ssh-key

{mce-shortF} コンソールを使用してシークレットを作成するには、ナビゲーションメニューから Credentials を選択し、コンソールで認証情報の作成手順に従います。

コマンドラインでシークレットを作成するには、次のコマンドを入力します。

oc create secret generic <my-secret> -n <namespace> --from-literal=baseDomain=<your-basedomain> --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>", "email":"<your-email>"}, "quay.io":{"auth":"<auth>", "email":"<your-email>"} } }' --from-literal=ssh-publickey=<your-ssh-publickey> --from-literal=ssh-privatekey=<your-ssh-privatekey>

$ oc create secret generic <my-secret> -n <namespace> --from-literal=baseDomain=<your-basedomain> --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>", "email":"<your-email>"}, "quay.io":{"auth":"<auth>", "email":"<your-email>"} } }' --from-literal=ssh-publickey=<your-ssh-publickey> --from-literal=ssh-privatekey=<your-ssh-privatekey>

Copy to Clipboard

Toggle word wrap

シークレットの形式は次のとおりです。

apiVersion: v1
metadata:
  name: my-aws-cred 
  namespace: clusters 
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

apiVersion: v1
metadata:
  name: my-aws-cred


  namespace: clusters


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

Copy to Clipboard

Toggle word wrap

1.7.6.8.2. 関連情報
リンクのコピー

ホステッドクラスターに AWS Elastic File Service (EFS) CSI Driver Operator をインストールする手順は、セキュリティートークンサービスを使用した AWS EFS CSI Driver Operator の設定を参照してください。

1.7.6.9. ARM64 OpenShift Container Platform クラスターで Hosted Control Plane を有効にする (テクノロジープレビュー)
リンクのコピー

ARM64 でホストされるコントロールプレーンを有効にして、管理クラスター環境で OpenShift Container Platform ARM64 データプレーンと連携できるようにすることができます。この機能は、AWS 上の Hosted Control Plane でのみ利用できます。

1.7.6.9.1. 前提条件
リンクのコピー

64 ビット ARM インフラストラクチャーにインストールされた OpenShift Container Platform クラスターが必要です。詳細は、OpenShift クラスターの作成: AWS (ARM) を参照してください。

1.7.6.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
```
```
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
```
Copy to Clipboard Toggle word wrap
この例では、--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
```
```
hcp create nodepool aws \
--cluster-name $CLUSTER_NAME \
--name $NODEPOOL_NAME \
--node-count=$NODEPOOL_REPLICAS
```
Copy to Clipboard Toggle word wrap

1.7.6.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

% 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

Copy to Clipboard

Toggle word wrap

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

hcp create nodepool aws --cluster-name $CLUSTER_NAME --name $ARM64_NODEPOOL_NAME --node-count=$NODEPOOL_REPLICAS --render > arm_nodepool_spec.yml

Copy to Clipboard

Toggle word wrap

このコマンドは、次の例に示すように、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

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

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、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

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

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、レンダリングされた YAML ファイルをホステッドクラスターに適用します。
```
oc apply -f arm_nodepool_spec.yml
```
```
oc apply -f arm_nodepool_spec.yml
```
Copy to Clipboard Toggle word wrap

1.7.6.10. ホステッドクラスターへのアクセス
リンクのコピー

ホステッドクラスターにアクセスするには、kubeconfig ファイルと kubeadmin 認証情報をリソースから直接取得するか、hcp コマンドラインインターフェイスを使用して kubeconfig ファイルを生成します。

リソースから kubeconfig ファイルと認証情報を直接取得し、ホステッドクラスターにアクセスするには、Hosted Control Plane クラスターのアクセスシークレットを理解しておく必要があります。シークレットは、ホステッドクラスター (ホスティング) namespace に保存されます。ホステッドクラスター (ホスティング) namespace にはホステッドクラスターリソースが含まれており、Hosted Control Plane namespace では Hosted Control Plane が実行されます。
シークレット名の形式は次のとおりです。
- kubeconfig シークレット: <hosted-cluster-namespace>-<name>-admin-kubeconfig (clusters-hypershift-demo-admin-kubeconfig)
- kubeadmin パスワードシークレット: <hosted-cluster-namespace>-<name>-kubeadmin-password (clusters-hypershift-demo-kubeadmin-password)
  kubeconfig シークレットには Base64 でエンコードされた kubeconfig フィールドが含まれており、これをデコードしてファイルに保存し、次のコマンドで使用できます。
  oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
  Copy to Clipboard Toggle word wrap
kubeadmin パスワードシークレットも Base64 でエンコードされます。これをデコードし、そのパスワードを使用して、ホステッドクラスターの API サーバーまたはコンソールにログインできます。
hcp CLI を使用してホステッドクラスターにアクセスして kubeconfig ファイルを生成するには、次の手順を実行します。
1. 次のコマンドを入力して、kubeconfig ファイルを生成します。
  hcp create kubeconfig --namespace <hosted-cluster-namespace> --name <hosted-cluster-name> > <hosted-cluster-name>.kubeconfig
  Copy to Clipboard Toggle word wrap
2. kubeconfig ファイルを保存した後、次のコマンド例を入力して、ホステッドクラスターにアクセスできます。
  oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
  Copy to Clipboard Toggle word wrap

1.7.6.10.1. 関連情報
リンクのコピー

ホステッドクラスターへのアクセス後に、ノードプールをスケーリングしたり、ホステッドクラスターのノード自動スケーリングを有効にしたりできます。詳細は、以下のトピックを参照してください。

ノードプールのスケーリング
ホステッドクラスターのノード自動スケーリングの有効化

ホステッドクラスターのノード調整を設定するには、次のトピックを参照してください。

1.7.6.11. プライベートのホステッドクラスターを AWS にデプロイする (テクノロジープレビュー)
リンクのコピー

Hosted Control Plane (hcp) コマンドラインインターフェイスを設定し、ローカルクラスターを ホスティングクラスターとして有効にすると、ホステッドクラスターまたはプライベートのホステッドクラスターを AWS にデプロイできます。パブリックのホステッドクラスターを AWS にデプロイするには、AWS でのホステッドクラスターのデプロイ を参照してください。

デフォルトでは、Hosted Control Plane のゲストクラスターは、パブリック DNS および管理クラスターのデフォルトルーターを通じてパブリックにアクセスできます。

AWS のプライベートクラスターの場合、ゲストクラスターとのすべての通信は AWS PrivateLink 経由で行われます。AWS でプライベートクラスターをサポートするように Hosted Control Plane を設定するには、次の手順を実行します。

重要: パブリッククラスターは任意のリージョンに作成できますが、プライベートクラスターは --aws-private-region で指定されたリージョンにのみ作成できます。

前提条件
AWS 上にプライベートホステッドクラスターを作成する
AWS 上のプライベートホスティングクラスターへのアクセス
関連情報

1.7.6.11.1. 前提条件
リンクのコピー

AWS のプライベートホストクラスターを有効にするには、まず AWS PrivateLink を有効にする必要があります。詳細は、AWS PrivateLink の有効化を参照してください。

1.7.6.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": "\*"
    }
  ]
}

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": "\*"
    }
  ]
}

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、AWS で IAM ポリシーを作成します。

aws iam create-policy --policy-name=hypershift-operator-policy --policy-document=file://policy.json

aws iam create-policy --policy-name=hypershift-operator-policy --policy-document=file://policy.json

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、hypershift-operator IAM ユーザーを作成します。
```
aws iam create-user --user-name=hypershift-operator
```
```
aws iam create-user --user-name=hypershift-operator
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、ポリシーを hypershift-operator ユーザーにアタッチします。<policy-arn> は、作成したポリシーの ARN に置き換えます。
```
aws iam attach-user-policy --user-name=hypershift-operator --policy-arn=<policy-arn>
```
```
aws iam attach-user-policy --user-name=hypershift-operator --policy-arn=<policy-arn>
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、ユーザーの IAM アクセスキーを作成します。
```
aws iam create-access-key --user-name=hypershift-operator
```
```
aws iam create-access-key --user-name=hypershift-operator
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、プライベートホストクラスターを作成します。必要に応じて、変数を実際の値に置き換えます。
```
hcp create cluster aws \
--name <hosted-cluster-name> \ 
--node-pool-replicas=<node-pool-replica-count> \ 
--base-domain <basedomain> \ 
--pull-secret <path-to-pull-secret> \ 
--aws-creds <path-to-aws-credentials> \ 
--region <region> \ 
--endpoint-access Private 
```
```
hcp create cluster aws \
--name <hosted-cluster-name> \ 
```
1
```
--node-pool-replicas=<node-pool-replica-count> \ 
```
2
```
--base-domain <basedomain> \ 
```
3
```
--pull-secret <path-to-pull-secret> \ 
```
4
```
--aws-creds <path-to-aws-credentials> \ 
```
5
```
--region <region> \ 
```
6
```
--endpoint-access Private 
```
7
Copy to Clipboard Toggle word wrap
1 1
ホステッドクラスターの名前を指定します (例: example)。
2 2
ノードプールのレプリカ数を指定します (例: 3)。
3
ベースドメインを指定します (例: example.com)。
4
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
5
AWS 認証情報ファイルへのパスを指定します (例: /user/name/.aws/credentials)。
6
AWS リージョン名を指定します (例: us-east-1)。
7
クラスターがパブリックかプライベートかを定義します。
クラスターの API エンドポイントには、プライベート DNS ゾーンを通じてアクセスできます。
- api.<hosted-cluster-name>.hypershift.local
- *.apps.<hosted-cluster-name>.hypershift.local

1.7.6.11.3. AWS 上のプライベートホスティングクラスターへのアクセス
リンクのコピー

踏み台インスタンスを使用してプライベートクラスターにアクセスできます。

次のコマンドを入力して、踏み台インスタンスを起動します。
```
hypershift create bastion aws --aws-creds=<aws-creds> --infra-id=<infra-id> --region=<region> --ssh-key-file=<ssh-key>
```
```
hypershift create bastion aws --aws-creds=<aws-creds> --infra-id=<infra-id> --region=<region> --ssh-key-file=<ssh-key>
```
Copy to Clipboard Toggle word wrap
<ssh-key> を、踏み台に接続するための SSH 公開鍵ファイルに置き換えます。SSH 公開鍵ファイルのデフォルトの場所は ~/.ssh/id_rsa.pub です。<aws-creds> を AWS 認証情報ファイルへのパスに置き換えます (例: /user/name/.aws/credentials)。

注記: hypershift CLI はダウンロードできません。次のコマンドを使用して、hypershift namespace に存在する HyperShift Operator Pod を使用して CLI を抽出してください。<hypershift-operator-pod-name> は、HyperShift Operator Pod 名に置き換えてください。

oc project hypershift
oc rsync <hypershift-operator-pod-name>:/usr/bin/hypershift-no-cgo .
mv hypershift-no-cgo hypershift

oc project hypershift
oc rsync <hypershift-operator-pod-name>:/usr/bin/hypershift-no-cgo .
mv hypershift-no-cgo hypershift

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、クラスターノードプール内のノードのプライベート IP を検索します。

aws ec2 describe-instances --filter="Name=tag:kubernetes.io/cluster/<infra-id>,Values=owned" | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") | .PrivateIpAddress'

aws ec2 describe-instances --filter="Name=tag:kubernetes.io/cluster/<infra-id>,Values=owned" | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") | .PrivateIpAddress'

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、ノードにコピーできるクラスターの kubeconfig ファイルを作成します。
```
hcp create kubeconfig > <cluster-kubeconfig>
```
```
hcp create kubeconfig > <cluster-kubeconfig>
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、create bastion コマンドから出力された IP を使用して踏み台を介していずれかのノードに SSH 接続します。
```
ssh -o ProxyCommand="ssh ec2-user@<bastion-ip> -W %h:%p" core@<node-ip>
```
```
ssh -o ProxyCommand="ssh ec2-user@<bastion-ip> -W %h:%p" core@<node-ip>
```
Copy to Clipboard Toggle word wrap
SSH シェルから、次のコマンドを入力して、kubeconfig ファイルの内容をノード上のファイルにコピーします。
```
mv <path-to-kubeconfig-file> <new-file-name>
```
```
mv <path-to-kubeconfig-file> <new-file-name>
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、kubeconfig ファイルをエクスポートします。
```
export KUBECONFIG=<path-to-kubeconfig-file>
```
```
export KUBECONFIG=<path-to-kubeconfig-file>
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、ゲストクラスターのステータスを確認します。
```
oc get clusteroperators clusterversion
```
```
oc get clusteroperators clusterversion
```
Copy to Clipboard Toggle word wrap

1.7.6.11.4. 関連情報
リンクのコピー

AWS でのパブリックホステッドクラスターのデプロイの詳細は、AWS でのホステッドクラスターのデプロイを参照してください。

1.7.6.12. AWS インフラストラクチャーと Hosted Control Plane の IAM 権限の管理 (テクノロジープレビュー)
リンクのコピー

AWS で Red Hat OpenShift Container Platform のホストされているコントロールプレーンを使用する場合、インフラストラクチャーの要件はセットアップに応じて異なります。

前提条件
AWS インフラストラクチャーの要件
ID とアクセス管理の権限
AWS インフラストラクチャーと IAM リソースを個別に作成する

1.7.6.12.1. 前提条件
リンクのコピー

Hosted Control Plane クラスターを作成する前に、Hosted Control Plane を設定する必要があります。詳細は、AWS での Hosted Control Plane クラスターの設定 (テクノロジープレビュー) を参照してください。

1.7.6.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.6.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.6.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.6.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.6.12.2.4. ホステッドクラスター内の Hosted Control Plane 管理インフラストラクチャー AWS アカウント
リンクのコピー

インフラストラクチャーがホステッドクラスター AWS アカウントの Hosted Control Plane によって管理されている場合、インフラストラクチャー要件は、クラスターがパブリック、プライベート、またはその組み合わせであるかによって異なります。

パブリッククラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。

ノードプールには、Role と RolePolicy が定義された EC2 インスタンスが必要です。

プライベートクラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。

アベイラビリティーゾーンごとに 1 つのプライベートリンクエンドポイント
ノードプールの EC2 インスタンス

パブリッククラスターとプライベートクラスターを持つアカウントの場合、インフラストラクチャー要件は次のとおりです。

アベイラビリティーゾーンごとに 1 つのプライベートリンクエンドポイント
ノードプールの EC2 インスタンス

1.7.6.12.2.5. ホステッドクラスターの Kubernetes 管理インフラストラクチャー AWS アカウント
リンクのコピー

Kubernetes がホステッドクラスター AWS アカウントでインフラストラクチャーを管理する場合、インフラストラクチャー要件は次のとおりです。

デフォルトの Ingress 用のネットワークロードバランサー
レジストリー用の S3 バケット

1.7.6.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
...

...
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
...

Copy to Clipboard

Toggle word wrap

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"
            ]
        }
    ]
}

{
    "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"
            ]
        }
    ]
}

Copy to Clipboard

Toggle word wrap

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": "\*"
        }
    ]
}

{
    "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": "\*"
        }
    ]
}

Copy to Clipboard

Toggle word wrap

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": "\*"
        }
    ]
}

{
    "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": "\*"
        }
    ]
}

Copy to Clipboard

Toggle word wrap

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": "\*"
        }
    ]
}

{
    "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": "\*"
        }
    ]
}

Copy to Clipboard

Toggle word wrap

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"
        }
    ]
}

{
    "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"
        }
    ]
}

Copy to Clipboard

Toggle word wrap

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"
        }
    ]
}

{
    "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"
        }
    ]
}

Copy to Clipboard

Toggle word wrap

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"
        }
    ]
}

{
    "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"
        }
    ]
}

Copy to Clipboard

Toggle word wrap

1.7.6.12.4. AWS インフラストラクチャーと IAM リソースを個別に作成する
リンクのコピー

デフォルトでは、hcp create cluster aws コマンドは、ホステッドクラスターを使用してクラウドインフラストラクチャーを作成し、それを適用します。クラウドインフラストラクチャー部分を個別に作成して、hcp create cluster aws コマンドをクラスターの作成のみに使用したり、クラスターを適用する前に変更できるようにレンダリングしたりすることができます。

クラウドインフラストラクチャー部分を個別に作成するには、AWS インフラストラクチャーを作成し、AWS Identity and Access (IAM) リソースを作成し、クラスターを作成する必要があります。

1.7.6.12.4.1. AWS インフラストラクチャーの作成
リンクのコピー

AWS インフラストラクチャーを作成するには、次のコマンドを入力します。

hypershift create infra aws --name CLUSTER_NAME \ 
    --aws-creds AWS_CREDENTIALS_FILE \ 
    --base-domain BASEDOMAIN \ 
    --infra-id INFRA_ID \ 
    --region REGION \ 
    --output-file OUTPUT_INFRA_FILE

hypershift create infra aws --name CLUSTER_NAME \


    --aws-creds AWS_CREDENTIALS_FILE \


    --base-domain BASEDOMAIN \


    --infra-id INFRA_ID \


    --region REGION \


    --output-file OUTPUT_INFRA_FILE

Copy to Clipboard

Toggle word wrap

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 リソースのフィールドに値を設定できます。

oc project hypershift
oc rsync <hypershift-operator-pod-name>:/usr/bin/hypershift-no-cgo .
mv hypershift-no-cgo hypershift

oc project hypershift
oc rsync <hypershift-operator-pod-name>:/usr/bin/hypershift-no-cgo .
mv hypershift-no-cgo hypershift

Copy to Clipboard

Toggle word wrap

コマンドを入力すると、次のリソースが作成されます。

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.6.12.4.2. AWS IAM リソースの作成
リンクのコピー

AWS IAM リソースを作成するには、次のコマンドを入力します。

hypershift create iam aws --infra-id INFRA_ID \ 
    --aws-creds AWS_CREDENTIALS_FILE \ 
    --oidc-storage-provider-s3-bucket-name OIDC_BUCKET_NAME \ 
    --oidc-storage-provider-s3-region OIDC_BUCKET_REGION \ 
    --region REGION \ 
    --public-zone-id PUBLIC_ZONE_ID \ 
    --private-zone-id PRIVATE_ZONE_ID \ 
    --local-zone-id LOCAL_ZONE_ID \ 
    --output-file OUTPUT_IAM_FILE

hypershift create iam aws --infra-id INFRA_ID \


    --aws-creds AWS_CREDENTIALS_FILE \


    --oidc-storage-provider-s3-bucket-name OIDC_BUCKET_NAME \


    --oidc-storage-provider-s3-region OIDC_BUCKET_REGION \


    --region REGION \


    --public-zone-id PUBLIC_ZONE_ID \


    --private-zone-id PRIVATE_ZONE_ID \


    --local-zone-id LOCAL_ZONE_ID \


    --output-file OUTPUT_IAM_FILE

Copy to Clipboard

Toggle word wrap

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.6.12.4.3. クラスターの作成
リンクのコピー

クラスターを作成するには、次のコマンドを入力します。

hcp create cluster aws \
    --infra-id INFRA_ID \ 
    --name CLUSTER_NAME \ 
    --aws-creds AWS_CREDENTIALS \ 
    --pull-secret PULL_SECRET_FILE \ 
    --generate-ssh \ 
    --node-pool-replicas 3

hcp create cluster aws \
    --infra-id INFRA_ID \


    --name CLUSTER_NAME \


    --aws-creds AWS_CREDENTIALS \


    --pull-secret PULL_SECRET_FILE \


    --generate-ssh \


    --node-pool-replicas 3

Copy to Clipboard

Toggle word wrap

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.6.13. AWS でのホステッドクラスターの破棄
リンクのコピー

ホステッドクラスターとそのマネージドクラスターリソースを破棄するには、次の手順を実行します。

次のコマンドを実行して、マルチクラスターエンジン Operator のマネージドクラスターリソースを削除します。
```
oc delete managedcluster <managed_cluster_name>
```
```
oc delete managedcluster <managed_cluster_name>
```
Copy to Clipboard Toggle word wrap
ここで、<managed_cluster_name> は管理対象クラスターの名前です。

次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。

hcp destroy cluster aws --name <hosted_cluster_name> --infra-id <infra_id> --aws-creds <path_to_aws_creds> --base-domain <basedomain>

hcp destroy cluster aws --name <hosted_cluster_name> --infra-id <infra_id> --aws-creds <path_to_aws_creds> --base-domain <basedomain>

Copy to Clipboard

Toggle word wrap

必要に応じて名前を置き換えます。

1.7.7. ベアメタルでの Hosted Control Plane クラスターの設定
リンクのコピー

ホスティングクラスターとして機能するようにクラスターを設定することで、Hosted Control Plane をデプロイメントできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。ホスティングクラスターは管理クラスターとも呼ばれます。

注記: 管理クラスターは、マネージド クラスターとは異なります。マネージドクラスターは、ハブクラスターが管理するクラスターです。

Hosted Control Plane 機能がデフォルトで有効になりました。

マルチクラスターエンジン Operator 2.5 は、管理対象のハブクラスターであるデフォルトの local-cluster と、ホスティングクラスターとしてのハブクラスターのみをサポートします。Red Hat Advanced Cluster Management 2.10 では、マネージドハブクラスター (local-cluster) をホスティングクラスターとして使用できます。

重要:

Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
各ホステッドクラスターに、クラスター全体で一意の名前が必要です。マルチクラスターエンジン Operator によってホストクラスターを管理するには、ホストクラスター名を既存のマネージドクラスターと同じにすることはできません。
ホステッドクラスター名として clusters を使用しないでください。
ホステッドクラスターは、マルチクラスターエンジンの operator 管理クラスターの namespace には作成できません。
エージェントプラットフォームを使用して、Hosted Control Plane をベアメタルでプロビジョニングできます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。Central Infrastructure Management の概要は、central infrastructure management の有効化を参照してください。
すべてのベアメタルホストでは、Central Infrastructure Management が提供する検出イメージ ISO を使用して手動でブートする必要があります。ホストは手動で起動することも、Cluster-Baremetal-Operator を使用して自動化することもできます。各ホストが起動すると、エージェントプロセスが実行され、ホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。
Agent プラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。
ノードプールによってレプリカをスケーリングすると、マシンが作成されます。クラスター API プロバイダーは、すべてのマシンに対して、ノードプール仕様で指定された要件を満たすエージェントを見つけてインストールします。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。Agent を再利用するには、Discovery イメージを使用してエージェントを再起動する必要があります。
Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、OpenShift Container Platform ドキュメントの 推奨される etcd プラクティス および 論理ボリュームマネージャーストレージを使用した永続ストレージ を参照してください。

1.7.7.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
```
```
oc get managedclusters local-cluster
```
Copy to Clipboard Toggle word wrap
管理クラスター上のベアメタルホストに topology.kubernetes.io/zone ラベルを追加する必要があります。そうしないと、すべての Hosted Control Plane Pod が単一ノードでスケジュールされ、単一障害点が発生します。
Central Infrastructure Management を有効にする必要があります。詳細は、Central Infrastructure Management サービスの有効化を参照してください。
Hosted Control Plane コマンドラインインターフェイスをインストールする必要があります。
ホステッドクラスター API エンドポイントに到達するためのプロキシー設定を持つハブクラスターの場合は、すべてのホステッドクラスター API エンドポイントをプロキシーオブジェクトの noProxy フィールドに追加します。詳細は、クラスター全体のプロキシーの設定を参照してください。

1.7.7.2. ベアメタルファイアウォール、ポート、およびサービスの要件
リンクのコピー

管理クラスター、コントロールプレーン、ホストされたクラスター間でポートの通信ができるように、ファイアウォール、ポート、およびサービスの要件を満たす必要があります。

注記: サービスはデフォルトのポートで実行されます。ただし、NodePort 公開ストラテジーを使用する場合、サービスは NodePort サービスによって割り当てられたポートで実行されます。

ファイアウォールルール、セキュリティーグループ、またはその他のアクセス制御を使用して、必要なソースだけにアクセスを制限します。必要な場合を除き、ポートを公開しないでください。実稼働環境の場合は、ロードバランサーを使用して、単一の IP アドレスによるアクセスを簡素化します。

Hosted Control Plane はベアメタル上で次のサービスを公開します。

APIServer
- APIServer サービスはデフォルトでポート 6443 で実行され、コントロールプレーンコンポーネント間の通信には ingress アクセスが必要です。
- MetalLB ロードバランシングを使用する場合は、ロードバランサーの IP アドレスに使用される IP 範囲への ingress アクセスを許可します。
OAuthServer
- ルートと Ingress を使用してサービスを公開する場合、OAuthServer サービスはデフォルトでポート 443 で実行されます。
- NodePort 公開ストラテジーを使用する場合は、OAuthServer サービスにファイアウォールルールを使用します。
Konnectivity
- ルートと Ingress を使用してサービスを公開する場合、Konnectivity サービスはデフォルトでポート 443 で実行されます。
- Konnectivity エージェントは、ホステッドクラスター上で双方向通信を可能にするリバーストンネルを確立し、ポート 6443 でクラスター API サーバーアドレスへの egress アクセスを必要とします。この egress アクセスを使用すると、エージェントは APIServer サービスにアクセスできます。
- クラスター API サーバーのアドレスが内部 IP アドレスの場合は、ワークロードサブネットからポート 6443 の IP アドレスへのアクセスを許可します。
- アドレスが外部 IP アドレスの場合は、ノードからその外部 IP アドレスにポート 6443 で送信できるように許可します。
Ignition
- ルートと Ingress を使用してサービスを公開する場合、Ignition サービスはデフォルトでポート 443 で実行されます。
- NodePort 公開ストラテジーを使用する場合は、Ignition サービスにファイアウォールルールを使用します。

ベアメタルで以下のサービスは必要ありません。

OVNSbDb
OIDC

1.7.7.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.7.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

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

Copy to Clipboard

Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

デュアルスタックネットワークの非接続環境で 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]

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]

Copy to Clipboard

Toggle word wrap

次に、ベアメタルに Hosted Control Plane のホストインベントリーを作成します。

1.7.7.5. ベアメタルでのホステッドクラスターの作成
リンクのコピー

ベアメタルでホステッドクラスターを作成するか、インポートできます。ホステッドクラスターをインポートする手順は、ホステッドクラスターのインポート を参照してください。

次のコマンドを入力して、Hosted Control Plane namespace を作成します。
```
oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>
```
```
oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>
```
Copy to Clipboard Toggle word wrap
<hosted_cluster_namespace> を、ホストされたクラスターの namespace 名 (例: clusters) に置き換えます。<hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
クラスターにデフォルトのストレージクラスが設定されていることを確認します。そうしないと、保留中の PVC が表示される場合があります。以下のコマンドを実行します。
```
hcp create cluster agent \
    --name=<hosted_cluster_name> \ 
    --pull-secret=<path_to_pull_secret> \ 
    --agent-namespace=<hosted_control_plane_namespace> \ 
    --base-domain=<basedomain> \ 
    --api-server-address=api.<hosted_cluster_name>.<basedomain> \
    --etcd-storage-class=<etcd_storage_class> \ 
    --ssh-key  <path_to_ssh_public_key> \ 
    --namespace <hosted_cluster_namespace> \ 
    --control-plane-availability-policy SingleReplica \
    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> 
```
```
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
Copy to Clipboard Toggle word wrap
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

oc -n <hosted_control_plane_namespace> get pods

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

1.7.7.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.7.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

- 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

Copy to Clipboard

Toggle word wrap

ファイルを icsp.yaml として保存します。このファイルにはミラーレジストリーが含まれます。
ミラーレジストリーを使用してホステッドクラスターを作成するには、次のコマンドを実行します。
```
hcp create cluster agent \
    --name=<hosted_cluster_name> \ 
    --pull-secret=<path_to_pull_secret> \ 
    --agent-namespace=<hosted_control_plane_namespace> \ 
    --base-domain=<basedomain> \ 
    --api-server-address=api.<hosted_cluster_name>.<basedomain> \
    --image-content-sources icsp.yaml  \ 
    --ssh-key  <path_to_ssh_key> \ 
    --namespace <hosted_cluster_namespace> \ 
    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> 
```
```
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
Copy to Clipboard Toggle word wrap
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.7.5.3. 関連情報
リンクのコピー

コンソールでホステッドクラスターを作成するときに再利用できる認証情報を作成するには、オンプレミス環境の認証情報の作成を参照してください。
ホステッドクラスターをインポートするには、Hosted Control Plane クラスターの手動インポートを参照してください。
ホステッドクラスターにアクセスするには、ホステッドクラスターへのアクセスを参照してください。
Discovery Image を使用してホストインベントリーにホストを追加するには、Discovery Image を使用したホストインベントリーへのホストの追加を参照してください。
OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出を参照してください。

1.7.7.6. ホステッドクラスター作成の確認
リンクのコピー

デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。

次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。

oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

Copy to Clipboard

Toggle word wrap

kubeconfig を使用して、ホステッドクラスターのクラスター Operator を表示します。以下のコマンドを入力します。

oc get co --kubeconfig=kubeconfig-<hosted-cluster-name>

oc get co --kubeconfig=kubeconfig-<hosted-cluster-name>

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.10.26   True        False         False      2m38s
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

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.10.26   True        False         False      2m38s
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

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、ホステッドクラスター上で実行中の Pod を表示することもできます。

oc get pods -A --kubeconfig=kubeconfig-<hosted-cluster-name>

oc get pods -A --kubeconfig=kubeconfig-<hosted-cluster-name>

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
openshift-cluster-node-tuning-operator             tuned-dhw5p                                               1/1     Running            0               109s
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-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-kfqnh                                         2/2     Running            0               113s

NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
openshift-cluster-node-tuning-operator             tuned-dhw5p                                               1/1     Running            0               109s
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-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-kfqnh                                         2/2     Running            0               113s

Copy to Clipboard

Toggle word wrap

1.7.7.7. ホステッドクラスターの NodePool オブジェクトのスケーリング
リンクのコピー

ホストされたクラスターにノードを追加することで、NodePool オブジェクトをスケールアップできます。

NodePool オブジェクトを 2 つのノードにスケーリングします。
```
oc -n <hosted-cluster-namespace> scale nodepool <nodepool-name> --replicas 2
```
```
oc -n <hosted-cluster-namespace> scale nodepool <nodepool-name> --replicas 2
```
Copy to Clipboard Toggle word wrap
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

oc -n <hosted-control-plane-namespace> get agent

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

以下のコマンドを入力します。

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}'

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}'

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

Copy to Clipboard

Toggle word wrap

エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、ホステッドクラスターの OpenShift Container Platform ノードが表示されることを確認します。
```
oc --kubeconfig kubeconfig-<hosted-cluster-name> get nodes
```
```
oc --kubeconfig kubeconfig-<hosted-cluster-name> get nodes
```
Copy to Clipboard Toggle word wrap
以下の出力例を参照してください。
```
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
```
```
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
```
Copy to Clipboard Toggle word wrap
Cluster Operator は、ワークロードをノードに追加することによって調整を開始します。

次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。

oc -n <hosted-control-plane-namespace> get machines

oc -n <hosted-control-plane-namespace> get machines

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.13z
hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.13z

NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.13z
hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.13z

Copy to Clipboard

Toggle word wrap

clusterversion 調整プロセスは最終的に、Ingress および Console クラスター Operator のみが欠落しているポイントに到達します。

以下のコマンドを入力します。

oc --kubeconfig kubeconfig-<hosted-cluster-name> get clusterversion,co

oc --kubeconfig kubeconfig-<hosted-cluster-name> get clusterversion,co

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.13z: 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

NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.13z: 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

Copy to Clipboard

Toggle word wrap

1.7.7.7.1. ノードプールの追加
リンクのコピー

名前、レプリカの数、およびエージェントラベルセレクターなどの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。

ノードプールを作成するには、次の情報を入力します。

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"}}'

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"}}'

Copy to Clipboard

Toggle word wrap

1: --agentLabelSelector は任意です。ノードプールは、"size" : "medium" ラベルを持つエージェントを使用します。

clusters namespace 内の nodepool リソースをリスト表示して、ノードプールのステータスを確認します。
```
oc get nodepools --namespace clusters
```
```
oc get nodepools --namespace clusters
```
Copy to Clipboard Toggle word wrap

次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。

oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm

oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

hostedcluster-secrets/kubeconfig

hostedcluster-secrets/kubeconfig

Copy to Clipboard

Toggle word wrap

しばらくしてから、次のコマンドを入力してノードプールのステータスを確認できます。
```
oc --kubeconfig ./hostedcluster-secrets get nodes
```
```
oc --kubeconfig ./hostedcluster-secrets get nodes
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、使用可能なノードプールの数が予想されるノードプールの数と一致することを確認します。
```
oc get nodepools --namespace clusters
```
```
oc get nodepools --namespace clusters
```
Copy to Clipboard Toggle word wrap

1.7.7.7.2. 関連情報
リンクのコピー

データプレーンをゼロにスケールダウンするには、データプレーンをゼロにスケールダウンするを参照してください。

1.7.7.8. ベアメタル上のホステッドクラスターでの Ingress の処理
リンクのコピー

すべての OpenShift Container Platform クラスターには、通常、外部 DNS レコードが関連付けられているデフォルトのアプリケーション Ingress コントローラーがあります。たとえば、ベースドメイン krnl.es で example という名前のホストされたクラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es がルーティング可能であると予想することができます。

*.apps ドメインのロードバランサーとワイルドカード DNS レコードを設定するには、ゲストクラスターで次のアクションを実行します。

MetalLB Operator の設定を含む YAML ファイルを作成して MetalLB をデプロイします。

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

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

Copy to Clipboard

Toggle word wrap

ファイルを metallb-operator-config.yaml として保存します。
以下のコマンドを入力して設定を適用します。
```
oc apply -f metallb-operator-config.yaml
```
```
oc apply -f metallb-operator-config.yaml
```
Copy to Clipboard Toggle word wrap
Operator の実行後、MetalLB インスタンスを作成します。
1. MetalLB インスタンスの設定を含む YAML ファイルを作成します。
  apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb
  Copy to Clipboard Toggle word wrap
2. ファイルを metallb-instance-config.yaml として保存します。
3. 次のコマンドを入力して、MetalLB インスタンスを作成します。
```
oc apply -f metallb-instance-config.yaml
```
```
oc apply -f metallb-instance-config.yaml
```
Copy to Clipboard Toggle word wrap

2 つのリソースを作成して MetalLB Operator を設定します。

単一の IP アドレスを持つ IPAddressPool リソース。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。
IPAddressPool リソースが BGP プロトコルを通じて提供するロードバランサーの IP アドレスをアドバタイズするための BGP アドバタイズリソース。
1. 設定を含む YAML ファイルを作成します。

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: <ip_address_pool_name> 
  namespace: metallb
spec:
  protocol: layer2
  autoAssign: false
  addresses:
    - <ingress_ip>-<ingress_ip> 
---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: <bgp_advertisement_name> 
  namespace: metallb
spec:
  ipAddressPools:
    - <ip_address_pool_name>

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: <ip_address_pool_name>


  namespace: metallb
spec:
  protocol: layer2
  autoAssign: false
  addresses:
    - <ingress_ip>-<ingress_ip>


---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: <bgp_advertisement_name>


  namespace: metallb
spec:
  ipAddressPools:
    - <ip_address_pool_name>

Copy to Clipboard

Toggle word wrap

1 4

IPAddressPool リソース名を指定します。

環境の IP アドレスを指定します (例: 192.168.122.23)。

BGPAdvertisement リソース名を指定します。

ファイルを ipaddresspool-bgpadvertisement-config.yaml として保存します。
次のコマンドを入力してリソースを作成します。
```
oc apply -f ipaddresspool-bgpadvertisement-config.yaml
```
```
oc apply -f ipaddresspool-bgpadvertisement-config.yaml
```
Copy to Clipboard Toggle word wrap
1. LoadBalancer タイプのサービスを作成すると、MetalLB はサービスに外部 IP アドレスを追加します。

metallb-loadbalancer-service.yaml という名前の YAML ファイルを作成して、Ingress トラフィックを Ingress デプロイメントにルーティングする新しいロードバランサーサービスを設定します。

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

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

Copy to Clipboard

Toggle word wrap

metallb-loadbalancer-service.yaml ファイルを保存します。
YAML 設定を適用するには、次のコマンドを入力します。
```
oc apply -f metallb-loadbalancer-service.yaml
```
```
oc apply -f metallb-loadbalancer-service.yaml
```
Copy to Clipboard Toggle word wrap

次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。

curl -kI https://console-openshift-console.apps.example.krnl.es

HTTP/1.1 200 OK

curl -kI https://console-openshift-console.apps.example.krnl.es

HTTP/1.1 200 OK

Copy to Clipboard

Toggle word wrap

clusterversion と clusteroperator の値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。
```
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
```
```
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
```
Copy to Clipboard Toggle word wrap
以下の出力例を参照してください。

NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.x.y      True        False         3m32s   Cluster version is 4.x.y

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.x.y     True        False         False      3m50s
clusteroperator.config.openshift.io/ingress                                    4.x.y     True        False         False      53m

NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.x.y      True        False         3m32s   Cluster version is 4.x.y

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.x.y     True        False         False      3m50s
clusteroperator.config.openshift.io/ingress                                    4.x.y     True        False         False      53m

Copy to Clipboard

Toggle word wrap

+ 4.x.y は、使用する OpenShift Container Platform サポート対象バージョン (例: 4.14.0-x86_64 に置き換えます。

1.7.7.8.1. 関連情報
リンクのコピー

MetalLB の詳細は、OpenShift Container Platform ドキュメントの MetalLB および MetalLB Operator についてを参照してください。

1.7.7.9. ホステッドクラスターのノード自動スケーリングの有効化
リンクのコピー

ホステッドクラスターにさらに容量が必要で、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいワーカーノードをインストールできます。

自動スケーリングを有効にするには、次のコマンドを入力します。

oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'

oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'

Copy to Clipboard

Toggle word wrap

注記: この例では、ノードの最小数は 2、最大数は 5 です。追加できるノードの最大数は、プラットフォームによって制限される場合があります。たとえば、エージェントプラットフォームを使用する場合、ノードの最大数は使用可能なエージェントの数によって制限されます。

新しいノードを必要とするワークロードを作成します。

次の例を使用して、ワークロード設定を含む 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: {}

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: {}

Copy to Clipboard

Toggle word wrap

ファイルを workload-config.yaml として保存します。
以下のコマンドを入力して、YAML を適用します。

oc apply -f workload-config.yaml

oc apply -f workload-config.yaml

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

hostedcluster-secrets/kubeconfig

hostedcluster-secrets/kubeconfig

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、新しいノードが Ready ステータスであるかどうかを確認できます。
```
oc --kubeconfig ./hostedcluster-secrets get nodes
```
```
oc --kubeconfig ./hostedcluster-secrets get nodes
```
Copy to Clipboard Toggle word wrap

ノードを削除するには、次のコマンドを入力してワークロードを削除します。

oc --kubeconfig ./hostedcluster-secrets -n default delete deployment reversewords

oc --kubeconfig ./hostedcluster-secrets -n default delete deployment reversewords

Copy to Clipboard

Toggle word wrap

数分間待ちます。その間に、容量の追加が必要にならないようにします。エージェントプラットフォームでは、エージェントは廃止され、再利用できます。次のコマンドを入力すると、ノードが削除されたことを確認できます。
```
oc --kubeconfig ./hostedcluster-secrets get nodes
```
```
oc --kubeconfig ./hostedcluster-secrets get nodes
```
Copy to Clipboard Toggle word wrap

1.7.7.9.1. ホストされたクラスターのノードの自動スケーリングを無効にする
リンクのコピー

ノードの自動スケーリングを無効にするには、次のコマンドを入力します。

oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify-value-to-scale-replicas>]'

oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify-value-to-scale-replicas>]'

Copy to Clipboard

Toggle word wrap

このコマンドは、YAML ファイルから "spec.autoScaling" を削除し、"spec.replicas" を追加し、"spec.replicas" を指定の整数値に設定します。

1.7.7.10. ベアメタルでのホステッドクラスターの破棄
リンクのコピー

コンソールを使用して、ベアメタルホステッドクラスターを破棄できます。ベアメタル上のホステッドクラスターを破壊するには、次の手順を実行します。

コンソールで、Infrastructure > Clusters に移動します。
Clusters ページで、破棄するクラスターを選択します。
Actions メニューで Destroy clusters を選択し、クラスターを削除します。

1.7.7.10.1. コマンドラインを使用したベアメタル上でのホステッドクラスターの破棄
リンクのコピー

ホステッドクラスターを破棄するには、次の手順を実行します。

次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。
```
hcp destroy cluster agent --name <hosted_cluster_name>
```
```
hcp destroy cluster agent --name <hosted_cluster_name>
```
Copy to Clipboard Toggle word wrap
<hosted_cluster_name> をホストされたクラスターの名前に置き換えます。

1.7.8. 非ベアメタルエージェントマシンを使用した Hosted Control Plane クラスターの設定 (テクノロジープレビュー)
リンクのコピー

注記: 管理クラスターは、マネージド クラスターとは異なります。マネージドクラスターは、ハブクラスターが管理するクラスターです。

Hosted Control Plane 機能がデフォルトで有効になりました。

重要:

各ホステッドクラスターに、クラスター全体で一意の名前が必要です。マルチクラスターエンジン Operator によってホストクラスターを管理するには、ホストクラスター名を既存のマネージドクラスターと同じにすることはできません。
ホステッドクラスター名として clusters を使用しないでください。
Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
ホステッドクラスターは、マルチクラスターエンジンの operator 管理クラスターの namespace には作成できません。
エージェントプラットフォームを使用して、エージェントマシンをワーカーノードとしてホステッドクラスターに追加できます。エージェントマシンは、Discovery Image でブートされ、OpenShift Container Platform ノードとしてプロビジョニングされる準備ができているホストを表します。Agent プラットフォームは、Central Infrastructure Management サービスの一部です。詳細は、Central Infrastructure Management サービスの有効化を参照してください。
ベアメタルではないすべてのホストは、Central Infrastructure Management が提供する Discovery Image ISO を使用して手動でブートする必要があります。
Agent プラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。
ノードプールをスケールアップすると、レプリカごとにマシンが作成されます。Cluster API プロバイダーは、マシンごとに、承認済みで、検証に合格し、現在使用されておらず、ノードプール仕様で指定されている要件を満たしているエージェントを検索してインストールします。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。Agent を再利用するには、Discovery イメージを使用してエージェントを再起動する必要があります。
Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、OpenShift Container Platform ドキュメントの 推奨される etcd プラクティス および 論理ボリュームマネージャーストレージを使用した永続ストレージ を参照してください。

1.7.8.1. 前提条件
リンクのコピー

ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。

OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.5 以降のマルチクラスターエンジン。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。OpenShift Container Platform OperatorHub から Operator として Red Hat Advanced Cluster Management を使用せずに、マルチクラスターエンジン Operator をインストールすることもできます。
マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。local-cluster は自動的にインポートされます。local-cluster の詳細については、詳細設定を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。
```
oc get managedclusters local-cluster
```
```
oc get managedclusters local-cluster
```
Copy to Clipboard Toggle word wrap
Central Infrastructure Management を有効にする必要があります。詳細は、Central Infrastructure Management サービスの有効化を参照してください。
Hosted Control Plane コマンドラインインターフェイスをインストールする必要があります。

1.7.8.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.8.3. 非ベアメタルエージェントマシンのインフラストラクチャー要件
リンクのコピー

エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャーに関して次の要件があります。

Agent: Agent は、Discovery イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングされる準備ができているホストを表します。
DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

1.7.8.4. 非ベアメタルエージェントマシンでの DNS の設定
リンクのコピー

ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達できる宛先を指す api.<hosted-cluster-name>.<basedomain> に、DNS エントリーが存在する必要があります。

次の DNS 設定の例を参照してください。

api-int.example.krnl.es.    IN A 192.168.122.22
`*`.apps.example.krnl.es. IN A 192.168.122.23

api-int.example.krnl.es.    IN A 192.168.122.22
`*`.apps.example.krnl.es. IN A 192.168.122.23

Copy to Clipboard

Toggle word wrap

IPv6 ネットワークで非接続環境の DNS を設定する場合は、次の DNS 設定の例を参照してください。

api-int.example.krnl.es.    IN A 2620:52:0:1306::7
`*`.apps.example.krnl.es. IN A 2620:52:0:1306::10

api-int.example.krnl.es.    IN A 2620:52:0:1306::7
`*`.apps.example.krnl.es. IN A 2620:52:0:1306::10

Copy to Clipboard

Toggle word wrap

host-record=api-int.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]

host-record=api-int.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]

Copy to Clipboard

Toggle word wrap

1.7.8.5. 非ベアメタルエージェントマシンでのホステッドクラスターの作成
リンクのコピー

ホステッドクラスターの作成やインポートが可能です。ホステッドクラスターをインポートする手順は、ホステッドクラスターのインポート を参照してください。

次のコマンドを入力して、Hosted Control Plane namespace を作成します。
```
oc create ns <hosted-cluster-namespace>-<hosted-cluster-name>
```
```
oc create ns <hosted-cluster-namespace>-<hosted-cluster-name>
```
Copy to Clipboard Toggle word wrap
<hosted-cluster-namespace> を、ホストされたクラスターの namespace 名 (例: clusters) に置き換えます。<hosted-cluster-name> をホストされたクラスター名に置き換えます。
クラスターにデフォルトのストレージクラスが設定されていることを確認します。設定されていない場合は、PVC が保留になる可能性があります。次のコマンドを入力し、変数例を実際の情報に置き換えます。
```
hcp create cluster agent \
    --name=<hosted-cluster-name> \ 
    --pull-secret=<path-to-pull-secret> \ 
    --agent-namespace=<hosted-control-plane-namespace> \ 
    --base-domain=<basedomain> \ 
    --api-server-address=api.<hosted-cluster-name>.<basedomain> \
    --etcd-storage-class=<etcd-storage-class> \ 
    --ssh-key  <path-to-ssh-key> \ 
    --namespace <hosted-cluster-namespace> \ 
    --control-plane-availability-policy SingleReplica \
    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp-release> 
```
```
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-key> \ 
```
6
```
    --namespace <hosted-cluster-namespace> \ 
```
7
```
    --control-plane-availability-policy SingleReplica \
    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp-release> 
```
8
Copy to Clipboard Toggle word wrap
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)。

しばらくしてから、次のコマンドを入力して、Hosted Control Plane の Pod が稼働中であることを確認します。

oc -n <hosted-control-plane-namespace> get pods

oc -n <hosted-control-plane-namespace> get pods

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                                             READY   STATUS    RESTARTS   AGE
catalog-operator-6cd867cc7-phb2q                 2/2     Running   0          2m50s
control-plane-operator-f6b4c8465-4k5dh           1/1     Running   0          4m32s

NAME                                             READY   STATUS    RESTARTS   AGE
catalog-operator-6cd867cc7-phb2q                 2/2     Running   0          2m50s
control-plane-operator-f6b4c8465-4k5dh           1/1     Running   0          4m32s

Copy to Clipboard

Toggle word wrap

1.7.8.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.8.5.2. 関連情報
リンクのコピー

コンソールでホステッドクラスターを作成するときに再利用できる認証情報を作成するには、オンプレミス環境の認証情報の作成を参照してください。
ホステッドクラスターをインポートするには、Hosted Control Plane クラスターの手動インポートを参照してください。
ホステッドクラスターにアクセスするには、ホステッドクラスターへのアクセスを参照してください。
Discovery Image を使用してホストインベントリーにホストを追加するには、Discovery Image を使用したホストインベントリーへのホストの追加を参照してください。

1.7.8.6. ホステッドクラスター作成の確認
リンクのコピー

次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

Copy to Clipboard

Toggle word wrap

kubeconfig を使用して、ホステッドクラスターのクラスター Operator を表示します。以下のコマンドを入力します。

oc get co --kubeconfig=kubeconfig-<hosted_cluster_name>

oc get co --kubeconfig=kubeconfig-<hosted_cluster_name>

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、ホステッドクラスター上で実行中の Pod を表示することもできます。

oc get pods -A --kubeconfig=kubeconfig-<hosted-cluster-name>

oc get pods -A --kubeconfig=kubeconfig-<hosted-cluster-name>

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
openshift-cluster-samples-operator                 cluster-samples-operator-6b5bcb9dff-kpnbc                 2/2     Running            0               20m
openshift-monitoring                               alertmanager-main-0                                       6/6     Running            0               100s
openshift-monitoring                               openshift-state-metrics-677b9fb74f-qqp6g                  3/3     Running            0               104s

NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
openshift-cluster-samples-operator                 cluster-samples-operator-6b5bcb9dff-kpnbc                 2/2     Running            0               20m
openshift-monitoring                               alertmanager-main-0                                       6/6     Running            0               100s
openshift-monitoring                               openshift-state-metrics-677b9fb74f-qqp6g                  3/3     Running            0               104s

Copy to Clipboard

Toggle word wrap

1.7.8.7. ホステッドクラスターの NodePool オブジェクトのスケーリング
リンクのコピー

NodePool オブジェクトをスケーリングして、ホステッドクラスターにノードを追加します。

NodePool オブジェクトを 2 つのノードにスケーリングします。
```
oc -n <hosted-cluster-namespace> scale nodepool <nodepool-name> --replicas 2
```
```
oc -n <hosted-cluster-namespace> scale nodepool <nodepool-name> --replicas 2
```
Copy to Clipboard Toggle word wrap
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

oc -n <hosted-control-plane-namespace> get agent

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                                   CLUSTER         APPROVED   ROLE          STAGE
4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign

NAME                                   CLUSTER         APPROVED   ROLE          STAGE
4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign

Copy to Clipboard

Toggle word wrap

以下のコマンドを入力します。

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}'

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}'

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient

BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient

Copy to Clipboard

Toggle word wrap

次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

Copy to Clipboard

Toggle word wrap

エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、ホステッドクラスターの OpenShift Container Platform ノードが表示されることを確認します。
```
oc --kubeconfig kubeconfig-<hosted-cluster-name> get nodes
```
```
oc --kubeconfig kubeconfig-<hosted-cluster-name> get nodes
```
Copy to Clipboard Toggle word wrap
以下の出力例を参照してください。
```
NAME           STATUS   ROLES    AGE     VERSION
ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
```
```
NAME           STATUS   ROLES    AGE     VERSION
ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
```
Copy to Clipboard Toggle word wrap
Cluster Operator は、ワークロードをノードに追加することによって調整を開始します。

次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。

oc -n <hosted-control-plane-namespace> get machines

oc -n <hosted-control-plane-namespace> get machines

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.13z

NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.13z

Copy to Clipboard

Toggle word wrap

clusterversion 調整プロセスは最終的に、Ingress および Console クラスター Operator のみが欠落しているポイントに到達します。

以下のコマンドを入力します。

oc --kubeconfig kubeconfig-<hosted-cluster-name> get clusterversion,co

oc --kubeconfig kubeconfig-<hosted-cluster-name> get clusterversion,co

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.13z: the cluster operator console has not yet successfully rolled out

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.13z    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.13z    True        False         False      10m
clusteroperator.config.openshift.io/dns                                        4.13z    True        False         False      9m16s

NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.13z: the cluster operator console has not yet successfully rolled out

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.13z    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.13z    True        False         False      10m
clusteroperator.config.openshift.io/dns                                        4.13z    True        False         False      9m16s

Copy to Clipboard

Toggle word wrap

1.7.8.7.1. ノードプールの追加
リンクのコピー

名前、レプリカの数、およびエージェントラベルセレクターなどの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。

ノードプールを作成するには、次の情報を入力します。

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"}}'

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"}}'

Copy to Clipboard

Toggle word wrap

1: --agentLabelSelector は任意です。ノードプールは、"size" : "medium" ラベルを持つエージェントを使用します。

clusters namespace 内の nodepool リソースをリスト表示して、ノードプールのステータスを確認します。
```
oc get nodepools --namespace clusters
```
```
oc get nodepools --namespace clusters
```
Copy to Clipboard Toggle word wrap

次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

hostedcluster-secrets/kubeconfig

hostedcluster-secrets/kubeconfig

Copy to Clipboard

Toggle word wrap

しばらくしてから、次のコマンドを入力してノードプールのステータスを確認できます。
```
oc --kubeconfig ./hostedcluster-secrets get nodes
```
```
oc --kubeconfig ./hostedcluster-secrets get nodes
```
Copy to Clipboard Toggle word wrap
次のコマンドを入力して、使用可能なノードプールの数が予想されるノードプールの数と一致することを確認します。
```
oc get nodepools --namespace clusters
```
```
oc get nodepools --namespace clusters
```
Copy to Clipboard Toggle word wrap

1.7.8.7.2. 関連情報
リンクのコピー

データプレーンをゼロにスケールダウンするには、データプレーンをゼロにスケールダウンするを参照してください。

1.7.8.8. 非ベアメタルエージェントマシン上のホステッドクラスターでの Ingress の処理
リンクのコピー

*.apps ドメインのロードバランサーとワイルドカード DNS レコードを設定するには、ゲストクラスターで次のアクションを実行します。

MetalLB Operator の設定を含む YAML ファイルを作成して MetalLB をデプロイします。

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

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

Copy to Clipboard

Toggle word wrap

ファイルを metallb-operator-config.yaml として保存します。
以下のコマンドを入力して設定を適用します。
```
oc apply -f metallb-operator-config.yaml
```
```
oc apply -f metallb-operator-config.yaml
```
Copy to Clipboard Toggle word wrap
Operator の実行後、MetalLB インスタンスを作成します。
1. MetalLB インスタンスの設定を含む YAML ファイルを作成します。
  apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb
  Copy to Clipboard Toggle word wrap
2. ファイルを metallb-instance-config.yaml として保存します。
3. 次のコマンドを入力して、MetalLB インスタンスを作成します。
```
oc apply -f metallb-instance-config.yaml
```
```
oc apply -f metallb-instance-config.yaml
```
Copy to Clipboard Toggle word wrap

2 つのリソースを作成して MetalLB Operator を設定します。

単一の IP アドレスを持つ IPAddressPool リソース。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。
IPAddressPool リソースが BGP プロトコルを通じて提供するロードバランサーの IP アドレスをアドバタイズするための BGP アドバタイズリソース。
1. 設定を含む YAML ファイルを作成します。

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: <ip_address_pool_name> 
  namespace: metallb
spec:
  protocol: layer2
  autoAssign: false
  addresses:
    - <ingress_ip>-<ingress_ip> 
---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: <bgp_advertisement_name> 
  namespace: metallb
spec:
  ipAddressPools:
    - <ip_address_pool_name>

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: <ip_address_pool_name>


  namespace: metallb
spec:
  protocol: layer2
  autoAssign: false
  addresses:
    - <ingress_ip>-<ingress_ip>


---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: <bgp_advertisement_name>


  namespace: metallb
spec:
  ipAddressPools:
    - <ip_address_pool_name>

Copy to Clipboard

Toggle word wrap

1 4

IPAddressPool リソース名を指定します。

環境の IP アドレスを指定します (例: 192.168.122.23)。

BGPAdvertisement リソース名を指定します。

ファイルを ipaddresspool-bgpadvertisement-config.yaml として保存します。
次のコマンドを入力してリソースを作成します。
```
oc apply -f ipaddresspool-bgpadvertisement-config.yaml
```
```
oc apply -f ipaddresspool-bgpadvertisement-config.yaml
```
Copy to Clipboard Toggle word wrap
1. LoadBalancer タイプのサービスを作成すると、MetalLB はサービスに外部 IP アドレスを追加します。

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

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

Copy to Clipboard

Toggle word wrap

ファイルを metallb-loadbalancer-service.yaml として保存します。
YAML 設定を適用するには、次のコマンドを入力します。
```
oc apply -f metallb-loadbalancer-service.yaml
```
```
oc apply -f metallb-loadbalancer-service.yaml
```
Copy to Clipboard Toggle word wrap

次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。

curl -kI https://console-openshift-console.apps.example.krnl.es

HTTP/1.1 200 OK

curl -kI https://console-openshift-console.apps.example.krnl.es

HTTP/1.1 200 OK

Copy to Clipboard

Toggle word wrap

clusterversion と clusteroperator の値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。
```
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
```
```
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
```
Copy to Clipboard Toggle word wrap
以下の出力例を参照してください。

NAME                                         VERSION           AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.x.y             True        False         3m32s   Cluster version is 4.x.y

NAME                                                                           VERSION           AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.x.y             True        False         False      3m50s
clusteroperator.config.openshift.io/ingress                                    4.x.y             True        False         False      53m

NAME                                         VERSION           AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.x.y             True        False         3m32s   Cluster version is 4.x.y

NAME                                                                           VERSION           AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.x.y             True        False         False      3m50s
clusteroperator.config.openshift.io/ingress                                    4.x.y             True        False         False      53m

Copy to Clipboard

Toggle word wrap

+ 4.x.y は、使用する OpenShift Container Platform サポート対象バージョン (例: 4.14.0-x86_64 に置き換えます。

1.7.8.8.1. 関連情報
リンクのコピー

MetalLB の詳細は、OpenShift Container Platform ドキュメントの MetalLB および MetalLB Operator についてを参照してください。

1.7.8.9. ホステッドクラスターのノード自動スケーリングの有効化
リンクのコピー

自動スケーリングを有効にするには、次のコマンドを入力します。この例では、ノードの最小数は 2 で、最大数は 5 です。追加できるノードの最大数は、プラットフォームによって制限される場合があります。たとえば、エージェントプラットフォームを使用する場合、ノードの最大数は使用可能なエージェントの数によって制限されます。
```
oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
```
```
oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
```
Copy to Clipboard Toggle word wrap

新しいノードを必要とするワークロードを作成します。

次の例で使用して、ワークロード設定を含む 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: {}

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: {}

Copy to Clipboard

Toggle word wrap

ファイルを workload-config.yaml として保存します。
以下のコマンドを入力して、YAML を適用します。

oc apply -f workload-config.yaml

oc apply -f workload-config.yaml

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>admin-kubeconfig --to=./hostedcluster-secrets --confirm

oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>admin-kubeconfig --to=./hostedcluster-secrets --confirm

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

hostedcluster-secrets/kubeconfig

hostedcluster-secrets/kubeconfig

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、新しいノードが Ready ステータスであるかどうかを確認できます。
```
oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
```
```
oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
```
Copy to Clipboard Toggle word wrap

ノードを削除するには、次のコマンドを入力してワークロードを削除します。

oc --kubeconfig <hosted-cluster-name>.kubeconfig -n default delete deployment reversewords

oc --kubeconfig <hosted-cluster-name>.kubeconfig -n default delete deployment reversewords

Copy to Clipboard

Toggle word wrap

数分間待ちます。その間に、容量の追加が必要にならないようにします。エージェントプラットフォームでは、エージェントは廃止され、再利用できます。次のコマンドを入力すると、ノードが削除されたことを確認できます。
```
oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
```
```
oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
```
Copy to Clipboard Toggle word wrap

1.7.8.9.1. ホストされたクラスターのノードの自動スケーリングを無効にする
リンクのコピー

ノードの自動スケーリングを無効にするには、次のコマンドを入力します。

oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify-value-to-scale-replicas>]'

oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify-value-to-scale-replicas>]'

Copy to Clipboard

Toggle word wrap

このコマンドは、YAML ファイルから "spec.autoScaling" を削除し、"spec.replicas" を追加し、"spec.replicas" を指定の整数値に設定します。

1.7.8.10. 非ベアメタルエージェントマシン上のホステッドクラスターの破棄
リンクのコピー

コンソールを使用して、非ベアメタルのホステッドクラスターを破棄できます。非ベアメタルエージェントマシン上のホステッドクラスターを破棄するには、次の手順を実行します。

コンソールで、Infrastructure > Clusters に移動します。
Clusters ページで、破棄するクラスターを選択します。
Actions メニューで Destroy clusters を選択し、クラスターを削除します。

1.7.8.10.1. コマンドラインを使用した非ベアメタルエージェントマシン上のホステッドクラスターの破棄
リンクのコピー

ホステッドクラスターを破棄するには、次の手順を実行します。

次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。
```
hcp destroy cluster agent --name <hosted_cluster_name>
```
```
hcp destroy cluster agent --name <hosted_cluster_name>
```
Copy to Clipboard Toggle word wrap
<hosted_cluster_name> をホストされたクラスターの名前に置き換えます。

1.7.9. 64 ビット x86 OpenShift Container Platform クラスターでのホスティングクラスターの設定による、IBM Power コンピュートノードの Hosted Control Plane の作成 (テクノロジープレビュー)
リンクのコピー

テクノロジープレビュー: IBM Power (ppc64le) コンピュートノード用の 64 ビット x86 ベアメタル上でのホスティングクラスターの設定のサポートには制限があります。

注:management クラスターは マネージド クラスターではありません。マネージドクラスターは、ハブクラスターが管理するクラスターです。

マルチクラスターエンジン Operator 2.5 は、管理対象のハブクラスターであるデフォルトの 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.9.1. 前提条件
リンクのコピー

ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。

OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.5 以降のマルチクラスターエンジン。マルチクラスターエンジン 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.5 以降で自動的にインポートされます。local-cluster の詳細については、詳細設定を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。
```
oc get managedclusters local-cluster
```
```
oc get managedclusters local-cluster
```
Copy to Clipboard Toggle word wrap
HyperShift Operator を実行するには、3 つ以上のワーカーノードを含むホスティングクラスターが必要です。
Central Infrastructure Management サービスが有効である。詳細は、Central Infrastructure Management サービスの有効化を参照してください。
Hosted Control Plane コマンドラインインターフェイスをインストールする。Hosted Control Plane コマンドラインインターフェイスのインストールを参照してください。

1.7.9.2. IBM Power インフラストラクチャーの要件
リンクのコピー

エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャーとして次のものが必要です。

Agents: Agent は Discovery イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングする準備ができているホストを表します。
DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

1.7.9.3. IBM Power 設定ドキュメント
リンクのコピー

前提条件を満たしたら、次のトピックを参照して、ベアメタル上に Hosted Control Plane を設定します。

InfraEnv リソースにエージェントを追加する
IBM Power での Hosted Control Plane の DNS の設定
ベアメタルでのホステッドクラスターの作成
IBM Power コンピューティングノード用の 64 ビット x86 ベアメタル上への Hosted Control Plane 用の InfraEnv リソース作成
IBM Power 上のホステッドクラスターの NodePool オブジェクトのスケーリング

1.7.9.4. InfraEnv リソースにエージェントを追加する
リンクのコピー

エージェントを追加するには、ライブ ISO で開始するようにマシンを手動で設定できます。

ライブ ISO をダウンロードし、それを使用してホスト (ベアメタルまたは VM) を起動します。ライブ ISO の URL は、InfraEnv リソースの status.isoDownloadURL フィールドにあります。起動時に、ホストは Assisted Service と通信し、InfraEnv リソースと同じ namespace にエージェントとして登録します。

エージェントとそのプロパティーの一部を一覧表示するには、次のコマンドを入力します。

oc -n <hosted-control-plane-namespace> get agents

oc -n <hosted-control-plane-namespace> get agents

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218                        auto-assign
e57a637f-745b-496e-971d-1abbf03341ba                        auto-assign

NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218                        auto-assign
e57a637f-745b-496e-971d-1abbf03341ba                        auto-assign

Copy to Clipboard

Toggle word wrap

各エージェントが作成された後、オプションでその 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> 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

Copy to Clipboard

Toggle word wrap

エージェントの使用が承認されていることを確認するには、次のコマンドを入力して出力を確認します。

oc -n <hosted-control-plane-namespace> get agents

oc -n <hosted-control-plane-namespace> get agents

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218             true       auto-assign
e57a637f-745b-496e-971d-1abbf03341ba             true       auto-assign

NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218             true       auto-assign
e57a637f-745b-496e-971d-1abbf03341ba             true       auto-assign

Copy to Clipboard

Toggle word wrap

1.7.9.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>

$ cat /var/named/<example.krnl.es.zone>

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

TTL 900

$ 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


api-int               IN A 1xx.2x.2xx.1xx
;
;
*.apps.<hosted-cluster-name>.<basedomain>           IN A 1xx.2x.2xx.1xx
;
;EOF

Copy to Clipboard

Toggle word wrap

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

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy

Copy to Clipboard

Toggle word wrap

1.7.9.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-public-key>

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-public-key>

Copy to Clipboard

Toggle word wrap

ファイルを infraenv-config.yaml として保存します。
次のコマンドを入力して設定を適用します。
```
oc apply -f infraenv-config.yaml
```
```
oc apply -f infraenv-config.yaml
```
Copy to Clipboard Toggle word wrap
URL を取得してライブ ISO をダウンロードし、IBM Power マシンがエージェントとして参加できるようにするには、以下のコマンドを入力します。
```
oc -n <hosted-control-plane-namespace> get InfraEnv <hosted-cluster-name> -o json
```
```
oc -n <hosted-control-plane-namespace> get InfraEnv <hosted-cluster-name> -o json
```
Copy to Clipboard Toggle word wrap

1.7.9.7. IBM Power 上のホステッドクラスターの NodePool オブジェクトのスケーリング
リンクのコピー

NodePool オブジェクトは、ホステッドクラスターの作成時に作成されます。NodePool オブジェクトをスケーリングすることで、Hosted Control Plane にさらに多くのコンピュートノードを追加できます。

次のコマンドを実行して、NodePool オブジェクトを 2 つのノードにスケーリングします。
```
oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
```
```
oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
```
Copy to Clipboard Toggle word wrap
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}'

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}'

Copy to Clipboard

Toggle word wrap

以下の出力を参照してください。

BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient

BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、移行フェーズを表示します。

oc -n <hosted_control_plane_namespace> get agent

oc -n <hosted_control_plane_namespace> get agent

Copy to Clipboard

Toggle word wrap

以下の出力を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、ホステッドクラスターにアクセスするための kubeconfig ファイルを生成します。

hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig

hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig

Copy to Clipboard

Toggle word wrap

エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、OpenShift Container Platform ノードが表示されることを確認します。

oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

Copy to Clipboard

Toggle word wrap

以下の出力を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。

oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io

oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io

Copy to Clipboard

Toggle word wrap

以下の出力を参照してください。

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.15.0
hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0

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.15.0
hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、クラスターのバージョンとクラスター Operator のステータスを確認します。

oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion

oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion

Copy to Clipboard

Toggle word wrap

以下の出力を参照してください。

NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.15.0   True        False         40h     Cluster version is 4.15.0

NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.15.0   True        False         40h     Cluster version is 4.15.0

Copy to Clipboard

Toggle word wrap

以下のコマンドを実行して、クラスター Operator のステータスを確認します。
```
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
```
```
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
```
Copy to Clipboard Toggle word wrap

クラスターの各コンポーネントの出力には、NAME、VERSION、AVAILABLE、PROGRESSING、DEGRADED、SINCE、および MESSAGE のクラスター Operator のステータスが表示されます。

出力例は、OpenShift Container Platform ドキュメントの初期 Operator 設定セクションを参照してください。

1.7.9.7.1. 関連情報
リンクのコピー

データプレーンをゼロにスケールダウンするには、データプレーンをゼロにスケールダウンするを参照してください。

1.7.10. IBM Z コンピュートノード用の x86 ベアメタル上でのホスティングクラスターの設定 (テクノロジープレビュー)
リンクのコピー

テクノロジープレビュー: IBM Z (s390x) コンピュートノード用の x86 ベアメタル上でのホスティングクラスターの設定は、テクノロジープレビュー状態であり、サポートに制限があります。

注:management クラスターは マネージド クラスターではありません。マネージドクラスターは、ハブクラスターが管理するクラスターです。

hypershift アドオンを使用してマネージドクラスターをホスティングクラスターに変換し、そのクラスターに HyperShift Operator をデプロイできます。その後、ホステッドクラスターの作成を開始できます。

重要:

エージェントプラットフォームを使用して、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.10.1. 前提条件
リンクのコピー

OpenShift Container Platform クラスターに Kubernetes Operator バージョン 2.5 以降のマルチクラスターエンジンをインストールする。マルチクラスターエンジン 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.5 以降で自動的にインポートされます。local-cluster の詳細については、詳細設定を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。
```
oc get managedclusters local-cluster
```
```
oc get managedclusters local-cluster
```
Copy to Clipboard Toggle word wrap
HyperShift Operator を実行するために 3 つ以上のワーカーノードを含むホスティングクラスターがある。
Central Infrastructure Management サービスが有効である。詳細は、Central Infrastructure Management サービスの有効化を参照してください。
Hosted Control Plane コマンドラインインターフェイスをインストールする。Hosted Control Plane コマンドラインインターフェイスのインストールを参照してください。

1.7.10.2. IBM Z インフラストラクチャーの要件
リンクのコピー

エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャーとして次のものが必要です。

Agents: Agent は Discovery イメージまたは PXE イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングする準備ができているホストを表します。
DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

Hosted Control Plane 機能はデフォルトで有効になっています。機能を無効にした後、手動で有効にする場合、または機能を無効にする必要がある場合は、Hosted Control Plane 機能の有効化または無効化を参照してください。

1.7.10.3. IBM Z 設定ドキュメント
リンクのコピー

前提条件を満たしたら、次のトピックを参照して、ベアメタル上に Hosted Control Plane を設定します。

IBM Z を使用した Hosted Control Plane の DNS の設定
ベアメタルでのホステッドクラスターの作成
IBM Z コンピューティングノード用の 64 ビット x86 ベアメタル上への Hosted Control Plane 用の InfraEnv リソース作成
IBM Z エージェントを InfraEnv リソースに追加する (テクノロジープレビュー)
IBM Z 上のホステッドクラスターの NodePool オブジェクトのスケーリング

1.7.10.4. IBM Z エージェントを InfraEnv リソースに追加する (テクノロジープレビュー)
リンクのコピー

IBM Z 環境にエージェントを追加するには、追加の手順が必要です。これについては、このセクションで詳しく説明します。

注: 特に明記されていない限り、これらの手順は、IBM Z および IBM LinuxONE 上の z/VM と RHEL KVM の両方のインストールに適用されます。

1.7.10.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"

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"

Copy to Clipboard

Toggle word wrap

ISO ブートの場合は、InfraEnv リソースから ISO をダウンロードし、次のコマンドを実行してノードを起動します。

virt-install \
  --name "<vm_name>" \
  --autostart \
  --memory=16384 \
  --cpu host \
  --vcpus=4 \
  --network network:macvtap-net,mac=<mac_address> \
  --cdrom "<path_to_image.iso>" \
  --disk <qcow_image_path> \
  --graphics none \
  --noautoconsole \
  --os-variant <os_version> \
  --wait=-1 \

virt-install \
  --name "<vm_name>" \
  --autostart \
  --memory=16384 \
  --cpu host \
  --vcpus=4 \
  --network network:macvtap-net,mac=<mac_address> \
  --cdrom "<path_to_image.iso>" \
  --disk <qcow_image_path> \
  --graphics none \
  --noautoconsole \
  --os-variant <os_version> \
  --wait=-1 \

Copy to Clipboard

Toggle word wrap

1.7.10.4.2. z/VM を使用した IBM のエージェントの追加
リンクのコピー

注記: z/VM ゲストに静的 IP を使用する場合は、IP パラメーターが 2 回目の起動でも持続するように、z/VM エージェントの NMStateConfig 属性を設定する必要があります。

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 \ 
rd.znet=qeth,<network_adaptor_range>,layer2=1 \
rd.<disk_type>=<storage> 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

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 \


rd.znet=qeth,<network_adaptor_range>,layer2=1 \
rd.<disk_type>=<storage> 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

Copy to Clipboard

Toggle word wrap

1: VSwitch を使用したインストールの場合は、zfcp.allow_lun_scan=0 を追加します。OSA、Hipersockets、および RoCE を使用したインストールの場合は、このエントリーを省略します。
2: DASD タイプのディスクにインストールする場合は、rd.dasd= を使用してインストールディスクを指定します。FCP タイプのディスクにインストールする場合は、rd.zfcp= を使用します。

次のコマンドを実行して、initrd、カーネルイメージ、およびパラメーターファイルをゲスト VM に移動します。

vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>

vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>

Copy to Clipboard

Toggle word wrap

vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename

vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename

Copy to Clipboard

Toggle word wrap

vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>

vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>

Copy to Clipboard

Toggle word wrap

ゲスト VM コンソールから次のコマンドを実行します。
```
cp ipl c
```
```
cp ipl c
```
Copy to Clipboard Toggle word wrap

エージェントとそのプロパティーをリスト表示するには、次のコマンドを入力します。

oc -n <hosted_control_plane_namespace> get agents

oc -n <hosted_control_plane_namespace> get agents

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME    CLUSTER APPROVED    ROLE    STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d    auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a    auto-assign

NAME    CLUSTER APPROVED    ROLE    STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d    auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a    auto-assign

Copy to Clipboard

Toggle word wrap

次のコマンドを実行してエージェントを承認します。オプション: 仕様でエージェント 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> 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

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、エージェントが承認されていることを確認します。

oc -n <hosted_control_plane_namespace> get agents

oc -n <hosted_control_plane_namespace> get agents

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                                            CLUSTER     APPROVED   ROLE          STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d             true       auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a             true       auto-assign

NAME                                            CLUSTER     APPROVED   ROLE          STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d             true       auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a             true       auto-assign

Copy to Clipboard

Toggle word wrap

1.7.10.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>

$ cat /var/named/<example.krnl.es.zone>

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

TTL 900

$ 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


api-int               IN A 1xx.2x.2xx.1xx
;
;
*.apps        IN A 1xx.2x.2xx.1xx
;
;EOF

Copy to Clipboard

Toggle word wrap

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

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy

Copy to Clipboard

Toggle word wrap

1.7.10.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-public-key>

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-public-key>

Copy to Clipboard

Toggle word wrap

ファイルを infraenv-config.yaml として保存します。
次のコマンドを入力して設定を適用します。
```
oc apply -f infraenv-config.yaml
```
```
oc apply -f infraenv-config.yaml
```
Copy to Clipboard Toggle word wrap
initrd.img、kernel.img、または rootfs.img などの PXE イメージをダウンロードする URL を取得するには、次のコマンドを入力します。このイメージは、IBM Z マシンがエージェントとして参加できるようにします。
```
oc -n <hosted-control-plane-namespace> get InfraEnv <hosted-cluster-name> -o json
```
```
oc -n <hosted-control-plane-namespace> get InfraEnv <hosted-cluster-name> -o json
```
Copy to Clipboard Toggle word wrap

1.7.10.7. IBM Z 上のホステッドクラスターの NodePool オブジェクトのスケーリング
リンクのコピー

次のコマンドを実行して、NodePool オブジェクトを 2 つのノードにスケーリングします。
```
oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
```
```
oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
```
Copy to Clipboard Toggle word wrap
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}'

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}'

Copy to Clipboard

Toggle word wrap

以下の出力を参照してください。

BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient

BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、移行フェーズを表示します。

oc -n <hosted_control_plane_namespace> get agent

oc -n <hosted_control_plane_namespace> get agent

Copy to Clipboard

Toggle word wrap

以下の出力を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、ホステッドクラスターにアクセスするための kubeconfig ファイルを生成します。

hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig

hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig

Copy to Clipboard

Toggle word wrap

エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、OpenShift Container Platform ノードが表示されることを確認します。

oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

Copy to Clipboard

Toggle word wrap

以下の出力を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

Cluster Operator は、ワークロードをノードに追加することによって調整を開始します。

次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。

oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io

oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io

Copy to Clipboard

Toggle word wrap

以下の出力を参照してください。

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.15.0
hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0

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.15.0
hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、クラスターのバージョンを確認します。

oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co

oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co

Copy to Clipboard

Toggle word wrap

以下の出力を参照してください。

NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.15.0-ec.2   True        False         40h     Cluster version is 4.15.0-ec.2

NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.15.0-ec.2   True        False         40h     Cluster version is 4.15.0-ec.2

Copy to Clipboard

Toggle word wrap

以下のコマンドを実行して、クラスター Operator のステータスを確認します。
```
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
```
```
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
```
Copy to Clipboard Toggle word wrap

出力例は、OpenShift Container Platform ドキュメントの初期 Operator 設定セクションを参照してください。

1.7.10.7.1. 関連情報
リンクのコピー

データプレーンをゼロにスケールダウンするには、データプレーンをゼロにスケールダウンするを参照してください。

1.7.11. 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 によってホストクラスターを管理するには、ホストクラスター名を既存のマネージドクラスターと同じにすることはできません。
ホステッドクラスター名として clusters を使用しないでください。
ホステッドクラスターは、マルチクラスターエンジンの operator 管理クラスターの namespace には作成できません。
Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、OpenShift Container Platform ドキュメントの 推奨される etcd プラクティス および 論理ボリュームマネージャーストレージを使用した永続ストレージ を参照してください。

1.7.11.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"}}]'

oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'

Copy to Clipboard

Toggle word wrap

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"}}}'
```
```
oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
```
Copy to Clipboard Toggle word wrap
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 は自動的にインポートされます。local-cluster の詳細については、詳細設定を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。
```
oc get managedclusters local-cluster
```
```
oc get managedclusters local-cluster
```
Copy to Clipboard Toggle word wrap

1.7.11.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.11.3. KubeVirt プラットフォームを使用したホステッドクラスターの作成
リンクのコピー

OpenShift Container Platform 4.14 以降では、KubeVirt を使用してクラスターを作成でき、外部インフラストラクチャーを使用して作成することも可能です。KubeVirt を使用した作成プロセスの詳細は、以下をご覧ください。

ホストされたクラスターの作成
外部インフラストラクチャーを使用したホステッドクラスターの作成

1.7.11.3.1. ホストされたクラスターの作成
リンクのコピー

ホストされたクラスターを作成するには、Hosted Control Plane コマンドラインインターフェイス hcp を使用します。
```
hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 
--node-pool-replicas <worker-count> \ 
--pull-secret <path-to-pull-secret> \ 
--memory <value-for-memory> \ 
--cores <value-for-cpu> \ 
--etcd-storage-class=<etcd-storage-class> 
```
```
hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 
```
1
```
--node-pool-replicas <worker-count> \ 
```
2
```
--pull-secret <path-to-pull-secret> \ 
```
3
```
--memory <value-for-memory> \ 
```
4
```
--cores <value-for-cpu> \ 
```
5
```
--etcd-storage-class=<etcd-storage-class> 
```
6
Copy to Clipboard Toggle word wrap
1
ホステッドクラスターの名前を指定します (例: example)。
2
ワーカー数を指定します (例: 2)。
3
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4
メモリーの値を指定します (例: 6Gi)。
5
CPU の値を指定します (例: 2)。
6
etcd ストレージクラス名を指定します (例: lvm-storageclass)。
注記: --release-image フラグを使用して、特定の OpenShift Container Platform リリースでホステッドクラスターをセットアップできます。
--node-pool-replicas フラグに従って、2 つの仮想マシンワーカーレプリカを持つクラスターに対してデフォルトのノードプールが作成されます。

しばらくすると、次のコマンドを入力して、ホストされているコントロールプレーン Pod が実行されていることを確認できます。

oc -n clusters-<hosted-cluster-name> get pods

oc -n clusters-<hosted-cluster-name> get pods

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

KubeVirt 仮想マシンによってサポートされるワーカーノードを含むホステッドクラスターは、通常、完全にプロビジョニングされるまでに 10 ~ 15 分かかります。

ホステッドクラスターのステータスを確認するには、次のコマンドを入力して、対応する HostedCluster リソースを確認します。

oc get --namespace clusters hostedclusters

oc get --namespace clusters hostedclusters

Copy to Clipboard

Toggle word wrap

完全にプロビジョニングされた HostedCluster オブジェクトを示す以下の出力例を参照してください。

NAMESPACE   NAME      VERSION   KUBECONFIG                 PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
clusters    example   4.x.0     example-admin-kubeconfig   Completed   True        False         The hosted control plane is available

NAMESPACE   NAME      VERSION   KUBECONFIG                 PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
clusters    example   4.x.0     example-admin-kubeconfig   Completed   True        False         The hosted control plane is available

Copy to Clipboard

Toggle word wrap

4.x.0 を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

ホステッドクラスターへのアクセスの説明に従って、ホステッドクラスターにアクセスします。

1.7.11.3.2. 外部インフラストラクチャーを使用したホステッドクラスターの作成
リンクのコピー

デフォルトでは、HyperShift Operator は、ホステッドクラスターのコントロールプレーン Pod と、同じクラスター内の KubeVirt ワーカー VM の両方をホストします。外部インフラストラクチャー機能を使用すると、ワーカーノード VM をコントロールプレーン Pod とは別のクラスターに配置できます。

管理クラスター は HyperShift Operator を実行し、ホステッドクラスターのコントロールプレーン Pod をホストする OpenShift Container Platform クラスターです。
インフラストラクチャークラスター は、ホステッドクラスターの KubeVirt ワーカー VM を実行する OpenShift Container Platform クラスターです。
デフォルトでは、管理クラスターは VM をホストするインフラストラクチャークラスターとしても機能します。ただし、外部インフラストラクチャーの場合、管理クラスターとインフラストラクチャークラスターは異なります。

1.7.11.3.2.1. 外部インフラストラクチャーの前提条件
リンクのコピー

KubeVirt ノードをホストする外部インフラストラクチャークラスター上に namespace が必要です。
外部インフラストラクチャークラスター用の kubeconfig ファイルが必要です。

1.7.11.3.2.2. hcp コマンドラインインターフェイスを使用したホステッドクラスターの作成
リンクのコピー

hcp コマンドラインインターフェイスを使用して、ホステッドクラスターを作成できます。

KubeVirt ワーカーの仮想マシンをインフラストラクチャークラスターに配置するには、次の例に示すように、--infra-kubeconfig-file および --infra-namespace 引数を使用します。
```
hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 
--node-pool-replicas <worker-count> \ 
--pull-secret <path-to-pull-secret> \ 
--memory <value-for-memory> \ 
--cores <value-for-cpu> \ 
--infra-namespace=<hosted-cluster-namespace>-<hosted-cluster-name> \ 
--infra-kubeconfig-file=<path-to-external-infra-kubeconfig> 
```
```
hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 
```
1
```
--node-pool-replicas <worker-count> \ 
```
2
```
--pull-secret <path-to-pull-secret> \ 
```
3
```
--memory <value-for-memory> \ 
```
4
```
--cores <value-for-cpu> \ 
```
5
```
--infra-namespace=<hosted-cluster-namespace>-<hosted-cluster-name> \ 
```
6
```
--infra-kubeconfig-file=<path-to-external-infra-kubeconfig> 
```
7
Copy to Clipboard Toggle word wrap
1
ホステッドクラスターの名前を指定します (例: example)。
2
ワーカー数を指定します (例: 2)。
3
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4
メモリーの値を指定します (例: 6Gi)。
5
CPU の値を指定します (例: 2)。
6
インフラストラクチャー namespace を指定します (例: clusters-example)。
7
インフラストラクチャークラスターの kubeconfig ファイルへのパスを指定します (例: /user/name/external-infra-kubeconfig)。
このコマンドを入力すると、コントロールプレーン Pod は HyperShift Operator が実行される管理クラスターでホストされ、KubeVirt VM は別のインフラストラクチャークラスターでホストされます。
ホステッドクラスターへのアクセスの説明に従って、ホステッドクラスターにアクセスします。

1.7.11.3.3. コンソールを使用したホステッドクラスターの作成
リンクのコピー

コンソールを使用して KubeVirt プラットフォームでホステッドクラスターを作成するには、次の手順を実行します。

OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。コンソールを開く手順については、OpenShift Container Platform ドキュメントの Web コンソールへのアクセスを参照してください。
コンソールヘッダーで、All Clusters が選択されていることを確認します。
Infrastructure > Clusters をクリックします。
Create cluster > Red Hat OpenShift Virtualization > Hosted をクリックします。
Create cluster ページで、プロンプトに従ってクラスターとノードプールの詳細を入力します。
注記:
- 事前定義された値を使用してコンソールのフィールドに自動的に値を入力する場合は、Red Hat OpenShift Virtualization の認証情報を作成します。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
- Cluster details ページのプルシークレットは、OpenShift Container Platform リソースへのアクセスに使用する OpenShift Container Platform プルシークレットです。Red Hat OpenShift Virtualization の認証情報を選択した場合、プルシークレットが自動的に入力されます。
エントリーを確認し、Create をクリックします。
Hosted cluster ビューが表示されます。
Hosted cluster ビューでホストされたクラスターのデプロイメントを監視します。ホストされたクラスターに関する情報が表示されない場合は、All Clusters が選択されていることを確認し、クラスター名をクリックします。
コントロールプレーンコンポーネントの準備が整うまで待ちます。このプロセスには数分かかる場合があります。
ノードプールのステータスを表示するには、NodePool セクションまでスクロールします。ノードをインストールするプロセスには約 10 分かかります。Nodes をクリックして、ノードがホストされたクラスターに参加したかどうかを確認することもできます。

1.7.11.3.4. 関連情報
リンクのコピー

コンソールでホステッドクラスターを作成するときに再利用できる認証情報を作成するには、オンプレミス環境の認証情報の作成を参照してください。
ホステッドクラスターにアクセスするには、ホステッドクラスターへのアクセスを参照してください。

1.7.11.4. デフォルトの Ingress と DNS の動作
リンクのコピー

すべての OpenShift Container Platform クラスターにはデフォルトのアプリケーション Ingress コントローラーが含まれており、これにはワイルドカード DNS レコードが関連付けられている必要があります。デフォルトでは、HyperShift KubeVirt プロバイダーを使用して作成されたホステッドクラスターは、自動的に KubeVirt 仮想マシンが実行される OpenShift Container Platform クラスターのサブドメインになります。

たとえば、OpenShift Container Platform クラスターには次のデフォルトの Ingress DNS エントリーがある可能性があります。

*.apps.mgmt-cluster.example.com

*.apps.mgmt-cluster.example.com

Copy to Clipboard

Toggle word wrap

その結果、guest という名前が付けられ、その基礎となる OpenShift Container Platform クラスター上で実行される KubeVirt ホステッドクラスターには、次のデフォルト Ingress が設定されます。

*.apps.guest.apps.mgmt-cluster.example.com

*.apps.guest.apps.mgmt-cluster.example.com

Copy to Clipboard

Toggle word wrap

デフォルトの Ingress DNS が適切に機能するには、KubeVirt 仮想マシンをホストするクラスターでワイルドカード DNS ルートを許可する必要があります。この動作は、以下のコマンドを入力して設定できます。

oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'

oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'

Copy to Clipboard

Toggle word wrap

注: デフォルトのホステッドクラスター Ingress を使用する場合は、接続はポート 443 経由の HTTPS トラフィックに制限されます。ポート 80 経由のプレーン HTTP トラフィックは拒否されます。この制限は、デフォルトの Ingress の動作にのみ適用されます。

1.7.11.4.1. Ingress と DNS の動作のカスタマイズ
リンクのコピー

デフォルトの Ingress および DNS 動作を使用しない場合は、作成時に一意のベースドメインを使用して KubeVirt ホステッドクラスターを設定できます。このオプションでは、作成時に手動の設定手順が必要であり、クラスターの作成、ロードバランサーの作成、およびワイルドカード DNS 設定の 3 つの主要な手順が含まれます。

1.7.11.4.1.1. 基本ドメインを指定するホステッドクラスターのデプロイ
リンクのコピー

基本ドメインを指定するホステッドクラスターを作成するには、次のコマンドを入力します。

hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 
--node-pool-replicas <worker-count> \ 
--pull-secret <path-to-pull-secret> \ 
--memory <value-for-memory> \ 
--cores <value-for-cpu> \ 
--base-domain <basedomain>

hcp create cluster kubevirt \
--name <hosted-cluster-name> \


--node-pool-replicas <worker-count> \


--pull-secret <path-to-pull-secret> \


--memory <value-for-memory> \


--cores <value-for-cpu> \


--base-domain <basedomain>

Copy to Clipboard

Toggle word wrap

1: ホステッドクラスターの名前を指定します (例: example)。
2: ワーカー数を指定します (例: 2)。
3: プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4: メモリーの値を指定します (例: 6Gi)。
5: CPU の値を指定します (例: 2)。
6: ベースドメインを指定します (例: hypershift.lab)。

その結果、ホストされたクラスターには、クラスター名とベースドメイン用に設定された Ingress ワイルドカード (例: .apps.example.hypershift.lab) が含まれます。ホストされたクラスターは Partial ステータスのままです。一意のベースドメインを持つホストされたクラスターを作成した後、必要な DNS レコードとロードバランサーを設定する必要があるためです。

次のコマンドを入力して、ホストされたクラスターのステータスを表示します。

oc get --namespace clusters hostedclusters

oc get --namespace clusters hostedclusters

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME            VERSION   KUBECONFIG                       PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
example                   example-admin-kubeconfig         Partial    True        False         The hosted control plane is available

NAME            VERSION   KUBECONFIG                       PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
example                   example-admin-kubeconfig         Partial    True        False         The hosted control plane is available

Copy to Clipboard

Toggle word wrap

次のコマンドを入力してクラスターにアクセスします。

hcp create kubeconfig --name <hosted-cluster-name> > <hosted-cluster-name>-kubeconfig

hcp create kubeconfig --name <hosted-cluster-name> > <hosted-cluster-name>-kubeconfig

Copy to Clipboard

Toggle word wrap

oc --kubeconfig <hosted-cluster-name>-kubeconfig get co

oc --kubeconfig <hosted-cluster-name>-kubeconfig get co

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.x.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.x.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)

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.x.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.x.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)

Copy to Clipboard

Toggle word wrap

4.x.0 を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

次の手順では、出力内のエラーを修正します。

注記: ホストされたクラスターがベアメタル上にある場合は、ロードバランサーサービスを設定するために MetalLB が必要になる場合があります。詳細は、オプション: MetalLB の設定 を参照してください。

1.7.11.4.1.2. ロードバランサーのセットアップ
リンクのコピー

Ingress トラフィックを KubeVirt 仮想マシンにルーティングし、ロードバランサー IP アドレスにワイルドカード DNS エントリーを割り当てるロードバランサーサービスを設定します。

ホストされたクラスターの Ingress を公開する NodePort サービスがすでに存在します。ノードポートをエクスポートし、それらのポートをターゲットとするロードバランサーサービスを作成できます。
1. 次のコマンドを入力して、HTTP ノードポートを取得します。
  oc --kubeconfig <hosted-cluster-name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'
  Copy to Clipboard Toggle word wrap
  次の手順で使用する HTTP ノードポート値をメモします。
2. 次のコマンドを入力して、HTTPS ノードポートを取得します。
  oc --kubeconfig <hosted-cluster-name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'
  Copy to Clipboard Toggle word wrap
次の手順で使用する HTTPS ノードポート値をメモします。

次のコマンドを入力して、ロードバランサーサービスを作成します。

oc apply -f -
apiVersion: v1
kind: Service
metadata:
  labels:
    app: <hosted-cluster-name>
  name: <hosted-cluster-name>-apps
  namespace: clusters-<hosted-cluster-name>
spec:
  ports:
  - name: https-443
    port: 443
    protocol: TCP
    targetPort: <https-node-port> 
  - name: http-80
    port: 80
    protocol: TCP
    targetPort: <http-node-port> 
  selector:
    kubevirt.io: virt-launcher
  type: LoadBalancer

oc apply -f -
apiVersion: v1
kind: Service
metadata:
  labels:
    app: <hosted-cluster-name>
  name: <hosted-cluster-name>-apps
  namespace: clusters-<hosted-cluster-name>
spec:
  ports:
  - name: https-443
    port: 443
    protocol: TCP
    targetPort: <https-node-port>


  - name: http-80
    port: 80
    protocol: TCP
    targetPort: <http-node-port>


  selector:
    kubevirt.io: virt-launcher
  type: LoadBalancer

Copy to Clipboard

Toggle word wrap

1: 前の手順でメモした HTTPS ノードポート値を指定します。
2: 前の手順でメモした HTTP ノードポート値を指定します。

1.7.11.4.1.3. ワイルドカード DNS の設定
リンクのコピー

ロードバランサーサービスの外部 IP を参照するワイルドカード DNS レコードまたは CNAME を設定します。

次のコマンドを入力して外部 IP アドレスを取得します。

oc -n clusters-<hosted-cluster-name> get service <hosted-cluster-name>-apps -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

oc -n clusters-<hosted-cluster-name> get service <hosted-cluster-name>-apps -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

192.168.20.30

192.168.20.30

Copy to Clipboard

Toggle word wrap

外部 IP アドレスを参照するワイルドカード DNS エントリーを設定します。次の DNS エントリーの例を表示します。
```
*.apps.<hosted-cluster-name\>.<base-domain\>.
```
```
*.apps.<hosted-cluster-name\>.<base-domain\>.
```
Copy to Clipboard Toggle word wrap
DNS エントリーは、クラスターの内部と外部にルーティングできる必要があります。次の DNS 解決の例を参照してください。
```
dig +short test.apps.example.hypershift.lab

192.168.20.30
```
```
dig +short test.apps.example.hypershift.lab

192.168.20.30
```
Copy to Clipboard Toggle word wrap

次のコマンドを実行して、ホストされたクラスターのステータスが Partial から Completed に移行したことを確認します。

oc get --namespace clusters hostedclusters

oc get --namespace clusters hostedclusters

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME            VERSION   KUBECONFIG                       PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
example         4.x.0     example-admin-kubeconfig         Completed   True        False         The hosted control plane is available

NAME            VERSION   KUBECONFIG                       PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
example         4.x.0     example-admin-kubeconfig         Completed   True        False         The hosted control plane is available

Copy to Clipboard

Toggle word wrap

4.x.0 を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

1.7.11.4.1.4. 関連情報
リンクのコピー

OpenShift Virtualization での Hosted Control Plane クラスターの管理
オプション: MetalLB の設定
このトピックの最初のデフォルトの Ingress と DNS の動作に戻ります。

1.7.11.5. オプション: MetalLB の設定
リンクのコピー

MetalLB を設定する前に、MetalLB Operator をインストールする必要があります。詳細は、OpenShift Container Platform ドキュメントの MetalLB Operator のインストール を参照してください。

ゲストクラスターで MetalLB を設定するには、次の手順を実行します。

次のサンプル YAML コンテンツを configure-metallb.yaml ファイルに保存して、MetalLB リソースを作成します。

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、YAML コンテンツを適用します。
```
oc apply -f configure-metallb.yaml
```
```
oc apply -f configure-metallb.yaml
```
Copy to Clipboard Toggle word wrap
以下の出力例を参照してください。
```
metallb.metallb.io/metallb created
```
```
metallb.metallb.io/metallb created
```
Copy to Clipboard Toggle word wrap
以下のサンプル YAML コンテンツを create-ip-address-pool.yaml ファイルに保存して、IPAddressPool リソースを作成します。
```
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: metallb
  namespace: metallb-system
spec:
  addresses:
  - 192.168.216.32-192.168.216.122 
```
```
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: metallb
  namespace: metallb-system
spec:
  addresses:
  - 192.168.216.32-192.168.216.122 
```
1
Copy to Clipboard Toggle word wrap
1
ノードネットワーク内で使用可能な IP アドレスの範囲を使用してアドレスプールを作成します。IP アドレス範囲は、ネットワーク内で使用可能な IP アドレスの未使用のプールに置き換えます。
次のコマンドを入力して、YAML コンテンツを適用します。
```
oc apply -f create-ip-address-pool.yaml
```
```
oc apply -f create-ip-address-pool.yaml
```
Copy to Clipboard Toggle word wrap
以下の出力例を参照してください。
```
ipaddresspool.metallb.io/metallb created
```
```
ipaddresspool.metallb.io/metallb created
```
Copy to Clipboard Toggle word wrap

次のサンプル YAML コンテンツを l2advertisement.yaml ファイルに保存して、L2Advertisement リソースを作成します。

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
   - metallb

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
   - metallb

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、YAML コンテンツを適用します。
```
oc apply -f l2advertisement.yaml
```
```
oc apply -f l2advertisement.yaml
```
Copy to Clipboard Toggle word wrap
以下の出力例を参照してください。
```
l2advertisement.metallb.io/metallb created
```
```
l2advertisement.metallb.io/metallb created
```
Copy to Clipboard Toggle word wrap

1.7.11.5.1. 関連情報
リンクのコピー

MetalLB の詳細は、MetalLB Operator のインストールを参照してください。

1.7.11.6. 追加のネットワーク、Guaranteed CPU、およびノードプールの仮想マシンのスケジュールを設定する
リンクのコピー

ノードプール用に追加のネットワークを設定する必要がある場合、仮想マシン (VM) 用の Guaranteed CPU へのアクセスを要求する場合、または KubeVirt 仮想マシンのスケジュールを管理する必要がある場合は、次の手順を参照してください。

1.7.11.6.1. ノードプールへの複数のネットワークの追加
リンクのコピー

デフォルトでは、ノードプールによって生成されたノードは、Pod ネットワークに割り当てられます。Multus および NetworkAttachmentDefinitions を使用すると、追加のネットワークをノードに割り当てることができます。

ノードに複数のネットワークを追加するには、次のコマンドを実行して --additional-network 引数を使用します。

hcp create cluster kubevirt \
--name <hosted_cluster_name> \ 
--node-pool-replicas <worker_node_count> \ 
--pull-secret <path_to_pull_secret> \ 
--memory <memory> \ 
--cores <cpu> \ 
--additional-network name:<namespace/name> \ 
–-additional-network name:<namespace/name>

hcp create cluster kubevirt \
--name <hosted_cluster_name> \


--node-pool-replicas <worker_node_count> \


--pull-secret <path_to_pull_secret> \


--memory <memory> \


--cores <cpu> \


--additional-network name:<namespace/name> \


–-additional-network name:<namespace/name>

Copy to Clipboard

Toggle word wrap

1: ホステッドクラスターの名前を指定します (例: example)。
2: ワーカーノードの数を指定します (例: 2)。
3: プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4: メモリー値を指定します (例: 8Gi)。
5: CPU 値を指定します (例: 2)。
6: –additional-network 引数の値を name:<namespace/name> に設定します。<namespace/name> は、NetworkAttachmentDefinition の namespace と名前に置き換えます。

1.7.11.6.2. Guaranteed CPU リソースの要求
リンクのコピー

デフォルトでは、KubeVirt 仮想マシンはノード上の他のワークロードと CPU を共有する場合があります。これにより、仮想マシンのパフォーマンスに影響が出る可能性があります。パフォーマンスへの影響を回避するために、仮想マシン用の Guaranteed CPU へのアクセスを要求できます。

保証された CPU リソースを要求するには、次のコマンドを実行して --qos-class 引数を Guaranteed に設定します。

hcp create cluster kubevirt \
--name <hosted_cluster_name> \ 
--node-pool-replicas <worker_node_count> \ 
--pull-secret <path_to_pull_secret> \ 
--memory <memory> \ 
--cores <cpu> \ 
--qos-class Guaranteed

hcp create cluster kubevirt \
--name <hosted_cluster_name> \


--node-pool-replicas <worker_node_count> \


--pull-secret <path_to_pull_secret> \


--memory <memory> \


--cores <cpu> \


--qos-class Guaranteed

Copy to Clipboard

Toggle word wrap

1: ホステッドクラスターの名前を指定します (例: example)。
2: ワーカーノードの数を指定します (例: 2)。
3: プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4: メモリー値を指定します (例: 8Gi)。
5: CPU 値を指定します (例: 2)。
6: --qos-class Guaranteed 引数は、指定された数の CPU リソースが仮想マシンに割り当てられることを保証します。

1.7.11.6.3. ノードセットに KubeVirt 仮想マシンをスケジュールする
リンクのコピー

デフォルトでは、ノードプールによって作成された KubeVirt 仮想マシンは、使用可能な任意のノードにスケジュールされます。KubeVirt 仮想マシンは、仮想マシンを実行するのに十分な容量を持つ特定のノードセットにスケジュールすることもできます。

特定のノードセット上のノードプール内で KubeVirt 仮想マシンをスケジュールするには、次のコマンドを実行して -- 仮想マシン -node-selector 引数を使用します。

hcp create cluster kubevirt \
--name <hosted_cluster_name> \ 
--node-pool-replicas <worker_node_count> \ 
--pull-secret <path_to_pull_secret> \ 
--memory <memory> \ 
--cores <cpu> \ 
--vm-node-selector <label_key>=<label_value>,<label_key>=<label_value>

hcp create cluster kubevirt \
--name <hosted_cluster_name> \


--node-pool-replicas <worker_node_count> \


--pull-secret <path_to_pull_secret> \


--memory <memory> \


--cores <cpu> \


--vm-node-selector <label_key>=<label_value>,<label_key>=<label_value>

Copy to Clipboard

Toggle word wrap

1: ホステッドクラスターの名前を指定します (例: example)。
2: ワーカーノードの数を指定します (例: 2)。
3: プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4: メモリー値を指定します (例: 8Gi)。
5: CPU 値を指定します (例: 2)。
6: --vm-node-selector フラグは、キーと値のペアを含む特定のノードセットを定義します。<label_key> と <label_value> をそれぞれラベルのキーと値に置き換えます。

1.7.11.7. ノードプールのスケーリング
リンクのコピー

oc scale コマンドを使用して、ノードプールを手動でスケーリングできます。

NODEPOOL_NAME=${CLUSTER_NAME}-work
NODEPOOL_REPLICAS=5

oc scale nodepool/$NODEPOOL_NAME --namespace clusters --replicas=$NODEPOOL_REPLICAS

NODEPOOL_NAME=${CLUSTER_NAME}-work
NODEPOOL_REPLICAS=5

oc scale nodepool/$NODEPOOL_NAME --namespace clusters --replicas=$NODEPOOL_REPLICAS

Copy to Clipboard

Toggle word wrap

しばらくしてから、次のコマンドを入力して、ノードプールのステータスを確認します。

oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes

oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

1.7.11.7.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 $DISK

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 $DISK

Copy to Clipboard

Toggle word wrap

clusters namespace 内のノードプールリソースをリストして、nodepool プールのステータスを確認します。

oc get nodepools --namespace clusters

oc get nodepools --namespace clusters

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
example                   example         5               5               False         False        4.x.0
example-extra-cpu         example         2                               False         False                  True              True             Minimum availability requires 2 replicas, current 0 available

NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
example                   example         5               5               False         False        4.x.0
example-extra-cpu         example         2                               False         False                  True              True             Minimum availability requires 2 replicas, current 0 available

Copy to Clipboard

Toggle word wrap

4.x.0 を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

しばらくしてから、次のコマンドを入力してノードプールのステータスを確認できます。

oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes

oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、ノードプールが予期したステータスになっていることを確認します。

oc get nodepools --namespace clusters

oc get nodepools --namespace clusters

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
example                   example         5               5               False         False        4.x.0
example-extra-cpu         example         2               2               False         False        4.x.0

NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
example                   example         5               5               False         False        4.x.0
example-extra-cpu         example         2               2               False         False        4.x.0

Copy to Clipboard

Toggle word wrap

4.x.0 を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

1.7.11.7.1.1. 関連情報
リンクのコピー

OpenShift Virtualization での Hosted Control Plane クラスターの管理
このトピックの最初のノードプールのスケーリングに戻ります。
データプレーンをゼロにスケールダウンするには、データプレーンをゼロにスケールダウンするを参照してください。

1.7.11.8. OpenShift Virtualization でのホステッドクラスターの作成の検証
リンクのコピー

ホステッドクラスターが正常に作成されたことを確認するには、次の手順を完了します。

次のコマンドを入力して、HostedCluster リソースが completed 状態に移行したことを確認します。

oc get --namespace clusters hostedclusters ${CLUSTER_NAME}

oc get --namespace clusters hostedclusters ${CLUSTER_NAME}

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

次のコマンドを入力して、ホステッドクラスター内のすべてのクラスターオペレーターがオンラインであることを確認します。

hcp create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig

hcp create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig

Copy to Clipboard

Toggle word wrap

oc get co --kubeconfig=$CLUSTER_NAME-kubeconfig

oc get co --kubeconfig=$CLUSTER_NAME-kubeconfig

Copy to Clipboard

Toggle word wrap

以下の出力例を参照してください。

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

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

Copy to Clipboard

Toggle word wrap

1.7.11.9. OpenShift Virtualization での Hosted Control Plane のストレージの設定
リンクのコピー

高度な設定が提供されていない場合、デフォルトのストレージクラスが KubeVirt 仮想マシン (VM) イメージ、KubeVirt CSI マッピング、および etcd ボリュームに使用されます。

1.7.11.9.1. KubeVirt CSI ストレージクラスのマッピング
リンクのコピー

KubeVirt CSI では、ReadWriteMany アクセスモードを持つインフラストラクチャーストレージクラスをホステッドクラスターに公開することができます。--infra-storage-class-mapping 引数を使用して、クラスターの作成時にインフラストラクチャークラスターストレージクラスとホストクラスターストレージクラスのマッピングを設定できます。

インフラストラクチャーストレージクラスをホステッドストレージクラスにマップするには、次の例を参照してください。

hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 
--node-pool-replicas <worker-count> \ 
--pull-secret <path-to-pull-secret> \ 
--memory <value-for-memory> \ 
--cores <value-for-cpu> \ 
--infra-storage-class-mapping=<storage-class>/<hosted-storage-class> \

hcp create cluster kubevirt \
--name <hosted-cluster-name> \


--node-pool-replicas <worker-count> \


--pull-secret <path-to-pull-secret> \


--memory <value-for-memory> \


--cores <value-for-cpu> \


--infra-storage-class-mapping=<storage-class>/<hosted-storage-class> \

Copy to Clipboard

Toggle word wrap

1: ホストされているクラスターの名前を指定します (例: example)。
2: ワーカー数を指定します (例: 2)。
3: プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4: メモリーの値を指定します (例: 6Gi)。
5: CPU の値を指定します (例: 2)。
6: <storage-class> をインフラストラクチャーストレージクラス名に置き換え、<hosted-storage-class> をホストされたクラスターストレージクラス名に置き換えます。create コマンド内で --infra-storage-class-mapping 引数を複数回使用できます。

ホスト型クラスターを作成すると、インフラストラクチャーストレージクラスがホストされたクラスター内に表示されます。これらのストレージクラスのいずれかを使用するホステッドクラスター内に PVC を作成すると、KubeVirt CSI はクラスターの作成時に設定したインフラストラクチャーストレージクラスマッピングを使用してそのボリュームをプロビジョニングします。

注記: KubeVirt CSI は、ReadWriteMany (RWX) アクセスが可能なインフラストラクチャーストレージクラスのマッピングのみをサポートします。

1.7.11.9.2. KubeVirt VM ルートボリュームの設定
リンクのコピー

クラスターの作成時に、--root-volume-storage-class 引数を使用して、KubeVirt 仮想マシンルートボリュームをホストするために使用されるストレージクラスを設定できます。

KubeVirt VM のカスタムストレージクラスとボリュームサイズを設定するには、次の例を参照してください。

hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 
--node-pool-replicas <worker-count> \ 
--pull-secret <path-to-pull-secret> \ 
--memory <value-for-memory> \ 
--cores <value-for-cpu> \ 
--root-volume-storage-class <root-volume-storage-class> \ 
--root-volume-size <volume-size>

hcp create cluster kubevirt \
--name <hosted-cluster-name> \


--node-pool-replicas <worker-count> \


--pull-secret <path-to-pull-secret> \


--memory <value-for-memory> \


--cores <value-for-cpu> \


--root-volume-storage-class <root-volume-storage-class> \


--root-volume-size <volume-size>

Copy to Clipboard

Toggle word wrap

1: ホストされているクラスターの名前を指定します (例: example)。
2: ワーカー数を指定します (例: 2)。
3: プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4: メモリーの値を指定します (例: 6Gi)。
5: CPU の値を指定します (例: 2)。
6: KubeVirt 仮想マシンルートボリュームをホストするために使用されるストレージクラスの名前を指定します (例: ocs-storagecluster-ceph-rbd)。
7: ボリュームサイズを指定します (例: 64)。

結果は、ocs-storagecluster-ceph-rdb ストレージクラスにホストされる PVC 上でホストされる仮想マシンを含むホストされたクラスターになります。

1.7.11.9.3. KubeVirt VM イメージキャッシュの有効化
リンクのコピー

KubeVirt イメージキャッシュは、クラスターの起動時間とストレージ使用率の両方を最適化するために使用できる高度な機能です。この機能には、スマートクローン作成と ReadWriteMany アクセスモードが可能なストレージクラスの使用が必要です。スマートクローン作成の詳細は、smart-cloning を使用したデータボリュームのクローン作成 を参照してください。

イメージのキャッシュは次のように機能します。

VM イメージは、ホステッドクラスターに関連付けられた PVC にインポートされます。
その PVC の一意のクローンは、クラスターにワーカーノードとして追加されるすべての KubeVirt VM に対して作成されます。

イメージキャッシュを使用すると、イメージのインポートが 1 つだけ必要になるため、VM の起動時間が短縮されます。ストレージクラスがコピーオンライトクローン作成をサポートしている場合、クラスター全体のストレージ使用量をさらに削減できます。

イメージキャッシュを有効にするには、クラスターの作成時に、次の例に示すように、--root-volume-cache-strategy=PVC 引数を使用します。

hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 
--node-pool-replicas <worker-count> \ 
--pull-secret <path-to-pull-secret> \ 
--memory <value-for-memory> \ 
--cores <value-for-cpu> \ 
--root-volume-cache-strategy=PVC

hcp create cluster kubevirt \
--name <hosted-cluster-name> \


--node-pool-replicas <worker-count> \


--pull-secret <path-to-pull-secret> \


--memory <value-for-memory> \


--cores <value-for-cpu> \


--root-volume-cache-strategy=PVC

Copy to Clipboard

Toggle word wrap

1: ホストされているクラスターの名前を指定します (例: example)。
2: ワーカー数を指定します (例: 2)。
3: プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4: メモリーの値を指定します (例: 6Gi)。
5: CPU の値を指定します (例: 2)。
6: イメージキャッシュのストラテジー (例: PVC) を指定します。

1.7.11.9.4. etcd ストレージの設定
リンクのコピー

クラスターの作成時に、--etcd-storage-class 引数を使用して、etcd データをホストするために使用されるストレージクラスを設定できます。

etcd のストレージクラスを設定するには、次の例を参照してください。

hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 
--node-pool-replicas <worker-count> \ 
--pull-secret <path-to-pull-secret> \ 
--memory <value-for-memory> \ 
--cores <value-for-cpu> \ 
--etcd-storage-class=<etcd-storage-class-name>

hcp create cluster kubevirt \
--name <hosted-cluster-name> \


--node-pool-replicas <worker-count> \


--pull-secret <path-to-pull-secret> \


--memory <value-for-memory> \


--cores <value-for-cpu> \


--etcd-storage-class=<etcd-storage-class-name>

Copy to Clipboard

Toggle word wrap

1: ホストされているクラスターの名前を指定します (例: example)。
2: ワーカー数を指定します (例: 2)。
3: プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4: メモリーの値を指定します (例: 6Gi)。
5: CPU の値を指定します (例: 2)。
6: etcd ストレージクラス名を指定します (例: lvm-storageclass)。--etcd-storage-class 引数を指定しない場合は、デフォルトのストレージクラスが使用されます。

1.7.11.9.4.1. 関連情報
リンクのコピー

smart-cloning を使用したデータボリュームのクローン作成

1.7.11.10. OpenShift Virtualization 上のホステッドクラスターの破棄
リンクのコピー

ホステッドクラスターとそのマネージドクラスターリソースを破棄するには、次の手順を実行します。

次のコマンドを実行して、マルチクラスターエンジン Operator のマネージドクラスターリソースを削除します。
```
oc delete managedcluster <managed_cluster_name>
```
```
oc delete managedcluster <managed_cluster_name>
```
Copy to Clipboard Toggle word wrap
ここで、<managed_cluster_name> は管理対象クラスターの名前です。
次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。
```
hcp destroy cluster kubevirt --name <hosted_cluster_name>
```
```
hcp destroy cluster kubevirt --name <hosted_cluster_name>
```
Copy to Clipboard Toggle word wrap
<hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。

1.7.12. 非接続環境での 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.12.1. 非接続環境のアーキテクチャー
リンクのコピー

Agent プラットフォームを使用して、ベアメタル上に Hosted Control Plane をプロビジョニングできます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。Central Infrastructure Management の概要は、central infrastructure management の有効化を参照してください。

非接続環境の次のアーキテクチャー図を参照してください。

Disconnected architecture diagram

TLS サポートを備えたレジストリー証明書のデプロイメント、Web サーバー、DNS などのインフラストラクチャーサービスを設定して、非接続デプロイメントが確実に機能するようにします。
openshift-config namespace に config map を作成します。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-engine namespace に 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
...
...

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
...
...

Copy to Clipboard

Toggle word wrap

レジストリーの CA 証明書が含まれます。