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

手順

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

   $ oc create ns <hosted_cluster_namespace>

   <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

   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) を指定します。

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>
     # ...

     1

     API サーバータイプとして LoadBalancer を指定します。それ以外のすべてのサービスでは、タイプとして Route を指定します。

4. 次のコマンドを入力して、ホステッドクラスター設定ファイルに変更を適用します。

   $ oc apply -f hosted_cluster_config.yaml

5. 次のコマンドを入力して、ホステッドクラスター、ノードプール、および Pod の作成を確認します。

   $ oc get hostedcluster \
     <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 .

   $ oc get pods -n <hosted_cluster_namespace>

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

      $ export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"

   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
      # ...

   3. 以下のコマンドを入力してファイルを適用します。

      $ oc apply -f install-metallb-operator.yaml

   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
      # ...

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

      $ oc apply -f deploy-metallb-ipaddresspool.yaml

   6. 次のコマンドを入力して、Operator ステータス、IP アドレスプール、および L2Advertisement リソースを確認し、MetalLB のインストールを検証します。

      $ oc get pods -n metallb-system

      $ oc get ipaddresspool -n metallb-system

      $ oc get l2advertisement -n metallb-system

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
      # ...

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

      $ oc apply -f ingress-loadbalancer.yaml

   3. 次のコマンドを入力して、ロードバランサーサービスが期待どおりに動作することを確認します。

      $ oc get svc metallb-ingress -n openshift-ingress

      出力例

      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

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>

      出力例

      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

検証

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

   $ oc get clusteroperators

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

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

   $ oc get nodes

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

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

   https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>

手順

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