Nutanix へのインストール
Nutanix への OpenShift Container Platform のインストール
概要
第1章 Nutanix へのインストールの準備
OpenShift Container Platform クラスターをインストールする前に、Nutanix 環境が以下の要件を満たしていることを確認してください。
1.1. Nutanix バージョン要件
以下の要件を満たす Nutanix 環境に OpenShift Container Platform クラスターをインストールする必要があります。
コンポーネント | 必須バージョン |
---|---|
Nutanix AOS | 6.5.2.7 以降 |
Prism Central | pc.2022.6 以降 |
1.2. 環境要件
OpenShift Container Platform クラスターをインストールする前に、以下の Nutanix AOS 環境要件を確認してください。
1.2.1. 必要なアカウント特権
インストールプログラムには、クラスターをデプロイし、その日次の操作を維持するために必要な権限のある Nutanix アカウントへのアクセスが必要です。以下のオプションを使用できます。
- 管理者権限を持つローカル Prism Central ユーザーアカウントを使用できます。ローカルアカウントを使用することは、必要な権限を持つアカウントへのアクセスを許可する最も簡単な方法です。
- 組織のセキュリティーポリシーにより、より制限の厳しい権限セットを使用する必要がある場合は、次の表にリストされている権限を使用して、Prism Central でカスタムの Cloud Native ロールを作成します。その後、Prism Central 認証ディレクトリーのメンバーであるユーザーアカウントにロールを割り当てることができます。
このユーザーアカウントを管理するときは、次の点を考慮してください。
- エンティティーをロールに割り当てるときは、ユーザーが仮想マシンのデプロイに必要な Prism Element とサブネットのみにアクセスできるようにしてください。
- ユーザーが、仮想マシンを割り当てる必要があるプロジェクトのメンバーであることを確認してください。
詳細は、Custom Cloud Native ロール の作成、ロールの割り当て、プロジェクトへのユーザーの追加に関する Nutanix ドキュメントを参照してください。
例1.1 Custom Cloud Native ロールの作成に必要な権限
Nutanix オブジェクト | 必要になる場合 | Nutanix API で必要な権限 | 説明 |
---|---|---|---|
Categories | 常時 |
| OpenShift Container Platform マシンに割り当てられたカテゴリーを作成、読み取り、削除します。 |
Images | 常時 |
| OpenShift Container Platform マシンに使用されるオペレーティングシステムイメージを作成、読み取り、削除します。 |
仮想マシン | 常時 |
| OpenShift Container Platform マシンを作成、読み取り、削除します。 |
クラスター | 常時 |
| OpenShift Container Platform マシンをホストする Prism Element クラスターを表示します。 |
サブネット | 常時 |
| OpenShift Container Platform マシンをホストするサブネットを表示します。 |
プロジェクト | プロジェクトをコンピューティングマシン、コントロールプレーンマシン、またはすべてのマシンに関連付ける場合。 |
| Prism Central で定義されたプロジェクトを表示し、プロジェクトを OpenShift Container Platform マシンに割り当てることができるようにします。 |
1.2.2. クラスターの制限
利用可能なリソースはクラスターによって異なります。Nutanix 環境内で可能なクラスターの数は、主に、使用可能なストレージスペースと、クラスターが作成するリソースに関連する制限、および IP アドレスやネットワークなど、クラスターをデプロイするために必要なリソースによって制限されます。
1.2.3. クラスターリソース
標準クラスターを使用するには、最低 800 GB のストレージが必要です。
installer-provisioned infrastructure を使用する OpenShift Container Platform クラスターをデプロイする場合、インストールプログラムは Nutanix インスタンスに複数のリソースを作成できる必要があります。これらのリソースは 856 GB のストレージを使用しますが、ブートストラップノードはインストールプロセスの一部として破棄されます。
標準的な OpenShift Container Platform インストールでは、以下のリソースを作成します。
- 1 ラベル
仮想マシン:
- 1 ディスクイメージ
- 1 一時的ブートストラップノード
- 3 コントロールプレーンノード
- 3 コンピュートマシン
1.2.4. ネットワーク要件
ネットワークには AHV IP アドレス管理 (IPAM) または動的ホスト設定プロトコル (DHCP) のいずれかを使用し、クラスターマシンに永続的な IP アドレスを提供するように設定されていることを確認する必要があります。さらに、OpenShift Container Platform クラスターをインストールする前に以下のネットワークリソースを作します。
- IP アドレス
- DNS レコード
クラスターの各 OpenShift Container Platform ノードは、DHCP を使用して検出可能な Network Time Protocol (NTP) サーバーにアクセスできることが推奨されます。NTP サーバーなしでインストールが可能です。ただし、NTP サーバーは、非同期サーバークロックに通常関連するエラーを防ぎます。
1.2.4.1. 必要な IP アドレス
installer-provisioned installation には、2 つの静的仮想 IP (VIP) アドレスが必要です。
- API の VIP アドレスが必要です。このアドレスは、クラスター API にアクセスするために使用されます。
- Ingress 用の VIP アドレスが必要です。このアドレスは、クラスターの Ingress トラフィックに使用されます。
これらの IP アドレスは、OpenShift Container Platform クラスターをインストールするときに指定します。
1.2.4.2. DNS レコード
OpenShift Container Platform クラスターをホストする Nutanix インスタンスについて 2 つの静的 IP アドレスの DNS レコードを適切な DNS サーバーに作成する必要があります。各レコードで、<cluster_name>
はクラスター名で、<base_domain>
は、クラスターのインストール時に指定するクラスターのベースドメインです。
独自の DNS または DHCP サーバーを使用する場合は、ブートストラップ、コントロールプレーン、コンピュートノードなどの各ノードのレコードも作成する必要があります。
完全な DNS レコードは <component>.<cluster_name>.<base_domain>.
の形式を取ります。
コンポーネント | レコード | 説明 |
---|---|---|
API VIP |
| この DNS A/AAAA または CNAME レコードは、コントロールプレーンマシンのロードバランサーを参照する必要があります。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
Ingress VIP |
| Ingress ルーター Pod を実行するマシンをターゲットにするロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
1.3. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) は、クラウドプロバイダーの認証情報を Kubernetes カスタムリソース定義 (CRD) として管理します。Nutanix にクラスターをインストールするには、インストールプロセスの一部として CCO を manual
モードに設定する必要があります。
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
$ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
注記$RELEASE_IMAGE
のアーキテクチャーが、ccoctl
ツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctl
バイナリーを抽出します。$ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
次のコマンドを実行して、権限を変更して
ccoctl
を実行可能にします。$ chmod 775 ccoctl
検証
ccoctl
が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。$ ./ccoctl.rhel9
出力例
OpenShift credentials provisioning tool Usage: ccoctl [command] Available Commands: alibabacloud Manage credentials objects for alibaba cloud aws Manage credentials objects for AWS cloud azure Manage credentials objects for Azure gcp Manage credentials objects for Google cloud help Help about any command ibmcloud Manage credentials objects for IBM Cloud nutanix Manage credentials objects for Nutanix Flags: -h, --help help for ccoctl Use "ccoctl [command] --help" for more information about a command.
第2章 複数の Prism Element を使用したフォールトトレラントなデプロイメント
デフォルトでは、インストールプログラムは、コントロールプレーンとコンピュートマシンを単一の Nutanix Prism Element (クラスター) にインストールします。OpenShift Container Platform クラスターのフォールトトレランスを向上させるために、これらのマシンを複数の Nutanix クラスターに分散するように指定できます。これを行うには、障害ドメインを設定します。
障害ドメインは、インストール中およびインストール後に OpenShift Container Platform マシンプールで使用できる追加の Prism Element インスタンスを表します。
2.1. インストール方法と障害ドメインの設定
OpenShift Container Platform のインストール方法によって、障害ドメインをいつどのように設定するかが決まります。
installer-provisioned infrastructure を使用してデプロイする場合は、クラスターをデプロイする前に、インストール設定ファイルで障害ドメインを設定できます。詳細は、障害ドメインの設定 を参照してください。
クラスターのデプロイ後に障害ドメインを設定することもできます。インストール後の障害ドメインの設定の詳細は、既存の Nutanix クラスターへの障害ドメインの追加 を参照してください。
- お客様が管理するインフラストラクチャー (user-provisioned infrastructure) を使用してデプロイする場合、追加の設定は必要ありません。クラスターをデプロイした後、コントロールプレーンとコンピュートマシンを障害ドメイン全体に手動で分散できます。
2.2. 既存の Nutanix クラスターへの障害ドメインの追加
デフォルトでは、インストールプログラムは、コントロールプレーンとコンピュートマシンを単一の Nutanix Prism Element (クラスター) にインストールします。OpenShift Container Platform クラスターをデプロイした後、障害ドメインを使用して追加の Prism Element インスタンスをデプロイメントに追加することで、フォールトトレランスを向上させることができます。
障害ドメインは、新しいコントロールプレーンとコンピュートマシンをデプロイし、既存のコントロールプレーンとコンピュートマシンを分散できる単一の Prism Element インスタンスを表します。
2.2.1. 障害ドメインの要件
障害ドメインの使用を計画する場合は、次の要件を考慮してください。
- すべての Nutanix Prism Element インスタンスは、同一の Prism Central インスタンスによって管理する必要があります。複数の Prism Central インスタンスで構成されるデプロイメントはサポートされていません。
- Prism Element クラスターを構成するマシンは、障害ドメインが相互に通信できるように、同じイーサネットネットワーク上に存在する必要があります。
- OpenShift Container Platform クラスターで障害ドメインとして使用する各 Prism Element には、サブネットが必要です。これらのサブネットを定義するときは、共通の IP アドレス接頭辞 (CIDR) を指定する必要があります。また、OpenShift Container Platform クラスターが使用する仮想 IP アドレスをサブネットに含める必要があります。
2.2.2. インフラストラクチャー CR への障害ドメインの追加
既存の Nutanix クラスターに障害ドメインを追加するには、そのインフラストラクチャーカスタムリソース (CR) (infrastructures.config.openshift.io
) を変更します。
高可用性を確保するには、3 つの障害ドメインを設定することを推奨します。
手順
次のコマンドを実行して、インフラストラクチャー CR を編集します。
$ oc edit infrastructures.config.openshift.io cluster
障害ドメインを設定します。
Nutanix 障害ドメインを使用したインフラストラクチャー CR の例
spec: cloudConfig: key: config name: cloud-provider-config #... platformSpec: nutanix: failureDomains: - cluster: type: UUID uuid: <uuid> name: <failure_domain_name> subnets: - type: UUID uuid: <network_uuid> - cluster: type: UUID uuid: <uuid> name: <failure_domain_name> subnets: - type: UUID uuid: <network_uuid> - cluster: type: UUID uuid: <uuid> name: <failure_domain_name> subnets: - type: UUID uuid: <network_uuid> # ...
ここでは、以下のようになります。
<uuid>
- Prism Element の汎用一意識別子 (UUID) を指定します。
<failure_domain_name>
-
障害ドメインの一意の名前を指定します。名前は 64 文字以下に制限されており、小文字、数字、ダッシュ (
-
) を含めることができます。ダッシュを名前の先頭または末尾に含めることはできません。 <network_uuid>
- Prism Element サブネットオブジェクトの UUID を指定します。サブネットの IP アドレス接頭辞 (CIDR) には、OpenShift Container Platform クラスターが使用する仮想 IP アドレスを含める必要があります。OpenShift Container Platform クラスター内の障害ドメイン (Prism Element) ごとに 1 つのサブネットのみがサポートされます。
- CR を保存して変更を適用します。
2.2.3. 障害ドメイン全体へのコントロールプレーンの分散
コントロールプレーンマシンセットのカスタムリソース (CR) を変更することで、Nutanix 障害ドメイン全体にコントロールプレーンを分散します。
前提条件
- クラスターのインフラストラクチャーカスタムリソース (CR) で障害ドメインを設定している。
- コントロールプレーンマシンセットのカスタムリソース (CR) がアクティブな状態である。
コントロールプレーンマシンセットのカスタムリソースの状態を確認する方法の詳細は、「関連情報」を参照してください。
手順
次のコマンドを実行して、コントロールプレーンマシンセット CR を編集します。
$ oc edit controlplanemachineset.machine.openshift.io cluster -n openshift-machine-api
spec.template.machines_v1beta1_machine_openshift_io.failureDomains
スタンザを追加して、障害ドメインを使用するようにコントロールプレーンマシンセットを設定します。Nutanix 障害ドメインが設定されたコントロールプレーンマシンの例
apiVersion: machine.openshift.io/v1 kind: ControlPlaneMachineSet metadata: creationTimestamp: null labels: machine.openshift.io/cluster-api-cluster: <cluster_name> name: cluster namespace: openshift-machine-api spec: # ... template: machineType: machines_v1beta1_machine_openshift_io machines_v1beta1_machine_openshift_io: failureDomains: platform: Nutanix nutanix: - name: <failure_domain_name_1> - name: <failure_domain_name_2> - name: <failure_domain_name_3> # ...
- 変更を保存します。
デフォルトでは、コントロールプレーンマシンセットは、変更をコントロールプレーン設定に自動的に反映します。クラスターが OnDelete
更新ストラテジーを使用するように設定されている場合は、コントロールプレーンを手動で置き換える必要があります。詳細は、「関連情報」を参照してください。
2.2.4. 障害ドメイン全体へのコンピュートマシンの分散
次のいずれかの方法で、Nutanix 障害ドメイン全体にコンピュートマシンを分散できます。
- 既存のコンピュートマシンセットを編集 すると、設定更新を最小限に抑えながら、Nutanix 障害ドメイン全体にコンピュートマシンを分散できます。
- 既存のコンピュートマシンセットを置き換える と、仕様をイミュータブルにして、すべてのマシンを確実に同じにすることができます。
2.2.4.1. コンピュートマシンセットの編集による障害ドメインの実装
既存のコンピュートマシンセットを使用して Nutanix 障害ドメイン全体にコンピュートマシンを分散するには、設定でコンピュートマシンセットを更新し、スケーリングを使用して既存のコンピュートマシンを置き換えます。
前提条件
- クラスターのインフラストラクチャーカスタムリソース (CR) で障害ドメインを設定している。
手順
次のコマンドを実行して、クラスターのインフラストラクチャー CR を表示します。
$ oc describe infrastructures.config.openshift.io cluster
-
各障害ドメイン (
platformSpec.nutanix.failureDomains
) について、クラスターの UUID、名前、サブネットオブジェクト UUID をメモします。これらの値は、障害ドメインをコンピュートマシンセットに追加するために必要です。 以下のコマンドを実行して、クラスター内のコンピュートマシンセットを一覧表示します。
$ oc get machinesets -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE <machine_set_name_1> 1 1 1 1 55m <machine_set_name_2> 1 1 1 1 55m
次のコマンドを実行して、最初のコンピュートマシンセットを編集します。
$ oc edit machineset <machine_set_name_1> -n openshift-machine-api
spec.template.spec.providerSpec.value
スタンザを次のように更新して、最初の障害ドメインを使用するようにコンピュートマシンセットを設定します。注記cluster
およびsubnets
フィールドに指定する値が、クラスターのインフラストラクチャー CR のfailureDomains
スタンザに設定されている値と一致していることを確認してください。Nutanix 障害ドメインを使用したコンピュートマシンセットの例
apiVersion: machine.openshift.io/v1 kind: MachineSet metadata: creationTimestamp: null labels: machine.openshift.io/cluster-api-cluster: <cluster_name> name: <machine_set_name_1> namespace: openshift-machine-api spec: replicas: 2 # ... template: spec: # ... providerSpec: value: apiVersion: machine.openshift.io/v1 failureDomain: name: <failure_domain_name_1> cluster: type: uuid uuid: <prism_element_uuid_1> subnets: - type: uuid uuid: <prism_element_network_uuid_1> # ...
-
spec.replicas
の値をメモします。この値は、変更を適用するためにコンピュートマシンセットをスケーリングする際に必要になるためです。 - 変更を保存します。
次のコマンドを実行して、更新されたコンピュートマシンセットによって管理されているマシンをリスト表示します。
$ oc get -n openshift-machine-api machines \ -l machine.openshift.io/cluster-api-machineset=<machine_set_name_1>
出力例
NAME PHASE TYPE REGION ZONE AGE <machine_name_original_1> Running AHV Unnamed Development-STS 4h <machine_name_original_2> Running AHV Unnamed Development-STS 4h
次のコマンドを実行して、更新されたコンピュートマシンセットで管理されるマシンごとに
delete
アノテーションを設定します。$ oc annotate machine/<machine_name_original_1> \ -n openshift-machine-api \ machine.openshift.io/delete-machine="true"
代わりとなるマシンを新しい設定で作成するために、次のコマンドを実行して、コンピュートマシンセットをレプリカ数の 2 倍にスケーリングします。
$ oc scale --replicas=<twice_the_number_of_replicas> \1 machineset <machine_set_name_1> \ -n openshift-machine-api
- 1
- たとえば、コンピュートマシンセット内のレプリカの元の数が
2
の場合、レプリカを4
にスケーリングします。
次のコマンドを実行して、更新されたコンピュートマシンセットによって管理されているマシンをリスト表示します。
$ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<machine_set_name_1>
新しいマシンが
Running
フェーズにある場合、コンピュートマシンセットを元のレプリカ数にスケーリングできます。古い設定で作成されたマシンを削除するために、次のコマンドを実行して、コンピュートマシンセットを元のレプリカ数にスケーリングします。
$ oc scale --replicas=<original_number_of_replicas> \1 machineset <machine_set_name_1> \ -n openshift-machine-api
- 1
- たとえば、コンピュートマシンセット内のレプリカの元の数が
2
であった場合、レプリカを2
にスケーリングします。
- 必要に応じて、デプロイメントで使用可能な追加の障害ドメインを参照するようにマシンセットの変更を続けます。
関連情報
2.2.4.2. コンピュートマシンセットの置き換えによる障害ドメインの実装
コンピュートマシンセットを置き換えることによって、Nutanix 障害ドメイン全体にコンピュートマシンを分散するには、独自の設定で新しいコンピュートマシンセットを作成し、作成されたマシンが起動するのを待ってから、古いコンピュートマシンセットを削除します。
前提条件
- クラスターのインフラストラクチャーカスタムリソース (CR) で障害ドメインを設定している。
手順
次のコマンドを実行して、クラスターのインフラストラクチャー CR を表示します。
$ oc describe infrastructures.config.openshift.io cluster
-
各障害ドメイン (
platformSpec.nutanix.failureDomains
) について、クラスターの UUID、名前、サブネットオブジェクト UUID をメモします。これらの値は、障害ドメインをコンピュートマシンセットに追加するために必要です。 以下のコマンドを実行して、クラスター内のコンピュートマシンセットを一覧表示します。
$ oc get machinesets -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE <original_machine_set_name_1> 1 1 1 1 55m <original_machine_set_name_2> 1 1 1 1 55m
- 既存のコンピュートマシンセットの名前に注意してください。
次のいずれかの方法を使用して、新しいコンピュートマシンセットのカスタムリソース (CR) の値を含む YAML ファイルを作成します。
次のコマンドを実行して、既存のコンピュートマシンセット設定を新しいファイルにコピーします。
$ oc get machineset <original_machine_set_name_1> \ -n openshift-machine-api -o yaml > <new_machine_set_name_1>.yaml
この YAML ファイルは、任意のテキストエディターで編集できます。
任意のテキストエディターを使用して
<new_machine_set_name_1>.yaml
という名前の空の YAML ファイルを作成し、新しいコンピュートマシンセットに必要な値を含めます。特定のフィールドに設定する値がわからない場合は、次のコマンドを実行して、既存のコンピュートマシンセット CR の値を確認できます。
$ oc get machineset <original_machine_set_name_1> \ -n openshift-machine-api -o yaml
出力例
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 name: <infrastructure_id>-<role> 2 namespace: openshift-machine-api spec: replicas: 1 selector: matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> template: metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> machine.openshift.io/cluster-api-machine-role: <role> machine.openshift.io/cluster-api-machine-type: <role> machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> spec: providerSpec: 3 ...
<new_machine_set_name_1>.yaml
ファイルのspec.template.spec.providerSpec.value
スタンザを更新または追加して、最初の障害ドメインを使用するように新しいコンピュートマシンセットを設定します。注記cluster
およびsubnets
フィールドに指定する値が、クラスターのインフラストラクチャー CR のfailureDomains
スタンザに設定されている値と一致していることを確認してください。Nutanix 障害ドメインを使用したコンピュートマシンセットの例
apiVersion: machine.openshift.io/v1 kind: MachineSet metadata: creationTimestamp: null labels: machine.openshift.io/cluster-api-cluster: <cluster_name> name: <new_machine_set_name_1> namespace: openshift-machine-api spec: replicas: 2 # ... template: spec: # ... providerSpec: value: apiVersion: machine.openshift.io/v1 failureDomain: name: <failure_domain_name_1> cluster: type: uuid uuid: <prism_element_uuid_1> subnets: - type: uuid uuid: <prism_element_network_uuid_1> # ...
- 変更を保存します。
次のコマンドを実行して、コンピュートマシンセット CR を作成します。
$ oc create -f <new_machine_set_name_1>.yaml
- 必要に応じて、デプロイメントで使用可能な追加の障害ドメインを参照するコンピュートマシンセットの作成に進みます。
新しいコンピュートマシンセットごとに次のコマンドを実行して、新しいコンピュートマシンセットによって管理されているマシンをリスト表示します。
$ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<new_machine_set_name_1>
出力例
NAME PHASE TYPE REGION ZONE AGE <machine_from_new_1> Provisioned AHV Unnamed Development-STS 25s <machine_from_new_2> Provisioning AHV Unnamed Development-STS 25s
新しいマシンが
Running
フェーズにある場合、障害ドメイン設定を含まない古いコンピュートマシンセットを削除できます。新しいマシンが
Running
フェーズにあることを確認したら、古いコンピュートマシンセットごとに次のコマンドを実行して削除します。$ oc delete machineset <original_machine_set_name_1> -n openshift-machine-api
検証
設定を更新していないコンピューティングマシンセットが削除されたことを確認するには、次のコマンドを実行して、クラスター内のコンピューティングマシンセットをリスト表示します。
$ oc get machinesets -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE <new_machine_set_name_1> 1 1 1 1 4m12s <new_machine_set_name_2> 1 1 1 1 4m12s
設定を更新していないコンピュートマシンが削除されたことを確認するには、次のコマンドを実行してクラスター内のマシンをリスト表示します。
$ oc get -n openshift-machine-api machines
削除中の出力例
NAME PHASE TYPE REGION ZONE AGE <machine_from_new_1> Running AHV Unnamed Development-STS 5m41s <machine_from_new_2> Running AHV Unnamed Development-STS 5m41s <machine_from_original_1> Deleting AHV Unnamed Development-STS 4h <machine_from_original_2> Deleting AHV Unnamed Development-STS 4h
削除完了時の出力例
NAME PHASE TYPE REGION ZONE AGE <machine_from_new_1> Running AHV Unnamed Development-STS 6m30s <machine_from_new_2> Running AHV Unnamed Development-STS 6m30s
新しいコンピューティングマシンセットによって作成されたマシンの設定が正しいことを確認するには、次のコマンドを実行して、いずれかの新しいマシンの CR に含まれる関連フィールドを調べます。
$ oc describe machine <machine_from_new_1> -n openshift-machine-api
第3章 クラスターの Nutanix へのインストール
OpenShift Container Platform バージョン 4.15 では、以下のオプションのいずれかを選択して、Nutanix インスタンスにクラスターをインストールできます。
インストーラーによってプロビジョニングされたインフラストラクチャーの使用: インストーラーによってプロビジョニングされたインフラストラクチャーを使用するには、次のセクションの手順を使用します。installer-provisioned infrastructure は、接続されたネットワーク環境または切断されたネットワーク環境でのインストールに最適です。installer-provisioned infrastructure には、クラスターの基礎となるインフラストラクチャーをプロビジョニングするインストールプログラムが含まれています。
Assisted Installer の使用: Assisted Installer は console.redhat.com でホストされます。Assisted Installer は、切断された環境では使用できません。Assisted Installer はクラスターの基礎となるインフラストラクチャーをプロビジョニングしないため、Assisted Installer を実行する前にインフラストラクチャーをプロビジョニングする必要があります。Assisted Installer を使用してインストールすると、Nutanix との統合も提供され、自動スケーリングが可能になります。詳細は、自動インストーラーを使用したオンプレミスクラスターのインストール を参照してください。
user-provisioned infrastructure の使用: 任意のプラットフォームへのクラスターのインストール ドキュメントに概説されている関連手順を完了します。
3.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- インストールプログラムで、Prism Central および Prism Element のポート 9440 にアクセスできる。ポート 9440 にアクセスできることを確認している。
ファイアウォールを使用している場合は、次の前提条件を満たしています。
- ポート 9440 にアクセスできることを確認している。コントロールプレーンノードがポート 9440 で Prism Central および Prism Element にアクセスできる (インストールが成功するために必要)。
- OpenShift Container Platform が必要とするサイトへの アクセスを許可する ようにファイアウォールを設定している。これには、Telemetry の使用が含まれます。
Nutanix 環境でデフォルトの自己署名 SSL 証明書を使用している場合は、CA によって署名された証明書に置き換える。インストールプログラムには、Prism Central API にアクセスするための有効な CA 署名付き証明書が必要です。自己署名証明書の置き換えに関する詳細は、Nutanix AOS Security Guide を参照してください。
Nutanix 環境で内部 CA を使用して証明書を発行する場合は、インストールプロセスの一部としてクラスター全体のプロキシーを設定する必要があります。詳細は、カスタム PKI の設定 を参照してください。
重要2048 ビット証明書を使用します。Prism Central 2022.x で 4096 ビット証明書を使用すると、インストールに失敗します。
3.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしないと、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
3.3. Prism Central のインターネットアクセス
Prism Central では、クラスターのインストールに必要な Red Hat Enterprise Linux CoreOS (RHCOS) イメージを取得するためにインターネットアクセスが必要です。Nutanix の RHCOS イメージは、rhcos.mirror.openshift.com
で入手できます。
3.4. クラスターノードの 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
ディレクトリーにあることを確認します。
注記x86_64
、ppc64le
、およびs390x
アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、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 パブリックキーをインストールプログラムに指定します。
3.5. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- Linux または macOS を実行し、少なくとも 1.2 GB のローカルディスク容量を備えたコンピューターがある。
手順
- Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
- OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。
ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。
重要- インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。クラスターを削除するには、両方のファイルが必要です。
- インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
Red Hat カスタマーポータル からインストールプログラムを取得することもできます。このページでは、ダウンロードするインストールプログラムのバージョンを指定できます。ただし、このページにアクセスするには、有効なサブスクリプションが必要です。
3.6. Nutanix root CA 証明書をシステム信頼に追加する
インストールプログラムは Prism Central API へのアクセスを必要とするため、OpenShift Container Platform クラスターをインストールする前に、Nutanix の信頼された root CA 証明書をシステム信頼に追加する必要があります。
手順
- Prism Central Web コンソールから、Nutanix root CA 証明書をダウンロードします。
- Nutanix root CA 証明書を含む圧縮ファイルを抽出します。
オペレーティングシステム用のファイルをシステム信頼に追加します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
# cp certs/lin/* /etc/pki/ca-trust/source/anchors
システム信頼を更新します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
# update-ca-trust extract
3.7. インストール設定ファイルの作成
Nutanix にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- Nutanix のネットワーク要件を満たしていることが確認されました。詳細は、「Nutanix へのインストールの準備」を参照してください。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットとするプラットフォームとして nutanix を選択します。
- Prism Central のドメイン名または IP アドレスを入力します。
- Prism Central へのログインに使用するポートを入力します。
Prism Central へのログインに使用する認証情報を入力します。
インストールプログラムが Prism Central に接続します。
- OpenShift Container Platform クラスターを管理する Prism Element を選択します。
- 使用するネットワークサブネットを選択します。
- コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
- クラスター Ingress に設定した仮想 IP アドレスを入力します。
- ベースドメインを入力します。このベースドメインは、DNS レコードで設定したものと同じである必要があります。
クラスターの記述名を入力します。
入力するクラスター名は、DNS レコードの設定時に指定したクラスター名と一致する必要があります。
オプション:
install.config.yaml
ファイル内の 1 つ以上のデフォルト設定パラメーターを更新して、インストールをカスタマイズします。パラメーターの詳細は、「インストール設定パラメーター」を参照してください。
注記3 ノードクラスターをインストールする場合は、必ず
compute.replicas
パラメーターを0
に設定してください。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細は、「Nutanix への 3 ノードクラスターのインストール」を参照してください。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
3.7.1. Nutanix 用にカスタマイズされた install-config.yaml ファイルのサンプル
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com 1 compute: 2 - hyperthreading: Enabled 3 name: worker replicas: 3 platform: nutanix: 4 cpus: 2 coresPerSocket: 2 memoryMiB: 8196 osDisk: diskSizeGiB: 120 categories: 5 - key: <category_key_name> value: <category_value> controlPlane: 6 hyperthreading: Enabled 7 name: master replicas: 3 platform: nutanix: 8 cpus: 4 coresPerSocket: 2 memoryMiB: 16384 osDisk: diskSizeGiB: 120 categories: 9 - key: <category_key_name> value: <category_value> metadata: creationTimestamp: null name: test-cluster 10 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes 11 serviceNetwork: - 172.30.0.0/16 platform: nutanix: apiVIPs: - 10.40.142.7 12 defaultMachinePlatform: bootType: Legacy categories: 13 - key: <category_key_name> value: <category_value> project: 14 type: name name: <project_name> ingressVIPs: - 10.40.142.8 15 prismCentral: endpoint: address: your.prismcentral.domainname 16 port: 9440 17 password: <password> 18 username: <username> 19 prismElements: - endpoint: address: your.prismelement.domainname port: 9440 uuid: 0005b0f1-8f43-a0f2-02b7-3cecef193712 subnetUUIDs: - c7938dc6-7659-453e-a688-e26020c68e43 clusterOSImage: http://example.com/images/rhcos-47.83.202103221318-0-nutanix.x86_64.qcow2 20 credentialsMode: Manual publish: External pullSecret: '{"auths": ...}' 21 fips: false 22 sshKey: ssh-ed25519 AAAA... 23
- 1 10 12 15 16 17 18 19 21
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 6
controlPlane
セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。どちらのセクションも、現時点では単一のマシンプールを定義しますが、OpenShift Container Platform の今後のバージョンでは、インストール時の複数のコンピュートプールの定義をサポートする可能性があります。1 つのコントロールプレーンプールのみが使用されます。- 3 7
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。
- 4 8
- オプション: コンピュートおよびコントロールプレーンマシンのマシンプールパラメーターの追加設定を指定します。
- 5 9 13
- オプション: プリズムカテゴリーキーとプリズムカテゴリー値のペアを 1 つ以上指定します。これらのカテゴリーのキーと値のペアは、Prism Central に存在する必要があります。コンピューティングマシン、コントロールプレーンマシン、またはすべてのマシンに個別のカテゴリーを指定できます。
- 11
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 14
- オプション: VM が関連付けられているプロジェクトを指定します。プロジェクトタイプの
name
またはuuid
を指定してから、対応する UUID またはプロジェクト名を指定します。プロジェクトは、コンピューティングマシン、コントロールプレーンマシン、またはすべてのマシンに関連付けることができます。 - 20
- オプション: デフォルトでは、インストールプログラムは Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードしてインストールします。Prism Central がインターネットにアクセスできない場合は、任意の HTTP サーバーで RHCOS イメージをホストし、インストールプログラムがそのイメージを指すようにすることで、デフォルトの動作をオーバーライドできます。
- 22
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
- 23
- オプション: クラスター内のマシンにアクセスするのに使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。
3.7.2. 障害ドメインの設定
障害ドメインは、コントロールプレーンとコンピュートマシンを複数の Nutanix Prism Element (クラスター) に分散することで、OpenShift Container Platform クラスターのフォールトトレランスを向上させます。
高可用性を確保するには、3 つの障害ドメインを設定することを推奨します。
前提条件
-
インストール設定ファイル (
install-config.yaml
) がある。
手順
install-config.yaml
ファイルを編集し、次のスタンザを追加して最初の障害ドメインを設定します。apiVersion: v1 baseDomain: example.com compute: # ... platform: nutanix: failureDomains: - name: <failure_domain_name> prismElement: name: <prism_element_name> uuid: <prism_element_uuid> subnetUUIDs: - <network_uuid> # ...
ここでは、以下のようになります。
<failure_domain_name>
-
障害ドメインの一意の名前を指定します。名前は 64 文字以下に制限されており、小文字、数字、ダッシュ (
-
) を含めることができます。ダッシュを名前の先頭または末尾に含めることはできません。 <prism_element_name>
- オプション: Prism Element の名前を指定します。
<prism_element_uuid
>- Prism Element の UUID を指定します。
<network_uuid
>- Prism Element サブネットオブジェクトの UUID を指定します。サブネットの IP アドレス接頭辞 (CIDR) には、OpenShift Container Platform クラスターが使用する仮想 IP アドレスを含める必要があります。OpenShift Container Platform クラスター内の障害ドメイン (Prism Element) ごとに 1 つのサブネットのみがサポートされます。
- 必要に応じて、追加の障害ドメインを設定します。
コントロールプレーンとコンピュートマシンを障害ドメイン全体に分散するには、次のいずれかを実行します。
コンピューティングプレーンとコントロールプレーンのマシンが同じ障害ドメインセットを共有できる場合は、クラスターのデフォルトのマシン設定の下に障害ドメイン名を追加します。
障害ドメインセットを共有するコントロールプレーンとコンピュートマシンの例
apiVersion: v1 baseDomain: example.com compute: # ... platform: nutanix: defaultMachinePlatform: failureDomains: - failure-domain-1 - failure-domain-2 - failure-domain-3 # ...
コンピュートマシンとコントロールプレーンマシンが別々の障害ドメインを使用する必要がある場合は、それぞれのマシンプールの下に障害ドメイン名を追加します。
別々の障害ドメインを使用するコントロールプレーンとコンピュートマシンの例
apiVersion: v1 baseDomain: example.com compute: # ... controlPlane: platform: nutanix: failureDomains: - failure-domain-1 - failure-domain-2 - failure-domain-3 # ... compute: platform: nutanix: failureDomains: - failure-domain-1 - failure-domain-2 # ...
- ファイルを保存します。
3.7.3. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml
ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yaml
ファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxy
オブジェクトのspec.noProxy
フィールドに追加している。注記Proxy
オブジェクトのstatus.noProxy
フィールドには、インストール設定のnetworking.machineNetwork[].cidr
、networking.clusterNetwork[].cidr
、およびnetworking.serviceNetwork[]
フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxy
オブジェクトのstatus.noProxy
フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254
) も設定されます。
手順
install-config.yaml
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: example.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundle
という名前の設定マップをopenshift-config
namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージするtrusted-ca-bundle
設定マップを作成し、この設定マップはProxy
オブジェクトのtrustedCA
フィールドで参照されます。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。 - 5
- オプション:
trustedCA
フィールドのuser-ca-bundle
設定マップを参照するProxy
オブジェクトの設定を決定するポリシー。許可される値はProxyonly
およびAlways
です。Proxyonly
を使用して、http/https
プロキシーが設定されている場合にのみuser-ca-bundle
設定マップを参照します。Always
を使用して、常にuser-ca-bundle
設定マップを参照します。デフォルト値はProxyonly
です。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。注記インストーラーがタイムアウトした場合は、インストーラーの
wait-for
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。$ ./openshift-install wait-for install-complete --log-level debug
- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
3.8. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.17 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.17 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。$ oc <command>
3.9. Nutanix の IAM の設定
クラスターをインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。インストールプログラムが手動モード用に CCO を設定する間、ID およびアクセス管理シークレットを指定する必要があります。
前提条件
-
ccoctl
バイナリーを設定している。 -
install-config.yaml
ファイルがある。
手順
認証情報データを含む YAML ファイルを次の形式で作成します。
認証情報データの形式
credentials: - type: basic_auth 1 data: prismCentral: 2 username: <username_for_prism_central> password: <password_for_prism_central> prismElements: 3 - name: <name_of_prism_element> username: <username_for_prism_element> password: <password_for_prism_element>
次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
カスタムリソース (CR) のリストを抽出します。$ oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \1 --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2 --to=<path_to_directory_for_credentials_requests> 3
サンプル
CredentialsRequest
オブジェクトapiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: annotations: include.release.openshift.io/self-managed-high-availability: "true" labels: controller-tools.k8s.io: "1.0" name: openshift-machine-api-nutanix namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: NutanixProviderSpec secretRef: name: nutanix-credentials namespace: openshift-machine-api
次のコマンドを実行し、
ccoctl
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl nutanix create-shared-secrets \ --credentials-requests-dir=<path_to_credentials_requests_directory> \1 --output-dir=<ccoctl_output_dir> \2 --credentials-source-filepath=<path_to_credentials_file> 3
credentialsMode
パラメーターがManual
に設定されるように、install-config.yaml
設定ファイルを編集します。サンプル
install-config.yaml
設定ファイルapiVersion: v1 baseDomain: cluster1.example.com credentialsMode: Manual 1 ...
- 1
- この行を追加して、
credentialsMode
パラメーターをManual
に設定します。
次のコマンドを実行して、インストールマニフェストを作成します。
$ openshift-install create manifests --dir <installation_directory> 1
- 1
- クラスターの
install-config.yaml
ファイルを含むディレクトリーへのパスを指定します。
次のコマンドを実行して、生成された認証情報ファイルをターゲットマニフェストディレクトリーにコピーします。
$ cp <ccoctl_output_dir>/manifests/*credentials.yaml ./<installation_directory>/manifests
検証
manifests
ディレクトリーに適切なシークレットが存在することを確認します。$ ls ./<installation_directory>/manifests
出力例
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 kube-cloud-config.yaml kube-system-configmap-root-ca.yaml machine-config-server-tls-secret.yaml openshift-config-secret-pull-secret.yaml openshift-cloud-controller-manager-nutanix-credentials-credentials.yaml openshift-machine-api-nutanix-credentials-credentials.yaml
3.10. Nutanix CCM に必要な config map とシークレットリソースの追加
Nutanix にインストールするには、Nutanix Cloud Controller Manager (CCM) と統合するために追加の ConfigMap
および Secret
リソースが必要です。
前提条件
-
インストールディレクトリー内に
manifests
ディレクトリーが作成されました。
手順
manifests
ディレクトリーに移動します。$ cd <path_to_installation_directory>/manifests
openshift-cloud-controller-manager-cloud-config.yaml
という名前でcloud-conf
ConfigMap
ファイルを作成し、以下の情報を追加します。apiVersion: v1 kind: ConfigMap metadata: name: cloud-conf namespace: openshift-cloud-controller-manager data: cloud.conf: "{ \"prismCentral\": { \"address\": \"<prism_central_FQDN/IP>\", 1 \"port\": 9440, \"credentialRef\": { \"kind\": \"Secret\", \"name\": \"nutanix-credentials\", \"namespace\": \"openshift-cloud-controller-manager\" } }, \"topologyDiscovery\": { \"type\": \"Prism\", \"topologyCategories\": null }, \"enableCustomLabeling\": true }"
- 1
- Prism Central FQDN/IP を指定します。
ファイル
cluster-infrastructor-02-config.yml
が存在し、次の情報が含まれていることを確認します。spec: cloudConfig: key: config name: cloud-provider-config
3.11. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.log
にも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com INFO Login to the console with user: "kubeadmin", and password: "password" INFO Time elapsed: 36m22s
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
3.12. デフォルトのストレージコンテナーの設定
クラスターをインストールしたら、Nutanix CSI Operator をインストールし、クラスターのデフォルトのストレージコンテナーを設定する必要があります。
詳細は、CSI Operator のインストール と レジストリーストレージの設定 に関する Nutanix のドキュメントを参照してください。
3.13. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
3.14. 関連情報
3.15. 次のステップ
第4章 ネットワークが制限された環境での Nutanix へのクラスターのインストール
OpenShift Container Platform 4.15 では、インストールリリースコンテンツの内部ミラーを作成すると、制限されたネットワーク内の Nutanix インフラストラクチャーにクラスターをインストールできます。
4.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- インストールプログラムで、Prism Central および Prism Element のポート 9440 にアクセスできる。ポート 9440 にアクセスできることを確認している。
ファイアウォールを使用している場合は、次の前提条件を満たしています。
- ポート 9440 にアクセスできることを確認している。コントロールプレーンノードがポート 9440 で Prism Central および Prism Element にアクセスできる (インストールが成功するために必要)。
- OpenShift Container Platform が必要とするサイトへの アクセスを許可する ようにファイアウォールを設定している。これには、Telemetry の使用が含まれます。
Nutanix 環境でデフォルトの自己署名 SSL/TLS 証明書を使用している場合は、CA によって署名された証明書に置き換える。インストールプログラムには、Prism Central API にアクセスするための有効な CA 署名付き証明書が必要です。自己署名証明書の置き換えに関する詳細は、Nutanix AOS Security Guide を参照してください。
Nutanix 環境で内部 CA を使用して証明書を発行する場合は、インストールプロセスの一部としてクラスター全体のプロキシーを設定する必要があります。詳細は、カスタム PKI の設定 を参照してください。
重要2048 ビット証明書を使用します。Prism Central 2022.x で 4096 ビット証明書を使用すると、インストールに失敗します。
- Red Hat Quay などのコンテナーイメージレジストリーがある。レジストリーがまだない場合は、Red Hat OpenShift のミラーレジストリー を使用してミラーレジストリーを作成できます。
oc-mirror OpenShift CLI (oc) プラグイン を使用して、必要なすべての OpenShift Container Platform コンテンツと、Nutanix CSI Operator を含むその他のイメージをミラーレジストリーにミラーリングした。
重要インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。
4.2. ネットワークが制限された環境でのインストールについて
OpenShift Container Platform 4.15 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、インストーラーでプロビジョニングされるインフラストラクチャーまたはユーザーによってプロビジョニングされるインフラストラクチャーを使用して実行できます。
クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。
ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。
4.2.1. その他の制限
ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。
-
ClusterVersion
ステータスにはUnable to retrieve available updates
エラーが含まれます。 - デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。
4.3. クラスターノードの 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
ディレクトリーにあることを確認します。
注記x86_64
、ppc64le
、およびs390x
アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、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 パブリックキーをインストールプログラムに指定します。
4.4. Nutanix root CA 証明書をシステム信頼に追加する
インストールプログラムは Prism Central API へのアクセスを必要とするため、OpenShift Container Platform クラスターをインストールする前に、Nutanix の信頼された root CA 証明書をシステム信頼に追加する必要があります。
手順
- Prism Central Web コンソールから、Nutanix root CA 証明書をダウンロードします。
- Nutanix root CA 証明書を含む圧縮ファイルを抽出します。
オペレーティングシステム用のファイルをシステム信頼に追加します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
# cp certs/lin/* /etc/pki/ca-trust/source/anchors
システム信頼を更新します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
# update-ca-trust extract
4.5. RHCOS クラスターイメージのダウンロード
Prism Central は、クラスターをインストールするために Red Hat Enterprise Linux CoreOS (RHCOS) イメージにアクセスする必要があります。インストールプログラムを使用して、RHCOS イメージを見つけてダウンロードし、内部 HTTP サーバーまたは Nutanix オブジェクトを介して利用できるようにすることができます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install coreos print-stream-json
コマンドの出力を使用して Nutanix イメージの場所を見つけ、リンクをクリックしてダウンロードします。
出力例
"nutanix": { "release": "411.86.202210041459-0", "formats": { "qcow2": { "disk": { "location": "https://rhcos.mirror.openshift.com/art/storage/releases/rhcos-4.11/411.86.202210041459-0/x86_64/rhcos-411.86.202210041459-0-nutanix.x86_64.qcow2", "sha256": "42e227cac6f11ac37ee8a2f9528bb3665146566890577fd55f9b950949e5a54b"
- 内部 HTTP サーバーまたは Nutanix オブジェクトを介してイメージを利用できるようにします。
-
ダウンロードしたイメージの場所に注意してください。クラスターをデプロイする前に、インストール設定ファイル (
install-config.yaml
) のplatform
セクションをイメージの場所で更新します。
RHCOS イメージを指定する install-config.yaml
ファイルのスニペット
platform: nutanix: clusterOSImage: http://example.com/images/rhcos-411.86.202210041459-0-nutanix.x86_64.qcow2
4.6. インストール設定ファイルの作成
Nutanix にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
-
レジストリーをミラーリングしたときに作成された
imageContentSourcePolicy.yaml
ファイルを用意する。 - ダウンロードした Red Hat Enterprise Linux CoreOS (RHCOS) イメージの場所を用意する。
- ミラーレジストリーの証明書の内容を取得している。
- Red Hat Enterprise Linux CoreOS (RHCOS) イメージを取得し、アクセス可能な場所にアップロードしました。
- Nutanix のネットワーク要件を満たしていることが確認されました。詳細は、「Nutanix へのインストールの準備」を参照してください。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットとするプラットフォームとして nutanix を選択します。
- Prism Central のドメイン名または IP アドレスを入力します。
- Prism Central へのログインに使用するポートを入力します。
Prism Central へのログインに使用する認証情報を入力します。
インストールプログラムが Prism Central に接続します。
- OpenShift Container Platform クラスターを管理する Prism Element を選択します。
- 使用するネットワークサブネットを選択します。
- コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
- クラスター Ingress に設定した仮想 IP アドレスを入力します。
- ベースドメインを入力します。このベースドメインは、DNS レコードで設定したものと同じである必要があります。
クラスターの記述名を入力します。
入力するクラスター名は、DNS レコードの設定時に指定したクラスター名と一致する必要があります。
install-config.yaml
ファイルで、platform.nutanix.clusterOSImage
の値をイメージの場所または名前に設定します。以下に例を示します。platform: nutanix: clusterOSImage: http://mirror.example.com/images/rhcos-47.83.202103221318-0-nutanix.x86_64.qcow2
install-config.yaml
ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。pullSecret
の値を更新して、レジストリーの認証情報を追加します。pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'
<mirror_host_name>
の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials>
の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。additionalTrustBundle
パラメーターおよび値を追加します。additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----
この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。
次の YAML の抜粋のようなイメージコンテンツリソースを追加します。
imageContentSources: - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: quay.io/openshift-release-dev/ocp-release - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: registry.redhat.io/ocp/release
これらの値には、レジストリーをミラーリングしたときに作成された
imageContentSourcePolicy.yaml
ファイルを使用します。オプション: パブリッシュストラテジーを
Internal
に設定します。publish: Internal
このオプションを設定すると、内部 Ingress コントローラーおよびプライベートロードバランサーを作成します。
オプション:
install.config.yaml
ファイル内の 1 つ以上のデフォルト設定パラメーターを更新して、インストールをカスタマイズします。パラメーターの詳細は、「インストール設定パラメーター」を参照してください。
注記3 ノードクラスターをインストールする場合は、必ず
compute.replicas
パラメーターを0
に設定してください。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細は、「{platform} への 3 ノードクラスターのインストール」を参照してください。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
4.6.1. Nutanix 用にカスタマイズされた install-config.yaml ファイルのサンプル
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com 1 compute: 2 - hyperthreading: Enabled 3 name: worker replicas: 3 platform: nutanix: 4 cpus: 2 coresPerSocket: 2 memoryMiB: 8196 osDisk: diskSizeGiB: 120 categories: 5 - key: <category_key_name> value: <category_value> controlPlane: 6 hyperthreading: Enabled 7 name: master replicas: 3 platform: nutanix: 8 cpus: 4 coresPerSocket: 2 memoryMiB: 16384 osDisk: diskSizeGiB: 120 categories: 9 - key: <category_key_name> value: <category_value> metadata: creationTimestamp: null name: test-cluster 10 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes 11 serviceNetwork: - 172.30.0.0/16 platform: nutanix: apiVIP: 10.40.142.7 12 ingressVIP: 10.40.142.8 13 defaultMachinePlatform: bootType: Legacy categories: 14 - key: <category_key_name> value: <category_value> project: 15 type: name name: <project_name> prismCentral: endpoint: address: your.prismcentral.domainname 16 port: 9440 17 password: <password> 18 username: <username> 19 prismElements: - endpoint: address: your.prismelement.domainname port: 9440 uuid: 0005b0f1-8f43-a0f2-02b7-3cecef193712 subnetUUIDs: - c7938dc6-7659-453e-a688-e26020c68e43 clusterOSImage: http://example.com/images/rhcos-47.83.202103221318-0-nutanix.x86_64.qcow2 20 credentialsMode: Manual publish: External pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' 21 fips: false 22 sshKey: ssh-ed25519 AAAA... 23 additionalTrustBundle: | 24 -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE----- imageContentSources: 25 - mirrors: - <local_registry>/<local_repository_name>/release source: quay.io/openshift-release-dev/ocp-release - mirrors: - <local_registry>/<local_repository_name>/release source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
- 1 10 12 13 16 17 18 19
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 6
controlPlane
セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。どちらのセクションも、現時点では単一のマシンプールを定義しますが、OpenShift Container Platform の今後のバージョンでは、インストール時の複数のコンピュートプールの定義をサポートする可能性があります。1 つのコントロールプレーンプールのみが使用されます。- 3 7
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。
- 4 8
- オプション: コンピュートおよびコントロールプレーンマシンのマシンプールパラメーターの追加設定を指定します。
- 5 9 14
- オプション: プリズムカテゴリーキーとプリズムカテゴリー値のペアを 1 つ以上指定します。これらのカテゴリーのキーと値のペアは、Prism Central に存在する必要があります。コンピューティングマシン、コントロールプレーンマシン、またはすべてのマシンに個別のカテゴリーを指定できます。
- 11
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 15
- オプション: VM が関連付けられているプロジェクトを指定します。プロジェクトタイプの
name
またはuuid
を指定してから、対応する UUID またはプロジェクト名を指定します。プロジェクトは、コンピューティングマシン、コントロールプレーンマシン、またはすべてのマシンに関連付けることができます。 - 20
- オプション: デフォルトでは、インストールプログラムは Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードしてインストールします。Prism Central がインターネットにアクセスできない場合は、任意の HTTP サーバーまたは Nutanix オブジェクトで RHCOS イメージをホストし、インストールプログラムがそのイメージを指すようにすることで、デフォルトの動作をオーバーライドできます。
- 21
<local_registry>
には、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例:registry.example.com
またはregistry.example.com:5000
<credentials>
に、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。- 22
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
- 23
- オプション: クラスター内のマシンにアクセスするのに使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 24
- ミラーレジストリーに使用した証明書ファイルの内容を指定します。
- 25
- レジストリーをミラーリングしたときに作成された
imageContentSourcePolicy.yaml
ファイルのmetadata.name: release-0
セクションからこれらの値を指定します。
4.6.2. 障害ドメインの設定
障害ドメインは、コントロールプレーンとコンピュートマシンを複数の Nutanix Prism Element (クラスター) に分散することで、OpenShift Container Platform クラスターのフォールトトレランスを向上させます。
高可用性を確保するには、3 つの障害ドメインを設定することを推奨します。
前提条件
-
インストール設定ファイル (
install-config.yaml
) がある。
手順
install-config.yaml
ファイルを編集し、次のスタンザを追加して最初の障害ドメインを設定します。apiVersion: v1 baseDomain: example.com compute: # ... platform: nutanix: failureDomains: - name: <failure_domain_name> prismElement: name: <prism_element_name> uuid: <prism_element_uuid> subnetUUIDs: - <network_uuid> # ...
ここでは、以下のようになります。
<failure_domain_name>
-
障害ドメインの一意の名前を指定します。名前は 64 文字以下に制限されており、小文字、数字、ダッシュ (
-
) を含めることができます。ダッシュを名前の先頭または末尾に含めることはできません。 <prism_element_name>
- オプション: Prism Element の名前を指定します。
<prism_element_uuid
>- Prism Element の UUID を指定します。
<network_uuid
>- Prism Element サブネットオブジェクトの UUID を指定します。サブネットの IP アドレス接頭辞 (CIDR) には、OpenShift Container Platform クラスターが使用する仮想 IP アドレスを含める必要があります。OpenShift Container Platform クラスター内の障害ドメイン (Prism Element) ごとに 1 つのサブネットのみがサポートされます。
- 必要に応じて、追加の障害ドメインを設定します。
コントロールプレーンとコンピュートマシンを障害ドメイン全体に分散するには、次のいずれかを実行します。
コンピューティングプレーンとコントロールプレーンのマシンが同じ障害ドメインセットを共有できる場合は、クラスターのデフォルトのマシン設定の下に障害ドメイン名を追加します。
障害ドメインセットを共有するコントロールプレーンとコンピュートマシンの例
apiVersion: v1 baseDomain: example.com compute: # ... platform: nutanix: defaultMachinePlatform: failureDomains: - failure-domain-1 - failure-domain-2 - failure-domain-3 # ...
コンピュートマシンとコントロールプレーンマシンが別々の障害ドメインを使用する必要がある場合は、それぞれのマシンプールの下に障害ドメイン名を追加します。
別々の障害ドメインを使用するコントロールプレーンとコンピュートマシンの例
apiVersion: v1 baseDomain: example.com compute: # ... controlPlane: platform: nutanix: failureDomains: - failure-domain-1 - failure-domain-2 - failure-domain-3 # ... compute: platform: nutanix: failureDomains: - failure-domain-1 - failure-domain-2 # ...
- ファイルを保存します。
4.6.3. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml
ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yaml
ファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxy
オブジェクトのspec.noProxy
フィールドに追加している。注記Proxy
オブジェクトのstatus.noProxy
フィールドには、インストール設定のnetworking.machineNetwork[].cidr
、networking.clusterNetwork[].cidr
、およびnetworking.serviceNetwork[]
フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxy
オブジェクトのstatus.noProxy
フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254
) も設定されます。
手順
install-config.yaml
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: example.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundle
という名前の設定マップをopenshift-config
namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージするtrusted-ca-bundle
設定マップを作成し、この設定マップはProxy
オブジェクトのtrustedCA
フィールドで参照されます。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。 - 5
- オプション:
trustedCA
フィールドのuser-ca-bundle
設定マップを参照するProxy
オブジェクトの設定を決定するポリシー。許可される値はProxyonly
およびAlways
です。Proxyonly
を使用して、http/https
プロキシーが設定されている場合にのみuser-ca-bundle
設定マップを参照します。Always
を使用して、常にuser-ca-bundle
設定マップを参照します。デフォルト値はProxyonly
です。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。注記インストーラーがタイムアウトした場合は、インストーラーの
wait-for
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。$ ./openshift-install wait-for install-complete --log-level debug
- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.7. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.17 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.17 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。$ oc <command>
4.8. Nutanix の IAM の設定
クラスターをインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。インストールプログラムが手動モード用に CCO を設定する間、ID およびアクセス管理シークレットを指定する必要があります。
前提条件
-
ccoctl
バイナリーを設定している。 -
install-config.yaml
ファイルがある。
手順
認証情報データを含む YAML ファイルを次の形式で作成します。
認証情報データの形式
credentials: - type: basic_auth 1 data: prismCentral: 2 username: <username_for_prism_central> password: <password_for_prism_central> prismElements: 3 - name: <name_of_prism_element> username: <username_for_prism_element> password: <password_for_prism_element>
次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
カスタムリソース (CR) のリストを抽出します。$ oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \1 --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2 --to=<path_to_directory_for_credentials_requests> 3
サンプル
CredentialsRequest
オブジェクトapiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: annotations: include.release.openshift.io/self-managed-high-availability: "true" labels: controller-tools.k8s.io: "1.0" name: openshift-machine-api-nutanix namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: NutanixProviderSpec secretRef: name: nutanix-credentials namespace: openshift-machine-api
次のコマンドを実行し、
ccoctl
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl nutanix create-shared-secrets \ --credentials-requests-dir=<path_to_credentials_requests_directory> \1 --output-dir=<ccoctl_output_dir> \2 --credentials-source-filepath=<path_to_credentials_file> 3
credentialsMode
パラメーターがManual
に設定されるように、install-config.yaml
設定ファイルを編集します。サンプル
install-config.yaml
設定ファイルapiVersion: v1 baseDomain: cluster1.example.com credentialsMode: Manual 1 ...
- 1
- この行を追加して、
credentialsMode
パラメーターをManual
に設定します。
次のコマンドを実行して、インストールマニフェストを作成します。
$ openshift-install create manifests --dir <installation_directory> 1
- 1
- クラスターの
install-config.yaml
ファイルを含むディレクトリーへのパスを指定します。
次のコマンドを実行して、生成された認証情報ファイルをターゲットマニフェストディレクトリーにコピーします。
$ cp <ccoctl_output_dir>/manifests/*credentials.yaml ./<installation_directory>/manifests
検証
manifests
ディレクトリーに適切なシークレットが存在することを確認します。$ ls ./<installation_directory>/manifests
出力例
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 kube-cloud-config.yaml kube-system-configmap-root-ca.yaml machine-config-server-tls-secret.yaml openshift-config-secret-pull-secret.yaml openshift-cloud-controller-manager-nutanix-credentials-credentials.yaml openshift-machine-api-nutanix-credentials-credentials.yaml
4.9. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.log
にも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com INFO Login to the console with user: "kubeadmin", and password: "password" INFO Time elapsed: 36m22s
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.10. インストール後の設定
以下の手順を実行して、クラスターの設定を完了します。
4.10.1. デフォルトの OperatorHub カタログソースの無効化
Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。
手順
disableAllDefaultSources: true
をOperatorHub
オブジェクトに追加して、デフォルトカタログのソースを無効にします。$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
または、Web コンソールを使用してカタログソースを管理できます。Administration → Cluster Settings → Configuration → OperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。
4.10.2. クラスターへのポリシーリソースのインストール
oc-mirror OpenShift CLI (oc) プラグインを使用して OpenShift Container Platform コンテンツをミラーリングすると、catalogSource-certified-operator-index.yaml
および imageContentSourcePolicy.yaml
を含むリソースが作成されます。
-
ImageContentSourcePolicy
リソースは、ミラーレジストリーをソースレジストリーに関連付け、イメージプル要求をオンラインレジストリーからミラーレジストリーにリダイレクトします。 -
CatalogSource
リソースは、Operator Lifecycle Manager (OLM) によって使用され、ミラーレジストリーで使用可能な Operator に関する情報を取得します。これにより、ユーザーは Operator を検出してインストールできます。
クラスターをインストールしたら、これらのリソースをクラスターにインストールする必要があります。
前提条件
- 非接続環境で、イメージセットをレジストリーミラーにミラーリングしました。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
-
cluster-admin
ロールを持つユーザーとして OpenShift CLI にログインします。 results ディレクトリーからクラスターに YAML ファイルを適用します。
$ oc apply -f ./oc-mirror-workspace/results-<id>/
検証
ImageContentSourcePolicy
リソースが正常にインストールされたことを確認します。$ oc get imagecontentsourcepolicy
CatalogSource
リソースが正常にインストールされたことを確認します。$ oc get catalogsource --all-namespaces
4.10.3. デフォルトのストレージコンテナーの設定
クラスターをインストールしたら、Nutanix CSI Operator をインストールし、クラスターのデフォルトのストレージコンテナーを設定する必要があります。
詳細は、CSI Operator のインストール と レジストリーストレージの設定 に関する Nutanix のドキュメントを参照してください。
4.11. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
4.12. 関連情報
4.13. 次のステップ
- 必要に応じて、リモートヘルスレポートのオプトアウト を参照してください。
- 必要に応じて、非接続クラスターの登録 を参照してください。
- クラスターのカスタマイズ
第5章 Nutanix への 3 ノードクラスターのインストール
OpenShift Container Platform バージョン 4.15 では、Nutanix に 3 ノードクラスターをインストールできます。3 ノードクラスターは、コンピューティングマシンとしても機能する 3 つのコントロールプレーンマシンで設定されます。このタイプのクラスターは、クラスター管理者および開発者がテスト、開発、および実稼働に使用するためのより小さくリソース効率の高いクラスターを提供します。
5.1. 3 ノードクラスターの設定
クラスターをデプロイする前に、install-config.yaml
ファイルでワーカーノードの数を 0
に設定して、3 ノードクラスターを設定します。ワーカーノードの数を 0
に設定すると、コントロールプレーンマシンがスケジュール可能になります。これにより、アプリケーションワークロードをコントロールプレーンノードから実行するようにスケジュールできます。
アプリケーションワークロードはコントロールプレーンノードから実行され、コントロールプレーンノードはコンピュートノードと見なされるため、追加のサブスクリプションが必要です。
前提条件
-
既存の
install-config.yaml
ファイルがある。
手順
次の
compute
スタンザに示すように、install-config.yaml
ファイルでコンピューティングレプリカの数を0
に設定します。3 ノードクラスターの
install-config.yaml
ファイルの例apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ...
5.2. 次のステップ
第6章 Nutanix でのクラスターのアンインストール
Nutanix にデプロイしたクラスターを削除できます。
6.1. installer-provisioned infrastructure を使用するクラスターの削除
installer-provisioned infrastructure を使用するクラスターは、クラウドから削除できます。
アンインストール後に、とくに user-provisioned infrastructure (UPI) クラスターで適切に削除されていないリソースがあるかどうかについて、クラウドプロバイダーを確認します。インストーラーが作成されなかったり、インストーラーがアクセスできない場合には、リソースがある可能性があります。
前提条件
- クラスターをデプロイするために使用したインストールプログラムのコピーがあります。
- クラスター作成時にインストールプログラムが生成したファイルがあります。
手順
クラスターをインストールするために使用したコンピューターのインストールプログラムが含まれるディレクトリーから、以下のコマンドを実行します。
$ ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2
注記クラスターのクラスター定義ファイルが含まれるディレクトリーを指定する必要があります。クラスターを削除するには、インストールプログラムでこのディレクトリーにある
metadata.json
ファイルが必要になります。-
オプション:
<installation_directory>
ディレクトリーおよび OpenShift Container Platform インストールプログラムを削除します。
第7章 Nutanix のインストール設定パラメーター
OpenShift Container Platform クラスターを Nutanix にデプロイする前に、クラスターとそれをホストするプラットフォームをカスタマイズするためのパラメーターを指定します。install-config.yaml
ファイルを作成するときは、コマンドラインを使用して必要なパラメーターの値を指定します。その後、install-config.yaml
ファイルを変更して、クラスターをさらにカスタマイズできます。
7.1. Nutanix で使用可能なインストール設定パラメーター
次の表では、インストールプロセスの一部として設定できる、必須、オプション、および Nutanix 固有のインストール設定パラメーターを指定します。
インストール後は、これらのパラメーターを install-config.yaml
ファイルで変更することはできません。
7.1.1. 必須設定パラメーター
必須のインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
apiVersion: |
| 文字列 |
baseDomain: |
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
metadata: |
Kubernetes リソース | オブジェクト |
metadata: name: |
クラスターの名前。クラスターの DNS レコードはすべて |
小文字いちぶハイフン ( |
platform: |
インストールを実行する特定のプラットフォームの設定: | オブジェクト |
pullSecret: | 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" } } } |
7.1.2. ネットワーク設定パラメーター
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。
パラメーター | 説明 | 値 |
---|---|---|
networking: | クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
networking: networkType: | インストールする Red Hat OpenShift Networking ネットワークプラグイン。 |
|
networking: clusterNetwork: | Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 |
networking: clusterNetwork: cidr: |
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
networking: clusterNetwork: hostPrefix: |
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
networking: serviceNetwork: |
サービスの IP アドレスブロック。デフォルト値は OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16 |
networking: machineNetwork: | マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16 |
networking: machineNetwork: cidr: |
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
7.1.3. オプションの設定パラメーター
オプションのインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
additionalTrustBundle: | ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
capabilities: | オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。 | 文字列配列 |
capabilities: baselineCapabilitySet: |
有効にするオプション機能の初期セットを選択します。有効な値は | 文字列 |
capabilities: additionalEnabledCapabilities: |
オプションの機能のセットを、 | 文字列配列 |
cpuPartitioningMode: | ワークロードパーティション設定を使用して、OpenShift Container Platform サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod を分離し、予約された CPU セットで実行できます。ワークロードパーティショニングはインストール中にのみ有効にすることができ、インストール後に無効にすることはできません。このフィールドはワークロードのパーティショニングを有効にしますが、特定の CPU を使用するようにワークロードを設定するわけではありません。詳細は、スケーラビリティとパフォーマンス セクションの ワークロードパーティショニング ページを参照してください。 |
|
compute: | コンピュートノードを構成するマシンの設定。 |
|
compute: architecture: |
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
compute: hyperthreading: |
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
compute: name: |
|
|
compute: platform: |
|
|
compute: replicas: | プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
featureSet: | 機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。 |
文字列。 |
controlPlane: | コントロールプレーンを構成するマシンの設定。 |
|
controlPlane: architecture: |
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
controlPlane: hyperthreading: |
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
controlPlane: name: |
|
|
controlPlane: platform: |
|
|
controlPlane: replicas: | プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
credentialsMode: | Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 |
|
fips: |
FIPS モードを有効または無効にします。デフォルトは 重要 クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
imageContentSources: | release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
imageContentSources: source: |
| 文字列 |
imageContentSources: mirrors: | 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
publish: | Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
このパラメーターを 重要
フィールドの値が |
sshKey: | クラスターマシンへのアクセスを認証するための SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
たとえば、 |
- すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、認証と認可 コンテンツの「クラウドプロバイダーの認証情報の管理」を参照してください。
7.1.4. 追加の Nutanix 設定パラメーター
追加の Nutanix 設定パラメーターについては、次の表で説明します。
パラメーター | 説明 | 値 |
---|---|---|
compute: platform: nutanix: categories: key: |
コンピューティング VM に適用するプリズムカテゴリーのキーの名前。このパラメーターには、 | 文字列 |
compute: platform: nutanix: categories: value: |
コンピューティング VM に適用するプリズムカテゴリーのキーと値のペアの値。このパラメーターには、 | 文字列 |
compute: platform: nutanix: failureDomains: | コンピュートマシンのみに適用する障害ドメイン。
障害ドメインは | List。 1 つ以上の障害ドメインの名前。 |
compute: platform: nutanix: project: type: | コンピューティング VM のプロジェクトを選択するために使用する識別子のタイプ。プロジェクトは、権限、ネットワーク、およびその他のパラメーターを管理するためのユーザーロールの論理グループを定義します。プロジェクトの詳細は、プロジェクトの概要 を参照してください。 |
|
compute: platform: nutanix: project: name: or uuid: |
コンピューティング VM が関連付けられているプロジェクトの名前または UUID。このパラメーターには、 | 文字列 |
compute: platform: nutanix: bootType: |
コンピューティングマシンが使用するブートタイプ。OpenShift Container Platform 4.15 では、 |
|
controlPlane: platform: nutanix: categories: key: |
コントロールプレーン VM に適用するプリズムカテゴリーのキーの名前。このパラメーターには、 | 文字列 |
controlPlane: platform: nutanix: categories: value: |
コントロールプレーン VM に適用するプリズムカテゴリーのキーと値のペアの値。このパラメーターには、 | 文字列 |
controlPlane: platform: nutanix: failureDomains: | コントロールプレーンマシンのみに適用する障害ドメイン。
障害ドメインは | List。 1 つ以上の障害ドメインの名前。 |
controlPlane: platform: nutanix: project: type: | コントロールプレーン VM のプロジェクトを選択するために使用する識別子のタイプ。プロジェクトは、権限、ネットワーク、およびその他のパラメーターを管理するためのユーザーロールの論理グループを定義します。プロジェクトの詳細は、プロジェクトの概要 を参照してください。 |
|
controlPlane: platform: nutanix: project: name: or uuid: |
コントロールプレーン VM が関連付けられているプロジェクトの名前または UUID。このパラメーターには、 | 文字列 |
platform: nutanix: defaultMachinePlatform: categories: key: |
すべての VM に適用するプリズムカテゴリーのキーの名前。このパラメーターには、 | 文字列 |
platform: nutanix: defaultMachinePlatform: categories: value: |
すべての VM に適用するプリズムカテゴリーのキーと値のペアの値。このパラメーターには、 | 文字列 |
platform: nutanix: defaultMachinePlatform: failureDomains: | コントロールプレーンとコンピュートマシンの両方に適用する障害ドメイン。
障害ドメインは | List。 1 つ以上の障害ドメインの名前。 |
platform: nutanix: defaultMachinePlatform: project: type: | すべての VM のプロジェクトを選択するために使用する識別子のタイプ。プロジェクトは、権限、ネットワーク、およびその他のパラメーターを管理するためのユーザーロールの論理グループを定義します。プロジェクトの詳細は、プロジェクトの概要 を参照してください。 |
|
platform: nutanix: defaultMachinePlatform: project: name: or uuid: |
すべての VM が関連付けられているプロジェクトの名前または UUID。このパラメーターには、 | 文字列 |
platform: nutanix: defaultMachinePlatform: bootType: |
すべてのマシンのブートタイプ。OpenShift Container Platform 4.15 では、 |
|
platform: nutanix: apiVIP: | コントロールプレーン API のアクセス用に設定した仮想 IP (VIP) アドレス。 | IP アドレス |
platform: nutanix: failureDomains: - name: prismElement: name: uuid: subnetUUIDs: - | デフォルトでは、インストールプログラムはクラスターマシンを単一の Prism Element インスタンスにインストールします。フォールトトレランスのために追加の Prism Element インスタンスを指定し、そのインスタンスを次のものに適用できます。
| 設定した障害ドメインのリスト。 使用方法の詳細は、「Nutanix へのクラスターのインストール」の「障害ドメインの設定」を参照してください。 |
platform: nutanix: ingressVIP: | クラスター Ingress に設定した仮想 IP (VIP) アドレス。 | IP アドレス |
platform: nutanix: prismCentral: endpoint: address: | Prism Central ドメイン名または IP アドレス。 | 文字列 |
platform: nutanix: prismCentral: endpoint: port: | Prism Central へのログインに使用されるポート。 | 文字列 |
platform: nutanix: prismCentral: password: | Prism Central ユーザー名のパスワード。 | 文字列 |
platform: nutanix: prismCentral: username: | Prism Central へのログインに使用されるユーザー名。 | 文字列 |
platform: nutanix: prismElements: endpoint: address: | Prism Element ドメイン名または IP アドレス。 [1] | 文字列 |
platform: nutanix: prismElements: endpoint: port: | Prism Element へのログインに使用されるポート。 | 文字列 |
platform: nutanix: prismElements: uuid: | Prism Element の Universally Unique Identifier (UUID)。 | 文字列 |
platform: nutanix: subnetUUIDs: | 設定した仮想 IP アドレスと DNS レコードを含む Prism Element ネットワークの UUID。[2] | 文字列 |
platform: nutanix: clusterOSImage: | オプション: デフォルトでは、インストールプログラムは Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードしてインストールします。Prism Central がインターネットにアクセスできない場合は、任意の HTTP サーバーで RHCOS イメージをホストし、インストールプログラムがそのイメージを指すようにすることで、デフォルトの動作をオーバーライドできます。 | HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。例: http://example.com/images/rhcos-47.83.202103221318-0-nutanix.x86_64.qcow2 |
-
prismElements
セクションには、Prism Elements (クラスター) のリストが含まれています。Prism Element は、OpenShift Container Platform クラスターをホストするために使用されるすべての Nutanix リソース (仮想マシンやサブネットなど) を包含します。 - OpenShift Container Platform クラスター内の Prism Element ごとに 1 つのサブネットのみがサポートされます。
Legal Notice
Copyright © 2024 Red Hat, Inc.
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.