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 でホステッドクラスターを作成および管理する予定の場合は、次の手順を実行します。

  1. クラスターの 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
  2. HyperShift Operator 用に hypershift-operator-oidc-provider-s3-credentials という名前の OIDC S3 シークレットを作成します。
  3. シークレットを local-cluster namespace に保存します。
  4. シークレットに以下のフィールドが含まれることを確認するには、以下の表を参照してください。

    フィールド名説明

    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) でプロビジョニングする予定の場合は、次の手順を実行します。

  1. HyperShift Operator の AWS 認証情報シークレットを作成し、local-cluster 名前空間で hypershift-operator-external-dns-credentials という名前を付けます。
  2. シークレットに必須フィールドが含まれていることを確認するには、以下の表を参照してください。

    フィールド名説明任意または必須

    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.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 にインストールします。

  1. 以下の例のようなファイルを作成して、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
  2. 以下のコマンドを実行してこのファイルを適用します。

    oc apply -f <filename>

    filename は、作成したファイル名に置き換えます。

  3. 以下のコマンドを実行して、hypershift-addon がインストールされていることを確認します。

    oc get managedclusteraddons -n local-cluster hypershift-addon
  4. アドオンがインストールされている場合、出力は以下の例のようになります。

    NAME               AVAILABLE   DEGRADED   PROGRESSING
    hypershift-addon   True

HyperShift アドオンがインストールされ、HyperShift クラスターを作成および管理するためのホスティングクラスターが利用できます。

1.7.1.7. ホステッドコントロールプレーン CLI のインストール

ホステッドコントロールプレーン (HyperShift) CLI は、OpenShift Container Platform のホステッドコントロールプレーンクラスターを作成および管理するために使用されます。ホステッドコントロールプレーン機能を有効にした後、次の手順を実行してホステッドコントロールプレーン CLI をインストールできます。

  1. OpenShift Container Platform コンソールから、Help icon > Command Line Tools をクリックします。
  2. お使いのプラットフォームの Download hypershift CLI をクリックします。

    注記: ダウンロードは hypershift-preview 機能を有効にしている場合にのみ表示されます。

  3. 次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。

    tar xvzf hypershift.tar.gz
  4. 次のコマンドを実行して、バイナリーファイルを実行可能にします。

    chmod +x hypershift
  5. 次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。

    sudo mv hypershift /usr/local/bin/.

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

hypershift create cluster aws --help

1.7.1.8. 関連情報

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 にデプロイできます。

  1. 環境変数を次のように設定し、必要に応じて変数を認証情報に置き換えます。

    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
  2. CLUSTER_NAMEINFRA_ID の値が同じであることを確認してください。そうしないと、クラスターが Kubernetes Operator コンソールのマルチクラスターエンジンに正しく表示されない可能性があります。各変数の説明を表示するには、次のコマンドを実行します。

    hypershift create cluster aws --help
  3. ハブクラスターにログインしていることを確認します。
  4. 次のコマンドを実行して、ホステッドクラスターを作成します。

    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>

    注記: デフォルトでは、HostedClusterNodePool のすべてのカスタムリソースが clusters namespace に作成されます。--namespace <namespace> パラメーターを指定すると、選択した namespace に HostedCluster および NodePool カスタムリソースが作成されます。

  5. 以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。

    oc get hostedclusters -n <hypershift-hosting-service-cluster>

1.7.2.4. ホストされたコントロールプレーンクラスターの AWS へのインポート

コンソールを使用して、ホストされたコントロールプレーンクラスターをインポートできます。

  1. Infrastructure > Clusters に移動し、インポート予定の、ホストされたクラスターを選択します。
  2. ホストされたクラスターのインポート をクリックします。

    注記: 検出された ホステッドクラスターについては、コンソールからインポートすることもできますが、クラスターはアップグレード可能な状態である必要があります。Hosted control plane を使用できないため、ホステッドクラスターがアップグレード可能な状態ではない場合、クラスターへのインポートは無効になります。Import をクリックして、プロセスを開始します。クラスターが更新を受信している間、ステータスは Importing であり、その後、Ready に変わります。

次の手順を完了し、CLI を使用して AWS でホストされたコントロールプレーンクラスターをインポートすることもできます。

  1. 以下のコマンドを実行して、アノテーションを HostedCluster カスタムリソースに追加します。

    oc edit hostedcluster <cluster_name> -n clusters

    <cluster_name> は、ホステッドクラスターの名前に置き換えます。

  2. 以下のコマンドを実行して、アノテーションを HostedCluster カスタムリソースに追加します。

    cluster.open-cluster-management.io/hypershiftdeployment: local-cluster/<cluster_name>
    cluster.open-cluster-management.io/managedcluster-name: <cluster_name>

    <cluster_name> は、ホステッドクラスターの名前に置き換えます。

  3. 以下のサンプル 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> は、ホステッドクラスターの名前に置き換えます。

  4. 以下のコマンドを実行してリソースを適用します。

    oc apply -f <file_name>

    <file_name> を、直前の手順で作成した YAML ファイル名に置き換えます。

  5. 以下のサンプル 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> は、ホステッドクラスターの名前に置き換えます。

  6. 以下のコマンドを実行してリソースを適用します。

    oc apply -f <file_name>

    <file_name> を、直前の手順で作成した YAML ファイル名に置き換えます。

  7. インポートプロセスが完了すると、ホステッドクラスターがコンソールに表示されます。以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。

    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 でのホステッドクラスターの破棄

ホステッドクラスターとそのマネージドクラスターリソースを破棄するには、次の手順を実行します。

  1. 次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。

    hypershift destroy cluster aws --name <cluster_name> --infra-id <infra_id> --aws-creds <aws-credentials> --base-domain <base_domain> --destroy-cloud-resources

    必要に応じて名前を置き換えます。

  2. 次のコマンドを実行して、マルチクラスターエンジン 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. 関連情報

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 が保留になる可能性があります。

  1. 次のコマンドを入力します。

    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} \
  2. しばらくしてから、次のコマンドを入力して、ホストされたコントロールプレーン 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 を開始しているホストがエージェントとして参加できる環境です。この場合、エージェントはホステッドコントロールプレーンと同じ名前空間に作成されます。

  1. 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
  2. 仮想マシンまたはベアメタルマシンがエージェントとして参加できるようにするライブ ISO を生成するには、次のコマンドを入力します。

    oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get InfraEnv ${HOSTED_CLUSTER_NAME} -ojsonpath="{.status.isoDownloadURL}"

1.7.4.5. エージェントの追加

エージェントを追加するには、手動でマシンを設定してライブ ISO で開始するか、Metal3 を使用します。

  • エージェントを手動で追加するには、次の手順に従います。

    1. ライブ ISO をダウンロードし、それを使用してノード (ベアメタルまたは VM) を起動します。起動時に、ノードは Assisted Service と通信し、InfraEnv と同じ名前空間にエージェントとして登録します。
    2. 各エージェントが作成された後、オプションでその installation_disk_idhostname を仕様に設定することができます。次に、エージェントを使用する準備ができていることを示すためにこれを承認します。

      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

  • Metal3 を使用してエージェントを追加するには、次の手順に従います。

    1. 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 名前空間で再起動されます。

    2. 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
    3. 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}"
    4. 次の手順に従って BaremetalHost を作成します。

      1. 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
      2. 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

        エージェントは自動的に承認されます。

      3. 他の 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. ホステッドクラスターへのアクセス

