2.4. カスタマイズによる vSphere へのクラスターのインストール


OpenShift Container Platform バージョン 4.14 では、インストーラーでプロビジョニングされるインフラストラクチャーを使用して、VMware vSphere インスタンスにクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

注記

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

2.4.1. 前提条件

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

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

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

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

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

2.4.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

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

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

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。

手順

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

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

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

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

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

        注記

        古い設定の再利用を回避するために、~/.powervs ディレクトリーは必ず削除してください。以下のコマンドを実行します。

        $ rm -rf ~/.powervs
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

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

        注記

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

      2. ターゲットに設定するプラットフォームとして vsphere を選択します。
      3. vCenter インスタンスの名前を指定します。
      4. クラスターを作成するのに必要なパーミッションを持つ vCenter アカウントのユーザー名およびパスワードを指定します。

        インストールプログラムは vCenter インスタンスに接続します。

      5. 接続する vCenter インスタンスのデータセンターを選択します。

        注記

        インストール設定ファイルを作成した後、そのファイルを変更して複数の vSphere データセンター環境を作成できます。これは、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできることを意味します。この環境の作成の詳細については、VMware vSphere のリージョンとゾーンの有効化 を参照してください。

      6. 使用するデフォルトの vCenter データストアを選択します。

        警告

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

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

      7. OpenShift Container Platform クラスターをインストールする vCenter クラスターを選択します。インストールプログラムは、vSphere クラスターの root リソースプールをデフォルトのリソースプールとして使用します。
      8. 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワークを選択します。
      9. コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
      10. クラスター Ingress に設定した仮想 IP アドレスを入力します。
      11. ベースドメインを入力します。このベースドメインは、設定した DNS レコードで使用したものと同じである必要があります。
      12. クラスターの記述名を入力します。

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

  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。

    注記

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

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

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

2.4.4.1. installer-provisioned VMware vSphere クラスターの install-config.yaml ファイルのサンプル

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

apiVersion: v1
baseDomain: example.com 1
compute: 2
- architecture: amd64
  name:  <worker_node>
  platform: {}
  replicas: 3
controlPlane: 3
  architecture: amd64
  name: <parent_node>
  platform: {}
  replicas: 3
metadata:
  creationTimestamp: null
  name: test 4
platform:
  vsphere: 5
    apiVIPs:
      - 10.0.0.1
    failureDomains: 6
    - name: <failure_domain_name>
      region: <default_region_name>
      server: <fully_qualified_domain_name>
      topology:
        computeCluster: "/<datacenter>/host/<cluster>"
        datacenter: <datacenter>
        datastore: "/<datacenter>/datastore/<datastore>" 7
        networks:
        - <VM_Network_name>
        resourcePool: "/<datacenter>/host/<cluster>/Resources/<resourcePool>" 8
        folder: "/<datacenter_name>/vm/<folder_name>/<subfolder_name>"
      zone: <default_zone_name>
    ingressVIPs:
    - 10.0.0.2
    vcenters:
    - datacenters:
      - <datacenter>
      password: <password>
      port: 443
      server: <fully_qualified_domain_name>
      user: administrator@vsphere.local
    diskType: thin 9
fips: false
pullSecret: '{"auths": ...}'
sshKey: 'ssh-ed25519 AAAA...'
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 3
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
4
DNS レコードに指定したクラスター名。
5
オプション: コンピュートおよびコントロールプレーンマシンのマシンプールパラメーターの追加設定を指定します。
6
リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
7
仮想マシンファイル、テンプレート、ISO イメージを保持する vSphere データストアへのパス。
重要

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

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

8
オプション: マシン作成用の既存のリソースプールを提供します。値を指定しない場合、インストールプログラムは vSphere クラスターのルートリソースプールを使用します。
9
vSphere ディスクのプロビジョニング方法。
注記

OpenShift Container Platform 4.12 以降では、apiVIP および ingressVIP 設定は非推奨です。代わりに、リスト形式を使用して、apiVIPs および ingressVIPs 設定に値を入力します。

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

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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 には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。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 オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

