IBM Z および LinuxONE へのインストール

手順

1. 静的 IP アドレスをセットアップします。
2. FTP サーバーをセットアップします。
3. 必要なロードバランサーをプロビジョニングします。
4. マシンのポートを設定します。
5. DNS を設定します。
6. ネットワーク接続を確認します。

手順

1. パスワードなしの認証に設定されている SSH キーがコンピューター上にない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

   $ ssh-keygen -t rsa -b 4096 -N '' \
       -f <path>/<file_name> 1

   1

   ~/.ssh/id_rsa などの、SSH キーのパスおよびファイル名を指定します。既存の SSH キーは上書きされるため、指定しないでください。

   このコマンドを実行すると、指定した場所にパスワードを必要としない SSH キーが生成されます。

2. ssh-agent プロセスをバックグラウンドタスクとして開始します。

   $ eval "$(ssh-agent -s)"
   
   Agent pid 31874

3. SSH プライベートキーを ssh-agent に追加します。

   $ ssh-add <path>/<file_name> 1
   
   Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

   1

   ~/.ssh/id_rsa などの、SSH プライベートキーのパスおよびファイル名を指定します。

手順

1. Red Hat OpenShift Cluster Manager サイトの「Infrastructure Provider」ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使ってログインします。アカウントがない場合はこれを作成します。

2. 選択するインストールタイプのページに移動し、オペレーティングシステムのインストールプログラムをダウンロードし、ファイルをインストール設定ファイルを保存するディレクトリーに配置します。

   重要

   インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターインストールの完了後は、インストールプログラムおよびインストールプログラムが作成するファイルの両方を保持する必要があります。

   重要

   インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。特定のクラウドプロバイダー用に記載された OpenShift Container Platform のアンインストール手順を完了して、クラスターを完全に削除する必要があります。

3. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

   $ tar xvf <installation_program>.tar.gz

4. Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから、インストールプルシークレットを .txt ファイルとしてダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

手順

1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

   $ mkdir <installation_directory>

   重要

   ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

2. 以下の install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

   注記

   この設定ファイル install-config.yaml に名前を付ける必要があります。

3. install-config.yaml ファイルをバックアップし、これを複数のクラスターをインストールするために使用できるようにします。

   重要

   install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

手順

1. クラスターの Kubernetes マニフェストを生成します。

   $ ./openshift-install create manifests --dir=<installation_directory> 1
   
   INFO Consuming Install Config from target directory
   WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings

   1

   <installation_directory> については、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。

   インストールプロセスの後の部分で独自のコンピュートマシンを作成するため、この警告を無視しても問題がありません。

2. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルを変更し、Pod がコントロールプレーンマシンにスケジュールされないようにします。

   1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
   2. mastersSchedulable パラメーターを見つけ、その値を False に設定します。
   3. ファイルを保存し、終了します。
   注記

   現時点では、Kubernetes の制限により、コントロールプレーンマシンで実行されるルーター Pod に Ingress ロードバランサーがアクセスすることができません。この手順は、OpenShift Container Platform の今後のマイナーバージョンで不要になる可能性があります。

3. Ignition 設定ファイルを取得します。

   $ ./openshift-install create ignition-configs --dir=<installation_directory> 1

   1

   <installation_directory> については、同じインストールディレクトリーを指定します。

   以下のファイルはディレクトリーに生成されます。

   .
   ├── auth
   │   ├── kubeadmin-password
   │   └── kubeconfig
   ├── bootstrap.ign
   ├── master.ign
   ├── metadata.json
   └── worker.ign

手順

1. プロビジョニングマシンで Linux にログインします。

2. RHCOS イメージミラーから Red Hat Enterprise Linux CoreOS インストールファイルをダウンロードします。

   重要

   RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。この手順には ISO イメージのみを使用します。RHCOS qcow2 イメージは、ベアメタルのインストールではサポートされません。

   以下のファイルをダウンロードします。

   • initramfs: rhcos-<version>-installer-initramfs.img
   • kernel: rhcos-<version>-installer-kernel

   • RHCOS をインストールするディスクのオペレーティングシステムイメージ。このタイプは仮想マシンによって異なる場合があります。

     rhcos-<version>-s390x-dasd.s390x.raw.gz (DASD 用)

     rhcos-<version>-s390x-metal.s390x.raw.gz (FCP 用)

3. パラメーターファイルを作成します。以下のパラメーターは特定の仮想マシンに固有のものです。

   • coreos.inst.install_dev= の場合、DASD インストールに dasda を指定するか、または FCP に sda を指定します。FCP には zfcp.allow_lun_scan=0 が必要なことに注意してください。
   • rd.dasd= の場合、RHCOS がインストールされる DASD を指定します。
   • rd.zfcp=<adapter>,<wwpn>,<lun> は、RHCOS をインストールする FCP ディスクを指定します。

   • ip=には、以下の 7 つのエントリーを指定します。

     1. マシンの IP アドレス。
     2. 空の文字列。
     3. ゲートウェイ。
     4. ネットマスク。
     5. hostname.domainname 形式のマシンホストおよびドメイン名。RHCOS に決定し、設定させる場合は、この値を省略します。
     6. ネットワークインターフェース名。RHCOS に決定し、設定させる場合は、この値を省略します。
     7. 静的 IP アドレスを使用する場合、空の文字列になります。
   • coreos.inst.ignition_url= の場合、マシンロールの Ignition ファイルを指定します。bootstrap.ign、master.ign、または worker.ign を使用します。

   • その他のパラメーターはそのまま利用できます。

     ブートストラップマシンのパラメーターファイルのサンプル bootstrap-0.parm:

     rd.neednet=1 coreos.inst=yes coreos.inst.install_dev=dasda coreos.inst.image_url=ftp://
     cl1.provide.example.com:8080/assets/rhcos-43.80.20200430.0-s390x-dasd.390x.raw.gz
     coreos.inst.ignition_url=ftp://cl1.provide.example.com:8080/ignition-bootstrap-0
     ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1
     rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 zfcp.allow_lun_scan=0 cio_ignore=all,
     !condev rd.dasd=0.0.3490

4. FTP などを使用し、initramfs、kernel、パラメーターファイル、および RHCOS イメージを z/VM に転送します。FTP でファイルを転送し、仮想リーダーから起動する方法については、「 Z/VM 環境へのインストール」を参照してください。

5. ブートストラップノードになる z/VM ゲスト仮想マシンの仮想リーダーに対してファイルの punch を実行します。

   IBM Knowledge Center で PUNCH を参照してください。

   ヒント

   CP PUNCH コマンドを使用するか、Linux を使用している場合は、 vmur コマンドを使用して 2 つの z/VM ゲスト仮想マシン間でファイルを転送できます。

6. ブートストラップマシンで CMS にログインします。

7. リーダーからブートストラップマシンに対して IPL を実行します。

   $ ipl c

   IBM Knowledge Center で IPL を参照してください。

8. クラスター内の他のマシンについてこの手順を繰り返します。

手順

1. ブートストラッププロセスをモニターします。

   $ ./openshift-install --dir=<installation_directory> wait-for bootstrap-complete \ 1
       --log-level=info 2
   INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com...
   INFO API v1.16.2 up
   INFO Waiting up to 30m0s for bootstrapping to complete...
   INFO It is now safe to remove the bootstrap resources

   1

   <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

   2

   異なるインストールの詳細情報を表示するには、 info ではなく、warn、debug、または error を指定します。

   Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。

2. ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。

   重要

   この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、マシン自体を削除し、再フォーマットすることができます。

手順

1. kubeadmin 認証情報をエクスポートします。

   $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1

   1

   <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

   $ oc whoami
   system:admin

手順

1. クラスターがマシンを認識していることを確認します。

   # oc get nodes
   
   NAME                    STATUS   ROLES    AGE   VERSION
   master-01.example.com   Ready    master   40d   v1.16.2
   master-02.example.com   Ready    master   40d   v1.16.2
   master-03.example.com   Ready    master   40d   v1.16.2
   worker-01.example.com   Ready    worker   40d   v1.16.2
   worker-02.example.com   Ready    worker   40d   v1.16.2

   出力には作成したすべてのマシンが一覧表示されます。

2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

   $ oc get csr
   
   NAME        AGE   REQUESTOR                                   CONDITION
   csr-mddf5   20m   system:node:master-01.example.com   Approved,Issued
   csr-z5rln   16m   system:node:worker-21.example.com   Approved,Issued

3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

   注記

   CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。最初の CSR の承認後、後続のノードクライアント CSR はクラスターの kube-controller-manger によって自動的に承認されます。kubelet 提供証明書の要求を自動的に承認する方法を実装する必要があります。

   • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> は、現行の CSR の一覧からの CSR の名前です。

   • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

手順