ホステッドコントロールプレーンが実行されており、エージェントはホステッドクラスターに参加する準備ができています。エージェントがホステッドクラスターに参加する前に、ホステッドクラスターにアクセスする必要があります。

  1. 次のコマンドを入力して、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 オブジェクトをスケーリングして、ホステッドクラスターにノードを追加します。

  1. NodePool オブジェクトを 2 つのノードにスケーリングします。

    oc -n ${CLUSTERS_NAMESPACE} scale nodepool ${NODEPOOL_NAME} --replicas 2

    ClusterAPI Agent プロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。状態は、binding から discoveringinsufficientinstallinginstalling-in-progressadded-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

  2. エージェントが 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.esexample という名前の HyperShift クラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es がルーティング可能であると予想することができます。

*.apps のロードバランサーとワイルドカード DNS レコードをセットアップできます。このプロセスでは、MetalLB をデプロイし、Ingress デプロイメントにルーティングする新しいロードバランサーサービスを設定し、ワイルドカード DNS エントリーをロードバランサー IP アドレスに割り当てる必要があります。

  1. 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
  2. Operator の実行後、MetalLB インスタンスを作成します。

    cat <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f -
    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb
    EOF
  3. 単一の 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
  4. 以下の手順に従って、MetalLB を介して OpenShift Container Platform ルーターを公開します。

    1. 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
    2. 次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。

      curl -kI https://console-openshift-console.apps.example.krnl.es
      
      HTTP/1.1 200 OK
    3. clusterversionclusteroperator の値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。

      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. ホステッドクラスターのノード自動スケーリングの有効化

ホステッドクラスターにさらに容量が必要で、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいエージェントをインストールできます。

  1. 自動スケーリングを有効にするには、次のコマンドを入力します。この場合、ノードの最小数は 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 分が経過すると、エージェントは廃止され、スペアキューに再び配置されます。

  2. 新しいノードを必要とするワークロードを作成します。

    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
  3. 次のコマンドを入力して、残りのエージェントがデプロイされていることを確認します。この例では、スペアエージェント 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

  4. 次のコマンドを入力してノードを確認すると、新しいノードが出力に表示されます。この例では、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

  5. ノードを削除するには、次のコマンドを入力してワークロードを削除します。

    oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig -n default delete deployment reversewords
  6. 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. ホステッドクラスター作成の確認

デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。

  1. 次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。

    oc extract -n kni21 secret/kni21-admin-kubeconfig --to=- > kubeconfig-kni21
    # kubeconfig
  2. 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

  3. 次のコマンドを入力して、ホストされたクラスター上で実行中の 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. ベアメタルでのホステッドクラスターの破棄

コンソールを使用して、ベアメタルホステッドクラスターを破棄できます。ベアメタル上のホステッドクラスターを破壊するには、次の手順を実行します。

  1. コンソールで、Infrastructure > Clusters に移動します。
  2. Clusters ページで、破棄するクラスターを選択します。
  3. Actions メニューで Destroy clusters を選択し、クラスターを削除します。

1.7.4.12. 関連情報

1.7.5. ホステッドコントロールプレーン機能の無効化

HyperShift Operator をアンインストールして、Hosted control plane を無効にすることができます。ホステッドコントロールプレーンクラスター機能を無効にする場合は、ホステッドコントロールプレーンクラスターの管理 トピックで説明されているとおり、マルチクラスターエンジン Operator でホステッドクラスターとマネージドクラスターリソースを破棄する必要があります。

1.7.5.1. HyperShift Operator のアンインストール

HyperShift Operator をアンインストールし、local-cluster から hypershift-addon を無効にするには、以下の手順を実行します。

  1. 以下のコマンドを実行して、ホステッドクラスターが実行されていないことを確認します。

    oc get hostedcluster -A

    重要: ホステッドクラスターが実行されている場合、hypershift-addon が無効になっていても、HyperShift Operator はアンインストールされません。

  2. 以下のコマンドを実行して hypershift-addon を無効にします。

    oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}'

    ヒント: hypershift-addon を無効にした後、マルチクラスターエンジン Operator コンソールから local-clusterhypershift-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-previewhypershift-local-hostingenabled: フラグが 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

1.7.5.3. 関連情報