4.5. IBM Z への Hosted Control Plane のデプロイ
クラスターを管理クラスターとして機能するように設定することで、Hosted Control Plane をデプロイできます。管理クラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。管理クラスターは ホスティング クラスターとも呼ばれます。
管理 クラスターは マネージド クラスターではありません。マネージドクラスターは、ハブクラスターが管理するクラスターです。
hypershift
アドオンを使用してマネージドクラスターに HyperShift Operator をデプロイすることにより、そのマネージドクラスターを管理クラスターに変換できます。その後、ホステッドクラスターの作成を開始できます。
multicluster engine Operator は、マネージドのハブクラスターであるデフォルトの local-cluster
と、管理クラスターとしてのハブクラスターのみをサポートしています。
エージェントプラットフォームを使用して、Hosted Control Plane をベアメタルでプロビジョニングできます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。詳細は、「Central Infrastructure Management サービスの有効化」を参照してください。
各 IBM Z システムホストは、Central Infrastructure Management によって提供される PXE イメージを使用して起動する必要があります。各ホストが起動すると、エージェントプロセスが実行されてホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。
Agent プラットフォームでホステッドクラスターを作成すると、HyperShift Operator は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。
4.5.1. IBM Z で Hosted Control Plane を設定するための前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- multicluster engine for Kubernetes Operator version 2.5 以降を OpenShift Container Platform クラスターにインストールする必要があります。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator としてインストールできます。
multicluster engine Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。multicluster engine Operator バージョン 2.5 以降では、
local-cluster
が自動的にインポートされます。local-cluster
の詳細は、Red Hat Advanced Cluster Management ドキュメントの 詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。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 のコマンドラインインターフェイスのインストール を参照してください。
4.5.2. IBM Z のインフラストラクチャー要件 リンクのコピーリンクがクリップボードにコピーされました!
エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャー用の次のリソースを必要とします。
- Agents: Agent は Discovery イメージまたは PXE イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングする準備ができているホストを表します。
- DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。
Hosted Control Plane 機能はデフォルトで有効になっています。この機能を以前に無効にしていて手動で有効にする場合、またはこの機能を無効にする必要がある場合は、Hosted Control Plane 機能の有効化または無効化 を参照してください。
4.5.3. IBM Z での Hosted Control Plane の DNS 設定 リンクのコピーリンクがクリップボードにコピーされました!
ホステッドクラスターの API サーバーは、NodePort
サービスとして公開されます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<base_domain>
の DNS エントリーが存在する必要があります。
DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。
エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。
次の DNS 設定の例を参照してください。
cat /var/named/<example.krnl.es.zone>
$ cat /var/named/<example.krnl.es.zone>
出力例
- 1
- このレコードは、Hosted Control Plane の受信トラフィックと送信トラフィックを処理する API ロードバランサーの IP アドレスを参照します。
IBM z/VM の場合、エージェントの 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.5.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
パラメーターを定義して証明書を指定すると、コントロールプレーン 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.5.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
$ 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 の識別子に置き換えます。HyperShift Operator は名前空間を作成します。ベアメタルインフラストラクチャー上のホステッドクラスター作成プロセス中に、生成された Cluster API プロバイダーロールには、名前空間がすでに存在している必要があります。次のコマンドを入力して、ホステッドクラスターの設定ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 コンポーネントの可用性ポリシーを指定します。サポートされているオプションは
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
フラグの後に、user/.ssh/id_rsa
などの SSH キーへのパスを指定します。
サービス公開ストラテジーを設定します。デフォルトでは、ホステッドクラスターは 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.5.5. IBM Z 上の Hosted Control Plane 用の InfraEnv リソースを作成する リンクのコピーリンクがクリップボードにコピーされました!
InfraEnv
は、PXE イメージを使用して起動されるホストがエージェントとして参加できる環境です。この場合、エージェントは Hosted Control Plane と同じ namespace に作成されます。
手順
設定を含む YAML ファイルを作成します。以下の例を参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ファイルを
infraenv-config.yaml
として保存します。 次のコマンドを入力して設定を適用します。
oc apply -f infraenv-config.yaml
$ oc apply -f infraenv-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow initrd.img
、kernel.img
、またはrootfs.img
などの PXE イメージをダウンロードする URL を取得するには、次のコマンドを入力します。このイメージは、IBM Z マシンがエージェントとして参加できるようにします。oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json
$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.6. InfraEnv リソースへの IBM Z エージェントの追加 リンクのコピーリンクがクリップボードにコピーされました!
Hosted Control Plane にコンピュートノードをアタッチするには、ノードプールのスケーリングに役立つエージェントを作成します。IBM Z 環境にエージェントを追加するには、追加の手順が必要です。これは、このセクションで詳しく説明します。
特に明記されていない限り、以下の手順は IBM Z および IBM LinuxONE 上の z/VM と RHEL KVM の両方のインストールに適用されます。
4.5.6.1. IBM Z KVM をエージェントとして追加する リンクのコピーリンクがクリップボードにコピーされました!
KVM を使用する IBM Z の場合は、次のコマンドを実行して、InfraEnv
リソースからダウンロードした PXE イメージを使用して IBM Z 環境を開始します。エージェントが作成されると、ホストは Assisted Service と通信し、管理クラスター上の InfraEnv
リソースと同じ namespace に登録します。
手順
以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ISO ブートの場合は、
InfraEnv
リソースから ISO をダウンロードし、次のコマンドを実行してノードを起動します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.6.2. IBM Z LPAR をエージェントとして追加する リンクのコピーリンクがクリップボードにコピーされました!
IBM Z または IBM LinuxONE 上の論理パーティション (LPAR) をコンピュートノードとして Hosted Control Plane に追加できます。
手順
エージェントのブートパラメーターファイルを作成します。
パラメーターファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
coreos.live.rootfs_url
アーティファクトには、起動するkernel
とinitramfs
に合ったrootfs
アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。- 2
ip
パラメーターには、z/VM を使用したクラスターの IBM Z および IBM LinuxONE へのインストール の説明に従って、IP アドレスを手動で割り当てます。- 3
- DASD タイプのディスクにインストールする場合は、
rd.dasd
を使用して、Red Hat Enterprise Linux CoreOS (RHCOS) をインストールする DASD を指定します。FCP タイプのディスクにインストールする場合は、rd.zfcp=<adapter>,<wwpn>,<lun>
を使用して、RHCOS がインストールされる FCP ディスクを指定します。 - 4
- Open Systems Adapter (OSA) または HiperSockets を使用する場合は、このパラメーターを指定します。
InfraEnv
リソースから.ins
ファイルとinitrd.img.addrsize
ファイルをダウンロードします。デフォルトでは、
.ins
ファイルとinitrd.img.addrsize
ファイルの URL は、InfraEnv
リソースにはありません。これらのアーティファクトを取得するには、URL を編集する必要があります。次のコマンドを実行して、カーネル URL エンドポイントを更新し、
ins-file
を含めます。curl -k -L -o generic.ins "< url for ins-file >"
$ curl -k -L -o generic.ins "< url for ins-file >"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow URL の例
https://…/boot-artifacts/ins-file?arch=s390x&version=4.17.0
https://…/boot-artifacts/ins-file?arch=s390x&version=4.17.0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow initrd
URL エンドポイントを更新し、s390x-initrd-addrsize
を含めます。URL の例
https://…./s390x-initrd-addrsize?api_key=<api-key>&arch=s390x&version=4.17.0
https://…./s390x-initrd-addrsize?api_key=<api-key>&arch=s390x&version=4.17.0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
initrd
、kernel
、generic.ins
、およびinitrd.img.addrsize
パラメーターファイルをファイルサーバーに転送します。FTP を使用してファイルを転送し、ブートする方法の詳細は、「LPAR へのインストール」を参照してください。 - マシンを起動します。
- クラスター内の他のマシンすべてに対してこの手順を繰り返します。
4.5.6.3. IBM z/VM をエージェントとして追加する リンクのコピーリンクがクリップボードにコピーされました!
z/VM ゲストに静的 IP を使用する場合は、IP パラメーターが 2 回目の起動でも持続するように、z/VM エージェントの NMStateConfig
属性を設定する必要があります。
InfraEnv
リソースからダウンロードした PXE イメージを使用して IBM Z 環境を開始するには、以下の手順を実行します。エージェントが作成されると、ホストは Assisted Service と通信し、管理クラスター上の InfraEnv
リソースと同じ namespace に登録します。
手順
パラメーターファイルを更新して、
rootfs_url
、network_adaptor
、およびdisk_type
の値を追加します。パラメーターファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
coreos.live.rootfs_url
アーティファクトには、起動するkernel
とinitramfs
に合ったrootfs
アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。- 2
ip
パラメーターには、z/VM を使用したクラスターの IBM Z および IBM LinuxONE へのインストール の説明に従って、IP アドレスを手動で割り当てます。- 3
- DASD タイプのディスクにインストールする場合は、
rd.dasd
を使用して、Red Hat Enterprise Linux CoreOS (RHCOS) をインストールする DASD を指定します。FCP タイプのディスクにインストールする場合は、rd.zfcp=<adapter>,<wwpn>,<lun>
を使用して、RHCOS がインストールされる FCP ディスクを指定します。注記FCP マルチパス設定の場合、1 つのディスクではなく 2 つのディスクを用意します。
例
rd.zfcp=<adapter1>,<wwpn1>,<lun1> \ rd.zfcp=<adapter2>,<wwpn2>,<lun2>
rd.zfcp=<adapter1>,<wwpn1>,<lun1> \ rd.zfcp=<adapter2>,<wwpn2>,<lun2>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 4
- Open Systems Adapter (OSA) または HiperSockets を使用する場合は、このパラメーターを指定します。
次のコマンドを実行して、
initrd
、カーネルイメージ、およびパラメーターファイルをゲスト VM に移動します。vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>
vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename
vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename
Copy to Clipboard Copied! Toggle word wrap Toggle overflow vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>
vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ゲスト VM コンソールから次のコマンドを実行します。
cp ipl c
cp ipl c
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 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a auto-assign
NAME CLUSTER APPROVED ROLE STAGE 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a auto-assign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してエージェントを承認します。
oc -n <hosted_control_plane_namespace> patch agent \ 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d -p \ '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-zvm-0.hostedn.example.com"}}' \ --type merge
$ oc -n <hosted_control_plane_namespace> patch agent \ 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d -p \ '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-zvm-0.hostedn.example.com"}}' \
1 --type merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必要に応じて、仕様でエージェント ID
<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 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d true auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d true auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a true auto-assign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.7. IBM Z 上のホステッドクラスターの NodePool オブジェクトのスケーリング リンクのコピーリンクがクリップボードにコピーされました!
NodePool
オブジェクトは、ホステッドクラスターの作成時に作成されます。NodePool
オブジェクトをスケーリングすることで、Hosted Control Plane にさらに多くのコンピュートノードを追加できます。
ノードプールをスケールアップすると、マシンが作成されます。Cluster API プロバイダーは、承認され、検証に合格し、現在使用されておらず、ノードプールの仕様で指定されている要件を満たすエージェントを見つけます。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
手順
次のコマンドを実行して、
NodePool
オブジェクトを 2 つのノードにスケーリングします。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 -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: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、移行フェーズを表示します。
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 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d hosted-forwarder true auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hosted-forwarder true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d hosted-forwarder true auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hosted-forwarder true auto-assign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ホステッドクラスターにアクセスするための
kubeconfig
ファイルを生成します。hcp create kubeconfig \ --namespace <clusters_namespace> \ --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
$ hcp create kubeconfig \ --namespace <clusters_namespace> \ --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
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 worker-zvm-0.hostedn.example.com Ready worker 5m41s v1.24.0+3882f8f worker-zvm-1.hostedn.example.com Ready worker 6m3s v1.24.0+3882f8f
NAME STATUS ROLES AGE VERSION worker-zvm-0.hostedn.example.com Ready worker 5m41s v1.24.0+3882f8f worker-zvm-1.hostedn.example.com Ready worker 6m3s v1.24.0+3882f8f
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster Operator は、ワークロードをノードに追加することによってリコンシリエーションを開始します。
次のコマンドを入力して、
NodePool
オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
$ oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hosted-forwarder-79558597ff-5tbqp hosted-forwarder-crqq5 worker-zvm-0.hostedn.example.com agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d Running 41h 4.15.0 hosted-forwarder-79558597ff-lfjfk hosted-forwarder-crqq5 worker-zvm-1.hostedn.example.com agent://5e498cd3-542c-e54f-0c58-ed43e28b568a Running 41h 4.15.0
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hosted-forwarder-79558597ff-5tbqp hosted-forwarder-crqq5 worker-zvm-0.hostedn.example.com agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d Running 41h 4.15.0 hosted-forwarder-79558597ff-lfjfk hosted-forwarder-crqq5 worker-zvm-1.hostedn.example.com agent://5e498cd3-542c-e54f-0c58-ed43e28b568a Running 41h 4.15.0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、クラスターのバージョンを確認します。
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.15.0-ec.2 True False 40h Cluster version is 4.15.0-ec.2
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.15.0-ec.2 True False 40h Cluster version is 4.15.0-ec.2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、クラスター Operator のステータスを確認します。
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
クラスターの各コンポーネントの出力には、NAME
、VERSION
、AVAILABLE
、PROGRESSING
、DEGRADED
、SINCE
、および MESSAGE
のクラスター Operator のステータスが表示されます。
出力例は、Operator の初期設定 参照してください。