4.5. IBM Z への Hosted Control Plane のデプロイ

手順

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

   $ oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>

   <hosted_cluster_namespace> を、ホストされたクラスターの namespace 名 (例: clusters) に置き換えます。<hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。

2. クラスターにデフォルトのストレージクラスが設定されていることを確認します。そうしないと、保留中の PVC が表示される場合があります。以下のコマンドを実行します。

   $ 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=<basedomain> \4
       --api-server-address=api.<hosted_cluster_name>.<basedomain> \5
       --etcd-storage-class=<etcd_storage_class> \6
       --ssh-key  <path_to_ssh_public_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> 10

   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

   コントロールプレーンの可用性ポリシーのデフォルト値は、HighlyAvailable です。

   10

   使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.17.0-multi)。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。

3. しばらくしてから、次のコマンドを入力して、Hosted Control Plane の Pod が稼働中であることを確認します。

   $ oc -n <hosted_control_plane_namespace> get pods

   出力例

   NAME                                             READY   STATUS    RESTARTS   AGE
   capi-provider-7dcf5fc4c4-nr9sq                   1/1     Running   0          4m32s
   catalog-operator-6cd867cc7-phb2q                 2/2     Running   0          2m50s
   certified-operators-catalog-884c756c4-zdt64      1/1     Running   0          2m51s
   cluster-api-f75d86f8c-56wfz                      1/1     Running   0          4m32s

手順

1. 設定を含む YAML ファイルを作成します。以下の例を参照してください。

   apiVersion: agent-install.openshift.io/v1beta1
   kind: InfraEnv
   metadata:
     name: <hosted_cluster_name>
     namespace: <hosted_control_plane_namespace>
   spec:
     cpuArchitecture: s390x
     pullSecretRef:
       name: pull-secret
     sshAuthorizedKey: <ssh_public_key>

2. ファイルを infraenv-config.yaml として保存します。

3. 次のコマンドを入力して設定を適用します。

   $ oc apply -f infraenv-config.yaml

4. initrd.img、kernel.img、または rootfs.img などの PXE イメージをダウンロードする URL を取得するには、次のコマンドを入力します。このイメージは、IBM Z マシンがエージェントとして参加できるようにします。

   $ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json

手順

1. 次のコマンドを実行して、NodePool オブジェクトを 2 つのノードにスケーリングします。

   $ oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2

   Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で移行フェーズを通過します。

   • binding
   • discovering
   • insufficient
   • installing
   • installing-in-progress
   • added-to-existing-cluster

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}'

   出力例

   BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
   BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient

3. 次のコマンドを実行して、移行フェーズを表示します。

   $ oc -n <hosted_control_plane_namespace> get agent

   出力例

   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

4. 次のコマンドを実行して、ホステッドクラスターにアクセスするための kubeconfig ファイルを生成します。

   $ hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig

5. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、OpenShift Container Platform ノードが表示されることを確認します。

   $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

   出力例

   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

   Cluster Operator は、ワークロードをノードに追加することによって調整を開始します。

6. 次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。

   $ oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io

   出力例

   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

7. 次のコマンドを実行して、クラスターのバージョンを確認します。

   $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co

   出力例

   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

8. 以下のコマンドを実行して、クラスター Operator のステータスを確認します。

   $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators