Nutanix へのインストール


OpenShift Container Platform 4.15

Nutanix への OpenShift Container Platform のインストール

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、Nutanix に OpenShift Container Platform をインストールする方法を説明します。

第1章 Nutanix へのインストールの準備

OpenShift Container Platform クラスターをインストールする前に、Nutanix 環境が以下の要件を満たしていることを確認してください。

1.1. Nutanix バージョン要件

以下の要件を満たす Nutanix 環境に OpenShift Container Platform クラスターをインストールする必要があります。

表1.1 Nutanix 仮想環境のバージョン要件
コンポーネント必須バージョン

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

常時

Create_Category_Mapping
Create_Or_Update_Name_Category
Create_Or_Update_Value_Category
Delete_Category_Mapping
Delete_Name_Category
Delete_Value_Category
View_Category_Mapping
View_Name_Category
View_Value_Category

OpenShift Container Platform マシンに割り当てられたカテゴリーを作成、読み取り、削除します。

Images

常時

Create_Image
Delete_Image
View_Image

OpenShift Container Platform マシンに使用されるオペレーティングシステムイメージを作成、読み取り、削除します。

仮想マシン

常時

Create_Virtual_Machine
Delete_Virtual_Machine
View_Virtual_Machine

OpenShift Container Platform マシンを作成、読み取り、削除します。

クラスター

常時

View_Cluster

OpenShift Container Platform マシンをホストする Prism Element クラスターを表示します。

サブネット

常時

View_Subnet

OpenShift Container Platform マシンをホストするサブネットを表示します。

プロジェクト

プロジェクトをコンピューティングマシン、コントロールプレーンマシン、またはすべてのマシンに関連付ける場合。

View_Project

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>. の形式を取ります。

表1.2 必要な DNS レコード
コンポーネントレコード説明

API VIP

api.<cluster_name>.<base_domain>.

この DNS A/AAAA または CNAME レコードは、コントロールプレーンマシンのロードバランサーを参照する必要があります。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

Ingress VIP

*.apps.<cluster_name>.<base_domain>.

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) がインストールされている。

手順

  1. 次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。

    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注記

    $RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。

  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

    $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
  4. 次のコマンドを実行して、権限を変更して 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 つの障害ドメインを設定することを推奨します。

手順

  1. 次のコマンドを実行して、インフラストラクチャー CR を編集します。

    $ oc edit infrastructures.config.openshift.io cluster
  2. 障害ドメインを設定します。

    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 つのサブネットのみがサポートされます。
  3. CR を保存して変更を適用します。

2.2.3. 障害ドメイン全体へのコントロールプレーンの分散

コントロールプレーンマシンセットのカスタムリソース (CR) を変更することで、Nutanix 障害ドメイン全体にコントロールプレーンを分散します。

前提条件

  • クラスターのインフラストラクチャーカスタムリソース (CR) で障害ドメインを設定している。
  • コントロールプレーンマシンセットのカスタムリソース (CR) がアクティブな状態である。

コントロールプレーンマシンセットのカスタムリソースの状態を確認する方法の詳細は、「関連情報」を参照してください。

手順

  1. 次のコマンドを実行して、コントロールプレーンマシンセット CR を編集します。

    $ oc edit controlplanemachineset.machine.openshift.io cluster -n openshift-machine-api
  2. 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>
    # ...

  3. 変更を保存します。

デフォルトでは、コントロールプレーンマシンセットは、変更をコントロールプレーン設定に自動的に反映します。クラスターが OnDelete 更新ストラテジーを使用するように設定されている場合は、コントロールプレーンを手動で置き換える必要があります。詳細は、「関連情報」を参照してください。

2.2.4. 障害ドメイン全体へのコンピュートマシンの分散

次のいずれかの方法で、Nutanix 障害ドメイン全体にコンピュートマシンを分散できます。

2.2.4.1. コンピュートマシンセットの編集による障害ドメインの実装

既存のコンピュートマシンセットを使用して Nutanix 障害ドメイン全体にコンピュートマシンを分散するには、設定でコンピュートマシンセットを更新し、スケーリングを使用して既存のコンピュートマシンを置き換えます。