1. クラスターコンポーネントがオンラインになることを確認します。

   $ watch -n5 oc get clusteroperators
   NAME                                       VERSION               AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                             4.3.0       True        False         False      40d
   cloud-credential                           4.3.0       True        False         False      40d
   cluster-autoscaler                         4.3.0       True        False         False      40d
   console                                    4.3.0       True        False         False      6d2h
   dns                                        4.3.0       True        False         False      22d
   image-registry                             4.3.0       True        False         False      6d2h
   ingress                                    4.3.0       True        False         False      6d2h
   insights                                   4.3.0       True        False         False      40d
   kube-apiserver                             4.3.0       True        False         False      40d
   kube-controller-manager                    4.3.0       True        False         False      40d
   kube-scheduler                             4.3.0       True        False         False      40d
   machine-api                                4.3.0       True        False         False      40d
   machine-config                             4.3.0       True        False         False      22d
   marketplace                                4.3.0       True        False         False      40d
   monitoring                                 4.3.0       True        False         False      6d16h
   network                                    4.3.0       True        False         False      40d
   node-tuning                                4.3.0       True        False         False      22d
   openshift-apiserver                        4.3.0       True        False         False      22d
   openshift-controller-manager               4.3.0       True        False         False      6d2h
   openshift-samples                          4.3.0       True        False         False      40d
   operator-lifecycle-manager                 4.3.0       True        False         False      40d
   operator-lifecycle-manager-catalog         4.3.0       True        False         False      40d
   operator-lifecycle-manager-packageserver   4.3.0       True        False         False      6d2h
   service-ca                                 4.3.0       True        False         False      40d
   service-catalog-apiserver                  4.3.0       True        False         False      40d
   service-catalog-controller-manager         4.3.0       True        False         False      40d
   storage                                    4.3.0       True        False         False      40d

2. 利用不可の Operator を設定します。

手順

1. すべてのクラスターコンポーネントがオンラインであることを確認します。

   $ watch -n5 oc get clusteroperators
   
   NAME                                 VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                       4.3.0     True        False         False      10m
   cloud-credential                     4.3.0     True        False         False      22m
   cluster-autoscaler                   4.3.0     True        False         False      21m
   console                              4.3.0     True        False         False      10m
   dns                                  4.3.0     True        False         False      21m
   image-registry                       4.3.0     True        False         False      16m
   ingress                              4.3.0     True        False         False      16m
   kube-apiserver                       4.3.0     True        False         False      19m
   kube-controller-manager              4.3.0     True        False         False      18m
   kube-scheduler                       4.3.0     True        False         False      22m
   machine-api                          4.3.0     True        False         False      22m
   machine-config                       4.3.0     True        False         False      18m
   marketplace                          4.3.0     True        False         False      18m
   monitoring                           4.3.0     True        False         False      18m
   network                              4.3.0     True        False         False      16m
   node-tuning                          4.3.0     True        False         False      21m
   openshift-apiserver                  4.3.0     True        False         False      21m
   openshift-controller-manager         4.3.0     True        False         False      17m
   openshift-samples                    4.3.0     True        False         False      14m
   operator-lifecycle-manager           4.3.0     True        False         False      21m
   operator-lifecycle-manager-catalog   4.3.0     True        False         False      21m
   service-ca                           4.3.0     True        False         False      21m
   service-catalog-apiserver            4.3.0     True        False         False      16m
   service-catalog-controller-manager   4.3.0     True        False         False      16m
   storage                              4.3.0     True        False         False      16m

   すべてのクラスター Operator が AVAILABLE の場合、インストールを完了することができます。

2. クラスターの完了をモニターします。

   $ ./openshift-install --dir=<installation_directory> wait-for install-complete 1
   INFO Waiting up to 30m0s for the cluster to initialize...

   1

   <installation_directory> については、インストールファイルを保存したディレクトリーへのパスを指定します。

   Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。

   重要

   インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになる証明書が含まれます。最初の証明書のローテーションが正常に実行されるようにするには、クラスターを動作が低下していない状態で 24 時間実行し続ける必要があります。

3. Kubernetes API サーバーが Pod と通信していることを確認します。

   1. すべての Pod の一覧を表示するには、以下のコマンドを使用します。

      $ oc get pods --all-namespaces
      
      NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
      openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
      openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
      openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
      openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
      openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
      ...

   2. 以下のコマンドを使用して、直前のコマンドの出力に一覧表示される Pod のログを表示します。

      $ oc logs <pod_name> -n <namespace> 1

      1

      直前のコマンドの出力にあるように、Pod 名および namespace を指定します。

      Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。

