4.6. IBM Power への Hosted Control Plane のデプロイ


ホスティングクラスターとして機能するようにクラスターを設定することで、Hosted Control Plane をデプロイできます。この設定は、多数のクラスターを管理するための効率的でスケーラブルなソリューションを提供します。ホスティングクラスターは、コントロールプレーンをホストする OpenShift Container Platform クラスターです。ホスティングクラスターは 管理 クラスターとも呼ばれます。

注記

管理 クラスターは マネージド クラスターではありません。マネージドクラスターは、ハブクラスターが管理するクラスターです。

multicluster engine Operator は、管理対象ハブクラスターであるデフォルトの local-cluster と、ホスティングクラスターとしてのハブクラスターのみをサポートします。

ベアメタルインフラストラクチャー上で Hosted Control Plane をプロビジョニングするには、エージェントプラットフォームを使用できます。エージェントプラットフォームは、中央インフラストラクチャー管理サービスを使用して、ホステッドクラスターにコンピュートノードを追加します。詳細は、「Central Infrastructure Management サービスの有効化」を参照してください。

各 IBM Power ホストは、中央インフラストラクチャー管理が提供する Discovery イメージを使用して起動する必要があります。各ホストが起動すると、エージェントプロセスが実行されてホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。

Agent プラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。

4.6.1. IBM Power で Hosted Control Plane を設定するための前提条件

  • OpenShift Container Platform クラスターにインストールされた multicluster engine for Kubernetes Operator 2.7 以降。multicluster engine Operator は、Red Hat Advanced Cluster Management (RHACM) をインストールすると、自動的にインストールされます。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator として RHACM なしでインストールすることもできます。
  • multicluster engine Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。multicluster engine Operator バージョン 2.7 以降では、local-cluster マネージドハブクラスターが自動的にインポートされます。local-cluster の詳細は、RHACM ドキュメントの 詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。

    $ oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • HyperShift Operator を実行するには、少なくとも 3 つのコンピュートノードを持つホスティングクラスターが必要です。
  • Central Infrastructure Management サービスが有効である。詳細は、「Central Infrastructure Management サービスの有効化」を参照してください。
  • Hosted Control Plane コマンドラインインターフェイスをインストールする必要があります。詳細は、「Hosted Control Plane のコマンドラインインターフェイスのインストール」を参照してください。

Hosted Control Plane 機能はデフォルトで有効になっています。この機能を無効にし、手動で有効にしたい場合は、Hosted Control Plane 機能を手動で有効にするを参照してください。機能を無効にする必要がある場合は、「Hosted Control Plane 機能の無効化」を参照してください。

4.6.2. IBM Power のインフラストラクチャー要件

エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャー用の次のリソースを必要とします。

  • エージェント: エージェントは、検出イメージで起動し、OpenShift Container Platform ノードとしてプロビジョニングできるホストを表します。
  • DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

4.6.3. IBM Power での Hosted Control Plane の DNS 設定

ネットワーク外のクライアントは、ホステッドクラスターの API サーバーにアクセスできます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<basedomain> エントリーの DNS エントリーが存在する必要があります。

DNS エントリーは、Hosted Control Plane を実行する管理対象クラスター内のノードの 1 つを指すレコードと同じくらい単純なものになります。

エントリーは、デプロイされたロードバランサーを指定して、着信トラフィックを Ingress Pod にリダイレクトすることもできます。

次の DNS 設定の例を参照してください。

$ cat /var/named/<example.krnl.es.zone>
Copy to Clipboard Toggle word wrap

出力例

$ TTL 900
@ IN  SOA bastion.example.krnl.es.com. hostmaster.example.krnl.es.com. (
      2019062002
      1D 1H 1W 3H )
  IN NS bastion.example.krnl.es.com.
;
;
api                   IN A 1xx.2x.2xx.1xx 
1

api-int               IN A 1xx.2x.2xx.1xx
;
;
*.apps.<hosted_cluster_name>.<basedomain>           IN A 1xx.2x.2xx.1xx
;
;EOF
Copy to Clipboard Toggle word wrap