2.4.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> /<datacenter_1>
  5. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。

    $ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_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:
      - <datacenter1_name>
      - <datacenter2_name>
    failureDomains:
    - name: <machine_pool_zone_1>
      region: <region_tag_1>
      zone: <zone_tag_1>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <datacenter1>
        computeCluster: "/<datacenter1>/host/<cluster1>"
        networks:
        - <VM_Network1_name>
        datastore: "/<datacenter1>/datastore/<datastore1>"
        resourcePool: "/<datacenter1>/host/<cluster1>/Resources/<resourcePool1>"
        folder: "/<datacenter1>/vm/<folder1>"
    - name: <machine_pool_zone_2>
      region: <region_tag_2>
      zone: <zone_tag_2>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <datacenter2>
        computeCluster: "/<datacenter2>/host/<cluster2>"
        networks:
        - <VM_Network2_name>
        datastore: "/<datacenter2>/datastore/<datastore2>"
        resourcePool: "/<datacenter2>/host/<cluster2>/Resources/<resourcePool2>"
        folder: "/<datacenter2>/vm/<folder2>"
---

2.4.5. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
  • オプション: クラスターを作成する前に、デフォルトのロードバランサーの代わりに外部ロードバランサーを設定します。

    重要

    インストールプログラムに API および Ingress 静的アドレスを指定する必要はありません。この設定を選択した場合は、追加のアクションを実行して、参照される各 vSphere サブネットから IP アドレスを受け入れるネットワークターゲットを定義する必要があります。「外部ロードバランサーの設定」のセクションを参照してください。

手順

  • インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    $ ./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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

2.4.6. 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

2.4.7. レジストリーストレージの作成

クラスターのインストール後に、レジストリー Operator のストレージを作成する必要があります。

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

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

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

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

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

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

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

2.4.7.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

2.4.7.2.2. 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 のレジストリーの設定 を参照してください。

2.4.8. OpenShift Container Platform の Telemetry アクセス

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

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

関連情報

2.4.9. 外部ロードバランサー用のサービス

OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。

重要

外部ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。

このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。

Red Hat は、外部ロードバランサーに対して次のサービスをサポートしています。

  • Ingress Controller
  • OpenShift API
  • OpenShift MachineConfig API

外部ロードバランサーに対して、これらのサービスの 1 つまたはすべてを設定するように選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。

図2.1 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する Ingress Controller のネットワークワークフローの例を示すイメージ。

図2.2 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する OpenShift API のネットワークワークフローの例を示すイメージ。

図2.3 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する OpenShift MachineConfig API のネットワークワークフローの例を示すイメージ。

外部ロードバランサーでは、次の設定オプションがサポートされています。

  • ノードセレクターを使用して、Ingress Controller を特定のノードのセットにマッピングします。このセットの各ノードに静的 IP アドレスを割り当てるか、Dynamic Host Configuration Protocol (DHCP) から同じ IP アドレスを受け取るように各ノードを設定する必要があります。インフラストラクチャーノードは通常、このタイプの設定を受け取ります。
  • サブネット上のすべての IP アドレスをターゲットにします。この設定では、ロードバランサーターゲットを再設定せずにネットワーク内でノードを作成および破棄できるため、メンテナンスオーバーヘッドを削減できます。/27/28 などの小規模なネットワーク上に設定されたマシンを使用して Ingress Pod をデプロイする場合、ロードバランサーのターゲットを簡素化できます。

    ヒント

    マシン config プールのリソースを確認することで、ネットワーク内に存在するすべての IP アドレスをリスト表示できます。

OpenShift Container Platform クラスターの外部ロードバランサーを設定する前に、以下の情報を考慮してください。

  • フロントエンド IP アドレスの場合、フロントエンド IP アドレス、Ingress Controller のロードバランサー、および API ロードバランサーに同じ IP アドレスを使用できます。この機能については、ベンダーのドキュメントを確認してください。
  • バックエンド IP アドレスの場合、OpenShift Container Platform コントロールプレーンノードの IP アドレスが、外部ロードバランサーの存続期間中に変更されないようにください。次のいずれかのアクションを実行すると、これを実現できます。

    • 各コントロールプレーンノードに静的 IP アドレスを割り当てます。
    • ノードが DHCP リースを要求するたびに、DHCP から同じ IP アドレスを受信するように各ノードを設定します。ベンダーによっては、DHCP リースは IP 予約または静的 DHCP 割り当ての形式になる場合があります。
  • Ingress Controller バックエンドサービスの外部ロードバランサーで、Ingress Controller を実行する各ノードを手動で定義します。たとえば、Ingress Controller が未定義のノードに移動すると、接続が停止する可能性があります。

2.4.9.1. 外部ロードバランサーの設定

OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。

重要

