サポートコンソール開発者トライアルの開始お問い合わせ

3.3. user-provisioned infrastructure を使用した vSphere へのクラスターのインストール

OpenShift Container Platform バージョン 4.16 では、独自にプロビジョニングする VMware vSphere インフラストラクチャーに、クラスターをインストールできます。

注記

OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。

重要

user-provisioned infrastructure のインストールする手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、vSphere プラットフォームおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。user-provisioned infrastructure のインストール手順をガイドとして使用します。他の方法で必要なリソースを作成することもできます。

3.3.1. 前提条件

  • user-provisioned infrastructure を使用したクラスターのインストールの準備 のタスクを完了した。
  • VMware プラットフォームのライセンスを確認した。Red Hat は VMware ライセンスに制限を設けていませんが、一部の VMware インフラストラクチャーコンポーネントにはライセンスが必要です。
  • OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
  • クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
  • クラスターの 永続ストレージ をプロビジョニングした。プライベートイメージレジストリーをデプロイするには、ストレージで ReadWriteMany アクセスモードを指定する必要があります。
  • インストールを完了するには、vSphere ホストに Red Hat Enterprise Linux CoreOS(RHCOS) OVA をアップロードする必要があります。このプロセスを完了するマシンには、vCenter および ESXi ホストのポート 443 にアクセスできる必要があります。ポート 443 にアクセスできることを確認している。
  • ファイアウォールを使用する場合は、ポート 443 にアクセスできることを管理者に確認している。インストールを成功させるには、コントロールプレーンノードがポート 443 で vCenter および ESXi ホストに到達できる必要があります。

  • ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。

    注記

    プロキシーを設定する場合は、このサイトリストも確認してください。

3.3.2. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.16 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

3.3.3. VMware vSphere のリージョンとゾーンの有効化

OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは、複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

重要

VMware vSphere のリージョンおよびゾーンの有効化機能には、クラスター内のデフォルトのストレージドライバーとして vSphere Container Storage Interface (CSI) ドライバーが必要です。そのため、この機能は新しくインストールされたクラスターでのみ使用できます。

以前のリリースからアップグレードされたクラスターの場合は、クラスターの CSI 自動移行を有効にする必要があります。その後、アップグレードされたクラスターに対して複数のリージョンとゾーンを設定できます。

デフォルトのインストール設定では、クラスターが単一の vSphere データセンターにデプロイされます。クラスターを複数の vSphere データセンターにデプロイする場合は、リージョンおよびゾーン機能を有効にするインストール設定ファイルを作成する必要があります。

デフォルトの install-config.yaml ファイルには vcenters フィールドと failureDomains フィールドが含まれており、OpenShift Container Platform クラスターに複数の vSphere データセンターとクラスターを指定できます。単一のデータセンターで構成される vSphere 環境に OpenShift Container Platform クラスターをインストールする場合は、これらのフィールドを空白のままにすることができます。

次のリストでは、クラスターのゾーンとリージョンの定義に関連する用語を説明します。

  • 障害ドメイン: リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
  • リージョン: vCenter データセンターを指定します。リージョンを定義するには、openshift-region タグカテゴリーのタグを使用します。
  • ゾーン: vCenter クラスターを指定します。ゾーンを定義するには、openshift-zone タグカテゴリーのタグを使用します。
注記

install-config.yaml ファイルで複数の障害ドメインを指定する予定がある場合は、設定ファイルを作成する前に、タグカテゴリー、ゾーンタグ、およびリージョンタグを作成する必要があります。

リージョンを表す vCenter データセンターごとに vCenter タグを作成する必要があります。さらに、データセンターで実行されるクラスターごとに、ゾーンを表す vCenter タグを作成する必要があります。タグを作成した後、各タグをそれぞれのデータセンターとクラスターにアタッチする必要があります。

次の表は、単一の VMware vCenter で実行されている複数の vSphere データセンターを含む設定のリージョン、ゾーン、タグ間の関係の例を示しています。

