15.6. 独自のインフラストラクチャーでの Kuryr を使用する OpenStack へのクラスターのインストール
OpenShift Container Platform バージョン 4.9 では、ユーザーによってプロビジョニングされたインフラストラクチャーを実行するクラスターを Red Hat OpenStack Platform (RHOSP) にインストールできます。
独自のインフラストラクチャーを使用することで、クラスターを既存のインフラストラクチャーおよび変更と統合できます。このプロセスでは、インストーラーでプロビジョニングされるインストールの場合よりも多くの手作業が必要になります。Nova サーバー、Neutron ポート、セキュリティーグループなどのすべての RHOSP リソースを作成する必要があるためです。ただし、Red Hat では、デプロイメントプロセスを支援する Ansible Playbook を提供しています。
15.6.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスについての詳細を確認している。
- クラスターンストール方法の選択およびそのユーザー向けの準備 を確認している。
- OpenShift クラスターでサポートされるプラットフォーム のセクションを参照し、OpenShift Container Platform 4.9 がお使いの RHOSP バージョンと互換性があることを確認している。RHOSP サポートマトリックスの OpenShift Container Platform を参照して、プラットフォームのサポートを異なるバージョン間で比較することもできます。
- OpenShift Container Platform のインストール先に RHOSP アカウントがある。
インストールプログラムを実行するマシンには、以下が含まれる。
- インストールプロセス時に作成したファイルを保持できる単一ディレクトリー
- Python 3
15.6.2. Kuryr SDN について
Kuryr は、Neutron および Octavia Red Hat OpenStack Platform (RHOSP) サービスを使用して Pod およびサービスのネットワークを提供する Container Network Interface (CNI) プラグインです。
Kuryr と OpenShift Container Platform の統合は主に、RHOSP の仮想マシンで実行する OpenShift Container Platform クラスター用に設計されました。Kuryr は、OpenShift Container Platform Pod を RHOSP SDN にプラグインしてネットワークのパフォーマンスを強化します。さらに、これは Pod と RHOSP 仮想インスタンス間の接続を可能にします。
Kuryr コンポーネントは openshift-kuryr
namespace を使用して OpenShift Container Platform の Pod としてインストールされます。
-
kuryr-controller
:master
ノードにインストールされる単一のサービスインスタンスです。これは、OpenShift Container Platform でDeployment
としてモデリングされます。 -
kuryr-cni
: 各 OpenShift Container Platform ノードで Kuryr を CNI ドライバーとしてインストールし、設定するコンテナーです。これは、OpenShift Container Platform でDaemonSet
オブジェクトとしてモデリングされます。
Kuryr コントローラーは OpenShift Container Platform API サーバーで Pod、サービスおよび namespace の作成、更新、および削除イベントについて監視します。これは、OpenShift Container Platform API 呼び出しを Neutron および Octavia の対応するオブジェクトにマップします。そのため、Neutron トランクポート機能を実装するすべてのネットワークソリューションを使用して、Kuryr 経由で OpenShift Container Platform をサポートすることができます。これには、Open vSwitch (OVS) および Open Virtual Network (OVN) などのオープンソースソリューションや Neutron と互換性のある市販の SDN が含まれます。
Kuryr は、カプセル化された RHOSP テナントネットワーク上の OpenShift Container Platform デプロイメントに使用することが推奨されています。これは、 RHOSP ネットワークでカプセル化された OpenShift Container Platform SDN を実行するなど、二重のカプセル化を防ぐために必要です。
プロバイダーネットワークまたはテナント VLAN を使用する場合は、二重のカプセル化を防ぐために Kuryr を使用する必要はありません。パフォーマンス上の利点はそれほど多くありません。ただし、設定によっては、Kuryr を使用して 2 つのオーバーレイが使用されないようにすることには利点がある場合があります。
Kuryr は、以下のすべての基準が true であるデプロイメントでは推奨されません。
- RHOSP のバージョンが 16 よりも前のバージョンである。
- デプロイメントで UDP サービスが使用されているか、または少数のハイパーバイザーで多数の TCP サービスが使用されている。
または、以下を実行します。
-
ovn-octavia
Octavia ドライバーが無効にされている。 - デプロイメントで、少数のハイパーバイザーで多数の TCP サービスが使用されている。
15.6.3. Kuryr を使用して OpenShift Container Platform を RHOSP にインストールするためのリソースのガイドライン
Kuryr SDN を使用する場合、Pod、サービス、namespace およびネットワークポリシーは RHOSP クォータのリソースを使用します。これにより、最小要件が増加します。また、Kuryr にはデフォルトインストールに必要な要件以外の追加要件があります。
以下のクォータを使用してデフォルトのクラスターの最小要件を満たすようにします。
リソース | 値 |
---|---|
Floating IP アドレス | 3: LoadBalancer タイプに予想されるサービス数 |
ポート | 1500: Pod ごとに 1 つ必要 |
ルーター | 1 |
サブネット | 250: namespace/プロジェクトごとに 1 つ必要 |
ネットワーク | 250: namespace/プロジェクトごとに 1 つ必要 |
RAM | 112 GB |
vCPU | 28 |
ボリュームストレージ | 275 GB |
インスタンス | 7 |
セキュリティーグループ | 250: サービスおよび NetworkPolicy ごとに 1 つ必要 |
セキュリティーグループルール | 1000 |
ロードバランサー | 100: サービスごとに 1 つ必要 |
ロードバランサーリスナー | 500: サービスで公開されるポートごとに 1 つ必要 |
ロードバランサーノード | 500: サービスで公開されるポートごとに 1 つ必要 |
クラスターは推奨されるリソースよりもリソースが少ない場合にも機能する場合がありますが、その場合のパフォーマンスは保証されません。
RHOSP オブジェクトストレージ (Swift) が利用可能で、swiftoperator
ロールを持つユーザーアカウントによって操作されている場合、これは OpenShift Container Platform イメージレジストリーのデフォルトバックエンドとして使用されます。この場合、ボリュームストレージ要件は 175 GB です。Swift 領域要件は、イメージレジストリーのサイズによって異なります。
OVN Octavia ドライバーではなく Amphora ドライバーで Red Hat OpenStack Platform(RHOSP) バージョン 16 を使用している場合、セキュリティーグループはユーザープロジェクトではなくサービスアカウントに関連付けられます。
リソースを設定する際には、以下の点に注意してください。
- 必要なポート数は Pod 数よりも大きくなる。Kuryr はポートプールを使用して、事前に作成済みのポートを Pod で使用できるようにし、Pod の起動時間を短縮します。
-
各ネットワークポリシーは RHOSP セキュリティーグループにマップされ、
NetworkPolicy
仕様によっては 1 つ以上のルールがセキュリティーグループに追加される。 各サービスは RHOSP ロードバランサーにマップされる。クォータに必要なセキュリティーグループの数を見積もる場合には、この要件を考慮してください。
RHOSP バージョン 15 以前のバージョン、または
ovn-octavia driver
を使用している場合、各ロードバランサーにはユーザープロジェクトと共にセキュリティーグループがあります。クォータはロードバランサーのリソース (VM リソースなど) を考慮しませんが、RHOSP デプロイメントのサイズを決定する際にはこれらのリソースを考慮する必要があります。デフォルトのインストールには 50 を超えるロードバランサーが あり、クラスターはそれらのロードバランサーに対応できる必要があります。
OVN Octavia ドライバーを有効にして RHOSP バージョン 16 を使用している場合は、1 つのロードバランサー仮想マシンのみが生成され、サービスは OVN フロー経由で負荷分散されます。
OpenShift Container Platform デプロイメントは、コントロールプレーンマシン、コンピュートマシン、およびブートストラップマシンで設定されます。
Kuryr SDN を有効にするには、使用する環境が以下の要件を満たしている必要があります。
- RHOSP 13+ を実行します。
- オーバークラウドと Octavia を使用します。
- Neutron トランクポートの拡張を使用します。
-
ML2/OVS Neutron ドライバーが
ovs-hybrid
の代わりに使用れる場合、openvswitch
ファイアウォールドライバーを使用します。
15.6.3.1. クォータの拡大
Kuryr SDN を使用する場合、Pod、サービス、namespace、およびネットワークポリシーが使用する Red Hat OpenStack Platform (RHOSP) リソースに対応するためにクォータを引き上げる必要があります。
手順
以下のコマンドを実行して、プロジェクトのクォータを増やします。
$ sudo openstack quota set --secgroups 250 --secgroup-rules 1000 --ports 1500 --subnets 250 --networks 250 <project>
15.6.3.2. Neutron の設定
Kuryr CNI は Neutron トランクの拡張を使用してコンテナーを Red Hat OpenStack Platform (RHOSP) SDN にプラグインします。したがって、Kuryr が適切に機能するには trunks
拡張を使用する必要があります。
さらにデフォルトの ML2/OVS Neutron ドライバーを使用する場合には、セキュリティーグループがトランクサブポートで実行され、Kuryr がネットワークポリシーを適切に処理できるように、ovs_hybrid
ではなく openvswitch
に設定される必要があります。
15.6.3.3. Octavia の設定
Kuryr SDN は Red Hat OpenStack Platform (RHOSP) の Octavia LBaaS を使用して OpenShift Container Platform サービスを実装します。したがって、Kuryr SDN を使用するように RHOSP に Octavia コンポーネントをインストールし、設定する必要があります。
Octavia を有効にするには、Octavia サービスを RHOSP オーバークラウドのインストール時に組み込むか、またはオーバークラウドがすでに存在する場合は Octavia サービスをアップグレードする必要があります。Octavia を有効にする以下の手順は、オーバークラウドのクリーンインストールまたはオーバークラウドの更新の両方に適用されます。
以下の手順では、Octavia を使用する場合に RHOSP のデプロイメント 時に必要となる主な手順のみを説明します。また、レジストリーメソッド が変更されることにも留意してください。
以下の例では、ローカルレジストリーの方法を使用しています。
手順
ローカルレジストリーを使用している場合、イメージをレジストリーにアップロードするためのテンプレートを作成します。以下に例を示します。
(undercloud) $ openstack overcloud container image prepare \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \ --namespace=registry.access.redhat.com/rhosp13 \ --push-destination=<local-ip-from-undercloud.conf>:8787 \ --prefix=openstack- \ --tag-from-label {version}-{product-version} \ --output-env-file=/home/stack/templates/overcloud_images.yaml \ --output-images-file /home/stack/local_registry_images.yaml
local_registry_images.yaml
ファイルに Octavia イメージが含まれることを確認します。以下に例を示します。... - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-api:13.0-43 push_destination: <local-ip-from-undercloud.conf>:8787 - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-health-manager:13.0-45 push_destination: <local-ip-from-undercloud.conf>:8787 - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-housekeeping:13.0-45 push_destination: <local-ip-from-undercloud.conf>:8787 - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-worker:13.0-44 push_destination: <local-ip-from-undercloud.conf>:8787
注記Octavia コンテナーのバージョンは、インストールされている特定の RHOSP リリースによって異なります。
コンテナーイメージを
registry.redhat.io
からアンダークラウドノードにプルします。(undercloud) $ sudo openstack overcloud container image upload \ --config-file /home/stack/local_registry_images.yaml \ --verbose
これには、ネットワークおよびアンダークラウドディスクの速度に応じて多少の時間がかかる可能性があります。
Octavia ロードバランサーは OpenShift Container Platform API にアクセスするために使用されるため、それらのリスナーの接続のデフォルトタイムアウトを増やす必要があります。デフォルトのタイムアウトは 50 秒です。以下のファイルをオーバークラウドのデプロイコマンドに渡し、タイムアウトを 20 分に増やします。
(undercloud) $ cat octavia_timeouts.yaml parameter_defaults: OctaviaTimeoutClientData: 1200000 OctaviaTimeoutMemberData: 1200000
注記これは RHOSP 13.0.13+ では不要です。
Octavia を使用してオーバークラウドをインストールまたは更新します。
$ openstack overcloud deploy --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \ -e octavia_timeouts.yaml
注記このコマンドには、Octavia に関連付けられたファイルのみが含まれます。これは、RHOSP の特定のインストールによって異なります。詳細は RHOSP のドキュメントを参照してください。Octavia インストールのカスタマイズについての詳細は、Octavia デプロイメントのプランニング を参照してください。
注記Kuryr SDN を利用する際には、オーバークラウドのインストールに Neutron の
trunk
拡張機能が必要です。これは、Director デプロイメントでデフォルトで有効にされます。Neutron バックエンドが ML2/OVS の場合、デフォルトのovs-hybrid
の代わりにopenvswitch
ファイアウォールを使用します。バックエンドが ML2/OVN の場合には変更の必要がありません。RHOSP の 13.0.13 よりも前のバージョンでは、プロジェクトの作成後にプロジェクト ID を
octavia.conf
設定ファイルに追加します。トラフィックが Octavia ロードバランサーを通過する場合など、複数のサービス全体でネットワークポリシーを実行するには、Octavia がユーザープロジェクトで Amphora 仮想マシンセキュリティーグループを作成するようにする必要があります。
この変更により、必要なロードバランサーのセキュリティーグループがそのプロジェクトに属し、それらをサービスの分離を実行するように更新できます。
注記RHOSP の 13.0.13 よりも後のバージョンでは、このタスクは必要ありません。
Octavia は、ロードバランサー VIP へのアクセスを制限する新しい ACL API を実装します。
プロジェクト ID を取得します。
$ openstack project show <project>
出力例
+-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | | | domain_id | default | | enabled | True | | id | PROJECT_ID | | is_domain | False | | name | *<project>* | | parent_id | default | | tags | [] | +-------------+----------------------------------+
プロジェクト ID をコントローラーの
octavia.conf
に追加します。stackrc
ファイルを取得します。$ source stackrc # Undercloud credentials
オーバークラウドコントローラーを一覧表示します。
$ openstack server list
出力例
+--------------------------------------+--------------+--------+-----------------------+----------------+------------+ │ | ID | Name | Status | Networks | Image | Flavor | │ +--------------------------------------+--------------+--------+-----------------------+----------------+------------+ │ | 6bef8e73-2ba5-4860-a0b1-3937f8ca7e01 | controller-0 | ACTIVE | ctlplane=192.168.24.8 | overcloud-full | controller | │ | dda3173a-ab26-47f8-a2dc-8473b4a67ab9 | compute-0 | ACTIVE | ctlplane=192.168.24.6 | overcloud-full | compute | │ +--------------------------------------+--------------+--------+-----------------------+----------------+------------+
コントローラーに対して SSH を実行します。
$ ssh heat-admin@192.168.24.8
octavia.conf
ファイルを編集して、プロジェクトを Amphora セキュリティーグループがユーザーのアカウントに設定されているプロジェクトの一覧に追加します。# List of project IDs that are allowed to have Load balancer security groups # belonging to them. amp_secgroup_allowed_projects = PROJECT_ID
新しい設定が読み込まれるように Octavia ワーカーを再起動します。
controller-0$ sudo docker restart octavia_worker
RHOSP 環境によっては、Octavia は UDP リスナーをサポートしない可能性があります。RHOSP の 13.0.13 よりも前のバージョンで Kuryr SDN を使用する場合、UDP サービスはサポートされません。RHOSP バージョン 16 以降は UDP をサポートします。
15.6.3.3.1. Octavia OVN ドライバー
Octavia は Octavia API を使用して複数のプロバイダードライバーをサポートします。
利用可能なすべての Octavia プロバイダードライバーをコマンドラインで表示するには、以下を入力します。
$ openstack loadbalancer provider list
出力例
+---------+-------------------------------------------------+ | name | description | +---------+-------------------------------------------------+ | amphora | The Octavia Amphora driver. | | octavia | Deprecated alias of the Octavia Amphora driver. | | ovn | Octavia OVN driver. | +---------+-------------------------------------------------+
RHOSP バージョン 16 以降、Octavia OVN プロバイダードライバー (ovn
) は RHOSP デプロイメントの OpenShift Container Platform でサポートされます。
ovn
は、Octavia および OVN が提供する負荷分散用の統合ドライバーです。これは基本的な負荷分散機能をサポートし、OpenFlow ルールに基づいています。このドライバーは、OVN Neutron ML2 を使用するデプロイメント上の director により Octavia で自動的に有効にされます。
Amphora プロバイダードライバーがデフォルトのドライバーです。ただし、ovn
が有効にされる場合には、Kuryr がこれを使用します。
Kuryr が Amphora の代わりに ovn
を使用する場合は、以下の利点があります。
- リソース要件が減少します。Kuryr は、各サービスにロードバランサーの仮想マシンを必要としません。
- ネットワークレイテンシーが短縮されます。
- サービスごとに仮想マシンを使用する代わりに、OpenFlow ルールを使用することで、サービスの作成速度が上がります。
- Amphora 仮想マシンで集中管理されるのではなく、すべてのノードに分散負荷分散アクションが分散されます。
15.6.3.4. Kuryr を使用したインストールについての既知の制限
OpenShift Container Platform を Kuryr SDN で使用する場合、いくつかの既知の制限があります。
RHOSP の一般的な制限
OpenShift Container Platform を Kuryr SDN と共に使用する場合は、すべてのバージョンおよび環境に適用されるいくつかの制限があります。
-
NodePort
タイプのService
オブジェクトはサポートされません。 -
OVN Octavia プロバイダーを使用するクラスターは、
Service
オブジェクトをサポートします。このオブジェクトについて、.spec.selector
プロパティーは、Endpoints
オブジェクトの.subsets.addresses
プロパティーにノードまたは Pod のサブネットが含まれる場合は指定されません。 -
マシンが作成されるサブネットがルーターに接続されていない場合や、サブネットが接続されていても、ルーターに外部ゲートウェイが設定されていない場合、Kuryr はタイプが
LoadBalancer
のService
オブジェクトの Floating IP を作成できません。 -
Service
オブジェクトでsessionAffinity=ClientIP
プロパティーを設定しても効果はありません。Kuryr はこの設定をサポートしていません。
RHOSP バージョンの制限
OpenShift Container Platform を Kuryr SDN で使用する場合は、RHOSP バージョンに依存するいくつかの制限があります。
RHOSP の 16 よりも前のバージョンでは、デフォルトの Octavia ロードバランサードライバー (Amphora) を使用します。このドライバーでは、OpenShift Container Platform サービスごとに 1 つの Amphora ロードバランサー仮想マシンをデプロイする必要があります。サービス数が多すぎると、リソースが不足する可能性があります。
OVN Octavia ドライバーが無効にされている以降のバージョンの RHOSP のデプロイメントでも Amphora ドライバーを使用します。この場合も、RHOSP の以前のバージョンと同じリソースに関する懸念事項を考慮する必要があります。
- バージョン 13.0.13 よりも前の Octavia RHOSP バージョンは UDP リスナーをサポートしません。そのため、OpenShift Container Platform UDP サービスはサポートされません。
- 13.0.13 よりも前の Octavia RHOSP バージョンは、同じポートで複数のプロトコルをリッスンできません。TCP や UDP など、同じポートを異なるプロトコルに公開するサービスはサポートされません。
- Kuryr SDN は、サービスによる自動解凍をサポートしていません。
RHOSP 環境の制限
Kuryr SDN を使用する場合に、デプロイメント環境に依存する制限事項があります。
Octavia には UDP プロトコルおよび複数のリスナーのサポートがないため、RHOCP バージョンが 13.0.13 よりも前のバージョンの場合、Kuryr は Pod が DNS 解決に TCP を使用するように強制します。
Go バージョン 1.12 以前では、CGO サポートが無効にされた状態でコンパイルされたアプリケーションは UDP のみを使用します。この場合、ネイティブの Go リゾルバーは、TCP が DNS 解決に強制的に実行されるかどうかを制御する、resolv.conf
の use-vc
オプションを認識しません。その結果、UDP は引き続き DNS 解決に使用されますが、これは失敗します。
TCP の強制を許可するには、環境変数 CGO_ENABLED
を 1
に設定 (例: CGO_ENABLED=1
) されている状態でアプリケーションをコンパイルするか、または変数がないことを確認します。
Go バージョン 1.13 以降では、UDP を使用した DNS 解決が失敗する場合に TCP が自動的に使用されます。
Alpine ベースのコンテナーを含む musl ベースのコンテナーは use-vc
オプションをサポートしません。
RHOSP のアップグレードの制限
RHOSP のアップグレードプロセスにより、Octavia API が変更され、ロードバランサーに使用される Amphora イメージへのアップグレードが必要になる可能性があります。
API の変更に個別に対応できます。
Amphora イメージがアップグレードされると、RHOSP Operator は既存のロードバランサー仮想マシンを 2 つの方法で処理できます。
- ロードバランサーのフェイルオーバー をトリガーしてそれぞれの仮想マシンをアップグレードします。
- ユーザーが仮想マシンのアップグレードを行う必要があります。
Operator が最初のオプションを選択する場合、フェイルオーバー時に短い時間のダウンタイムが生じる可能性があります。
Operator が 2 つ目のオプションを選択する場合、既存のロードバランサーは UDP リスナーなどのアップグレードされた Octavia API 機能をサポートしません。この場合、ユーザーはこれらの機能を使用するためにサービスを再作成する必要があります。
OpenShift Container Platform が UDP の負荷分散をサポートする新規の Octavia バージョンを検出する場合、これは DNS サービスを自動的に再作成します。サービスの再作成により、サービスのデフォルトが UDP の負荷分散をサポートするようになります。
再作成により、DNS サービスに約 1 分間のダウンタイムが発生します。
15.6.3.5. コントロールプレーンマシン
デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコントロールプレーンマシンを作成します。
それぞれのマシンには以下が必要です。
- RHOSP クォータからのインスタンス
- RHOSP クォータからのポート
- 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
- RHOSP クォータから少なくとも 100 GB のストレージ容量
15.6.3.6. コンピュートマシン
デフォルトでは、OpenShift Container Platform インストールプロセスは 3 つのコンピューティングマシンを作成します。
それぞれのマシンには以下が必要です。
- RHOSP クォータからのインスタンス
- RHOSP クォータからのポート
- 少なくとも 8 GB のメモリーと 2 つの vCPU を備えたフレーバー
- RHOSP クォータから少なくとも 100 GB のストレージ容量
コンピュートマシンは、OpenShift Container Platform で実行されるアプリケーションをホストします。できるだけ多くのアプリケーションを実行することが意図されています。
15.6.3.7. ブートストラップマシン
インストール時に、ブートストラップマシンは一時的にプロビジョニングされ、コントロールプレーンを初期化します。実稼働環境用のコントロールプレーンの準備ができた後に、ブートストラップマシンのプロビジョニングは解除されます。
ブートストラップマシンには以下が必要です。
- RHOSP クォータからのインスタンス
- RHOSP クォータからのポート
- 少なくとも 16 GB のメモリーと 4 つの vCPU を備えたフレーバー
- RHOSP クォータから少なくとも 100 GB のストレージ容量
15.6.4. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.9 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
15.6.5. Playbook 依存関係のダウンロード
ユーザーによってプロビジョニングされたインフラストラクチャーでのインストールプロセスを単純化する Ansible Playbook には、複数の Python モジュールが必要です。インストーラーを実行するマシンで、モジュールのリポジトリーを追加し、それらをダウンロードします。
この手順では、Red Hat Enterprise Linux (RHEL) 8 を使用していることを前提としています。
前提条件
- Python 3 がマシンにインストールされている。
手順
コマンドラインで、リポジトリーを追加します。
Red Hat Subscription Manager に登録します。
$ sudo subscription-manager register # If not done already
最新のサブスクリプションデータをプルします。
$ sudo subscription-manager attach --pool=$YOUR_POOLID # If not done already
現在のリポジトリーを無効にします。
$ sudo subscription-manager repos --disable=* # If not done already
必要なリポジトリーを追加します。
$ sudo subscription-manager repos \ --enable=rhel-8-for-x86_64-baseos-rpms \ --enable=openstack-16-tools-for-rhel-8-x86_64-rpms \ --enable=ansible-2.9-for-rhel-8-x86_64-rpms \ --enable=rhel-8-for-x86_64-appstream-rpms
モジュールをインストールします。
$ sudo yum install python3-openstackclient ansible python3-openstacksdk python3-netaddr
python
コマンドがpython3
を参照していることを確認します。$ sudo alternatives --set python /usr/bin/python3
15.6.6. インストール Playbook のダウンロード
OpenShift Container Platform を独自の Red Hat OpenStack Platform (RHOSP) インフラストラクチャーにインストールするために使用できる Ansible Playbook をダウンロードします。
前提条件
- curl コマンドラインツールがマシンで利用できる。
手順
Playbook を作業ディレクトリーにダウンロードするには、コマンドラインから以下のスクリプトを実行します。
$ xargs -n 1 curl -O <<< ' https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/bootstrap.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/common.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/compute-nodes.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/control-plane.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/inventory.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/network.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/security-groups.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/down-bootstrap.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/down-compute-nodes.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/down-control-plane.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/down-load-balancers.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/down-network.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/down-security-groups.yaml https://raw.githubusercontent.com/openshift/installer/release-4.9/upi/openstack/down-containers.yaml'
Playbook はマシンにダウンロードされます。
インストールプロセス時に、Playbook を変更してデプロイメントを設定できます。
クラスターの有効期間中に、すべての Playbook を保持します。OpenShift Container Platform クラスターを RHOSP から削除するには Playbook が必要です。
bootstrap.yaml
、compute-nodes.yaml
、control-plane.yaml
、network.yaml
、および security-groups.yaml
ファイルに加えた編集内容は、down-
の接頭辞が付けられた対応する Playbook に一致している必要があります。たとえば、bootstrap.yaml
ファイルへの編集は、down-bootstrap.yaml
ファイルにも反映される必要があります。両方のファイルを編集しない場合、サポートされるクラスターの削除プロセスは失敗します。
15.6.7. インストールプログラムの取得
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 など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
15.6.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 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
手順
クラスターノードへの認証に使用するローカルマシンに既存の 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 パブリックキーをインストールプログラムに指定します。
15.6.9. Red Hat Enterprise Linux CoreOS (RHCOS) イメージの作成
OpenShift Container Platform インストールプログラムでは、Red Hat Enterprise Linux CoreOS (RHCOS) イメージが Red Hat OpenStack Platform (RHOSP) クラスターに存在する必要があります。最新の RHCOS イメージを取得した後、RHOSP CLI を使用してこれをアップロードします。
前提条件
- RHOSP CLI がインストールされています。
手順
- Red Hat カスタマーポータルの 製品ダウンロードページ にログインします。
Version で、Red Hat Enterprise Linux (RHEL) 8 用の OpenShift Container Platform 4.9 の最新リリースを選択します。
重要RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。
- Red Hat Enterprise Linux CoreOS (RHCOS) - OpenStack Image (QCOW) をダウンロードします。
イメージを展開します。
注記クラスターが使用する前に RHOSP イメージを圧縮解除する必要があります。ダウンロードしたファイルの名前に、
.gz
または.tgz
などの圧縮拡張子が含まれていない場合があります。ファイルを圧縮するか、またはどのように圧縮するかを確認するには、コマンドラインで以下を入力します。$ file <name_of_downloaded_file>
ダウンロードしたイメージから、RHOSP CLI を使用して
rhcos
という名前のイメージをクラスターに作成します。$ openstack image create --container-format=bare --disk-format=qcow2 --file rhcos-${RHCOS_VERSION}-openstack.qcow2 rhcos
重要RHOSP 環境によっては、
.raw
または.qcow2
形式 のいずれかでイメージをアップロードできる場合があります。Ceph を使用する場合は、.raw
形式を使用する必要があります。警告インストールプログラムが同じ名前を持つ複数のイメージを見つける場合、それらのイメージのいずれかがランダムに選択されます。この動作を回避するには、RHOSP でリソースの一意の名前を作成します。
RHOSP にイメージをアップロードした後は、インストールプログラムでイメージを利用できます。
15.6.10. 外部ネットワークアクセスの確認
OpenShift Container Platform インストールプロセスでは、外部ネットワークへのアクセスが必要です。外部ネットワーク値をこれに指定する必要があります。指定しない場合には、デプロイメントは失敗します。このプロセスを実行する前に、外部ルータータイプのネットワークが Red Hat OpenStack Platform (RHOSP) に存在することを確認します。
手順
RHOSP CLI を使用して、'External' ネットワークの名前と ID を確認します。
$ openstack network list --long -c ID -c Name -c "Router Type"
出力例
+--------------------------------------+----------------+-------------+ | ID | Name | Router Type | +--------------------------------------+----------------+-------------+ | 148a8023-62a7-4672-b018-003462f8d7dc | public_network | External | +--------------------------------------+----------------+-------------+
外部ルータータイプのあるネットワークがネットワーク一覧に表示されます。1 つ以上のネットワークが表示されない場合は、デフォルトの Floating IP ネットワークの作成 および デフォルトのプロバイダーネットワークの作成 を参照してください。
Neutron トランクサービスプラグインが有効にされると、トランクポートがデフォルトで作成されます。詳細は、Neutron trunk port を参照してください。
15.6.11. 環境へのアクセスの有効化
デプロイ時に、OpenShift Container Platform マシンはすべて Red Hat OpenStack Platform (RHOSP) テナントネットワークに作成されます。したがって、ほとんどの RHOSP デプロイメントでは直接アクセスできません。
インストール時に Floating IP アドレス (FIP) を使用して OpenShift Container Platform API およびアプリケーションのアクセスを設定できます。FIP を設定せずにインストールを完了することもできますが、インストーラーは API またはアプリケーションを外部からアクセスする方法を設定しません。
15.6.11.1. floating IP アドレスを使ったアクセスの有効化
OpenShift Container Platform API、クラスターアプリケーション、およびブートストラッププロセスへの外部アクセス用に Floating IP (FIP) アドレスを作成します。
手順
Red Hat OpenStack Platform (RHOSP) CLI を使用して、API FIP を作成します。
$ openstack floating ip create --description "API <cluster_name>.<base_domain>" <external_network>
Red Hat OpenStack Platform (RHOSP) CLI を使用して、apps (アプリ)、または Ingress、FIP を作成します。
$ openstack floating ip create --description "Ingress <cluster_name>.<base_domain>" <external_network>
Red Hat OpenStack Platform (RHOSP) CLI を使用して、ブートストラップ FIP を作成します。
$ openstack floating ip create --description "bootstrap machine" <external_network>
API および Ingress FIP の DNS サーバーに、これらのパターンに準拠するレコードを追加します。
api.<cluster_name>.<base_domain>. IN A <API_FIP> *.apps.<cluster_name>.<base_domain>. IN A <apps_FIP>
注記DNS サーバーを制御していない場合は、次のようなクラスタードメイン名を
/etc/hosts
ファイルに追加することで、クラスターにアクセスできます。-
<api_floating_ip> api.<cluster_name>.<base_domain>
-
<application_floating_ip> grafana-openshift-monitoring.apps.<cluster_name>.<base_domain>
-
<application_floating_ip> prometheus-k8s-openshift-monitoring.apps.<cluster_name>.<base_domain>
-
<application_floating_ip> oauth-openshift.apps.<cluster_name>.<base_domain>
-
<application_floating_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
-
application_floating_ip integrated-oauth-server-openshift-authentication.apps.<cluster_name>.<base_domain>
/etc/hosts
ファイル内のクラスタードメイン名により、クラスターの Web コンソールおよび監視インターフェイスへのローカルアクセスが許可されます。kubectl
またはoc
を使用することもできます。<application_floating_ip> を指す追加のエントリーを使用して、ユーザーアプリケーションにアクセスできます。このアクションにより、API およびアプリケーションは他のユーザーがアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。-
FIP を以下の変数の値として
inventory.yaml
ファイルに追加します。-
os_api_fip
-
os_bootstrap_fip
-
os_ingress_fip
-
これらの値を使用する場合には、inventory.yaml
ファイルの os_external_network
変数の値として外部ネットワークを入力する必要もあります。
Floating IP アドレスを割り当て、ファイアウォール設定を更新することで、OpenShift Container Platform リソースがクラスター外で利用できる状態にすることができます。
15.6.11.2. Floating IP アドレスなしでのインストールの完了
Floating IP アドレスを指定せずに OpenShift Container Platform を Red Hat OpenStack Platform (RHOSP) にインストールすることができます。
inventory.yaml
ファイルで、以下の変数を定義しないでください。
-
os_api_fip
-
os_bootstrap_fip
-
os_ingress_fip
外部ネットワークを提供できない場合は、os_external_network
を空白のままにすることもできます。os_external_network
の値を指定しない場合はルーターが作成されず、追加のアクションがない場合は、インストーラーは Glance からのイメージの取得に失敗します。インストールプロセスで、ネットワークリソースを作成する際に、独自の外部接続を設定する必要があります。
Floating IP アドレスまたは名前解決がないために、クラスター API に到達できないシステムから wait-for
コマンドでインストーラーを実行すると、インストールに失敗します。このような場合にインストールが失敗するのを防ぐために、プロキシーネットワークを使用するか、マシンと同じネットワークにあるシステムからインストーラーを実行できます。
API および Ingress ポートの DNS レコードを作成して、名前解決を有効にできます。以下に例を示します。
api.<cluster_name>.<base_domain>. IN A <api_port_IP> *.apps.<cluster_name>.<base_domain>. IN A <ingress_port_IP>
DNS サーバーを制御しない場合は、/etc/hosts
ファイルにレコードを追加できます。このアクションにより、API は他者のアクセスできない状態になり、この状態は実稼働デプロイメントには適していませんが、開発およびテスト目的のインストールが可能になります。
15.6.12. インストールプログラムのパラメーターの定義
OpenShift Container Platform インストールプログラムは、clouds.yaml
というファイルを使用します。このファイルは、プロジェクト名、ログイン情報、認可サービスの URL を含む Red Hat OpenStack Platform (RHOSP) 設定パラメーターを説明します。
手順
clouds.yaml
ファイルを作成します。RHOSP ディストリビューションに Horizon Web UI が含まれる場合には、そこに
clouds.yaml
ファイルを生成します。重要パスワードを必ず
auth
フィールドに追加してください。シークレットは、clouds.yaml
の 別のファイル に保持できます。RHOSP ディストリビューションに Horizon Web UI が含まれない場合や Horizon を使用する必要がない場合には、このファイルを独自に作成します。
clouds.yaml
についての詳細は、RHOSP ドキュメントの Config files を参照してください。clouds: shiftstack: auth: auth_url: http://10.10.14.42:5000/v3 project_name: shiftstack username: shiftstack_user password: XXX user_domain_name: Default project_domain_name: Default dev-env: region_name: RegionOne auth: username: 'devuser' password: XXX project_name: 'devonly' auth_url: 'https://10.10.14.22:5001/v2.0'
RHOSP インストールでエンドポイント認証用に自己署名認証局 (CA) を使用する場合、以下を実行します。
- 認証局ファイルをマシンにコピーします。
cacerts
キーをclouds.yaml
ファイルに追加します。この値は、CA 証明書への絶対的な root 以外によるアクセスが可能なパスである必要があります。clouds: shiftstack: ... cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"
ヒントカスタム CA 証明書を使用してインストーラーを実行した後に、
cloud-provider-config
キーマップのca-cert.pem
キーの値を編集して証明書を更新できます。コマンドラインで、以下を実行します。$ oc edit configmap -n openshift-config cloud-provider-config
clouds.yaml
ファイルを以下の場所のいずれかに置きます。-
OS_CLIENT_CONFIG_FILE
環境変数の値 - 現行ディレクトリー
-
Unix 固有のユーザー設定ディレクトリー (例:
~/.config/openstack/clouds.yaml
) Unix 固有のサイト設定ディレクトリー (例:
/etc/openstack/clouds.yaml
)インストールプログラムはこの順序で
clouds.yaml
を検索します。
-
15.6.13. インストール設定ファイルの作成
Red Hat OpenStack Platform (RHOSP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして openstack を選択します。
- クラスターのインストールに使用する Red Hat OpenStack Platform (RHOSP) の外部ネットワーク名を指定します。
- OpenShift API への外部アクセスに使用する floating IP アドレスを指定します。
- コントロールプレーンノードに使用する少なくとも 16 GB の RAM とコンピュートノードに使用する 8 GB の RAM を持つ RHOSP フレーバーを指定します。
- クラスターをデプロイするベースドメインを選択します。すべての DNS レコードはこのベースのサブドメインとなり、クラスター名も含まれます。
- クラスターの名前を入力します。名前は 14 文字以下でなければなりません。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、インストール設定パラメーターのセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
これで、指定したディレクトリーに install-config.yaml
ファイルが作成されます。
15.6.14. インストール設定パラメーター
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml
インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml
ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml
ファイルで変更することはできません。
openshift-install
コマンドは、パラメーターのフィールド名を検証しません。正しくない名前を指定すると、関連するファイルまたはオブジェクトは作成されず、エラーが報告されません。指定されたパラメーターのフィールド名が正しいことを確認します。
15.6.14.1. 必須設定パラメーター
必須のインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
|
| 文字列 |
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
Kubernetes リソース | オブジェクト |
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
|
インストールの実行に使用する特定プラットフォームの設定: | オブジェクト |
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
{ "auths":{ "cloud.openshift.com":{ "auth":"b3Blb=", "email":"you@example.com" }, "quay.io":{ "auth":"b3Blb=", "email":"you@example.com" } } } |
15.6.14.2. ネットワーク設定パラメーター
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
パラメーター | 説明 | 値 |
---|---|---|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
| インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) プラグイン。 |
|
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 |
|
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
|
サービスの IP アドレスブロック。デフォルト値は OpenShift SDN および OVN-Kubernetes ネットワークプロバイダーは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16 |
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16 |
|
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
15.6.14.3. オプションの設定パラメーター
オプションのインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
| コンピュートノードを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
| コントロールプレーンを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
| Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。 注記
AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、 |
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
| 文字列 |
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
このフィールドを |
| クラスターマシンへのアクセスを認証するための単一または複数の SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 | 1 つ以上のキー。以下に例を示します。 sshKey: <key1> <key2> <key3> |
15.6.14.4. 追加の Red Hat OpenStack Platform (RHOSP) 設定パラメーター
追加の RHOSP 設定パラメーターは以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
| コンピュートマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。 |
整数 (例: |
| コンピュートマシンの場合、root のボリュームタイプです。 |
文字列 (例: |
| コントロールプレーンマシンの場合、root ボリュームのギガバイトのサイズになります。この値を設定しない場合、マシンは一時ストレージを使用します。 |
整数 (例: |
| コントロールプレーンマシンの場合、root ボリュームのタイプです。 |
文字列 (例: |
|
|
文字列 (例: |
| インストールに使用される RHOSP の外部ネットワーク名。 |
文字列 (例: |
| コントロールプレーンおよびコンピュートマシンに使用する RHOSP フレーバー。
このプロパティーは非推奨にされています。すべてのマシンプールのデフォルトとしてフレーバーを使用するには、これを |
文字列 (例: |
15.6.14.5. オプションの RHOSP 設定パラメーター
オプションの RHOSP 設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
| コンピュートマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。 |
文字列としての 1 つ以上の UUID の一覧。例: |
| コンピュートマシンに関連付けられた追加のセキュリティーグループ。 |
文字列としての 1 つ以上の UUID の一覧。例: |
| マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストーラーは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。 Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。 |
文字列の一覧(例: |
| コンピュートマシンの root ボリュームをインストールするアベイラビリティーゾーン。このパラメーターに値を設定しない場合、インストーラーはデフォルトのアベイラビリティーゾーンを選択します。 |
文字列の一覧 (例: |
| コントロールプレーンマシンに関連付けられた追加のネットワーク。追加ネットワーク用に許可されるアドレスのペアは作成されません。 |
文字列としての 1 つ以上の UUID の一覧。例: |
| コントロールプレーンマシンに関連付けられた追加のセキュリティーグループ。 |
文字列としての 1 つ以上の UUID の一覧。例: |
| マシンをインストールする RHOSP Compute (Nova) アベイラビリティーゾーン (AZs)。このパラメーターが設定されていない場合、インストーラーは RHOSP 管理者が設定した Nova のデフォルト設定に依存します。 Kuryr を使用するクラスターでは、RHOSP Octavia はアベイラビリティーゾーンをサポートしません。ロードバランサーおよび Amphora プロバイダードライバーを使用している場合、Amphora 仮想マシンに依存する OpenShift Container Platform サービスは、このプロパティーの値に基づいて作成されません。 |
文字列の一覧(例: |
| コントロールプレーンマシンの root ボリュームをインストールするアベイラビリティーゾーン。この値を設定しない場合、インストーラーはデフォルトのアベイラビリティーゾーンを選択します。 |
文字列の一覧 (例: |
| インストーラーが RHCOS イメージをダウンロードする場所。 ネットワークが制限された環境でインストールを実行するには、このパラメーターを設定する必要があります。 | HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。
例: |
|
Glance のインストーラーでアップロードされた ClusterOSImage に追加するプロパティー。このプロパティーは、
このプロパティーを使用し、ノードあたり 26 PV の RHOSP のデフォルト永続ボリューム (PV) の制限を超過することができます。制限を超えるには、
このプロパティーを使用し、 |
キーと値の文字列のペアの一覧。例: |
| デフォルトのマシンプールプラットフォームの設定。 |
{ "type": "ml.large", "rootVolume": { "size": 30, "type": "performance" } } |
|
Ingress ポートに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、 |
IP アドレス (例: |
|
API ロードバランサーに関連付ける既存の Floating IP アドレス。このプロパティーを使用するには、 |
IP アドレス (例: |
| クラスターインスタンスが DNS 解決に使用する外部 DNS サーバーの IP アドレス。 |
文字列としての IP アドレスの一覧。例: |
| クラスターのノードが使用する RHOSP サブネットの UUID。ノードおよび仮想 IP (VIP) ポートがこのサブネットに作成されます。
カスタムサブネットにデプロイする場合、OpenShift Container Platform インストーラーに外部 DNS サーバーを指定することはできません。代わりに、DNS を RHOSP のサブネットに追加 します。 |
文字列としての UUID。例: |
15.6.14.6. RHOSP デプロイメントでのカスタムサブネット
オプションで、選択する Red Hat OpenStack Platform (RHOSP) サブネットにクラスターをデプロイすることができます。サブネットの GUID は、install-config.yaml
ファイルの platform.openstack.machinesSubnet
の値として渡されます。
このサブネットはクラスターのプライマリーサブネットとして使用されます。デフォルトで、ノードおよびポートはこの上に作成されます。platform.openstack.machinesSubnet
プロパティーの値をサブネットの UUID に設定すると、異なる RHOSP サブネットにノードおよびポートを作成することができます。
カスタムサブネットを使用して OpenShift Container Platform インストーラーを実行する前に、設定が以下の要件を満たしていることを確認してください。
-
platform.openstack.machinesSubnet
で使用されるサブネットで DHCP が有効にされている。 -
platform.openstack.machinesSubnet
の CIDR はnetworking.machineNetwork
の CIDR に一致する。 - インストールプログラムのユーザーには、固定 IP アドレスを持つポートなど、このネットワークでポートを作成するパーミッションがある。
カスタムサブネットを使用するクラスターには、以下の制限があります。
-
Floating IP アドレスを使用するクラスターをインストールする予定の場合には、
platform.openstack.machinesSubnet
サブネットをexternalNetwork
ネットワークに接続されているルーターに接続する必要があります。 -
platform.openstack.machinesSubnet
の値がinstall-config.yaml
ファイルに設定されている場合、インストールプログラムは RHOSP マシンのプライベートネットワークまたはサブネットを作成しません。 -
platform.openstack.externalDNS
プロパティーは、カスタムサブネットと同時に使用することはできません。カスタムサブネットを使用するクラスターに DNS を追加するには、RHOSP ネットワークで DNS を設定します。
デフォルトでは、API VIP は x.x.x.5 を取得し、Ingress VIP はネットワークの CIDR ブロックから x.x.x.7 を取得します。これらのデフォルト値を上書きするには、DHCP 割り当てプール外の platform.openstack.apiVIP
および platform.openstack.ingressVIP
の値を設定します。
15.6.14.7. Kuryr を使用した OpenStack のカスタマイズされた install-config.yaml
ファイルのサンプル
デフォルトの OpenShift SDN ではなく Kuryr SDN を使用してデプロイするには、install-config.yaml
ファイルを変更して Kuryr
を必要な networking.networkType
として追加してから、デフォルトの OpenShift Container Platform SDN インストール手順に進む必要があります。このサンプル install-config.yaml
は、すべての可能な Red Hat OpenStack Platform (RHOSP) カスタマイズオプションを示しています。
このサンプルファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得する必要があります。
apiVersion: v1 baseDomain: example.com controlPlane: name: master platform: {} replicas: 3 compute: - name: worker platform: openstack: type: ml.large replicas: 3 metadata: name: example networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 serviceNetwork: - 172.30.0.0/16 1 networkType: Kuryr platform: openstack: cloud: mycloud externalNetwork: external computeFlavor: m1.xlarge apiFloatingIP: 128.0.0.1 trunkSupport: true 2 octaviaSupport: true 3 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA...
- 1
- Amphora Octavia ドライバーは、ロードバランサーごとに 2 つのポートを作成します。そのため、インストーラーが作成するサービスサブネットは、
serviceNetwork
プロパティーの値として指定される CIDR のサイズは 2 倍になります。IP アドレスの競合を防ぐには、範囲をより広くする必要があります。 - 2 3
trunkSupport
とoctaviaSupport
の両方はインストーラーによって自動的に検出されるため、それらを設定する必要はありません。ただし、ご使用の環境がこれらの両方の要件を満たさないと、Kuryr SDN は適切に機能しません。トランクは Pod を RHOSP ネットワークに接続するために必要であり、Octavia は OpenShift Container Platform サービスを作成するために必要です。
15.6.14.8. RHOSP プロバイダーネットワーク上のクラスターデプロイメント
プロバイダーネットワーク上のプライマリーネットワークインターフェイスを使用して、OpenShift Container Platform クラスターを Red Hat OpenStack Platform (RHOSP) にデプロイできます。プロバイダーネットワークは一般的に、インターネットへの到達に使用可能なパブリックネットワークに、プロジェクトが直接アクセスできるように使用します。ネットワーク作成プロセスの一環として、プロバイダーネットワークをプロジェクト間で共有することもできます。
RHOSP プロバイダーネットワークは、データセンター内の既存の物理ネットワークに直接マップします。RHOSP 管理者はこれらを作成する必要があります。
以下の例では、OpenShift Container Platform ワークロードはプロバイダーネットワークを使用してデータセンターに接続されます。
![OpenStack 上の 4 つの OpenShift ワークロードを示す図。各ワークロードは、プロバイダーネットワークを使用して、NIC によって外部のデータセンターに接続されます。](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.9-Installing-ja-JP/images/b49712cae2810b6700081476367769dc/openshift-on-openstack-provider-network.png)
プロバイダーネットワークにインストールされている OpenShift Container Platform クラスターは、テナントネットワークまたは Floating IP アドレスを必要としません。インストーラーは、インストール中にこれらのリソースを作成しません。
プロバイダーネットワークタイプの例には、フラット (タグなし) および VLAN (802.1Q タグ付き) が含まれます。
クラスターは、ネットワークタイプが許可する限り多くのプロバイダーネットワーク接続をサポートできます。たとえば、VLAN ネットワークは、通常最大 4096 の接続をサポートします。
プロバイダーネットワークおよびテナントネットワークの詳細は、RHOSP のドキュメント を参照してください。
15.6.14.8.1. クラスターのインストールにおける RHOSP プロバイダーネットワーク要件
OpenShift Container Platform クラスターをインストールする前に、Red Hat OpenStack Platform (RHOSP) のデプロイメントおよびプロバイダーネットワークは、さまざまな条件を満たす必要があります。
- RHOSP ネットワークサービス (Neutron) が有効化され、RHOSP ネットワーク API 経由でアクセス可能であること。
- RHOSP ネットワークサービスでは、ポートセキュリティーと許可するアドレスペアの機能拡張が有効化 されていること。
プロバイダーネットワークは他のテナントと共有できます。
ヒント--share
フラグを指定してopenstack network create
コマンドを使用して、共有できるネットワークを作成します。クラスターのインストールに使用する RHOSP プロジェクトは、プロバイダーネットワークと適切なサブネットを所有する必要があります。
ヒント- openshift という名前のプロジェクトのネットワークを作成するには、以下のコマンドを入力します。
$ openstack network create --project openshift
- openshift という名前のプロジェクトのサブネットを作成するには、以下のコマンドを入力します。
$ openstack subnet create --project openshift
RHOSP でのネットワークの作成に関する詳細は、プロバイダーネットワークに関するドキュメント を参照してください。
クラスターが
admin
ユーザーによって所有されている場合、そのユーザーとしてインストーラーを実行してネットワーク上でポートを作成する必要があります。重要プロバイダーネットワークは、クラスターの作成に使用される RHOSP プロジェクトによって所有されている必要があります。所有されていない場合は、RHOSP Compute サービス (Nova) はそのネットワークからポートを要求できません。
プロバイダーネットワークが、デフォルトで
169.254.169.254
である RHOSP メタデータサービスの IP アドレスに到達できることを確認します。RHOSP SDN とネットワークサービス設定によっては、サブネットを作成する際に、ルートを提供しなければならない場合があります。以下に例を示します。
$ openstack subnet create --dhcp --host-route destination=169.254.169.254/32,gateway=192.0.2.2 ...
- オプション: ネットワークのセキュリティーを保護するには、単一のプロジェクトへのネットワークアクセスを制限する ロールベースのアクセス制御 (RBAC) ルールを作成します。
15.6.14.8.2. プロバイダーネットワークにプライマリーインターフェイスを持つクラスターのデプロイ
Red Hat OpenStack Platform (RHOSP) プロバイダーネットワーク上にプライマリーネットワークインターフェイスを持つ OpenShift Container Platform クラスターをデプロイすることができます。
- クラスターのインストールにおける RHOSP プロバイダーネットワーク要件に記載されているとおりに、お使いの Red Hat OpenStack Platform (RHOSP) のデプロイメントが設定されています。
手順
-
テキストエディターで
install-config.yaml
ファイルを開きます。 -
platform.openstack.apiVIP
プロパティーの値を API VIP の IP アドレスに設定します。 -
platform.openstack.ingressVIP
プロパティーの値を Ingress VIP の IP アドレスに設定します。 -
platform.openstack.machinesSubnet
プロパティーの値をプロバイダーネットワークサブネットの UUID に設定します。 -
networking.machineNetwork.cidr
プロパティーの値をプロバイダーネットワークサブネットの CIDR ブロックに設定します。
platform.openstack.apiVIP
プロパティーおよび platform.openstack.ingressVIP
プロパティーはいずれも、networking.machineNetwork.cidr
ブロックから割り当てられていない IP アドレスである必要があります。
RHOSP プロバイダーネットワークに依存するクラスターのインストール設定ファイルのセクション
... platform: openstack: apiVIP: 192.0.2.13 ingressVIP: 192.0.2.23 machinesSubnet: fa806b2f-ac49-4bce-b9db-124bc64209bf # ... networking: machineNetwork: - cidr: 192.0.2.0/24
プライマリーネットワークインターフェイスにプロバイダーネットワークを使用している間は、platform.openstack.externalNetwork
パラメーターまたは platform.openstack.externalDNS
パラメーターを設定することはできません。
クラスターをデプロイする際に、インストーラーは install-config.yaml
ファイルを使用してプロバイダーネットワークにクラスターをデプロイします。
プロバイダーネットワークを含むネットワークを platform.openstack.additionalNetworkIDs
一覧に追加できます。
クラスターのデプロイ後に、Pod を追加のネットワークに接続することができます。詳細は、複数ネットワークについて を参照してください。
15.6.14.9. Kuryr ポートプール
Kuryr ポートプールでは、Pod 作成のスタンバイ状態の多数のポートを維持します。
ポートをスタンバイ状態に維持すると、Pod の作成時間が必要最小限に抑えることができます。ポートプールを使用しない場合には、Kuryr は Pod が作成または削除されるたびにポートの作成または削除を明示的に要求する必要があります。
Kuryr が使用する Neutron ポートは、namespace に関連付けられるサブネットに作成されます。これらの Pod ポートは、OpenShift Container Platform クラスターノードのプライマリーポートにサブポートとして追加されます。
Kuryr は namespace をそれぞれ、別のサブネットに保存するため、namespace-worker ペアごとに別個のポートプールが維持されます。
クラスターをインストールする前に、cluster-network-03-config.yml
マニフェストファイルに以下のパラメーターを設定して、ポートプールの動作を設定できます。
-
enablePortPoolsPrepopulation
パラメーターで、プールの事前生成が制御されるので、Kuryr は新規ホストが追加される時や新規 namespace の作成時などの作成時に、Kuryr によりプールにポートが強制的に追加されるようにします。デフォルト値はfalse
です。 -
poolMinPorts
パラメーターは、プールに保持する空きポートの最小数です。デフォルト値は1
です。 poolMaxPorts
パラメーターは、プールに保持する空きポートの最大数です。値が0
の場合は、上限が無効になります。これはデフォルト設定です。OpenStack ポートのクォータが低い場合や、Pod ネットワークで IP アドレスの数が限定されている場合には、このオプションを設定して、不要なポートが削除されるようにします。
-
poolBatchPorts
パラメーターは、一度に作成可能な Neutron ポートの最大数を定義します。デフォルト値は3
です。
15.6.14.10. インストール時の Kuryr ポートプールの調整
インストール時に、Pod 作成の速度や効率性を制御するために Kuryr で Red Hat OpenStack Platform (RHOSP) Neutron ポートを管理する方法を設定できます。
前提条件
-
install-config.yaml
ファイルを作成して変更しておく。
手順
コマンドラインからマニフェストファイルを作成します。
$ ./openshift-install create manifests --dir <installation_directory> 1
- 1
<installation_directory>
については、クラスターのinstall-config.yaml
ファイルが含まれるディレクトリーの名前を指定します。
cluster-network-03-config.yml
という名前のファイルを<installation_directory>/manifests/
ディレクトリーに作成します。$ touch <installation_directory>/manifests/cluster-network-03-config.yml 1
- 1
<installation_directory>
については、クラスターのmanifests/
ディレクトリーが含まれるディレクトリー名を指定します。
ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが
manifests/
ディレクトリーに置かれます。$ ls <installation_directory>/manifests/cluster-network-*
出力例
cluster-network-01-crd.yml cluster-network-02-config.yml cluster-network-03-config.yml
エディターで
cluster-network-03-config.yml
ファイルを開き、必要な Cluster Network Operator 設定を記述するカスタムリソース (CR) を入力します。$ oc edit networks.operator.openshift.io cluster
要件に合わせて設定を編集します。以下のファイルをサンプルとして紹介しています。
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 serviceNetwork: - 172.30.0.0/16 defaultNetwork: type: Kuryr kuryrConfig: enablePortPoolsPrepopulation: false 1 poolMinPorts: 1 2 poolBatchPorts: 3 3 poolMaxPorts: 5 4 openstackServiceNetwork: 172.30.0.0/15 5
- 1
enablePortPoolsPrepopulation
の値をtrue
に設定し、namespace の作成時、または新規ノードがクラスターに追加された後に Kuryr が新規 Neutron ポートを作成するようにします。この設定により、Neutron ポートのクォータが引き上げられますが、Pod の起動に必要となる時間を短縮できます。デフォルト値はfalse
です。- 2
- Kuryr は、対象のプール内にある空きポートの数が
poolMinPorts
の値よりも少ない場合には、プールに新規ポートを作成します。デフォルト値は1
です。 - 3
poolBatchPorts
は、空きポートの数がpoolMinPorts
の値よりも少ない場合に作成される新規ポートの数を制御します。デフォルト値は3
です。- 4
- プール内の空きポートの数が
poolMaxPorts
の値よりも多い場合に、Kuryr はその値と同じ数になるまでポートを削除します。この値を0
に設定すると、この上限は無効になり、プールが縮小できないようにします。デフォルト値は0
です。 - 5
openStackServiceNetwork
パラメーターは、RHOSP Octavia の LoadBalancer に割り当てられるネットワークの CIDR 範囲を定義します。
このパラメーターを Amphora ドライバーと併用する場合には、Octavia は、ロードバランサーごとに、このネットワークから IP アドレスを 2 つ (OpenShift 用に 1 つ、VRRP 接続用に 1 つ) 取得します。これらの IP アドレスは OpenShift Container Platform と Neutron でそれぞれ管理されるため、異なるプールから取得する必要があります。したがって、
openStackServiceNetwork
serviceNetwork
の値の 2 倍になる必要があり、serviceNetwork
の値は、openStackServiceNetwork
で定義された範囲と完全に重複する必要があります。CNO は、このパラメーターの定義範囲から取得した VRRP IP アドレスが
serviceNetwork
パラメーターの定義範囲と重複しないことを検証します。このパラメーターが設定されていない場合には、CNO は
serviceNetwork
の拡張値を使用します。この値は、プリフィックスのサイズを 1 つずつ減らして決定します。-
cluster-network-03-config.yml
ファイルを保存し、テキストエディターを終了します。 -
オプション:
manifests/cluster-network-03-config.yml
ファイルをバックアップします。インストールプログラムは、クラスターの作成時にmanifests/
ディレクトリーを削除します。
15.6.14.11. マシンのカスタムサブネットの設定
インストールプログラムがデフォルトで使用する IP 範囲は、OpenShift Container Platform のインストール時に作成する Neutron サブネットと一致しない可能性があります。必要な場合は、インストール設定ファイルを編集して、新規マシンの CIDR 値を更新します。
前提条件
-
OpenShift Container Platform インストールプログラムで生成された
install-config.yaml
ファイルがあります。
手順
-
コマンドラインで、
install-config.yaml
が含まれるディレクトリーを参照します。 そのディレクトリーからスクリプトを実行して
install-config.yaml
ファイルを編集するか、または手動でファイルを更新します。スクリプトを使用して値を設定するには、以下を実行します。
$ python -c ' import yaml; path = "install-config.yaml"; data = yaml.safe_load(open(path)); data["networking"]["machineNetwork"] = [{"cidr": "192.168.0.0/18"}]; 1 open(path, "w").write(yaml.dump(data, default_flow_style=False))'
- 1
- 必要な Neutron サブネットに一致する値 (例:
192.0.2.0/24
) を挿入します。
-
値を手動で設定するには、ファイルを開き、
networking.machineCIDR
の値を必要な Neutron サブネットに一致する値に設定します。
15.6.14.12. コンピュートマシンプールを空にする
独自のインフラストラクチャーを使用するインストールを実行するには、インストール設定ファイルのコンピュートマシンの数をゼロに設定します。その後、これらのマシンを手動で作成します。
前提条件
-
OpenShift Container Platform インストールプログラムで生成された
install-config.yaml
ファイルがあります。
手順
-
コマンドラインで、
install-config.yaml
が含まれるディレクトリーを参照します。 そのディレクトリーからスクリプトを実行して
install-config.yaml
ファイルを編集するか、または手動でファイルを更新します。スクリプトを使用して値を設定するには、以下を実行します。
$ python -c ' import yaml; path = "install-config.yaml"; data = yaml.safe_load(open(path)); data["compute"][0]["replicas"] = 0; open(path, "w").write(yaml.dump(data, default_flow_style=False))'
-
値を手動で設定するには、ファイルを開き、
compute.<first entry>.replicas
の値を0
に設定します。
15.6.14.13. ネットワークタイプの変更
デフォルトで、インストールプログラムは OpenShiftSDN
ネットワークタイプを選択します。代わりに Kuryr を使用するには、プログラムが生成したインストール設定ファイルの値を変更します。
前提条件
-
OpenShift Container Platform インストールプログラムで生成された
install-config.yaml
ファイルがあります。
手順
-
コマンドプロンプトで、
install-config.yaml
が含まれるディレクトリーを参照します。 そのディレクトリーからスクリプトを実行して
install-config.yaml
ファイルを編集するか、または手動でファイルを更新します。スクリプトを使用して値を設定するには、以下を実行します。
$ python -c ' import yaml; path = "install-config.yaml"; data = yaml.safe_load(open(path)); data["networking"]["networkType"] = "Kuryr"; open(path, "w").write(yaml.dump(data, default_flow_style=False))'
-
値を手動で設定するには、ファイルを開き、
networking.networkType
を"Kuryr"
に設定します。
15.6.15. Kubernetes マニフェストおよび Ignition 設定ファイルの作成
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。
-
OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。
-
install-config.yaml
インストール設定ファイルを作成していること。
手順
OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
$ ./openshift-install create manifests --dir <installation_directory> 1
- 1
<installation_directory>
については、作成したinstall-config.yaml
ファイルが含まれるインストールディレクトリーを指定します。
コントロールプレーンマシンおよびコンピュートマシンセットを定義する Kubernetes マニフェストファイルを削除します。
$ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml
これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。
- マシンセットファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。
<installation_directory>/manifests/cluster-scheduler-02-config.yml
Kubernetes マニフェストファイルのmastersSchedulable
パラメーターがfalse
に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.yml
ファイルを開きます。 -
mastersSchedulable
パラメーターを見つけ、これがfalse
に設定されていることを確認します。 - ファイルを保存し、終了します。
-
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
メタデータファイルの
infraID
キーを環境変数としてエクスポートします。$ export INFRA_ID=$(jq -r .infraID metadata.json)
metadata.json
から infraID
キーを抽出し、作成するすべての RHOSP リソースの接頭辞として使用します。これを実行することで、同じプロジェクトで複数のデプロイメントを実行する際に名前の競合が発生しないようにします。
15.6.16. ブートストラップ Ignition ファイルの準備
OpenShift Container Platform インストールプロセスは、ブートストラップ Ignition 設定ファイルから作成されるブートストラップマシンに依存します。
ファイルを編集し、アップロードします。次に、Red Hat OpenStack Platform (RHOSP) がプライマリーファイルをダウンロードする際に使用するセカンダリーブートストラップ Ignition 設定ファイルを作成します。
前提条件
-
インストーラープログラムが生成するブートストラップ Ignition ファイル
bootstrap.ign
があります。 インストーラーのメタデータファイルのインフラストラクチャー ID は環境変数 (
$INFRA_ID
) として設定されます。- 変数が設定されていない場合は、Kubernetes マニフェストおよび Ignition 設定ファイルの作成 を参照してください。
HTTP(S) でアクセス可能な方法でブートストラップ Ignition ファイルを保存できます。
- 記載された手順では RHOSP イメージサービス (Glance) を使用しますが、RHOSP ストレージサービス (Swift)、Amazon S3、内部 HTTP サーバー、またはアドホックの Nova サーバーを使用することもできます。
手順
以下の Python スクリプトを実行します。スクリプトはブートストラップ Ignition ファイルを変更して、ホスト名および利用可能な場合は、実行時の CA 証明書ファイルを設定します。
import base64 import json import os with open('bootstrap.ign', 'r') as f: ignition = json.load(f) files = ignition['storage'].get('files', []) infra_id = os.environ.get('INFRA_ID', 'openshift').encode() hostname_b64 = base64.standard_b64encode(infra_id + b'-bootstrap\n').decode().strip() files.append( { 'path': '/etc/hostname', 'mode': 420, 'contents': { 'source': 'data:text/plain;charset=utf-8;base64,' + hostname_b64 } }) ca_cert_path = os.environ.get('OS_CACERT', '') if ca_cert_path: with open(ca_cert_path, 'r') as f: ca_cert = f.read().encode() ca_cert_b64 = base64.standard_b64encode(ca_cert).decode().strip() files.append( { 'path': '/opt/openshift/tls/cloud-ca-cert.pem', 'mode': 420, 'contents': { 'source': 'data:text/plain;charset=utf-8;base64,' + ca_cert_b64 } }) ignition['storage']['files'] = files; with open('bootstrap.ign', 'w') as f: json.dump(ignition, f)
RHOSP CLI を使用して、ブートストラップ Ignition ファイルを使用するイメージを作成します。
$ openstack image create --disk-format=raw --container-format=bare --file bootstrap.ign <image_name>
イメージの詳細を取得します。
$ openstack image show <image_name>
file
値をメモします。これはv2/images/<image_ID>/file
パターンをベースとしています。注記作成したイメージがアクティブであることを確認します。
イメージサービスのパブリックアドレスを取得します。
$ openstack catalog show image
-
パブリックアドレスとイメージ
file
値を組み合わせ、結果を保存場所として保存します。この場所は、<image_service_public_URL>/v2/images/<image_ID>/file
パターンをベースとしています。 認証トークンを生成し、トークン ID を保存します。
$ openstack token issue -c id -f value
$INFRA_ID-bootstrap-ignition.json
というファイルに以下のコンテンツを挿入し、独自の値に一致するようにプレースホルダーを編集します。{ "ignition": { "config": { "merge": [{ "source": "<storage_url>", 1 "httpHeaders": [{ "name": "X-Auth-Token", 2 "value": "<token_ID>" 3 }] }] }, "security": { "tls": { "certificateAuthorities": [{ "source": "data:text/plain;charset=utf-8;base64,<base64_encoded_certificate>" 4 }] } }, "version": "3.2.0" } }
- セカンダリー Ignition 設定ファイルを保存します。
ブートストラップ Ignition データはインストール時に RHOSP に渡されます。
ブートストラップ Ignition ファイルには、clouds.yaml
認証情報などの機密情報が含まれます。これを安全な場所に保存し、インストールプロセスの完了後に削除します。
15.6.17. RHOSP でのコントロールプレーンの Ignition 設定ファイルの作成
独自のインフラストラクチャーを使用して OpenShift Container Platform を Red Hat OpenStack Platform (RHOSP) にインストールするには、コントロールプレーンの Ignition 設定ファイルが必要です。複数の設定ファイルを作成する必要があります。
ブートストラップ Ignition 設定と同様に、各コントロールプレーンマシンのホスト名を明示的に定義する必要があります。
前提条件
インストールプログラムのメタデータファイルのインフラストラクチャー ID は環境変数 (
$INFRA_ID
) として設定されます。- 変数が設定されていない場合は、Kubernetes マニフェストおよび Ignition 設定ファイルの作成を参照してください。
手順
コマンドラインで、以下の Python スクリプトを実行します。
$ for index in $(seq 0 2); do MASTER_HOSTNAME="$INFRA_ID-master-$index\n" python -c "import base64, json, sys; ignition = json.load(sys.stdin); storage = ignition.get('storage', {}); files = storage.get('files', []); files.append({'path': '/etc/hostname', 'mode': 420, 'contents': {'source': 'data:text/plain;charset=utf-8;base64,' + base64.standard_b64encode(b'$MASTER_HOSTNAME').decode().strip(), 'verification': {}}, 'filesystem': 'root'}); storage['files'] = files; ignition['storage'] = storage json.dump(ignition, sys.stdout)" <master.ign >"$INFRA_ID-master-$index-ignition.json" done
以下の 3 つのコントロールプレーン Ignition ファイルが作成されます。
<INFRA_ID>-master-0-ignition.json
、<INFRA_ID>-master-1-ignition.json
、および<INFRA_ID>-master-2-ignition.json
。
15.6.18. RHOSP でのネットワークリソースの作成
独自のインフラストラクチャーを使用する Red Hat OpenStack Platform (RHOSP) インストールの OpenShift Container Platform に必要なネットワークリソースを作成します。時間を節約するには、セキュリティーグループ、ネットワーク、サブネット、ルーター、およびポートを生成する指定された Ansible Playbook を実行します。
前提条件
- Python 3 がマシンにインストールされている。
- Playbook 依存関係のダウンロードでモジュールをダウンロードしている。
- インストール Playbook のダウンロードで Playbook をダウンロードしている。
手順
オプション: 外部ネットワークの値を
inventory.yaml
Playbook に追加します。inventory.yaml
Ansible Playbook の外部ネットワーク値の例... # The public network providing connectivity to the cluster. If not # provided, the cluster external connectivity must be provided in another # way. # Required for os_api_fip, os_ingress_fip, os_bootstrap_fip. os_external_network: 'external' ...
重要inventory.yaml
ファイルのos_external_network
の値を指定しなかった場合は、仮想マシンが Glance および外部接続にアクセスできるようにする必要があります。オプション: 外部ネットワークおよび Floating IP (FIP) アドレスの値を
inventory.yaml
Playbook に追加します。inventory.yaml
Ansible Playbook の FIP 値の例... # OpenShift API floating IP address. If this value is non-empty, the # corresponding floating IP will be attached to the Control Plane to # serve the OpenShift API. os_api_fip: '203.0.113.23' # OpenShift Ingress floating IP address. If this value is non-empty, the # corresponding floating IP will be attached to the worker nodes to serve # the applications. os_ingress_fip: '203.0.113.19' # If this value is non-empty, the corresponding floating IP will be # attached to the bootstrap machine. This is needed for collecting logs # in case of install failure. os_bootstrap_fip: '203.0.113.20'
重要os_api_fip
およびos_ingress_fip
の値を定義しない場合、インストール後のネットワーク設定を実行する必要があります。os_bootstrap_fip
の値を定義しない場合、インストーラーは失敗したインストールからデバッグ情報をダウンロードできません。詳細は、環境へのアクセスの有効化を参照してください。
コマンドラインで、
security-groups.yaml
Playbook を実行してセキュリティーグループを作成します。$ ansible-playbook -i inventory.yaml security-groups.yaml
コマンドラインで、
network.yaml
Playbook を実行して、ネットワーク、サブネット、およびルーターを作成します。$ ansible-playbook -i inventory.yaml network.yaml
オプション: Nova サーバーが使用するデフォルトのリゾルバーを制御する必要がある場合は、RHOSP CLI コマンドを実行します。
$ openstack subnet set --dns-nameserver <server_1> --dns-nameserver <server_2> "$INFRA_ID-nodes"
15.6.19. RHOSP でのブートストラップマシンの作成
ブートストラップマシンを作成し、これに Red Hat OpenStack Platform (RHOSP) で実行するために必要なネットワークアクセスを付与します。Red Hat は、このプロセスを単純化するために実行する Ansible Playbook を提供しています。
前提条件
- Playbook 依存関係のダウンロードでモジュールをダウンロードしている。
- インストール Playbook のダウンロードで Playbook をダウンロードしている。
-
inventory.yaml
、common.yaml
、およびbootstrap.yaml
Ansible Playbook は共通ディレクトリーにある。 -
インストールプログラムが作成した
metadata.json
ファイルが Ansible Playbook と同じディレクトリーにあります。
手順
- コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。
コマンドラインで、
bootstrap.yaml
Playbook を実行します。$ ansible-playbook -i inventory.yaml bootstrap.yaml
ブートストラップサーバーがアクティブになった後に、ログを表示し、Ignition ファイルが受信されたことを確認します。
$ openstack console log show "$INFRA_ID-bootstrap"
15.6.20. RHOSP でのコントロールプレーンの作成
生成した Ignition 設定ファイルを使用して 3 つのコントロールプレーンマシンを作成します。Red Hat は、このプロセスを単純化するために実行する Ansible Playbook を提供しています。
前提条件
- Playbook 依存関係のダウンロードでモジュールをダウンロードしている。
- インストール Playbook のダウンロードで Playbook をダウンロードしている。
-
インストールプログラムのメタデータファイルのインフラストラクチャー ID は環境変数 (
$INFRA_ID
) として設定されます。 -
inventory.yaml
、common.yaml
、およびcontrol-plane.yaml
Ansible Playbook は共通ディレクトリーにあります。 - コントロールプレーンの Ignition 設定ファイルの作成で作成された 3 つの Ignition ファイルがある。
手順
- コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。
- コントロールプレーン Ignition 設定ファイルが作業ディレクトリーにない場合、それらをここにコピーします。
コマンドラインで、
control-plane.yaml
Playbook を実行します。$ ansible-playbook -i inventory.yaml control-plane.yaml
以下のコマンドを実行してブートストラッププロセスをモニターします。
$ openshift-install wait-for bootstrap-complete
コントロールプレーンマシンが実行され、クラスターに参加していることを確認できるメッセージが表示されます。
INFO API v1.22.1 up INFO Waiting up to 30m0s for bootstrapping to complete... ... INFO It is now safe to remove the bootstrap resources
15.6.21. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
15.6.22. RHOSP からのブートストラップリソースの削除
不要になったブートストラップリソースを削除します。
前提条件
- Playbook 依存関係のダウンロードでモジュールをダウンロードしている。
- インストール Playbook のダウンロードで Playbook をダウンロードしている。
-
inventory.yaml
、common.yaml
、およびdown-bootstrap.yaml
Ansible Playbook が共通ディレクトリーにある。 コントロールプレーンマシンが実行中である。
- マシンのステータスが不明な場合は、クラスターステータスの確認を参照してください。
手順
- コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。
コマンドラインで、
down-bootstrap.yaml
Playbook を実行します。$ ansible-playbook -i inventory.yaml down-bootstrap.yaml
ブートストラップポート、サーバー、および Floating IP アドレスが削除されます。
ブートストラップ Ignition ファイル URL をまだ無効にしていない場合は、無効にしてください。
15.6.23. RHOSP でのコンピュートマシンの作成
コントロールプレーンの起動後、コンピュートマシンを作成します。Red Hat は、このプロセスを単純化するために実行する Ansible Playbook を提供しています。
前提条件
- Playbook 依存関係のダウンロードでモジュールをダウンロードしている。
- インストール Playbook のダウンロードで Playbook をダウンロードしている。
-
inventory.yaml
、common.yaml
、およびcompute-nodes.yaml
Ansible Playbook が共通ディレクトリーにある。 -
インストールプログラムが作成した
metadata.json
ファイルが Ansible Playbook と同じディレクトリーにあります。 - コントロールプレーンが有効である。
手順
- コマンドラインで、作業ディレクトリーを Playbook の場所に切り替えます。
コマンドラインで Playbook を実行します。
$ ansible-playbook -i inventory.yaml compute-nodes.yaml
次のステップ
- マシンの証明書署名要求を承認します。
15.6.24. マシンの証明書署名要求の承認
マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、または必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.22.1 master-1 Ready master 63m v1.22.1 master-2 Ready master 64m v1.22.1
出力には作成したすべてのマシンが一覧表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (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 が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pending
ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approver
によって自動的に承認されます。注記ベアメタルおよび他のユーザーによってプロビジョニングされるインフラストラクチャーなどのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec
、oc rsh
、およびoc logs
コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:node
またはsystem:admin
グループのnode-bootstrapper
サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。
$ oc adm certificate approve <csr_name> 1
- 1
<csr_name>
は、現行の CSR の一覧からの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
$ 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 ...
残りの 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
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Ready
になります。以下のコマンドを実行して、これを確認します。$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 73m v1.22.1 master-1 Ready master 73m v1.22.1 master-2 Ready master 74m v1.22.1 worker-0 Ready worker 11m v1.22.1 worker-1 Ready worker 11m v1.22.1
注記サーバー CSR の承認後にマシンが
Ready
ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。
15.6.25. インストールの正常な実行の確認
OpenShift Container Platform のインストールが完了していることを確認します。
前提条件
-
インストールプログラム (
openshift-install
) があります。
手順
コマンドラインで、以下を入力します。
$ openshift-install --log-level debug wait-for install-complete
プログラムはコンソール URL と管理者のログイン情報を出力します。
15.6.26. 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 サービスの詳細は、リモートヘルスモニターリング について参照してください。
15.6.27. 次のステップ
- クラスターをカスタマイズ します。
- 必要な場合は、リモートの健全性レポートをオプトアウト することができます。
- ノードポートへの外部アクセスを有効にする必要がある場合は、ノードポートを使用して Ingress クラスタートラフィックを設定 します。
- RHOSP が Floating IP アドレス上でアプリケーショントラフィックを受け入れるように設定しなかった場合には、RHOSP のアクセスを Floating IP アドレスで設定 します。