外部ロードバランサーを設定する前に、「外部ロードバランサー用のサービス」セクションを必ず確認してください。

外部ロードバランサー用に設定するサービスに適用される次の前提条件を確認してください。

注記

クラスター上で動作する MetalLB は、外部ロードバランサーとして機能します。

OpenShift API の前提条件

  • フロントエンド IP アドレスを定義している。
  • TCP ポート 6443 および 22623 は、ロードバランサーのフロントエンド IP アドレスで公開されている。以下の項目を確認します。

    • ポート 6443 が OpenShift API サービスにアクセスできる。
    • ポート 22623 が Ignition 起動設定をノードに提供できる。
  • フロントエンド IP アドレスとポート 6443 へは、OpenShift Container Platform クラスターの外部の場所にいるシステムのすべてのユーザーがアクセスできる。
  • フロントエンド IP アドレスとポート 22623 は、OpenShift Container Platform ノードからのみ到達できる。
  • ロードバランサーバックエンドは、ポート 6443 および 22623 の OpenShift Container Platform コントロールプレーンノードと通信できる。

Ingress Controller の前提条件

  • フロントエンド IP アドレスを定義している。
  • TCP ポート 443 および 80 はロードバランサーのフロントエンド IP アドレスで公開されている。
  • フロントエンドの IP アドレス、ポート 80、ポート 443 へは、OpenShift Container Platform クラスターの外部の場所にあるシステムの全ユーザーがアクセスできる。
  • フロントエンドの IP アドレス、ポート 80、ポート 443 は、OpenShift Container Platform クラスターで動作するすべてのノードから到達できる。
  • ロードバランサーバックエンドは、ポート 80、443、および 1936 で Ingress Controller を実行する OpenShift Container Platform ノードと通信できる。

ヘルスチェック URL 仕様の前提条件

ほとんどのロードバランサーは、サービスが使用可能か使用不可かを判断するヘルスチェック URL を指定して設定できまうs.OpenShift Container Platform は、OpenShift API、Machine Configuration API、および Ingress Controller バックエンドサービスのこれらのヘルスチェックを提供します。

次の例は、前にリスト表示したバックエンドサービスのヘルスチェック仕様を示しています。

Kubernetes API ヘルスチェック仕様の例

Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10

Machine Config API ヘルスチェック仕様の例

Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10

Ingress Controller のヘルスチェック仕様の例

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10

手順

  1. HAProxy Ingress Controller を設定して、ポート 6443、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。

    HAProxy 設定の例

    #...
    listen my-cluster-api-6443
        bind 192.168.1.100:6443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /readyz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2
    
    listen my-cluster-machine-config-api-22623
        bind 192.168.1.100:22623
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2
    
    listen my-cluster-apps-443
            bind 192.168.1.100:443
            mode tcp
            balance roundrobin
        option httpchk
        http-check connect
        http-check send meth GET uri /healthz/ready
        http-check expect status 200
            server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
            server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
            server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2
    
    listen my-cluster-apps-80
            bind 192.168.1.100:80
            mode tcp
            balance roundrobin
        option httpchk
        http-check connect
        http-check send meth GET uri /healthz/ready
        http-check expect status 200
            server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
            server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
            server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
    # ...

  2. curl CLI コマンドを使用して、外部ロードバランサーとそのリソースが動作していることを確認します。

    1. 次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure

      設定が正しい場合は、応答として JSON オブジェクトを受信します。

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
      }
    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      Content-Length: 0
    3. 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.ocp4.private.opequon.net/
      cache-control: no-cache
    4. 次のコマンドを実行して出力を確認し、コントローラーがポート 443 の Ingress Controller リソースにアクセスできることを確認します。

      $ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
  3. 外部ロードバランサーのフロントエンド IP アドレスをターゲットにするように、クラスターの DNS レコードを設定します。ロードバランサー経由で、クラスター API およびアプリケーションの DNS サーバーのレコードを更新する必要があります。

    変更された DNS レコードの例

    <load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End

    <load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End
    重要

    DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。

  4. curl CLI コマンドを使用して、外部ロードバランサーと DNS レコード設定が動作していることを確認します。

    1. 次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure

      設定が正しい場合は、応答として JSON オブジェクトを受信します。

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
        }
    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      Content-Length: 0
    3. 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      cache-control: no-cacheHTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Tue, 17 Nov 2020 08:42:10 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
    4. 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private

2.4.10. 次のステップ

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.