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

手順

1. Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。

   ヒント

   特定の OpenShift Container Platform リリースのバイナリーをダウンロード することもできます。

2. ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
3. OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。

4. ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。

   重要
   • インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。クラスターを削除するには、両方のファイルが必要です。
   • インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

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

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

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

手順

1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

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

   1

   Copy to Clipboard Toggle word wrap

   1

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

   注記

   x86_64、ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

2. SSH 公開鍵を表示します。

   $ cat <path>/<file_name>.pub

   Copy to Clipboard Toggle word wrap

   たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

   $ cat ~/.ssh/id_ed25519.pub

   Copy to Clipboard Toggle word wrap

3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

   注記

   一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

   1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

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

      Copy to Clipboard Toggle word wrap

      出力例

      Agent pid 31874

      Copy to Clipboard Toggle word wrap

      注記

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

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

   $ ssh-add <path>/<file_name> 

   1

   Copy to Clipboard Toggle word wrap

   1

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

   出力例

   Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

   Copy to Clipboard Toggle word wrap

手順

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

   1. Kubernetes API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。

      $ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain> 

      1

      Copy to Clipboard Toggle word wrap

      1

      <nameserver_ip> をネームサーバーの IP アドレスに、<cluster_name> をクラスター名に、<base_domain> をベースドメイン名に置き換えます。

      出力例

      api.ocp4.example.com.		604800	IN	A	192.168.1.5

      Copy to Clipboard Toggle word wrap

   2. Kubernetes 内部 API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。

      $ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>

      Copy to Clipboard Toggle word wrap

      出力例

      api-int.ocp4.example.com.		604800	IN	A	192.168.1.5

      Copy to Clipboard Toggle word wrap

   3. *.apps.<cluster_name>.<base_domain> DNS ワイルドカードルックアップの例をテストします。すべてのアプリケーションのワイルドカードルックアップは、アプリケーション Ingress ロードバランサーの IP アドレスに解決する必要があります。

      $ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>

      Copy to Clipboard Toggle word wrap

      出力例

      random.apps.ocp4.example.com.		604800	IN	A	192.168.1.5

      Copy to Clipboard Toggle word wrap

      注記

      出力例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。

      random は、別のワイルドカード値に置き換えることができます。たとえば、OpenShift Container Platform コンソールへのルートをクエリーできます。

      $ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>

      Copy to Clipboard Toggle word wrap

      出力例

      console-openshift-console.apps.ocp4.example.com. 604800 IN	A 192.168.1.5

      Copy to Clipboard Toggle word wrap

   4. ブートストラップ DNS レコード名に対してルックアップを実行します。結果がブートストラップノードの IP アドレスを参照することを確認します。

      $ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>

      Copy to Clipboard Toggle word wrap

      出力例

      bootstrap.ocp4.example.com.		604800	IN	A	192.168.1.96

      Copy to Clipboard Toggle word wrap

   5. この方法を使用して、コントロールプレーンおよびコンピュートノードの DNS レコード名に対してルックアップを実行します。結果が各ノードの IP アドレスに対応していることを確認します。

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

   1. API ロードバランサーの IP アドレスに対して逆引き参照を実行します。応答に、Kubernetes API および Kubernetes 内部 API のレコード名が含まれていることを確認します。

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.5

      Copy to Clipboard Toggle word wrap

      出力例

      5.1.168.192.in-addr.arpa. 604800	IN	PTR	api-int.ocp4.example.com. 

      1

      
      5.1.168.192.in-addr.arpa. 604800	IN	PTR	api.ocp4.example.com. 

      2

      Copy to Clipboard Toggle word wrap

      1

      Kubernetes 内部 API のレコード名を指定します。

      2

      Kubernetes API のレコード名を指定します。

      注記

      PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。アプリケーション Ingress ロードバランサーの IP アドレスに対する逆引き DNS 解決の検証手順は必要ありません。

   2. ブートストラップノードの IP アドレスに対して逆引き参照を実行します。結果がブートストラップノードの DNS レコード名を参照していることを確認します。

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.96

      Copy to Clipboard Toggle word wrap

      出力例

      96.1.168.192.in-addr.arpa. 604800	IN	PTR	bootstrap.ocp4.example.com.

      Copy to Clipboard Toggle word wrap

   3. この方法を使用して、コントロールプレーンおよびコンピュートノードの IP アドレスに対して逆引きルックアップを実行します。結果が各ノードの DNS レコード名に対応していることを確認します。