データセンター (リージョン)クラスター (ゾーン)タグ

米国東部

us-east-1

us-east-1a

us-east-1b

us-east-2

us-east-2a

us-east-2b

us-west

us-west-1

us-west-1a

us-west-1b

us-west-2

us-west-2a

us-west-2b

関連情報

3.3.4. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

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

    $ mkdir <installation_directory>
    重要

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

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

    注記

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

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

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

    重要

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

関連情報

3.3.4.1. VMware vSphere のサンプル install-config.yaml ファイル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。 

additionalTrustBundlePolicy: Proxyonly
apiVersion: v1
baseDomain: example.com 1
compute: 2
- architecture: amd64
  name: <worker_node>
  platform: {}
  replicas: 0 3
controlPlane: 4
  architecture: amd64
  name: <parent_node>
  platform: {}
  replicas: 3 5
metadata:
  creationTimestamp: null
  name: test 6
networking:
---
platform:
  vsphere:
    failureDomains: 7
    - name: <failure_domain_name>
      region: <default_region_name>
      server: <fully_qualified_domain_name>
      topology:
        computeCluster: "/<data_center>/host/<cluster>"
        datacenter: <data_center> 8
        datastore: "/<data_center>/datastore/<datastore>" 9
        networks:
        - <VM_Network_name>
        resourcePool: "/<data_center>/host/<cluster>/Resources/<resourcePool>" 10
        folder: "/<data_center_name>/vm/<folder_name>/<subfolder_name>" 11
      zone: <default_zone_name>
    vcenters:
    - datacenters:
      - <data_center>
      password: <password> 12
      port: 443
      server: <fully_qualified_domain_name> 13
      user: administrator@vsphere.local
    diskType: thin 14
fips: false 15
pullSecret: '{"auths": ...}' 16
sshKey: 'ssh-ed25519 AAAA...' 17
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 4
controlPlane セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。両方のセクションで単一のマシンプールが定義されるため、使用されるコントロールプレーンは 1 つだけです。OpenShift Container Platform は、複数のコンピューティングプールの定義をサポートしていません。
3
replicas パラメーターの値を 0 に設定する必要があります。このパラメーターはクラスターが作成し、管理するワーカーの数を制御します。これは、user-provisioned infrastructure を使用する場合にクラスターが実行しない機能です。OpenShift Container Platform のインストールが終了する前に、クラスターが使用するワーカーマシンを手動でデプロイする必要があります。
5
クラスターに追加するコントロールプレーンマシンの数。クラスターをこの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
6
DNS レコードに指定したクラスター名。
7
リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
8
vSphere データセンター。
9
仮想マシンファイル、テンプレート、ISO イメージを保持する vSphere データストアへのパス。
重要

データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion はデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage vMotion を無効にする必要があります。

複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

10
オプション: installer-provisioned infrastructure の場合、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パス (例: /<data_center_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>)。値を指定しない場合、リソースはクラスターのルート /example_data_center/host/example_cluster/Resources にインストールされます。
11
オプション: installer-provisioned infrastructure の場合、インストールプログラムが仮想マシンを作成する既存フォルダーの絶対パス (例: /<data_center_name>/vm/<folder_name>/<subfolder_name>)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供していて、thin という名前のデフォルトの StorageClass オブジェクトを使用したくない場合は、install-config.yaml ファイルから folder パラメーターを省略できます。
12
vSphere ユーザーに関連付けられたパスワード。
13
vCenter サーバーの完全修飾ホスト名または IP アドレス。
重要

Cloud Controller Manager Operator は、指定されたホスト名または IP アドレスに対して接続チェックを行います。到達可能な vCenter サーバーに対して、ホスト名または IP アドレスを指定していることを確認してください。存在しない vCenter サーバーにメタデータを提供すると、クラスターのインストールはブートストラップ段階で失敗します。