手順

1. クラスターにログインします。

   $ oc login

2. ハードウェア情報を収集するノードで、デバッグコンテナーを起動します。

   $ oc debug node/<nodename>

3. /host ファイルシステムに切り替え、toolbox を起動します。

   $ chroot /host
   $ toolbox

4. dbginfo データを収集します。

   $ dbginfo.sh

5. その後に、scp を使用するなどしてデータを取得できます。

手順

1. 各ノードに DHCP を設定するか、または静的 IP アドレスを設定します。
2. 必要なロードバランサーをプロビジョニングします。
3. マシンのポートを設定します。
4. DNS を設定します。
5. ネットワーク接続を確認します。

手順

1. パスワードなしの認証に設定されている SSH キーがコンピューター上にない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

   $ ssh-keygen -t rsa -b 4096 -N '' \
       -f <path>/<file_name> 1

   1

   ~/.ssh/id_rsa などの、SSH キーのパスおよびファイル名を指定します。既存の SSH キーは上書きされるため、指定しないでください。

   このコマンドを実行すると、指定した場所にパスワードを必要としない SSH キーが生成されます。

2. ssh-agent プロセスをバックグラウンドタスクとして開始します。

   $ eval "$(ssh-agent -s)"
   
   Agent pid 31874

3. SSH プライベートキーを ssh-agent に追加します。

   $ ssh-add <path>/<file_name> 1
   
   Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

   1

   ~/.ssh/id_rsa などの、SSH プライベートキーのパスおよびファイル名を指定します。

手順

1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

   $ mkdir <installation_directory>

   重要

   ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

2. 以下の install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

   注記

   この設定ファイル install-config.yaml に名前を付ける必要があります。

3. install-config.yaml ファイルをバックアップし、これを複数のクラスターをインストールするために使用できるようにします。

   重要

   install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

手順

1. クラスターの Kubernetes マニフェストを生成します。

   $ ./openshift-install create manifests --dir=<installation_directory> 1
   
   INFO Consuming Install Config from target directory
   WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings

   1

   <installation_directory> については、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。

   インストールプロセスの後の部分で独自のコンピュートマシンを作成するため、この警告を無視しても問題がありません。

2. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルを変更し、Pod がコントロールプレーンマシンにスケジュールされないようにします。

   1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
   2. mastersSchedulable パラメーターを見つけ、その値を False に設定します。
   3. ファイルを保存し、終了します。
   注記

   現時点では、Kubernetes の制限により、コントロールプレーンマシンで実行されるルーター Pod に Ingress ロードバランサーがアクセスすることができません。この手順は、OpenShift Container Platform の今後のマイナーバージョンで不要になる可能性があります。

3. Ignition 設定ファイルを取得します。

   $ ./openshift-install create ignition-configs --dir=<installation_directory> 1

   1

   <installation_directory> については、同じインストールディレクトリーを指定します。

   以下のファイルはディレクトリーに生成されます。

   .
   ├── auth
   │   ├── kubeadmin-password
   │   └── kubeconfig
   ├── bootstrap.ign
   ├── master.ign
   ├── metadata.json
   └── worker.ign

手順

1. プロビジョニングマシンで Linux にログインします。

2. RHCOS イメージミラーから Red Hat Enterprise Linux CoreOS インストールファイルをダウンロードします。

   重要

   RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。この手順には ISO イメージのみを使用します。RHCOS qcow2 イメージは、ベアメタルのインストールではサポートされません。

   以下のファイルをダウンロードします。

   • initramfs: rhcos-<version>-installer-initramfs.img
   • kernel: rhcos-<version>-installer-kernel

   • RHCOS をインストールするディスクのオペレーティングシステムイメージ。このタイプは仮想マシンによって異なる場合があります。

     rhcos-<version>-s390x-dasd.s390x.raw.gz (DASD 用)

     rhcos-<version>-s390x-metal.s390x.raw.gz (FCP 用)