手順

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. プロビジョニングマシンで 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.33.4 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.33.4
   master-1  Ready     master  63m  v1.33.4
   master-2  Ready     master  64m  v1.33.4

   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-mddf5   20m   system:node:master-01.example.com   Approved,Issued
   csr-z5rln   16m   system:node:worker-21.example.com   Approved,Issued

   Copy to Clipboard Toggle word wrap

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.33.4
   master-1  Ready     master  73m  v1.33.4
   master-2  Ready     master  74m  v1.33.4
   worker-0  Ready     worker  11m  v1.33.4
   worker-1  Ready     worker  11m  v1.33.4

   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.20.0    True        False         False      19m
   baremetal                                  4.20.0    True        False         False      37m
   cloud-credential                           4.20.0    True        False         False      40m
   cluster-autoscaler                         4.20.0    True        False         False      37m
   config-operator                            4.20.0    True        False         False      38m
   console                                    4.20.0    True        False         False      26m
   csi-snapshot-controller                    4.20.0    True        False         False      37m
   dns                                        4.20.0    True        False         False      37m
   etcd                                       4.20.0    True        False         False      36m
   image-registry                             4.20.0    True        False         False      31m
   ingress                                    4.20.0    True        False         False      30m
   insights                                   4.20.0    True        False         False      31m
   kube-apiserver                             4.20.0    True        False         False      26m
   kube-controller-manager                    4.20.0    True        False         False      36m
   kube-scheduler                             4.20.0    True        False         False      36m
   kube-storage-version-migrator              4.20.0    True        False         False      37m
   machine-api                                4.20.0    True        False         False      29m
   machine-approver                           4.20.0    True        False         False      37m
   machine-config                             4.20.0    True        False         False      36m
   marketplace                                4.20.0    True        False         False      37m
   monitoring                                 4.20.0    True        False         False      29m
   network                                    4.20.0    True        False         False      38m
   node-tuning                                4.20.0    True        False         False      37m
   openshift-apiserver                        4.20.0    True        False         False      32m
   openshift-controller-manager               4.20.0    True        False         False      30m
   openshift-samples                          4.20.0    True        False         False      32m
   operator-lifecycle-manager                 4.20.0    True        False         False      37m
   operator-lifecycle-manager-catalog         4.20.0    True        False         False      37m
   operator-lifecycle-manager-packageserver   4.20.0    True        False         False      32m
   service-ca                                 4.20.0    True        False         False      38m
   storage                                    4.20.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.20.0    True        False         False      19m
   baremetal                                  4.20.0    True        False         False      37m
   cloud-credential                           4.20.0    True        False         False      40m
   cluster-autoscaler                         4.20.0    True        False         False      37m
   config-operator                            4.20.0    True        False         False      38m
   console                                    4.20.0    True        False         False      26m
   csi-snapshot-controller                    4.20.0    True        False         False      37m
   dns                                        4.20.0    True        False         False      37m
   etcd                                       4.20.0    True        False         False      36m
   image-registry                             4.20.0    True        False         False      31m
   ingress                                    4.20.0    True        False         False      30m
   insights                                   4.20.0    True        False         False      31m
   kube-apiserver                             4.20.0    True        False         False      26m
   kube-controller-manager                    4.20.0    True        False         False      36m
   kube-scheduler                             4.20.0    True        False         False      36m
   kube-storage-version-migrator              4.20.0    True        False         False      37m
   machine-api                                4.20.0    True        False         False      29m
   machine-approver                           4.20.0    True        False         False      37m
   machine-config                             4.20.0    True        False         False      36m
   marketplace                                4.20.0    True        False         False      37m
   monitoring                                 4.20.0    True        False         False      29m
   network                                    4.20.0    True        False         False      38m
   node-tuning                                4.20.0    True        False         False      37m
   openshift-apiserver                        4.20.0    True        False         False      32m
   openshift-controller-manager               4.20.0    True        False         False      30m
   openshift-samples                          4.20.0    True        False         False      32m
   operator-lifecycle-manager                 4.20.0    True        False         False      37m
   operator-lifecycle-manager-catalog         4.20.0    True        False         False      37m
   operator-lifecycle-manager-packageserver   4.20.0    True        False         False      32m
   service-ca                                 4.20.0    True        False         False      38m
   storage                                    4.20.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 でのカーネル引数を使用したマルチパスの有効化」を参照してください。