14
vSphere ディスクのプロビジョニング方法。
15
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から 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 暗号化ライブラリーを使用します。

16
OpenShift Cluster Manager から取得したプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
17
Red Hat Enterprise Linux CoreOS (RHCOS) の core ユーザーのデフォルト SSH キーの公開部分。

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

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

前提条件

  • 既存の install-config.yaml ファイルがある。

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

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、および networking.serviceNetwork[] フィールドの値が設定されます。

    Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、Proxy オブジェクトの status.noProxy フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。

手順

  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.com は x.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。vCenter の IP アドレスと、そのマシンに使用する IP 範囲を含める必要があります。
    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.3.4.3. VMware vCenter のリージョンとゾーンの設定

デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。

OpenShift Container Platform の以前のリリースのデフォルトの install-config.yaml ファイル設定は非推奨になりました。非推奨のデフォルト設定を引き続き使用できますが、openshift-installer により、設定ファイル内の非推奨のフィールドの使用を示す警告メッセージが表示されます。

重要

この例では、govc コマンドを使用します。govc コマンドは、VMware から入手できるオープンソースコマンドです。Red Hat からは入手できません。Red Hat サポートチームは govc コマンドを保守していません。govc のダウンロードとインストールの手順は、VMware ドキュメント Web サイトを参照してください。

前提条件

  • 既存の install-config.yaml インストール設定ファイルがあります。

    重要

    VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

手順

  1. 次の govc コマンドラインツールコマンドを入力して、openshift-region および openshift-zone vCenter タグカテゴリーを作成します。

    重要

    openshift-region および openshift-zone vCenter タグカテゴリーに異なる名前を指定すると、OpenShift Container Platform クラスターのインストールは失敗します。 

    $ govc tags.category.create -d "OpenShift region" openshift-region
    $ govc tags.category.create -d "OpenShift zone" openshift-zone

  2. クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。 

    $ govc tags.create -c <region_tag_category> <region_tag>

  3. クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。 

    $ govc tags.create -c <zone_tag_category> <zone_tag>

  4. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにリージョンタグをアタッチします。 

    $ govc tags.attach -c <region_tag_category> <region_tag_1> /<data_center_1>

  5. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。 

    $ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<data_center_1>/host/vcs-mdcnc-workload-1
  6. インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。

vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml ファイル

---
compute:
---
  vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
controlPlane:
---
vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
platform:
  vsphere:
    vcenters:
---
    datacenters:
      - <data_center_1_name>
      - <data_center_2_name>
    failureDomains:
    - name: <machine_pool_zone_1>
      region: <region_tag_1>
      zone: <zone_tag_1>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_1>
        computeCluster: "/<data_center_1>/host/<cluster1>"
        networks:
        - <VM_Network1_name>
        datastore: "/<data_center_1>/datastore/<datastore1>"
        resourcePool: "/<data_center_1>/host/<cluster1>/Resources/<resourcePool1>"
        folder: "/<data_center_1>/vm/<folder1>"
    - name: <machine_pool_zone_2>
      region: <region_tag_2>
      zone: <zone_tag_2>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_2>
        computeCluster: "/<data_center_2>/host/<cluster2>"
        networks:
        - <VM_Network2_name>
        datastore: "/<data_center_2>/datastore/<datastore2>"
        resourcePool: "/<data_center_2>/host/<cluster2>/Resources/<resourcePool2>"
        folder: "/<data_center_2>/vm/<folder2>"
---

3.3.5. Kubernetes マニフェストおよび Ignition 設定ファイルの作成

一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。

重要
  • OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

前提条件

  • OpenShift Container Platform インストールプログラムを取得していること。
  • install-config.yaml インストール設定ファイルを作成していること。