前提条件

  • クラスターのインフラストラクチャーカスタムリソース (CR) で障害ドメインを設定している。

手順

  1. 次のコマンドを実行して、クラスターのインフラストラクチャー CR を表示します。

    $ oc describe infrastructures.config.openshift.io cluster
  2. 各障害ドメイン (platformSpec.nutanix.failureDomains) について、クラスターの UUID、名前、サブネットオブジェクト UUID をメモします。これらの値は、障害ドメインをコンピュートマシンセットに追加するために必要です。
  3. 以下のコマンドを実行して、クラスター内のコンピュートマシンセットを一覧表示します。

    $ 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

  4. 次のコマンドを実行して、最初のコンピュートマシンセットを編集します。

    $ oc edit machineset <machine_set_name_1> -n openshift-machine-api
  5. 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>
    # ...

  6. spec.replicas の値をメモします。この値は、変更を適用するためにコンピュートマシンセットをスケーリングする際に必要になるためです。
  7. 変更を保存します。
  8. 次のコマンドを実行して、更新されたコンピュートマシンセットによって管理されているマシンをリスト表示します。

    $ 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

  9. 次のコマンドを実行して、更新されたコンピュートマシンセットで管理されるマシンごとに delete アノテーションを設定します。

    $ oc annotate machine/<machine_name_original_1> \
      -n openshift-machine-api \
      machine.openshift.io/delete-machine="true"
  10. 代わりとなるマシンを新しい設定で作成するために、次のコマンドを実行して、コンピュートマシンセットをレプリカ数の 2 倍にスケーリングします。

    $ oc scale --replicas=<twice_the_number_of_replicas> \1
      machineset <machine_set_name_1> \
      -n openshift-machine-api
    1
    たとえば、コンピュートマシンセット内のレプリカの元の数が 2 の場合、レプリカを 4 にスケーリングします。
  11. 次のコマンドを実行して、更新されたコンピュートマシンセットによって管理されているマシンをリスト表示します。

    $ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<machine_set_name_1>

    新しいマシンが Running フェーズにある場合、コンピュートマシンセットを元のレプリカ数にスケーリングできます。

  12. 古い設定で作成されたマシンを削除するために、次のコマンドを実行して、コンピュートマシンセットを元のレプリカ数にスケーリングします。

    $ oc scale --replicas=<original_number_of_replicas> \1
      machineset <machine_set_name_1> \
      -n openshift-machine-api
    1
    たとえば、コンピュートマシンセット内のレプリカの元の数が 2 であった場合、レプリカを 2 にスケーリングします。
  13. 必要に応じて、デプロイメントで使用可能な追加の障害ドメインを参照するようにマシンセットの変更を続けます。
2.2.4.2. コンピュートマシンセットの置き換えによる障害ドメインの実装

コンピュートマシンセットを置き換えることによって、Nutanix 障害ドメイン全体にコンピュートマシンを分散するには、独自の設定で新しいコンピュートマシンセットを作成し、作成されたマシンが起動するのを待ってから、古いコンピュートマシンセットを削除します。

前提条件

  • クラスターのインフラストラクチャーカスタムリソース (CR) で障害ドメインを設定している。

