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


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

注記

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

multicluster engine Operator がホスティングクラスターとしてサポートしているのは、デフォルトの local-cluster (マネージドハブクラスター) と、ハブクラスターだけです。

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

各 IBM Power ホストは、Central Infrastructure Management が提供する 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 ソフトウェアカタログから 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 のインフラストラクチャー要件

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

  • Agents: Agent は、Discovery イメージで起動し、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 を実行しているマネージドクラスター内のいずれかのノードを指す単純なレコードで構いません。

また、そのエントリーでデプロイ済みのロードバランサーを指定し、受信トラフィックを 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 パラメーターを定義して証明書を指定すると、Control Plane Operator のコントローラーによって custom-admin-kubeconfig という名前の kubeconfig ファイルが作成されます。このファイルは HostedControlPlane namespace に保存されます。証明書はルート CA から生成され、HostedControlPlane namespace によって証明書の有効期限と更新が管理されます。

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

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

注記

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

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

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

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

前提条件

  • 各ホステッドクラスターの名前がクラスター全体で一意である。ホステッドクラスター名は、既存のマネージドクラスターと同じにすることはできません。この要件を満たさないと、multicluster engine Operator がホステッドクラスターを管理できません。
  • ホステッドクラスター名として clusters という単語を使用しない。
  • multicluster engine Operator のマネージドクラスターの namespace にホステッドクラスターを作成することはできない。
  • 最適なセキュリティーと管理プラクティスを実現するために、他のホステッドクラスターとは別にホステッドクラスターを作成する。
  • クラスターにデフォルトのストレージクラスが設定されていることを確認する。そうしない場合、保留中の永続ボリューム要求 (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 の識別子に置き換えます。namespace は HyperShift Operator によって作成されます。ベアメタルインフラストラクチャーにホステッドクラスターを作成するプロセスでは、Cluster API プロバイダー用のロールが生成されます。このロールを生成するには、namespace が事前に存在している必要があります。

  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
    Hosted Control Plane の namespace を指定します (例: clusters-example)。oc get agent -n <hosted_control_plane_namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメイン (例: krnl.es) を指定します。
    5
    --api-server-address フラグは、ホステッドクラスター内の Kubernetes API 通信に使用される IP アドレスを定義します。--api-server-address フラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。
    6
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。
    7
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    8
    ホステッドクラスターの namespace を指定します。
    9
    Hosted Control Plane コンポーネントの可用性ポリシーを指定します。サポートされているオプションは SingleReplicaHighlyAvailable です。デフォルト値は HighlyAvailable です。
    10
    使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.20.0-multi)。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
    11
    ノードプールのレプリカ数を指定します (例: 3)。レプリカ数は 0 以上で指定する必要があります。指定したとおりの数のノードが作成されます。この値を指定しない場合、ノードプールは作成されません。
    12
    --ssh-key フラグの後に、SSH 鍵へのパス (例: user/.ssh/id_rsa) を指定します。
  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. エージェントホステッドクラスターでの異種ノードプールの作成について

ノードプールは、同じ構成を共有するクラスター内のノードのグループです。異種ノードプールはそれぞれ異なる構成を持ちます。そのため、さまざまなワークロードに合わせてプールを作成し、最適化することが可能です。

異種ノードプールは Agent プラットフォーム上に作成できます。このプラットフォームにより、1 つのホステッドクラスター内で、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) 設定の目的は、外部クライアントが Ingress コントローラーにアクセスして、トラフィックを内部コンポーネントにルーティングできるようにすることです。この設定を指定すると、トラフィックが 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