1
このレコードは、Hosted Control Plane の受信トラフィックと送信トラフィックを処理する API ロードバランサーの IP アドレスを参照します。

IBM Power の場合、エージェントの IP アドレスに対応する IP アドレスを追加します。

設定例

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy
Copy to Clipboard Toggle word wrap

4.6.3.1. カスタム DNS 名の定義

クラスター管理者は、ノードのブートストラップとコントロールプレーンの通信に使用される内部エンドポイントとは異なる外部 API DNS 名を持つホステッドクラスターを作成できます。別の DNS 名を定義する理由には、次のようなものがあります。

  • 内部ルート CA にバインドされているコントロールプレーン機能を壊すことなく、ユーザー向けの TLS 証明書をパブリック CA からの証明書に置き換えます。
  • スプリットホライズン DNS および NAT のシナリオをサポートするため
  • スタンドアロンのコントロールプレーンと同様のエクスペリエンスを確保するよう、正しい kubeconfig と DNS 設定で「Show Login Command」などの機能を使用できるようにするため

HostedCluster オブジェクトの kubeAPIServerDNSName パラメーターにドメイン名を入力することで、初期セットアップ時またはインストール後の操作時に DNS 名を定義できます。

前提条件

  • kubeAPIServerDNSName パラメーターで設定した DNS 名をカバーする有効な TLS 証明書があること。
  • 正しいアドレスに到達してポイントできる解決可能な DNS 名 URI があります。

手順

  • HostedCluster オブジェクトの仕様で、kubeAPIServerDNSName パラメーターとドメインのアドレスを追加し、使用する証明書を指定します (次の例を参照)。

    #...
    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names:
              - xxx.example.com
              - yyy.example.com
              servingCertificate:
                name: <my_serving_certificate>
      kubeAPIServerDNSName: <custom_address> 
    1
    Copy to Clipboard Toggle word wrap
    1
    kubeAPIServerDNSName パラメーターの値は、有効でアドレス指定可能なドメインである必要があります。

kubeAPIServerDNSName パラメーターを定義して証明書を指定すると、コントロールプレーン Operator コントローラーは custom-admin-kubeconfig という名前の kubeconfig ファイルを作成し、そのファイルは HostedControlPlane 名前空間に保存されます。証明書の生成はルート CA から行われ、HostedControlPlane 名前空間によって証明書の有効期限と更新が管理されます。

Control Plane Operator は、HostedControlPlane namespace に CustomKubeconfig という名前の新しい kubeconfig ファイルを報告します。このファイルは、kubeAPIServerDNSName パラメーターで定義された新しいサーバーを使用します。

カスタム kubeconfig ファイルへの参照は、HostedCluster オブジェクトの CustomKubeconfig として ステータス パラメーターに存在します。CustomKubeConfig パラメーターはオプションであり、kubeAPIServerDNSName パラメーターが空でない場合のみパラメーターを追加できます。CustomKubeConfig パラメーターを設定すると、そのパラメーターによって、HostedCluster 名前空間に <hosted_cluster_name>-custom-admin-kubeconfig という名前のシークレットの生成がトリガーされます。このシークレットを使用して HostedCluster API サーバーにアクセスできます。インストール後の操作中に CustomKubeConfig パラメーターを削除すると、関連するすべてのシークレットとステータス参照が削除されます。

注記

カスタム DNS 名を定義してもデータプレーンには直接影響しないため、予期されるロールアウトは発生しません。HostedControlPlane 名前空間は、HyperShift Operator からの変更を受け取り、対応するパラメーターを削除します。

HostedCluster オブジェクトの仕様から kubeAPIServerDNSName パラメーターを削除すると、新しく生成されたすべてのシークレットと CustomKubeconfig 参照がクラスターと ステータス パラメーターから削除されます。

4.6.4. コンソールを使用したホステッドクラスターの作成