手順

  1. 次のコマンドを実行して、クラスターのインフラストラクチャー CR を表示します。

    $ oc describe infrastructures.config.openshift.io cluster
  2. 各障害ドメイン (platformSpec.nutanix.failureDomains) について、クラスターの UUID、名前、サブネットオブジェクト UUID をメモします。これらの値は、障害ドメインをコンピュートマシンセットに追加するために必要です。
  3. 以下のコマンドを実行して、クラスター内のコンピュートマシンセットを一覧表示します。

    $ 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

  4. 既存のコンピュートマシンセットの名前に注意してください。
  5. 次のいずれかの方法を使用して、新しいコンピュートマシンセットのカスタムリソース (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
              ...

      1
      クラスターインフラストラクチャー ID。
      2
      デフォルトのノードラベル。
      注記

      user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットが作成できるのは、worker または infra ロールを持つマシンのみです。

      3
      コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細は、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。
  6. <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>
    # ...

  7. 変更を保存します。
  8. 次のコマンドを実行して、コンピュートマシンセット CR を作成します。

    $ oc create -f <new_machine_set_name_1>.yaml
  9. 必要に応じて、デプロイメントで使用可能な追加の障害ドメインを参照するコンピュートマシンセットの作成に進みます。
  10. 新しいコンピュートマシンセットごとに次のコマンドを実行して、新しいコンピュートマシンセットによって管理されているマシンをリスト表示します。

    $ 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 フェーズにある場合、障害ドメイン設定を含まない古いコンピュートマシンセットを削除できます。

  11. 新しいマシンが 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 Installerconsole.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 キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

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

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

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

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

    $ cat <path>/<file_name>.pub

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

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

    注記

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

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

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

      出力例

      Agent pid 31874

      注記

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

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

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

    出力例

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

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

3.5. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • Linux または macOS を実行し、少なくとも 1.2 GB のローカルディスク容量を備えたコンピューターがある。

手順

  1. Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
  3. OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。
  4. ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。

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

    $ tar -xvf openshift-install-linux.tar.gz
  6. 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 証明書をシステム信頼に追加する必要があります。

手順

  1. Prism Central Web コンソールから、Nutanix root CA 証明書をダウンロードします。
  2. Nutanix root CA 証明書を含む圧縮ファイルを抽出します。
  3. オペレーティングシステム用のファイルをシステム信頼に追加します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。

    # cp certs/lin/* /etc/pki/ca-trust/source/anchors
  4. システム信頼を更新します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。

    # update-ca-trust extract

3.7. インストール設定ファイルの作成

Nutanix にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • Nutanix のネットワーク要件を満たしていることが確認されました。詳細は、「Nutanix へのインストールの準備」を参照してください。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットとするプラットフォームとして nutanix を選択します。
      3. Prism Central のドメイン名または IP アドレスを入力します。
      4. Prism Central へのログインに使用するポートを入力します。
      5. Prism Central へのログインに使用する認証情報を入力します。

        インストールプログラムが Prism Central に接続します。

      6. OpenShift Container Platform クラスターを管理する Prism Element を選択します。
      7. 使用するネットワークサブネットを選択します。
      8. コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
      9. クラスター Ingress に設定した仮想 IP アドレスを入力します。
      10. ベースドメインを入力します。このベースドメインは、DNS レコードで設定したものと同じである必要があります。
      11. クラスターの記述名を入力します。

        入力するクラスター名は、DNS レコードの設定時に指定したクラスター名と一致する必要があります。

  2. オプション: install.config.yaml ファイル内の 1 つ以上のデフォルト設定パラメーターを更新して、インストールをカスタマイズします。

    パラメーターの詳細は、「インストール設定パラメーター」を参照してください。

    注記

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

  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) がある。

手順

  1. 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 つのサブネットのみがサポートされます。
  2. 必要に応じて、追加の障害ドメインを設定します。
  3. コントロールプレーンとコンピュートマシンを障害ドメイン全体に分散するには、次のいずれかを実行します。

    • コンピューティングプレーンとコントロールプレーンのマシンが同じ障害ドメインセットを共有できる場合は、クラスターのデフォルトのマシン設定の下に障害ドメイン名を追加します。

      障害ドメインセットを共有するコントロールプレーンとコンピュートマシンの例

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

3.7.3. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.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) も設定されます。

手順

  1. 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.comx.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
  2. ファイルを保存し、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 にインストールできます。

手順

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

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

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

    $ echo $PATH

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    $ oc <command>
Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

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

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

    C:\> path

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    C:\> oc <command>
macOS への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

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

    注記

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

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

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

    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    $ oc <command>

3.9. Nutanix の IAM の設定

クラスターをインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。インストールプログラムが手動モード用に CCO を設定する間、ID およびアクセス管理シークレットを指定する必要があります。

前提条件

  • ccoctl バイナリーを設定している。
  • install-config.yaml ファイルがある。