手順

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

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> には、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。

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

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

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

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

      警告

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

      重要

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

  3. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

    1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
    2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
    3. ファイルを保存し、終了します。

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

    $ ./openshift-install create ignition-configs --dir <installation_directory> 1
    1
    <installation_directory> には、同じインストールディレクトリーを指定します。

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

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

3.3.6. インフラストラクチャー名の抽出

Ignition 設定ファイルには、VMware vSphere でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。クラスター ID を仮想マシンフォルダーの名前として使用する予定がある場合、これを抽出する必要があります。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
  • クラスターの Ignition 設定ファイルを生成している。
  • jq パッケージをインストールしている。

手順

  • Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出し、表示するには、以下のコマンドを実行します。 

    $ jq -r .infraID <installation_directory>/metadata.json 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    openshift-vw9j6 1

    1
    このコマンドの出力はクラスター名とランダムな文字列です。

3.3.7. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始

OpenShift Container Platform を VMware vSphere の user-provisioned infrastructure にインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) を vSphere ホストにインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプに、OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS マシンの再起動後に自動的に開始されます。

前提条件

  • クラスターの Ignition 設定ファイルを取得している。
  • お使いのコンピューターからアクセスでき、作成するマシンがアクセスできる HTTP サーバーへのアクセス権がある。
  • vSphere クラスター を作成している。

手順

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

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

    {
  "ignition": {
    "config": {
      "merge": [
        {
          "source": "<bootstrap_ignition_config_url>", 1
          "verification": {}
        }
      ]
    },
    "timeouts": {},
    "version": "3.2.0"
  },
  "networkd": {},
  "passwd": {},
  "storage": {},
  "systemd": {}
}
    1
    ホストしているブートストラップの Ignition 設定ファイルの URL を指定します。

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

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

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

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

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

    $ base64 -w0 <installation_directory>/master.ign > <installation_directory>/master.64
    $ base64 -w0 <installation_directory>/worker.ign > <installation_directory>/worker.64
    $ base64 -w0 <installation_directory>/merge-bootstrap.ign > <installation_directory>/merge-bootstrap.64
    重要

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

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

    重要

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

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

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

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

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

    注記

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

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

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

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

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

      重要

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

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

    重要

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

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

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

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

      注記

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

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

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

      重要

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

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

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

          コマンドの例

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

          コマンドの例

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

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

          コマンドの例

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

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

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

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

      コマンドの例

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

次のステップ

  • 各マシンごとに先の手順に従って、クラスターの残りのマシンを作成します。

    重要

    この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。一部の Pod はデフォルトでコンピュートマシンにデプロイされるため、クラスターのインストール前に、2 つ以上のコンピュートマシンを作成します。

3.3.8. vSphere でのコンピュートマシンのクラスターへの追加

コンピュートマシンを VMware vSphere の user-provisioned OpenShift Container Platform クラスターに追加することができます。

vSphere テンプレートを OpenShift Container Platform クラスターにデプロイした後に、そのクラスター内のマシンの仮想マシン (VM) をデプロイできます。

注記

3 ノードクラスターをインストールする場合は、この手順をスキップしてください。3 ノードクラスターは、コンピュートマシンとしても機能する 3 つのコントロールプレーンマシンで構成されます。

前提条件

  • コンピュートマシンの base64 でエンコードされた Ignition ファイルを取得します。
  • クラスター用に作成した vSphere テンプレートにアクセスできる必要があります。

手順

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

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

    注記

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

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

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

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

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

次のステップ

  • 継続してクラスター用の追加のコンピュートマシンを作成します。

3.3.9. ディスクパーティション設定

ほとんどの場合、データパーティションは、最初に別のオペレーティングシステムをインストールするのではなく、RHCOS をインストールして作成されます。この場合、OpenShift Container Platform インストーラーでは、ディスクパーティションの設定が許可されます。

ただし、以下は、OpenShift Container Platform ノードのインストール時に、デフォルトのパーティション設定を上書きするために介入が必要と思われる 2 つのケースになります。

  • 別個のパーティションの作成: 空のディスクへのグリーンフィールドインストールの場合は、別のストレージをパーティションに追加する必要がある場合があります。これは、/var または /var/lib/etcd などの /var のサブディレクトリー (両方ではない) を個別のパーティションとして作成する場合にのみ正式にサポートされます。

    重要

    ディスクサイズが 100 GB を超える場合、特にディスクサイズが 1 TB を超える場合は、別の /var パーティションを作成します。詳細は、「個別の /var パーティションの作成」およびこちらの Red Hat ナレッジベースの記事 を参照してください。

    重要

    Kubernetes は 2 つのファイルシステムパーティションのみをサポートします。元の設定に複数のパーティションを追加すると、Kubernetes はそれらをすべて監視できません。

  • 既存のパーティションの保持: ブラウンフィールドインストールで、既存のノードに OpenShift Container Platform を再インストールし、以前のオペレーティングシステムからのデータパーティションを維持する必要がある場合、既存のデータパーティションを保持できる coreos-installer へのブート引数とオプションの両方があります。

個別の /var パーティションの作成

一般的に、OpenShift Container Platform のディスクパーティション設定は、インストーラーに任せる必要があります。ただし、拡張予定のファイルシステムの一部に個別のパーティションの作成が必要となる場合もあります。

OpenShift Container Platform は、ストレージを /var パーティションまたは /var のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。

  • /var/lib/containers: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。
  • /var/lib/etcd: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。

  • /var: 監査などの目的に合わせて分離させる必要のあるデータを保持します。

    重要

    ディスクサイズが 100 GB を超える場合、特に 1 TB を超える場合は、別の /var パーティションを作成します。

/var ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。

/var は、Red Hat Enterprise Linux CoreOS (RHCOS) の新規インストール前に有効にする必要があるため、以下の手順では OpenShift Container Platform インストールの openshift-install の準備フェーズで挿入されるマシン設定マニフェストを作成して、別の /var パーティションを設定します。

手順

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

    $ mkdir $HOME/clusterconfig

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

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

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

    variant: openshift
version: 4.16.0
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 98-var-partition
storage:
  disks:
  - device: /dev/disk/by-id/<device_name> 1
    partitions:
    - label: var
      start_mib: <partition_start_offset> 2
      size_mib: <partition_size> 3
      number: 5
  filesystems:
    - device: /dev/disk/by-partlabel/var
      path: /var
      format: xfs
      mount_options: [defaults, prjquota] 4
      with_mount_unit: true
    1
    パーティションを設定する必要のあるディスクのストレージデバイス名。
    2
    データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
    3
    データパーティションのサイズ (メビバイト単位)。
    4
    コンテナーストレージに使用されるファイルシステムでは、prjquota マウントオプションを有効にする必要があります。
    注記

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

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

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

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

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

Ignition 設定ファイルを Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールために vSphere インストール手順への入力として使用できます。

3.3.10. ブートストラッププロセスの完了まで待機する

OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。

前提条件

  • クラスターの Ignition 設定ファイルを作成している。
  • 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
  • インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
  • RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。
  • お使いのマシンでインターネットに直接アクセスできるか、HTTP または HTTPS プロキシーが利用できる。

手順

  1. ブートストラッププロセスをモニターします。 

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

    出力例

    INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
INFO API v1.29.4 up
INFO Waiting up to 30m0s for bootstrapping to complete...
INFO It is now safe to remove the bootstrap resources

    Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。

  2. ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。

    重要

    この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。

3.3.11. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。 

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。 

    $ oc whoami

    出力例

    system:admin

3.3.12. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。 

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4

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

    注記

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

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

    $ oc get csr

    出力例

    NAME        AGE     REQUESTOR                                                                   CONDITION
csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...

    この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

    注記

    ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc exec、oc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。 

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。

    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。 

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
      注記

      一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

  4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。 

    $ oc get csr

    出力例

    NAME        AGE     REQUESTOR                                                                   CONDITION
csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
...

  5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。 

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。

    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。 

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。 

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.29.4
master-1  Ready     master  73m  v1.29.4
master-2  Ready     master  74m  v1.29.4
worker-0  Ready     worker  11m  v1.29.4
worker-1  Ready     worker  11m  v1.29.4

    注記

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

関連情報

3.3.13. Operator の初期設定

コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。

前提条件

  • コントロールプレーンが初期化されています。

手順

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

    $ watch -n5 oc get clusteroperators

    出力例

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

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

3.3.13.1. インストール時に削除されたイメージレジストリー

共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed としてブートストラップされます。これにより、openshift-installer がそれらのプラットフォームタイプでのインストールを完了できます。

インストール後に、Image Registry Operator 設定を編集して managementState を Removed から Managed に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。

3.3.13.2. イメージレジストリーストレージの設定

Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

3.3.13.2.1. VMware vSphere のレジストリーストレージの設定

クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。

前提条件

  • クラスター管理者のパーミッション。
  • VMware vSphere 上のクラスター。

  • Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。

    重要

    OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの ReadWriteOnce アクセスをサポートします。ReadWriteOnce アクセスでは、レジストリーが Recreate ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany アクセスが必要です。

  • "100Gi" の容量が必要です。
重要

テストにより、NFS サーバーを RHEL でコアサービスのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container レジストリーおよび Quay、メトリックストレージの Prometheus、およびロギングストレージの Elasticsearch が含まれます。そのため、コアサービスで使用される PV をサポートするために RHEL NFS を使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift Container Platform コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

手順

  1. レジストリーをストレージを使用できるように設定するには、configs.imageregistry/cluster リソースの spec.storage.pvc を変更します。

    注記

    共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。

  2. レジストリー Pod がないことを確認します。 

    $ oc get pod -n openshift-image-registry -l docker-registry=default

    出力例

    No resourses found in openshift-image-registry namespace

    注記

    出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。

  3. レジストリー設定を確認します。 

    $ oc edit configs.imageregistry.operator.openshift.io

    出力例

    storage:
  pvc:
    claim: 1

    1
    image-registry-storage 永続ボリューム要求 (PVC) の自動作成を許可するには、claim フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。

  4. clusteroperator ステータスを確認します。 

    $ oc get clusteroperator image-registry

    出力例

    NAME             VERSION                              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
image-registry   4.7                                  True        False         False      6h50m

3.3.13.2.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定

Image Registry Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。

手順

  • イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。 

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
    警告

    実稼働用以外のクラスターにのみこのオプションを設定します。

    Image Registry Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、oc patch コマンドは以下のエラーを出して失敗します。 

    Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found

    数分待機した後に、このコマンドを再び実行します。

3.3.13.2.3. VMware vSphere のブロックレジストリーストレージの設定

イメージレジストリーがクラスター管理者によるアップグレード時に vSphere Virtual Machine Disk (VMDK) などのブロックストレージタイプを使用できるようにするには、Recreate ロールアウトストラテジーを使用できます。

重要

ブロックストレージボリュームはサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。

手順

  1. 次のコマンドを入力してイメージレジストリーストレージをブロックストレージタイプとして設定し、レジストリーにパッチを適用して Recreate ロールアウトストラテジーを使用し、1 つのレプリカのみで実行されるようにします。 

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'

  2. ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。

    1. 以下の内容で pvc.yaml ファイルを作成して VMware vSphere PersistentVolumeClaim オブジェクトを定義します。 

      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: image-registry-storage 1
  namespace: openshift-image-registry 2
spec:
  accessModes:
  - ReadWriteOnce 3
  resources:
    requests:
      storage: 100Gi 4
      1
      PersistentVolumeClaim オブジェクトを表す一意の名前。
      2
      PersistentVolumeClaim オブジェクトの namespace (openshift-image-registry)。
      3
      永続ボリューム要求のアクセスモード。ReadWriteOnce では、ボリュームは単一ノードによって読み取り/書き込みパーミッションでマウントできます。
      4
      永続ボリューム要求のサイズ。

    2. 次のコマンドを入力して、ファイルから PersistentVolumeClaim オブジェクトを作成します。 

      $ oc create -f pvc.yaml -n openshift-image-registry

  3. 次のコマンドを入力して、正しい PVC を参照するようにレジストリー設定を編集します。 

    $ oc edit config.imageregistry.operator.openshift.io -o yaml

    出力例

    storage:
  pvc:
    claim: 1

    1
    カスタム PVC を作成することにより、image-registry-storage PVC のデフォルトの自動作成の claim フィールドを空のままにできます。

正しい PVC を参照するようにレジストリーストレージを設定する手順は、vSphere のレジストリーの設定 を参照してください。

3.3.14. user-provisioned infrastructure でのインストールの完了

Operator の設定が完了したら、独自に提供するインフラストラクチャーへのクラスターのインストールを完了できます。

前提条件

  • コントロールプレーンが初期化されています。
  • Operator の初期設定を完了済みです。

手順

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

    $ watch -n5 oc get clusteroperators

    出力例

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

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

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    INFO Waiting up to 30m0s for the cluster to initialize...

    Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。

    重要
    • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
    • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

  2. Kubernetes API サーバーが Pod と通信していることを確認します。

    1. すべての Pod のリストを表示するには、以下のコマンドを使用します。 

      $ oc get pods --all-namespaces

      出力例

      NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
...

    2. 以下のコマンドを使用して、直前のコマンドの出力にリスト表示される Pod のログを表示します。 

      $ oc logs <pod_name> -n <namespace> 1
      1
      直前のコマンドの出力にあるように、Pod 名および namespace を指定します。

      Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。

  3. FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。

    詳細は、インストール後のマシン設定タスク ドキュメントで、「RHCOS でのカーネル引数を使用したマルチパスの有効化」を参照してください。

クラスターのインストールが完了したら、コンピュートマシンの vSphere への追加 に従って、コンピュートマシンをさらに追加できます。

3.3.15. コントロールプレーンノードの vSphere DRS 非アフィニティールールの設定

vSphere Distributed Resource Scheduler (DRS) 非アフィニティールールを設定して、OpenShift Container Platform コントロールプレーンノードでより高い可用性をサポートできます。非アフィニティールールにより、OpenShift Container Platform コントロールプレーンノードの vSphere 仮想マシンが同じ vSphere ノードにスケジュールされないようにします。

重要
  • 以下の情報はコンピュート DRS にのみ適用され、ストレージ DRS には適用されません。
  • govc コマンドは、VMware で利用可能なオープンソースのコマンドであり、Red Hat からは利用できません。govc コマンドは、Red Hat サポートではサポートされません。
  • govc のダウンロードおよびインストール手順は、VMware ドキュメントの Web サイトを参照してください。

以下のコマンドを実行して anti-affinity ルールを作成します。

コマンドの例

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

ルールを作成すると、コントロールプレーンノードは vSphere によって自動的に移行されるため、同じホストで実行されることはありません。vSphere が新しいルールを調整するまで、しばらく時間がかかる場合があります。コマンドを正しく補完する方法は、以下の手順に示します。

注記

移行は自動的に行われ、移行が完了するまで短い OpenShift API 停止またはレイテンシーが発生する可能性があります。

vSphere DRS の非アフィニティールールは、コントロールプレーンの仮想マシン名が変更された場合や、新しい vSphere クラスターへの移行時に手動で更新する必要があります。

手順

  1. 以下のコマンドを実行して、既存の DRS 非アフィニティールールを削除します。 

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

    出力例

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

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

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

3.3.16. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.16 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

3.3.17. 次のステップ

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.