16.4. ユーザーによってプロビジョニングされるインフラストラクチャーを使用した RHV へのクラスターのインストール
OpenShift Container Platform バージョン 4.9 では、Red Hat Virtualization (RHV) および提供する他のインフラストラクチャーにカスタマイズされた OpenShift Container Platform クラスターをインストールできます。OpenShift Container Platform ドキュメントでは、ユーザーによってプロビジョニングされるインフラストラクチャー という用語を使用して、このインフラストラクチャータイプに言及しています。
以下の図は、RHV クラスターで実行される可能性のある OpenShift Container Platform クラスターの例を示しています。
RHV ホストは、コントロールプレーンとコンピュート Pod の両方が含まれる仮想マシンを実行します。ホストのいずれかが Manage 仮想マシンと、一時的なコントロールプレーン Pod を含むブートストラップ仮想マシンも実行します。
16.4.1. 前提条件
OpenShift Container Platform クラスターを RHV 環境にインストールするには、以下の要件を満たしている必要があります。
- OpenShift Container Platform のインストールおよび更新 プロセスについての詳細を確認している。
- クラスターンストール方法の選択およびそのユーザー向けの準備 を確認している。
- Support Matrix for OpenShift Container Platform on Red Hat Virtualization (RHV) に記載のあるサポートされるバージョンの組み合わせを使用できる。
16.4.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.9 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
16.4.3. RHV 環境の要件
OpenShift Container Platform バージョン 4.9 クラスターをインストールし、実行するには、RHV 環境が以下の要件を満たしている必要があります。
これらの要件を満たさないと、インストールまたはプロセスが失敗する可能性があります。さらに、これらの要件を満たしていないと、OpenShift Container Platform クラスターはインストールしてから数日または数週間後に失敗する可能性があります。
CPU、メモリー、ストレージリソースについての以下の要件は、インストールプログラムが作成する仮想マシンのデフォルト数で乗算した デフォルト 値に基づいています。これらのリソースは、RHV 環境が OpenShift Container Platform 以外の操作に使用するものに 加え、利用可能でなければなりません。
デフォルトでは、インストールプログラムは 7 つの仮想マシンをインストールプロセスで作成します。まず、ブートストラップ仮想マシンを作成し、OpenShift Container Platform クラスターの残りの部分を作成する間に一時サービスとコントロールプレーンを提供します。インストールプログラムがクラスターの作成を終了すると、ブートストラップマシンが削除され、そのリソースが解放されます。
RHV 環境の仮想マシン数を増やす場合は、リソースを適宜増やす必要があります。
要件
- RHV のバージョンは 4.4 である。
- RHV 環境に Up 状態のデータセンターが 1 つあること。
- RHV データセンターに RHV クラスターが含まれていること。
RHV クラスターに OpenShift Container Platform クラスター専用の以下のリソースがあること。
- 最小 28 vCPU: インストール時に作成される 7 仮想マシンのそれぞれに 4 vCPU。
以下を含む 112 GiB 以上の RAM。
- 一時的なコントロールプレーンを提供するブートストラップマシン用に 16 GiB 以上。
- コントロールプレーンを提供する 3 つのコントロールプレーンマシンのそれぞれに 16 GiB 以上。
- アプリケーションワークロードを実行する 3 つのコンピュートマシンのそれぞれに 16 GiB 以上。
- RHV ストレージドメインは、これらの etcd バックエンドのパフォーマンス要件 を満たす必要があります。
- 実稼働環境では、各仮想マシンに 120 GiB 以上が必要です。そのため、ストレージドメインはデフォルトの OpenShift Container Platform クラスターに 840 GiB 以上を提供する必要があります。リソースに制約のある環境または非実稼働環境では、各仮想マシンに 32 GiB 以上を指定する必要があるため、ストレージドメインにはデフォルトの OpenShift Container Platform クラスター用に 230 GiB 以上が必要になります。
- インストールおよび更新中に Red Hat Ecosystem Catalog からイメージをダウンロードするには、RHV クラスターがインターネット接続にアクセスできる必要があります。また、サブスクリプションおよびエンタイトルメントプロセスを単純化するために Telemetry サービスにもインターネット接続が必要です。
- RHV クラスターには、RHV Manager の REST API にアクセスできる仮想ネットワークが必要です。インストーラーが作成する仮想マシンが DHCP を使用して IP アドレスを取得するため、DHCP がこのネットワークで有効にされていることを確認します。
ターゲット RHV クラスターに OpenShift Container Platform クラスターをインストールし、管理するための以下の最小限の権限を持つユーザーアカウントおよびグループ。
-
DiskOperator
-
DiskCreator
-
UserTemplateBasedVm
-
TemplateOwner
-
TemplateCreator
-
ターゲットクラスターの
ClusterAdmin
-
最小権限の原則を適用します。インストールプロセスで RHV で SuperUser
権限を持つ管理者アカウントを使用することを避けます。インストールプログラムは、ユーザーが指定する認証情報を、危険にさらされる可能性のある一時的な ovirt-config.yaml
ファイルに保存します。
16.4.4. RHV 環境の要件の確認
RHV 環境が OpenShift Container Platform クラスターをインストールし、実行するための要件を満たしていることを確認します。これらの要件を満たさないと、エラーが発生する可能性があります。
これらの要件は、インストールプログラムがコントロールプレーンおよびコンピュートマシンの作成に使用するデフォルトのリソースに基づいています。これらのリソースには、vCPU、メモリー、およびストレージが含まれます。これらのリソースを変更するか、または OpenShift Container Platform マシンの数を増やす場合は、これらの要件を適宜調整します。
手順
RHV のバージョンが OpenShift Container Platform バージョン 4.9 のインストールをサポートすることを確認します。
- RHV Administration Portal の右上にある ? ヘルプアイコンをクリックし、About を選択します。
- 開かれるウィンドウで、RHV ソフトウェアのバージョン をメモします。
- RHV のバージョンが 4.4 であることを確認します。サポートされるバージョンの組み合わせについての詳細は、Support Matrix for OpenShift Container Platform on RHV を参照してください。
データセンター、クラスター、およびストレージを検査します。
-
RHV 管理ポータルで、Compute
Data Centers をクリックします。 - OpenShift Container Platform をインストールする予定のデータセンターにアクセスできることを確認します。
- そのデータセンターの名前をクリックします。
- データセンターの詳細の Storage タブで、OpenShift Container Platform をインストールする予定のストレージドメインが Active であることを確認します。
- 後で使用できるように ドメイン名 を記録します。
- 空き領域 に 230 GiB 以上あることを確認します。
- ストレージドメインが これらの etcd バックエンドのパフォーマンス要件 を満たしていることを確認します。これは、fio パフォーマンスベンチマークツールを使用して測定できます。
- データセンターの詳細で、Clusters タブをクリックします。
- OpenShift Container Platform をインストールする予定の RHV クラスターを見つけます。後で使用できるようにクラスター名を記録します。
-
RHV 管理ポータルで、Compute
RHV ホストリソースを確認します。
- RHV 管理ポータルで、Compute > Clusters をクリックします。
- OpenShift Container Platform をインストールする予定のクラスターをクリックします。
- クラスターの詳細で、Hosts タブをクリックします。
- ホストを検査し、それらに OpenShift Container Platform クラスター 専用 として利用可能な 論理 CPU コア の合計が 28 つ以上であることを確認します。
- 後で使用できるように、利用可能な 論理 CPU コア の数を記録します。
- これらの CPU コアが分散され、インストール時に作成された 7 つの仮想マシンのそれぞれに 4 つのコアを持たせることができることを確認します。
ホストには、以下の OpenShift Container Platform マシンのそれぞれの要件を満たすように 新規仮想マシンをスケジュールするための最大空きメモリー として 112 GiB があることを確認します。
- ブートストラップマシンに 16 GiB が必要です。
- 3 つのコントロールプレーンマシンのそれぞれに 16 GiB が必要です。
- 3 つのコンピュートマシンのそれぞれに 16 GiB が必要です。
- 後で使用できるように 新規仮想マシンをスケジュールするための最大空きメモリー の量を記録します。
OpenShift Container Platform をインストールするための仮想ネットワークが RHV Manager の REST API にアクセスできることを確認します。このネットワーク上の仮想マシンから、RHV Manager の REST API に到達するために curl を使用します。
$ curl -k -u <username>@<profile>:<password> \ 1 https://<engine-fqdn>/ovirt-engine/api 2
以下に例を示します。
$ curl -k -u ocpadmin@internal:pw123 \ https://rhv-env.virtlab.example.com/ovirt-engine/api
16.4.5. ユーザーによってプロビジョニングされるインフラストラクチャーのネットワーク要件
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs
でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。
初回の起動時に、マシンには DHCP サーバーを使用して設定される IP アドレス設定、または必要な起動オプションを指定して静的に設定される IP アドレス設定が必要です。ネットワーク設定の確立後に、マシンは HTTP または HTTPS サーバーから Ignition 設定ファイルをダウンロードします。その後、Ignition 設定ファイルは各マシンの正確な状態を設定するために使用されます。Machine Config Operator はインストール後に、新しい証明書やキーの適用など、マシンへの追加の変更を完了します。
クラスターマシンの長期管理に DHCP サーバーを使用することが推奨されます。DHCP サーバーが永続 IP アドレス、DNS サーバー情報、およびホスト名をクラスターマシンに提供するように設定されていることを確認します。
DHCP サービスがユーザーによってプロビジョニングされるインフラストラクチャーで利用できない場合は、IP ネットワーク設定および DNS サーバーのアドレスを RHCOS のインストール時にノードに提供することができます。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始のセクションを参照してください。
Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照します。
ファイアウォール
クラスターが必要なサイトにアクセスできるようにファイアウォールを設定します。
以下も参照してください。
ロードバランサー
レイヤー 4 のロードバランサーを 1 つまたは 2 つ (推奨) 設定します。
-
コントロールプレーンおよびブートストラップマシンのポート
6443
および22623
に対して負荷分散を行います。ポート6443
は Kubernetes API サーバーへのアクセスを提供し、内外で到達可能である必要があります。ポート22623
はクラスター内のノードからアクセスできる必要があります。 -
Ingress ルーターを実行するマシン (通常はデフォルト設定のコンピュートノード) 向けに、ポート
443
および80
に対する負荷分散を行います。いずれのポートもクラスター内外でアクセスできる必要があります。
DNS
インフラストラクチャーで提供される DNS を設定して、主要なコンポーネントとサービスの正しい解決を許可します。1 つのロードバランサーのみを使用する場合、これらの DNS レコードは同じ IP アドレスを参照できます。
-
api.<cluster_name>.<base_domain>
(内部および外部解決) と、コントロールプレーンマシンのロードバランサーを参照するapi-int.<cluster_name>.<base_domain>
(内部解決) の DNS レコードを作成します。 -
Ingress ルーターのロードバランサーを参照する
*.apps.<cluster_name>.<base_domain>
の DNS レコードを作成します。たとえば、コンピュートマシンのポート443
および80
などが含まれます。
16.4.5.1. DHCP を使用したクラスターノードのホスト名の設定
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost
または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
16.4.5.2. ネットワーク接続の要件
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
本セクションでは、必要なポートの詳細を説明します。
接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供するために、すべてのノードにインターネットへのアクセスが必要です。
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリクス |
|
ホストレベルのサービス。 ポート | |
| Kubernetes が予約するデフォルトポート | |
| openshift-sdn | |
UDP |
| VXLAN および Geneve |
| VXLAN および Geneve | |
|
ポート | |
| IPsec IKE パケット | |
| IPsec NAT-T パケット | |
TCP/UDP |
| Kubernetes ノードポート |
ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
ユーザーによってプロビジョニングされるインフラストラクチャーの NTP 設定
OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、またはクラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。
DHCP サーバーが NTP サーバー情報を提供する場合、Red Hat Enterprise Linux CoreOS (RHCOS) マシンの chrony タイムサービスは情報を読み取り、NTP サーバーとクロックを同期できます。
16.4.6. インストールマシンの設定
バイナリー openshift-install
インストールプログラムおよび Ansible スクリプトを実行するには、Manager 上の RHV 環境および REST API にネットワークでアクセスできるように、RHV Manager または Red Hat Enterprise Linux (RHEL) を設定します。
手順
Python3 および Ansible を更新またはインストールします。以下に例を示します。
# dnf update python3 ansible
-
python3-ovirt-engine-sdk4
パッケージをインストール して、Python Software Development Kit を取得します。 ovirt.image-template
Ansible ロールをインストールします。RHV Manager およびその他の Red Hat Enterprise Linux (RHEL) マシンでは、このロールはovirt-ansible-image-template
パッケージとして提供されます。たとえば、 以下を入力します。# dnf install ovirt-ansible-image-template
ovirt.vm-infra
Ansible ロールをインストールします。RHV Manager およびその他の RHEL マシンでは、このロールはovirt-ansible-vm-infra
パッケージとして提供されます。# dnf install ovirt-ansible-vm-infra
環境変数を作成し、その環境変数に絶対パスまたは相対パスを割り当てます。たとえば、 以下を入力します。
$ export ASSETS_DIR=./wrk
注記インストールプログラムはこの変数を使用して、重要なインストール関連のファイルを保存するディレクトリーを作成します。その後、インストールプロセスはこの変数を再利用して、これらのアセットファイルを見つけます。このアセットディレクトリーを削除しないでください。これは、クラスターのアンインストールに必要になります。
16.4.7. OpenShift Container Platform OpenStack クラスターの RHV への非セキュアモードでのインストール
デフォルトで、インストーラーは CA 証明書を作成し、確認を求めるプロンプトを出し、インストール時に使用する証明書を保存します。これは、手動で作成したりインストールしたりする必要はありません。
推奨されていませんが、OpenShift Container Platform を RHV に 非セキュアモード でインストールして、この機能を上書きし、証明書の検証なしに OpenShift Container Platform をインストールすることができます。
非セキュア モードでのインストールは推奨されていません。これにより、攻撃者が中間者 (Man-in-the-Middle) 攻撃を実行し、ネットワーク上の機密の認証情報を取得できる可能性が生じるためです。
手順
-
~/.ovirt/ovirt-config.yaml
という名前のファイルを作成します。 以下の内容を
ovirt-config.yaml
に追加します。ovirt_url: https://ovirt.example.com/ovirt-engine/api 1 ovirt_fqdn: ovirt.example.com 2 ovirt_pem_url: "" ovirt_username: ocpadmin@internal ovirt_password: super-secret-password 3 ovirt_insecure: true
- インストーラーを実行します。
16.4.8. クラスターノードの SSH アクセス用のキーペアの生成
OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core
ユーザーの ~/.ssh/authorized_keys
一覧に追加され、パスワードなしの認証が可能になります。
キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core
として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。
インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。 /openshift-install gather
コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
- 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記FIPS で検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)"
出力例
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。$ ssh-add <path>/<file_name> 1
- 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
16.4.9. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使ってログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
選択するインストールタイプのページに移動し、オペレーティングシステムのインストールプログラムをダウンロードし、ファイルをインストール設定ファイルを保存するディレクトリーに配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
16.4.10. Ansible Playbook のダウンロード
RHV に OpenShift Container Platform バージョン 4.9 をインストールするために Ansible Playbook をダウンロードします。
手順
インストールマシンで、以下のコマンドを実行します。
$ mkdir playbooks
$ cd playbooks
$ curl -s -L -X GET https://api.github.com/repos/openshift/installer/contents/upi/ovirt?ref=release-4.9 | grep 'download_url.*\.yml' | awk '{ print $2 }' | sed -r 's/("|",)//g' | xargs -n 1 curl -O
次のステップ
-
これらの Ansible Playbook をダウンロードしたら、インストールプログラムを実行してインストール設定ファイルを作成する前に、アセットディレクトリーの環境変数を作成し、
inventory.yml
ファイルをカスタマイズする必要もあります。
16.4.11. inventory.yml ファイル
inventory.yml
ファイルを使用して、インストールする OpenShift Container Platform クラスターの各種の要素を定義し、作成します。これには、Red Hat Enterprise Linux CoreOS(RHCOS) イメージ、仮想マシンテンプレート、ブートストラップマシン、コントロールプレーンノード、ワーカーノードなどの要素が含まれます。また、inventory.yml
を使用してクラスターを破棄します。
以下の inventory.yml
の例は、パラメーターとそれらのデフォルト値を示しています。これらのデフォルト値の量と数は、RHV 環境で実稼働用の OpenShift Container Platform クラスターを実行するための要件を満たしています。
inventory.yml
ファイルの例
--- all: vars: ovirt_cluster: "Default" ocp: assets_dir: "{{ lookup('env', 'ASSETS_DIR') }}" ovirt_config_path: "{{ lookup('env', 'HOME') }}/.ovirt/ovirt-config.yaml" # --- # {op-system} section # --- rhcos: image_url: "https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.9/latest/rhcos-openstack.x86_64.qcow2.gz" local_cmp_image_path: "/tmp/rhcos.qcow2.gz" local_image_path: "/tmp/rhcos.qcow2" # --- # Profiles section # --- control_plane: cluster: "{{ ovirt_cluster }}" memory: 16GiB sockets: 4 cores: 1 template: rhcos_tpl operating_system: "rhcos_x64" type: high_performance graphical_console: headless_mode: false protocol: - spice - vnc disks: - size: 120GiB name: os interface: virtio_scsi storage_domain: depot_nvme nics: - name: nic1 network: lab profile: lab compute: cluster: "{{ ovirt_cluster }}" memory: 16GiB sockets: 4 cores: 1 template: worker_rhcos_tpl operating_system: "rhcos_x64" type: high_performance graphical_console: headless_mode: false protocol: - spice - vnc disks: - size: 120GiB name: os interface: virtio_scsi storage_domain: depot_nvme nics: - name: nic1 network: lab profile: lab # --- # Virtual machines section # --- vms: - name: "{{ metadata.infraID }}-bootstrap" ocp_type: bootstrap profile: "{{ control_plane }}" type: server - name: "{{ metadata.infraID }}-master0" ocp_type: master profile: "{{ control_plane }}" - name: "{{ metadata.infraID }}-master1" ocp_type: master profile: "{{ control_plane }}" - name: "{{ metadata.infraID }}-master2" ocp_type: master profile: "{{ control_plane }}" - name: "{{ metadata.infraID }}-worker0" ocp_type: worker profile: "{{ compute }}" - name: "{{ metadata.infraID }}-worker1" ocp_type: worker profile: "{{ compute }}" - name: "{{ metadata.infraID }}-worker2" ocp_type: worker profile: "{{ compute }}"
Enter から始まる説明のあるパラメーターの値を入力します。 それ以外の場合は、デフォルト値を使用するか、またはこえを新しい値に置き換えることができます。
General セクション
-
ovirt_cluster
: OpenShift Container Platform クラスターをインストールする既存の RHV クラスターの名前を入力します。 -
ocp.assets_dir
:openshift-install
インストールプログラムが生成するファイルを保存するために作成するディレクトリーのパス。 -
ocp.ovirt_config_path
: インストールプログラムが生成するovirt-config.yaml
ファイルのパス (./wrk/install-config.yaml
など)。このファイルには、Manager の REST API との対話に必要な認証情報が含まれます。
Red Hat Enterprise Linux CoreOS (RHCOS) セクション
-
image_url
: ダウンロード用に指定した RHCOS イメージの URL を入力します。 -
local_cmp_image_path
: 圧縮された RHCOS イメージのローカルダウンロードディレクトリーのパス。 -
local_image_path
: 展開した RHCOS イメージのローカルディレクトリーのパス。
Profiles セクション
このセクションは、2 つのプロファイルで設定されます。
-
control_plane
: ブートストラップおよびコントロールプレーンノードのプロファイル。 -
compute
: コンピュートプレーン内のワーカーノードのプロファイル。
これらのプロファイルには以下のパラメーターが含まれます。パラメーターのデフォルト値は、実稼働クラスターを実行するために必要な最小要件を満たします。これらの値は、ワークロードの要件に応じて増減したり、カスタマイズしたりできます。
-
cluster
: 値は、General セクションのovirt_cluster
からクラスター名を取得します。 -
memory
: 仮想マシンに必要なメモリーの量 (GB)。 -
sockets
: 仮想マシンのソケット数。 -
cores
: 仮想マシンのコア数。 -
template
: 仮想マシンテンプレートの名前。複数のクラスターをインストールする計画があり、これらのクラスターが異なる仕様が含まれるテンプレートを使用する場合には、テンプレート名の先頭にクラスターの ID を付けます。 -
operating_system
: 仮想マシンのゲストオペレーティングシステムのタイプ。oVirt/RHV バージョン 4.4 では、Ignition script
の値を仮想マシンに渡すことができるようにするために、この値をrhcos_x64
にする必要があります。 type
: 仮想マシンのタイプとしてserver
を入力します。重要type
パラメーターの値をhigh_performance
からserver
に変更する必要があります。-
disks
: ディスクの仕様。control_plane
とcompute
ノードには、異なるストレージドメインを設定できます。 -
size
: ディスクの最小サイズ。 -
name
: RHV のターゲットクラスターに接続されたディスクの名前を入力します。 -
interface
: 指定したディスクのインターフェイスタイプを入力します。 -
storage_domain
: 指定したディスクのストレージドメインを入力します。 -
nics
: 仮想マシンが使用するname
およびnetwork
を入力します。仮想ネットワークインターフェイスプロファイルを指定することもできます。デフォルトでは、NIC は oVirt/RHV MAC プールから MAC アドレスを取得します。
仮想マシンセクション
この最後のセクション vms
は、クラスターで作成およびデプロイする予定の仮想マシンを定義します。デフォルトで、実稼働環境用の最小数のコントロールプレーンおよびワーカーノードが提供されます。
vms
には 3 つの必須要素が含まれます。
-
name
: 仮想マシンの名前。この場合、metadata.infraID
は、仮想マシン名の先頭にmetadata.yml
ファイルのインフラストラクチャー ID を付けます。 -
ocp_type
: OpenShift Container Platform クラスター内の仮想マシンのロール。使用できる値はbootstrap
、master
、worker
です。 profile
: それぞれの仮想マシンが仕様を継承するプロファイルの名前。この例で使用可能な値はcontrol_plane
またはcompute
です。仮想マシンがプロファイルから継承する値を上書きできます。これを実行するには、
inventory.yml
の仮想マシンに profile 属性の名前を追加し、これに上書きする値を割り当てます。この例を確認するには、直前のinventory.yml
の例のname: "{{ metadata.infraID }}-bootstrap"
仮想マシンを検査します。これには値がserver
のtype
属性があり、この仮想マシンがそれ以外の場合にcontrol_plane
プロファイルから継承するtype
属性の値を上書きします。
メタデータ変数
仮想マシンの場合、metadata.infraID
は、仮想マシンの名前の先頭に、Ignition ファイルのビルド時に作成する metadata.json
ファイルのインフラストラクチャー ID を付けます。
Playbook は以下のコードを使用して、ocp.assets_dir
にある特定のファイルから infraID
を読み取ります。
--- - name: include metadata.json vars include_vars: file: "{{ ocp.assets_dir }}/metadata.json" name: metadata ...
16.4.12. RHCOS イメージ設定の指定
inventory.yml
ファイルの Red Hat Enterprise Linux CoreOS (RHCOS) イメージ設定を更新します。後にこのファイルを Playbook のいずれかとして実行すると、圧縮された Red Hat Enterprise Linux CoreOS (RHCOS) イメージが image_url
URL から local_cmp_image_path
ディレクトリーにダウンロードされます。次に Playbook はイメージを local_image_path
ディレクトリーに展開し、これを使用して oVirt/RHV テンプレートを作成します。
手順
- インストールする OpenShift Container Platform バージョンの RHCOS イメージダウンロードページを見つけます (例: /pub/openshift-v4/dependencies/rhcos/latest/latest のインデックス)。
-
このダウンロードページから、OpenStack
qcow2
イメージの URL (https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.9/latest/rhcos-openstack.x86_64.qcow2.gz
など) をコピーします。 先のステップでダウンロードした
inventory.yml
Playbook を編集します。この中で、URL をimage_url
の値として貼り付けます。以下に例を示します。rhcos: "https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.9/latest/rhcos-openstack.x86_64.qcow2.gz"
16.4.13. インストール設定ファイルの作成
インストールプログラム openshift-install
を実行し、先に指定または収集した情報でプロンプトに応答し、インストール設定ファイルを作成します。
プロンプトに応答すると、インストールプログラムは、以前に指定したアセットディレクトリーの install-config.yaml
ファイルの初期バージョンを作成します (例: ./wrk/install-config.yaml
)。
インストールプログラムは、Manager に到達して REST API を使用するために必要なすべての接続パラメーターが含まれる $HOME/.ovirt/ovirt-config.yaml
ファイルも作成します。
注: インストールプロセスでは、Internal API virtual IP
および Ingress virtual IP
などの一部のパラメーターに指定する値を使用しません。それらの値はインフラストラクチャー DNS にすでに設定されているためです。
また、oVirt cluster
、 oVirt storage
、および oVirt network
などの値のような inventory.yml
のパラメーターに指定する値を使用します。また、スクリプトを使用して install-config.yaml
の同じ値を削除するか、またはこれを前述の virtual IPs
に置き換えます。
手順
インストールプログラムを実行します。
$ openshift-install create install-config --dir $ASSETS_DIR
インストールプログラムのプロンプトに応答し、システムに関する情報を提供します。
出力例
? SSH Public Key /home/user/.ssh/id_dsa.pub ? Platform <ovirt> ? Engine FQDN[:PORT] [? for help] <engine.fqdn> ? Enter ovirt-engine username <ocpadmin@internal> ? Enter password <******> ? oVirt cluster <cluster> ? oVirt storage <storage> ? oVirt network <net> ? Internal API virtual IP <172.16.0.252> ? Ingress virtual IP <172.16.0.251> ? Base Domain <example.org> ? Cluster Name <ocp4> ? Pull Secret [? for help] <********>
? SSH Public Key /home/user/.ssh/id_dsa.pub ? Platform <ovirt> ? Engine FQDN[:PORT] [? for help] <engine.fqdn> ? Enter ovirt-engine username <ocpadmin@internal> ? Enter password <******> ? oVirt cluster <cluster> ? oVirt storage <storage> ? oVirt network <net> ? Internal API virtual IP <172.16.0.252> ? Ingress virtual IP <172.16.0.251> ? Base Domain <example.org> ? Cluster Name <ocp4> ? Pull Secret [? for help] <********>
Internal API virtual IP
および Ingress virtual IP
について、DNS サービスの設定時に指定した IP アドレスを指定します。
さらに、oVirt cluster
および Base Domain
プロンプトに対して入力する値は REST API および作成するアプリケーションの URL の一部を設定します (例: https://api.ocp4.example.org:6443/
and https://console-openshift-console.apps.ocp4.example.org
)。
16.4.14. install-config.yaml のカスタマイズ
ここでは、3 つの python スクリプトを使用して、インストールプログラムのデフォルト動作の一部を上書きします。
- デフォルトでは、インストールプログラムはマシン API を使用してノードを作成します。このデフォルトの動作を上書きするには、コンピュートノードの数をゼロ (0) レプリカに設定します。後に Ansible Playbook を使用してコンピュートノードを作成します。
- デフォルトでは、インストールプログラムはノードのマシンネットワークの IP 範囲を設定します。このデフォルトの動作を上書きするには、インフラストラクチャーに一致するように IP 範囲を設定します。
-
デフォルトでは、インストールプログラムはプラットフォームを
ovirt
に設定します。ただし、ユーザーによってプロビジョニングされるインフラストラクチャーにクラスターをインストールすることは、ベアメタルにクラスターをインストールすることに似ています。したがって、ovirt プラットフォームセクションをinstall-config.yaml
から削除し、プラットフォームをnone
に変更します。代わりに、inventory.yml
を使用して、必要な設定をすべて指定します。
これらのスニペットは Python 3 および Python 2 で動作します。
手順
コンピュートノードの数をゼロ (0) レプリカに設定します。
$ python3 -c 'import os, yaml path = "%s/install-config.yaml" % os.environ["ASSETS_DIR"] conf = yaml.safe_load(open(path)) conf["compute"][0]["replicas"] = 0 open(path, "w").write(yaml.dump(conf, default_flow_style=False))'
マシンネットワークの IP 範囲を設定します。たとえば、範囲を
172.16.0.0/16
に設定するには、以下を実行します。$ python3 -c 'import os, yaml path = "%s/install-config.yaml" % os.environ["ASSETS_DIR"] conf = yaml.safe_load(open(path)) conf["networking"]["machineNetwork"][0]["cidr"] = "172.16.0.0/16" open(path, "w").write(yaml.dump(conf, default_flow_style=False))'
ovirt
セクションを削除し、プラットフォームをnone
に変更します。$ python3 -c 'import os, yaml path = "%s/install-config.yaml" % os.environ["ASSETS_DIR"] conf = yaml.safe_load(open(path)) platform = conf["platform"] del platform["ovirt"] platform["none"] = {} open(path, "w").write(yaml.dump(conf, default_flow_style=False))'
警告Red Hat Virtualization は現在、oVirt プラットフォーム上にあるユーザーによってプロビジョニングされるインフラストラクチャーでのインストールをサポートしていません。そのため、プラットフォームを
none
に設定し、OpenShift Container Platform が各ノードをベアメタルノードとして、およびクラスターをベアメタルクラスターとして識別できるようにします。これは、任意のプラットフォームにクラスターをインストールする のと同じであり、次の制限があります。- クラスタープロバイダーがないため、各マシンを手動で追加する必要があり、ノードスケーリング機能はありません。
- oVirt CSI ドライバーはインストールされず、CSI 機能はありません。
16.4.15. マニフェストファイルの生成
インストールプログラムを使用して、アセットディレクトリーにマニフェストファイルのセットを生成します。
マニフェストファイルを生成するコマンドにより、install-config.yaml
ファイルを使用する前に警告メッセージが表示されます。
install-config.yaml
ファイルを再利用する予定の場合には、マニフェストファイルを生成する前にバックアップしてからバックアップコピーを作成してください。
手順
オプション:
install-config.yaml
ファイルのバックアップコピーを作成します。$ cp install-config.yaml install-config.yaml.backup
アセットディレクトリーにマニフェストのセットを生成します。
$ openshift-install create manifests --dir $ASSETS_DIR
このコマンドにより、以下の情報が表示されます。
出力例
INFO Consuming Install Config from target directory WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings
このコマンドにより、以下のマニフェストファイルが生成されます。
出力例
$ tree . └── wrk ├── manifests │ ├── 04-openshift-machine-config-operator.yaml │ ├── cluster-config.yaml │ ├── cluster-dns-02-config.yml │ ├── cluster-infrastructure-02-config.yml │ ├── cluster-ingress-02-config.yml │ ├── cluster-network-01-crd.yml │ ├── cluster-network-02-config.yml │ ├── cluster-proxy-01-config.yaml │ ├── cluster-scheduler-02-config.yml │ ├── cvo-overrides.yaml │ ├── etcd-ca-bundle-configmap.yaml │ ├── etcd-client-secret.yaml │ ├── etcd-host-service-endpoints.yaml │ ├── etcd-host-service.yaml │ ├── etcd-metric-client-secret.yaml │ ├── etcd-metric-serving-ca-configmap.yaml │ ├── etcd-metric-signer-secret.yaml │ ├── etcd-namespace.yaml │ ├── etcd-service.yaml │ ├── etcd-serving-ca-configmap.yaml │ ├── etcd-signer-secret.yaml │ ├── kube-cloud-config.yaml │ ├── kube-system-configmap-root-ca.yaml │ ├── machine-config-server-tls-secret.yaml │ └── openshift-config-secret-pull-secret.yaml └── openshift ├── 99_kubeadmin-password-secret.yaml ├── 99_openshift-cluster-api_master-user-data-secret.yaml ├── 99_openshift-cluster-api_worker-user-data-secret.yaml ├── 99_openshift-machineconfig_99-master-ssh.yaml ├── 99_openshift-machineconfig_99-worker-ssh.yaml └── openshift-install-manifests.yaml
次のステップ
- コントロールプレーンノードをスケジュール対象外にします。
16.4.16. コントロールプレーンノードのスケジュール対象外の設定
コントロールプレーンマシンを手動で作成し、デプロイしているので、コントロールプレーンノードをスケジュール対象外にするようにマニフェストファイルを設定する必要があります。
手順
コントロールプレーンノードをスケジュール対象外にするには、以下を入力します。
$ python3 -c 'import os, yaml path = "%s/manifests/cluster-scheduler-02-config.yml" % os.environ["ASSETS_DIR"] data = yaml.safe_load(open(path)) data["spec"]["mastersSchedulable"] = False open(path, "w").write(yaml.dump(data, default_flow_style=False))'
16.4.17. Ignition ファイルのビルド
生成および変更したマニフェストファイルから Ignition ファイルを作成するには、インストールプログラムを実行します。このアクションにより、Ignition ファイルをフェッチし、ノードを作成するために必要な設定を実行する Red Hat Enterprise Linux CoreOS (RHCOS) マシン initramfs
が作成されます。
Ignition ファイルのほかに、インストールプログラムは以下を生成します。
-
oc
およびkubectl
ユーティリティーを使用してクラスターに接続するための管理者認証情報が含まれるauth
ディレクトリー。 -
OpenShift Container Platform クラスター名、クラスター ID、および現行インストールのインフラストラクチャー ID などの情報を含む
metadata.json
ファイル。
このインストールプロセスの Ansible Playbook は、infraID
の値を、作成する仮想マシンの接頭辞として使用します。これにより、同じ oVirt/RHV クラスターに複数のインストールがある場合の命名の競合が回避されます。
Ignition 設定ファイルの証明書は 24 時間後に有効期限が切れます。最初の証明書のローテーションが終了するように、クラスターのインストールを完了し、クラスターを動作が低下していない状態で 24 時間実行し続ける必要があります。
手順
Ignition ファイルをビルドするには、以下を入力します。
$ openshift-install create ignition-configs --dir $ASSETS_DIR
出力例
$ tree . └── wrk ├── auth │ ├── kubeadmin-password │ └── kubeconfig ├── bootstrap.ign ├── master.ign ├── metadata.json └── worker.ign
16.4.18. テンプレートおよび仮想マシンの作成
inventory.yml
の変数を確認した後に、最初の Ansible プロビジョニング Playbook create-templates-and-vms.yml
を実行します。
この Playbook は、$HOME/.ovirt/ovirt-config.yaml
から RHV Manager の接続パラメーターを使用し、アセットディレクトリーで metadata.json
を読み取ります。
ローカルの Red Hat Enterprise Linux CoreOS (RHCOS) イメージが存在しない場合、Playbook は inventory.yml
の image_url
に指定した URL からダウンロードします。これはイメージを展開し、これを RHV にアップロードしてテンプレートを作成します。
Playbook は、inventory.yml
ファイルの control_plane
と compute
プロファイルに基づいてテンプレートを作成します。これらのプロファイルの名前が異なる場合、2 つのテンプレートが作成されます。
Playbook が完了すると、作成される仮想マシンは停止します。他のインフラストラクチャー要素の設定に役立つ情報を取得できます。たとえば、仮想マシンの MAC アドレスを取得して、仮想マシンに永続的な IP アドレスを割り当てるように DHCP を設定できます。
手順
-
inventory.yml
のcontrol_plane
およびcompute
変数で、type: high_performance
の 両方のインスタンスをtype: server
に変更します。 オプション: 同じクラスターに複数のインストールを実行する予定の場合には、OpenShift Container Platform インストールごとに異なるテンプレートを作成します。
inventory.yml
ファイルで、template
の値の先頭にinfraID
を付けます。以下に例を示します。control_plane: cluster: "{{ ovirt_cluster }}" memory: 16GiB sockets: 4 cores: 1 template: "{{ metadata.infraID }}-rhcos_tpl" operating_system: "rhcos_x64" ...
テンプレートおよび仮想マシンを作成します。
$ ansible-playbook -i inventory.yml create-templates-and-vms.yml
16.4.19. ブートストラップマシンの作成
bootstrap.yml
Playbook を実行してブートストラップマシンを作成します。この Playbook はブートストラップ仮想マシンを起動し、これをアセットディレクトリーから bootstrap.ign
Ignition ファイルに渡します。ブートストラップノードは、Ignition ファイルをコントロールプレーンノードに送信できるように設定します。
ブートストラッププロセスをモニターするには、RHV 管理ポータルでコンソールを使用するか、SSH を使用して仮想マシンに接続します。
手順
ブートストラップマシンを作成します。
$ ansible-playbook -i inventory.yml bootstrap.yml
管理ポータルまたは SSH のコンソールを使用してブートストラップマシンに接続します。
<bootstrap_ip>
をブートストラップノードの IP アドレスに置き換えます。SSH を使用するには、以下を入力します。$ ssh core@<boostrap.ip>
ブートストラップノードからリリースイメージサービスについての
bootkube.service
journald ユニットログを収集します。[core@ocp4-lk6b4-bootstrap ~]$ journalctl -b -f -u release-image.service -u bootkube.service
注記ブートストラップノードの
bootkube.service
のログは etcd のconnection refused
エラーを出力し、ブートストラップサーバーがコントロールプレーンノードの etcd に接続できないことを示します。etcd が各コントロールプレーンノードで起動し、ノードがクラスターに参加した後には、エラーは発生しなくなるはずです。
16.4.20. コントロールプレーンノードの作成
masters.yml
Playbook を実行してコントロールプレーンノードを作成します。この Playbook は master.ign
Ignition ファイルをそれぞれの仮想マシンに渡します。Ignition ファイルには、https://api-int.ocp4.example.org:22623/config/master
などの URL から Ignition を取得するためのコントロールプレーンノードのディレクティブが含まれます。この URL のポート番号はロードバランサーによって管理され、クラスター内でのみアクセスできます。
手順
コントロールプレーンノードを作成します。
$ ansible-playbook -i inventory.yml masters.yml
Playbook がコントロールプレーンを作成する間に、ブートストラッププロセスをモニターします。
$ openshift-install wait-for bootstrap-complete --dir $ASSETS_DIR
出力例
INFO API v1.22.1 up INFO Waiting up to 40m0s for bootstrapping to complete...
コントロールプレーンノードおよび etcd のすべての Pod が実行されている場合、インストールプログラムは以下の出力を表示します。
出力例
INFO It is now safe to remove the bootstrap resources
16.4.21. クラスターステータスの確認
インストール時またはインストール後に OpenShift Container Platform クラスターのステータスを確認することができます。
手順
クラスター環境で、管理者の kubeconfig ファイルをエクスポートします。
$ export KUBECONFIG=$ASSETS_DIR/auth/kubeconfig
kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。デプロイメント後に作成されたコントロールプレーンおよびコンピュートマシンを表示します。
$ oc get nodes
クラスターのバージョンを表示します。
$ oc get clusterversion
Operator のステータスを表示します。
$ oc get clusteroperator
クラスター内のすべての実行中の Pod を表示します。
$ oc get pods -A
16.4.22. ブートストラップマシンの削除
wait-for
コマンドがブートストラッププロセスが完了したことを示していることを確認したら、ブートストラップ仮想マシンを削除してコンピュート、メモリー、およびストレージリソースを解放する必要があります。また、ロードバランサーディレクティブからブートストラップマシンの設定を削除します。
手順
クラスターからブートストラップマシンを削除するには、以下を実行します。
$ ansible-playbook -i inventory.yml retire-bootstrap.yml
- ロードバランサーディレクティブからブートストラップマシンの設定を削除します。
16.4.23. ワーカーノードの作成およびインストールの完了
ワーカーノードの作成は、コントロールプレーンノードの作成と同様です。ただし、ワーカーノードはクラスターに自動的に参加しません。これらをクラスターに追加するには、ワーカーの保留状態の CSR(証明書署名要求) を確認し、承認します。
最初の要求の承認後に、ワーカーノードがすべて承認されるまで CSR の承認を継続します。このプロセスが完了すると、ワーカーノードは Ready
になり、Pod がそれらで実行されるようにスケジュールできます。
最後に、コマンドラインを監視し、インストールプロセスが完了するタイミングを確認します。
手順
ワーカーノードを作成します。
$ ansible-playbook -i inventory.yml workers.yml
すべての CSR を一覧表示するには、以下を入力します。
$ oc get csr -A
最終的に、このコマンドはノードごとに 1 つの CSR を表示します。以下に例を示します。
出力例
NAME AGE SIGNERNAME REQUESTOR CONDITION csr-2lnxd 63m kubernetes.io/kubelet-serving system:node:ocp4-lk6b4-master0.ocp4.example.org Approved,Issued csr-hff4q 64m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued csr-hsn96 60m kubernetes.io/kubelet-serving system:node:ocp4-lk6b4-master2.ocp4.example.org Approved,Issued csr-m724n 6m2s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-p4dz2 60m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued csr-t9vfj 60m kubernetes.io/kubelet-serving system:node:ocp4-lk6b4-master1.ocp4.example.org Approved,Issued csr-tggtr 61m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued csr-wcbrf 7m6s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending
一覧をフィルターし、保留中の CSR のみを表示するには、以下を実行します。
$ watch "oc get csr -A | grep pending -i"
このコマンドは 2 秒ごとに出力を更新し、保留中の CSR のみを表示します。以下に例を示します。
出力例
Every 2.0s: oc get csr -A | grep pending -i csr-m724n 10m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-wcbrf 11m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending
保留中のそれぞれの要求を検査します。以下に例を示します。
出力例
$ oc describe csr csr-m724n
出力例
Name: csr-m724n Labels: <none> Annotations: <none> CreationTimestamp: Sun, 19 Jul 2020 15:59:37 +0200 Requesting User: system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Signer: kubernetes.io/kube-apiserver-client-kubelet Status: Pending Subject: Common Name: system:node:ocp4-lk6b4-worker1.ocp4.example.org Serial Number: Organization: system:nodes Events: <none>
CSR 情報が正しい場合は、要求を承認します。
$ oc adm certificate approve csr-m724n
インストールプロセスが完了するまで待機します。
$ openshift-install wait-for install-complete --dir $ASSETS_DIR --log-level debug
インストールが完了すると、コマンドラインには OpenShift Container Platform Web コンソールの URL と、管理者のユーザー名およびパスワードが表示されます。
16.4.24. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.9 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニターリング について参照してください。