手順

  1. 認証情報データを含む 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>

    1
    認証タイプを指定します。Basic 認証のみがサポートされています。
    2
    Prism Central の認証情報を指定します。
    3
    オプション: Prism Element 認証情報を指定します。
  2. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  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
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

    サンプル 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

  4. 次のコマンドを実行し、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
    1
    コンポーネント CredentialsRequests オブジェクトのファイルを含むディレクトリーへのパスを指定します。
    2
    オプション: ccoctl ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。
    3
    オプション: 認証情報データ YAML ファイルを含むディレクトリーを指定します。デフォルトでは、ccoctl はこのファイルが <home_directory>/.nutanix/credentials にあると想定します。
  5. credentialsMode パラメーターが Manual に設定されるように、install-config.yaml 設定ファイルを編集します。

    サンプル install-config.yaml 設定ファイル

    apiVersion: v1
    baseDomain: cluster1.example.com
    credentialsMode: Manual 1
    ...

    1
    この行を追加して、credentialsMode パラメーターを Manual に設定します。
  6. 次のコマンドを実行して、インストールマニフェストを作成します。

    $ openshift-install create manifests --dir <installation_directory> 1
    1
    クラスターの install-config.yaml ファイルを含むディレクトリーへのパスを指定します。
  7. 次のコマンドを実行して、生成された認証情報ファイルをターゲットマニフェストディレクトリーにコピーします。

    $ 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 ディレクトリーが作成されました。

手順

  1. manifests ディレクトリーに移動します。

    $ cd <path_to_installation_directory>/manifests
  2. 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 を指定します。
  3. ファイル 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
    1
    <installation_directory> に、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、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 キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

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

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

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

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

    $ cat <path>/<file_name>.pub

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

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

    注記

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

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

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

      出力例

      Agent pid 31874

      注記

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

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

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

    出力例

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

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

4.4. Nutanix root CA 証明書をシステム信頼に追加する

インストールプログラムは Prism Central API へのアクセスを必要とするため、OpenShift Container Platform クラスターをインストールする前に、Nutanix の信頼された root CA 証明書をシステム信頼に追加する必要があります。

手順

  1. Prism Central Web コンソールから、Nutanix root CA 証明書をダウンロードします。
  2. Nutanix root CA 証明書を含む圧縮ファイルを抽出します。
  3. オペレーティングシステム用のファイルをシステム信頼に追加します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。

    # cp certs/lin/* /etc/pki/ca-trust/source/anchors
  4. システム信頼を更新します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。

    # update-ca-trust extract

4.5. RHCOS クラスターイメージのダウンロード

Prism Central は、クラスターをインストールするために Red Hat Enterprise Linux CoreOS (RHCOS) イメージにアクセスする必要があります。インストールプログラムを使用して、RHCOS イメージを見つけてダウンロードし、内部 HTTP サーバーまたは Nutanix オブジェクトを介して利用できるようにすることができます。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

    $ ./openshift-install coreos print-stream-json
  2. コマンドの出力を使用して 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"

  3. 内部 HTTP サーバーまたは Nutanix オブジェクトを介してイメージを利用できるようにします。
  4. ダウンロードしたイメージの場所に注意してください。クラスターをデプロイする前に、インストール設定ファイル (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 へのインストールの準備」を参照してください。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットとするプラットフォームとして nutanix を選択します。
      3. Prism Central のドメイン名または IP アドレスを入力します。
      4. Prism Central へのログインに使用するポートを入力します。
      5. Prism Central へのログインに使用する認証情報を入力します。

        インストールプログラムが Prism Central に接続します。

      6. OpenShift Container Platform クラスターを管理する Prism Element を選択します。
      7. 使用するネットワークサブネットを選択します。
      8. コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
      9. クラスター Ingress に設定した仮想 IP アドレスを入力します。
      10. ベースドメインを入力します。このベースドメインは、DNS レコードで設定したものと同じである必要があります。
      11. クラスターの記述名を入力します。

        入力するクラスター名は、DNS レコードの設定時に指定したクラスター名と一致する必要があります。

  2. install-config.yaml ファイルで、platform.nutanix.clusterOSImage の値をイメージの場所または名前に設定します。以下に例を示します。

    platform:
      nutanix:
          clusterOSImage: http://mirror.example.com/images/rhcos-47.83.202103221318-0-nutanix.x86_64.qcow2
  3. install-config.yaml ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。

    1. pullSecret の値を更新して、レジストリーの認証情報を追加します。

      pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'

      <mirror_host_name> の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials> の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

    2. additionalTrustBundle パラメーターおよび値を追加します。

      additionalTrustBundle: |
        -----BEGIN CERTIFICATE-----
        ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
        -----END CERTIFICATE-----

      この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。

    3. 次の 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 ファイルを使用します。

    4. オプション: パブリッシュストラテジーを Internal に設定します。

      publish: Internal

      このオプションを設定すると、内部 Ingress コントローラーおよびプライベートロードバランサーを作成します。

  4. オプション: install.config.yaml ファイル内の 1 つ以上のデフォルト設定パラメーターを更新して、インストールをカスタマイズします。

    パラメーターの詳細は、「インストール設定パラメーター」を参照してください。

    注記

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

  5. 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) がある。

