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 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
$ oc get managedclusters local-cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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>
$ cat /var/named/<example.krnl.es.zone>
出力例
- 1
- このレコードは、Hosted Control Plane の受信トラフィックと送信トラフィックを処理する API ロードバランサーの IP アドレスを参照します。
IBM Power の場合、エージェントの IP アドレスに対応する IP アドレスを追加します。
設定例
compute-0 IN A 1xx.2x.2xx.1yy compute-1 IN A 1xx.2x.2xx.1yy
compute-0 IN A 1xx.2x.2xx.1yy
compute-1 IN A 1xx.2x.2xx.1yy
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
パラメーターとドメインのアドレスを追加し、使用する証明書を指定します (次の例を参照)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
$ oc label node [compute-node-1] topology.kubernetes.io/zone=zone1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label node [compute-node-2] topology.kubernetes.io/zone=zone2
$ oc label node [compute-node-2] topology.kubernetes.io/zone=zone2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label node [compute-node-3] topology.kubernetes.io/zone=zone3
$ oc label node [compute-node-3] topology.kubernetes.io/zone=zone3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ハードウェアインベントリーにベアメタルノードを追加したことを確認する。
手順
次のコマンドを入力して namespace を作成します。
oc create ns <hosted_cluster_namespace>
$ oc create ns <hosted_cluster_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <hosted_cluster_namespace>
は、ホステッドクラスター namespace の識別子に置き換えます。namespace は HyperShift Operator によって作成されます。ベアメタルインフラストラクチャーにホステッドクラスターを作成するプロセスでは、Cluster API プロバイダー用のロールが生成されます。このロールを生成するには、namespace が事前に存在している必要があります。次のコマンドを入力して、ホステッドクラスターの設定ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 コンポーネントの可用性ポリシーを指定します。サポートされているオプションは
SingleReplica
とHighlyAvailable
です。デフォルト値はHighlyAvailable
です。 - 10
- 使用するサポート対象の OpenShift Container Platform バージョンを指定します (例:
4.19.0-multi
)。非接続環境を使用している場合は、<ocp_release_image>
をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。 - 11
- ノードプールのレプリカ数を指定します (例:
3
)。レプリカ数は0
以上で指定する必要があります。指定したとおりの数のノードが作成されます。この値を指定しない場合、ノードプールは作成されません。 - 12
--ssh-key
フラグの後に、SSH 鍵へのパス (例:user/.ssh/id_rsa
) を指定します。
サービス公開ストラテジーを設定します。デフォルトでは、ホステッドクラスターは
NodePort
サービス公開ストラテジーを使用します。これは、ノードポートが追加のインフラストラクチャーなしで常に利用可能であるためです。ただし、ロードバランサーを使用するようにサービス公開ストラテジーを設定することもできます。-
デフォルトの
NodePort
ストラテジーを使用している場合は、管理クラスターノードではなく、ホステッドクラスターコンピュートノードを指すように DNS を設定します。詳細は、「ベアメタル上の DNS 設定」を参照してください。 実稼働環境では、証明書の処理と自動 DNS 解決を提供する
LoadBalancer
ストラテジーを使用します。次の例は、ホステッドクラスターの設定ファイルでLoadBalancer
サービス公開ストラテジーを変更する方法を示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- API サーバータイプとして
LoadBalancer
を指定します。それ以外のすべてのサービスでは、タイプとしてRoute
を指定します。
-
デフォルトの
次のコマンドを入力して、ホステッドクラスター設定ファイルに変更を適用します。
oc apply -f hosted_cluster_config.yaml
$ oc apply -f hosted_cluster_config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ホステッドクラスター、ノードプール、および Pod の作成を確認します。
oc get hostedcluster \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
$ oc get hostedcluster \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get nodepool \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
$ oc get nodepool \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pods -n <hosted_cluster_namespace>
$ oc get pods -n <hosted_cluster_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ホステッドクラスターの準備ができていることを確認します。
Available: True
というステータスはクラスターの準備完了状態であることを示しています。ノードプールのステータスにはAllMachinesReady: True
と表示されます。これらのステータスは、すべてのクラスター Operator の健全性を示しています。 ホステッドクラスターに MetalLB をインストールします。
次のコマンドを入力して、ホステッドクラスターから
kubeconfig
ファイルを展開し、ホステッドクラスターアクセス用の環境変数を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"
$ export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow install-metallb-operator.yaml
ファイルを作成して MetalLB Operator をインストールします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力してファイルを適用します。
oc apply -f install-metallb-operator.yaml
$ oc apply -f install-metallb-operator.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow deploy-metallb-ipaddresspool.yaml
ファイルを作成して、MetalLB IP アドレスプールを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して設定を適用します。
oc apply -f deploy-metallb-ipaddresspool.yaml
$ oc apply -f deploy-metallb-ipaddresspool.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、Operator ステータス、IP アドレスプール、および
L2Advertisement
リソースを確認し、MetalLB のインストールを検証します。oc get pods -n metallb-system
$ oc get pods -n metallb-system
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get ipaddresspool -n metallb-system
$ oc get ipaddresspool -n metallb-system
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get l2advertisement -n metallb-system
$ oc get l2advertisement -n metallb-system
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Ingress 用のロードバランサーを設定します。
ingress-loadbalancer.yaml
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して設定を適用します。
oc apply -f ingress-loadbalancer.yaml
$ oc apply -f ingress-loadbalancer.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ロードバランサーサービスが期待どおりに動作することを確認します。
oc get svc metallb-ingress -n openshift-ingress
$ oc get svc metallb-ingress -n openshift-ingress
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow
ロードバランサーと連携するように DNS を設定します。
-
*.apps.<hosted_cluster_namespace>.<base_domain>
ワイルドカード DNS レコードがロードバランサーの IP アドレスをポイントするように、apps
ドメインの DNS を設定します。 次のコマンドを入力して DNS 解決を確認します。
nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>
$ nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow
-
検証
次のコマンドを入力して、クラスター Operator を確認します。
oc get clusteroperators
$ oc get clusteroperators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべての Operator に
AVAILABLE: True
、PROGRESSING: False
、DEGRADED: False
が表示されていることを確認します。次のコマンドを入力してノードを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ノードのステータスが
READY
であることを確認します。Web ブラウザーに次の URL を入力して、コンソールへのアクセスをテストします。
https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>
https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.5. エージェントホステッドクラスターでの異種ノードプールの作成について リンクのコピーリンクがクリップボードにコピーされました!
ノードプールは、同じ構成を共有するクラスター内のノードのグループです。異種ノードプールはそれぞれ異なる構成を持ちます。そのため、さまざまなワークロードに合わせてプールを作成し、最適化することが可能です。
異種ノードプールは Agent プラットフォーム上に作成できます。このプラットフォームにより、1 つのホステッドクラスター内で、x86_64
や ppc64le
などのさまざまなマシンタイプをクラスターで実行できるようになります。
異種ノードプールを作成するには、次の一般的な手順を完了する必要があります。
-
データベースやファイルシステムなどのコンポーネントに必要なストレージの量を Operator に通知する
AgentServiceConfig
カスタムリソース (CR) を作成します。この CR では、どの OpenShift Container Platform バージョンをサポートするかも定義します。 - エージェントクラスターを作成します。
- 異種ノードプールを作成します。
- Hosted Control Plane の DNS を設定します。
-
各アーキテクチャー用の
InfraEnv
カスタムリソース (CR) を作成します。 - 異種クラスターにエージェントを追加します。
4.6.5.1. AgentServiceConfig カスタムリソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
エージェントホステッドクラスターに異種ノードプールを作成するには、2 つの異種アーキテクチャーオペレーティングシステム (OS) イメージを使用して AgentServiceConfig
CR を作成する必要があります。
手順
以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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. エージェントクラスターの作成 リンクのコピーリンクがクリップボードにコピーされました!
エージェントベースのアプローチでは、エージェントクラスターを管理およびプロビジョニングします。エージェントクラスターは、異種ノードプールを使用して、同じクラスター内で異なる種類のコンピュートノードを使用することを可能にします。
前提条件
- ホステッドクラスターを作成するときに、異種ノードプールのサポートを有効にするために、マルチアーキテクチャーリリースイメージを使用した。最新のマルチアーキテクチャーイメージについては、マルチアーキテクチャーリリースイメージ ページを参照してください。
手順
次のコマンドを実行して、クラスターの namespace の環境変数を作成します。
export CLUSTERS_NAMESPACE=<hosted_cluster_namespace>
$ export CLUSTERS_NAMESPACE=<hosted_cluster_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マシンの Classless Inter-Domain Routing (CIDR) 表記の環境変数を作成します。
export MACHINE_CIDR=192.168.122.0/24
$ export MACHINE_CIDR=192.168.122.0/24
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Hosted Control Plane の namespace を作成します。
oc create ns <hosted_control_plane_namespace>
$ oc create ns <hosted_control_plane_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してクラスターを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.5.3. 異種ノードプールの作成 リンクのコピーリンクがクリップボードにコピーされました!
NodePool
カスタムリソース (CR) を使用して異種ノードプールを作成し、さまざまなワークロードを特定のハードウェアに関連付けることで、コストとパフォーマンスを最適化できます。
手順
NodePool
CR を定義するには、次の例のような YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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_64
と ppc64le
アーキテクチャーの両方のオペレーティングシステムイメージを AgentServiceConfig
リソースに追加してください。追加したら、InfraEnv
リソースを使用して最小限の ISO イメージを取得できます。
手順
次のコマンドを実行して、異種ノードプール用の
x86_64
アーキテクチャーのInfraEnv
リソースを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、異種ノードプール用の
ppc64le
アーキテクチャーのInfraEnv
リソースを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
InfraEnv
リソースが正常に作成されたことを確認します。x86_64
InfraEnv
リソースが正常に作成されたことを確認します。oc describe InfraEnv <hosted_cluster_name>-<arch_x86>
$ oc describe InfraEnv <hosted_cluster_name>-<arch_x86>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ppc64le
InfraEnv
リソースが正常に作成されたことを確認します。oc describe InfraEnv <hosted_cluster_name>-<arch_ppc64le>
$ oc describe InfraEnv <hosted_cluster_name>-<arch_ppc64le>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、仮想マシンまたはベアメタルマシンのいずれかがエージェントとして参加することを可能にするライブ ISO を生成します。
x86_64
用のライブ ISO を生成します。oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_x86> -ojsonpath="{.status.isoDownloadURL}"
$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_x86> -ojsonpath="{.status.isoDownloadURL}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ppc64le
用のライブ ISO を生成します。oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_ppc64le> -ojsonpath="{.status.isoDownloadURL}"
$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_ppc64le> -ojsonpath="{.status.isoDownloadURL}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.5.6. 異種クラスターへのエージェントの追加 リンクのコピーリンクがクリップボードにコピーされました!
エージェントを追加するには、ライブ ISO を使用して起動するようにマシンを手動で設定します。ライブ ISO をダウンロードし、それを使用してベアメタルノードまたは仮想マシンを起動できます。ノードは起動時に assisted-service
と通信し、InfraEnv
リソースと同じ namespace にエージェントとして登録されます。各エージェントの作成後、必要に応じて、仕様で installation_disk_id
および hostname
パラメーターを設定できます。その後、エージェントを承認して、エージェントを使用する準備が完了していることを示すことができます。
手順
次のコマンドを実行してエージェントのリストを取得します。
oc -n <hosted_control_plane_namespace> get agents
$ oc -n <hosted_control_plane_namespace> get agents
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assign
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、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
$ 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 Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、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
$ 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 Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、エージェントの承認ステータスを確認します。
oc -n <hosted_control_plane_namespace> get agents
$ oc -n <hosted_control_plane_namespace> get agents
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.5.7. ノードプールのスケーリング リンクのコピーリンクがクリップボードにコピーされました!
エージェントを承認したら、ノードプールをスケーリングできます。ノードプールに設定した agentLabelSelector
値により、条件に一致するエージェントだけが確実にクラスターに追加されます。これはノードプールのスケールダウンにも役立ちます。クラスターから特定のアーキテクチャーのノードを削除するには、対応するノードプールをスケールダウンします。
手順
次のコマンドを実行してノードプールをスケーリングします。
oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
$ oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Cluster API エージェントプロバイダーは、2 つのエージェントをランダムに選択してホステッドクラスターに割り当てます。これらのエージェントはさまざまな状態を経て、OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントの状態には、
binding
、discovering
、insufficient
、installing
、installing-in-progress
、added-to-existing-cluster
などがあります。
検証
次のコマンドを実行してエージェントをリスト表示します。
oc -n <hosted_control_plane_namespace> get agent
$ oc -n <hosted_control_plane_namespace> get agent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、スケーリングした特定のエージェントのステータスを確認します。
oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
$ oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
Copy to Clipboard Copied! Toggle word wrap Toggle overflow エージェントが
added-to-existing-cluster
状態に達したら、次のコマンドを実行して、OpenShift Container Platform ノードの準備ができていることを確認します。oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8f
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8f
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードにワークロードが追加されると、一部のクラスター Operator がリコンサイルされることがあります。次のコマンドを実行すると、ノードプールをスケールアップした後に 2 台のマシンが作成されたことが表示されます。
oc -n <hosted_control_plane_namespace> get machines
$ oc -n <hosted_control_plane_namespace> get machines
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow