2.4. 非接続環境で IBM Z および IBM LinuxONE に z/VM を使用したクラスターをインストールする

手順

1. 静的 IP アドレスをセットアップします。
2. HTTP または HTTPS サーバーを設定し、Ignition ファイルをクラスターノードに提供します。
3. ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。

4. OpenShift Container Platform クラスターコンポーネントで通信するために必要なポートを有効にするようにファイアウォールを設定します。必要なポートの詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。

   重要

   デフォルトで、ポート 1936 は OpenShift Container Platform クラスターにアクセスできます。これは、各コントロールプレーンノードがこのポートへのアクセスを必要とするためです。

   Ingress ロードバランサーを使用してこのポートを公開しないでください。これを実行すると、Ingress コントローラーに関連する統計やメトリクスなどの機密情報が公開される可能性があるためです。

5. クラスターに必要な DNS インフラストラクチャーを設定します。

   1. Kubernetes API、アプリケーションワイルドカード、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの DNS 名前解決を設定します。

   2. Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの逆引き DNS 解決を設定します。

      OpenShift Container Platform DNS 要件の詳細は、user-provisioned DNS 要件 のセクションを参照してください。

6. DNS 設定を検証します。

   1. インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答の IP アドレスが正しいコンポーネントに対応することを確認します。

   2. インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答のレコード名が正しいコンポーネントに対応することを確認します。

      DNS 検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。

7. 必要な API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングします。要件に関する詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。

手順

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

   $ mkdir <installation_directory>

   Copy to Clipboard Toggle word wrap
   重要

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

2. 提供されているサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、ファイルを <installation_directory> に保存します。

   注記

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

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

   重要

   インストールプロセスの次のステップで install-config.yaml ファイルを使用するため、今すぐこのファイルをバックアップしてください。

手順

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

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

   1

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   1

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

   Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。kubeadmin-password および kubeconfig ファイルが ./<installation_directory>/auth ディレクトリーに作成されます。

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

   Copy to Clipboard Toggle word wrap

手順

1. コントロールプレーンとコンピュートノードの Butane 設定ファイルを作成します。

   次のコントロールプレーンノードの Butane 設定の例では、ディスク暗号化用に master-storage.bu という名前のファイルを作成します。

   variant: openshift
   version: 4.18.0
   metadata:
     name: master-storage
     labels:
       machineconfiguration.openshift.io/role: master
   storage:
     luks:
       - clevis:
           tang:
             - thumbprint: QcPr_NHFJammnRCA3fFMVdNBwjs
               url: http://clevis.example.com:7500
           options: 

   1

   
              - --cipher
              - aes-cbc-essiv:sha256
         device: /dev/disk/by-partlabel/root 

   2

   
         label: luks-root
         name: root
         wipe_volume: true
     filesystems:
       - device: /dev/mapper/root
         format: xfs
         label: root
         wipe_filesystem: true
   openshift:
     fips: true 

   3

   Copy to Clipboard Toggle word wrap

   1

   暗号オプションは、FIPS モードが有効な場合にのみ必要です。FIPS が無効になっている場合は、エントリーを省略します。

   2

   DASD タイプのディスクにインストールする場合は、device:/dev/disk/by-label/root に置き換えます。

   3

   FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。

2. 次のコマンドを実行して、マシンを起動するためのカスタマイズされた initramfs ファイルを作成します。

   $ coreos-installer pxe customize \
       /root/rhcos-bootfiles/rhcos-<release>-live-initramfs.s390x.img \
       --dest-device /dev/disk/by-id/scsi-<serial_number> --dest-karg-append \
       ip=<ip_address>::<gateway_ip>:<subnet_mask>::<network_device>:none \
       --dest-karg-append nameserver=<nameserver_ip> \
       --dest-karg-append rd.neednet=1 -o \
       /root/rhcos-bootfiles/<node_name>-initramfs.s390x.img

   Copy to Clipboard Toggle word wrap
   注記

   最初のブートの前に、クラスター内の各ノードの initramfs をカスタマイズし、PXE カーネルパラメーターを追加する必要があります。

3. ignition.platform.id=metal および ignition.firstboot を含むパラメーターファイルを作成します。

   コントロールプレーンマシンのカーネルパラメーターファイルの例

   cio_ignore=all,!condev rd.neednet=1 \
   console=ttysclp0 \
   coreos.inst.install_dev=/dev/<block_device> \

   1

   
   ignition.firstboot ignition.platform.id=metal \
   coreos.inst.ignition_url=http://<http_server>/master.ign \

   2

   
   coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \

   3

   
   ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
   rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1 \
   rd.zfcp=0.0.5677,0x600606680g7f0056,0x034F000000000000 \

   4

   
   zfcp.allow_lun_scan=0

   Copy to Clipboard Toggle word wrap

   1

   ブロックデバイスタイプを指定します。DASD タイプのディスクにインストールする場合は、/dev/dasda を指定します。FCP タイプのディスクにインストールする場合は、/dev/sda を指定します。

   2

   Ignition 設定ファイルの場所を指定します。master.ign または worker.ign を使用します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

   3

   起動する kernel と initramfs の rootfs アーティファクトの場所を指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

   4

   DASD タイプのディスクにインストールする場合は、rd.dasd=0.0.xxxx に置き換えて DASD デバイスを指定します。

   注記

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

手順

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 が逆引き DNS ルックアップによりホスト名を取得します。
     6. ネットワークインターフェイス名。この値を省略すると、RHCOS が利用可能なすべてのインターフェイスに IP 設定を適用します。
     7. 静的 IP アドレスを使用する場合、none を指定します。
   • coreos.inst.ignition_url= の場合、マシンロールの Ignition ファイルを指定します。bootstrap.ign、master.ign、または worker.ign を使用します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
   • coreos.live.rootfs_url= の場合、起動しているカーネルおよび initramfs の一致する rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
   • オプション: セキュアブートを有効にするには、coreos.inst.secure_ipl を追加します。

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

     1. coreos.inst.install_dev= には、/dev/disk/by-path/ccw-<device_id> を指定します。<device_id> には、たとえば 0.0.1000 を指定します。
     2. rd.dasd= を使用して、RHCOS がインストールされる DASD を指定します。

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

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

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/disk/by-id/scsi-<serial_number> \

        1

        
        coreos.inst.ignition_url=http://<http_server>/bootstrap.ign \

        2

        
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \

        3

        
        coreos.inst.secure_ipl \

        4

        
        ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        rd.dasd=0.0.3490

        Copy to Clipboard Toggle word wrap

        1

        ディスクの種類に応じて一意の完全修飾パスを指定します。これは、DASD タイプまたは FCP タイプのディスクのいずれかです。

        2

        Ignition 設定ファイルの場所を指定します。bootstrap.ign、master.ign、または worker.ign を使用します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

        3

        起動する kernel と initramfs の rootfs アーティファクトの場所を指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

        4

        オプション: セキュアブートを有効にするには、coreos.inst.secure_ipl を追加します。

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

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

     1. rd.zfcp=<adapter>,<wwpn>,<lun> を使用して RHCOS がインストールされる FCP ディスクを指定します。マルチパスの場合、それぞれの追加のステップでこのステップを繰り返します。

        注記

        複数のパスを使用してインストールする場合は、問題が発生する可能性があるため、後でではなくインストールの直後にマルチパスを有効にする必要があります。

     2. インストールデバイスを coreos.inst.install_dev=/dev/disk/by-id/scsi-<serial_number> として設定します。

4. オプション: generic.ins ファイルを作成します。

   インストール方法によっては、Hardware Management Console (HMC)、DVD、または FTP サーバーのファイルシステム内のインストールデータの場所と、データがコピーされるメモリー位置のマッピングを含む generic.ins ファイルも必要です。サンプルの generic.ins ファイルが、RHEL インストールメディアに付属しています。ファイルには、初期 RAM ディスク (initrd.img)、カーネルイメージ (kernel.img)、およびパラメーター (generic.prm) ファイルのファイル名と、各ファイルのメモリー位置が含まれています。

   generic.ins ファイルの例

   images/kernel.img 0x00000000
   images/initrd.img 0x02000000
   images/genericdvd.prm 0x00010480
   images/initrd.addrsize 0x00010408

   Copy to Clipboard Toggle word wrap

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

   重要

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

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

   cio_ignore=all,!condev rd.neednet=1 \
   console=ttysclp0 \
   coreos.inst.install_dev=/dev/disk/by-id/scsi-<serial_number> \
   coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
   coreos.inst.ignition_url=http://<http_server>/worker.ign \
   ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
   rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=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

   Copy to Clipboard Toggle word wrap

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

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

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

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

   ヒント

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

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

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

   $ ipl c

   Copy to Clipboard Toggle word wrap

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

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

手順

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

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

   1

   
       --log-level=info 

   2

   Copy to Clipboard Toggle word wrap

   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.31.3 up
   INFO Waiting up to 30m0s for bootstrapping to complete...
   INFO It is now safe to remove the bootstrap resources

   Copy to Clipboard Toggle word wrap

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

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

   重要

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

手順

1. 次のコマンドを実行して、kubeadmin 認証情報をエクスポートします。

   $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 

   1

   Copy to Clipboard Toggle word wrap

   1

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

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

   $ oc whoami

   Copy to Clipboard Toggle word wrap

   出力例

   system:admin

   Copy to Clipboard Toggle word wrap

手順

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

   $ oc get nodes

   Copy to Clipboard Toggle word wrap

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.31.3
   master-1  Ready     master  63m  v1.31.3
   master-2  Ready     master  64m  v1.31.3

   Copy to Clipboard Toggle word wrap

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

   注記

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

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

   $ oc get csr

   Copy to Clipboard Toggle word wrap

   出力例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   Copy to Clipboard Toggle word wrap

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

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

   注記

   CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

   注記

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

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

     $ oc adm certificate approve <csr_name> 

     1

     Copy to Clipboard Toggle word wrap

     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

     Copy to Clipboard Toggle word wrap
     注記

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

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

   $ oc get csr

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

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

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

     $ oc adm certificate approve <csr_name> 

     1

     Copy to Clipboard Toggle word wrap

     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

     Copy to Clipboard Toggle word wrap

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

   $ oc get nodes

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

   注記

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

手順

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

   $ watch -n5 oc get clusteroperators

   Copy to Clipboard Toggle word wrap

   出力例

   NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                             4.18.0    True        False         False      19m
   baremetal                                  4.18.0    True        False         False      37m
   cloud-credential                           4.18.0    True        False         False      40m
   cluster-autoscaler                         4.18.0    True        False         False      37m
   config-operator                            4.18.0    True        False         False      38m
   console                                    4.18.0    True        False         False      26m
   csi-snapshot-controller                    4.18.0    True        False         False      37m
   dns                                        4.18.0    True        False         False      37m
   etcd                                       4.18.0    True        False         False      36m
   image-registry                             4.18.0    True        False         False      31m
   ingress                                    4.18.0    True        False         False      30m
   insights                                   4.18.0    True        False         False      31m
   kube-apiserver                             4.18.0    True        False         False      26m
   kube-controller-manager                    4.18.0    True        False         False      36m
   kube-scheduler                             4.18.0    True        False         False      36m
   kube-storage-version-migrator              4.18.0    True        False         False      37m
   machine-api                                4.18.0    True        False         False      29m
   machine-approver                           4.18.0    True        False         False      37m
   machine-config                             4.18.0    True        False         False      36m
   marketplace                                4.18.0    True        False         False      37m
   monitoring                                 4.18.0    True        False         False      29m
   network                                    4.18.0    True        False         False      38m
   node-tuning                                4.18.0    True        False         False      37m
   openshift-apiserver                        4.18.0    True        False         False      32m
   openshift-controller-manager               4.18.0    True        False         False      30m
   openshift-samples                          4.18.0    True        False         False      32m
   operator-lifecycle-manager                 4.18.0    True        False         False      37m
   operator-lifecycle-manager-catalog         4.18.0    True        False         False      37m
   operator-lifecycle-manager-packageserver   4.18.0    True        False         False      32m
   service-ca                                 4.18.0    True        False         False      38m
   storage                                    4.18.0    True        False         False      37m

   Copy to Clipboard Toggle word wrap

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

手順

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

   $ watch -n5 oc get clusteroperators

   Copy to Clipboard Toggle word wrap

   出力例

   NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                             4.18.0    True        False         False      19m
   baremetal                                  4.18.0    True        False         False      37m
   cloud-credential                           4.18.0    True        False         False      40m
   cluster-autoscaler                         4.18.0    True        False         False      37m
   config-operator                            4.18.0    True        False         False      38m
   console                                    4.18.0    True        False         False      26m
   csi-snapshot-controller                    4.18.0    True        False         False      37m
   dns                                        4.18.0    True        False         False      37m
   etcd                                       4.18.0    True        False         False      36m
   image-registry                             4.18.0    True        False         False      31m
   ingress                                    4.18.0    True        False         False      30m
   insights                                   4.18.0    True        False         False      31m
   kube-apiserver                             4.18.0    True        False         False      26m
   kube-controller-manager                    4.18.0    True        False         False      36m
   kube-scheduler                             4.18.0    True        False         False      36m
   kube-storage-version-migrator              4.18.0    True        False         False      37m
   machine-api                                4.18.0    True        False         False      29m
   machine-approver                           4.18.0    True        False         False      37m
   machine-config                             4.18.0    True        False         False      36m
   marketplace                                4.18.0    True        False         False      37m
   monitoring                                 4.18.0    True        False         False      29m
   network                                    4.18.0    True        False         False      38m
   node-tuning                                4.18.0    True        False         False      37m
   openshift-apiserver                        4.18.0    True        False         False      32m
   openshift-controller-manager               4.18.0    True        False         False      30m
   openshift-samples                          4.18.0    True        False         False      32m
   operator-lifecycle-manager                 4.18.0    True        False         False      37m
   operator-lifecycle-manager-catalog         4.18.0    True        False         False      37m
   operator-lifecycle-manager-packageserver   4.18.0    True        False         False      32m
   service-ca                                 4.18.0    True        False         False      38m
   storage                                    4.18.0    True        False         False      37m

   Copy to Clipboard Toggle word wrap

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

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

   1

   Copy to Clipboard Toggle word wrap

   1

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

   出力例

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

   Copy to Clipboard Toggle word wrap

   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

      Copy to Clipboard Toggle word wrap

      出力例

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

      Copy to Clipboard Toggle word wrap

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

      $ oc logs <pod_name> -n <namespace> 

      1

      Copy to Clipboard Toggle word wrap

      1

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

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

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

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

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

1. 次のコマンドを実行してノードをデバッグします。

   $ oc debug node/<node_name>
   chroot /host

   Copy to Clipboard Toggle word wrap

2. 次のコマンドを実行して、セキュアブートが有効になっていることを確認します。

   $ cat /sys/firmware/ipl/secure

   Copy to Clipboard Toggle word wrap

   出力例

   1 

   1

   Copy to Clipboard Toggle word wrap

   1

   セキュアブートが有効になっている場合、値は 1 です。有効になっていない場合は 0 です。