手順

  1. 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 つのサブネットのみがサポートされます。
  2. 必要に応じて、追加の障害ドメインを設定します。
  3. コントロールプレーンとコンピュートマシンを障害ドメイン全体に分散するには、次のいずれかを実行します。

    • コンピューティングプレーンとコントロールプレーンのマシンが同じ障害ドメインセットを共有できる場合は、クラスターのデフォルトのマシン設定の下に障害ドメイン名を追加します。

      障害ドメインセットを共有するコントロールプレーンとコンピュートマシンの例

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

4.6.3. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.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) も設定されます。

手順

  1. 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.comx.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
  2. ファイルを保存し、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 にインストールできます。

手順

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

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

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

    $ echo $PATH

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    $ oc <command>
Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

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

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

    C:\> path

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    C:\> oc <command>
macOS への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

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

    注記

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

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

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

    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    $ oc <command>

4.8. Nutanix の IAM の設定

クラスターをインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。インストールプログラムが手動モード用に CCO を設定する間、ID およびアクセス管理シークレットを指定する必要があります。

前提条件

  • ccoctl バイナリーを設定している。
  • install-config.yaml ファイルがある。

手順

  1. 認証情報データを含む 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>

    1
    認証タイプを指定します。Basic 認証のみがサポートされています。
    2
    Prism Central の認証情報を指定します。
    3
    オプション: Prism Element 認証情報を指定します。
  2. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  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
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

    サンプル 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

  4. 次のコマンドを実行し、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
    1
    コンポーネント CredentialsRequests オブジェクトのファイルを含むディレクトリーへのパスを指定します。
    2
    オプション: ccoctl ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。
    3
    オプション: 認証情報データ YAML ファイルを含むディレクトリーを指定します。デフォルトでは、ccoctl はこのファイルが <home_directory>/.nutanix/credentials にあると想定します。
  5. credentialsMode パラメーターが Manual に設定されるように、install-config.yaml 設定ファイルを編集します。

    サンプル install-config.yaml 設定ファイル

    apiVersion: v1
    baseDomain: cluster1.example.com
    credentialsMode: Manual 1
    ...

    1
    この行を追加して、credentialsMode パラメーターを Manual に設定します。
  6. 次のコマンドを実行して、インストールマニフェストを作成します。

    $ openshift-install create manifests --dir <installation_directory> 1
    1
    クラスターの install-config.yaml ファイルを含むディレクトリーへのパスを指定します。
  7. 次のコマンドを実行して、生成された認証情報ファイルをターゲットマニフェストディレクトリーにコピーします。

    $ 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
    1
    <installation_directory> に、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、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: trueOperatorHub オブジェクトに追加して、デフォルトカタログのソースを無効にします。

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
ヒント

または、Web コンソールを使用してカタログソースを管理できます。AdministrationCluster SettingsConfigurationOperatorHub ページから、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 ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift CLI にログインします。
  2. results ディレクトリーからクラスターに YAML ファイルを適用します。

    $ oc apply -f ./oc-mirror-workspace/results-<id>/

検証

  1. ImageContentSourcePolicy リソースが正常にインストールされたことを確認します。

    $ oc get imagecontentsourcepolicy
  2. 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) クラスターで適切に削除されていないリソースがあるかどうかについて、クラウドプロバイダーを確認します。インストーラーが作成されなかったり、インストーラーがアクセスできない場合には、リソースがある可能性があります。