ベアメタルインフラストラクチャーでは、ホステッドクラスターを作成またはインポートできます。multicluster engine Operator へのアドオンとして Assisted Installer を有効にし、エージェントプラットフォームでホステッドクラスターを作成すると、HyperShift Operator によってエージェントクラスター API プロバイダーが Hosted Control Plane 名前空間にインストールされます。エージェントクラスター API プロバイダーは、コントロールプレーンをホストする管理クラスターと、コンピュートノードのみで設定されるホステッドクラスターを接続します。

前提条件

  • 各ホステッドクラスターに、クラスター全体で一意の名前が必要。ホステッドクラスター名は、既存の管理対象クラスターと同じにすることはできません。そうしないと、multicluster engine Operator はホステッドクラスターを管理できません。
  • ホステッドクラスター名として clustersという 単語を使用しないでください。
  • multicluster engine Operator が管理するクラスターの名前空間にホステッドクラスターを作成することはできません。
  • 最適なセキュリティーと管理プラクティスを実現するには、他のホストクラスターとは別にホステッドクラスターを作成します。
  • クラスターにデフォルトのストレージクラスが設定されていることを確認する。そうしない場合、保留中の永続ボリューム要求 (PVC) が表示されることがあります。
  • デフォルトでは、hcp create cluster agent コマンドを使用すると、設定されたノードポートを持つホステッドクラスターが作成されます。ベアメタル上のホステッドクラスターの推奨公開ストラテジーは、ロードバランサーを通じてサービスを公開することです。Web コンソールまたは Red Hat Advanced Cluster Management を使用してホステッドクラスターを作成する場合、Kubernetes API サーバー以外のサービスの公開ストラテジーを設定するには、HostedCluster カスタムリソースで servicePublishingStrategy 情報を手動で指定する必要があります。
  • インフラストラクチャー、ファイアウォール、ポート、およびサービスに関連する要件を含む、ベアメタル上の Hosted Control Plane の要件に記載されている要件を満たしていることを確認します。要件では、たとえば次のコマンド例に示すように、管理クラスター内のベアメタルホストに適切なゾーンラベルを追加する方法が説明されています。

    $ oc label node [compute-node-1] topology.kubernetes.io/zone=zone1
    Copy to Clipboard Toggle word wrap
    $ oc label node [compute-node-2] topology.kubernetes.io/zone=zone2
    Copy to Clipboard Toggle word wrap
    $ oc label node [compute-node-3] topology.kubernetes.io/zone=zone3
    Copy to Clipboard Toggle word wrap
  • ハードウェアインベントリーにベアメタルノードを追加したことを確認する。

