21.3. user-provisioned infrastructure

手順

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. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
3. バージョン ドロップダウンリストから適切なバージョンを選択します。
4. OpenShift v4.14 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

5. アーカイブを展開します。

   $ tar xvf <file>

6. oc バイナリーを、PATH にあるディレクトリーに配置します。

   PATH を確認するには、以下のコマンドを実行します。

   $ echo $PATH

手順

1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
2. バージョン ドロップダウンリストから適切なバージョンを選択します。
3. OpenShift v4.14 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
4. ZIP プログラムでアーカイブを展開します。

5. oc バイナリーを、PATH にあるディレクトリーに移動します。

   PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

   C:\> path

手順

1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
2. バージョン ドロップダウンリストから適切なバージョンを選択します。

3. OpenShift v4.14 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

   注記

   macOS arm64 の場合は、OpenShift v4.14 macOS arm64 Client エントリーを選択します。

4. アーカイブを展開し、解凍します。

5. oc バイナリーをパスにあるディレクトリーに移動します。

   PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

   $ echo $PATH

手順

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

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

   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

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

   $ cat ~/.ssh/id_ed25519.pub

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

   注記

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

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

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

      出力例

      Agent pid 31874

      注記

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

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

   $ ssh-add <path>/<file_name> 1

   1

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

   出力例

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

手順

1. DHCP を使用して IP ネットワーク設定をクラスターノードに提供する場合は、DHCP サービスを設定します。

   1. ノードの永続 IP アドレスを DHCP サーバー設定に追加します。設定で、関連するネットワークインターフェイスの MAC アドレスを、各ノードの目的の IP アドレスと一致させます。

   2. DHCP を使用してクラスターマシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP サーバー設定を介してクラスターノードが使用する永続 DNS サーバーアドレスを定義します。

      注記

      DHCP サービスを使用しない場合、IP ネットワーク設定と DNS サーバーのアドレスを RHCOS インストール時にノードに指定する必要があります。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始のセクションを参照してください。

   3. DHCP サーバー設定でクラスターノードのホスト名を定義します。ホスト名に関する考慮事項については、DHCP を使用したクラスターノードのホスト名の設定 参照してください。

      注記

      DHCP サービスを使用しない場合、クラスターノードは逆引き DNS ルックアップを介してホスト名を取得します。

2. ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。

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

   重要

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

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

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

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

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

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

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

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

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

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

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

手順

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

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

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

      1

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

      出力例

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

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

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

      出力例

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

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

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

      出力例

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

      注記

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

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

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

      出力例

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

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

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

      出力例

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

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

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

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

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

      出力例

      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

      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

      出力例

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

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

手順

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

   $ mkdir <installation_directory>

   重要

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

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

   注記

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

3. 3 ノードクラスターをインストールする場合は、compute.replicas パラメーターを 0 に設定して、install-config.yaml ファイルを変更します。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細は、「vSphere への 3 ノードクラスターのインストール」を参照してください。

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

   重要

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

手順

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

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

   1

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

2. コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。

   $ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml

   これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。

3. コントロールプレーンマシンセットを定義する Kubernetes マニフェストファイルを削除します。

   $ rm -f <installation_directory>/openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml

4. オプション: クラスターでコンピュートマシンをプロビジョニングする必要がない場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。

   $ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml

   重要

   user-provisioned infrastructure にクラスターをインストールするときに MachineAPI 機能を無効にした場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除する必要があります。そうしないと、クラスターのインストールに失敗します。

   ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。

5. コントロールプレーンマシン、コンピュートマシンセット、およびコントロールプレーンマシンセットを定義する Kubernetes マニフェストファイルを削除します。

   $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml

   これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。

   • コンピュートマシンセットファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。

     警告

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

     重要

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

6. <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. ファイルを保存し、終了します。

7. オプション: Ingress Operator を DNS レコードを作成するよう設定する必要がない場合は、<installation_directory>/manifests/cluster-dns-02-config.yml DNS 設定ファイルから privateZone および publicZone セクションを削除します。

   apiVersion: config.openshift.io/v1
   kind: DNS
   metadata:
     creationTimestamp: null
     name: cluster
   spec:
     baseDomain: example.openshift.com
     privateZone: 1
       id: mycluster-100419-private-zone
     publicZone: 2
       id: example.openshift.com
   status: {}

   1 2

   このセクションを完全に削除します。

   これを実行する場合、後のステップで Ingress DNS レコードを手動で追加する必要があります。

8. Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。

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

   1

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

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

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

手順

1. <installation_directory>/bootstrap.ign という名前のインストールプログラムが作成したブートストラップ Ignition 設定ファイルを HTTP サーバーにアップロードします。このファイルの URL をメモします。

2. ブートストラップノードの以下の二次的な Ignition 設定ファイルを、<installation_directory>/merge-bootstrap.ign としてコンピューターに保存します。

   {
     "ignition": {
       "config": {
         "merge": [
           {
             "source": "<bootstrap_ignition_config_url>", 1
             "verification": {}
           }
         ]
       },
       "timeouts": {},
       "version": "3.2.0"
     },
     "networkd": {},
     "passwd": {},
     "storage": {},
     "systemd": {}
   }

   1

   ホストしているブートストラップの Ignition 設定ファイルの URL を指定します。

   ブートストラップマシンの仮想マシン (VM) を作成する場合に、この Ignition 設定ファイルを使用します。

3. インストールプログラムにより作成された次の Ignition 設定ファイルを見つけます。

   • <installation_directory>/master.ign
   • <installation_directory>/worker.ign
   • <installation_directory>/merge-bootstrap.ign

4. Ignition 設定ファイルを Base64 エンコーディングに変換します。この手順の後半で、これらのファイルを VM の追加の設定パラメーター guestinfo.ignition.config.data に追加する必要があります。

   たとえば、Linux オペレーティングシステムを使用する場合、base64 コマンドを使用してファイルをエンコードできます。

   $ base64 -w0 <installation_directory>/master.ign > <installation_directory>/master.64

   $ base64 -w0 <installation_directory>/worker.ign > <installation_directory>/worker.64

   $ base64 -w0 <installation_directory>/merge-bootstrap.ign > <installation_directory>/merge-bootstrap.64

   重要

   インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。

5. RHCOS OVA イメージを取得します。イメージは、RHCOS イメージミラー ページから入手できます。

   重要

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

   ファイル名には、rhcos-vmware.<architecture>.ova 形式の OpenShift Container Platform のバージョン番号が含まれます。

6. vSphere クライアントで、仮想マシンを保管するフォルダーをデータセンターに作成します。

   1. VMs and Templates ビューをクリックします。
   2. データセンターの名前を右クリックします。
   3. New Folder New VM and Template Folder をクリックします。
   4. 表示されるウィンドウで、フォルダー名を入力します。install-config.yaml ファイルに既存のフォルダーを指定していない場合には、インフラストラクチャー ID と同じ名前を持つフォルダーを作成します。このフォルダー名を使用すると、vCenter はその Workspace 設定に適した場所にあるストレージを動的にプロビジョニングします。

7. vSphere クライアントで、OVA イメージのテンプレートを作成してから、必要に応じてテンプレートのクローンを作成します。

   注記

   以下の手順では、テンプレートを作成してから、すべてのクラスターマシンのテンプレートのクローンを作成します。次に、仮想マシンのプロビジョニング時にクローン作成されたマシンタイプの Ignition 設定ファイルの場所を指定します。

   1. Hosts and Clusters タブで、クラスターの名前を右クリックし、Deploy OVF Template を選択します。
   2. Select an OVF タブで、ダウンロードした RHCOS OVA ファイルの名前を指定します。
   3. Select a name and folder タブで、Template-RHCOS などの Virtual machine name をテンプレートに設定します。vSphere クラスターの名前をクリックし、直前の手順で作成したフォルダーを選択します。
   4. Select a compute resource タブで、vSphere クラスターの名前をクリックします。

   5. Select storage タブで、仮想マシンのストレージオプションを設定します。

      • ストレージ設定に応じて、Thin Provision または Thick Provision を選択します。
      • install-config.yaml ファイルで指定したデータストアを選択します。
      • 仮想マシンを暗号化する場合は、Encrypt this virtual machine を選択します。詳細は、「仮想マシンを暗号化するための要件」セクションを参照してください。
   6. Select network タブで、クラスターに設定したネットワークを指定します (ある場合)。

   7. OVF テンプレートの作成時には、Customize template タブで値を指定したり、テンプレートに追加の設定をしないようにしてください。

      重要

      元の仮想マシンテンプレートは開始しないでください。仮想マシンテンプレートは停止した状態でなければなりません。また、新規 RHCOS マシン用にクローン作成する必要があります。仮想マシンテンプレートを起動すると、仮想マシンテンプレートがプラットフォームの仮想マシンとして設定されるので、これをコンピュートマシンセットで設定を適用できるテンプレートとして使用できなくなります。

8. 必要に応じて、仮想マシンテンプレートで設定された仮想ハードウェアバージョンを更新します。詳細は、VMware ドキュメントの Upgrading a virtual machine to the latest hardware version を参照してください。

   重要

   必要に応じて、仮想マシンを作成する前に、仮想マシンテンプレートのハードウェアバージョンをバージョン 15 に更新することが推奨されます。vSphere で実行しているクラスターノード用にハードウェアバージョン 13 を使用することは非推奨となりました。インポートしたテンプレートがハードウェアバージョン 13 にデフォルト設定されている場合は、仮想マシンテンプレートをハードウェアバージョン 15 にアップグレードする前に、ESXi ホストが 6.7U3 以降を使用していることを確認する必要があります。vSphere のバージョンが 6.7U3 未満の場合は、このアップグレード手順を省略できます。ただし、OpenShift Container Platform の今後のバージョンでは、ハードウェアバージョン 13 および vSphere バージョンのサポートが 6.7U3 未満になる予定です。

9. テンプレートがデプロイされた後に、マシンの仮想マシンをクラスターにデプロイします。

   1. テンプレートの名前を右クリックし、Clone Clone to Virtual Machine をクリックします。

   2. Select a name and folder タブで、仮想マシンの名前を指定します。control-plane-0 または compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

      注記

      vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

   3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
   4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
   5. Select clone options で、Customize this virtual machine's hardware を選択します。

   6. Customize hardware タブで、Advanced Parameters をクリックします。

      重要

      次の設定の提案は、例としてのみ使用されます。クラスター管理者は、クラスターに課せられるリソース需要に従ってリソースを設定する必要があります。クラスターリソースを最適に管理するには、クラスターのルートリソースプールからリソースプールを作成することを検討してください。

      • オプション: vSphere でデフォルトの DHCP ネットワークを上書きします。静的 IP ネットワークを有効にするには、以下を実行します。

        • 静的 IP 設定を行います。

          コマンドの例

          $ export IPCFG="ip=<ip>::<gateway>:<netmask>:<hostname>:<iface>:none nameserver=srv1 [nameserver=srv2 [nameserver=srv3 [...]]]"

          コマンドの例

          $ export IPCFG="ip=192.168.100.101::192.168.100.254:255.255.255.0:::none nameserver=8.8.8.8"

        • vSphere で OVA から仮想マシンを起動する前に、guestinfo.afterburn.initrd.network-kargs プロパティーを設定します。

          コマンドの例

          $ govc vm.change -vm "<vm_name>" -e "guestinfo.afterburn.initrd.network-kargs=${IPCFG}"

      • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

        • guestinfo.ignition.config.data: この手順で先程作成した、base-64 でエンコードされたファイルを見つけて、このマシンタイプに関する base-64 でエンコードされた Ignition 設定ファイルの内容を貼り付けます。
        • guestinfo.ignition.config.data.encoding: base64 を指定します。
        • disk.EnableUUID: TRUE を指定します。
        • stealclock.enable: このパラメーターが定義されていない場合は、追加して TRUE を指定します。
        • クラスターの root リソースプールから子リソースプールを作成します。この子リソースプールでリソースの割り当てを実行します。
   7. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。
   8. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
   9. Virtual Machines タブで仮想マシンを右クリックし、Power Power On を選択します。

   10. コンソール出力をチェックして、Ignition が実行されたことを確認します。

       コマンドの例

       Ignition: ran on 2022/03/14 14:48:33 UTC (this boot)
       Ignition: user-provided config was applied

手順

1. テンプレートの名前を右クリックし、Clone Clone to Virtual Machine をクリックします。

2. Select a name and folder タブで、仮想マシンの名前を指定します。compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

   注記

   vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
5. Select storage タブで、設定ファイルとディスクファイル用のストレージを選択します。
6. Select clone options で、Customize this virtual machine's hardware を選択します。

7. Customize hardware タブで、Advanced Parameters をクリックします。

   • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

     • guestinfo.ignition.config.data: このマシンファイルの base64 でエンコードしたコンピュート Ignition 設定ファイルの内容を貼り付けます。
     • guestinfo.ignition.config.data.encoding: base64 を指定します。
     • disk.EnableUUID: TRUE を指定します。
8. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。多くのネットワークが存在する場合は、Add New Device > Network Adapter を選択し、New Network メニュー項目に表示されるフィールドにネットワーク情報を入力します。
9. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
10. Virtual Machines タブで仮想マシンを右クリックし、Power Power On を選択します。

手順

1. OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。

   $ mkdir $HOME/clusterconfig

2. openshift-install を実行して、manifest および openshift のサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。

   $ openshift-install create manifests --dir $HOME/clusterconfig
   ? SSH Public Key ...
   $ ls $HOME/clusterconfig/openshift/
   99_kubeadmin-password-secret.yaml
   99_openshift-cluster-api_master-machines-0.yaml
   99_openshift-cluster-api_master-machines-1.yaml
   99_openshift-cluster-api_master-machines-2.yaml
   ...

3. 追加のパーティションを設定する Butane 設定を作成します。たとえば、$HOME/clusterconfig/98-var-partition.bu ファイルに名前を付け、ディスクのデバイス名を worker システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var ディレクトリーを別のパーティションにマウントします。

   variant: openshift
   version: 4.14.0
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 98-var-partition
   storage:
     disks:
     - device: /dev/disk/by-id/<device_name> 1
       partitions:
       - label: var
         start_mib: <partition_start_offset> 2
         size_mib: <partition_size> 3
         number: 5
     filesystems:
       - device: /dev/disk/by-partlabel/var
         path: /var
         format: xfs
         mount_options: [defaults, prjquota] 4
         with_mount_unit: true

   1

   パーティションを設定する必要のあるディスクのストレージデバイス名。

   2

   データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。

   3

   データパーティションのサイズ (メビバイト単位)。

   4

   コンテナーストレージに使用されるファイルシステムでは、prjquota マウントオプションを有効にする必要があります。

   注記

   個別の /var パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。

4. Butane config からマニフェストを作成し、clusterconfig/openshift ディレクトリーに保存します。たとえば、以下のコマンドを実行します。

   $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml

5. openshift-install を再度実行し、manifest および openshift のサブディレクトリー内のファイルセットから、Ignition 設定を作成します。

   $ openshift-install create ignition-configs --dir $HOME/clusterconfig
   $ ls $HOME/clusterconfig/
   auth  bootstrap.ign  master.ign  metadata.json  worker.ign

手順

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

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

   注記

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

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

   $ oc get csr

   出力例

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

   この例では、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 サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

   • それらを個別に承認するには、それぞれの有効な 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.27.3
   master-1  Ready     master  73m  v1.27.3
   master-2  Ready     master  74m  v1.27.3
   worker-0  Ready     worker  11m  v1.27.3
   worker-1  Ready     worker  11m  v1.27.3

   注記

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

手順

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

   $ watch -n5 oc get clusteroperators

   出力例

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

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

手順

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

   $ watch -n5 oc get clusteroperators

   出力例

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

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

   $ ./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. 以下のコマンドを実行して、既存の DRS 非アフィニティールールを削除します。

   $ govc cluster.rule.remove \
     -name openshift4-control-plane-group \
     -dc MyDatacenter -cluster MyCluster

   出力例

   [13-10-22 09:33:24] Reconfigure /MyDatacenter/host/MyCluster...OK

2. 以下のコマンドを実行して、更新された名前でルールを再度作成します。

   $ govc cluster.rule.create \
     -name openshift4-control-plane-group \
     -dc MyDatacenter -cluster MyOtherCluster \
     -enable \
     -anti-affinity master-0 master-1 master-2

手順

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. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

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

   1

   <installation_directory> は、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。

2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:

3. 以下の例のように、cluster-network-03-config.yml ファイルで、クラスターの高度なネットワーク設定を指定します。

   OpenShift SDN ネットワークプロバイダーに異なる VXLAN ポートを指定します。

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     defaultNetwork:
       openshiftSDNConfig:
         vxlanPort: 4800

   OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にします。

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     defaultNetwork:
       ovnKubernetesConfig:
         ipsecConfig: {}

4. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時に manifests/ ディレクトリーを使用します。

5. コントロールプレーンマシンおよび compute machineSets を定義する Kubernetes マニフェストファイルを削除します。

   $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml

   これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。

   • MachineSet ファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。

手順

1. <installation_directory>/bootstrap.ign という名前のインストールプログラムが作成したブートストラップ Ignition 設定ファイルを HTTP サーバーにアップロードします。このファイルの URL をメモします。

2. ブートストラップノードの以下の二次的な Ignition 設定ファイルを、<installation_directory>/merge-bootstrap.ign としてコンピューターに保存します。

   {
     "ignition": {
       "config": {
         "merge": [
           {
             "source": "<bootstrap_ignition_config_url>", 1
             "verification": {}
           }
         ]
       },
       "timeouts": {},
       "version": "3.2.0"
     },
     "networkd": {},
     "passwd": {},
     "storage": {},
     "systemd": {}
   }

   1

   ホストしているブートストラップの Ignition 設定ファイルの URL を指定します。

   ブートストラップマシンの仮想マシン (VM) を作成する場合に、この Ignition 設定ファイルを使用します。

3. インストールプログラムにより作成された次の Ignition 設定ファイルを見つけます。

   • <installation_directory>/master.ign
   • <installation_directory>/worker.ign
   • <installation_directory>/merge-bootstrap.ign

4. Ignition 設定ファイルを Base64 エンコーディングに変換します。この手順の後半で、これらのファイルを VM の追加の設定パラメーター guestinfo.ignition.config.data に追加する必要があります。

   たとえば、Linux オペレーティングシステムを使用する場合、base64 コマンドを使用してファイルをエンコードできます。

   $ base64 -w0 <installation_directory>/master.ign > <installation_directory>/master.64

   $ base64 -w0 <installation_directory>/worker.ign > <installation_directory>/worker.64

   $ base64 -w0 <installation_directory>/merge-bootstrap.ign > <installation_directory>/merge-bootstrap.64

   重要

   インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。

5. RHCOS OVA イメージを取得します。イメージは、RHCOS イメージミラー ページから入手できます。

   重要

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

   ファイル名には、rhcos-vmware.<architecture>.ova 形式の OpenShift Container Platform のバージョン番号が含まれます。

6. vSphere クライアントで、仮想マシンを保管するフォルダーをデータセンターに作成します。

   1. VMs and Templates ビューをクリックします。
   2. データセンターの名前を右クリックします。
   3. New Folder New VM and Template Folder をクリックします。
   4. 表示されるウィンドウで、フォルダー名を入力します。install-config.yaml ファイルに既存のフォルダーを指定していない場合には、インフラストラクチャー ID と同じ名前を持つフォルダーを作成します。このフォルダー名を使用すると、vCenter はその Workspace 設定に適した場所にあるストレージを動的にプロビジョニングします。

7. vSphere クライアントで、OVA イメージのテンプレートを作成してから、必要に応じてテンプレートのクローンを作成します。

   注記

   以下の手順では、テンプレートを作成してから、すべてのクラスターマシンのテンプレートのクローンを作成します。次に、仮想マシンのプロビジョニング時にクローン作成されたマシンタイプの Ignition 設定ファイルの場所を指定します。

   1. Hosts and Clusters タブで、クラスターの名前を右クリックし、Deploy OVF Template を選択します。
   2. Select an OVF タブで、ダウンロードした RHCOS OVA ファイルの名前を指定します。
   3. Select a name and folder タブで、Template-RHCOS などの Virtual machine name をテンプレートに設定します。vSphere クラスターの名前をクリックし、直前の手順で作成したフォルダーを選択します。
   4. Select a compute resource タブで、vSphere クラスターの名前をクリックします。

   5. Select storage タブで、仮想マシンのストレージオプションを設定します。

      • ストレージ設定に応じて、Thin Provision または Thick Provision を選択します。
      • install-config.yaml ファイルで指定したデータストアを選択します。
      • 仮想マシンを暗号化する場合は、Encrypt this virtual machine を選択します。詳細は、「仮想マシンを暗号化するための要件」セクションを参照してください。
   6. Select network タブで、クラスターに設定したネットワークを指定します (ある場合)。

   7. OVF テンプレートの作成時には、Customize template タブで値を指定したり、テンプレートに追加の設定をしないようにしてください。

      重要

      元の仮想マシンテンプレートは開始しないでください。仮想マシンテンプレートは停止した状態でなければなりません。また、新規 RHCOS マシン用にクローン作成する必要があります。仮想マシンテンプレートを起動すると、仮想マシンテンプレートがプラットフォームの仮想マシンとして設定されるので、これをコンピュートマシンセットで設定を適用できるテンプレートとして使用できなくなります。

8. 必要に応じて、仮想マシンテンプレートで設定された仮想ハードウェアバージョンを更新します。詳細は、VMware ドキュメントの Upgrading a virtual machine to the latest hardware version を参照してください。

   重要

   必要に応じて、仮想マシンを作成する前に、仮想マシンテンプレートのハードウェアバージョンをバージョン 15 に更新することが推奨されます。vSphere で実行しているクラスターノード用にハードウェアバージョン 13 を使用することは非推奨となりました。インポートしたテンプレートがハードウェアバージョン 13 にデフォルト設定されている場合は、仮想マシンテンプレートをハードウェアバージョン 15 にアップグレードする前に、ESXi ホストが 6.7U3 以降を使用していることを確認する必要があります。vSphere のバージョンが 6.7U3 未満の場合は、このアップグレード手順を省略できます。ただし、OpenShift Container Platform の今後のバージョンでは、ハードウェアバージョン 13 および vSphere バージョンのサポートが 6.7U3 未満になる予定です。

9. テンプレートがデプロイされた後に、マシンの仮想マシンをクラスターにデプロイします。

   1. テンプレートの名前を右クリックし、Clone Clone to Virtual Machine をクリックします。

   2. Select a name and folder タブで、仮想マシンの名前を指定します。control-plane-0 または compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

      注記

      vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

   3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
   4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
   5. Select clone options で、Customize this virtual machine's hardware を選択します。

   6. Customize hardware タブで、Advanced Parameters をクリックします。

      重要

      次の設定の提案は、例としてのみ使用されます。クラスター管理者は、クラスターに課せられるリソース需要に従ってリソースを設定する必要があります。クラスターリソースを最適に管理するには、クラスターのルートリソースプールからリソースプールを作成することを検討してください。

      • オプション: vSphere でデフォルトの DHCP ネットワークを上書きします。静的 IP ネットワークを有効にするには、以下を実行します。

        • 静的 IP 設定を行います。

          コマンドの例

          $ export IPCFG="ip=<ip>::<gateway>:<netmask>:<hostname>:<iface>:none nameserver=srv1 [nameserver=srv2 [nameserver=srv3 [...]]]"

          コマンドの例

          $ export IPCFG="ip=192.168.100.101::192.168.100.254:255.255.255.0:::none nameserver=8.8.8.8"

        • vSphere で OVA から仮想マシンを起動する前に、guestinfo.afterburn.initrd.network-kargs プロパティーを設定します。

          コマンドの例

          $ govc vm.change -vm "<vm_name>" -e "guestinfo.afterburn.initrd.network-kargs=${IPCFG}"

      • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

        • guestinfo.ignition.config.data: この手順で先程作成した、base-64 でエンコードされたファイルを見つけて、このマシンタイプに関する base-64 でエンコードされた Ignition 設定ファイルの内容を貼り付けます。
        • guestinfo.ignition.config.data.encoding: base64 を指定します。
        • disk.EnableUUID: TRUE を指定します。
        • stealclock.enable: このパラメーターが定義されていない場合は、追加して TRUE を指定します。
        • クラスターの root リソースプールから子リソースプールを作成します。この子リソースプールでリソースの割り当てを実行します。
   7. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。
   8. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
   9. Virtual Machines タブで仮想マシンを右クリックし、Power Power On を選択します。

   10. コンソール出力をチェックして、Ignition が実行されたことを確認します。

       コマンドの例

       Ignition: ran on 2022/03/14 14:48:33 UTC (this boot)
       Ignition: user-provided config was applied

手順

1. テンプレートの名前を右クリックし、Clone Clone to Virtual Machine をクリックします。

2. Select a name and folder タブで、仮想マシンの名前を指定します。compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

   注記

   vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
5. Select storage タブで、設定ファイルとディスクファイル用のストレージを選択します。
6. Select clone options で、Customize this virtual machine's hardware を選択します。

7. Customize hardware タブで、Advanced Parameters をクリックします。

   • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

     • guestinfo.ignition.config.data: このマシンファイルの base64 でエンコードしたコンピュート Ignition 設定ファイルの内容を貼り付けます。
     • guestinfo.ignition.config.data.encoding: base64 を指定します。
     • disk.EnableUUID: TRUE を指定します。
8. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。多くのネットワークが存在する場合は、Add New Device > Network Adapter を選択し、New Network メニュー項目に表示されるフィールドにネットワーク情報を入力します。
9. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
10. Virtual Machines タブで仮想マシンを右クリックし、Power Power On を選択します。

手順

1. OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。

   $ mkdir $HOME/clusterconfig

2. openshift-install を実行して、manifest および openshift のサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。

   $ openshift-install create manifests --dir $HOME/clusterconfig
   ? SSH Public Key ...
   $ ls $HOME/clusterconfig/openshift/
   99_kubeadmin-password-secret.yaml
   99_openshift-cluster-api_master-machines-0.yaml
   99_openshift-cluster-api_master-machines-1.yaml
   99_openshift-cluster-api_master-machines-2.yaml
   ...

3. 追加のパーティションを設定する Butane 設定を作成します。たとえば、$HOME/clusterconfig/98-var-partition.bu ファイルに名前を付け、ディスクのデバイス名を worker システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var ディレクトリーを別のパーティションにマウントします。

   variant: openshift
   version: 4.14.0
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 98-var-partition
   storage:
     disks:
     - device: /dev/disk/by-id/<device_name> 1
       partitions:
       - label: var
         start_mib: <partition_start_offset> 2
         size_mib: <partition_size> 3
         number: 5
     filesystems:
       - device: /dev/disk/by-partlabel/var
         path: /var
         format: xfs
         mount_options: [defaults, prjquota] 4
         with_mount_unit: true

   1

   パーティションを設定する必要のあるディスクのストレージデバイス名。

   2

   データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。

   3

   データパーティションのサイズ (メビバイト単位)。

   4

   コンテナーストレージに使用されるファイルシステムでは、prjquota マウントオプションを有効にする必要があります。

   注記

   個別の /var パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。

4. Butane config からマニフェストを作成し、clusterconfig/openshift ディレクトリーに保存します。たとえば、以下のコマンドを実行します。

   $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml

5. openshift-install を再度実行し、manifest および openshift のサブディレクトリー内のファイルセットから、Ignition 設定を作成します。

   $ openshift-install create ignition-configs --dir $HOME/clusterconfig
   $ ls $HOME/clusterconfig/
   auth  bootstrap.ign  master.ign  metadata.json  worker.ign

手順

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

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

   注記

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

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

   $ oc get csr

   出力例

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

   この例では、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 サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

   • それらを個別に承認するには、それぞれの有効な 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.27.3
   master-1  Ready     master  73m  v1.27.3
   master-2  Ready     master  74m  v1.27.3
   worker-0  Ready     worker  11m  v1.27.3
   worker-1  Ready     worker  11m  v1.27.3

   注記

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

手順

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

   $ watch -n5 oc get clusteroperators

   出力例

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

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

   $ ./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. 以下のコマンドを実行して、既存の DRS 非アフィニティールールを削除します。

   $ govc cluster.rule.remove \
     -name openshift4-control-plane-group \
     -dc MyDatacenter -cluster MyCluster

   出力例

   [13-10-22 09:33:24] Reconfigure /MyDatacenter/host/MyCluster...OK

2. 以下のコマンドを実行して、更新された名前でルールを再度作成します。

   $ govc cluster.rule.create \
     -name openshift4-control-plane-group \
     -dc MyDatacenter -cluster MyOtherCluster \
     -enable \
     -anti-affinity master-0 master-1 master-2

手順

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

   $ mkdir <installation_directory>

   重要

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

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

   注記

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

   • docker.io などの、RHCOS がデフォルトで信頼するレジストリーを使用しない限り、additionalTrustBundle セクションにミラーリポジトリーの証明書の内容を指定する必要があります。ほとんどの場合、ミラーの証明書を指定する必要があります。
   • リポジトリーのミラーリングに使用するコマンドの出力の imageContentSources セクションを組み込む必要があります。
   重要
   • ImageContentSourcePolicy ファイルは、ミラーリングプロセスの終了後に oc mirror の出力として生成されます。
   • oc mirror コマンドは、ImageContentSourcePolicy の定義に必要な YAML を含む ImageContentSourcePolicy ファイルを生成します。このファイルからテキストをコピーし、install-config.yaml ファイルに貼り付けます。
   • 'oc mirror' コマンドを 2 回実行する必要があります。初めて oc mirror コマンドを実行すると、完全な ImageContentSourcePolicy ファイルが取得されます。oc mirror コマンドを 2 回目に実行すると、1 回目と 2 回目の実行の差のみが得られます。この動作のため、これらのファイルを 1 つの完全な ImageContentSourcePolicy ファイルにマージする必要がある場合に備えて、常にこれらのファイルのバックアップを保持する必要があります。これら 2 つの出力ファイルのバックアップを保持すると、完全な ImageContentSourcePolicy ファイルが確実に作成されます。

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

   重要

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

手順

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

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

   1

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

2. コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。

   $ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml

   これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。

3. コントロールプレーンマシンセットを定義する Kubernetes マニフェストファイルを削除します。

   $ rm -f <installation_directory>/openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml

4. オプション: クラスターでコンピュートマシンをプロビジョニングする必要がない場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。

   $ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml

   重要

   user-provisioned infrastructure にクラスターをインストールするときに MachineAPI 機能を無効にした場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除する必要があります。そうしないと、クラスターのインストールに失敗します。

   ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。

5. コントロールプレーンマシン、コンピュートマシンセット、およびコントロールプレーンマシンセットを定義する Kubernetes マニフェストファイルを削除します。

   $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml

   これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。

   • コンピュートマシンセットファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。

6. <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. ファイルを保存し、終了します。

7. オプション: Ingress Operator を DNS レコードを作成するよう設定する必要がない場合は、<installation_directory>/manifests/cluster-dns-02-config.yml DNS 設定ファイルから privateZone および publicZone セクションを削除します。

   apiVersion: config.openshift.io/v1
   kind: DNS
   metadata:
     creationTimestamp: null
     name: cluster
   spec:
     baseDomain: example.openshift.com
     privateZone: 1
       id: mycluster-100419-private-zone
     publicZone: 2
       id: example.openshift.com
   status: {}

   1 2

   このセクションを完全に削除します。

   これを実行する場合、後のステップで Ingress DNS レコードを手動で追加する必要があります。

8. Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。

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

   1

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

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

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

手順

1. chrony.conf ファイルのコンテンツを含む Butane 設定を作成します。たとえば、ワーカーノードで chrony を設定するには、99-worker-chrony.bu ファイルを作成します。

   注記

   Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。

   variant: openshift
   version: 4.14.0
   metadata:
     name: 99-worker-chrony 1
     labels:
       machineconfiguration.openshift.io/role: worker 2
   storage:
     files:
     - path: /etc/chrony.conf
       mode: 0644 3
       overwrite: true
       contents:
         inline: |
           pool 0.rhel.pool.ntp.org iburst 4
           driftfile /var/lib/chrony/drift
           makestep 1.0 3
           rtcsync
           logdir /var/log/chrony

   1 2

   コントロールプレーンノードでは、これらの両方の場所で worker の代わりに master を使用します。

   3

   マシン設定ファイルの mode フィールドに 8 進数の値でモードを指定します。ファイルを作成し、変更を適用すると、mode は 10 進数の値に変換されます。コマンド oc get mc <mc-name> -o yaml で YAML ファイルを確認できます。

   4

   DHCP サーバーが提供するものなど、有効な到達可能なタイムソースを指定します。

2. Butane を使用して、ノードに配信される設定を含む MachineConfig オブジェクトファイル (99-worker-chrony.yaml) を生成します。

   $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml

3. 以下の 2 つの方法のいずれかで設定を適用します。

   • クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、MachineConfig オブジェクトファイルを <installation_directory>/openshift ディレクトリーに追加してから、クラスターの作成を続行します。

   • クラスターがすでに実行中の場合は、ファイルを適用します。

     $ oc apply -f ./99-worker-chrony.yaml

手順

