1.7. ホステッドコントロールプレーン (テクノロジープレビュー)
マルチクラスターエンジン Operator クラスター管理では、スタンドアロンまたはホステッドコントロールプレーンの 2 つの異なるコントロールプレーン設定を使用して、OpenShift Container Platform クラスターをデプロイできます。スタンドアロン設定では、専用の仮想マシンまたは物理マシンを使用して、OpenShift Container Platform のコントロールプレーンをホストします。OpenShift Container Platform の Hosted control plane を使用すると、コントロールプレーンごとに専用の物理マシンを必要とせずに、ホスティングクラスター上にコントロールプレーンを Pod として作成できます。
OpenShift Container Platform のホステッドコントロールプレーンは、Amazon Web Services (AWS) およびベアメタルでテクノロジープレビュー機能として利用できます。コントロールプレーンは、OpenShift Container Platform バージョン 4.10.7 以降でホスティングできます。
注記: ホステッドコントロールプレーンの同じプラットフォームで、ハブクラスターとワーカーを実行します。
コントロールプレーンは、単一の namespace に含まれる Pod として実行され、Hosted control plane クラスターに関連付けられます。OpenShift Container Platform がこのタイプのホステッドクラスターを作成すると、コントロールプレーンから独立したワーカーノードが作成されます。
Hosted control plane クラスターには、いくつかの利点があります。
- 専用コントロールプレーンノードをホストする必要がなくなるため、コストを節約できます。
- コントロールプレーンとワークロードを分離することで、分離が改善され、変更が必要になる設定エラーが減少します。
- コントロールプレーンノードのブートストラップの要件をなくすことで、クラスターの作成時間を短縮します。
- ターンキーデプロイメントまたは完全にカスタマイズされた OpenShift Container Platform プロビジョニングをサポートします。
ホステッドコントロールプレーンの詳細については、以下のトピックを参照してください。
1.7.1. AWS でのホスティングクラスターの設定 (テクノロジープレビュー)
Hosted control plane を設定するには、ホスティングクラスターとホステッドクラスターが必要です。hypershift-addon
マネージドクラスターアドオンを使用して既存のマネージドクラスターに HyperShift Operator をデプロイすることにより、そのクラスターをホスティングクラスターとして有効にして、ホステッドクラスターを作成し始めることができます。
マルチクラスターエンジン Operator 2.2 は、デフォルトの local-cluster
とハブクラスターのみをホスティングクラスターとしてサポートします。
ホステッドコントロールプレーンはテクノロジープレビュー機能であるため、関連コンポーネントはデフォルトで無効になっています。
既存のクラスターをホスティングクラスターとして機能するように設定することで、Hosted control plane をデプロイできます。ホスティングクラスターは、コントロールプレーンがホストされている Red Hat OpenShift Container Platform クラスターです。Red Hat Advanced Cluster Management 2.7 は、local-cluster
とも呼ばれるハブクラスターをホスティングクラスターとして使用できます。local-cluster
をホスティングクラスターとして設定する方法については、次のトピックを参照してください。
ベストプラクティス: ホステッドコントロールプレーンでは、必ず同じプラットフォームでハブクラスターとワーカーを実行してください。
1.7.1.1. 前提条件
ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。
- OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.2 以降のマルチクラスターエンジン。マルチクラスターエンジン 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.2 以降で自動的にインポートされます。local-cluster
の詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。oc get managedclusters local-cluster
- HyperShift Operator を実行するための少なくとも 3 つのワーカーノードを含むホスティングクラスター。
- AWS コマンドラインインターフェイス。
1.7.1.2. Amazon Web Services S3 バケットと S3 OIDC シークレットの作成
AWS でホステッドクラスターを作成および管理する予定の場合は、次の手順を実行します。
クラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを持つ S3 バケットを作成します。
us-east-1 リージョンにバケットを作成するには、次のコードを入力します。
BUCKET_NAME=<your_bucket_name> aws s3api create-bucket --bucket $BUCKET_NAME aws s3api delete-public-access-block --bucket $BUCKET_NAME echo '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::${BUCKET_NAME}/*" } ] }' | envsubst > policy.json aws s3api put-bucket-policy --bucket $BUCKET_NAME --policy file://policy.json
us-east-1 リージョン以外のリージョンにバケットを作成するには、次のコードを入力します。
BUCKET_NAME=your-bucket-name REGION=us-east-2 aws s3api create-bucket --bucket $BUCKET_NAME \ --create-bucket-configuration LocationConstraint=$REGION \ --region $REGION aws s3api delete-public-access-block --bucket $BUCKET_NAME echo '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::${BUCKET_NAME}/*" } ] }' | envsubst > policy.json aws s3api put-bucket-policy --bucket $BUCKET_NAME --policy file://policy.json
-
HyperShift Operator 用に
hypershift-operator-oidc-provider-s3-credentials
という名前の OIDC S3 シークレットを作成します。 -
シークレットを
local-cluster
namespace に保存します。 シークレットに以下のフィールドが含まれることを確認するには、以下の表を参照してください。
フィールド名 説明 bucket
HyperShift クラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを備えた S3 バケットが含まれます。
credentials
バケットにアクセスできる
default
プロファイルの認証情報を含むファイルへの参照。デフォルトでは、HyperShift はdefault
プロファイルのみを使用してバケット
を操作します。region
S3 バケットのリージョンを指定します。
次の例は、サンプルの AWS シークレットテンプレートを示しています。
oc create secret generic hypershift-operator-oidc-provider-s3-credentials --from-file=credentials=$HOME/.aws/credentials --from-literal=bucket=<s3-bucket-for-hypershift> --from-literal=region=<region> -n local-cluster
注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に
hypershift-operator-oidc-provider-s3-credentials
シークレットのバックアップを有効にするラベルを追加します。oc label secret hypershift-operator-oidc-provider-s3-credentials -n local-cluster cluster.open-cluster-management.io/backup=true
1.7.1.3. ルーティング可能なパブリックゾーンの作成
ゲストクラスター内のアプリケーションにアクセスするには、パブリックゾーンがルーティング可能である必要があります。パブリックゾーンが存在する場合は、この手順を省略します。省力しない場合は、パブリックゾーンが既存の機能に影響を及ぼします。
次のコマンドを実行して、クラスター DNS レコードのパブリックゾーンを作成します。
BASE_DOMAIN=www.example.com aws route53 create-hosted-zone --name $BASE_DOMAIN --caller-reference $(whoami)-$(date --rfc-3339=date)
1.7.1.4. 外部 DNS の有効化
ホステッドコントロールプレーンクラスターをサービスレベル DNS (外部 DNS) でプロビジョニングする予定の場合は、次の手順を実行します。
-
HyperShift Operator の AWS 認証情報シークレットを作成し、
local-cluster
名前空間でhypershift-operator-external-dns-credentials
という名前を付けます。 シークレットに必須フィールドが含まれていることを確認するには、以下の表を参照してください。
フィールド名 説明 任意または必須 provider
サービスレベル DNS ゾーンを管理する DNS プロバイダー。
必須
domain-filter
サービスレベルドメイン。
必須
credentials
すべての外部 DNS タイプをサポートする認証情報ファイル。
AWS キーを使用する場合のオプション
aws-access-key-id
認証情報アクセスキー ID。
AWS DNS サービスを使用する場合のオプション
aws-secret-access-key
認証情報アクセスキーのシークレット。
AWS DNS サービスを使用する場合のオプション
詳細は、HyperShift ドキュメントの 外部 DNS を参照してください。次の例は、サンプルの
hypershift-operator-external-dns-credentials
シークレットテンプレートを示しています。oc create secret generic hypershift-operator-external-dns-credentials --from-literal=provider=aws --from-literal=domain-filter=service.my.domain.com --from-file=credentials=<credentials-file> -n local-cluster
注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に
hypershift-operator-external-dns-credentials
シークレットのバックアップを有効にするラベルを追加します。oc label secret hypershift-operator-external-dns-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
1.7.1.5. AWS PrivateLink の有効化
PrivateLink を使用して AWS プラットフォームで Hosted control plane クラスターをプロビジョニングする予定の場合は、次の手順を実行します。
-
HyperShift Operator の AWS 認証情報シークレットを作成し、
hypershift-operator-private-link-credentials
という名前を付けます。シークレットは、ホスティングクラスターとして使用されるマネージドクラスターの namespace であるマネージドクラスター namespace に存在する必要があります。local-cluster
を使用した場合は、local-cluster
namespace にシークレットを作成します シークレットに必要なフィールドが含まれることを確認するには、以下の表を参照してください。
フィールド名
説明
任意または必須
region
Private Link で使用するリージョン
必須
aws-access-key-id
認証情報アクセスキー ID。
必須
aws-secret-access-key
認証情報アクセスキーのシークレット。
必須
詳細は、HyperShift ドキュメントのAWS プライベートクラスターのデプロイ を参照してください。次の例は、サンプルの
hypershift-operator-private-link-credentials
シークレットテンプレートを示しています。oc create secret generic hypershift-operator-private-link-credentials --from-literal=aws-access-key-id=<aws-access-key-id> --from-literal=aws-secret-access-key=<aws-secret-access-key> --from-literal=region=<region> -n local-cluster
注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に
hypershift-operator-private-link-credentials
シークレットのバックアップを有効にするラベルを追加します。oc label secret hypershift-operator-private-link-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
1.7.1.6. ホステッドコントロールプレーン機能の有効化
ホステッドコントロールプレーン機能はデフォルトで無効になっています。この機能を自動的に有効にすると、hypershift-addon
マネージドクラスターアドオンも有効になります。次のコマンドを実行して、以下の機能を有効にすることができます。
oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-preview","enabled": true}]}}}'
次のコマンドを実行して、hypershift-preview
および hypershift-local-hosting
機能が MultiClusterEngine
カスタムリソースで有効になっていることを確認します。
oc get mce multiclusterengine -o yaml
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: overrides: components: - name: hypershift-preview enabled: true - name: hypershift-local-hosting enabled: true
1.7.1.6.1. local-cluster の hypershift-addon マネージドクラスターアドオンを手動で有効にする
Hosted control plane 機能を有効にすると、hypershift-addon
マネージドクラスターアドオンが自動的に有効になります。hypershift-addon
マネージドクラスターアドオンを手動で有効にする必要がある場合は、次の手順を実行して hypershift-addon
を使用し、HyperShift Operator を local-cluster
にインストールします。
以下の例のようなファイルを作成して、
ManagedClusterAddon
HyperShift アドオンを作成します。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ManagedClusterAddOn metadata: name: hypershift-addon namespace: local-cluster spec: installNamespace: open-cluster-management-agent-addon
以下のコマンドを実行してこのファイルを適用します。
oc apply -f <filename>
filename
は、作成したファイル名に置き換えます。以下のコマンドを実行して、
hypershift-addon
がインストールされていることを確認します。oc get managedclusteraddons -n local-cluster hypershift-addon
アドオンがインストールされている場合、出力は以下の例のようになります。
NAME AVAILABLE DEGRADED PROGRESSING hypershift-addon True
HyperShift アドオンがインストールされ、HyperShift クラスターを作成および管理するためのホスティングクラスターが利用できます。
1.7.1.7. ホステッドコントロールプレーン CLI のインストール
ホステッドコントロールプレーン (HyperShift) CLI は、OpenShift Container Platform のホステッドコントロールプレーンクラスターを作成および管理するために使用されます。ホステッドコントロールプレーン機能を有効にした後、次の手順を実行してホステッドコントロールプレーン CLI をインストールできます。
- OpenShift Container Platform コンソールから、Help icon > Command Line Tools をクリックします。
お使いのプラットフォームの Download hypershift CLI をクリックします。
注記: ダウンロードは
hypershift-preview
機能を有効にしている場合にのみ表示されます。次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。
tar xvzf hypershift.tar.gz
次のコマンドを実行して、バイナリーファイルを実行可能にします。
chmod +x hypershift
次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。
sudo mv hypershift /usr/local/bin/.
hypershift create cluster
コマンドを使用して、ホステッドクラスターを作成および管理できるようになりました。次のコマンドを使用して、使用可能なパラメーターを一覧表示します。
hypershift create cluster aws --help
1.7.1.8. 関連情報
- AWS 認証情報シークレットの詳細は、HyperShift ドキュメントの AWS プライベートクラスターのデプロイ を参照してください。
- 外部 DNS の詳細は、HyperShift ドキュメントの 外部 DNS を参照してください。
- SR-IOV Operator をデプロイできるようになりました。SR-IOV Operator のデプロイに関する詳細は、ホステッドコントロールプレーン用の SR-IOV Operator のデプロイ を参照してください。
1.7.2. AWS でのホステッドコントロールプレーンクラスターの管理 (テクノロジープレビュー)
Kubernetes Operator コンソール用のマルチクラスターエンジンを使用して、Red Hat OpenShift Container Platform がホストするクラスターを作成できます。ホステッドコントロールプレーンは、Amazon Web Services (AWS) でテクノロジープレビューとして利用できます。AWS でホステッドコントロールプレーンを使用する場合、コンソールを使用してホステッドクラスターを作成するか、コンソールまたは CLI のいずれかを使用してホステッドクラスターをインポートすることができます。
1.7.2.1. 前提条件
ホステッドコントロールプレーンクラスターを作成する前に、ホステッドコントロールプレーンを設定する必要があります。詳細については、ホステッドコントロールプレーンの設定 (テクノロジープレビュー) を参照してください。
1.7.2.2. コンソールを使用した AWS でのホステッドコントロールプレーンクラスターの作成
マルチクラスターエンジン Operator コンソールからホステッドコントロールプレーンクラスターを作成するには、Infrastructure > Clusters に移動します。クラスター ページで、Create cluster > Amazon Web Services > Hosted をクリックし、コンソールで手順を完了します。
注記: コンソールにアクセスしたら、提供される基本情報を使用して、コマンドラインでクラスターを作成します。
1.7.2.3. コマンドラインを使用して AWS にホストされたクラスターをデプロイする
HyperShift コマンドラインインターフェイスをセットアップし、local-cluster
をホスティングクラスターとして有効化したら、以下の手順を実行して、ホステッドクラスターを AWS にデプロイできます。
環境変数を次のように設定し、必要に応じて変数を認証情報に置き換えます。
export REGION=us-east-1 export CLUSTER_NAME=clc-name-hs1 export INFRA_ID=clc-name-hs1 export BASE_DOMAIN=dev09.red-chesterfield.com export AWS_CREDS=$HOME/name-aws export PULL_SECRET=/Users/username/pull-secret.txt export BUCKET_NAME=acmqe-hypershift export BUCKET_REGION=us-east-1
CLUSTER_NAME
とINFRA_ID
の値が同じであることを確認してください。そうしないと、クラスターが Kubernetes Operator コンソールのマルチクラスターエンジンに正しく表示されない可能性があります。各変数の説明を表示するには、次のコマンドを実行します。hypershift create cluster aws --help
- ハブクラスターにログインしていることを確認します。
次のコマンドを実行して、ホステッドクラスターを作成します。
hypershift create cluster aws \ --name $CLUSTER_NAME \ --infra-id $INFRA_ID \ --aws-creds $AWS_CREDS \ --pull-secret $PULL_SECRET \ --region $REGION \ --generate-ssh \ --node-pool-replicas 3 \ --namespace <hypershift-hosting-service-cluster>
注記: デフォルトでは、
HostedCluster
とNodePool
のすべてのカスタムリソースがclusters
namespace に作成されます。--namespace <namespace>
パラメーターを指定すると、選択した namespace にHostedCluster
およびNodePool
カスタムリソースが作成されます。以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。
oc get hostedclusters -n <hypershift-hosting-service-cluster>
1.7.2.4. ホストされたコントロールプレーンクラスターの AWS へのインポート
コンソールを使用して、ホストされたコントロールプレーンクラスターをインポートできます。
- Infrastructure > Clusters に移動し、インポート予定の、ホストされたクラスターを選択します。
ホストされたクラスターのインポート をクリックします。
注記: 検出された ホステッドクラスターについては、コンソールからインポートすることもできますが、クラスターはアップグレード可能な状態である必要があります。Hosted control plane を使用できないため、ホステッドクラスターがアップグレード可能な状態ではない場合、クラスターへのインポートは無効になります。Import をクリックして、プロセスを開始します。クラスターが更新を受信している間、ステータスは
Importing
であり、その後、Ready
に変わります。
次の手順を完了し、CLI を使用して AWS でホストされたコントロールプレーンクラスターをインポートすることもできます。
以下のコマンドを実行して、アノテーションを
HostedCluster
カスタムリソースに追加します。oc edit hostedcluster <cluster_name> -n clusters
<cluster_name>
は、ホステッドクラスターの名前に置き換えます。以下のコマンドを実行して、アノテーションを
HostedCluster
カスタムリソースに追加します。cluster.open-cluster-management.io/hypershiftdeployment: local-cluster/<cluster_name> cluster.open-cluster-management.io/managedcluster-name: <cluster_name>
<cluster_name>
は、ホステッドクラスターの名前に置き換えます。以下のサンプル YAML ファイルを使用して、
ManagedCluster
リソースを作成します。apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: annotations: import.open-cluster-management.io/hosting-cluster-name: local-cluster import.open-cluster-management.io/klusterlet-deploy-mode: Hosted open-cluster-management/created-via: other labels: cloud: auto-detect cluster.open-cluster-management.io/clusterset: default name: <cluster_name> vendor: OpenShift name: <cluster_name> spec: hubAcceptsClient: true leaseDurationSeconds: 60
<cluster_name>
は、ホステッドクラスターの名前に置き換えます。以下のコマンドを実行してリソースを適用します。
oc apply -f <file_name>
<file_name> を、直前の手順で作成した YAML ファイル名に置き換えます。
以下のサンプル YAML ファイルを使用して、
KlusterletAddonConfig
リソースを作成します。これは、Red Hat Advanced Cluster Management にのみ適用されます。マルチクラスターエンジン Operator のみをインストールした場合は、この手順を省略します。apiVersion: agent.open-cluster-management.io/v1 kind: KlusterletAddonConfig metadata: name: <cluster_name> namespace: <cluster_name> spec: clusterName: <cluster_name> clusterNamespace: <cluster_name> clusterLabels: cloud: auto-detect vendor: auto-detect applicationManager: enabled: true certPolicyController: enabled: true iamPolicyController: enabled: true policyController: enabled: true searchCollector: enabled: false
<cluster_name>
は、ホステッドクラスターの名前に置き換えます。以下のコマンドを実行してリソースを適用します。
oc apply -f <file_name>
<file_name> を、直前の手順で作成した YAML ファイル名に置き換えます。
インポートプロセスが完了すると、ホステッドクラスターがコンソールに表示されます。以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。
oc get managedcluster <cluster_name>
1.7.2.5. AWS でのホスティングクラスターへのアクセス
ホステッドコントロールプレーンクラスターのアクセスシークレットは、hypershift-management-cluster
名前空間に格納されます。以下のシークレット名の形式を参照してください。
-
kubeconfig
シークレット:<hostingNamespace>-<name>-admin-kubeconfig
(clusters-hypershift-demo-admin-kubeconfig) -
kubeadmin
パスワードシークレット:<hostingNamespace>-<name>-kubeadmin-password
(clusters-hypershift-demo-kubeadmin-password)
1.7.2.6. AWS でのホステッドクラスターの破棄
ホステッドクラスターとそのマネージドクラスターリソースを破棄するには、次の手順を実行します。
次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。
hypershift destroy cluster aws --name <cluster_name> --infra-id <infra_id> --aws-creds <aws-credentials> --base-domain <base_domain> --destroy-cloud-resources
必要に応じて名前を置き換えます。
次のコマンドを実行して、マルチクラスターエンジン Operator のマネージドクラスターリソースを削除します。
oc delete managedcluster <cluster_name>
cluster_name
をクラスターの名前に置き換えます。
1.7.3. ベアメタルでのホスティングクラスターの設定 (テクノロジープレビュー)
ホステッドコントロールプレーンを設定するには、ホスティング クラスターと ホステッド クラスターが必要です。hypershift
アドオンを使用してマネージドクラスターをホスティングクラスターとして有効にし、そのクラスターに HyperShift Operator をデプロイできます。その後、ホストされたクラスターの作成を開始できます。
マルチクラスターエンジン Operator 2.2 は、デフォルトの local-cluster
とハブクラスターのみをホスティングクラスターとしてサポートします。
ホステッドコントロールプレーンはテクノロジープレビュー機能であるため、関連コンポーネントはデフォルトで無効になっています。
ホスティングクラスターとして機能するようにクラスターを設定することで、ホストされたコントロールプレーンをデプロイメントできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。
Red Hat Advanced Cluster Management 2.7 では、local-cluster
としても知られるマネージドハブクラスターをホスティングクラスターとして使用できます。
重要:
- ホステッドコントロールプレーンの同じプラットフォームで、ハブクラスターとワーカーを実行します。
- エージェントプラットフォームを使用して、Hosted control plane をベアメタルでプロビジョニングできます。エージェントプラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。
-
各ベアメタルホストは、central infrastructure management が提供する検出イメージを使用して開始する必要があります。ホストは手動で起動することも、
Cluster-Baremetal-Operator
を使用して自動化することもできます。各ホストが起動すると、エージェントプロセスが実行され、ホストの詳細が検出され、インストールが完了します。Agent
カスタムリソースは、各ホストを表します。 - エージェントプラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane (HCP) namespace に Agent Cluster API プロバイダーをインストールします。
- ノードプールをスケールアップすると、マシンが作成されます。Cluster API プロバイダーは、承認され、検証に合格し、現在使用されておらず、ノードプールの仕様で指定されている要件を満たすエージェントを見つけます。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。クラスターを再利用する前に、検出イメージを使用してクラスターを再起動し、ノード数を更新する必要があります。
1.7.3.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
- HyperShift Operator を実行するには、3 つ以上のワーカーノードを含むホスティングクラスターが必要です。
- ホストされたコントロールプレーン機能を有効にする必要があります。詳細は、ホストされたコントロールプレーン機能の有効化 を参照してください。
1.7.3.2. 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
1.7.3.3. 関連情報
- central infrastructure management サービスの概要は、Kube API - Getting Started Guide を参照してください。
- ロードバランサーの詳細については ユーザーによってプロビジョニングされるインフラストラクチャーの負荷分散要件 を参照してください。
- SR-IOV Operator をデプロイできるようになりました。SR-IOV Operator のデプロイに関する詳細は、ホステッドコントロールプレーン用の SR-IOV Operator のデプロイ を参照してください。
1.7.4. ベアメタルでのホステッドコントロールプレーンクラスターの管理 (テクノロジープレビュー)
Kubernetes Operator コンソール用のマルチクラスターエンジンを使用して、Red Hat OpenShift Container Platform のホステッドクラスターを作成および管理できます。ホステッドコントロールプレーンは、Amazon Web Services (AWS) およびベアメタルでテクノロジープレビューとして利用できます。
1.7.4.1. 前提条件
ホステッドコントロールプレーンクラスターを作成する前に、ベアメタル用のホステッドコントロールプレーンを設定する必要があります。詳細については、ベアメタルでのホスティングクラスターの設定 (テクノロジープレビュー) を参照してください。
1.7.4.2. コンソールを使用してベアメタルエージェント上にホストされたコントロールプレーンクラスターを作成する
マルチクラスターエンジン Operator コンソールからホステッドコントロールプレーンクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster > Host Inventory > Hosted control plane をクリックし、コンソールで手順を完了します。
重要: クラスターを作成すると、マルチクラスターエンジン Operator コントローラーは、クラスターとそのリソースのための名前空間を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。
クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin
権限がない場合に、clusterset-admin
権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットオプションがない場合には、クラスター管理者に連絡して、clusterset-admin
権限を受け取ってください。
マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet
に割り当てない場合は、デフォルト
のマネージドクラスターセットに自動的に追加されます。
このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。ホステッドコントロールプレーンクラスターは、提供されたリリースイメージのいずれかを使用する必要があります。
インフラストラクチャー環境で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。既存の情報を使用することも、それを上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。
-
HTTP プロキシー URL:
HTTP
トラフィックのプロキシーとして使用する URL。 -
HTTPS プロキシー URL:
HTTPS
トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL
と同じ値がHTTP
およびHTTPS
の両方に使用されます。 -
プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (
.
) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*
) を追加し、すべての宛先のプロキシーをバイパスします。 - 追加のトランスとバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツ。
注記: クラスターのインポートには、クラスターの詳細で提示された oc
コマンドを実行する必要があります。クラスターを作成すると、Red Hat Advanced Cluster Management で管理されるように自動的に設定されません。
1.7.4.3. コマンドラインを使用してベアメタル上にホストされたクラスターを作成する
クラスターにデフォルトのストレージクラスが設定されていることを確認します。設定されていない場合は、PVC が保留になる可能性があります。
次のコマンドを入力します。
export CLUSTERS_NAMESPACE="clusters" export HOSTED_CLUSTER_NAME="example" export HOSTED_CONTROL_PLANE_NAMESPACE="${CLUSTERS_NAMESPACE}-${HOSTED_CLUSTER_NAME}" export BASEDOMAIN="krnl.es" export PULL_SECRET_FILE=$PWD/pull-secret export MACHINE_CIDR=192.168.122.0/24 # Typically the namespace is created by the hypershift-operator # but agent cluster creation generates a capi-provider role that # needs the namespace to already exist oc create ns ${HOSTED_CONTROL_PLANE_NAMESPACE} hypershift create cluster agent \ --name=${HOSTED_CLUSTER_NAME} \ --pull-secret=${PULL_SECRET_FILE} \ --agent-namespace=${HOSTED_CONTROL_PLANE_NAMESPACE} \ --base-domain=${BASEDOMAIN} \ --api-server-address=api.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN} \
しばらくしてから、次のコマンドを入力して、ホストされたコントロールプレーン Pod が稼働中であることを確認します。
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get pods
出力例
NAME READY STATUS RESTARTS AGE capi-provider-7dcf5fc4c4-nr9sq 1/1 Running 0 4m32s catalog-operator-6cd867cc7-phb2q 2/2 Running 0 2m50s certified-operators-catalog-884c756c4-zdt64 1/1 Running 0 2m51s cluster-api-f75d86f8c-56wfz 1/1 Running 0 4m32s cluster-autoscaler-7977864686-2rz4c 1/1 Running 0 4m13s cluster-network-operator-754cf4ffd6-lwfm2 1/1 Running 0 2m51s cluster-policy-controller-784f995d5-7cbrz 1/1 Running 0 2m51s cluster-version-operator-5c68f7f4f8-lqzcm 1/1 Running 0 2m51s community-operators-catalog-58599d96cd-vpj2v 1/1 Running 0 2m51s control-plane-operator-f6b4c8465-4k5dh 1/1 Running 0 4m32s etcd-0 1/1 Running 0 4m13s hosted-cluster-config-operator-c4776f89f-dt46j 1/1 Running 0 2m51s ignition-server-7cd8676fc5-hjx29 1/1 Running 0 4m22s ingress-operator-75484cdc8c-zhdz5 1/2 Running 0 2m51s konnectivity-agent-c5485c9df-jsm9s 1/1 Running 0 4m13s konnectivity-server-85dc754888-7z8vm 1/1 Running 0 4m13s kube-apiserver-db5fb5549-zlvpq 3/3 Running 0 4m13s kube-controller-manager-5fbf7b7b7b-mrtjj 1/1 Running 0 90s kube-scheduler-776c59d757-kfhv6 1/1 Running 0 3m12s machine-approver-c6b947895-lkdbk 1/1 Running 0 4m13s oauth-openshift-787b87cff6-trvd6 2/2 Running 0 87s olm-operator-69c4657864-hxwzk 2/2 Running 0 2m50s openshift-apiserver-67f9d9c5c7-c9bmv 2/2 Running 0 89s openshift-controller-manager-5899fc8778-q89xh 1/1 Running 0 2m51s openshift-oauth-apiserver-569c78c4d-568v8 1/1 Running 0 2m52s packageserver-ddfffb8d7-wlz6l 2/2 Running 0 2m50s redhat-marketplace-catalog-7dd77d896-jtxkd 1/1 Running 0 2m51s redhat-operators-catalog-d66b5c965-qwhn7 1/1 Running 0 2m51s
1.7.4.4. InfraEnv の作成
InfraEnv
は、ライブ ISO を開始しているホストがエージェントとして参加できる環境です。この場合、エージェントはホステッドコントロールプレーンと同じ名前空間に作成されます。
InfraEnv
を作成するには、次のコマンドを入力します。export SSH_PUB_KEY=$(cat $HOME/.ssh/id_rsa.pub) envsubst <<"EOF" | oc apply -f - apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: ${HOSTED_CLUSTER_NAME} namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE} spec: pullSecretRef: name: pull-secret sshAuthorizedKey: ${SSH_PUB_KEY} EOF
仮想マシンまたはベアメタルマシンがエージェントとして参加できるようにするライブ ISO を生成するには、次のコマンドを入力します。
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get InfraEnv ${HOSTED_CLUSTER_NAME} -ojsonpath="{.status.isoDownloadURL}"
1.7.4.5. エージェントの追加
エージェントを追加するには、手動でマシンを設定してライブ ISO で開始するか、Metal3 を使用します。
エージェントを手動で追加するには、次の手順に従います。
-
ライブ ISO をダウンロードし、それを使用してノード (ベアメタルまたは VM) を起動します。起動時に、ノードは Assisted Service と通信し、
InfraEnv
と同じ名前空間にエージェントとして登録します。 各エージェントが作成された後、オプションでその
installation_disk_id
とhostname
を仕様に設定することができます。次に、エージェントを使用する準備ができていることを示すためにこれを承認します。oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agents
出力例
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assign
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type merge oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type merge
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agents
出力例
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assign
-
ライブ ISO をダウンロードし、それを使用してノード (ベアメタルまたは VM) を起動します。起動時に、ノードは Assisted Service と通信し、
Metal3 を使用してエージェントを追加するには、次の手順に従います。
Assisted Service を使用してカスタム ISO を作成し、Baremetal Operator を使用してインストールを実行します。
重要:
BaremetalHost
オブジェクトは、baremetal-operator 名前空間の外部に作成されるため、すべての名前空間を監視するように Operator を設定する必要があります。oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'
metal3
Pod がopenshift-machine-api
名前空間で再起動されます。metal3
Pod の準備が再び整うまで待ちます。until oc wait -n openshift-machine-api $(oc get pods -n openshift-machine-api -l baremetal.openshift.io/cluster-baremetal-operator=metal3-state -o name) --for condition=containersready --timeout 10s >/dev/null 2>&1 ; do sleep 1 ; done
BaremetalHost オブジェクトを作成します。ベアメタルノードを起動するために必要ないくつかの変数を設定する必要があります。
-
BMC_USERNAME
: BMC に接続するためのユーザー名。 -
BMC_PASSWORD
: BMC に接続するためのパスワード。 -
BMC_IP
: Metal3 が BMC に接続するために使用する IP。 -
WORKER_NAME
: BaremetalHost オブジェクトの名前 (この値はホスト名としても使用されます) -
BOOT_MAC_ADDRESS
: MachineNetwork に接続されている NIC の MAC アドレス。 -
UUID
: Redfish UUID (通常は1
)。suhy-tools を使用している場合は、この値は長い UUID になります。iDrac を使用している場合は、この値はSystem.Embedded.1
になります。ベンダーに確認することを推奨します。 -
REDFISH_SCHEME
: 使用する Redfish プロバイダー。標準の Redfish 実装を使用するハードウェアを使用している場合、この値をredfish-virtualmedia
に設定できます。iDRAC はidrac-virtualmedia
を使用します。iLO5 はilo5-virtualmedia
を使用します。ベンダーに確認することを推奨します。 REDFISH
: Redfish 接続エンドポイント。export BMC_USERNAME=$(echo -n "root" | base64 -w0) export BMC_PASSWORD=$(echo -n "calvin" | base64 -w0) export BMC_IP="192.168.124.228" export WORKER_NAME="ocp-worker-0" export BOOT_MAC_ADDRESS="aa:bb:cc:dd:ee:ff" export UUID="1" export REDFISH_SCHEME="redfish-virtualmedia" export REDFISH="${REDFISH_SCHEME}://${BMC_IP}/redfish/v1/Systems/${UUID}"
-
次の手順に従って BaremetalHost を作成します。
BMC シークレットを作成します。
oc apply -f - apiVersion: v1 data: password: ${BMC_PASSWORD} username: ${BMC_USERNAME} kind: Secret metadata: name: ${WORKER_NAME}-bmc-secret namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE} type: Opaque
BMH を作成します。
注記:
infraenvs.agent-install.openshift.io
ラベルは、BMH の開始に使用されるInfraEnv
を指定するために使用されます。bmac.agent-install.openshift.io/hostname
ラベルは、ホスト名を手動で設定するために使用されます。インストールディスクを手動で指定する場合は、BMH 仕様の
rootDeviceHints
を使用できます。rootDeviceHints
が提供されていない場合、エージェントは、インストール要件により適したインストールディスクを選択します。rootDeviceHints の詳細は、BareMetalHost ドキュメントの rootDeviceHints セクションを参照してください。oc apply -f - apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: ${WORKER_NAME} namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE} labels: infraenvs.agent-install.openshift.io: ${HOSTED_CLUSTER_NAME} annotations: inspect.metal3.io: disabled bmac.agent-install.openshift.io/hostname: ${WORKER_NAME} spec: automatedCleaningMode: disabled bmc: disableCertificateVerification: True address: ${REDFISH} credentialsName: ${WORKER_NAME}-bmc-secret bootMACAddress: ${BOOT_MAC_ADDRESS} online: true
エージェントは自動的に承認されます。承認されない場合は、
bootMACAddress
が正しいことを確認してください。BMH がプロビジョニングされます。
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get bmh
出力例
NAME STATE CONSUMER ONLINE ERROR AGE ocp-worker-0 provisioning true 2m50s
BMH は最終的に
provisioned
状態に達します。oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get bmh
出力例
NAME STATE CONSUMER ONLINE ERROR AGE ocp-worker-0 provisioned true 72s
プロビジョニング済み とは、ノードが virtualCD から正しく起動するように設定されたことを意味します。エージェントが表示されるまで少し時間がかかります。
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent
出力例
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 true auto-assign
エージェントは自動的に承認されます。
他の 2 つのノードでこのプロセスを繰り返します。
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent
出力例
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 true auto-assign
1.7.4.6. ホステッドクラスターへのアクセス
ホステッドコントロールプレーンが実行されており、エージェントはホステッドクラスターに参加する準備ができています。エージェントがホステッドクラスターに参加する前に、ホステッドクラスターにアクセスする必要があります。
次のコマンドを入力して、kubeconfig を生成します。
hypershift create kubeconfig --namespace ${CLUSTERS_NAMESPACE} --name ${HOSTED_CLUSTER_NAME} > ${HOSTED_CLUSTER_NAME}.kubeconfig
クラスターにアクセスすると、ノードがなく、ClusterVersion が Red Hat OpenShift Container Platform リリースを調整しようとしていることがわかります。
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,nodes
出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version False True 8m6s Unable to apply 4.12z: some cluster operators have not yet rolled out
クラスターを実行するには、クラスターにノードを追加する必要があります。
1.7.4.7. NodePool オブジェクトのスケーリング
NodePool オブジェクトをスケーリングして、ホステッドクラスターにノードを追加します。
NodePool オブジェクトを 2 つのノードにスケーリングします。
oc -n ${CLUSTERS_NAMESPACE} scale nodepool ${NODEPOOL_NAME} --replicas 2
ClusterAPI Agent プロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。状態は、
binding
からdiscovering
、insufficient
、installing
、installing-in-progress
、added-to-existing-cluster
へと推移します。oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent
出力例
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assign oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}' BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
エージェントが
added-to-existing-cluster
状態になったら、OpenShift Container Platform ノードが表示されることを確認します。oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
出力例
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8f
ClusterOperators は、ワークロードをノードに追加することによって調整を開始します。
NodePool
オブジェクトをスケールアップしたときに、2 つのマシンが作成されたことも確認できます。oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get machines
出力例
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hypercluster1-c96b6f675-m5vch hypercluster1-b2qhl ocp-worker-1 agent://da503cf1-a347-44f2-875c-4960ddb04091 Running 15m 4.12z hypercluster1-c96b6f675-tl42p hypercluster1-b2qhl ocp-worker-2 agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6 Running 15m 4.12z
clusterversion
調整は最終的に、Ingress および Console クラスター Operator のみが欠落しているポイントに到達します。oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,co NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version False True 40m Unable to apply 4.12z: the cluster operator console has not yet successfully rolled out NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/console 4.12z False False False 11m RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused clusteroperator.config.openshift.io/csi-snapshot-controller 4.12z True False False 10m clusteroperator.config.openshift.io/dns 4.12z True False False 9m16s clusteroperator.config.openshift.io/image-registry 4.12z True False False 9m5s clusteroperator.config.openshift.io/ingress 4.12z True False True 39m The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing) clusteroperator.config.openshift.io/insights 4.12z True False False 11m clusteroperator.config.openshift.io/kube-apiserver 4.12z True False False 40m clusteroperator.config.openshift.io/kube-controller-manager 4.12z True False False 40m clusteroperator.config.openshift.io/kube-scheduler 4.12z True False False 40m clusteroperator.config.openshift.io/kube-storage-version-migrator 4.12z True False False 10m clusteroperator.config.openshift.io/monitoring 4.12z True False False 7m38s clusteroperator.config.openshift.io/network 4.12z True False False 11m clusteroperator.config.openshift.io/openshift-apiserver 4.12z True False False 40m clusteroperator.config.openshift.io/openshift-controller-manager 4.12z True False False 40m clusteroperator.config.openshift.io/openshift-samples 4.12z True False False 8m54s clusteroperator.config.openshift.io/operator-lifecycle-manager 4.12z True False False 40m clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog 4.12z True False False 40m clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver 4.12z True False False 40m clusteroperator.config.openshift.io/service-ca 4.12z True False False 11m clusteroperator.config.openshift.io/storage 4.12z True False False 11m
1.7.4.8. Ingress の処理
すべての OpenShift Container Platform クラスターには、外部 DNS レコードが関連付けられていると想定されるデフォルトのアプリケーション Ingress コントローラーがセットアップされています。たとえば、ベースドメイン krnl.es
で example
という名前の HyperShift クラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es
がルーティング可能であると予想することができます。
*.apps
のロードバランサーとワイルドカード DNS レコードをセットアップできます。このプロセスでは、MetalLB をデプロイし、Ingress デプロイメントにルーティングする新しいロードバランサーサービスを設定し、ワイルドカード DNS エントリーをロードバランサー IP アドレスに割り当てる必要があります。
LoadBalancer タイプのサービスを作成するときに、MetalLB がサービスの外部 IP アドレスを追加するように、
MetalLB
をセットアップします。cat <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f - --- 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
Operator の実行後、MetalLB インスタンスを作成します。
cat <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f - apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb EOF
単一の IP アドレスで
IPAddressPool
を作成して、MetalLB Operator を設定します。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。重要: 環境のアドレスと一致するように
INGRESS_IP
環境変数を変更します。export INGRESS_IP=192.168.122.23 envsubst <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f - apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: ingress-public-ip namespace: metallb spec: protocol: layer2 autoAssign: false addresses: - ${INGRESS_IP}-${INGRESS_IP} --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: ingress-public-ip namespace: metallb spec: ipAddressPools: - ingress-public-ip EOF
以下の手順に従って、MetalLB を介して OpenShift Container Platform ルーターを公開します。
Ingress トラフィックを Ingress デプロイメントにルーティングする LoadBalancer Service をセットアップします。
cat <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f - 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 EOF
次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。
curl -kI https://console-openshift-console.apps.example.krnl.es HTTP/1.1 200 OK
clusterversion
とclusteroperator
の値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,co
出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.12z True False 3m32s Cluster version is 4.12z NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/console 4.12z True False False 3m50s clusteroperator.config.openshift.io/csi-snapshot-controller 4.12z True False False 25m clusteroperator.config.openshift.io/dns 4.12z True False False 23m clusteroperator.config.openshift.io/image-registry 4.12z True False False 23m clusteroperator.config.openshift.io/ingress 4.12z True False False 53m clusteroperator.config.openshift.io/insights 4.12z True False False 25m clusteroperator.config.openshift.io/kube-apiserver 4.12z True False False 54m clusteroperator.config.openshift.io/kube-controller-manager 4.12z True False False 54m clusteroperator.config.openshift.io/kube-scheduler 4.12z True False False 54m clusteroperator.config.openshift.io/kube-storage-version-migrator 4.12z True False False 25m clusteroperator.config.openshift.io/monitoring 4.12z True False False 21m clusteroperator.config.openshift.io/network 4.12z True False False 25m clusteroperator.config.openshift.io/openshift-apiserver 4.12z True False False 54m clusteroperator.config.openshift.io/openshift-controller-manager 4.12z True False False 54m clusteroperator.config.openshift.io/openshift-samples 4.12z True False False 23m clusteroperator.config.openshift.io/operator-lifecycle-manager 4.12z True False False 54m clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog 4.12z True False False 54m clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver 4.12z True False False 54m clusteroperator.config.openshift.io/service-ca 4.12z True False False 25m clusteroperator.config.openshift.io/storage 4.12z True False False 25m
1.7.4.9. ホステッドクラスターのノード自動スケーリングの有効化
ホステッドクラスターにさらに容量が必要で、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいエージェントをインストールできます。
自動スケーリングを有効にするには、次のコマンドを入力します。この場合、ノードの最小数は 2 で、最大数は 5 です。
oc -n ${CLUSTERS_NAMESPACE} patch nodepool ${HOSTED_CLUSTER_NAME} --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
追加のキャパシティーを必要とせずに 10 分が経過すると、エージェントは廃止され、スペアキューに再び配置されます。
新しいノードを必要とするワークロードを作成します。
cat <<EOF | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f - 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: {} EOF
次のコマンドを入力して、残りのエージェントがデプロイされていることを確認します。この例では、スペアエージェント
d9198891-39f4-4930-a679-65fb142b108b
がプロビジョニングされます。oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
出力例
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: added-to-existing-cluster BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: installing-in-progress BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: added-to-existing-cluster
次のコマンドを入力してノードを確認すると、新しいノードが出力に表示されます。この例では、
ocp-worker-0
がクラスターに追加されています。oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
出力例
NAME STATUS ROLES AGE VERSION ocp-worker-0 Ready worker 35s v1.24.0+3882f8f ocp-worker-1 Ready worker 40m v1.24.0+3882f8f ocp-worker-2 Ready worker 41m v1.24.0+3882f8f
ノードを削除するには、次のコマンドを入力してワークロードを削除します。
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig -n default delete deployment reversewords
10 分間待機し、次のコマンドを入力してノードが削除されたことを確認します。
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
出力例
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 51m v1.24.0+3882f8f ocp-worker-2 Ready worker 52m v1.24.0+3882f8f
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}' BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: added-to-existing-cluster BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: added-to-existing-cluster
1.7.4.10. ホステッドクラスター作成の確認
デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。
次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。
oc extract -n kni21 secret/kni21-admin-kubeconfig --to=- > kubeconfig-kni21 # kubeconfig
kubeconfig を使用して、ホステッドクラスターのクラスター Operator を表示します。以下のコマンドを入力します。
oc get co --kubeconfig=kubeconfig-kni21
出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.10.26 True False False 2m38s csi-snapshot-controller 4.10.26 True False False 4m3s dns 4.10.26 True False False 2m52s image-registry 4.10.26 True False False 2m8s ingress 4.10.26 True False False 22m kube-apiserver 4.10.26 True False False 23m kube-controller-manager 4.10.26 True False False 23m kube-scheduler 4.10.26 True False False 23m kube-storage-version-migrator 4.10.26 True False False 4m52s monitoring 4.10.26 True False False 69s network 4.10.26 True False False 4m3s node-tuning 4.10.26 True False False 2m22s openshift-apiserver 4.10.26 True False False 23m openshift-controller-manager 4.10.26 True False False 23m openshift-samples 4.10.26 True False False 2m15s operator-lifecycle-manager 4.10.26 True False False 22m operator-lifecycle-manager-catalog 4.10.26 True False False 23m operator-lifecycle-manager-packageserver 4.10.26 True False False 23m service-ca 4.10.26 True False False 4m41s storage 4.10.26 True False False 4m43s
次のコマンドを入力して、ホストされたクラスター上で実行中の Pod を表示することもできます。
oc get pods -A --kubeconfig=kubeconfig-kni21
出力例
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system konnectivity-agent-khlqv 0/1 Running 0 3m52s kube-system konnectivity-agent-nrbvw 0/1 Running 0 4m24s kube-system konnectivity-agent-s5p7g 0/1 Running 0 4m14s kube-system kube-apiserver-proxy-asus3-vm1.kni.schmaustech.com 1/1 Running 0 5m56s kube-system kube-apiserver-proxy-asus3-vm2.kni.schmaustech.com 1/1 Running 0 6m37s kube-system kube-apiserver-proxy-asus3-vm3.kni.schmaustech.com 1/1 Running 0 6m17s openshift-cluster-node-tuning-operator cluster-node-tuning-operator-798fcd89dc-9cf2k 1/1 Running 0 20m openshift-cluster-node-tuning-operator tuned-dhw5p 1/1 Running 0 109s openshift-cluster-node-tuning-operator tuned-dlp8f 1/1 Running 0 110s openshift-cluster-node-tuning-operator tuned-l569k 1/1 Running 0 109s openshift-cluster-samples-operator cluster-samples-operator-6b5bcb9dff-kpnbc 2/2 Running 0 20m openshift-cluster-storage-operator cluster-storage-operator-5f784969f5-vwzgz 1/1 Running 1 (113s ago) 20m openshift-cluster-storage-operator csi-snapshot-controller-6b7687b7d9-7nrfw 1/1 Running 0 3m8s openshift-cluster-storage-operator csi-snapshot-controller-6b7687b7d9-csksg 1/1 Running 0 3m9s openshift-cluster-storage-operator csi-snapshot-controller-operator-7f4d9fc5b8-hkvrk 1/1 Running 0 20m openshift-cluster-storage-operator csi-snapshot-webhook-6759b5dc8b-7qltn 1/1 Running 0 3m12s openshift-cluster-storage-operator csi-snapshot-webhook-6759b5dc8b-f8bqk 1/1 Running 0 3m12s openshift-console-operator console-operator-8675b58c4c-flc5p 1/1 Running 1 (96s ago) 20m openshift-console console-5cbf6c7969-6gk6z 1/1 Running 0 119s openshift-console downloads-7bcd756565-6wj5j 1/1 Running 0 4m3s openshift-dns-operator dns-operator-77d755cd8c-xjfbn 2/2 Running 0 21m openshift-dns dns-default-jwjkz 2/2 Running 0 113s openshift-dns dns-default-kfqnh 2/2 Running 0 113s openshift-dns dns-default-xlqsm 2/2 Running 0 113s openshift-dns node-resolver-jzxnd 1/1 Running 0 110s openshift-dns node-resolver-xqdr5 1/1 Running 0 110s openshift-dns node-resolver-zl6h4 1/1 Running 0 110s openshift-image-registry cluster-image-registry-operator-64fcfdbf5-r7d5t 1/1 Running 0 20m openshift-image-registry image-registry-7fdfd99d68-t9pq9 1/1 Running 0 53s openshift-image-registry node-ca-hkfnr 1/1 Running 0 56s openshift-image-registry node-ca-vlsdl 1/1 Running 0 56s openshift-image-registry node-ca-xqnsw 1/1 Running 0 56s openshift-ingress-canary ingress-canary-86z6r 1/1 Running 0 4m13s openshift-ingress-canary ingress-canary-8jhxk 1/1 Running 0 3m52s openshift-ingress-canary ingress-canary-cv45h 1/1 Running 0 4m24s openshift-ingress router-default-6bb8944f66-z2lxr 1/1 Running 0 20m openshift-kube-storage-version-migrator-operator kube-storage-version-migrator-operator-56b57b4844-p9zgp 1/1 Running 1 (2m16s ago) 20m openshift-kube-storage-version-migrator migrator-58bb4d89d5-5sl9w 1/1 Running 0 3m30s openshift-monitoring alertmanager-main-0 6/6 Running 0 100s openshift-monitoring cluster-monitoring-operator-5bc5885cd4-dwbc4 2/2 Running 0 20m openshift-monitoring grafana-78f798868c-wd84p 3/3 Running 0 94s openshift-monitoring kube-state-metrics-58b8f97f6c-6kp4v 3/3 Running 0 104s openshift-monitoring node-exporter-ll7cp 2/2 Running 0 103s openshift-monitoring node-exporter-tgsqg 2/2 Running 0 103s openshift-monitoring node-exporter-z99gr 2/2 Running 0 103s openshift-monitoring openshift-state-metrics-677b9fb74f-qqp6g 3/3 Running 0 104s openshift-monitoring prometheus-adapter-f69fff5f9-7tdn9 0/1 Running 0 17s openshift-monitoring prometheus-k8s-0 6/6 Running 0 93s openshift-monitoring prometheus-operator-6b9d4fd9bd-tqfcx 2/2 Running 0 2m2s openshift-monitoring telemeter-client-74d599658c-wqw5j 3/3 Running 0 101s openshift-monitoring thanos-querier-64c8757854-z4lll 6/6 Running 0 98s openshift-multus multus-additional-cni-plugins-cqst9 1/1 Running 0 6m14s openshift-multus multus-additional-cni-plugins-dbmkj 1/1 Running 0 5m56s openshift-multus multus-additional-cni-plugins-kcwl9 1/1 Running 0 6m14s openshift-multus multus-admission-controller-22cmb 2/2 Running 0 3m52s openshift-multus multus-admission-controller-256tn 2/2 Running 0 4m13s openshift-multus multus-admission-controller-mz9jm 2/2 Running 0 4m24s openshift-multus multus-bxgvr 1/1 Running 0 6m14s openshift-multus multus-dmkdc 1/1 Running 0 6m14s openshift-multus multus-gqw2f 1/1 Running 0 5m56s openshift-multus network-metrics-daemon-6cx4x 2/2 Running 0 5m56s openshift-multus network-metrics-daemon-gz4jp 2/2 Running 0 6m13s openshift-multus network-metrics-daemon-jq9j4 2/2 Running 0 6m13s openshift-network-diagnostics network-check-source-8497dc8f86-cn4nm 1/1 Running 0 5m59s openshift-network-diagnostics network-check-target-d8db9 1/1 Running 0 5m58s openshift-network-diagnostics network-check-target-jdbv8 1/1 Running 0 5m58s openshift-network-diagnostics network-check-target-zzmdv 1/1 Running 0 5m55s openshift-network-operator network-operator-f5b48cd67-x5dcz 1/1 Running 0 21m openshift-sdn sdn-452r2 2/2 Running 0 5m56s openshift-sdn sdn-68g69 2/2 Running 0 6m openshift-sdn sdn-controller-4v5mv 2/2 Running 0 5m56s openshift-sdn sdn-controller-crscc 2/2 Running 0 6m1s openshift-sdn sdn-controller-fxtn9 2/2 Running 0 6m1s openshift-sdn sdn-n5jm5 2/2 Running 0 6m openshift-service-ca-operator service-ca-operator-5bf7f9d958-vnqcg 1/1 Running 1 (2m ago) 20m openshift-service-ca service-ca-6c54d7944b-v5mrw 1/1 Running 0 3m8s
1.7.4.11. ベアメタルでのホステッドクラスターの破棄
コンソールを使用して、ベアメタルホステッドクラスターを破棄できます。ベアメタル上のホステッドクラスターを破壊するには、次の手順を実行します。
- コンソールで、Infrastructure > Clusters に移動します。
- Clusters ページで、破棄するクラスターを選択します。
- Actions メニューで Destroy clusters を選択し、クラスターを削除します。
1.7.4.12. 関連情報
- MetalLB の詳細は、OpenShift Container Platform ドキュメントの MetalLB および MetalLB Operator について を参照してください。
-
rootDeviceHints
の詳細は、BareMetalHost ドキュメントの rootDeviceHints セクションを参照してください。
1.7.5. ホステッドコントロールプレーン機能の無効化
HyperShift Operator をアンインストールして、Hosted control plane を無効にすることができます。ホステッドコントロールプレーンクラスター機能を無効にする場合は、ホステッドコントロールプレーンクラスターの管理 トピックで説明されているとおり、マルチクラスターエンジン Operator でホステッドクラスターとマネージドクラスターリソースを破棄する必要があります。
1.7.5.1. HyperShift Operator のアンインストール
HyperShift Operator をアンインストールし、local-cluster
から hypershift-addon
を無効にするには、以下の手順を実行します。
以下のコマンドを実行して、ホステッドクラスターが実行されていないことを確認します。
oc get hostedcluster -A
重要: ホステッドクラスターが実行されている場合、
hypershift-addon
が無効になっていても、HyperShift Operator はアンインストールされません。以下のコマンドを実行して
hypershift-addon
を無効にします。oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}'
ヒント:
hypershift-addon
を無効にした後、マルチクラスターエンジン Operator コンソールからlocal-cluster
のhypershift-addon
を無効にすることもできます。
1.7.5.2. ホステッドコントロールプレーン機能の無効化
Hosted control plane 機能を無効にする前に、まず HyperShift Operator をアンインストールする必要があります。次のコマンドを実行して、ホステッドコントロールプレーン機能を無効にします。
oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-preview","enabled": false}]}}}'
次のコマンドを実行すると、MultiClusterEngine
カスタムリソースで hypershift-preview
および hypershift-local-hosting
機能が無効になっていることを確認できます。
oc get mce multiclusterengine -o yaml
hypershift-preview
と hypershift-local-hosting
の enabled:
フラグが false
に設定されている次の例を参照してください。
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: overrides: components: - name: hypershift-preview enabled: false - name: hypershift-local-hosting enabled: false