手順

  1. 次のコマンドを入力して namespace を作成します。

    $ oc create ns <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

    <hosted_cluster_namespace> は、ホステッドクラスター namespace の識別子に置き換えます。HyperShift Operator は名前空間を作成します。ベアメタルインフラストラクチャー上のホステッドクラスター作成プロセス中に、生成された Cluster API プロバイダーロールには、名前空間がすでに存在している必要があります。

  2. 次のコマンドを入力して、ホステッドクラスターの設定ファイルを作成します。

    $ hcp create cluster agent \
      --name=<hosted_cluster_name> \
    1
    
      --pull-secret=<path_to_pull_secret> \
    2
    
      --agent-namespace=<hosted_control_plane_namespace> \
    3
    
      --base-domain=<base_domain> \
    4
    
      --api-server-address=api.<hosted_cluster_name>.<base_domain> \
    5
    
      --etcd-storage-class=<etcd_storage_class> \
    6
    
      --ssh-key=<path_to_ssh_key> \
    7
    
      --namespace=<hosted_cluster_namespace> \
    8
    
      --control-plane-availability-policy=HighlyAvailable \
    9
    
      --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image>-multi \
    10
    
      --node-pool-replicas=<node_pool_replica_count> \
    11
    
      --render \
      --render-sensitive \
      --ssh-key <home_directory>/<path_to_ssh_key>/<ssh_key> > hosted-cluster-config.yaml 
    12
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: example) を指定します。
    2
    /user/name/pullsecret など、プルシークレットへのパスを指定します。
    3
    clusters-example などの Hosted Control Plane 名前空間を指定します。oc get agent -n <hosted_control_plane_namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメイン(例: krnl.es) を指定します。
    5
    --api-server-address フラグは、ホステッドクラスターでの Kubernetes API 通信に使用される IP アドレスを定義します。--api-server-address フラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。
    6
    lvm-storageclass などの etcd ストレージクラス名を指定します。
    7
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    8
    ホステッドクラスターの namespace を指定します。
    9
    Hosted Control Plane コンポーネントの可用性ポリシーを指定します。サポートされているオプションは SingleReplicaHighlyAvailable です。デフォルト値は HighlyAvailable です。
    10
    使用するサポートされている OpenShift Container Platform バージョン (4.19.0-multi など) を指定します。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
    11
    ノードプールのレプリカ数 (例: 3) を指定します。同じ数のレプリカを作成するには、レプリカ数を 0 以上に指定する必要があります。それ以外の場合は、ノードプールは作成されません。
    12
    --ssh-key フラグの後に、user/.ssh/id_rsa などの SSH キーへのパスを指定します。
  3. サービス公開ストラテジーを設定します。デフォルトでは、ホステッドクラスターは NodePort サービス公開ストラテジーを使用します。これは、いつでも追加のインフラストラクチャーなしでノードポートを利用できるためです。ただし、ロードバランサーを使用するようにサービス公開ストラテジーを設定できます。

    • デフォルトの NodePort ストラテジーを使用している場合は、管理クラスターノードではなく、ホステッドクラスターコンピュートノードを指すように DNS を設定します。詳細は、「ベアメタル上の DNS 設定」を参照してください。
    • 実稼働環境では、このストラテジーが証明書の処理と自動 DNS 解決を提供するため、LoadBalancer ストラテジーを使用します。次の例は、ホステッドクラスター設定ファイルでサービス公開 LoadBalancer ストラテジーを変更する方法を示しています。

      # ...
      spec:
        services:
        - service: APIServer
          servicePublishingStrategy:
            type: LoadBalancer 
      1
      
        - service: Ignition
          servicePublishingStrategy:
            type: Route
        - service: Konnectivity
          servicePublishingStrategy:
            type: Route
        - service: OAuthServer
          servicePublishingStrategy:
            type: Route
        - service: OIDC
          servicePublishingStrategy:
            type: Route
        sshKey:
          name: <ssh_key>
      # ...
      Copy to Clipboard Toggle word wrap
      1
      API サーバータイプとして LoadBalancer を指定します。それ以外のすべてのサービスでは、タイプとして Route を指定します。
  4. 次のコマンドを入力して、ホステッドクラスター設定ファイルに変更を適用します。

    $ oc apply -f hosted_cluster_config.yaml
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを入力して、ホステッドクラスター、ノードプール、および Pod の作成を確認します。

    $ oc get hostedcluster \
      <hosted_cluster_namespace> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get nodepool \
      <hosted_cluster_namespace> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get pods -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  6. ホステッドクラスターの準備ができていることを確認します。Available: True のステータスはクラスターの準備状況を示し、ノードプールのステータスは AllMachinesReady: True と表示されます。これらのステータスは、すべてのクラスター Operator の健全性を示します。
  7. ホステッドクラスターに MetalLB をインストールします。

    1. 次のコマンドを入力して、ホステッドクラスターから kubeconfig ファイルを展開し、ホステッドクラスターアクセス用の環境変数を設定します。

      $ oc get secret \
        <hosted_cluster_namespace>-admin-kubeconfig \
        -n <hosted_cluster_namespace> \
        -o jsonpath='{.data.kubeconfig}' \
        | base64 -d > \
        kubeconfig-<hosted_cluster_namespace>.yaml
      Copy to Clipboard Toggle word wrap
      $ export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"
      Copy to Clipboard Toggle word wrap
    2. install-metallb-operator.yaml ファイルを作成して MetalLB Operator をインストールします。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: metallb-system
      ---
      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: metallb-operator
        namespace: metallb-system
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: metallb-operator
        namespace: metallb-system
      spec:
        channel: "stable"
        name: metallb-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        installPlanApproval: Automatic
      # ...
      Copy to Clipboard Toggle word wrap
    3. 以下のコマンドを入力してファイルを適用します。

      $ oc apply -f install-metallb-operator.yaml
      Copy to Clipboard Toggle word wrap
    4. deploy-metallb-ipaddresspool.yaml ファイルを作成して、MetalLB IP アドレスプールを設定します。

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        name: metallb
        namespace: metallb-system
      spec:
        autoAssign: true
        addresses:
        - 10.11.176.71-10.11.176.75
      ---
      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: l2advertisement
        namespace: metallb-system
      spec:
        ipAddressPools:
        - metallb
      # ...
      Copy to Clipboard Toggle word wrap
    5. 次のコマンドを入力して設定を適用します。

      $ oc apply -f deploy-metallb-ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
    6. 次のコマンドを入力して、Operator ステータス、IP アドレスプール、および L2Advertisement リソースをチェックし、MetalLB のインストールを確認します。

      $ oc get pods -n metallb-system
      Copy to Clipboard Toggle word wrap
      $ oc get ipaddresspool -n metallb-system
      Copy to Clipboard Toggle word wrap
      $ oc get l2advertisement -n metallb-system
      Copy to Clipboard Toggle word wrap
  8. Ingress 用のロードバランサーを設定します。

    1. ingress-loadbalancer.yaml ファイルを作成します。

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          metallb.universe.tf/address-pool: metallb
        name: metallb-ingress
        namespace: openshift-ingress
      spec:
        ports:
          - name: http
            protocol: TCP
            port: 80
            targetPort: 80
          - name: https
            protocol: TCP
            port: 443
            targetPort: 443
        selector:
          ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        type: LoadBalancer
      # ...
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを入力して設定を適用します。

      $ oc apply -f ingress-loadbalancer.yaml
      Copy to Clipboard Toggle word wrap
    3. 次のコマンドを入力して、ロードバランサーサービスが期待どおりに動作することを確認します。

      $ oc get svc metallb-ingress -n openshift-ingress
      Copy to Clipboard Toggle word wrap

      出力例

      NAME              TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
      metallb-ingress   LoadBalancer   172.31.127.129   10.11.176.71   80:30961/TCP,443:32090/TCP   16h
      Copy to Clipboard Toggle word wrap

  9. ロードバランサーと連携するように DNS を設定します。

    1. *.apps.<hosted_cluster_namespace>.<base_domain> ワイルドカード DNS レコードがロードバランサーの IP アドレスをポイントするように、apps ドメインの DNS を設定します。
    2. 次のコマンドを入力して DNS 解決を確認します。

      $ nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>
      Copy to Clipboard Toggle word wrap

      出力例

      Server:         10.11.176.1
      Address:        10.11.176.1#53
      
      Name:   console-openshift-console.apps.my-hosted-cluster.sample-base-domain.com
      Address: 10.11.176.71
      Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを入力して、クラスター Operator を確認します。

    $ oc get clusteroperators
    Copy to Clipboard Toggle word wrap

    すべての Operator に AVAILABLE: TruePROGRESSING: FalseDEGRADED: False が表示されていることを確認します。

  2. 次のコマンドを入力してノードを確認します。

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    各ノードが READY ステータスであることを確認します。

  3. Web ブラウザーに次の URL を入力して、コンソールへのアクセスをテストします。

    https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>
    Copy to Clipboard Toggle word wrap