1. <installation_directory>/bootstrap.ign という名前のインストールプログラムが作成したブートストラップ Ignition 設定ファイルを HTTP サーバーにアップロードします。このファイルの URL をメモします。

2. ブートストラップノードの以下の二次的な Ignition 設定ファイルを、<installation_directory>/merge-bootstrap.ign としてコンピューターに保存します。

   {
     "ignition": {
       "config": {
         "merge": [
           {
             "source": "<bootstrap_ignition_config_url>", 1
             "verification": {}
           }
         ]
       },
       "timeouts": {},
       "version": "3.2.0"
     },
     "networkd": {},
     "passwd": {},
     "storage": {},
     "systemd": {}
   }

   1

   ホストしているブートストラップの Ignition 設定ファイルの URL を指定します。

   ブートストラップマシンの仮想マシン (VM) を作成する場合に、この Ignition 設定ファイルを使用します。

3. インストールプログラムにより作成された次の Ignition 設定ファイルを見つけます。

   • <installation_directory>/master.ign
   • <installation_directory>/worker.ign
   • <installation_directory>/merge-bootstrap.ign

4. Ignition 設定ファイルを Base64 エンコーディングに変換します。この手順の後半で、これらのファイルを VM の追加の設定パラメーター guestinfo.ignition.config.data に追加する必要があります。

   たとえば、Linux オペレーティングシステムを使用する場合、base64 コマンドを使用してファイルをエンコードできます。

   $ base64 -w0 <installation_directory>/master.ign > <installation_directory>/master.64

   $ base64 -w0 <installation_directory>/worker.ign > <installation_directory>/worker.64

   $ base64 -w0 <installation_directory>/merge-bootstrap.ign > <installation_directory>/merge-bootstrap.64

   重要

   インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。

5. RHCOS OVA イメージを取得します。イメージは、RHCOS イメージミラー ページから入手できます。

   重要

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

   ファイル名には、rhcos-vmware.<architecture>.ova 形式の OpenShift Container Platform のバージョン番号が含まれます。

6. vSphere クライアントで、仮想マシンを保管するフォルダーをデータセンターに作成します。

   1. VMs and Templates ビューをクリックします。
   2. データセンターの名前を右クリックします。
   3. New Folder New VM and Template Folder をクリックします。
   4. 表示されるウィンドウで、フォルダー名を入力します。install-config.yaml ファイルに既存のフォルダーを指定していない場合には、インフラストラクチャー ID と同じ名前を持つフォルダーを作成します。このフォルダー名を使用すると、vCenter はその Workspace 設定に適した場所にあるストレージを動的にプロビジョニングします。

7. vSphere クライアントで、OVA イメージのテンプレートを作成してから、必要に応じてテンプレートのクローンを作成します。

   注記

   以下の手順では、テンプレートを作成してから、すべてのクラスターマシンのテンプレートのクローンを作成します。次に、仮想マシンのプロビジョニング時にクローン作成されたマシンタイプの Ignition 設定ファイルの場所を指定します。

   1. Hosts and Clusters タブで、クラスターの名前を右クリックし、Deploy OVF Template を選択します。
   2. Select an OVF タブで、ダウンロードした RHCOS OVA ファイルの名前を指定します。
   3. Select a name and folder タブで、Template-RHCOS などの Virtual machine name をテンプレートに設定します。vSphere クラスターの名前をクリックし、直前の手順で作成したフォルダーを選択します。
   4. Select a compute resource タブで、vSphere クラスターの名前をクリックします。

   5. Select storage タブで、仮想マシンのストレージオプションを設定します。

      • ストレージ設定に応じて、Thin Provision または Thick Provision を選択します。
      • install-config.yaml ファイルで指定したデータストアを選択します。
      • 仮想マシンを暗号化する場合は、Encrypt this virtual machine を選択します。詳細は、「仮想マシンを暗号化するための要件」セクションを参照してください。
   6. Select network タブで、クラスターに設定したネットワークを指定します (ある場合)。

   7. OVF テンプレートの作成時には、Customize template タブで値を指定したり、テンプレートに追加の設定をしないようにしてください。

      重要

      元の仮想マシンテンプレートは開始しないでください。仮想マシンテンプレートは停止した状態でなければなりません。また、新規 RHCOS マシン用にクローン作成する必要があります。仮想マシンテンプレートを起動すると、仮想マシンテンプレートがプラットフォームの仮想マシンとして設定されるので、これをコンピュートマシンセットで設定を適用できるテンプレートとして使用できなくなります。

8. 必要に応じて、仮想マシンテンプレートで設定された仮想ハードウェアバージョンを更新します。詳細は、VMware ドキュメントの Upgrading a virtual machine to the latest hardware version を参照してください。

   重要

   必要に応じて、仮想マシンを作成する前に、仮想マシンテンプレートのハードウェアバージョンをバージョン 15 に更新することが推奨されます。vSphere で実行しているクラスターノード用にハードウェアバージョン 13 を使用することは非推奨となりました。インポートしたテンプレートがハードウェアバージョン 13 にデフォルト設定されている場合は、仮想マシンテンプレートをハードウェアバージョン 15 にアップグレードする前に、ESXi ホストが 6.7U3 以降を使用していることを確認する必要があります。vSphere のバージョンが 6.7U3 未満の場合は、このアップグレード手順を省略できます。ただし、OpenShift Container Platform の今後のバージョンでは、ハードウェアバージョン 13 および vSphere バージョンのサポートが 6.7U3 未満になる予定です。