3. パラメーターファイルを作成します。以下のパラメーターは特定の仮想マシンに固有のものです。

   • coreos.inst.install_dev= の場合、DASD インストールに dasda を指定するか、または FCP に sda を指定します。FCP には zfcp.allow_lun_scan=0 が必要なことに注意してください。
   • rd.dasd= の場合、RHCOS がインストールされる DASD を指定します。
   • rd.zfcp=<adapter>,<wwpn>,<lun> は、RHCOS をインストールする FCP ディスクを指定します。

   • ip=には、以下の 7 つのエントリーを指定します。

     1. マシンの IP アドレス。
     2. 空の文字列。
     3. ゲートウェイ。
     4. ネットマスク。
     5. hostname.domainname 形式のマシンホストおよびドメイン名。RHCOS に決定し、設定させる場合は、この値を省略します。
     6. ネットワークインターフェース名。RHCOS に決定し、設定させる場合は、この値を省略します。
     7. 静的 IP アドレスを使用する場合、空の文字列になります。
   • coreos.inst.ignition_url= の場合、マシンロールの Ignition ファイルを指定します。bootstrap.ign、master.ign、または worker.ign を使用します。

   • その他のパラメーターはそのまま利用できます。

     ブートストラップマシンのパラメーターファイルのサンプル bootstrap-0.parm:

     rd.neednet=1 coreos.inst=yes coreos.inst.install_dev=dasda coreos.inst.image_url=ftp://
     cl1.provide.example.com:8080/assets/rhcos-43.80.20200430.0-s390x-dasd.390x.raw.gz
     coreos.inst.ignition_url=ftp://cl1.provide.example.com:8080/ignition-bootstrap-0
     ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1
     rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 zfcp.allow_lun_scan=0 cio_ignore=all,
     !condev rd.dasd=0.0.3490

4. FTP などを使用し、initramfs、kernel、パラメーターファイル、および RHCOS イメージを z/VM に転送します。FTP でファイルを転送し、仮想リーダーから起動する方法については、「 Z/VM 環境へのインストール」を参照してください。

5. ブートストラップノードになる z/VM ゲスト仮想マシンの仮想リーダーに対してファイルの punch を実行します。

   IBM Knowledge Center で PUNCH を参照してください。

   ヒント

   CP PUNCH コマンドを使用するか、Linux を使用している場合は、 vmur コマンドを使用して 2 つの z/VM ゲスト仮想マシン間でファイルを転送できます。

6. ブートストラップマシンで CMS にログインします。

7. リーダーからブートストラップマシンに対して IPL を実行します。

   $ ipl c

   IBM Knowledge Center で IPL を参照してください。

8. クラスター内の他のマシンについてこの手順を繰り返します。

手順

1. ブートストラッププロセスをモニターします。

   $ ./openshift-install --dir=<installation_directory> wait-for bootstrap-complete \ 1
       --log-level=info 2
   INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com...
   INFO API v1.16.2 up
   INFO Waiting up to 30m0s for bootstrapping to complete...
   INFO It is now safe to remove the bootstrap resources

   1

   <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

   2

   異なるインストールの詳細情報を表示するには、 info ではなく、warn、debug、または error を指定します。

   Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。

2. ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。

   重要

   この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、マシン自体を削除し、再フォーマットすることができます。

手順

1. kubeadmin 認証情報をエクスポートします。

   $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1

   1

   <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

   $ oc whoami
   system:admin

手順

1. クラスターがマシンを認識していることを確認します。

   $ oc get nodes
   
   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.16.2
   master-1  Ready     master  63m  v1.16.2
   master-2  Ready     master  64m  v1.16.2
   worker-0  NotReady  worker  76s  v1.16.2
   worker-1  NotReady  worker  70s  v1.16.2

   出力には作成したすべてのマシンが一覧表示されます。

2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

   $ oc get csr
   
   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

   1

   クライアント要求の CSR。

   2

   サーバー要求の CSR。

   この例では、2 つのマシンがクラスターに参加しています。この一覧にはさらに多くの承認された CSR が表示される可能性があります。

3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

   注記

   CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。最初の CSR の承認後、後続のノードクライアント CSR はクラスターの kube-controller-manger によって自動的に承認されます。kubelet 提供証明書の要求を自動的に承認する方法を実装する必要があります。

   • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> は、現行の CSR の一覧からの CSR の名前です。

   • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

手順