4.6.5. エージェントホステッドクラスターでの異種ノードプールの作成について

ノードプールは、同じ構成を共有するクラスター内のノードのグループです。異種ノードプールは設定が異なるため、プールを作成し、さまざまなワークロードに合わせて最適化できます。

異種ノードプールは、エージェントプラットフォーム上に作成できます。このプラットフォームにより、単一のホステッドクラスター内で、x86_64ppc64le などのさまざまなマシンタイプをクラスターで実行できるようになります。

異種ノードプールを作成するには、次の一般的な手順を完了する必要があります。

  • データベースやファイルシステムなどのコンポーネントに必要なストレージの量を Operator に通知する AgentServiceConfig カスタムリソース (CR) を作成します。CR では、サポートする OpenShift Container Platform のバージョンも定義されます。
  • エージェントクラスターを作成します。
  • 異種ノードプールを作成します。
  • Hosted Control Plane の DNS を設定します。
  • 各アーキテクチャー用の InfraEnv カスタムリソース (CR) を作成します。
  • 異種クラスターにエージェントを追加します。

4.6.5.1. AgentServiceConfig カスタムリソースの作成

エージェントホステッドクラスター上に異種ノードプールを作成するには、2 つの異種アーキテクチャーオペレーティングシステム (OS) イメージを使用して AgentServiceConfig CR を作成する必要があります。

