第9章 z/VM を使用した IBM Z および LinuxONE へのインストール

手順

1. 静的 IP アドレスをセットアップします。
2. HTTP または HTTPS サーバーを設定し、Ignition ファイルをクラスターノードに提供します。
3. 必要なロードバランサーをプロビジョニングします。
4. マシンのポートを設定します。
5. DNS を設定します。
6. ネットワーク接続を確認します。

手順

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

   $ ssh-keygen -t ed25519 -N '' \
       -f <path>/<file_name> 1

   1

   ~/.ssh/id_rsa などの、新規 SSH キーのパスおよびファイル名を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。

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

   注記

   FIPS で検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、ed25519 アルゴリズムを使用するキーは作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

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

   $ eval "$(ssh-agent -s)"

   出力例

   Agent pid 31874

   注記

   クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

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. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使ってログインします。アカウントがない場合はこれを作成します。
2. インフラストラクチャープロバイダーを選択します。

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

   重要

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

   重要

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

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

   $ tar xvf openshift-install-linux.tar.gz

5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、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. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

   apiVersion: v1
   baseDomain: my.domain.com
   proxy:
     httpProxy: http://<username>:<pswd>@<ip>:<port> 1
     httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
     noProxy: example.com 3
   additionalTrustBundle: | 4
       -----BEGIN CERTIFICATE-----
       <MY_TRUSTED_CA_CERT>
       -----END CERTIFICATE-----
   ...

   1

   クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。

   2

   クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。

   3

   プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.com は x.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。

   4

   指定されている場合には、インストールプログラムは、openshift-config namespace に user-ca-bundle という名前の設定魔府を生成して、追加の CA 証明書を保存します。additionalTrustBundle と少なくとも 1 つのプロキシー設定を指定した場合には、Proxy オブジェクトは trusted CA フィールドで user-ca-bundle 設定マップを参照するように設定されます。その後、Cluster Network Operator は、trustedCA パラメーターに指定されたコンテンツを RHCOS トラストバンドルにマージする trusted-ca-bundle 設定マップを作成します。additionalTrustBundle フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。

   注記

   インストールプログラムは、プロキシーの readinessEndpoints フィールドをサポートしません。

2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

手順

1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。

   $ ./openshift-install create manifests --dir <installation_directory> 1

   1

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

   警告

   3 ノードクラスターをインストールしている場合は、以下の手順を省略してコントロールプレーンノードをスケジュール対象にします。

   重要

   コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがワーカーノードになるためです。

2. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

   1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
   2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
   3. ファイルを保存し、終了します。

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) カーネル、 initramfs および rootfs ファイルを取得します。

   重要

   RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。この手順で説明されている適切な kernel、initramfs、および rootfs アーティファクトのみを使用します。

   ファイル名には、OpenShift Container Platform のバージョン番号が含まれます。以下の例のようになります。

   • kernel: rhcos-<version>-live-kernel-<architecture>
   • initramfs: rhcos-<version>-live-initramfs.<architecture>.img

   • rootfs: rhcos-<version>-live-rootfs.<architecture>.img

     注記

     rootfs イメージは FCP および DASD の場合と同じです。

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

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

     1. マシンの IP アドレス。
     2. 空の文字列。
     3. ゲートウェイ。
     4. ネットマスク。
     5. hostname.domainname 形式のマシンホストおよびドメイン名。この値を省略して、RHCOS に決定させるようにします。
     6. ネットワークインターフェイス名。この値を省略して、RHCOS に決定させるようにします。
     7. 静的 IP アドレスを使用する場合、 none を指定します。
   • coreos.inst.ignition_url= の場合、マシンロールの Ignition ファイルを指定します。bootstrap.ign、master.ign、または worker.ign を使用します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
   • coreos.live.rootfs_url= の場合、起動しているカーネルおよび initramfs の一致する rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

   • DASD タイプのディスクへのインストールには、以下のタスクを実行します。

     1. coreos.inst.install_dev= には、dasda を指定します。
     2. rd.dasd= を使用して、 RHCOS がインストールされる DASD を指定します。

     3. その他のパラメーターはすべて変更しません。

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

        rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=dasda \
        coreos.live.rootfs_url=http://cl1.provide.example.com:8080/assets/rhcos-live-rootfs.s390x.img \
        coreos.inst.ignition_url=http://cl1.provide.example.com:8080/ignition/bootstrap.ign \
        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 \
        rd.dasd=0.0.3490

        パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。

   • FCP タイプのディスクへのインストールには、以下のタスクを実行します。

     1. rd.zfcp=<adapter>,<wwpn>,<lun> を使用して RHCOS がインストールされる FCP ディスクを指定します。マルチパスの場合、それぞれの追加のステップについてこのステップを繰り返します。
     2. マルチパスの場合は、rd.multipath=default パラメーターを設定します。
     3. マルチパスの場合は、インストールデバイスを coreos.inst.install_dev=/dev/mapper/mpatha として設定します。

     4. 単一パスのインストールの場合は、インストールデバイスを coreos.inst.install_dev=sda として設定します。

        注記

        追加の LUN が NPIV で設定される場合は、FCP に zfcp.allow_lun_scan=0 が必要です。CSI ドライバーを使用するために zfcp.allow_lun_scan=1 を有効にする必要がある場合などには、各ノードが別のノードのブートパーティションにアクセスできないように NPIV を設定する必要があります。

     5. その他のパラメーターはすべて変更しません。

        重要

        マルチパスを完全に有効にするには、インストール後の追加の手順が必要です。詳細は、インストール後のマシン設定タスク の RHCOS でのカーネル引数を使用したマルチパスの有効化を参照してください。

        以下は、マルチパスが設定されたワーカーノードのパラメーターファイルのサンプル worker-1.parm です。

        rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=sda \
        coreos.live.rootfs_url=http://cl1.provide.example.com:8080/assets/rhcos-live-rootfs.s390x.img \
        coreos.inst.ignition_url=http://cl1.provide.example.com:8080/ignition/worker.ign \
        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 \
        rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000

        パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。

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

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

   IBM ドキュメントの PUNCH を参照してください。

   ヒント

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

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

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

   $ ipl c

   IBM ドキュメントの IPL を参照してください。

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

手順

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

   $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ 1
       --log-level=info 2

   1

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

   2

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

   出力例

   INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
   INFO API v1.20.0 up
   INFO Waiting up to 30m0s for bootstrapping to complete...
   INFO It is now safe to remove the bootstrap resources

   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.20.0
   master-1  Ready     master  63m  v1.20.0
   master-2  Ready     master  64m  v1.20.0

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

   注記

   上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

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 が承認されたら、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要です。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

   注記

   ベアメタルおよび他のユーザーによってプロビジョニングされるインフラストラクチャーなどのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc exec、 oc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

   • それらを個別に承認するには、それぞれの有効な 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 --no-run-if-empty oc adm certificate approve

     注記

     一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

   $ oc get csr

   出力例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

   • それらを個別に承認するには、それぞれの有効な 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

6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

   $ oc get nodes

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.20.0
   master-1  Ready     master  73m  v1.20.0
   master-2  Ready     master  74m  v1.20.0
   worker-0  Ready     worker  11m  v1.20.0
   worker-1  Ready     worker  11m  v1.20.0

   注記

   サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

手順

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

   $ watch -n5 oc get clusteroperators

   出力例

   NAME                                       VERSION AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                             4.7.0   True        False         False      3h56m
   baremetal                                  4.7.0   True        False         False      29h
   cloud-credential                           4.7.0   True        False         False      29h
   cluster-autoscaler                         4.7.0   True        False         False      29h
   config-operator                            4.7.0   True        False         False      6h39m
   console                                    4.7.0   True        False         False      3h59m
   csi-snapshot-controller                    4.7.0   True        False         False      4h12m
   dns                                        4.7.0   True        False         False      4h15m
   etcd                                       4.7.0   True        False         False      29h
   image-registry                             4.7.0   True        False         False      3h59m
   ingress                                    4.7.0   True        False         False      4h30m
   insights                                   4.7.0   True        False         False      29h
   kube-apiserver                             4.7.0   True        False         False      29h
   kube-controller-manager                    4.7.0   True        False         False      29h
   kube-scheduler                             4.7.0   True        False         False      29h
   kube-storage-version-migrator              4.7.0   True        False         False      4h2m
   machine-api                                4.7.0   True        False         False      29h
   machine-approver                           4.7.0   True        False         False      6h34m
   machine-config                             4.7.0   True        False         False      3h56m
   marketplace                                4.7.0   True        False         False      4h2m
   monitoring                                 4.7.0   True        False         False      6h31m
   network                                    4.7.0   True        False         False      29h
   node-tuning                                4.7.0   True        False         False      4h30m
   openshift-apiserver                        4.7.0   True        False         False      3h56m
   openshift-controller-manager               4.7.0   True        False         False      4h36m
   openshift-samples                          4.7.0   True        False         False      4h30m
   operator-lifecycle-manager                 4.7.0   True        False         False      29h
   operator-lifecycle-manager-catalog         4.7.0   True        False         False      29h
   operator-lifecycle-manager-packageserver   4.7.0   True        False         False      3h59m
   service-ca                                 4.7.0   True        False         False      29h
   storage                                    4.7.0   True        False         False      4h30m

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

手順

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

   $ watch -n5 oc get clusteroperators

   出力例

   NAME                                       VERSION AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                             4.7.0   True        False         False      3h56m
   baremetal                                  4.7.0   True        False         False      29h
   cloud-credential                           4.7.0   True        False         False      29h
   cluster-autoscaler                         4.7.0   True        False         False      29h
   config-operator                            4.7.0   True        False         False      6h39m
   console                                    4.7.0   True        False         False      3h59m
   csi-snapshot-controller                    4.7.0   True        False         False      4h12m
   dns                                        4.7.0   True        False         False      4h15m
   etcd                                       4.7.0   True        False         False      29h
   image-registry                             4.7.0   True        False         False      3h59m
   ingress                                    4.7.0   True        False         False      4h30m
   insights                                   4.7.0   True        False         False      29h
   kube-apiserver                             4.7.0   True        False         False      29h
   kube-controller-manager                    4.7.0   True        False         False      29h
   kube-scheduler                             4.7.0   True        False         False      29h
   kube-storage-version-migrator              4.7.0   True        False         False      4h2m
   machine-api                                4.7.0   True        False         False      29h
   machine-approver                           4.7.0   True        False         False      6h34m
   machine-config                             4.7.0   True        False         False      3h56m
   marketplace                                4.7.0   True        False         False      4h2m
   monitoring                                 4.7.0   True        False         False      6h31m
   network                                    4.7.0   True        False         False      29h
   node-tuning                                4.7.0   True        False         False      4h30m
   openshift-apiserver                        4.7.0   True        False         False      3h56m
   openshift-controller-manager               4.7.0   True        False         False      4h36m
   openshift-samples                          4.7.0   True        False         False      4h30m
   operator-lifecycle-manager                 4.7.0   True        False         False      29h
   operator-lifecycle-manager-catalog         4.7.0   True        False         False      29h
   operator-lifecycle-manager-packageserver   4.7.0   True        False         False      3h59m
   service-ca                                 4.7.0   True        False         False      29h
   storage                                    4.7.0   True        False         False      4h30m

   あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。

   $ ./openshift-install --dir <installation_directory> wait-for install-complete 1

   1

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

   出力例

   INFO Waiting up to 30m0s for the cluster to initialize...

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

   重要
   • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。
   • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

2. 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 サーバーはクラスターマシンと通信できます。

3. FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。

   詳細は、インストール後の設定 ドキュメントの RHCOS でのカーネル引数を使用したマルチパスの有効化について参照してください。

   1. すべてのワーカーノードが再起動します。プロセスを監視するには、以下のコマンドを入力します。

      $ oc get nodes -w

      注記

      インフラストラクチャーノードなどの追加のマシンタイプがある場合は、これらのタイプについてこのプロセスを繰り返します。

手順

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

   $ oc login -u <username>

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

   $ oc debug node/<nodename>

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

   $ chroot /host
   $ toolbox

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

   $ dbginfo.sh

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