1. クラスターコンポーネントがオンラインになることを確認します。

   $ watch -n5 oc get clusteroperators
   NAME                                       VERSION               AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                             4.3.0       True        False         False      40d
   cloud-credential                           4.3.0       True        False         False      40d
   cluster-autoscaler                         4.3.0       True        False         False      40d
   console                                    4.3.0       True        False         False      6d2h
   dns                                        4.3.0       True        False         False      22d
   image-registry                             4.3.0       True        False         False      6d2h
   ingress                                    4.3.0       True        False         False      6d2h
   insights                                   4.3.0       True        False         False      40d
   kube-apiserver                             4.3.0       True        False         False      40d
   kube-controller-manager                    4.3.0       True        False         False      40d
   kube-scheduler                             4.3.0       True        False         False      40d
   machine-api                                4.3.0       True        False         False      40d
   machine-config                             4.3.0       True        False         False      22d
   marketplace                                4.3.0       True        False         False      40d
   monitoring                                 4.3.0       True        False         False      6d16h
   network                                    4.3.0       True        False         False      40d
   node-tuning                                4.3.0       True        False         False      22d
   openshift-apiserver                        4.3.0       True        False         False      22d
   openshift-controller-manager               4.3.0       True        False         False      6d2h
   openshift-samples                          4.3.0       True        False         False      40d
   operator-lifecycle-manager                 4.3.0       True        False         False      40d
   operator-lifecycle-manager-catalog         4.3.0       True        False         False      40d
   operator-lifecycle-manager-packageserver   4.3.0       True        False         False      6d2h
   service-ca                                 4.3.0       True        False         False      40d
   service-catalog-apiserver                  4.3.0       True        False         False      40d
   service-catalog-controller-manager         4.3.0       True        False         False      40d
   storage                                    4.3.0       True        False         False      40d

2. 利用不可の Operator を設定します。

手順

1. すべてのクラスターコンポーネントがオンラインであることを確認します。

   $ watch -n5 oc get clusteroperators
   
   NAME                                 VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                       4.3.0     True        False         False      10m
   cloud-credential                     4.3.0     True        False         False      22m
   cluster-autoscaler                   4.3.0     True        False         False      21m
   console                              4.3.0     True        False         False      10m
   dns                                  4.3.0     True        False         False      21m
   image-registry                       4.3.0     True        False         False      16m
   ingress                              4.3.0     True        False         False      16m
   kube-apiserver                       4.3.0     True        False         False      19m
   kube-controller-manager              4.3.0     True        False         False      18m
   kube-scheduler                       4.3.0     True        False         False      22m
   machine-api                          4.3.0     True        False         False      22m
   machine-config                       4.3.0     True        False         False      18m
   marketplace                          4.3.0     True        False         False      18m
   monitoring                           4.3.0     True        False         False      18m
   network                              4.3.0     True        False         False      16m
   node-tuning                          4.3.0     True        False         False      21m
   openshift-apiserver                  4.3.0     True        False         False      21m
   openshift-controller-manager         4.3.0     True        False         False      17m
   openshift-samples                    4.3.0     True        False         False      14m
   operator-lifecycle-manager           4.3.0     True        False         False      21m
   operator-lifecycle-manager-catalog   4.3.0     True        False         False      21m
   service-ca                           4.3.0     True        False         False      21m
   service-catalog-apiserver            4.3.0     True        False         False      16m
   service-catalog-controller-manager   4.3.0     True        False         False      16m
   storage                              4.3.0     True        False         False      16m

   すべてのクラスター Operator が AVAILABLE の場合、インストールを完了することができます。

2. クラスターの完了をモニターします。

   $ ./openshift-install --dir=<installation_directory> wait-for install-complete 1
   INFO Waiting up to 30m0s for the cluster to initialize...

   1

   <installation_directory> については、インストールファイルを保存したディレクトリーへのパスを指定します。

   Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。

   重要

   インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになる証明書が含まれます。最初の証明書のローテーションが正常に実行されるようにするには、クラスターを動作が低下していない状態で 24 時間実行し続ける必要があります。

3. Kubernetes API サーバーが Pod と通信していることを確認します。

   1. すべての Pod の一覧を表示するには、以下のコマンドを使用します。

      $ oc get pods --all-namespaces
      
      NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
      openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
      openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
      openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
      openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
      openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
      ...

   2. 以下のコマンドを使用して、直前のコマンドの出力に一覧表示される Pod のログを表示します。

      $ oc logs <pod_name> -n <namespace> 1

      1

      直前のコマンドの出力にあるように、Pod 名および namespace を指定します。

      Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。

4. 「Cluster registration」ページでクラスターを登録します。

手順

1. クラスターにログインします。

   $ oc login

2. ハードウェア情報を収集するノードで、デバッグコンテナーを起動します。

   $ oc debug node/<nodename>

3. /host ファイルシステムに切り替え、toolbox を起動します。

   $ chroot /host
   $ toolbox

4. dbginfo データを収集します。

   $ dbginfo.sh

5. その後に、scp を使用するなどしてデータを取得できます。