手順

  • 以下のコマンドを実行します。

    $ envsubst <<"EOF" | oc apply -f -
    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
     name: agent
    spec:
      databaseStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <db_volume_name> 
    1
    
      filesystemStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <fs_volume_name> 
    2
    
      osImages:
        - openshiftVersion: <ocp_version> 
    3
    
          version: <ocp_release_version_x86> 
    4
    
          url: <iso_url_x86> 
    5
    
          rootFSUrl: <root_fs_url_x8> 
    6
    
          cpuArchitecture: <arch_x86> 
    7
    
        - openshiftVersion: <ocp_version> 
    8
    
          version: <ocp_release_version_ppc64le> 
    9
    
          url: <iso_url_ppc64le> 
    10
    
          rootFSUrl: <root_fs_url_ppc64le> 
    11
    
          cpuArchitecture: <arch_ppc64le> 
    12
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    multicluster engine for Kubernetes Operator の agentserviceconfig、データベースボリューム名を指定します。
    2
    multicluster engine Operator の agentserviceconfig、ファイルシステムボリューム名を指定します。
    3
    OpenShift Container Platform の現在のバージョンを指定します。
    4
    x86 の現在の OpenShift Container Platform リリースバージョンを指定します。
    5
    x86 の ISO の URL を指定します。
    6
    X86 のルートファイルシステムの URL を指定します。
    7
    x86 の CPU アーキテクチャーを指定します。
    8
    現在の OpenShift Container Platform バージョンを指定します。
    9
    ppc64le の OpenShift Container Platform リリースバージョンを指定します。
    10
    ppc64le の ISO の URL を指定します。
    11
    ppc64le のルートファイルシステムの URL を指定します。
    12
    ppc64le の CPU アーキテクチャーを指定します。

4.6.5.2. エージェントクラスターの作成

エージェントベースのアプローチは、エージェントクラスターを管理およびプロビジョニングします。エージェントクラスターは異種のノードプールを使用できるため、同じクラスター内で異なるタイプのコンピュートノードを使用できます。

前提条件

  • ホステッドクラスターを作成するときに、異種ノードプールのサポートを有効にするために、マルチアーキテクチャーリリースイメージを使用した。最新のマルチアーキテクチャーイメージについては、マルチアーキテクチャーリリースイメージ ページを参照してください。

手順

  1. 次のコマンドを実行して、クラスターの namespace の環境変数を作成します。

    $ export CLUSTERS_NAMESPACE=<hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、マシンの Classless Inter-Domain Routing (CIDR) 表記の環境変数を作成します。

    $ export MACHINE_CIDR=192.168.122.0/24
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、Hosted Control Plane の namespace を作成します。

    $ oc create ns <hosted_control_plane_namespace>
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行してクラスターを作成します。

    $ hcp create cluster agent \
        --name=<hosted_cluster_name> \
    1
    
        --pull-secret=<pull_secret_file> \
    2
    
        --agent-namespace=<hosted_control_plane_namespace> \
    3
    
        --base-domain=<basedomain> \
    4
    
        --api-server-address=api.<hosted_cluster_name>.<basedomain> \
        --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release> 
    5
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスター名を指定します。
    2
    プルシークレットファイルのパスを指定します。
    3
    Hosted Control Plane の namespace を指定します。
    4
    ホステッドクラスターのベースドメインを指定します。
    5
    現在の OpenShift Container Platform リリースバージョンを指定します。

4.6.5.3. 異種ノードプールの作成