前提条件

  • クラスターをデプロイするために使用したインストールプログラムのコピーがあります。
  • クラスター作成時にインストールプログラムが生成したファイルがあります。

手順

  1. クラスターをインストールするために使用したコンピューターのインストールプログラムが含まれるディレクトリーから、以下のコマンドを実行します。

    $ ./openshift-install destroy cluster \
    --dir <installation_directory> --log-level info 1 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なる詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    クラスターのクラスター定義ファイルが含まれるディレクトリーを指定する必要があります。クラスターを削除するには、インストールプログラムでこのディレクトリーにある metadata.json ファイルが必要になります。

  2. オプション: <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. 必須設定パラメーター

必須のインストール設定パラメーターは、以下の表で説明されています。

表7.1 必須パラメーター
パラメーター説明
apiVersion:

install-config.yaml コンテンツの API バージョン。現在のバージョンは v1 です。インストールプログラムは、古い API バージョンもサポートしている場合があります。

文字列

baseDomain:

クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、baseDomain<metadata.name>.<baseDomain> 形式を使用する metadata.name パラメーターの値の組み合わせです。

example.com などの完全修飾ドメインまたはサブドメイン名。

metadata:

Kubernetes リソース ObjectMeta。ここからは name パラメーターのみが消費されます。

オブジェクト

metadata:
  name:

クラスターの名前。クラスターの DNS レコードはすべて {{.metadata.name}}.{{.baseDomain}} のサブドメインです。

小文字いちぶハイフン (-) の文字列 (dev など)。

platform:

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}platform.<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 アドレスを使用するようにしてください。

表7.2 ネットワークパラメーター
パラメーター説明
networking:

クラスターのネットワークの設定。

オブジェクト

注記

インストール後に networking オブジェクトで指定したパラメーターを変更することはできません。

networking:
  networkType:

インストールする Red Hat OpenShift Networking ネットワークプラグイン。

OVNKubernetesOVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プラグインです。デフォルトの値は OVNKubernetes です。

networking:
  clusterNetwork:

Pod の IP アドレスブロック。

デフォルト値は 10.128.0.0/14 で、ホストの接頭辞は /23 です。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
networking:
  clusterNetwork:
    cidr:

networking.clusterNetwork を使用する場合に必須です。IP アドレスブロック。

IPv4 ネットワーク

CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は 0 から 32 の間になります。

networking:
  clusterNetwork:
    hostPrefix:

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。hostPrefix 値の 23 は、510 (2^(32 - 23) - 2) Pod IP アドレスを提供します。

サブネット接頭辞。

デフォルト値は 23 です。

networking:
  serviceNetwork:

サービスの IP アドレスブロック。デフォルト値は 172.30.0.0/16 です。

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:

networking.machineNetwork を使用する場合に必須です。IP アドレスブロック。libvirt と IBM Power® Virtual Server を除くすべてのプラットフォームのデフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。IBM Power® Virtual Server の場合、デフォルト値は 192.168.0.0/24 です。

CIDR 表記の IP ネットワークブロック。

例: 10.0.0.0/16

注記

優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

7.1.3. オプションの設定パラメーター

オプションのインストール設定パラメーターは、以下の表で説明されています。

表7.3 オプションのパラメーター
パラメーター説明
additionalTrustBundle:

ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。

文字列

capabilities:

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。

文字列配列

capabilities:
  baselineCapabilitySet:

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11v4.12vCurrent です。デフォルト値は vCurrent です。

文字列

capabilities:
  additionalEnabledCapabilities:

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。このパラメーターで複数の機能を指定できます。

文字列配列

cpuPartitioningMode:

ワークロードパーティション設定を使用して、OpenShift Container Platform サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod を分離し、予約された CPU セットで実行できます。ワークロードパーティショニングはインストール中にのみ有効にすることができ、インストール後に無効にすることはできません。このフィールドはワークロードのパーティショニングを有効にしますが、特定の CPU を使用するようにワークロードを設定するわけではありません。詳細は、スケーラビリティとパフォーマンス セクションの ワークロードパーティショニング ページを参照してください。

None または AllNodes。デフォルト値は None です。

compute:

コンピュートノードを構成するマシンの設定。

MachinePool オブジェクトの配列。

compute:
  architecture:

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

compute:
  hyperthreading:

コンピュートマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

compute:
  name:

compute を使用する場合に必須です。マシンプールの名前。

worker

compute:
  platform:

compute を使用する場合に必須です。このパラメーターを使用して、ワーカーマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は controlPlane.platform パラメーターの値に一致する必要があります。

alibabacloudawsazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}

compute:
  replicas:

プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。

2 以上の正の整数。デフォルト値は 3 です。

featureSet:

機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。

文字列。TechPreviewNoUpgrade など、有効にする機能セットの名前。

controlPlane:

コントロールプレーンを構成するマシンの設定。

MachinePool オブジェクトの配列。

controlPlane:
  architecture:

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

controlPlane:
  hyperthreading:

コントロールプレーンマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

controlPlane:
  name:

controlPlane を使用する場合に必須です。マシンプールの名前。

master

controlPlane:
  platform:

controlPlane を使用する場合に必須です。このパラメーターを使用して、コントロールプレーンマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は compute.platform パラメーターの値に一致する必要があります。

alibabacloudawsazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}

controlPlane:
  replicas:

プロビジョニングするコントロールプレーンマシンの数。

サポートされる値は 3、シングルノード OpenShift をデプロイする場合は 1 です。

credentialsMode:

Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。

MintPassthroughManual、または空の文字列 ("")。[1]

fips:

FIPS モードを有効または無効にします。デフォルトは false (無効) です。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。

重要

クラスターで 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 モードを有効にすることはできません。

false または true

imageContentSources:

release-image コンテンツのソースおよびリポジトリー。

オブジェクトの配列。この表の以下の行で説明されているように、source およびオプションで mirrors が含まれます。

imageContentSources:
  source:

imageContentSources を使用する場合に必須です。ユーザーが参照するリポジトリーを指定します (例: イメージプル仕様)。

文字列

imageContentSources:
  mirrors:

同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。

文字列の配列。

publish:

Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。

Internal または External。デフォルト値は External です。

このパラメーターを Internal に設定することは、クラウド以外のプラットフォームではサポートされません。

重要

フィールドの値が Internal に設定されている場合、クラスターは機能しなくなります。詳細は、BZ#1953035 を参照してください。

sshKey:

クラスターマシンへのアクセスを認証するための SSH キー。

注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

たとえば、sshKey: ssh-ed25519 AAAA.. です。

  1. すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、認証と認可 コンテンツの「クラウドプロバイダーの認証情報の管理」を参照してください。

7.1.4. 追加の Nutanix 設定パラメーター

追加の Nutanix 設定パラメーターについては、次の表で説明します。

表7.4 追加の Nutanix クラスターパラメーター
パラメーター説明
compute:
  platform:
    nutanix:
      categories:
        key:

コンピューティング VM に適用するプリズムカテゴリーのキーの名前。このパラメーターには、value パラメーターを指定する必要があり、keyvalue の両方のパラメーターが Prism Central に存在する必要があります。カテゴリーの詳細は、カテゴリー管理 を参照してください。

文字列

compute:
  platform:
    nutanix:
      categories:
        value:

コンピューティング VM に適用するプリズムカテゴリーのキーと値のペアの値。このパラメーターには、key パラメーターを指定する必要があり、keyvalue の両方のパラメーターが Prism Central に存在する必要があります。

文字列

compute:
  platform:
    nutanix:
     failureDomains:

コンピュートマシンのみに適用する障害ドメイン。

障害ドメインは platform.nutanix.failureDomains で指定します。

List。

1 つ以上の障害ドメインの名前。

compute:
  platform:
    nutanix:
      project:
        type:

コンピューティング VM のプロジェクトを選択するために使用する識別子のタイプ。プロジェクトは、権限、ネットワーク、およびその他のパラメーターを管理するためのユーザーロールの論理グループを定義します。プロジェクトの詳細は、プロジェクトの概要 を参照してください。

name または uuid

compute:
  platform:
    nutanix:
      project:
        name: or uuid:

コンピューティング VM が関連付けられているプロジェクトの名前または UUID。このパラメーターには、type パラメーターを指定する必要があります。

文字列

compute:
  platform:
    nutanix:
      bootType:

コンピューティングマシンが使用するブートタイプ。OpenShift Container Platform 4.15 では、Legacy ブートタイプを使用する必要があります。ブートタイプの詳細については、仮想化環境内の UEFI、セキュアブート、および TPM について を参照してください。

LegacySecureBoot、または UEFI。デフォルトは、Legacy です。

controlPlane:
  platform:
    nutanix:
      categories:
        key:

コントロールプレーン VM に適用するプリズムカテゴリーのキーの名前。このパラメーターには、value パラメーターを指定する必要があり、keyvalue の両方のパラメーターが Prism Central に存在する必要があります。カテゴリーの詳細は、カテゴリー管理 を参照してください。

文字列

controlPlane:
  platform:
    nutanix:
      categories:
        value:

コントロールプレーン VM に適用するプリズムカテゴリーのキーと値のペアの値。このパラメーターには、key パラメーターを指定する必要があり、keyvalue の両方のパラメーターが Prism Central に存在する必要があります。

文字列

controlPlane:
  platform:
    nutanix:
     failureDomains:

コントロールプレーンマシンのみに適用する障害ドメイン。

障害ドメインは platform.nutanix.failureDomains で指定します。

List。

1 つ以上の障害ドメインの名前。

controlPlane:
  platform:
    nutanix:
      project:
        type:

コントロールプレーン VM のプロジェクトを選択するために使用する識別子のタイプ。プロジェクトは、権限、ネットワーク、およびその他のパラメーターを管理するためのユーザーロールの論理グループを定義します。プロジェクトの詳細は、プロジェクトの概要 を参照してください。

name または uuid

controlPlane:
  platform:
    nutanix:
      project:
        name: or uuid:

コントロールプレーン VM が関連付けられているプロジェクトの名前または UUID。このパラメーターには、type パラメーターを指定する必要があります。

文字列

platform:
  nutanix:
    defaultMachinePlatform:
      categories:
        key:

すべての VM に適用するプリズムカテゴリーのキーの名前。このパラメーターには、value パラメーターを指定する必要があり、keyvalue の両方のパラメーターが Prism Central に存在する必要があります。カテゴリーの詳細は、カテゴリー管理 を参照してください。

文字列

platform:
  nutanix:
    defaultMachinePlatform:
      categories:
        value:

すべての VM に適用するプリズムカテゴリーのキーと値のペアの値。このパラメーターには、key パラメーターを指定する必要があり、keyvalue の両方のパラメーターが Prism Central に存在する必要があります。

文字列

platform:
  nutanix:
    defaultMachinePlatform:
      failureDomains:

コントロールプレーンとコンピュートマシンの両方に適用する障害ドメイン。

障害ドメインは platform.nutanix.failureDomains で指定します。

List。

1 つ以上の障害ドメインの名前。

platform:
  nutanix:
    defaultMachinePlatform:
      project:
        type:

すべての VM のプロジェクトを選択するために使用する識別子のタイプ。プロジェクトは、権限、ネットワーク、およびその他のパラメーターを管理するためのユーザーロールの論理グループを定義します。プロジェクトの詳細は、プロジェクトの概要 を参照してください。

name または uuid

platform:
  nutanix:
    defaultMachinePlatform:
      project:
        name: or uuid:

すべての VM が関連付けられているプロジェクトの名前または UUID。このパラメーターには、type パラメーターを指定する必要があります。

文字列

platform:
  nutanix:
    defaultMachinePlatform:
      bootType:

すべてのマシンのブートタイプ。OpenShift Container Platform 4.15 では、Legacy ブートタイプを使用する必要があります。ブートタイプの詳細については、仮想化環境内の UEFI、セキュアブート、および TPM について を参照してください。

LegacySecureBoot、または UEFI。デフォルトは、Legacy です。

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

  1. prismElements セクションには、Prism Elements (クラスター) のリストが含まれています。Prism Element は、OpenShift Container Platform クラスターをホストするために使用されるすべての Nutanix リソース (仮想マシンやサブネットなど) を包含します。
  2. 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.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.