9. テンプレートがデプロイされた後に、マシンの仮想マシンをクラスターにデプロイします。

   1. テンプレートの名前を右クリックし、Clone Clone to Virtual Machine をクリックします。

   2. Select a name and folder タブで、仮想マシンの名前を指定します。control-plane-0 または compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

      注記

      vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

   3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
   4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
   5. Select clone options で、Customize this virtual machine's hardware を選択します。

   6. Customize hardware タブで、Advanced Parameters をクリックします。

      重要

      次の設定の提案は、例としてのみ使用されます。クラスター管理者は、クラスターに課せられるリソース需要に従ってリソースを設定する必要があります。クラスターリソースを最適に管理するには、クラスターのルートリソースプールからリソースプールを作成することを検討してください。

      • オプション: vSphere でデフォルトの DHCP ネットワークを上書きします。静的 IP ネットワークを有効にするには、以下を実行します。

        • 静的 IP 設定を行います。

          コマンドの例

          $ export IPCFG="ip=<ip>::<gateway>:<netmask>:<hostname>:<iface>:none nameserver=srv1 [nameserver=srv2 [nameserver=srv3 [...]]]"

          コマンドの例

          $ export IPCFG="ip=192.168.100.101::192.168.100.254:255.255.255.0:::none nameserver=8.8.8.8"

        • vSphere で OVA から仮想マシンを起動する前に、guestinfo.afterburn.initrd.network-kargs プロパティーを設定します。

          コマンドの例

          $ govc vm.change -vm "<vm_name>" -e "guestinfo.afterburn.initrd.network-kargs=${IPCFG}"

      • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

        • guestinfo.ignition.config.data: この手順で先程作成した、base-64 でエンコードされたファイルを見つけて、このマシンタイプに関する base-64 でエンコードされた Ignition 設定ファイルの内容を貼り付けます。
        • guestinfo.ignition.config.data.encoding: base64 を指定します。
        • disk.EnableUUID: TRUE を指定します。
        • stealclock.enable: このパラメーターが定義されていない場合は、追加して TRUE を指定します。
        • クラスターの root リソースプールから子リソースプールを作成します。この子リソースプールでリソースの割り当てを実行します。
   7. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。
   8. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
   9. Virtual Machines タブで仮想マシンを右クリックし、Power Power On を選択します。

   10. コンソール出力をチェックして、Ignition が実行されたことを確認します。

       コマンドの例

       Ignition: ran on 2022/03/14 14:48:33 UTC (this boot)
       Ignition: user-provided config was applied

手順

1. テンプレートの名前を右クリックし、Clone Clone to Virtual Machine をクリックします。

2. Select a name and folder タブで、仮想マシンの名前を指定します。compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

   注記

   vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
5. Select storage タブで、設定ファイルとディスクファイル用のストレージを選択します。
6. Select clone options で、Customize this virtual machine's hardware を選択します。

7. Customize hardware タブで、Advanced Parameters をクリックします。

   • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

     • guestinfo.ignition.config.data: このマシンファイルの base64 でエンコードしたコンピュート Ignition 設定ファイルの内容を貼り付けます。
     • guestinfo.ignition.config.data.encoding: base64 を指定します。
     • disk.EnableUUID: TRUE を指定します。
8. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。多くのネットワークが存在する場合は、Add New Device > Network Adapter を選択し、New Network メニュー項目に表示されるフィールドにネットワーク情報を入力します。
9. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
10. Virtual Machines タブで仮想マシンを右クリックし、Power Power On を選択します。

手順

1. OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。

   $ mkdir $HOME/clusterconfig

2. openshift-install を実行して、manifest および openshift のサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。

   $ openshift-install create manifests --dir $HOME/clusterconfig
   ? SSH Public Key ...
   $ ls $HOME/clusterconfig/openshift/
   99_kubeadmin-password-secret.yaml
   99_openshift-cluster-api_master-machines-0.yaml
   99_openshift-cluster-api_master-machines-1.yaml
   99_openshift-cluster-api_master-machines-2.yaml
   ...

3. 追加のパーティションを設定する Butane 設定を作成します。たとえば、$HOME/clusterconfig/98-var-partition.bu ファイルに名前を付け、ディスクのデバイス名を worker システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var ディレクトリーを別のパーティションにマウントします。

   variant: openshift
   version: 4.14.0
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 98-var-partition
   storage:
     disks:
     - device: /dev/disk/by-id/<device_name> 1
       partitions:
       - label: var
         start_mib: <partition_start_offset> 2
         size_mib: <partition_size> 3
         number: 5
     filesystems:
       - device: /dev/disk/by-partlabel/var
         path: /var
         format: xfs
         mount_options: [defaults, prjquota] 4
         with_mount_unit: true

   1

   パーティションを設定する必要のあるディスクのストレージデバイス名。

   2

   データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。

   3

   データパーティションのサイズ (メビバイト単位)。

   4

   コンテナーストレージに使用されるファイルシステムでは、prjquota マウントオプションを有効にする必要があります。

   注記

   個別の /var パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。

4. Butane config からマニフェストを作成し、clusterconfig/openshift ディレクトリーに保存します。たとえば、以下のコマンドを実行します。

   $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml

5. openshift-install を再度実行し、manifest および openshift のサブディレクトリー内のファイルセットから、Ignition 設定を作成します。

   $ openshift-install create ignition-configs --dir $HOME/clusterconfig
   $ ls $HOME/clusterconfig/
   auth  bootstrap.ign  master.ign  metadata.json  worker.ign

手順

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

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

   注記

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

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

   $ oc get csr

   出力例

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

   この例では、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 サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

   • それらを個別に承認するには、それぞれの有効な 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.27.3
   master-1  Ready     master  73m  v1.27.3
   master-2  Ready     master  74m  v1.27.3
   worker-0  Ready     worker  11m  v1.27.3
   worker-1  Ready     worker  11m  v1.27.3

   注記

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

手順

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

   $ watch -n5 oc get clusteroperators

   出力例

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

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