NodePool カスタムリソース (CR) を使用して異種ノードプールを作成し、さまざまなワークロードを特定のハードウェアに関連付けることで、コストとパフォーマンスを最適化できます。

手順

  • NodePool CR を定義するには、次の例のような YAML ファイルを作成します。

    envsubst <<"EOF" | oc apply -f -
    apiVersion:apiVersion: hypershift.openshift.io/v1beta1
    kind: NodePool
    metadata:
      name: <hosted_cluster_name>
      namespace: <clusters_namespace>
    spec:
      arch: <arch_ppc64le>
      clusterName: <hosted_cluster_name>
      management:
        autoRepair: false
        upgradeType: InPlace
      nodeDrainTimeout: 0s
      nodeVolumeDetachTimeout: 0s
      platform:
        agent:
          agentLabelSelector:
            matchLabels:
              inventory.agent-install.openshift.io/cpu-architecture: <arch_ppc64le> 
    1
    
        type: Agent
      release:
        image: quay.io/openshift-release-dev/ocp-release:<ocp_release>
      replicas: 0
    EOF
    Copy to Clipboard Toggle word wrap
    1
    セレクターブロックは、指定されたラベルに一致するエージェントを選択します。レプリカ数ゼロで ppc64le アーキテクチャーのノードプールを作成するには、ppc64le を指定します。これにより、スケーリング操作中にセレクターブロックが ppc64le アーキテクチャーからのエージェントのみを選択するようになります。

4.6.5.4. Hosted Control Plane の DNS 設定

Hosted Control Plane のドメインネームサービス (DNS) 設定は、外部クライアントがイングレスコントローラーに到達できることを意味します。これにより、クライアントはトラフィックを内部コンポーネントにルーティングできるようになります。この設定を設定すると、トラフィックが ppc64le または x86_64 コンピュートノードのいずれかにルーティングされるようになります。

*.apps.<cluster_name> レコードを、Ingress アプリケーションをホストするいずれかのコンピュートノードにポイントすることができます。または、コンピュートノードの上にロードバランサーを設定できる場合は、レコードをこのロードバランサーにポイントします。異種ノードプールを作成するときは、コンピュートノードが相互にアクセスできることを確認するか、同じネットワーク内に保持してください。

4.6.5.5. インフラストラクチャー環境リソースの作成

異種ノードプールの場合は、各アーキテクチャー用の infraEnv カスタムリソース (CR) を作成する必要があります。この設定により、ノードのプロビジョニングプロセス中に、正しいアーキテクチャー固有のオペレーティングシステムとブートアーティファクトが使用されるようになります。たとえば、x86_64 および ppc64le アーキテクチャーのノードプールの場合は、x86_64 および ppc64le 用の InfraEnv CR を作成します。

注記

手順を開始する前に、x86_64ppc64le アーキテクチャーの両方のオペレーティングシステムイメージを AgentServiceConfig リソースに追加してください。追加したら、InfraEnv リソースを使用して最小限の ISO イメージを取得できます。

手順

  1. 次のコマンドを実行して、異種ノードプール用の x86_64 アーキテクチャーの InfraEnv リソースを作成します。

    $ envsubst <<"EOF" | oc apply -f -
    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: <hosted_cluster_name>-<arch_x86> 
    1
     
    2
    
      namespace: <hosted_control_plane_namespace> 
    3
    
    spec:
      cpuArchitecture: <arch_x86>
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: <ssh_pub_key> 
    4
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前。
    2
    x86_64 アーキテクチャー。
    3
    Hosted Control Plane の namespace。
    4
    SSH 公開鍵。
  2. 次のコマンドを実行して、異種ノードプール用の ppc64le アーキテクチャーの InfraEnv リソースを作成します。

    envsubst <<"EOF" | oc apply -f -
    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: <hosted_cluster_name>-<arch_ppc64le> 
    1
     
    2
    
      namespace: <hosted_control_plane_namespace> 
    3
    
    spec:
      cpuArchitecture: <arch_ppc64le>
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: <ssh_pub_key> 
    4
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前。
    2
    ppc64le アーキテクチャー。
    3
    Hosted Control Plane の namespace。
    4
    SSH 公開鍵。
  3. 次のコマンドを実行して、InfraEnv リソースが正常に作成されたことを確認します。

    • x86_64 InfraEnv リソースが正常に作成されたことを確認します。

      $ oc describe InfraEnv <hosted_cluster_name>-<arch_x86>
      Copy to Clipboard Toggle word wrap
    • ppc64le InfraEnv リソースが正常に作成されたことを確認します。

      $ oc describe InfraEnv <hosted_cluster_name>-<arch_ppc64le>
      Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、仮想マシンまたはベアメタルマシンのいずれかがエージェントとして参加することを可能にするライブ ISO を生成します。

    1. x86_64 用のライブ ISO を生成します。

      $ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_x86> -ojsonpath="{.status.isoDownloadURL}"
      Copy to Clipboard Toggle word wrap
    2. ppc64le 用のライブ ISO を生成します。

      $ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_ppc64le> -ojsonpath="{.status.isoDownloadURL}"
      Copy to Clipboard Toggle word wrap

4.6.5.6. 異種クラスターへのエージェントの追加

エージェントを追加するには、ライブ ISO を使用して起動するようにマシンを手動で設定します。ライブ ISO をダウンロードし、それを使用してベアメタルノードまたは仮想マシンを起動できます。ノードは起動時に assisted-service と通信し、InfraEnv リソースと同じ namespace にエージェントとして登録されます。各エージェントの作成後、オプションで仕様に installation_disk_id および hostname パラメーターを設定できます。その後、エージェントを承認して、エージェントが使用可能であることを示すことができます。

手順

  1. 次のコマンドを実行してエージェントのリストを取得します。

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
    86f7ac75-4fc4-4b36-8130-40fa12602218                        auto-assign
    e57a637f-745b-496e-971d-1abbf03341ba                        auto-assign
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、1 つのエージェントにパッチを適用します。

    $ 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
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、2 番目のエージェントにパッチを適用します。

    $ oc -n <hosted_control_plane_namespace> patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type merge
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、エージェントの承認ステータスを確認します。

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
    86f7ac75-4fc4-4b36-8130-40fa12602218             true       auto-assign
    e57a637f-745b-496e-971d-1abbf03341ba             true       auto-assign
    Copy to Clipboard Toggle word wrap

4.6.5.7. ノードプールのスケーリング

エージェントを承認したら、ノードプールをスケーリングできます。ノードプールで設定した agentLabelSelector 値により、一致するエージェントのみがクラスターに追加されるようになります。これはノードプールのスケールダウンにも役立ちます。クラスターから特定のアーキテクチャーのノードを削除するには、対応するノードプールをスケールダウンします。

手順

  • 次のコマンドを実行してノードプールをスケーリングします。

    $ oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
    Copy to Clipboard Toggle word wrap
    注記

    Cluster API エージェントプロバイダーは、2 つのエージェントをランダムに選択してホステッドクラスターに割り当てます。これらのエージェントはさまざまな状態を経て、OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントの状態には、bindingdiscoveringinsufficientinstallinginstalling-in-progressadded-to-existing-cluster などがあります。

検証

  1. 次のコマンドを実行してエージェントをリスト表示します。

    $ oc -n <hosted_control_plane_namespace> get agent
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER         APPROVED   ROLE          STAGE
    4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign
    d9198891-39f4-4930-a679-65fb142b108b                   true       auto-assign
    da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、スケーリングした特定のエージェントのステータスを確認します。

    $ oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    出力例

    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
    BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
    BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
    Copy to Clipboard Toggle word wrap

  3. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを実行して、OpenShift Container Platform ノードの準備ができていることを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME           STATUS   ROLES    AGE     VERSION
    ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
    ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

  4. ノードにワークロードが追加されると、一部のクラスター Operator が調整されることがあります。次のコマンドは、ノードプールをスケールアップした後に作成された 2 台のマシンを表示します。

    $ oc -n <hosted_control_plane_namespace> get machines
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
    hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.11.5
    hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.11.5
    Copy to Clipboard Toggle word wrap

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat