インストール


OpenShift Container Platform 4.11

OpenShift Container Platform クラスターのインストールおよび設定

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Container Platform のインストール方法と、一部の設定プロセスの詳細を説明します。

第1章 OpenShift Container Platform インストールの概要

1.1. OpenShift Container Platform のインストール

OpenShift Container Platform インストールプログラムの柔軟性を利用してクラスターをインストールできます。このプログラムは次の方法で使用できます。

  • プロビジョニングされたインフラストラクチャーにクラスターをデプロイします。
  • 準備して管理するインフラストラクチャーにクラスターをデプロイします。

以下に、2 種類の基本的な OpenShift Container Platform クラスターの詳細を示します。

  • インストーラーでプロビジョニングされるインフラストラクチャークラスター
  • ユーザーによってプロビジョニングされるインフラストラクチャークラスター

どちらのクラスタータイプにも次の特徴があります。

  • 単一障害点のない高可用性インフラストラクチャーがデフォルトで利用可能です。
  • 管理者は、更新メカニズムやスケジュールなどの更新を制御できます。

1.1.1. インストールプログラムについて

インストールプログラムを使用して、各タイプのクラスターをデプロイメントできます。インストールプログラムは、ブートストラップ、コントロールプレーン、コンピュートマシンの Ignition 設定ファイルなどのメインアセットを生成します。インフラストラクチャーを適切に設定している場合、これらの 3 つのマシン設定を使用して OpenShift Container Platform クラスターを起動できます。

OpenShift Container Platform インストールプログラムは、クラスターのインストールを管理するために一連のターゲットおよび依存関係を使用します。インストールプログラムには、達成する必要のある一連のターゲットが設定され、それぞれのターゲットには一連の依存関係が含まれます。各ターゲットはそれぞれの依存関係の条件が満たされ次第、別個に解決されるため、インストールプログラムは複数のターゲットを並行して達成できるように動作し、最終的にクラスターが実行するようにします。プログラムが依存関係を満たしているため、インストールプログラムはコマンドを実行してコンポーネントを再作成する代わりに、既存のコンポーネントを認識して使用します。

図1.1 OpenShift Container Platform インストールのターゲットおよび依存関係

OpenShift Container Platform インストールのターゲットおよび依存関係

1.1.2. Red Hat Enterprise Linux CoreOS (RHCOS) について

インストール後に、各クラスターマシンは Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングマシンとして使用します。RHCOS は Red Hat Enterprise Linux (RHEL) の不変のコンテナーホストのバージョンであり、デフォルトで SELinux が有効になった RHEL カーネルを特長としています。RHCOS には、Kubernetes ノードエージェントである kubelet や、Kubernetes に対して最適化される CRI-O コンテナーランタイムが含まれます。

OpenShift Container Platform 4.11 クラスターのすべてのコントロールプレーンは、Ignition と呼ばれる最初の起動時に使用される重要なプロビジョニングツールが含まれる RHCOS を使用する必要があります。このツールは、クラスターのマシンの設定を可能にします。オペレーティングシステムの更新は、OSTree をバックエンドとして使用する起動可能なコンテナーイメージとして配信され、Machine Config Operator によりクラスター全体にデプロイされます。実際のオペレーティングシステムの変更は、rpm-ostree を使用することにより、atomic 操作として各マシン上でインプレースで行われます。これらのテクノロジーを組み合わせることで、OpenShift Container Platform は、プラットフォーム全体を最新の状態に保つインプレースアップグレードによって、クラスター上の他のアプリケーションを管理するのと同じようにオペレーティングシステムを管理できるようになります。これらのインプレースアップグレードにより、オペレーションチームの負担を軽減できます。

すべてのクラスターマシンのオペレーティングシステムとして RHCOS を使用する場合、クラスターはオペレーティングシステムを含むコンポーネントとマシンのあらゆる側面を管理します。このため、マシンを変更できるのは、インストールプログラムと Machine Config Operator だけです。インストールプログラムは、Ignition 設定ファイルを使用して各マシンの正確な状態を設定し、インストール後に Machine Config Operator が新しい証明書やキーの適用などのマシンへの追加の変更を完了します。

1.1.3. OpenShift Container Platform のインストールに関する一般的な用語集

この用語集では、インストールコンテンツに関する一般的な用語を定義しています。インストールプロセスの理解を深めるために、次の用語リストを確認してください。

ブートストラップノード
OpenShift Container Platform コントロールプレーンをデプロイするために必要な最小限の Kubernetes 設定を実行する一時的なマシン。
コントロールプレーン
コンテナーのライフサイクルを定義、デプロイ、および管理するための API とインターフェイスを公開するコンテナーオーケストレーションレイヤー。コントロールプレーンマシンとも呼ばれます。
コンピュートノード
クラスターユーザーのワークロードを実行するノード。ワーカーノードとしても知られています。
非接続インストール
場合によっては、プロキシーサーバーを介しても、データセンターの一部はインターネットにアクセスできない可能性があります。このような環境でも OpenShift Container Platform をインストールできますが、必要なソフトウェアおよびイメージをダウンロードし、これらを非接続環境で利用できる状態にする必要があります。
OpenShift Container Platform インストールプログラム
インフラストラクチャーをプロビジョニングし、クラスターをデプロイするプログラム。
インストーラーでプロビジョニングされるインフラストラクチャー
インストールプログラムは、クラスターを実行するインフラストラクチャーをデプロイして設定します。
Ignition 設定ファイル
オペレーティングシステムの初期化中に Ignition ツールが Red Hat Enterprise Linux CoreOS (RHCOS) を設定するために使用するファイル。インストールプログラムは、ブートストラップ、コントロールプレーン、およびワーカーノードを初期化するために、さまざまな Ignition 設定ファイルを生成します。
Kubernetes マニフェスト
JSON または YAML 形式の Kubernetes API オブジェクトの仕様。設定ファイルには、デプロイメント、設定マップ、シークレット、デーモンセットなどを含めることができます。
Kubelet
コンテナーが Pod で実行されていることを確認するために、クラスター内の各ノードで実行されるプライマリーノードエージェント。
ロードバランサー
ロードバランサーは、クライアントに対する単一の通信先として機能します。API のロードバランサーは、着信トラフィックをコントロールプレーンノード全体に分散します。
Machine Config Operator
クラスター内のノードのカーネルと kubelet との間にあるすべてのものを含む、基本オペレーティングシステムとコンテナーランタイムの設定と更新を管理および適用する Operator。
Operator
OpenShift Container Platform クラスターで Kubernetes アプリケーションをパッケージ化、デプロイ、および管理するための推奨される方法。Operator は、人間の操作に関する知識を取り入れて、簡単にパッケージ化してお客様と共有できるソフトウェアにエンコードします。
ユーザーによってプロビジョニングされるインフラストラクチャー
OpenShift Container Platform は、ユーザーが独自にプロビジョニングするインフラストラクチャーにインストールできます。インストールプログラムを使用すると、クラスターインフラストラクチャーのプロビジョニングに必要なアセットを生成し、クラスターインフラストラクチャーを作成して、提供したインフラストラクチャーにクラスターをデプロイできます。

1.1.4. インストールプロセス

OpenShift Container Platform クラスターをインストールする場合、インストールプログラムを OpenShift Cluster Manager Hybrid Cloud Console の適切な Cluster Type ページからダウンロードします。このコンソールは以下を管理します。

  • アカウントの REST API。
  • 必要なコンポーネントを取得するために使用するプルシークレットであるレジストリートークン。
  • クラスターのアイデンティティーを Red Hat アカウントに関連付けて使用状況のメトリクスの収集を容易にするクラスター登録。

OpenShift Container Platform 4.11 では、インストールプログラムは、一連のアセットに対して一連のファイル変換を実行する Go バイナリーファイルです。インストールプログラムと対話する方法は、インストールタイプによって異なります。次のインストールユースケースを検討してください。

  • インストーラーでプロビジョニングされるインフラストラクチャーのクラスターの場合、インフラストラクチャーのブートストラップおよびプロビジョニングは、ユーザーが独自に行うのではなくインストールプログラムが代行します。インストールプログラムは、クラスターをサポートするために必要なネットワーク、マシン、およびオペレーティングシステムのすべてを作成します。
  • クラスターのインフラストラクチャーを独自にプロビジョニングし、管理する場合には、ブートストラップマシン、ネットワーク、負荷分散、ストレージ、および個々のクラスターマシンを含む、すべてのクラスターインフラストラクチャーおよびリソースを指定する必要があります。

インストール時には、お使いのマシンタイプ用の install-config.yaml という名前のインストール設定ファイル、Kubernetes マニフェスト、および Ingition 設定ファイルの 3 つのファイルセットを使用します。

重要

インストール時に、Kubernetes および基礎となる RHCOS オペレーティングシステムを制御する Ignition 設定ファイルを変更できます。ただし、これらのオブジェクトに対して加える変更の適合性を確認するための検証の方法はなく、これらのオブジェクトを変更するとクラスターが機能しなくなる可能性があります。これらのオブジェクトを変更する場合、クラスターが機能しなくなる可能性があります。このリスクがあるために、変更方法についての文書化された手順に従っているか、Red Hat サポートが変更することを指示した場合を除き、Kubernetes および Ignition 設定ファイルの変更はサポートされていません。

インストール設定ファイルは Kubernetes マニフェストに変換され、その後マニフェストは Ignition 設定にラップされます。インストールプログラムはこれらの Ignition 設定ファイルを使用してクラスターを作成します。

インストール設定ファイルはインストールプログラムの実行時にすべてプルーニングされるため、再び使用する必要のあるすべての設定ファイルをバックアップしてください。

重要

インストール時に設定したパラメーターを変更することはできませんが、インストール後に数多くのクラスター属性を変更することができます。

インストーラーでプロビジョニングされるインフラストラクチャーでのインストールプロセス

デフォルトのインストールタイプは、インストーラーでプロビジョニングされるインフラストラクチャーです。デフォルトで、インストールプログラムはインストールウィザードとして機能し、独自に判別できない値の入力を求めるプロンプトを出し、残りのパラメーターに妥当なデフォルト値を提供します。インストールプロセスは、高度なインフラストラクチャーシナリオに対応するようカスタマイズすることもできます。インストールプログラムは、クラスターの基盤となるインフラストラクチャーをプロビジョニングします。

標準クラスターまたはカスタマイズされたクラスターのいずれかをインストールすることができます。標準クラスターの場合、クラスターをインストールするために必要な最小限の詳細情報を指定します。カスタマイズされたクラスターの場合、コントロールプレーンが使用するマシン数、クラスターがデプロイする仮想マシンのタイプ、または Kubernetes サービスネットワークの CIDR 範囲などのプラットフォームについての詳細を指定することができます。

可能な場合は、この機能を使用してクラスターインフラストラクチャーのプロビジョニングと保守の手間を省くようにしてください。他のすべての環境の場合には、インストールプログラムを使用してクラスターインフラストラクチャーをプロビジョニングするために必要なアセットを生成できます。

インストーラーでプロビジョニングされるインフラストラクチャークラスターの場合、OpenShift Container Platform は、オペレーティングシステム自体を含むクラスターのすべての側面を管理します。各マシンは、それが参加するクラスターでホストされるリソースを参照する設定に基づいて起動します。この設定により、クラスターは更新の適用時に自己管理できます。

ユーザーによってプロビジョニングされるインフラストラクチャーを使用したインストールプロセス

OpenShift Container Platform はユーザーが独自にプロビジョニングするインフラストラクチャーにインストールすることもできます。インストールプログラムを使用してクラスターインフラストラクチャーのプロビジョニングに必要なアセットを生成し、クラスターインフラストラクチャーを作成し、その後にクラスターをプロビジョニングしたインフラストラクチャーにデプロイします。

インストールプログラムがプロビジョニングしたインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。次のリストは、一部のセルフマネージドリソースの詳細を示しています。

  • クラスターを設定するコントロールプレーンおよびコンピュートマシンの基礎となるインフラストラクチャー
  • ロードバランサー
  • DNS レコードおよび必要なサブネットを含むクラスターネットワーク
  • クラスターインフラストラクチャーおよびアプリケーションのストレージ

クラスターでユーザーによってプロビジョニングされるインフラストラクチャーを使用する場合には、RHEL コンピュートマシンをクラスターに追加するオプションを使用できます。

インストールプロセスの詳細

クラスターがプロビジョニングされると、クラスター内の各マシンにはクラスターに関する情報が必要になります。OpenShift Container Platform は初期設定時に一時的なブートストラップマシンを使用して、必要な情報を永続的なコントロールプレーンに提供します。一時的なブートストラップマシンは、クラスターの作成方法を記述する Ignition 設定ファイルを使用して起動します。ブートストラップマシンは、コントロールプレーンを設定するコントロールプレーンマシンを作成します。その後、コントロールプレーンマシンはコンピュートマシン (ワーカーマシンとしても知られる) を作成します。以下の図はこのプロセスを示しています。

図1.2 ブートストラップ、コントロールプレーンおよびコンピュートマシンの作成

ブートストラップの作成

クラスターマシンを初期化した後、ブートストラップマシンは破棄されます。すべてのクラスターがこのブートストラッププロセスを使用してクラスターを初期化しますが、ユーザーがクラスターのインフラストラクチャーをプロビジョニングする場合には、多くの手順を手動で実行する必要があります。

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

クラスターのブートストラップには、以下のステップが関係します。

  1. ブートストラップマシンが起動し、コントロールプレーンマシンの起動に必要なリモートリソースのホスティングを開始します。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
  2. ブートストラップマシンは、単一ノードの etcd クラスターと一時的な Kubernetes コントロールプレーンを起動します。
  3. コントロールプレーンマシンは、ブートストラップマシンからリモートリソースをフェッチし、起動を終了します。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
  4. 一時的なコントロールプレーンは、実稼働コントロールプレーンマシンに対して実稼働コントロールプレーンをスケジュールします。
  5. Cluster Version Operator (CVO) はオンラインになり、etcd Operator をインストールします。etcd Operator はすべてのコントロールプレーンノードで etcd をスケールアップします。
  6. 一時的なコントロールプレーンはシャットダウンし、コントロールを実稼働コントロールプレーンに渡します。
  7. ブートストラップマシンは OpenShift Container Platform コンポーネントを実稼働コントロールプレーンに挿入します。
  8. インストールプログラムはブートストラップマシンをシャットダウンします。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
  9. コントロールプレーンはコンピュートノードを設定します。
  10. コントロールプレーンは一連の Operator の形式で追加のサービスをインストールします。

このブートストラッププロセスの結果として、OpenShift Container Platform クラスターが実行されます。次に、クラスターはサポートされる環境でのコンピュートマシンの作成など、日常の操作に必要な残りのコンポーネントをダウンロードし、設定します。

1.1.5. インストール後のノード状態の確認

以下のインストールヘルスチェックが正常に行われると、OpenShift Container Platform のインストールが完了します。

  • プロビジョナーは、OpenShift Container Platform Web コンソールにアクセスできます。
  • すべてのコントロールプレーンノードが準備状態にある。
  • すべてのクラスター Operator が利用可能です。
注記

インストールが完了すると、ワーカーノードを実行する特定のクラスター Operator が継続的にすべてのワーカーノードのプロビジョニングを試みます。すべてのワーカーノードが READY と報告されるまで、多少時間がかかります。ベアメタルへのインストールの場合、ワーカーノードのトラブルシューティングを行う前に、少なくとも 60 分間待機してください。他のすべてのプラットフォームへのインストールの場合は、ワーカーノードのトラブルシューティングを行う前に、少なくとも 40 分間待機してください。ワーカーノードを実行するクラスター Operator の DEGRADED 状態は、ノードの状態ではなく、Operator 自体のリソースに依存します。

インストールが完了したら、引き続きクラスター内におけるノードの状態を監視できます。

前提条件

  • インストールプログラムはターミナルで正常に解決されます。

手順

  1. すべてのワーカーノードのステータスを表示します。

    $ oc get nodes

    出力例

    NAME                           STATUS   ROLES    AGE   VERSION
    example-compute1.example.com   Ready    worker   13m   v1.21.6+bb8d50a
    example-compute2.example.com   Ready    worker   13m   v1.21.6+bb8d50a
    example-compute4.example.com   Ready    worker   14m   v1.21.6+bb8d50a
    example-control1.example.com   Ready    master   52m   v1.21.6+bb8d50a
    example-control2.example.com   Ready    master   55m   v1.21.6+bb8d50a
    example-control3.example.com   Ready    master   55m   v1.21.6+bb8d50a

  2. すべてのワーカーマシンノードのフェーズを表示します。

    $ oc get machines -A

    出力例

    NAMESPACE               NAME                           PHASE         TYPE   REGION   ZONE   AGE
    openshift-machine-api   example-zbbt6-master-0         Running                              95m
    openshift-machine-api   example-zbbt6-master-1         Running                              95m
    openshift-machine-api   example-zbbt6-master-2         Running                              95m
    openshift-machine-api   example-zbbt6-worker-0-25bhp   Running                              49m
    openshift-machine-api   example-zbbt6-worker-0-8b4c2   Running                              49m
    openshift-machine-api   example-zbbt6-worker-0-jkbqt   Running                              49m
    openshift-machine-api   example-zbbt6-worker-0-qrl5b   Running                              49m

インストールのスコープ

OpenShift Container Platform インストールプログラムのスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後に数多くの設定タスクを実行することができます。

1.1.6. OpenShift Local の概要

OpenShift Local は、OpenShift Container Platform クラスターのビルドを開始するための迅速なアプリケーション開発をサポートします。OpenShift Local は、ローカルのコンピューターで実行し、セットアップおよびテストをシンプル化し、コンテナーベースのアプリケーションを開発するのに必要なすべてのツールと共にクラウド開発環境をローカルにエミュレートすることを目的として設計されています。

OpenShift Local は、使用するプログラミング言語にかかわらずアプリケーションをホストし、事前に設定された最小限の Red Hat OpenShift Container Platform クラスターをローカル PC に提供します。その際に、サーバーベースのインフラストラクチャーは必要ありません。

ホストされる環境では、OpenShift Local はマイクロサービスを作成してイメージに変換し、Linux、macOS、または Windows 10 以降を実行するノートパソコンまたはデスクトップ上の Kubernetes がホストするコンテナーで直接それらを実行できます。

OpenShift Local の詳細は、Red Hat OpenShift Local の概要 を参照してください。

1.2. OpenShift Container Platform クラスターでサポートされるプラットフォーム

OpenShift Container Platform バージョン 4.11 では、インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターの場合、以下のプラットフォームにインストールできます。

  • Alibaba Cloud
  • Amazon Web Services (AWS)
  • ベアメタル
  • Google Cloud Platform (GCP)
  • IBM Cloud® VPC
  • Microsoft Azure
  • Microsoft Azure Stack Hub
  • Nutanix
  • Red Hat OpenStack Platform (RHOSP)

    • OpenShift Container Platform の最新リリースは、最新の RHOSP のロングライフリリースおよび中間リリースの両方をサポートします。RHOSP リリースの互換性についての詳細は、OpenShift Container Platform on RHOSP support matrix を参照してください。
  • VMware Cloud (VMC) on AWS
  • VMware vSphere

これらのクラスターの場合、インストールプロセスを実行するコンピューターを含むすべてのマシンが、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供できるようインターネットに直接アクセスできる必要があります。

重要

インストール後は、以下の変更はサポートされません。

  • クラウドプロバイダープラットフォームの混在。
  • クラウドプロバイダーコンポーネントの混在。たとえば、クラスターをインストールしたプラットフォーム上の別のプラットフォームから永続ストレージフレームワークを使用します。

OpenShift Container Platform バージョン 4.11 では、ユーザーによってプロビジョニングされるインフラストラクチャーを使用するクラスターの場合、以下のプラットフォームにインストールできます。

  • AWS
  • Azure
  • Azure Stack Hub
  • ベアメタル
  • GCP
  • IBM Power
  • IBM Z または IBM® LinuxONE
  • RHOSP

    • OpenShift Container Platform の最新リリースは、最新の RHOSP のロングライフリリースおよび中間リリースの両方をサポートします。RHOSP リリースの互換性についての詳細は、OpenShift Container Platform on RHOSP support matrix を参照してください。
  • VMware Cloud on AWS
  • VMware vSphere

プラットフォームでサポートされているケースに応じて、user-provisioned infrastructure でインストールを実行できます。これにより、完全なインターネットアクセスでのマシンの実行、プロキシーの背後へのクラスターの配置、非接続インストールの実行が可能になります。

非接続インストールでは、クラスターのインストールに必要なイメージをダウンロードして、ミラーレジストリーに配置し、そのデータを使用してクラスターをインストールできます。vSphere またはベアメタルインフラストラクチャー上での非接続インストールでは、プラットフォームコンテナーのイメージをプルするためにインターネットにアクセスする必要がありますが、クラスターマシンはインターネットへの直接のアクセスを必要としません。

OpenShift Container Platform 4.x Tested Integrations のページには、各種プラットフォームの統合テストについての詳細が記載されています。

第2章 クラスターインストール方法の選択およびそのユーザー向けの準備

OpenShift Container Platform をインストールする前に、実行するインストールプロセスを決定し、ユーザー用にクラスターを準備する際に必要なすべてのリソースがあることを確認します。

2.1. クラスターのインストールタイプの選択

OpenShift Container Platform クラスターをインストールする前に、実行する最適なインストール手順を選択する必要があります。以下の質問に回答して、最も良いオプションを選択します。

2.1.1. OpenShift Container Platform クラスターを独自にインストールし、管理しますか ?

OpenShift Container Platform を独自にインストールし、管理する必要がある場合、以下のプラットフォームにインストールすることができます。

  • Alibaba Cloud
  • 64 ビット x86 インスタンスの Amazon Web Services (AWS)
  • 64 ビット ARM インスタンスの Amazon Web Services (AWS)
  • Microsoft Azure
  • Microsoft Azure Stack Hub
  • Google Cloud Platform (GCP)
  • Red Hat OpenStack Platform (RHOSP)
  • Red Hat Virtualization (RHV)
  • IBM Cloud VPC
  • IBM Z および LinuxONE
  • Red Hat Enterprise Linux (RHEL) KVM 用の IBM Z および LinuxONE
  • IBM Power
  • Nutanix
  • VMware vSphere
  • VMware Cloud (VMC) on AWS
  • ベアメタルまたはその他のプラットフォームに依存しないインフラストラクチャー

OpenShift Container Platform 4 クラスターは、オンプレミスハードウェアとクラウドホストサービスの両方にデプロイできますが、クラスターのすべてのマシンは同じデータセンターまたはクラウドホストサービスにある必要があります。

OpenShift Container Platform を使用する必要があるが、クラスターを独自に管理することを望まない場合は、複数のマネージドサービスオプションを使用できます。Red Hat によって完全に管理されるクラスターが必要な場合は、OpenShift Dedicated または OpenShift Online を使用することができます。OpenShift を Azure、AWS、IBM Cloud、または Google Cloud VPC でマネージドサービスとして使用することもできます。マネージドサービスの詳細は、OpenShift の製品 ページを参照してください。クラウド仮想マシンを仮想ベアメタルとして OpenShift Container Platform クラスターをインストールする場合、対応するクラウドベースのストレージはサポートされません。

OpenShift Container Platform 3 を使用したことがあり、OpenShift Container Platform 4 を使用してみたいと思われる場合は、OpenShift Container Platform 4 がどのように異なるかを理解しておく必要があります。OpenShift Container Platform 4 では、 Kubernetes アプリケーション、プラットフォームが実行されるオペレーティングシステム、Red Hat Enterprise Linux CoreOS (RHCOS) を共にシームレスにパッケージ化し、デプロイし、管理する Operator を使用します。マシンをデプロイし、それらのオペレーティングシステムを設定して OpenShift Container Platform をそれらにインストールできるようにする代わりに、RHCOS オペレーティングシステムが OpenShift Container Platform クラスターの統合された部分として使用されます。OpenShift Container Platform のインストールプロセスの一部として、クラスターマシンのオペレーティングシステムをデプロイします。OpenShift Container Platform 3 と 4 の相違点 を参照してください。

OpenShift Container Platform クラスターのインストールプロセスの一部としてマシンをプロビジョニングする必要があるため、OpenShift Container Platform 3 クラスターを OpenShift Container Platform 4 にアップグレードすることはできません。その代わりに、新規の OpenShift Container Platform 4 クラスターを作成し、OpenShift Container Platform 3 ワークロードをそれらに移行する必要があります。移行の詳細は、OpenShift Container Platform 3 から 4 への移行の概要 を参照してください。OpenShift Container Platform 4 に移行するにあたり、任意のタイプの実稼働用のクラスターのインストールプロセスを使用して新規クラスターを作成できます。

2.1.3. クラスターで既存のコンポーネントを使用する必要がありますか ?

オペレーティングシステムは OpenShift Container Platform に不可欠な要素であり、OpenShift Container Platform のインストールプログラムはすべてのインフラストラクチャーの起動を簡単に実行できます。これらは、インストーラーでプロビジョニングされるインフラストラクチャー のインストールと呼ばれています。この種のインストールでは、ユーザーは既存のインフラストラクチャーをクラスターに提供できますが、インストールプログラムがクラスターを最初に必要とするすべてのマシンをデプロイします。

クラスターまたはその基盤となるマシンの Alibaba CloudAWSAzureAzure Stack HubGCPNutanix、または VMC on AWS. へのカスタマイズを指定することなく、インストーラーでプロビジョニングされたインフラストラクチャークラスターをデプロイできます。これらのインストール方法は、実稼働対応の OpenShift Container Platform クラスターをデプロイする最も高速な方法です。

インストーラーでプロビジョニングされたインフラストラクチャークラスターの基本設定 (クラスターマシンのインスタンスタイプなど) を実行する必要がある場合は、Alibaba CloudAWSAzureGCPNutanix、または VMC on AWS のインストールをカスタマイズできます。

インストーラーでプロビジョニングされるインフラストラクチャーのインストールの場合、AWS の既存の VPCAzure の vNet、または GCP の VPC を使用できます。ネットワークインフラストラクチャーの一部を再利用して、AWSAzureGCP、または VMC on AWS のクラスターが環境内の既存の IP アドレスの割り当てと共存し、既存の MTU および VXLAN 設定と統合できるようにします。これらのクラウドに既存のアカウントおよび認証情報がある場合は、それらを再利用できますが、OpenShift Container Platform クラスターをインストールするために必要なパーミッションを持つようアカウントを変更する必要がある場合があります。

インストーラーでプロビジョニングされるインフラストラクチャー方法を使用して、RHOSPKuryr を使用した RHOSPRHVvSphere、および ベアメタル のハードウェアに適切なマシンインスタンスを作成できます。さらに、vSphereVMC on AWS では、インストール時に追加のネットワークパラメーターをカスタマイズすることもできます。

大規模なクラウドインフラストラクチャーを再利用する必要がある場合、ユーザーによってプロビジョニングされるインフラストラクチャー のインストールを実行できます。これらのインストールでは、インストールプロセス時にクラスターに必要なマシンを手動でデプロイします。AWSAzureAzure Stack HubGCP、または VMC on AWS でユーザーによってプロビジョニングされるインフラストラクチャーを実行する場合、提供されるテンプレートを使用して必要なすべてのコンポーネントを起動できます。共有 VPC on GCP を再利用することもできます。それ以外の場合は、プロバイダーに依存しない インストール方法を使用して、クラスターを他のクラウドにデプロイすることができます。

ユーザーによってプロビジョニングされるインフラストラクチャーは、既存のハードウェアで実行することもできます。RHOSPRHVIBM Z or LinuxONEIBM Z or LinuxONE with RHEL KVMIBM Power、または vSphere を使用する場合は、特定のインストール手順を使用してクラスターをデプロイします。サポートされる他のハードウェアを使用する場合は、ベアメタルのインストール 手順に従います。RHOSPvSphereVMC on AWSbare metal などの一部のプラットフォームの場合は、インストール時に追加のネットワークパラメーターをカスタマイズすることもできます。

2.1.4. クラスターに追加のセキュリティーが必要ですか ?

ユーザーによってプロビジョニングされるインストール方法を使用する場合、クラスターのプロキシーを設定できます。この手順は各インストール手順に含まれています。

パブリッククラウドのクラスターがエンドポイントを外部に公開するのを防ぐ必要がある場合、AWSAzure、または GCP のインストーラーでプロビジョニングされるインフラストラクチャーを使用してプライベートクラスターをデプロイすることができます。

非接続のクラスターまたはネットワークが制限されたクラスターなど、インターネットへのアクセスが限定されたクラスターをインストールする必要がある場合、インストールパッケージをミラーリング し、そこからクラスターをインストールできます。AWSGCPIBM Z or LinuxONEIBM Z or LinuxONE with RHEL KVMIBM PowervSphereVMC on AWS、または bare metal のネットワークが制限された環境へのユーザーによってプロビジョニングされるインフラストラクチャーのインストールの詳細な手順を実行します。AWSGCPVMC on AWSRHOSPRHV、および vSphere の詳細な手順に従って、インストーラーでプロビジョニングされるインフラストラクチャーを使用してクラスターをネットワークが制限された環境にインストールすることもできます。

クラスターを AWS GovCloud リージョンAWS China リージョン、または Azure government リージョン にデプロイする必要がある場合は、インストーラーでプロビジョニングされるインフラストラクチャーのインストール時にこれらのカスタムリージョンを設定できます。

また、インストール時に FIPS で検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリー を使用するようにクラスターマシンを設定することもできます。

重要

FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、x86_64 アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。

2.2. インストール後のユーザー向けのクラスターの準備

一部の設定は、クラスターのインストールに必須ではありませんが、ユーザーがクラスターにアクセスする前に設定することが推奨されます。クラスター自体のカスタマイズは、クラスターを設定する Operator を カスタマイズ して実行でき、クラスターをアイデンティティープロバイダーなどの他の必要なシステムに統合できます。

実稼働クラスターの場合、以下の統合を設定する必要があります。

2.3. ワークロードについてのクラスターの準備

ワークロードのニーズによっては、アプリケーションのデプロイを開始する前に、追加の手順が必要になる場合があります。たとえば、アプリケーションの ビルドストラテジー をサポートできるようなインフラストラクチャーを準備した後に、低レイテンシー のワークロードに対応できるようにしたり、機密のワークロードを保護 できるようにしたりする必要がある場合があります。アプリケーションワークロードの monitoring を設定することもできます。Windows ワークロード を実行する予定の場合、インストールプロセス時に OVN-Kubernetes を使用してハイブリッドネットワーク を有効にする必要があります。ハイブリッドネットワークは、クラスターのインストール後に有効にすることはできません。

2.4. 各種プラットフォームのサポートされているインストール方法

各種のプラットフォームで各種のインストールを実行できます。

注記

以下の表にあるように、すべてのプラットフォームですべてのインストールオプションがサポートされている訳ではありません。チェックマークは、オプションがサポートされていることを示し、関連するセクションにリンクしています。

Expand
表2.1 インストーラーでプロビジョニングされるインフラストラクチャーのオプション
 AlibabaAWS (64 ビット x86)AWS (64 ビット ARM)AzureAzure Stack HubGCPNutanixRHOSPRHVベアメタル (64 ビット x86)ベアメタル (64 ビット ARM)vSphereVMCIBM Cloud VPCIBM ZIBM Power

デフォルト

 

  

カスタム

  

  

ネットワークのカスタマイズ

 

   

  

ネットワークが制限されたインストール

 

  

 

   

プライベートクラスター

 

 

          

既存の仮想プライベートネットワーク

 

 

          

government リージョン

 

 

            

秘密の地域

 

              

China リージョン

 

              
Expand
表2.2 ユーザーによってプロビジョニングされるインフラストラクチャーのオプション
 AlibabaAWS (64 ビット x86)AWS (64 ビット ARM)AzureAzure Stack HubGCPNutanixRHOSPRHVベアメタル(64 ビット x86)ベアメタル(64 ビット ARM)vSphereVMCIBM Cloud VPCIBM ZRHEL KVM を使用した IBM ZIBM Powerプラットフォームの指定なし

カスタム

 

 

 

ネットワークのカスタマイズ

       

 

     

ネットワークが制限されたインストール

 

  

  

 

 

 

クラスタープロジェクト外でホストされる共有 VPC

     

            

第3章 非接続インストールミラーリング

3.1. 非接続インストールミラーリングについて

ミラーレジストリーを使用して、クラスターが、外部コンテンツに対する組織の制御条件を満たすコンテナーイメージのみを使用するようにすることができます。ネットワークが制限された環境でプロビジョニングするインフラストラクチャーにクラスターをインストールする前に、必要なコンテナーイメージをその環境にミラーリングする必要があります。コンテナーイメージをミラーリングするには、ミラーリング用のレジストリーが必要です。

3.1.1. ミラーレジストリーの作成

Red Hat Quay などのコンテナーイメージレジストリーがすでにある場合は、それをミラーレジストリーとして使用できます。レジストリーをまだ持っていない場合は、Red Hat Openshift 導入用のミラーレジストリー を使用して、ミラーレジストリーを作成 できます。

3.1.2. 非接続インストールのイメージのミラーリング

以下の手順のいずれかを使用して、OpenShift Container Platform イメージリポジトリーをミラーレジストリーにミラーリングできます。

3.2. Red Hat Openshift 導入用のミラーレジストリーを使用したミラーレジストリーの作成

Red Hat Openshift 導入用のミラーレジストリー は、切断されたインストールに必要な OpenShift Container Platform のコンテナーイメージのミラーリングターゲットとして使用できる小規模で合理化されたコンテナーレジストリーです。

Red Hat Quay などのコンテナーイメージレジストリーがすでにある場合は、このセクションをスキップして、OpenShift Container Platform イメージリポジトリーのミラーリング に直接進むことができます。

3.2.1. 前提条件

  • OpenShift Container Platform サブスクリプション
  • Podman 3.3 および OpenSSL がインストールされた Red Hat Enterprise Linux (RHEL) 8 および 9。
  • Red Hat Quay サービスの完全修飾ドメイン名。DNS サーバーを介して解決する必要があります。
  • ターゲットホストでのキーベースの SSH 接続。SSH キーは、ローカルインストール用に自動的に生成されます。リモートホストの場合は、独自の SSH キーを生成する必要があります。
  • vCPU 2 つ以上。
  • RAM 8 GB。
  • OpenShift Container Platform 4.11 リリースイメージの場合は約 12 GB、または OpenShift Container Platform 4.11 リリースイメージと OpenShift Container Platform 4.11 Red Hat Operator イメージの場合は約 358 GB。ストリームあたり最大 1TB 以上が推奨されます。

    重要

    これらの要件は、リリースイメージと Operator イメージのみを使用したローカルテスト結果に基づいています。ストレージ要件は、組織のニーズによって異なります。たとえば、複数の z-stream をミラーリングする場合は、より多くのスペースが必要になることがあります。標準の Red Hat Quay 機能 または適切な API コールアウト を使用して、不要なイメージを削除し、スペースを解放できます。

3.2.2. Red Hat OpenShift 導入用のミラーレジストリー

OpenShift Container Platform の切断されたデプロイメントの場合に、クラスターのインストールを実行するためにコンテナーレジストリーが必要です。このようなクラスターで実稼働レベルのレジストリーサービスを実行するには、別のレジストリーデプロイメントを作成して最初のクラスターをインストールする必要があります。Red Hat Openshift 導入用のミラーレジストリー は、このニーズに対応し、すべての OpenShift サブスクリプションに含まれています。これは、OpenShift コンソールの ダウンロード ページからダウンロードできます。

Red Hat Openshift 導入用のミラーレジストリー を使用すると、ユーザーは、 mirror-registry コマンドラインインターフェイス (CLI) ツールを使用して、Red Hat Quay の小規模バージョンとその必要なコンポーネントをインストールできます。Red Hat OpenShift 導入用のミラーレジストリーは、事前設定されたローカルストレージとローカルデータベースを使用して自動的にデプロイされます。また、このレジストリーには、自動生成されたユーザー認証情報とアクセス許可も含まれており、単一の入力セットを使用するだけで開始でき、追加の設定を選択する必要はありません。

Red Hat Openshift のミラーレジストリー は、事前に決定されたネットワーク設定を提供し、成功時にデプロイされたコンポーネントの認証情報とアクセス URL を報告します。完全修飾ドメイン名 (FQDN) サービス、スーパーユーザー名とパスワード、カスタム TLS 証明書などのオプションの設定入力のセットも少しだけ含まれています。これにより、ユーザーはコンテナーレジストリーを利用できるため、制限されたネットワーク環境で OpenShift Container Platform を実行するときに、すべての OpenShift Container Platform リリースコンテンツのオフラインミラーを簡単に作成できます。

インストール環境で別のコンテナーレジストリーがすでに使用可能な場合、Red Hat Openshift 導入用のミラーレジストリー の使用はオプションです。

3.2.2.1. Red Hat OpenShift のミラーレジストリーに関する制限

Red Hat OpenShift のミラーレジストリー には次の制限が適用されます。

  • Red Hat Openshift のミラーレジストリー は高可用性レジストリーではなく、ローカルファイルシステムストレージのみがサポートされます。Red Hat Quay や OpenShift Container Platform の内部イメージレジストリーを置き換えることを目的としたものではありません。
  • Red Hat Openshift のミラーレジストリー は、Release イメージや Red Hat Operator イメージなど、接続されていない OpenShift Container Platform クラスターのインストールに必要なイメージをホストする場合にのみサポートされます。Red Hat Enterprise Linux (RHEL) マシンのローカルストレージを使用して、RHEL でサポートされるストレージは、Red Hat Openshift 導入用のミラーレジストリー でサポートされます。

    注記

    Red Hat OpenShift のミラーレジストリー はローカルストレージを使用するため、イメージのミラーリング時に消費されるストレージの使用状況を認識し、Red Hat Quay のガベージコレクション機能を使用して潜在的な問題を軽減する必要があります。この機能の詳細は、Red Hat Quay ガベージコレクションを参照してください。

  • ブートストラップ目的で Red Hat OpenShift のミラーレジストリー にプッシュされる Red Hat 製品イメージのサポートは、各製品の有効なサブスクリプションでカバーされます。ブートストラップエクスペリエンスをさらに有効にする例外のリストは、セルフマネージド Red Hat OpenShift のサイジングおよびサブスクリプションガイド に記載されています。
  • お客様が作成したコンテンツは、Red Hat Openshift のミラーレジストリー でホストしないでください。
  • クラスターのグループの更新時にクラスターが複数あると単一障害点を生み出す可能性があるため、複数のクラスターで Red Hat Openshift のミラーレジストリー を使用することは推奨されません。Red Hat Openshift 導入用のミラーレジストリーを活用して、OpenShift Container Platform コンテンツを他のクラスターに提供できる Red Hat Quay などの実稼働環境レベルの高可用性レジストリーをホストできるクラスターをインストールすることを推奨します。

この手順では、mirror-registry インストーラーツールを使用して、 Red Hat Openshift 導入用のミラーレジストリーをローカルホストにインストールする方法について説明します。このツールを使用することで、ユーザーは、OpenShift Container Platform イメージのミラーを保存する目的で、ポート 443 で実行されるローカルホストレジストリーを作成できます。

注記

mirror-registry CLI ツールを使用してRed Hat Openshift 導入用のミラーレジストリー をインストールすると、マシンにいくつかの変更が加えられます。インストール後、インストールファイル、ローカルストレージ、および設定バンドルを含む、/ etc/quay-install ディレクトリーが作成されます。デプロイ先がローカルホストである場合には、信頼できる SSH キーが生成され、コンテナーのランタイムが永続的になるようにホストマシン上の systemd ファイルが設定されます。さらに、 init という名前の初期ユーザーが、自動生成されたパスワードを使用して作成されます。すべてのアクセス認証情報は、インストール操作の最後に出力されます。

手順

  1. OpenShift コンソールのダウンロードページにある Red Hat Openshift 導入用のミラーレジストリーの最新バージョンは、 mirror-registry.tar.gz パッケージをダウンロードしてください。
  2. mirror-registry ツールを使用して、現在のユーザーアカウントでローカルホストにRed Hat Openshift 導入用のミラーレジストリー をインストールします。使用可能なフラグの完全なリストは、Red Hat OpenShift フラグのミラーレジストリーを参照してください。

    $ ./mirror-registry install \
      --quayHostname <host_example_com> \
      --quayRoot <example_directory_name>
  3. インストール中に生成されたユーザー名とパスワードを使用して、次のコマンドを実行してレジストリーにログインします。

    $ podman login -u init \
      -p <password> \
      <host_example_com>:8443> \
      --tls-verify=false 
    1
    1
    生成された root CA 証明書を信頼するようにシステムを設定して、--tls-verify=false の実行を回避できます。詳細は、SSL を使用した Red Hat Quay への接続の保護および認証局を信頼するようにシステムを設定するを参照してください。
    注記

    インストール後、 https:// <host.example.com>:8443 の UI にアクセスしてログインすることもできます。

  4. ログイン後、OpenShift Container Platform イメージをミラーリングできます。必要に応じて、このドキュメントの OpenShift Container Platform イメージリポジトリーのミラーリングまたは、非接続クラスターで使用する Operator カタログのミラーリングセクションを参照してください。

    注記

    ストレージレイヤーの問題が原因でRed Hat Openshift 導入用のミラーレジストリー で保存されたイメージに問題がある場合は、OpenShift Container Platform イメージを再ミラーリングするか、より安定したストレージにミラーレジストリーを再インストールできます。

3.2.4. ローカルホストからの Red Hat Openshift 導入用のミラーレジストリーの更新

この手順では、upgrade コマンドを使用してローカルホストから Red Hat Openshift 導入用のミラーレジストリー を更新する方法について説明します。最新バージョンへの更新により、バグ修正およびセキュリティー脆弱性の修正が確保されます。

重要

更新時には、更新プロセスで再起動されるため、ミラーレジストリーが断続的にダウンします。

前提条件

  • Red Hat Openshift 導入用のミラーレジストリー をローカルホストにインストールしている。

手順

  • Red Hat Openshift 導入用のミラーレジストリー をローカルホストからアップグレードするには、以下のコマンドを入力します。

    $ sudo ./mirror-registry upgrade -v
    注記

    ./mirror-registry upgrade -v フラグを使用して Red Hat Openshift 導入用のミラーレジストリー をアップグレードするユーザーは、ミラーレジストリーの作成時に使用したものと同じクレデンシャルを含める必要があります。たとえば、Red Hat Openshift 導入用のミラーレジストリー--quayHostname<host_example_com> および --quayRoot<example_directory_name> でインストールした場合、ミラーレジストリーを適切にアップグレードするには、その文字列を含める必要があります。

  • Red Hat OpenShift のミラーレジストリー を 1.2.z から 1.3.0 にアップグレードし、1.2.z デプロイメントで指定されたディレクトリーを使用した場合は、新しい --pgStorage フラグと --quayStorage フラグを渡す必要があります。以下に例を示します。

    $ sudo ./mirror-registry upgrade --quayHostname <host_example_com> --quayRoot <example_directory_name> --pgStorage <example_directory_name>/pg-data --quayStorage <example_directory_name>/quay-storage -v

この手順では、mirror-registry ツールを使用して、 Red Hat Openshift 導入用のミラーレジストリーをリモートホストにインストールする方法について説明します。そうすることで、ユーザーは OpenShift Container Platform イメージのミラーを保持するレジストリーを作成できます。

注記

mirror-registry CLI ツールを使用してRed Hat Openshift 導入用のミラーレジストリー をインストールすると、マシンにいくつかの変更が加えられます。インストール後、インストールファイル、ローカルストレージ、および設定バンドルを含む、/ etc/quay-install ディレクトリーが作成されます。デプロイ先がローカルホストである場合には、信頼できる SSH キーが生成され、コンテナーのランタイムが永続的になるようにホストマシン上の systemd ファイルが設定されます。さらに、 init という名前の初期ユーザーが、自動生成されたパスワードを使用して作成されます。すべてのアクセス認証情報は、インストール操作の最後に出力されます。

手順

  1. OpenShift コンソールのダウンロードページにある Red Hat Openshift 導入用のミラーレジストリーの最新バージョンは、 mirror-registry.tar.gz パッケージをダウンロードしてください。
  2. mirror-registry ツールを使用して、現在のユーザーアカウントでローカルホストにRed Hat Openshift 導入用のミラーレジストリー をインストールします。使用可能なフラグの完全なリストは、Red Hat OpenShift フラグのミラーレジストリーを参照してください。

    $ ./mirror-registry install -v \
      --targetHostname <host_example_com> \
      --targetUsername <example_user> \
      -k ~/.ssh/my_ssh_key \
      --quayHostname <host_example_com> \
      --quayRoot <example_directory_name>
  3. インストール中に生成されたユーザー名とパスワードを使用して、次のコマンドを実行してミラーレジストリーにログインします。

    $ podman login -u init \
      -p <password> \
      <host_example_com>:8443> \
      --tls-verify=false 
    1
    1
    生成された root CA 証明書を信頼するようにシステムを設定して、--tls-verify=false の実行を回避できます。詳細は、SSL を使用した Red Hat Quay への接続の保護および認証局を信頼するようにシステムを設定するを参照してください。
    注記

    インストール後、 https:// <host.example.com>:8443 の UI にアクセスしてログインすることもできます。

  4. ログイン後、OpenShift Container Platform イメージをミラーリングできます。必要に応じて、このドキュメントの OpenShift Container Platform イメージリポジトリーのミラーリングまたは、非接続クラスターで使用する Operator カタログのミラーリングセクションを参照してください。

    注記

    ストレージレイヤーの問題が原因でRed Hat Openshift 導入用のミラーレジストリー で保存されたイメージに問題がある場合は、OpenShift Container Platform イメージを再ミラーリングするか、より安定したストレージにミラーレジストリーを再インストールできます。

3.2.6. リモートホストからの Red Hat Openshift 導入用のミラーレジストリーの更新

この手順では、upgrade コマンドを使用してリモートホストから Red Hat Openshift 導入用のミラーレジストリー を更新する方法について説明します。最新バージョンへの更新により、バグ修正およびセキュリティー脆弱性の修正が確保されます。

重要

更新時には、更新プロセスで再起動されるため、ミラーレジストリーが断続的にダウンします。

前提条件

  • Red Hat Openshift 導入用のミラーレジストリー をリモートホストにインストールしている。

手順

  • Red Hat Openshift 導入用のミラーレジストリー をリモートホストからアップグレードするには、以下のコマンドを入力します。

    $ ./mirror-registry upgrade -v --targetHostname <remote_host_url> --targetUsername <user_name> -k ~/.ssh/my_ssh_key
    注記

    ./mirror-registry upgrade -v フラグを使用して Red Hat Openshift 導入用のミラーレジストリー をアップグレードするユーザーは、ミラーレジストリーの作成時に使用したものと同じクレデンシャルを含める必要があります。たとえば、Red Hat Openshift 導入用のミラーレジストリー--quayHostname<host_example_com> および --quayRoot<example_directory_name> でインストールした場合、ミラーレジストリーを適切にアップグレードするには、その文字列を含める必要があります。

3.2.7. Red Hat OpenShift SSL/TLS 証明書のミラーレジストリーの置き換え

Red Hat OpenShift のミラーレジストリー の SSL/TLS 証明書を更新する必要がある場合もあるはずです。これは、以下のシナリオで役に立ちます。

  • 現在の Red Hat OpenShift のミラーレジストリー 証明書を置き換える場合。
  • 以前の Red Hat OpenShift のミラーレジストリー インストールと同じ証明書を使用している場合。
  • Red Hat OpenShift のミラーレジストリー 証明書を定期的に更新している場合。

Red Hat OpenShift のミラーレジストリー の SSL/TLS 証明書を置き換えるには、次の手順を使用します。

前提条件

手順

  1. 次のコマンドを入力して、Red Hat OpenShift のミラーレジストリー をインストールします。

    $ ./mirror-registry install \
    --quayHostname <host_example_com> \
    --quayRoot <example_directory_name>

    Red Hat OpenShift のミラーレジストリー$HOME/quay-install ディレクトリーにインストールされます。

  2. 新しい認証局 (CA) バンドルを準備し、新しい ssl.key および ssl.crt キーファイルを生成します。詳細は、SSL/TLS の使用 を参照してください。
  3. 次のコマンドを入力して、/$HOME/quay-install に環境変数 (QUAY など) を割り当てます。

    $ export QUAY=/$HOME/quay-install
  4. 次のコマンドを入力して、新しい ssl.crt ファイルを /$HOME/quay-install ディレクトリーにコピーします。

    $ cp ~/ssl.crt $QUAY/quay-config
  5. 次のコマンドを入力して、新しい ssl.key ファイルを /$HOME/quay-install ディレクトリーにコピーします。

    $ cp ~/ssl.key $QUAY/quay-config
  6. 次のコマンドを入力して、quay-app アプリケーション Pod を再起動します。

    $ systemctl restart quay-app

3.2.8. Red Hat Openshift 導入用のミラーレジストリーのアンインストール

  • 次のコマンドを実行して、ローカルホストから Red Hat Openshift 導入用のミラーレジストリー をアンインストールできます。

    $ ./mirror-registry uninstall -v \
      --quayRoot <example_directory_name>
    注記
    • Red Hat Openshift 導入用のミラーレジストリー を削除しようとと、削除前にユーザーにプロンプトが表示されます。--auto Approve を使用して、このプロンプトをスキップできます。
    • --quayRoot フラグを指定して Red Hat Openshift 導入用のミラーレジストリー をインストールした場合には、アンインストール時に --quayRoot フラグを含める必要があります。たとえば、 Red Hat Openshift 導入用のミラーレジストリー のインストールで --quay Rootexample_directory_name を指定した場合には、 この文字列を追加して、ミラーレジストリーを適切にアンインストールする必要があります。

3.2.9. Red Hat OpenShift フラグのミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー では、以下のフラグを使用できます。

Expand
Flags説明

--autoApprove

対話型プロンプトを無効にするブール値。true に設定すると、ミラーレジストリーをアンインストールするときに quayRoot ディレクトリーが自動的に削除されます。指定しない場合には、デフォルトは false に設定されます。

--initPassword

Quay のインストール中に作成された init ユーザーのパスワード。空白を含まず、8 文字以上にする必要があります。

--initUser string

初期ユーザーのユーザー名を表示します。指定しない場合、デフォルトで init になります。

--no-color, -c

インストール、アンインストール、およびアップグレードコマンドの実行時に、ユーザーがカラーシーケンスを無効にして、それを Ansible に伝播できるようにします。

--quayHostname

クライアントがレジストリーへの接続に使用するミラーレジストリーの完全修飾ドメイン名。Quayconfig.yamlSERVER_HOSTNAME に相当します。DNS で解決する必要があります。指定しない場合は、デフォルトは <target Hostname>:8443 です。[1]

--quayRoot, -r

root CA.keyroot CA.pemroot CA.srl 証明書など、コンテナーイメージレイヤーと設定データが保存されるディレクトリー。OpenShift Container Platform 4.10 リリースイメージの場合は約 12 GB、OpenShift Container Platform 4.10 リリースイメージおよび OpenShift Container Platform 4.10 Red Hat Operator イメージの場合は約 358 GB が必要です。指定しない場合、デフォルトは / etc/quay-install になります。

--ssh-key, -k

SSH ID キーのパス。指定しない場合、デフォルトは ~/.ssh/quay_installer です。

--sslCert

SSL/TLS 公開鍵/証明書へのパス。デフォルトは {quay Root}/quady-config で、指定しない場合は自動生成されます。

--sslCheckSkip

config.yaml ファイルの SERVER_HOSTNAME に対する証明書のホスト名のチェックをスキップします。[2]

--sslKey

HTTPS 通信に使用される SSL/TLS 秘密鍵へのパス。デフォルトは {quay Root}/quady-config で、指定しない場合は自動生成されます。

--targetHostname, -H

Quay のインストール先のホスト名。デフォルトは $HOST になります。たとえば、指定していない場合にはローカルホストになります。

--targetUsername, -u

SSH に使用するターゲットホストのユーザー。デフォルトは $USER です。たとえば、指定しない場合は現在のユーザーになります。

--verbose, -v

デバッグログと Ansible Playbook の出力を表示します。

  1. システムのパブリック DNS 名がローカルホスト名と異なる場合は、--quayHostname を変更する必要があります。さらに、--quayHostname フラグは、IP アドレスを使用したインストールをサポートしていません。ホスト名を使用してインストールする必要があります。
  2. --ssl Check Skipは、ミラーレジストリーがプロキシーの背後に設定されており、公開されているホスト名が内部の Quay ホスト名と異なる場合に使用されます。また、インストール中に、指定した Quay ホスト名に対して証明書の検証を行わない場合にも使用できます。

3.2.10. Red Hat OpenShift リリースノートのミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー は、切断されたインストールに必要な OpenShift Container Platform のコンテナーイメージのミラーリングターゲットとして使用できる小規模で合理化されたコンテナーレジストリーです。

これらのリリースノートは、OpenShift Container Platform で Red Hat Openshift 導入用のミラーレジストリー の開発を追跡します。

Red Hat Openshift 導入用のミラーレジストリー の概要については、Creating a mirror registry with mirror registry for Red Hat OpenShift を参照してください。

3.2.10.1. Mirror registry for Red Hat OpenShift 1.3.10

発行日: 2023 年 12 月 7 日

Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.14 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.2. Red Hat OpenShift 1.3.9 のミラーレジストリー

発行日: 2023-09-19

Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.12 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.3. Red Hat OpenShift 1.3.8 のミラーレジストリー

発行日: 2023 年 8 月 16 日

Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.11 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.4. Red Hat OpenShift 1.3.7 のミラーレジストリー

発行日: 2023-07-19

Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.10 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.5. Red Hat OpenShift 1.3.6 のミラーレジストリー

発行日: 2023-05-30

Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.8 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.6. Red Hat OpenShift 1.3.5 のミラーレジストリー

発行日: 2023-05-18

Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.7 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.7. Red Hat OpenShift 1.3.4 のミラーレジストリー

発行日: 2023-04-25

Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.6 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.8. Red Hat OpenShift 1.3.3 のミラーレジストリー

発行: 2023-04-05

Red Hat OpenShift のミラーレジストリー が Red Hat Quay 3.8.5 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.9. Red Hat OpenShift 1.3.2 のミラーレジストリー

発行: 2023-03-21

Red Hat OpenShift のミラーレジストリー は、Red Hat Quay 3.8.4 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.10. Red Hat OpenShift 1.3.1 のミラーレジストリー

発行日: 2023-03-7

Red Hat OpenShift のミラーレジストリー は、Red Hat Quay 3.8.3 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.11. Red Hat OpenShift 1.3.0 のミラーレジストリー

発行日: 2023-02-20

Red Hat OpenShift のミラーレジストリー が Red Hat Quay 3.8.1 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.11.1. 新機能
  • Red Hat OpenShift のミラーレジストリー が Red Hat Enterprise Linux (RHEL) 9 インストールでサポートされるようになりました。
  • Red Hat OpenShift ローカルホストインストールのミラーレジストリー で IPv6 サポートが利用できるようになりました。

    Red Hat OpenShift リモートホストインストールのミラーレジストリー では、IPv6 は現在サポートされていません。

  • 新しい機能フラグ --quayStorage が追加されました。このフラグを指定すると、Quay 永続ストレージの場所を手動で設定できます。
  • 新しい機能フラグ --pgStorage が追加されました。このフラグを指定すると、Postgres 永続ストレージの場所を手動で設定できます。
  • 以前は、Red Hat OpenShift のミラーレジストリー をインストールするには、root 権限 (sudo) が必要でした。今回の更新により、Red Hat OpenShift のミラーレジストリー をインストールするために、sudo は不要になりました。

    Red Hat OpenShift のミラーレジストリーsudo でインストールすると、インストールファイル、ローカルストレージ、および設定バンドルを含む /etc/quay-install ディレクトリーが作成されていました。sudo 要件の削除により、インストールファイルと設定バンドルが $HOME/quay-install にインストールされるようになりました。Postgres や Quay などのローカルストレージは、Podman によって自動的に作成される名前付きボリュームに格納されるようになりました。

    これらのファイルが保存されているデフォルトのディレクトリーを上書きするには、Red Hat OpenShift のミラーレジストリー のコマンドライン引数を使用できます。Red Hat OpenShift コマンドライン引数のミラーレジストリー の詳細については、Red Hat OpenShift フラグのミラーレジストリー を参照してください。

3.2.10.11.2. バグ修正
  • 以前のバージョンでは、Red Hat OpenShift のミラーレジストリー をアンインストールしようとすると、次のエラーが返される可能性がありました。["Error: no container with name or ID \"quay-postgres\" found: no such container"], "stdout": "", "stdout_lines": []*今回の更新により、Red Hat OpenShift サービスのミラーレジストリー を停止してアンインストールする順序が変更され、Red Hat OpenShift のミラーレジストリー をアンインストールするときにエラーが発生しなくなりました。詳細は、PROJQUAY-4629 を参照してください。
3.2.10.12. Red Hat OpenShift 1.2.9 のミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー が Red Hat Quay 3.7.10 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.13. Red Hat OpenShift 1.2.8 のミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー が Red Hat Quay 3.7.9 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.14. Red Hat OpenShift 1.2.7 のミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー が Red Hat Quay 3.7.8 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.14.1. バグ修正
  • 以前は、getFQDN() は完全修飾ドメイン名 (FQDN) ライブラリーに依存してその FQDN を決定し、FQDN ライブラリーは /etc/hosts フォルダーを直接読み取ろうとしました。その結果、一部の Red Hat Enterprise Linux CoreOS (RHCOS) インストールで、一般的でない DNS 設定を使用すると、FQDN ライブラリーのインストールが失敗し、インストールが中止されました。今回の更新により、Red Hat Openshift 導入用のミラーレジストリーhostname を使用して FQDN を決定します。その結果、FQDN ライブラリーはインストールに失敗しません。(PROJQUAY-4139)
3.2.10.15. Red Hat OpenShift 1.2.6 のミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー が Red Hat Quay 3.7.7 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.15.1. 新機能

新しい機能フラグ --no-color (-c) が追加されました。この機能フラグにより、インストール、アンインストール、およびアップグレードコマンドの実行時に、ユーザーはカラーシーケンスを無効にして、それを Ansible に伝播することができます。

3.2.10.16. Red Hat OpenShift 1.2.5 のミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー が Red Hat Quay 3.7.6 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.17. Red Hat OpenShift 1.2.4 のミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー が Red Hat Quay 3.7.5 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.18. Red Hat OpenShift 1.2.3 のミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー が Red Hat Quay 3.7.4 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.19. Red Hat OpenShift 1.2.2 のミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー が Red Hat Quay 3.7.3 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.20. Red Hat OpenShift 1.2.1 のミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー が Red Hat Quay 3.7.2 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.21. Red Hat OpenShift 1.2.0 のミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー が Red Hat Quay 3.7.1 で利用できるようになりました。

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.21.1. バグ修正
  • 以前は、Quay Pod Operator 内で実行されているすべてのコンポーネントとワーカーのログレベルが DEBUG に設定されていました。その結果、不要なスペースを消費する大量のトラフィックログが作成されました。今回の更新では、ログレベルがデフォルトで WARN に設定され、トラフィック情報を減らして問題のシナリオに焦点を当てています。(PROJQUAY-3504)
3.2.10.22. Red Hat OpenShift 1.1.0 のミラーレジストリー

Red Hat Openshift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。

3.2.10.22.1. 新機能
  • 新しいコマンド mirror-registry upgrade が追加されました。このコマンドは、設定やデータに干渉することなく、すべてのコンテナーイメージをアップグレードします。

    注記

    以前に quayRoot がデフォルト以外に設定されていた場合は、それをアップグレードコマンドに渡す必要があります。

3.2.10.22.2. バグ修正
  • 以前は、quayHostname または targetHostname がない場合に、ローカルホスト名がデフォルトになることはありませんでした。今回の更新により、quayHostnametargetHostname がない場合は、ローカルホスト名がデフォルトになります。(PROJQUAY-3079)
  • 以前は、コマンド ./mirror-registry --versionunknown flag エラーを返しました。現在は、./mirror-registry --version を実行すると、Red Hat Openshift 導入用のミラーレジストリー の現行バージョンが返されます。(PROJQUAY-3086)
  • 以前は、たとえば ./mirror-registry install --initUser <user_name> --initPassword <password> --verbose を実行する場合など、ユーザーはインストール中にパスワードを設定できませんでした。今回の更新により、ユーザーはインストール中にパスワードを設定できるようになりました。(PROJQUAY-3149)
  • 以前は、Red Hat Openshift 導入用のミラーレジストリー は、Pod が破棄された場合に Pod を再作成しませんでした。現在は、Pod が破棄された場合は Pod が再作成されます。(PROJQUAY-3261)

3.2.11. 関連情報

3.3. 非接続インストールのイメージのミラーリング

クラスターが、外部コンテンツに対する組織の制限条件を満たすコンテナーイメージのみを使用するようにできますネットワークが制限された環境でプロビジョニングするインフラストラクチャーにクラスターをインストールする前に、必要なコンテナーイメージをその環境にミラーリングする必要があります。コンテナーイメージをミラーリングするには、ミラーリング用のレジストリーが必要です。

重要

必要なコンテナーイメージを取得するには、インターネットへのアクセスが必要です。この手順では、ネットワークとインターネットの両方にアクセスできるミラーホストにミラーレジストリーを配置します。ミラーホストにアクセスできない場合は、非接続クラスターで使用する Operator カタログのミラーリング を使用して、ネットワークの境界を越えて移動できるデバイスにイメージをコピーします。

3.3.1. 前提条件

  • 以下のレジストリーのいずれかなど、OpenShift Container Platform クラスターをホストする場所に Docker v2-2 をサポートするコンテナーイメージレジストリーが必要です。

    Red Hat Quay のライセンスをお持ちの場合は、概念実証のため に、または Red Hat Quay Operator を使用 して Red Hat Quay をデプロイする方法を記載したドキュメントを参照してください。レジストリーの選択およびインストールがにおいてさらにサポートが必要な場合は、営業担当者または Red Hat サポートにお問い合わせください。

  • コンテナーイメージレジストリーの既存のソリューションがまだない場合には、OpenShift Container Platform のサブスクライバーに Red Hat Openshift 導入用のミラーレジストリー が提供されます。Red Hat Openshift 導入用のミラーレジストリーはサブスクリプションに含まれており、切断されたインストールで OpenShift Container Platform で必須のコンテナーイメージのミラーリングに使用できる小規模なコンテナーレジストリーです。

3.3.2. ミラーレジストリーについて

OpenShift Container Platform のインストールとその後の製品更新に必要なイメージは、Red Hat Quay、JFrog Artifactory、Sonatype Nexus Repository、Harbor などのコンテナーミラーレジストリーにミラーリングできます。大規模なコンテナーレジストリーにアクセスできない場合は、OpenShift Container Platform サブスクリプションに含まれる小規模なコンテナーレジストリーである Red Hat Openshift 導入用のミラーレジストリー を使用できます。

Red Hat Quay、Red Hat Openshift 導入用のミラーレジストリー、Artifactory、Sonatype Nexus リポジトリー、Harbor など、Dockerv2-2 をサポートする任意のコンテナーレジストリーを使用できます。選択したレジストリーに関係なく、インターネット上の Red Hat がホストするサイトから分離されたイメージレジストリーにコンテンツをミラーリングする手順は同じです。コンテンツをミラーリングした後に、各クラスターをミラーレジストリーからこのコンテンツを取得するように設定します。

重要

OpenShift イメージレジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。

Red Hat Openshift 導入用のミラーレジストリー以外のコンテナーレジストリーを選択する場合は、プロビジョニングするクラスター内の全マシンから到達可能である必要があります。レジストリーに到達できない場合、インストール、更新、またはワークロードの再配置などの通常の操作が失敗する可能性があります。そのため、ミラーレジストリーは可用性の高い方法で実行し、ミラーレジストリーは少なくとも OpenShift Container Platform クラスターの実稼働環境の可用性の条件に一致している必要があります。

ミラーレジストリーを OpenShift Container Platform イメージで設定する場合、2 つのシナリオを実行することができます。インターネットとミラーレジストリーの両方にアクセスできるホストがあり、クラスターノードにアクセスできない場合は、そのマシンからコンテンツを直接ミラーリングできます。このプロセスは、connected mirroring (接続ミラーリング) と呼ばれます。このようなホストがない場合は、イメージをファイルシステムにミラーリングしてから、そのホストまたはリムーバブルメディアを制限された環境に配置する必要があります。このプロセスは、disconnected mirroring (非接続ミラーリング) と呼ばれます。

ミラーリングされたレジストリーの場合は、プルされたイメージのソースを表示するには、CRI-O ログで Trying to access のログエントリーを確認する必要があります。ノードで crictl images コマンドを使用するなど、イメージのプルソースを表示する他の方法では、イメージがミラーリングされた場所からプルされている場合でも、ミラーリングされていないイメージ名を表示します。

注記

Red Hat は、OpenShift Container Platform を使用してサードパーティーのレジストリーをテストしません。

関連情報

CRI-O ログを表示してイメージソースを表示する方法の詳細は、Viewing the image pull source を参照してください。

3.3.3. ミラーホストの準備

ミラー手順を実行する前に、ホストを準備して、コンテンツを取得し、リモートの場所にプッシュできるようにする必要があります。

3.3.3.1. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

3.3.4. イメージのミラーリングを可能にする認証情報の設定

Red Hat からミラーへのイメージのミラーリングを可能にするコンテナーイメージレジストリーの認証情報ファイルを作成します。

警告

クラスターのインストール時に、このイメージレジストリー認証情報ファイルをプルシークレットとして使用しないでください。クラスターのインストール時にこのファイルを指定すると、クラスター内のすべてのマシンにミラーレジストリーへの書き込みアクセスが付与されます。

警告

このプロセスでは、ミラーレジストリーのコンテナーイメージレジストリーへの書き込みアクセスがあり、認証情報をレジストリープルシークレットに追加する必要があります。

前提条件

  • 切断された環境で使用するミラーレジストリーを設定しました。
  • イメージをミラーリングするミラーレジストリー上のイメージリポジトリーの場所を特定している。
  • イメージのイメージリポジトリーへのアップロードを許可するミラーレジストリーアカウントをプロビジョニングしている。

手順

インストールホストで以下の手順を実行します。

  1. Red Hat OpenShift Cluster Manager サイトの Pull Secret ページから registry.redhat.io プルシークレットをダウンロードします。
  2. JSON 形式でプルシークレットのコピーを作成します。

    $ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json> 
    1
    1
    プルシークレットを保存するフォルダーへのパスおよび作成する JSON ファイルの名前を指定します。

    ファイルの内容は以下の例のようになります。

    {
      "auths": {
        "cloud.openshift.com": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "quay.io": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "registry.connect.redhat.com": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        },
        "registry.redhat.io": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        }
      }
    }
  3. ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードまたはトークンを生成します。

    $ echo -n '<user_name>:<password>' | base64 -w0 
    1
    
    BGVtbYk3ZHAtqXs=
    1
    <user_name> および <password> については、レジストリーに設定したユーザー名およびパスワードを指定します。
  4. JSON ファイルを編集し、レジストリーについて記述するセクションをこれに追加します。

      "auths": {
        "<mirror_registry>": { 
    1
    
          "auth": "<credentials>", 
    2
    
          "email": "you@example.com"
        }
      },
    1
    <mirror_registry> については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:8443
    2
    <credentials> については、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

    ファイルは以下の例のようになります。

    {
      "auths": {
        "registry.example.com": {
          "auth": "BGVtbYk3ZHAtqXs=",
          "email": "you@example.com"
        },
        "cloud.openshift.com": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "quay.io": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "registry.connect.redhat.com": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        },
        "registry.redhat.io": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        }
      }
    }

3.3.5. OpenShift Container Platform イメージリポジトリーのミラーリング

クラスターのインストールまたはアップグレード時に使用するために、OpenShift Container Platform イメージリポジトリーをお使いのレジストリーにミラーリングします。

前提条件

  • ミラーホストがインターネットにアクセスできる。
  • ネットワークが制限された環境で使用するミラーレジストリーを設定し、設定した証明書および認証情報にアクセスできる。
  • Red Hat OpenShift Cluster Manager からプルシークレット をダウンロードし、ミラーリポジトリーへの認証を含めるようにこれを変更している。
  • 自己署名証明書を使用する場合は、証明書にサブジェクトの別名を指定しています。

手順

ミラーホストで以下の手順を実行します。

  1. OpenShift Container Platform ダウンロード ページを確認し、インストールする必要のある OpenShift Container Platform のバージョンを判別し、Repository Tags ページで対応するタグを判別します。
  2. 必要な環境変数を設定します。

    1. リリースバージョンをエクスポートします。

      $ OCP_RELEASE=<release_version>

      <release_version> について、インストールする OpenShift Container Platform のバージョンに対応するタグを指定します (例: 4.5.4)。

    2. ローカルレジストリー名とホストポートをエクスポートします。

      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'

      <local_registry_host_name> については、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port> については、コンテンツの送信に使用するポートを指定します。

    3. ローカルリポジトリー名をエクスポートします。

      $ LOCAL_REPOSITORY='<local_repository_name>'

      <local_repository_name> については、ocp4/openshift4 などのレジストリーに作成するリポジトリーの名前を指定します。

    4. ミラーリングするリポジトリーの名前をエクスポートします。

      $ PRODUCT_REPO='openshift-release-dev'

      実稼働環境のリリースの場合には、openshift-release-dev を指定する必要があります。

    5. パスをレジストリープルシークレットにエクスポートします。

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

      <path_to_pull_secret> については、作成したミラーレジストリーのプルシークレットの絶対パスおよびファイル名を指定します。

    6. リリースミラーをエクスポートします。

      $ RELEASE_NAME="ocp-release"

      実稼働環境のリリースについては、ocp-release を指定する必要があります。

    7. x86_64aarch64 など、サーバーのアーキテクチャーの種類をエクスポートします。

      $ ARCHITECTURE=<server_architecture>
    8. ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。

      $ REMOVABLE_MEDIA_PATH=<path> 
      1
      1
      最初のスラッシュ (/) 文字を含む完全パスを指定します。
  3. バージョンイメージをミラーレジストリーにミラーリングします。

    • ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。

      1. リムーバブルメディアをインターネットに接続しているシステムに接続します。
      2. ミラーリングするイメージおよび設定マニフェストを確認します。

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON}  \
             --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
             --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
             --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
      3. 直前のコマンドの出力の imageContentSources セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時に imageContentSources セクションを install-config.yaml ファイルに追加する必要があります。
      4. イメージをリムーバブルメディア上のディレクトリーにミラーリングします。

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
      5. メディアをネットワークが制限された環境に移し、イメージをローカルコンテナーレジストリーにアップロードします。

        $ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 
        1
        1
        REMOVABLE_MEDIA_PATH の場合、イメージのミラーリング時に指定した同じパスを使用する必要があります。
        重要

        oc image mirror を実行すると、error: unable to retrieve source image エラーが発生する場合があります。このエラーは、イメージレジストリーに存在しなくなったイメージへの参照がイメージインデックスに含まれている場合に発生します。イメージインデックスは、それらのイメージを実行しているユーザーがアップグレードグラフの新しいポイントへのアップグレードパスを実行できるように、古い参照を保持する場合があります。一時的な回避策として、--skip-missing オプションを使用してエラーを回避し、イメージインデックスのダウンロードを続行できます。詳細は、Service Mesh Operator mirroring failed を参照してください。

    • ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下の操作を実行します。

      1. 以下のコマンドを使用して、リリースイメージをローカルレジストリーに直接プッシュします。

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON}  \
             --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
             --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
             --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}

        このコマンドは、リリース情報をダイジェストとしてプルします。その出力には、クラスターのインストール時に必要な imageContentSources データが含まれます。

      2. 直前のコマンドの出力の imageContentSources セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時に imageContentSources セクションを install-config.yaml ファイルに追加する必要があります。

        注記

        ミラーリングプロセス中にイメージ名に Quay.io のパッチが適用され、podman イメージにはブートストラップ仮想マシンのレジストリーに Quay.io が表示されます。

  4. ミラーリングしたコンテンツをベースとしているインストールプログラムを作成するには、これをデプロイメントし、リリースに固定します。

    • ミラーホストがインターネットにアクセスできない場合は、以下のコマンドを実行します。

      $ oc adm release extract -a ${LOCAL_SECRET_JSON} --icsp-file=<file> \ --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}"
    • ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下のコマンドを実行します。

      $ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
      重要

      選択した OpenShift Container Platform バージョンに適したイメージを使用するには、ミラーリングされたコンテンツからインストールプログラムをデプロイメントする必要があります。

      インターネット接続のあるマシンで、このステップを実行する必要があります。

  5. インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターの場合は、以下のコマンドを実行します。

    $ openshift-install

3.3.6. 非接続環境の Cluster Samples Operator

非接続環境で Cluster Samples Operator を設定するには、クラスターのインストール後に追加の手順を実行する必要があります。以下の情報を確認し、準備してください。

3.3.6.1. ミラーリングの Cluster Samples Operator のサポート

インストール時に、OpenShift Container Platform は imagestreamtag-to-image という名前の設定マップを openshift-cluster-samples-operator namespace に作成します。imagestreamtag-to-image 設定マップには、各イメージストリームタグのエントリー (設定されるイメージ) が含まれます。

設定マップの data フィールドの各エントリーのキーの形式は、<image_stream_name>_<image_stream_tag_name> です。

OpenShift Container Platform の非接続インストール時に、Cluster Samples Operator のステータスは Removed に設定されます。これを Managed に変更することを選択する場合、サンプルがインストールされます。

注記

ネットワークが制限されている環境または切断されている環境でサンプルを使用するには、ネットワークの外部のサービスにアクセスする必要がある場合があります。サービスの例には、Github、Maven Central、npm、RubyGems、PyPi などがあります。場合によっては、Cluster Samples Operator のオブジェクトが必要なサービスに到達できるようにするために、追加の手順を実行する必要があります。

この config map は、イメージストリームをインポートするためにミラーリングする必要があるイメージの参照情報として使用できます。

  • Cluster Samples Operator が Removed に設定される場合、ミラーリングされたレジストリーを作成するか、使用する必要のある既存のミラーリングされたレジストリーを判別できます。
  • 新しい config map をガイドとして使用し、ミラーリングされたレジストリーに必要なサンプルをミラーリングします。
  • Cluster Samples Operator 設定オブジェクトの skippedImagestreams リストに、ミラーリングされていないイメージストリームを追加します。
  • Cluster Samples Operator 設定オブジェクトの samplesRegistry をミラーリングされたレジストリーに設定します。
  • 次に、Cluster Samples Operator を Managed に設定し、ミラーリングしたイメージストリームをインストールします。

3.3.7. 非接続クラスターで使用する Operator カタログのミラーリング

oc adm catalog mirror コマンドを使用して、Red Hat が提供するカタログまたはカスタムカタログの Operator コンテンツをコンテナーイメージレジストリーにミラーリングできます。ターゲットレジストリーは Docker v2-2 をサポートする必要があります。ネットワークが制限された環境のクラスターの場合、このレジストリーには、ネットワークが制限されたクラスターのインストール時に作成されたミラーレジストリーなど、クラスターにネットワークアクセスのあるレジストリーを使用できます。

重要
  • OpenShift イメージレジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。
  • oc adm catalog mirror を実行すると、error: unable to retrieve source image エラーが発生する場合があります。このエラーは、イメージレジストリーに存在しなくなったイメージへの参照がイメージインデックスに含まれている場合に発生します。イメージインデックスは、それらのイメージを実行しているユーザーがアップグレードグラフの新しいポイントへのアップグレードパスを実行できるように、古い参照を保持する場合があります。一時的な回避策として、--skip-missing オプションを使用してエラーを回避し、イメージインデックスのダウンロードを続行できます。詳細は、Service Mesh Operator mirroring failed を参照してください。

oc adm catalog mirror コマンドは、Red Hat が提供するインデックスイメージであるか、独自のカスタムビルドされたインデックスイメージであるかに関係なく、ミラーリングプロセス中に指定されるインデックスイメージをターゲットレジストリーに自動的にミラーリングします。次に、ミラーリングされたインデックスイメージを使用して、Operator Lifecycle Manager (OLM) がミラーリングされたカタログを OpenShift Container Platform クラスターにロードできるようにするカタログソースを作成できます。

3.3.7.1. 前提条件

非接続クラスターで使用する Operator カタログのミラーリングには、以下の前提条件があります。

  • ネットワークアクセスが無制限のワークステーション
  • podman バージョン 1.9.3 以降。
  • 既存のカタログをフィルタリングまたは プルーニング して、Operator のサブセットのみを選択的にミラーリングする場合は、次のセクションを参照してください。

  • Red Hat が提供するカタログをミラーリングする場合は、ネットワークアクセスが無制限のワークステーションで以下のコマンドを実行し、registry.redhat.io で認証します。

    $ podman login registry.redhat.io
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス。
  • ミラーレジストリーで、ミラーリングされた Operator コンテンツの保存に使用するリポジトリーまたは namespace を決定します。たとえば、olm-mirror リポジトリーを作成できます。
  • ミラーレジストリーにインターネットアクセスがない場合は、ネットワークアクセスが無制限のワークステーションにリムーバブルメディアを接続します。
  • registry.redhat.io などのプライベートレジストリーを使用している場合、後続の手順で使用するために REG_CREDS 環境変数をレジストリー認証情報のファイルパスに設定します。たとえば podman CLI の場合は、以下のようになります。

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
3.3.7.2. カタログコンテンツの抽出およびミラーリング

oc adm catalog mirror コマンドは、インデックスイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。コマンドのデフォルト動作で、マニフェストを生成し、インデックスイメージからのすべてのイメージコンテンツを、インデックスイメージと同様にミラーレジストリーに対して自動的にミラーリングします。

または、ミラーレジストリーが完全に非接続または エアギャップ環境のホスト上にある場合、最初にコンテンツをリムーバブルメディアにミラーリングし、メディアを非接続環境に移行してから、メディアからレジストリーにコンテンツをレジストリーに対してミラーリングできます。

3.3.7.2.1. 同じネットワーク上のレジストリーへのカタログコンテンツのミラーリング

ミラーレジストリーがネットワークアクセスが無制限のワークステーションと同じネットワーク上に置かれている場合は、ワークステーションで以下のアクションを実行します。

手順

  1. ミラーレジストリーに認証が必要な場合は、以下のコマンドを実行してレジストリーにログインします。

    $ podman login <mirror_registry>
  2. 以下のコマンドを実行して、コンテンツをミラーレジストリーに対して抽出し、ミラーリングします。

    $ oc adm catalog mirror \
        <index_image> \ 
    1
    
        <mirror_registry>:<port>[/<repository>] \ 
    2
    
        [-a ${REG_CREDS}] \ 
    3
    
        [--insecure] \ 
    4
    
        [--index-filter-by-os='<platform>/<arch>'] \ 
    5
    
        [--manifests-only] 
    6
    1
    ミラーリングするカタログのインデックスイメージを指定します。
    2
    Operator の内容をミラーリングするターゲットレジストリーの完全修飾ドメイン名 (FQDN) を指定します。ミラーレジストリー <repository> には、前提条件で説明した olm-mirror など、レジストリー上の既存のリポジトリーまたは namespace を指定できます。ミラーリング中に既存のリポジトリーが見つかった場合は、そのリポジトリー名が結果のイメージ名に追加されます。イメージ名にリポジトリー名を含めたくない場合は、この行から <repository> 値を省略します (例: <mirror_registry>:<port>)
    3
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。registry.redhat.io には、{REG_CREDS} が必要です。
    4
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    5
    オプション: 複数のバリアントが利用可能な場合に、選択するインデックスイメージのプラットフォームおよびアーキテクチャーを指定します。イメージは '<platform>/<arch>[/<variant>]' として渡されます。これはインデックスで参照されるイメージには適用されません。有効な値は、linux/amd64linux/ppc64lelinux/s390xlinux/arm64 です。
    6
    オプション: 実際にイメージコンテンツをレジストリーにミラーリングせずに、ミラーリングに必要なマニフェストのみを生成します。このオプションは、ミラーリングする内容を確認するのに役立ちます。また、パッケージのサブセットのみが必要な場合に、マッピングのリストに変更を加えることができます。次に、mapping.txt ファイルを oc image mirror コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。これは、カタログからのコンテンツの高度な選択可能ミラーリングの実行に使用するためのフラグです。

    出力例

    src image has index label for database path: /database/index.db
    using database path mapping: /database/index.db:/tmp/153048078
    wrote database to /tmp/153048078 
    1
    
    ...
    wrote mirroring manifests to manifests-redhat-operator-index-1614211642 
    2

    1
    コマンドで生成された一時的な index.db データベースのディレクトリー。
    2
    生成される manifests ディレクトリー名を記録します。このディレクトリーは、後続の手順で参照されます。
    注記

    Red Hat Quay では、ネストされたリポジトリーはサポート対象外です。その結果、oc adm catalog mirror コマンドを実行すると、401 unauthorized エラーで失敗します。回避策として、oc adm catalog mirror コマンドを実行するときに --max-components = 2 オプションを使用して、ネストされたリポジトリーの作成を無効にすることができます。この回避策の詳細は Unauthorized error thrown while using catalog mirror command with Quay registry のナレッジソリューションを参照してください。

3.3.7.2.2. カタログコンテンツをエアギャップされたレジストリーへのミラーリング

ミラーレジストリーが完全に切断された、またはエアギャップのあるホスト上にある場合は、次のアクションを実行します。

手順

  1. ネットワークアクセスが無制限のワークステーションで以下のコマンドを実行し、コンテンツをローカルファイルにミラーリングします。

    $ oc adm catalog mirror \
        <index_image> \ 
    1
    
        file:///local/index \ 
    2
    
        -a ${REG_CREDS} \ 
    3
    
        --insecure \ 
    4
    
        --index-filter-by-os='<platform>/<arch>' 
    5
    1
    ミラーリングするカタログのインデックスイメージを指定します。
    2
    現在のディレクトリーのローカルファイルにミラーリングするコンテンツを指定します。
    3
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    4
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    5
    オプション: 複数のバリアントが利用可能な場合に、選択するインデックスイメージのプラットフォームおよびアーキテクチャーを指定します。イメージは '<platform>/<arch>[/<variant>]' として指定されます。これはインデックスで参照されるイメージには適用されません。使用できる値は、linux/amd64linux/ppc64lelinux/s390xlinux/arm64、および .*です。

    出力例

    ...
    info: Mirroring completed in 5.93s (5.915MB/s)
    wrote mirroring manifests to manifests-my-index-1614985528 
    1
    
    
    To upload local images to a registry, run:
    
    	oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY 
    2

    1
    生成される manifests ディレクトリー名を記録します。このディレクトリーは、後続の手順で参照されます。
    2
    提供されたインデックスイメージをベースとする、拡張された file:// パスを記録します。このパスは、後続のステップで参照されます。

    このコマンドにより、現在のディレクトリーに v2/ ディレクトリーが作成されます。

  2. v2/ ディレクトリーをリムーバブルメディアにコピーします。
  3. メディアを物理的に削除して、これをミラーレジストリーにアクセスできる非接続環境のホストに割り当てます。
  4. ミラーレジストリーに認証が必要な場合は、非接続環境のホストで以下のコマンドを実行し、レジストリーにログインします。

    $ podman login <mirror_registry>
  5. v2/ ディレクトリーを含む親ディレクトリーから以下のコマンドを実行し、ローカルファイルからミラーレジストリーにイメージをアップロードします。

    $ oc adm catalog mirror \
        file://local/index/<repository>/<index_image>:<tag> \ 
    1
    
        <mirror_registry>:<port>[/<repository>] \ 
    2
    
        -a ${REG_CREDS} \ 
    3
    
        --insecure \ 
    4
    
        --index-filter-by-os='<platform>/<arch>' 
    5
    1
    直前のコマンド出力の file:// パスを指定します。
    2
    Operator の内容をミラーリングするターゲットレジストリーの完全修飾ドメイン名 (FQDN) を指定します。ミラーレジストリー <repository> には、前提条件で説明した olm-mirror など、レジストリー上の既存のリポジトリーまたは namespace を指定できます。ミラーリング中に既存のリポジトリーが見つかった場合は、そのリポジトリー名が結果のイメージ名に追加されます。イメージ名にリポジトリー名を含めたくない場合は、この行から <repository> 値を省略します (例: <mirror_registry>:<port>)
    3
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    4
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    5
    オプション: 複数のバリアントが利用可能な場合に、選択するインデックスイメージのプラットフォームおよびアーキテクチャーを指定します。イメージは '<platform>/<arch>[/<variant>]' として指定されます。これはインデックスで参照されるイメージには適用されません。使用できる値は、linux/amd64linux/ppc64lelinux/s390xlinux/arm64、および .*です。
    注記

    Red Hat Quay では、ネストされたリポジトリーはサポート対象外です。その結果、oc adm catalog mirror コマンドを実行すると、401 unauthorized エラーで失敗します。回避策として、oc adm catalog mirror コマンドを実行するときに --max-components = 2 オプションを使用して、ネストされたリポジトリーの作成を無効にすることができます。この回避策の詳細は Unauthorized error thrown while using catalog mirror command with Quay registry のナレッジソリューションを参照してください。

  6. oc adm catalogmirror コマンドを再度実行します。新しくミラー化されたインデックスイメージをソースとして使用し、前の手順で使用したものと同じミラーレジストリーターゲットを使用します。

    $ oc adm catalog mirror \
        <mirror_registry>:<port>/<index_image> \
        <mirror_registry>:<port>[/<repository>] \
        --manifests-only \
    1
    
        [-a ${REG_CREDS}] \
        [--insecure]
    1
    コマンドがミラーリングされたすべてのコンテンツを再度コピーしないように、このステップには --manifests-only フラグが必要です。
    重要

    前のステップで生成された imageContentSourcePolicy.yaml ファイルのイメージマッピングをローカルパスから有効なミラー位置に更新する必要があるため、このステップが必要です。そうしないと、後のステップで imageContentSourcePolicy オブジェクトを作成するときにエラーが発生します。

カタログのミラーリング後、残りのクラスターインストールを続行できます。クラスターのインストールが正常に完了した後に、この手順から manifests ディレクトリーを指定して ImageContentSourcePolicy および CatalogSource オブジェクトを作成する必要があります。これらのオブジェクトは、OperatorHub からの Operator のインストールを有効にするために必要になります。

3.3.7.3. 生成されたマニフェスト

Operator カタログコンテンツをミラーレジストリーにミラーリングした後に、現在のディレクトリーに manifests ディレクトリーが生成されます。

同じネットワークのレジストリーにコンテンツをミラーリングする場合、ディレクトリー名は以下のパターンになります。

manifests-<index_image_name>-<random_number>

直前のセクションで非接続ホストのレジストリーにコンテンツをミラーリングする場合、ディレクトリー名は以下のパターンになります。

manifests-index/<repository>/<index_image_name>-<random_number>
注記

manifests ディレクトリー名は、後続の手順で参照されます。

manifests ディレクトリーには以下のファイルが含まれており、これらの一部にはさらに変更が必要になる場合があります。

  • catalogSource.yaml ファイルは、インデックスイメージタグおよび他の関連するメタデータで事前に設定される CatalogSource オブジェクトの基本的な定義です。このファイルは、カタログソースをクラスターに追加するためにそのまま使用したり、変更したりできます。

    重要

    ローカルファイルにコンテンツをミラーリングする場合は、catalogSource.yaml ファイルを変更して metadata.name フィールドからバックスラッシュ (/) 文字を削除する必要があります。または、オブジェクトの作成を試みると、invalid resource name (無効なリソース名) を示すエラーを出して失敗します。

  • これにより、imageContentSourcePolicy.yaml ファイルは ImageContentSourcePolicy オブジェクトを定義します。このオブジェクトは、ノードを Operator マニフェストおよびミラーリングされたレジストリーに保存されるイメージ参照間で変換できるように設定します。

    注記

    クラスターが ImageContentSourcePolicy オブジェクトを使用してリポジトリーのミラーリングを設定する場合、ミラーリングされたレジストリーにグローバルプルシークレットのみを使用できます。プロジェクトにプルシークレットを追加することはできません。

  • mapping.txt ファイルには、すべてのソースイメージが含まれ、これはそれらのイメージをターゲットレジストリー内のどこにマップするかを示します。このファイルは oc image mirror コマンドと互換性があり、ミラーリング設定をさらにカスタマイズするために使用できます。

    重要

    ミラーリングのプロセスで --manifests-only フラグを使用しており、ミラーリングするパッケージのサブセットをさらにトリミングするには、mapping.txt ファイルの変更および oc image mirror コマンドでのファイルの使用について、OpenShift Container Platform 4.7 ドキュメントの Package Manifest Format カタログイメージのミラーリング の手順を参照してください。

3.3.7.4. インストール後の要件

カタログのミラーリング後、残りのクラスターインストールを続行できます。クラスターのインストールが正常に完了した後に、この手順から manifests ディレクトリーを指定して ImageContentSourcePolicy および CatalogSource オブジェクトを作成する必要があります。これらのオブジェクトは、OperatorHub からの Operator のインストールを設定し、有効にするために必要です。

3.3.8. 次のステップ

3.4. oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング

プライベートレジストリー内の OpenShift Container Platform コンテナーイメージのミラーリングされたセットからクラスターをインストールすることにより、インターネットに直接接続せずに制限されたネットワークでクラスターを実行することができます。このレジストリーは、クラスターが実行されている限り、常に実行されている必要があります。詳細は、前提条件 セクションを参照してください。

oc-mirror OpenShift CLI (oc) プラグインを使用して、完全なまたは部分的な非接続環境でイメージをミラーレジストリーにミラーリングできます。公式の Red Hat レジストリーから必要なイメージをダウンロードするには、インターネット接続のあるシステムから oc-mirror を実行する必要があります。

次の手順は、oc-mirror プラグインを使用してイメージをミラーレジストリーにミラーリングする方法の概要を示しています。

  1. イメージセット設定ファイルを作成します。
  2. 以下のいずれかの方法を使用して、イメージセットをミラーレジストリーにミラーリングします。

    • イメージセットをミラーレジストリーに直接ミラーリングします。
    • イメージセットをディスクにミラーリングし、イメージセットをターゲット環境に転送してから、イメージセットをターゲットミラーレジストリーにアップロードします。
  3. oc-mirror プラグインが生成したリソースを使用するようにクラスターを設定します。
  4. これらの手順を繰り返して、必要に応じてミラーレジストリーを更新します。

3.4.1. oc-mirror プラグインについて

oc-mirror OpenShift CLI(oc) プラグインを使用すると、単一のツールを使用して、必要なすべての OpenShift Container Platform コンテンツおよびその他のイメージをミラーレジストリーにミラーリングできます。次の機能を提供します。

  • OpenShift Container Platform のリリース、Operator、ヘルムチャート、およびその他のイメージをミラーリングするための一元化された方法を提供します。
  • OpenShift Container Platform および Operator の更新パスを維持します。
  • 宣言型イメージセット設定ファイルを使用して、クラスターに必要な OpenShift Container Platform リリース、Operator、およびイメージのみを含めます。
  • 将来のイメージセットのサイズを縮小するインクリメンタルミラーリングを実行します。
  • 前回の実行以降にイメージセット設定から除外されたターゲットミラーレジストリーからのイメージをプルーニングします。
  • オプションで、OpenShift Update Service (OSUS) を使用する際のサポートアーティファクトを生成します。

oc-mirror プラグインを使用する場合、イメージセット設定ファイルでミラーリングするコンテンツを指定します。この YAML ファイルでは、クラスターに必要な OpenShift Container Platform リリースと Operator のみを含めるように設定を微調整できます。これにより、ダウンロードして転送する必要のあるデータの量が減ります。oc-mirror プラグインは、任意のヘルムチャートと追加のコンテナーイメージをミラーリングして、ユーザーがワークロードをミラーレジストリーにシームレスに同期できるようにすることもできます。

oc-mirror プラグインを初めて実行すると、非接続クラスターのインストールまたは更新を実行するために必要なコンテンツがミラーレジストリーに入力されます。非接続クラスターが更新を受信し続けるには、ミラーレジストリーを更新しておく必要があります。ミラーレジストリーを更新するには、最初に実行したときと同じ設定を使用して oc-mirror プラグインを実行します。oc-mirror プラグインは、ストレージバックエンドからメタデータを参照し、ツールを最後に実行してからリリースされたもののみをダウンロードします。これにより、OpenShift Container Platform および Operator の更新パスが提供され、必要に応じて依存関係の解決が実行されます。

重要

oc-mirror CLI プラグインを使用してミラーレジストリーにデータを入力する場合、ミラーレジストリーをさらに更新するには、oc-mirror ツールを使用する必要があります。

3.4.2. oc-mirror の互換性とサポート

oc-mirror プラグインは、OpenShift Container Platform バージョン 4.9 以降の OpenShift Container Platform ペイロードイメージと Operator カタログのミラーリングをサポートします。

ミラーリングする必要がある OpenShift Container Platform のバージョンに関係なく、使用可能な最新バージョンの oc-mirror プラグインを使用してください。

重要

OpenShift Container Platform 4.10 のテクノロジープレビューバージョンの oc-mirror プラグインを使用している場合、ミラーレジストリーを OpenShift Container Platform 4.11 に移行することはできません。新規の oc-mirror プラグインをダウンロードし、新規ストレージバックエンドを使用して、ターゲットミラーレジストリーで新しい最上位の namespace を使用する必要があります。

3.4.3. ミラーレジストリーについて

OpenShift Container Platform のインストールとその後の製品更新に必要なイメージを、Red Hat Quay などの Docker v2-2 をサポートするコンテナーミラーレジストリーにミラーリングできます。大規模なコンテナーレジストリーにアクセスできない場合は、OpenShift Container Platform サブスクリプションに含まれる小規模なコンテナーレジストリーであるRed Hat Openshift 導入用のミラーレジストリー を使用できます。

選択したレジストリーに関係なく、インターネット上の Red Hat がホストするサイトから分離されたイメージレジストリーにコンテンツをミラーリングする手順は同じです。コンテンツをミラーリングした後に、各クラスターをミラーレジストリーからこのコンテンツを取得するように設定します。

重要

OpenShift イメージレジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。

Red Hat Openshift 導入用のミラーレジストリー以外のコンテナーレジストリーを選択する場合は、プロビジョニングするクラスター内の全マシンから到達可能である必要があります。レジストリーに到達できない場合、インストール、更新、またはワークロードの再配置などの通常の操作が失敗する可能性があります。そのため、ミラーレジストリーは可用性の高い方法で実行し、ミラーレジストリーは少なくとも OpenShift Container Platform クラスターの実稼働環境の可用性の条件に一致している必要があります。

ミラーレジストリーを OpenShift Container Platform イメージで設定する場合、2 つのシナリオを実行することができます。インターネットとミラーレジストリーの両方にアクセスできるホストがあり、クラスターノードにアクセスできない場合は、そのマシンからコンテンツを直接ミラーリングできます。このプロセスは、connected mirroring (接続ミラーリング) と呼ばれます。このようなホストがない場合は、イメージをファイルシステムにミラーリングしてから、そのホストまたはリムーバブルメディアを制限された環境に配置する必要があります。このプロセスは、disconnected mirroring (非接続ミラーリング) と呼ばれます。

ミラーリングされたレジストリーの場合は、プルされたイメージのソースを表示するには、CRI-O ログで Trying to access のログエントリーを確認する必要があります。ノードで crictl images コマンドを使用するなど、イメージのプルソースを表示する他の方法では、イメージがミラーリングされた場所からプルされている場合でも、ミラーリングされていないイメージ名を表示します。

注記

Red Hat は、OpenShift Container Platform を使用してサードパーティーのレジストリーをテストしません。

3.4.4. 前提条件

  • Red Hat Quay など、OpenShift Container Platform クラスターをホストする場所に Docker v2-2 をサポートするコンテナーイメージレジストリーを持っている。

    注記

    Red Hat Quay を使用する場合は、oc-mirror プラグインでバージョン 3.6 以降を使用する必要があります。Red Hat Quay のライセンスをお持ちの場合は、概念実証のため に、または Red Hat Quay Operator を使用 して Red Hat Quay をデプロイする方法を記載したドキュメントを参照してください。レジストリーの選択とインストールについてさらにサポートが必要な場合は、営業担当者または Red Hat サポートにお問い合わせください。

    コンテナーイメージレジストリーの既存のソリューションがまだない場合には、OpenShift Container Platform のサブスクライバーに Red Hat Openshift 導入用のミラーレジストリー が提供されます。Red Hat Openshift 導入用のミラーレジストリーはサブスクリプションに含まれており、切断されたインストールで OpenShift Container Platform で必須のコンテナーイメージのミラーリングに使用できる小規模なコンテナーレジストリーです。

3.4.5. ミラーホストの準備

oc-mirror プラグインを使用してイメージをミラーリングする前に、プラグインをインストールし、コンテナーイメージレジストリーの認証情報ファイルを作成して、Red Hat からお使いのミラーへのミラーリングを許可する必要があります。

3.4.5.1. oc-mirror OpenShift CLI プラグインのインストール

oc-mirror OpenShift CLI プラグインを使用してレジストリーイメージをミラーリングするには、プラグインをインストールする必要があります。完全な非接続環境でイメージセットをミラーリングする場合は、インターネットにアクセスできるホストと、ミラーレジストリーにアクセスできる非接続環境のホストに oc-mirror プラグインをインストールしてください。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. oc-mirror CLI プラグインをダウンロードします。

    1. OpenShift Cluster Manager Hybrid Cloud Consoleダウンロード ページに移動します。
    2. OpenShift 切断インストールツール セクションで、OpenShift Client (oc) ミラープラグインダウンロード をクリックしてファイルを保存します。
  2. アーカイブを抽出します。

    $ tar xvzf oc-mirror.tar.gz
  3. 必要に応じて、プラグインファイルを更新して実行可能にします。

    $ chmod +x oc-mirror
    注記

    oc-mirror ファイルの名前を変更しないでください。

  4. ファイルを PATH に配置して、oc-mirror CLI プラグインをインストールします (例: /usr/local/bin):。

    $ sudo mv oc-mirror /usr/local/bin/.

検証

  • oc mirror help を実行して、プラグインが正常にインストールされたことを確認します。

    $ oc mirror help
3.4.5.2. イメージのミラーリングを可能にする認証情報の設定

Red Hat からミラーへのイメージのミラーリングを可能にするコンテナーイメージレジストリーの認証情報ファイルを作成します。

警告

クラスターのインストール時に、このイメージレジストリー認証情報ファイルをプルシークレットとして使用しないでください。クラスターのインストール時にこのファイルを指定すると、クラスター内のすべてのマシンにミラーレジストリーへの書き込みアクセスが付与されます。

警告

このプロセスでは、ミラーレジストリーのコンテナーイメージレジストリーへの書き込みアクセスがあり、認証情報をレジストリープルシークレットに追加する必要があります。

前提条件

  • 切断された環境で使用するミラーレジストリーを設定しました。
  • イメージをミラーリングするミラーレジストリー上のイメージリポジトリーの場所を特定している。
  • イメージのイメージリポジトリーへのアップロードを許可するミラーレジストリーアカウントをプロビジョニングしている。

手順

インストールホストで以下の手順を実行します。

  1. Red Hat OpenShift Cluster Manager サイトの Pull Secret ページから registry.redhat.io プルシークレットをダウンロードします。
  2. JSON 形式でプルシークレットのコピーを作成します。

    $ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json> 
    1
    1
    プルシークレットを保存するフォルダーへのパスおよび作成する JSON ファイルの名前を指定します。

    ファイルの内容は以下の例のようになります。

    {
      "auths": {
        "cloud.openshift.com": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "quay.io": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "registry.connect.redhat.com": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        },
        "registry.redhat.io": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        }
      }
    }
  3. ファイルを ~/.docker/config.json または $XDG_RUNTIME_DIR/containers/auth.json として保存します。
  4. ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードまたはトークンを生成します。

    $ echo -n '<user_name>:<password>' | base64 -w0 
    1
    
    BGVtbYk3ZHAtqXs=
    1
    <user_name> および <password> については、レジストリーに設定したユーザー名およびパスワードを指定します。
  5. JSON ファイルを編集し、レジストリーについて記述するセクションをこれに追加します。

      "auths": {
        "<mirror_registry>": { 
    1
    
          "auth": "<credentials>", 
    2
    
          "email": "you@example.com"
        }
      },
    1
    <mirror_registry> については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:8443
    2
    <credentials> については、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

    ファイルは以下の例のようになります。

    {
      "auths": {
        "registry.example.com": {
          "auth": "BGVtbYk3ZHAtqXs=",
          "email": "you@example.com"
        },
        "cloud.openshift.com": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "quay.io": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "registry.connect.redhat.com": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        },
        "registry.redhat.io": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        }
      }
    }

3.4.6. イメージセット設定の作成

oc-mirror プラグインを使用してイメージセットをミラーリングする前に、イメージセット設定ファイルを作成する必要があります。このイメージセット設定ファイルは、ミラーリングする OpenShift Container Platform リリース、Operator、およびその他のイメージと、oc-mirror プラグインの他の設定を定義します。

イメージセット設定ファイルでストレージバックエンドを指定する必要があります。このストレージバックエンドは、 Docker v2-2 をサポートするローカルディレクトリーまたはレジストリーにすることができます。oc-mirror プラグインは、イメージセットの作成中にこのストレージバックエンドにメタデータを保存します。

重要

oc-mirror プラグインによって生成されたメタデータを削除または変更しないでください。同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、同じストレージバックエンドを使用する必要があります。

前提条件

  • コンテナーイメージレジストリーの認証情報ファイルを作成している。手順については、イメージのミラーリングを可能にする認証情報の設定 を参照してください。

手順

  1. oc mirror init コマンドを使用して、イメージセット設定のテンプレートを作成し、それを imageset-config.yaml というファイルに保存します。

    $ oc mirror init --registry example.com/mirror/oc-mirror-metadata > imageset-config.yaml 
    1
    1
    example.com/mirror/oc-mirror-metadata をストレージバックエンドのレジストリーの場所に置き換えます。
  2. ファイルを編集し、必要に応じて設定を調整します。

    kind: ImageSetConfiguration
    apiVersion: mirror.openshift.io/v1alpha2
    archiveSize: 4                                                      
    1
    
    storageConfig:                                                      
    2
    
      registry:
        imageURL: example.com/mirror/oc-mirror-metadata                 
    3
    
        skipTLS: false
    mirror:
      platform:
        channels:
        - name: stable-4.11                                             
    4
    
          type: ocp
        graph: true                                                     
    5
    
      operators:
      - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.11  
    6
    
        packages:
        - name: serverless-operator                                     
    7
    
          channels:
          - name: stable                                                
    8
    
      additionalImages:
      - name: registry.redhat.io/ubi8/ubi:latest                        
    9
    
      helm: {}
    1
    archiveSize を追加して、イメージセット内の各ファイルの最大サイズを GiB 単位で設定します。
    2
    イメージセットのメタデータを保存するバックエンドの場所を設定します。この場所は、レジストリーまたはローカルディレクトリーにすることができます。storageConfig値を指定する必要があります。
    3
    ストレージバックエンドのレジストリー URL を設定します。
    4
    OpenShift Container Platform イメージを取得するためのチャネルを設定します。
    5
    graph: true を追加して、グラフデータイメージをビルドし、ミラーレジストリーにプッシュします。OpenShift Update Service (OSUS) を作成するには、graph-data イメージが必要です。graph: true フィールドは UpdateService カスタムリソースマニフェストも生成します。oc コマンドラインインターフェイス (CLI) は、UpdateService カスタムリソースマニフェストを使用して OSUS を作成できます。詳細については、OpenShift Update Service について を参照してください。
    6
    OpenShift Container Platform イメージを取得するための Operator カタログを設定します。
    7
    イメージセットに含める特定の Operator パッケージのみを指定します。カタログ内のすべてのパッケージを取得するには、このフィールドを削除してください。
    8
    イメージセットに含める Operator パッケージの特定のチャネルのみを指定します。そのチャネルでバンドルを使用しない場合も、常に Operator パッケージのデフォルトチャネルを含める必要があります。コマンド oc mirror list operators --catalog=<catalog_name> --package=<package_name> を実行すると、デフォルトチャネルを見つけることができます。
    9
    イメージセットに含める追加のイメージを指定します。

    パラメーターの完全なリストについては、イメージセットの設定パラメーター を参照してください。また、さまざまなミラーリングのユースケースについては、イメージセットの設定例 を参照してください。

  3. 更新したファイルを保存します。

    このイメージセット設定ファイルは、コンテンツをミラーリングするときに oc mirror コマンドで必要になります。

3.4.7. イメージセットをミラーレジストリーにミラーリングする

oc-mirror CLI プラグインを使用して、部分的な非接続環境 または 完全な非接続環境 でイメージをミラーレジストリーにミラーリングできます。

これらの手順は、ミラーレジストリーがすでに設定されていることを前提としています。

3.4.7.1. 部分的な非接続環境でのイメージセットのミラーリング

部分的な非接続環境では、イメージセットをターゲットミラーレジストリーに直接ミラーリングできます。

3.4.7.1.1. ミラーからミラーへのミラーリング

oc-mirror プラグインを使用して、イメージセットの作成中にアクセス可能なターゲットミラーレジストリーにイメージセットを直接ミラーリングできます。

イメージセット設定ファイルでストレージバックエンドを指定する必要があります。このストレージバックエンドは、ローカルディレクトリーまたは Dockerv2 レジストリーにすることができます。oc-mirror プラグインは、イメージセットの作成中にこのストレージバックエンドにメタデータを保存します。

重要

oc-mirror プラグインによって生成されたメタデータを削除または変更しないでください。同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、同じストレージバックエンドを使用する必要があります。

前提条件

  • 必要なコンテナーイメージを取得するためのインターネットへのアクセスがある。
  • OpenShift CLI (oc) がインストールされている。
  • oc-mirror CLI プラグインをインストールしている。
  • イメージセット設定ファイルを作成している。

手順

  • oc mirror コマンドを実行して、指定されたイメージセット設定から指定されたレジストリーにイメージをミラーリングします。

    $ oc mirror --config=./imageset-config.yaml \
    1
    
      docker://registry.example:5000             
    2
    1
    作成されたイメージセット設定ファイルを渡します。この手順では、imageset-config.yaml という名前であることを前提としています。
    2
    イメージセットファイルをミラーリングするレジストリーを指定します。レジストリーは docker:// で始まる必要があります。ミラーレジストリーに最上位の namespace を指定する場合は、これ以降の実行でもこれと同じ namespace を使用する必要があります。

検証

  1. 生成された oc-mirror-workspace/ ディレクトリーに移動します。
  2. results ディレクトリーに移動します (例: results-1639608409/
  3. ImageContentSourcePolicy および CatalogSource リソースに YAML ファイルが存在することを確認します。

次のステップ

  • oc-mirror が生成したリソースを使用するようにクラスターを設定します。

トラブルシューティング

3.4.7.2. 完全な非接続環境でのイメージセットのミラーリング

完全な非接続環境でイメージセットをミラーリングするには、最初に イメージセットをディスクにミラーリング してから、ディスク上のイメージセットファイルをミラーにミラーリング する必要があります。

3.4.7.2.1. ミラーからディスクへのミラーリング

oc-mirror プラグインを使用して、イメージセットを生成し、コンテンツをディスクに保存できます。生成されたイメージセットは、非接続環境に転送され、ターゲットレジストリーにミラーリングされます。

重要

イメージセット設定ファイルで指定されている設定によっては、oc-mirror を使用してイメージをミラーリングすると、数百ギガバイトのデータがディスクにダウンロードされる場合があります。

多くの場合、ミラーレジストリーにデータを入力するときの最初のイメージセットのダウンロードが、最も大きなものとなります。最後にコマンドを実行した後に変更されたイメージのみをダウンロードするため、oc-mirror プラグインを再度実行すると、生成されるイメージセットは小さいことが多いです。

イメージセット設定ファイルでストレージバックエンドを指定する必要があります。このストレージバックエンドは、ローカルディレクトリーまたは docker v2 レジストリーにすることができます。oc-mirror プラグインは、イメージセットの作成中にこのストレージバックエンドにメタデータを保存します。

重要

oc-mirror プラグインによって生成されたメタデータを削除または変更しないでください。同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、同じストレージバックエンドを使用する必要があります。

前提条件

  • 必要なコンテナーイメージを取得するためのインターネットへのアクセスがある。
  • OpenShift CLI (oc) がインストールされている。
  • oc-mirror CLI プラグインをインストールしている。
  • イメージセット設定ファイルを作成している。

手順

  • oc mirror コマンドを実行して、指定されたイメージセット設定からディスクにイメージをミラーリングします。

    $ oc mirror --config=./imageset-config.yaml \
    1
    
      file://<path_to_output_directory>          
    2
    1
    作成されたイメージセット設定ファイルを渡します。この手順では、imageset-config.yaml という名前であることを前提としています。
    2
    イメージセットファイルを出力するターゲットディレクトリーを指定します。ターゲットディレクトリーのパスは、file:// で始まる必要があります。

検証

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

    $ cd <path_to_output_directory>
  2. イメージセットの .tar ファイルが作成されたことを確認します。

    $ ls

    出力例

    mirror_seq1_000000.tar

次のステップ

  • イメージセットの.tar ファイルを非接続環境に転送します。

トラブルシューティング

3.4.7.2.2. ディスクからミラーへのミラーリング

oc-mirror プラグインを使用して、生成されたイメージセットの内容をターゲットミラーレジストリーにミラーリングできます。

前提条件

  • 非接続環境に OpenShift CLI (oc) をインストールしている。
  • 非接続環境に oc-mirror CLI プラグインをインストールしている。
  • ocmirror コマンドを使用してイメージセットファイルを生成している。
  • イメージセットファイルを非接続環境に転送しました。

手順

  • oc mirror コマンドを実行して、ディスク上のイメージセットファイルを処理し、その内容をターゲットミラーレジストリーにミラーリングします。

    $ oc mirror --from=./mirror_seq1_000000.tar \
    1
    
      docker://registry.example:5000             
    2
    1
    この例では、mirror_seq1_000000.tar という名前のイメージセット.tar ファイルをミラーに渡します。イメージセット設定ファイルで archiveSize 値が指定されている場合、イメージセットは複数の.tar ファイルに分割される可能性があります。この状況では、イメージセットの.tar ファイルを含むディレクトリーを渡すことができます。
    2
    イメージセットファイルをミラーリングするレジストリーを指定します。レジストリーは docker:// で始まる必要があります。ミラーレジストリーに最上位の namespace を指定する場合は、これ以降の実行でもこれと同じ namespace を使用する必要があります。

    このコマンドは、ミラーレジストリーをイメージセットで更新し、ImageContentSourcePolicy および CatalogSource リソースを生成します。

検証

  1. 生成された oc-mirror-workspace/ ディレクトリーに移動します。
  2. results ディレクトリーに移動します (例: results-1639608409/
  3. ImageContentSourcePolicy および CatalogSource リソースに YAML ファイルが存在することを確認します。

次のステップ

  • oc-mirror が生成したリソースを使用するようにクラスターを設定します。

トラブルシューティング

3.4.8. oc-mirror が生成したリソースを使用するためのクラスター設定

イメージセットをミラーレジストリーにミラーリングした後に、生成された ImageContentSourcePolicyCatalogSource、およびリリースイメージの署名リソースをクラスターに適用する必要があります。

ImageContentSourcePolicy リソースは、ミラーレジストリーをソースレジストリーに関連付け、イメージプル要求をオンラインレジストリーからミラーレジストリーにリダイレクトします。CatalogSource リソースは、Operator Lifecycle Manager (OLM) によって使用され、ミラーレジストリーで使用可能な Operator に関する情報を取得します。リリースイメージの署名は、ミラーリングされたリリースイメージの検証に使用されます。

前提条件

  • 非接続環境で、イメージセットをレジストリーミラーにミラーリングしました。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

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

    $ oc apply -f ./oc-mirror-workspace/results-1639608409/
  3. リリースイメージをミラーリングした場合は、次のコマンドを実行して、リリースイメージの署名をクラスターに適用します。

    $ oc apply -f ./oc-mirror-workspace/results-1639608409/release-signatures/
    注記

    クラスターではなく Operator をミラーリングしている場合、$ oc apply -f ./oc-mirror-workspace/results-1639608409/release-signatures/ を実行する必要はありません。適用するリリースイメージ署名がないため、このコマンドを実行するとエラーが返されます。

検証

  1. 以下のコマンドを実行して、ImageContentSourcePolicy リソースが正常にインストールされたことを確認します。

    $ oc get imagecontentsourcepolicy --all-namespaces
  2. 以下のコマンドを実行して、CatalogSource リソースが正常にインストールされたことを確認します。

    $ oc get catalogsource --all-namespaces

3.4.9. ミラーレジストリーのコンテンツを最新の状態に保つ

ターゲットミラーレジストリーに初期イメージセットが設定された後は、定期的に更新して、最新の内容になるようにしてください。可能であれば、必要に応じて cron ジョブを設定して、ミラーレジストリーが定期的に更新されるようにすることもできます。

イメージセットの設定を更新して、必要に応じて OpenShift Container Platform および Operator リリースを追加または削除してください。削除されるすべてのイメージは、ミラーレジストリーからプルーニングされます。

3.4.9.1. ミラーレジストリーコンテンツの更新について

oc-mirror プラグインを再度実行すると、前回の実行以降に新しく更新されたイメージのみを含むイメージセットが生成されます。前に作成されたイメージセットとの違いのみを取り込むため、生成されたイメージセットは、多くの場合、最初のイメージセットよりも小さく、迅速に処理されます。

重要

生成されたイメージセットはシーケンシャルであり、ターゲットミラーレジストリーに順番にプッシュする必要があります。シーケンス番号は、生成されたイメージセットアーカイブファイルのファイル名から取得できます。

新規イメージおよび更新されたイメージの追加

イメージセット設定の設定に応じて、oc-mirror を今後実行すると、追加の新しいイメージと更新されたイメージがミラーリングされます。イメージセット設定の設定を確認して、必要に応じて新しいバージョンを取得していることを確認します。たとえば、特定のバージョンに制限する場合は、Operator の最小バージョンと最大バージョンをミラーリングするように設定できます。または、最小バージョンをミラーリングの開始点として設定することもできますが、バージョン範囲は開いたままにして、oc-mirror の今後の実行時に新しい Operator バージョンを受け取り続けることができます。最小または最大バージョンを省略すると、チャネル内の Operator の完全なバージョン履歴が得られます。明示的に名前付けされたチャネルを省略すると、指定された Operator のすべてのチャネルのすべてのリリースが提供されます。名前付き Operator を省略すると、これまでにリリースされたすべての Operator とそのすべてのバージョンのカタログ全体が提供されます。

これらすべての制約と条件は、oc-mirror が呼び出されるたびに Red Hat によって公開されたコンテンツに対して評価されます。このようにして、新しいリリースとまったく新しい Operator を自動的にピックアップします。制約は、必要な Operator のセットをリストするだけで指定できます。これにより、新しくリリースされた他の Operator がミラーセットに自動的に追加されることはありません。特定のリリースチャネルを指定することもできます。これにより、ミラーリングは追加された新しいチャネルではなく、このチャネルのみに制限されます。これは、マイナーリリースに異なるリリースチャネルを使用する Red Hat Quay などの Operator 製品にとって重要です。最後に、特定の Operator の最大バージョンを指定できます。これにより、ツールは指定されたバージョン範囲のみをミラーリングするため、ミラーリングされた最大バージョンを超えた新しいリリースが自動的に取得されることはありません。これらのすべての場合において、イメージセット設定ファイルを更新して Operator のミラーリングの範囲を広げ、他の Operator、新しいチャネル、および Operator の新しいバージョンをターゲットレジストリーで使用できるようにする必要があります。

チャネル仕様やバージョン範囲などの制約を、特定の Operator が選択したリリースストラテジーに合わせることを推奨します。たとえば、Operator が stable チャネルを使用している場合、ミラーリングをそのチャネルと可能ならば最小バージョンに制限し、ダウンロード量と定期的な安定した更新の取得との間の適切なバランスを見つける必要があります。Operator がリリースバージョンのチャネルスキーム (stable-3.7 など) を選択した場合、そのチャネルのすべてのリリースをミラーリングする必要があります。これにより、Operator のパッチバージョン (3.7.1 など) を引き続き受け取ることができます。また、イメージセットの設定を定期的に調整して、新製品リリース (stable-3.8 など) 用のチャネルを追加することもできます。

イメージのプルーニング

イメージは、生成およびミラーリングされた最新のイメージセットに含まれなくなった場合、ターゲットミラーレジストリーから自動的にプルーニングされます。これにより、不要なコンテンツを簡単に管理およびクリーンアップし、ストレージリソースを解放することができます。

不要になった OpenShift Container Platform リリースまたは Operator バージョンがある場合、イメージセットの設定を変更してそれらを除外できます。これらはミラーリング時にミラーレジストリーからプルーニングされます。これは、イメージセット設定ファイルで Operator ごとに最小または最大バージョン範囲の設定を調整するか、カタログからミラーリングする Operator のリストから Operator を削除することによって実行できます。Operator カタログ全体または OpenShift Container Platform リリース全体を設定ファイルから削除することもできます。

重要

ミラーリングする新しいイメージまたは更新されたイメージがない場合、除外されたイメージはターゲットミラーレジストリーからプルーニングされません。さらに、Operator パブリッシャーがチャネルから Operator バージョンを削除すると、削除されたバージョンはターゲットミラーレジストリーからプルーニングされます。

3.4.9.2. ミラーレジストリーコンテンツの更新

初期イメージセットをミラーレジストリーに公開した後、oc-mirror プラグインを使用して、切断されたクラスターを最新の状態に保つことができます。

イメージセットの設定に応じて、oc-mirror は、初期ミラーリングの完了後にリリースされた OpenShift Container Platform および選択した Operator の新しいリリースを自動的に検出します。たとえば、毎晩の cron ジョブなどで、定期的に oc-mirror を実行し、製品とセキュリティーの更新をタイムリーに受信することを推奨します。

前提条件

  • oc-mirror プラグインを使用して、最初のイメージセットをミラーレジストリーにミラーリングしている。
  • oc-mirror プラグインの最初の実行に使用されたストレージバックエンドにアクセスできる。

    注記

    同じミラーレジストリーに対して oc-mirror の最初の実行と同じストレージバックエンドを使用する必要があります。oc-mirror プラグインによって生成されたメタデータイメージを削除または変更しないでください。

手順

  1. 必要に応じて、イメージセット設定ファイルを更新して、新しい OpenShift Container Platform および Operator バージョンを取得します。ミラーリングの使用例については、イメージセットの設定例 を参照してください。
  2. 初期イメージセットをミラーレジストリーにミラーリングしたときと同じ手順に従います。手順については、部分的な非接続環境でのイメージセットのミラーリング または 完全な非接続環境でのイメージセットのミラーリング を参照してください。

    重要
    • 差分イメージセットのみが作成およびミラーリングされるように、同じストレージバックエンドを提供する必要があります。
    • イメージセットの最初の作成時にミラーレジストリーにトップレベルの namespace を指定した場合は、同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、この同じ namespace を使用する必要があります。
  3. oc-mirror が生成したリソースを使用するようにクラスターを設定します。

3.4.10. ドライランの実行

実際にイメージをミラーリングせずに、oc-mirror を使用してドライランを実行できます。これにより、ミラーリングされるイメージのリストと、ミラーレジストリーからプルーニングされるイメージを確認できます。また、イメージセット設定のエラーを早期に検出したり、生成されたイメージのリストを他のツールで使用してミラーリング操作を実行したりすることもできます。

前提条件

  • 必要なコンテナーイメージを取得するためのインターネットへのアクセスがある。
  • OpenShift CLI (oc) がインストールされている。
  • oc-mirror CLI プラグインをインストールしている。
  • イメージセット設定ファイルを作成している。

手順

  1. --dry-run フラグを指定して oc mirror コマンドを実行し、ドライランを実行します。

    $ oc mirror --config=./imageset-config.yaml \
    1
    
      docker://registry.example:5000            \
    2
    
      --dry-run                                  
    3
    1
    作成されたイメージセット設定ファイルを渡します。この手順では、imageset-config.yaml という名前であることを前提としています。
    2
    ミラーレジストリーを指定します。--dry-run フラグを使用している限り、このレジストリーには何もミラーリングされません。
    3
    --dry-run フラグを使用して、実際のイメージセットファイルではなく、ドライランアーティファクトを生成します。

    出力例

    Checking push permissions for registry.example:5000
    Creating directory: oc-mirror-workspace/src/publish
    Creating directory: oc-mirror-workspace/src/v2
    Creating directory: oc-mirror-workspace/src/charts
    Creating directory: oc-mirror-workspace/src/release-signatures
    No metadata detected, creating new workspace
    wrote mirroring manifests to oc-mirror-workspace/operators.1658342351/manifests-redhat-operator-index
    
    ...
    
    info: Planning completed in 31.48s
    info: Dry run complete
    Writing image mapping to oc-mirror-workspace/mapping.txt

  2. 生成されたワークスペースディレクトリーに移動します。

    $ cd oc-mirror-workspace/
  3. 生成された mapping.txt ファイルを確認します。

    このファイルには、ミラーリングされるすべてのイメージのリストが含まれています。

  4. 生成された pruning-plan.json ファイルを確認します。

    このファイルには、イメージセットの公開時にミラーレジストリーからプルーニングされるすべてのイメージのリストが含まれています。

    注記

    pruning-plan.json ファイルは、oc-mirror コマンドがミラーレジストリーを指し、プルーニングするイメージがある場合にのみ生成されます。

3.4.11. Image set configuration parameters

oc-mirror プラグインには、ミラーリングするイメージを定義するイメージセット設定ファイルが必要です。次の表に、ImageSetConfiguration リソースで使用可能なパラメーターを示します。

Expand
表3.1 ImageSetConfiguration パラメーター
パラメーター説明

apiVersion

ImageSetConfiguration コンテンツの API バージョン。

文字列。例: mirror.openshift.io/v1alpha2

archiveSize

イメージセット内の各アーカイブファイルの最大サイズ (GiB 単位)。

integer例: 4

mirror

イメージセットの設定。

オブジェクト

mirror.additionalImages

イメージセットの追加のイメージ設定。

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

additionalImages:
  - name: registry.redhat.io/ubi8/ubi:latest

mirror.additionalImages.name

ミラーリングするイメージのタグまたはダイジェスト。

文字列。例: registry.redhat.io/ubi8/ubi:latest

mirror.blockedImages

ミラーリングからブロックするイメージの完全なタグ、ダイジェスト、またはパターン。

文字列の配列例: docker.io/library/alpine

mirror.helm

イメージセットのヘルム設定。oc-mirror プラグインは、レンダリング時にユーザー入力を必要としないヘルムチャートのみをサポートすることに注意してください。

オブジェクト

mirror.helm.local

ミラーリングするローカルヘルムチャート。

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

local:
  - name: podinfo
    path: /test/podinfo-5.0.0.tar.gz

mirror.helm.local.name

ミラーリングするローカルヘルムチャートの名前。

文字列。例: podinfo

mirror.helm.local.path

ミラーリングするローカルヘルムチャートのパス。

文字列。例: /test/podinfo-5.0.0.tar.gz

mirror.helm.repositories

ミラーリング元のリモートヘルムリポジトリー。

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

repositories:
  - name: podinfo
    url: https://example.github.io/podinfo
    charts:
      - name: podinfo
        version: 5.0.0

mirror.helm.repositories.name

ミラーリング元のヘルムリポジトリーの名前。

文字列。例: podinfo

mirror.helm.repositories.url

ミラーリング元の helm リポジトリーの URL。

文字列。例: https://example.github.io/podinfo

mirror.helm.repositories.charts

ミラーリングするリモートヘルムチャート。

オブジェクトの配列。

mirror.helm.repositories.charts.name

ミラーリングするヘルムチャートの名前。

文字列。例: podinfo

mirror.helm.repositories.charts.version

ミラーリングする名前付きヘルムチャートのバージョン。

文字列。例: 5.0.0

mirror.operators

イメージセットの Operators 設定。

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

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.11
    packages:
      - name: elasticsearch-operator
        minVersion: '2.4.0'

mirror.operators.catalog

イメージセットに含める Operator カタログ。

文字列。例: registry.redhat.io/redhat/redhat-operator-index:v4.11

mirror.operators.full

true の場合、完全なカタログ、Operator パッケージ、または Operator チャネルをダウンロードします。

ブール値。デフォルト値は false です。

mirror.operators.packages

Operator パッケージ設定

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

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.11
    packages:
      - name: elasticsearch-operator
        minVersion: '5.2.3-31'

mirror.operators.packages.name

イメージセットに含める Operator パッケージ名

文字列。例: elasticsearch-operator

mirror.operators.packages.channels

Operator パッケージのチャネル設定。

オブジェクト

mirror.operators.packages.channels.name

イメージセットに含める、パッケージ内で一意の Operator チャネル名。

文字列。例:fast または stable-v4.11

mirror.operators.packages.channels.maxVersion

Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。

文字列。例: 5.2.3-31

mirror.operators.packages.channels.minBundle

含める最小バンドルの名前と、チャネルヘッドへのアップグレードグラフ内のすべてのバンドル。名前付きバンドルにセマンティックバージョンメタデータがない場合にのみ、このフィールドを設定します。

文字列。例: bundleName

mirror.operators.packages.channels.minVersion

存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。

文字列。例: 5.2.3-31

mirror.operators.packages.maxVersion

Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。

文字列。例: 5.2.3-31

mirror.operators.packages.minVersion

存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。

文字列。例: 5.2.3-31

mirror.operators.skipDependencies

true の場合、バンドルの依存関係は含まれません。

ブール値。デフォルト値は false です。

mirror.operators.targetName

参照カタログをミラーリングするためのオプションの代替名。

文字列。例: my-operator-catalog

mirror.operators.targetTag

targetName に追加するオプションの代替タグ。

文字列。例: v1

mirror.platform

イメージセットのプラットフォーム設定。

オブジェクト

mirror.platform.architectures

ミラーリングするプラットフォームリリースペイロードのアーキテクチャー。

文字列の配列以下に例を示します。

architectures:
  - amd64
  - arm64

mirror.platform.channels

イメージセットのプラットフォームチャネル設定。

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

channels:
  - name: stable-4.10
  - name: stable-4.11

mirror.platform.channels.full

true の場合、minVersion をチャネルの最初のリリースに設定し、maxVersion をチャネルの最後のリリースに設定します。

ブール値。デフォルト値は false です。

mirror.platform.channels.name

リリースチャネルの名前。

文字列。例: stable-4.11

mirror.platform.channels.minVersion

ミラーリングされる参照プラットフォームの最小バージョン。

文字列。例: 4.9.6

mirror.platform.channels.maxVersion

ミラーリングされる参照プラットフォームの最上位バージョン。

文字列。例: 4.11.1

mirror.platform.channels.shortestPath

最短パスミラーリングまたはフルレンジミラーリングを切り替えます。

ブール値。デフォルト値は false です。

mirror.platform.channels.type

ミラーリングするプラットフォームのタイプ。

文字列。例: ocp または okd。デフォルトは ocp です。

mirror.platform.graph

OSUS グラフがイメージセットに追加され、その後ミラーに公開されるかどうかを示します。

ブール値。デフォルト値は false です。

storageConfig

イメージセットのバックエンド設定。

オブジェクト

storageConfig.local

イメージセットのローカルバックエンド設定。

オブジェクト

storageConfig.local.path

イメージセットのメタデータを含むディレクトリーのパス。

文字列。例: ./path/to/dir/

storageConfig.registry

イメージセットのレジストリーバックエンド設定。

オブジェクト

storageConfig.registry.imageURL

バックエンドレジストリー URI。オプションで、URI に namespace 参照を含めることができます。

文字列。例: quay.io/myuser/imageset:metadata

storageConfig.registry.skipTLS

オプションで、参照されるバックエンドレジストリーの TLS 検証をスキップします。

ブール値。デフォルト値は false です。

3.4.12. Image set configuration examples

次の ImageSetConfiguration ファイルの例は、さまざまなミラーリングのユースケースの設定を示しています。

ユースケース: 任意のイメージとヘルムチャートを含む

次の ImageSetConfiguration ファイルは、レジストリーストレージバックエンドを使用し、これにはヘルムチャートと追加の Red Hat Universal Base Image (UBI) が含まれています。

ImageSetConfigurationファイルの例

apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
archiveSize: 4
storageConfig:
 registry:
   imageURL: example.com/mirror/oc-mirror-metadata
   skipTLS: false
mirror:
 platform:
   architectures:
     - "s390x"
   channels:
     - name: stable-4.11
 operators:
   - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.11
 helm:
   repositories:
     - name: redhat-helm-charts
       url: https://raw.githubusercontent.com/redhat-developer/redhat-helm-charts/master
       charts:
         - name: ibm-mongodb-enterprise-helm
           version: 0.2.0
 additionalImages:
   - name: registry.redhat.io/ubi8/ubi:latest

ユースケース: 最小から最新までの Operator バージョンを含める

次のImageSetConfigurationファイルは、ローカルストレージバックエンドを使用し、これには、latest チャネルの Kubernetes Operator 用の Red Hat Advanced Cluster Security (3.68.0 以降のバージョン) のみが含まれています。

ImageSetConfigurationファイルの例

apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
  local:
    path: /home/user/metadata
mirror:
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.11
      packages:
        - name: rhacs-operator
          channels:
          - name: latest
            minVersion: 3.68.0

ユースケース: 最短の OpenShift Container Platform アップグレードパスを含める

以下の ImageSetConfiguration ファイルは、ローカルストレージバックエンドを使用し、最小バージョン 4.9.37 から最大バージョン 4.10.22 への最短アップグレードパスに沿ってすべての OpenShift Container Platform バージョンを含めます。

ImageSetConfigurationファイルの例

apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
  local:
    path: /home/user/metadata
mirror:
  platform:
    channels:
      - name: stable-4.10
        minVersion: 4.9.37
        maxVersion: 4.10.22
        shortestPath: true

ユースケース: OpenShift Container Platform の最小バージョンから最新バージョンまでのすべてのバージョンを含める

以下の ImageSetConfiguration ファイルは、レジストリーストレージバックエンドを使用し、最小バージョン 4.10.10 からチャネルの最新バージョンまでのすべての OpenShift Container Platform バージョンを含みます。

このイメージセット設定で oc-mirror を呼び出すたびに、stable-4.10 チャネルの最新リリースが評価されるため、定期的に oc-mirror を実行すると、OpenShift Container Platform イメージの最新リリースを自動的に受け取ることができます。

ImageSetConfigurationファイルの例

apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
 registry:
   imageURL: example.com/mirror/oc-mirror-metadata
   skipTLS: false
mirror:
  platform:
    channels:
      - name: stable-4.10
        minVersion: 4.10.10

ユースケース: 最小から最大までの Operator バージョンを含める

次の ImageSetConfiguration ファイルは、ローカルストレージバックエンドを使用し、stable チャネルの 1.0.0 から 2.0.0 までのバージョンの Operator の例のみを含みます。

これにより、特定の Operator の特定のバージョン範囲のみをミラーリングできます。時間の経過とともに、バージョン 1.0.0 がもうどこにも動作していない場合などに、これらの設定を使用して新しいリリースにバージョンを合わせることができます。このシナリオでは、minVersion1.5.0 などの新しいバージョンに上げることができます。更新されたバージョン範囲で oc-mirror が再度実行されると、1.5.0 より古いリリースが不要になったことを自動的に検出し、それらをレジストリーから削除してストレージスペースを節約します。

ImageSetConfigurationファイルの例

apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
  local:
    path: /home/user/metadata
mirror:
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.11
      packages:
        - name: example-operator
          channels:
            - name: stable
              minVersion: '1.0.0'
              maxVersion: '2.0.0'

3.4.13. oc-mirror のコマンドリファレンス

以下の表は、oc mirror サブコマンドとフラグについて説明しています。

Expand
表3.2 oc mirror サブコマンド
サブコマンド説明

completion

指定されたシェルのオートコンプリートスクリプトを生成します。

describe

イメージセットの内容を出力します。

help

サブコマンドに関するヘルプを表示します。

init

初期イメージセット設定テンプレートを出力します。

list

利用可能なプラットフォームと Operator のコンテンツとそのバージョンを一覧表示します。

version

oc-mirror バージョンを出力します。

Expand
表3.3 oc mirror フラグ
フラグ説明

-c, --config <string>

イメージセット設定ファイルへのパスを指定します。

--continue-on-error

イメージのプルに関連しないエラーが発生した場合は、続行して、可能な限りミラーリングを試みます。

--dest-skip-tls

ターゲットレジストリーの TLS 検証を無効にします。

--dest-use-http

ターゲットレジストリーにはプレーン HTTP を使用します。

--dry-run

イメージをミラーリングせずにアクションを出力します。mapping.txt ファイルおよび pruning-plan.json ファイルを生成します。

--from <string>

oc-mirror の実行によって生成されたイメージセットアーカイブへのパスを指定して、ターゲットレジストリーにロードします。

-h--help

ヘルプを表示します。

--ignore-history

イメージをダウンロードしてレイヤーをパックするときに、過去のミラーリングを無視します。増分ミラーリングを無効にし、より多くのデータをダウンロードする可能性があります。

--manifests-only

ImageContentSourcePolicy オブジェクトのマニフェストを生成して、ミラーレジストリーを使用するようにクラスターを設定しますが、実際にはイメージをミラーリングしません。このフラグを使用するには、--from フラグでイメージセットアーカイブを渡す必要があります。

--max-per-registry <int>

レジストリーごとに許可される同時要求の数を指定します。デフォルト値は 6 です。

--skip-cleanup

アーティファクトディレクトリーの削除を省略します。

--skip-image-pin

Operator カタログのイメージタグをダイジェストピンに置き換えないでください。

--skip-metadata-check

イメージセットの公開時にメタデータをスキップします。これは、イメージセットが --ignore-history で作成された場合にのみ推奨されます。

--skip-missing

イメージが見つからない場合は、エラーを報告して実行を中止する代わりにスキップします。イメージセット設定で明示的に指定されたカスタムイメージには適用されません。

--skip-verification

ダイジェストの検証を省略します。

--source-skip-tls

ソースレジストリーの TLS 検証を無効にします。

--source-use-http

ソースレジストリーにはプレーン HTTP を使用します。

-v, --verbose <int>

ログレベルの詳細度の数値を指定します。有効な値は 0 - 9 です。デフォルトは 0 です。

第4章 Alibaba へのインストール

4.1. Alibaba Cloud へのインストールの準備

重要

OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

4.1.1. 前提条件

4.1.2. OpenShift Container Platform を Alibaba Cloud にインストールするための要件

OpenShift Container Platform を Alibaba Cloud にインストールする前に、ドメインを設定および登録し、インストール用の Resource Access Management (RAM) ユーザーを作成し、インストール用にサポートされている Alibaba Cloud データセンターのリージョンとゾーンを確認する必要があります。

4.1.3. Alibaba Cloud ドメインの登録と設定

OpenShift Container Platform をインストールするには、使用する Alibaba Cloud アカウントに専用のパブリックホストゾーンが必要です。このゾーンはドメインに対する権威を持っている必要があります。このサービスは、クラスターへの外部接続のためのクラスター DNS 解決および名前検索を提供します。

手順

  1. ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインとレジストラーを移行するか、Alibaba Cloud または別のソースから新しいドメインを取得することができます。

    注記

    Alibaba Cloud を介して新しいドメインを購入した場合、関連する DNS の変更が反映されるまでに時間がかかります。Alibaba Cloud を介したドメインの購入の詳細については、Alibaba Cloud ドメイン を参照してください。

  2. 既存のドメインとレジストラーを使用している場合は、その DNS を Alibaba Cloud に移行します。Alibaba Cloud のドキュメントの Domain name transfer を参照してください。
  3. ドメインの DNS を設定します。これには以下が含まれます。

  4. サブドメインを使用している場合は、会社の手順に従って、その委任レコードを親ドメインに追加します。

4.1.4. サポートされている Alibaba リージョン

OpenShift Container Platform クラスターを Alibaba のリージョンとゾーンのドキュメント にリストされているリージョンにデプロイできます。

4.1.5. 次のステップ

4.2. 必要な Alibaba Cloud リソースの作成

OpenShift Container Platform をインストールする前に、Alibaba Cloud コンソールを使用して、OpenShift Container Platform を Alibaba Cloud にインストールするための十分な権限を持つ Resource Access Management (RAM) ユーザーを作成する必要があります。このユーザーには、新しい RAM ユーザーを作成するための権限も必要です。ccoctl ツールを設定および使用して、OpenShift Container Platform コンポーネントに必要な権限を持つ新しいクレデンシャルを作成することもできます。

重要

OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

4.2.1. 必要な RAM ユーザーの作成

インストールには、十分な権限を持つ Alibaba Cloud Resource Access Management (RAM) ユーザーが必要です。Alibaba Cloud Resource Access Management コンソールを使用して、新しいユーザーを作成したり、既存のユーザーを変更したりできます。後で、このユーザーの権限に基づいて、OpenShift Container Platform でクレデンシャルを作成します。

RAM ユーザーを設定するときは、次の要件を必ず考慮してください。

  • ユーザーは、Alibaba Cloud AccessKey ID と AccessKey シークレットのペアを持っている必要があります。

    • 新規ユーザーの場合、ユーザーの作成時に Access Mode に Open API Access を選択できます。このモードでは、必要な AccessKey ペアが生成されます。
    • 既存のユーザーの場合は、AccessKey ペアを追加するか、そのユーザーの AccessKey のペアを取得 できます。

      注記

      作成されると、AccessKey シークレットは 1 回だけ表示されます。API 呼び出しには AccessKey ペアが必要であるため、AccessKey ペアをすぐに保存する必要があります。

  • AccessKey ID とシークレットをローカルコンピューターの ~/.alibabacloud/credentials ファイル に追加します。コンソールにログインすると、Alibaba Cloud によってこのファイルが自動的に作成されます。Cloud Credential Operator (CCO) ユーティリティー (ccoutil) は、Credential Request オブジェクトを処理するときにこれらの認証情報を使用します。

    以下に例を示します。

    [default]                          # Default client
    type = access_key                  # Certification type: access_key
    access_key_id = LTAI5t8cefXKmt                # Key 
    1
    
    access_key_secret = wYx56mszAN4Uunfh            # Secret
    1
    ここに AccessKeyID と AccessKeySecret を追加します。
  • RAM ユーザーは、アカウントが OpenShift Container Platform クラスターを作成するための十分なパーミッションを持っていることを確認するために AdministratorAccess ポリシーを持っている必要があります。このポリシーは、すべての Alibaba Cloud リソースを管理するための権限を付与します。

    AdministratorAccess ポリシーを RAM ユーザーにアタッチすると、そのユーザーにすべての Alibaba Cloud サービスとリソースへのフルアクセスが許可されます。フルアクセス権を持つユーザーを作成したくない場合は、インストールのために RAM ユーザーに追加できる次のアクションを使用してカスタムポリシーを作成します。これらのアクションは、OpenShift Container Platform をインストールするのに十分です。

    ヒント

    次の JSON コードをコピーして Alibaba Cloud コンソールに貼り付け、カスタムポリシーを作成できます。カスタムポリシー作成の詳細については、Alibaba Cloud のドキュメントの Create a custom policy を参照してください。

    例4.1 カスタムポリシー JSON ファイルの例

    {
      "Version": "1",
      "Statement": [
        {
          "Action": [
            "tag:ListTagResources",
            "tag:UntagResources"
          ],
          "Resource": "*",
          "Effect": "Allow"
        },
        {
          "Action": [
            "vpc:DescribeVpcs",
            "vpc:DeleteVpc",
            "vpc:DescribeVSwitches",
            "vpc:DeleteVSwitch",
            "vpc:DescribeEipAddresses",
            "vpc:DescribeNatGateways",
            "vpc:ReleaseEipAddress",
            "vpc:DeleteNatGateway",
            "vpc:DescribeSnatTableEntries",
            "vpc:CreateSnatEntry",
            "vpc:AssociateEipAddress",
            "vpc:ListTagResources",
            "vpc:TagResources",
            "vpc:DescribeVSwitchAttributes",
            "vpc:CreateVSwitch",
            "vpc:CreateNatGateway",
            "vpc:DescribeRouteTableList",
            "vpc:CreateVpc",
            "vpc:AllocateEipAddress",
            "vpc:ListEnhanhcedNatGatewayAvailableZones"
          ],
          "Resource": "*",
          "Effect": "Allow"
        },
        {
          "Action": [
            "ecs:ModifyInstanceAttribute",
            "ecs:DescribeSecurityGroups",
            "ecs:DeleteSecurityGroup",
            "ecs:DescribeSecurityGroupReferences",
            "ecs:DescribeSecurityGroupAttribute",
            "ecs:RevokeSecurityGroup",
            "ecs:DescribeInstances",
            "ecs:DeleteInstances",
            "ecs:DescribeNetworkInterfaces",
            "ecs:DescribeInstanceRamRole",
            "ecs:DescribeUserData",
            "ecs:DescribeDisks",
            "ecs:ListTagResources",
            "ecs:AuthorizeSecurityGroup",
            "ecs:RunInstances",
            "ecs:TagResources",
            "ecs:ModifySecurityGroupPolicy",
            "ecs:CreateSecurityGroup",
            "ecs:DescribeAvailableResource",
            "ecs:DescribeRegions",
            "ecs:AttachInstanceRamRole"
          ],
          "Resource": "*",
          "Effect": "Allow"
        },
        {
          "Action": [
            "pvtz:DescribeRegions",
            "pvtz:DescribeZones",
            "pvtz:DeleteZone",
            "pvtz:DeleteZoneRecord",
            "pvtz:BindZoneVpc",
            "pvtz:DescribeZoneRecords",
            "pvtz:AddZoneRecord",
            "pvtz:SetZoneRecordStatus",
            "pvtz:DescribeZoneInfo",
            "pvtz:DescribeSyncEcsHostTask",
            "pvtz:AddZone"
          ],
          "Resource": "*",
          "Effect": "Allow"
        },
        {
          "Action": [
            "slb:DescribeLoadBalancers",
            "slb:SetLoadBalancerDeleteProtection",
            "slb:DeleteLoadBalancer",
            "slb:SetLoadBalancerModificationProtection",
            "slb:DescribeLoadBalancerAttribute",
            "slb:AddBackendServers",
            "slb:DescribeLoadBalancerTCPListenerAttribute",
            "slb:SetLoadBalancerTCPListenerAttribute",
            "slb:StartLoadBalancerListener",
            "slb:CreateLoadBalancerTCPListener",
            "slb:ListTagResources",
            "slb:TagResources",
            "slb:CreateLoadBalancer"
          ],
          "Resource": "*",
          "Effect": "Allow"
        },
        {
          "Action": [
            "ram:ListResourceGroups",
            "ram:DeleteResourceGroup",
            "ram:ListPolicyAttachments",
            "ram:DetachPolicy",
            "ram:GetResourceGroup",
            "ram:CreateResourceGroup",
            "ram:DeleteRole",
            "ram:GetPolicy",
            "ram:DeletePolicy",
            "ram:ListPoliciesForRole",
            "ram:CreateRole",
            "ram:AttachPolicyToRole",
            "ram:GetRole",
            "ram:CreatePolicy",
            "ram:CreateUser",
            "ram:DetachPolicyFromRole",
            "ram:CreatePolicyVersion",
            "ram:DetachPolicyFromUser",
            "ram:ListPoliciesForUser",
            "ram:AttachPolicyToUser",
            "ram:CreateUser",
            "ram:GetUser",
            "ram:DeleteUser",
            "ram:CreateAccessKey",
            "ram:ListAccessKeys",
            "ram:DeleteAccessKey",
            "ram:ListUsers",
            "ram:ListPolicyVersions"
          ],
          "Resource": "*",
          "Effect": "Allow"
        },
        {
          "Action": [
            "oss:DeleteBucket",
            "oss:DeleteBucketTagging",
            "oss:GetBucketTagging",
            "oss:GetBucketCors",
            "oss:GetBucketPolicy",
            "oss:GetBucketLifecycle",
            "oss:GetBucketReferer",
            "oss:GetBucketTransferAcceleration",
            "oss:GetBucketLog",
            "oss:GetBucketWebSite",
            "oss:GetBucketInfo",
            "oss:PutBucketTagging",
            "oss:PutBucket",
            "oss:OpenOssService",
            "oss:ListBuckets",
            "oss:GetService",
            "oss:PutBucketACL",
            "oss:GetBucketLogging",
            "oss:ListObjects",
            "oss:GetObject",
            "oss:PutObject",
            "oss:DeleteObject"
          ],
          "Resource": "*",
          "Effect": "Allow"
        },
        {
          "Action": [
            "alidns:DescribeDomainRecords",
            "alidns:DeleteDomainRecord",
            "alidns:DescribeDomains",
            "alidns:DescribeDomainRecordInfo",
            "alidns:AddDomainRecord",
            "alidns:SetDomainRecordStatus"
          ],
          "Resource": "*",
          "Effect": "Allow"
        },
        {
          "Action": "bssapi:CreateInstance",
          "Resource": "*",
          "Effect": "Allow"
        },
        {
          "Action": "ram:PassRole",
          "Resource": "*",
          "Effect": "Allow",
          "Condition": {
            "StringEquals": {
              "acs:Service": "ecs.aliyuncs.com"
            }
          }
        }
      ]
    }

RAM ユーザーの作成と権限の付与の詳細については、Alibaba Cloud のドキュメントの Create a RAM user および Grant permissions to a RAM user を参照してください。

4.2.2. Cloud Credential Operator ユーティリティーの設定

クラスター内コンポーネントごとに長寿命の RAM AccessKeys (AKs) を提供する RAM ユーザーとポリシーを割り当てるには、Cloud Credential Operator (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 を使用する準備ができていることを確認するには、次のコマンドを実行してヘルプファイルを表示します。

    $ ccoctl --help

    ccoctl --help の出力

    OpenShift credentials provisioning tool
    
    Usage:
      ccoctl [command]
    
    Available Commands:
      alibabacloud Manage credentials objects for alibaba cloud
      aws          Manage credentials objects for AWS cloud
      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.

4.2.3. 次のステップ

4.3. クラスターを Alibaba Cloud にすばやくインストールする

OpenShift Container Platform バージョン 4.11 では、デフォルトの設定オプションを使用するクラスターを Alibaba Cloud にインストールできます。

重要

OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

4.3.1. 前提条件

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

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

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

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

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

4.3.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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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.3.4. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

Alibaba Cloud にインストールする 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 からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

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

        注記

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

      2. ターゲットとするプラットフォームとして alibabacloud を選択します。
      3. クラスターをデプロイするリージョンを選択します。
      4. クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
      5. クラスターの記述名を指定します。
      6. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. クラスターを Alibaba Cloud にインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。install-config.yaml ファイルを変更して、credentialsMode パラメーターを Manual に設定します。

    credentialsModeManual に設定された install-config.yaml 設定ファイルの例

    apiVersion: v1
    baseDomain: cluster1.example.com
    credentialsMode: Manual 
    1
    
    compute:
    - architecture: amd64
      hyperthreading: Enabled
     ...

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

    重要

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

4.3.6. 必要なインストールマニフェストの生成

クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

手順

  1. インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。

    $ openshift-install create manifests --dir <installation_directory>

    ここで、

    <installation_directory>
    インストールプログラムがファイルを作成するディレクトリーを指定します。

4.3.7. ccoctl ツールを使用した OpenShift Container Platform コンポーネントのクレデンシャルの作成

OpenShift Container Platform Cloud Credential Operator (CCO) ユーティリティーを使用して、Alibaba Cloud RAM ユーザーとクラスター内コンポーネントごとのポリシーの作成を自動化できます。

注記

デフォルトで、ccoctl はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir フラグを使用します。この手順では、<path_to_ccoctl_output_dir> を使用してこの場所を参照します。

前提条件

以下が必要になります。

  • ccoctl バイナリーを抽出して準備している。
  • OpenShift Container Platform クラスターを作成するための十分な権限を持つ RAM ユーザーを作成している。
  • その RAM ユーザーの AccessKeyID (access_key_id) と AccessKeySecret (access_key_secret) をローカルコンピューターの ~/.alibabacloud/credentials ファイル に追加しました。

手順

  1. 以下のコマンドを実行して、$RELEASE_IMAGE 変数を設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    $ oc adm release extract \
    --credentials-requests \
    --cloud=alibabacloud \
    --to=<path_to_directory_with_list_of_credentials_requests>/credrequests \ 
    1
    
    $RELEASE_IMAGE
    1
    credrequests は、CredentialsRequest オブジェクトのリストが格納されるディレクトリーです。ディレクトリーが存在しない場合、このコマンドはディレクトリーを作成します。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. クラスターでクラスター機能を使用して 1 つ以上のオプションコンポーネントを無効にする場合は、無効なコンポーネントの CredentialsRequest カスタムリソースを削除します。

    Alibaba Cloud 上の OpenShift Container Platform 4.12 の credrequests ディレクトリーの内容の例

    0000_30_machine-api-operator_00_credentials-request.yaml 
    1
    
    0000_50_cluster-image-registry-operator_01-registry-credentials-request-alibaba.yaml 
    2
    
    0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 
    3
    
    0000_50_cluster-storage-operator_03_credentials_request_alibaba.yaml 
    4

    1
    Machine API Operator CR が必要です。
    2
    Image Registry Operator CR が必要です。
    3
    Ingress Operator CR が必要です。
    4
    Storage Operator CR はオプションのコンポーネントであり、クラスターで無効になっている場合があります。
  4. ccoctl ツールを使用して、credrequests ディレクトリーですべての CredentialsRequest オブジェクトを処理します。

    1. ツールを使用するには、次のコマンドを実行します。

      $ ccoctl alibabacloud create-ram-users \
      --name <name> \
      --region=<alibaba_region> \
      --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests \
      --output-dir=<path_to_ccoctl_output_dir>

      ここで、

      • <name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
      • <alibaba_region> は、クラウドリソースが作成される Alibaba Cloud リージョンです。
      • <path_to_directory_with_list_of_credentials_requests>/credrequests は、コンポーネント CredentialsRequest オブジェクトのファイルを含むディレクトリーです。
      • <path_to_ccoctl_output_dir> は、生成されたコンポーネントクレデンシャルシークレットが配置されるディレクトリーです。
      注記

      クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

      出力例

      2022/02/11 16:18:26 Created RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials
      2022/02/11 16:18:27 Ready for creating new ram policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy
      2022/02/11 16:18:27 RAM policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has created
      2022/02/11 16:18:28 Policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has attached on user user1-alicloud-openshift-machine-api-alibabacloud-credentials
      2022/02/11 16:18:29 Created access keys for RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials
      2022/02/11 16:18:29 Saved credentials configuration to: user1-alicloud/manifests/openshift-machine-api-alibabacloud-credentials-credentials.yaml
      ...

      注記

      RAM ユーザーは、同時に最大 2 つの AccessKey を持つことができます。ccoctl alibabacloud create-ram-users を 3 回以上実行すると、以前に生成されたマニフェストシークレットが古くなり、新しく生成されたシークレットを再適用する必要があります。

    2. OpenShift Container Platform シークレットが作成されていることを確認します。

      $ ls <path_to_ccoctl_output_dir>/manifests

      出力例:

      openshift-cluster-csi-drivers-alibaba-disk-credentials-credentials.yaml
      openshift-image-registry-installer-cloud-credentials-credentials.yaml
      openshift-ingress-operator-cloud-credentials-credentials.yaml
      openshift-machine-api-alibabacloud-credentials-credentials.yaml

      RAM ユーザーとポリシーが Alibaba Cloud にクエリーを実行して作成されていることを確認できます。詳細については、RAM ユーザーとポリシーのリスト表示に関する Alibaba Cloud のドキュメントを参照してください。

  5. 生成されたクレデンシャルファイルをターゲットマニフェストディレクトリーにコピーします。

    $ cp ./<path_to_ccoctl_output_dir>/manifests/*credentials.yaml ./<path_to_installation>dir>/manifests/

    ここで、

    <path_to_ccoctl_output_dir>
    ccoctl alibabacloud create-ram-users コマンドによって作成されるディレクトリーを指定します。
    <path_to_installation_dir>
    インストールプログラムがファイルを作成するディレクトリーを指定します。

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

互換性のあるクラウドプラットフォームに 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.3.9. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

4.3.11. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

4.3.12. OpenShift Container Platform の Telemetry アクセス

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

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

4.3.13. 次のステップ

4.4. カスタマイズによる Alibaba Cloud へのクラスターのインストール

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

注記

OpenShift Container Platform インストール設定のスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後にさらに多くの OpenShift Container Platform 設定タスクを実行することができます。

重要

OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

4.4.1. 前提条件

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

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

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

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

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

4.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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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.4. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
4.4.4.1. インストール設定ファイルの作成

Alibaba Cloud にインストールする 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 からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

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

        注記

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

      2. ターゲットとするプラットフォームとして alibabacloud を選択します。
      3. クラスターをデプロイするリージョンを選択します。
      4. クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
      5. クラスターの記述名を指定します。
      6. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. クラスターを Alibaba Cloud にインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。install-config.yaml ファイルを変更して、credentialsMode パラメーターを Manual に設定します。

    credentialsModeManual に設定された install-config.yaml 設定ファイルの例

    apiVersion: v1
    baseDomain: cluster1.example.com
    credentialsMode: Manual 
    1
    
    compute:
    - architecture: amd64
      hyperthreading: Enabled
     ...

    1
    この行を追加して、 credentialsModeManual に設定します。
  3. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、インストール設定パラメーターのセクションを参照してください。
  4. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

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

4.4.4.2. 必要なインストールマニフェストの生成

クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

手順

  1. インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。

    $ openshift-install create manifests --dir <installation_directory>

    ここで、

    <installation_directory>
    インストールプログラムがファイルを作成するディレクトリーを指定します。

OpenShift Container Platform Cloud Credential Operator (CCO) ユーティリティーを使用して、Alibaba Cloud RAM ユーザーとクラスター内コンポーネントごとのポリシーの作成を自動化できます。

注記

デフォルトで、ccoctl はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir フラグを使用します。この手順では、<path_to_ccoctl_output_dir> を使用してこの場所を参照します。

前提条件

以下が必要になります。

  • ccoctl バイナリーを抽出して準備している。
  • OpenShift Container Platform クラスターを作成するための十分な権限を持つ RAM ユーザーを作成している。
  • その RAM ユーザーの AccessKeyID (access_key_id) と AccessKeySecret (access_key_secret) をローカルコンピューターの ~/.alibabacloud/credentials ファイル に追加しました。

手順

  1. 以下のコマンドを実行して、$RELEASE_IMAGE 変数を設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    $ oc adm release extract \
    --credentials-requests \
    --cloud=alibabacloud \
    --to=<path_to_directory_with_list_of_credentials_requests>/credrequests \ 
    1
    
    $RELEASE_IMAGE
    1
    credrequests は、CredentialsRequest オブジェクトのリストが格納されるディレクトリーです。ディレクトリーが存在しない場合、このコマンドはディレクトリーを作成します。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. クラスターでクラスター機能を使用して 1 つ以上のオプションコンポーネントを無効にする場合は、無効なコンポーネントの CredentialsRequest カスタムリソースを削除します。

    Alibaba Cloud 上の OpenShift Container Platform 4.12 の credrequests ディレクトリーの内容の例

    0000_30_machine-api-operator_00_credentials-request.yaml 
    1
    
    0000_50_cluster-image-registry-operator_01-registry-credentials-request-alibaba.yaml 
    2
    
    0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 
    3
    
    0000_50_cluster-storage-operator_03_credentials_request_alibaba.yaml 
    4

    1
    Machine API Operator CR が必要です。
    2
    Image Registry Operator CR が必要です。
    3
    Ingress Operator CR が必要です。
    4
    Storage Operator CR はオプションのコンポーネントであり、クラスターで無効になっている場合があります。
  4. ccoctl ツールを使用して、credrequests ディレクトリーですべての CredentialsRequest オブジェクトを処理します。

    1. ツールを使用するには、次のコマンドを実行します。

      $ ccoctl alibabacloud create-ram-users \
      --name <name> \
      --region=<alibaba_region> \
      --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests \
      --output-dir=<path_to_ccoctl_output_dir>

      ここで、

      • <name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
      • <alibaba_region> は、クラウドリソースが作成される Alibaba Cloud リージョンです。
      • <path_to_directory_with_list_of_credentials_requests>/credrequests は、コンポーネント CredentialsRequest オブジェクトのファイルを含むディレクトリーです。
      • <path_to_ccoctl_output_dir> は、生成されたコンポーネントクレデンシャルシークレットが配置されるディレクトリーです。
      注記

      クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

      出力例

      2022/02/11 16:18:26 Created RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials
      2022/02/11 16:18:27 Ready for creating new ram policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy
      2022/02/11 16:18:27 RAM policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has created
      2022/02/11 16:18:28 Policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has attached on user user1-alicloud-openshift-machine-api-alibabacloud-credentials
      2022/02/11 16:18:29 Created access keys for RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials
      2022/02/11 16:18:29 Saved credentials configuration to: user1-alicloud/manifests/openshift-machine-api-alibabacloud-credentials-credentials.yaml
      ...

      注記

      RAM ユーザーは、同時に最大 2 つの AccessKey を持つことができます。ccoctl alibabacloud create-ram-users を 3 回以上実行すると、以前に生成されたマニフェストシークレットが古くなり、新しく生成されたシークレットを再適用する必要があります。

    2. OpenShift Container Platform シークレットが作成されていることを確認します。

      $ ls <path_to_ccoctl_output_dir>/manifests

      出力例:

      openshift-cluster-csi-drivers-alibaba-disk-credentials-credentials.yaml
      openshift-image-registry-installer-cloud-credentials-credentials.yaml
      openshift-ingress-operator-cloud-credentials-credentials.yaml
      openshift-machine-api-alibabacloud-credentials-credentials.yaml

      RAM ユーザーとポリシーが Alibaba Cloud にクエリーを実行して作成されていることを確認できます。詳細については、RAM ユーザーとポリシーのリスト表示に関する Alibaba Cloud のドキュメントを参照してください。

  5. 生成されたクレデンシャルファイルをターゲットマニフェストディレクトリーにコピーします。

    $ cp ./<path_to_ccoctl_output_dir>/manifests/*credentials.yaml ./<path_to_installation>dir>/manifests/

    ここで、

    <path_to_ccoctl_output_dir>
    ccoctl alibabacloud create-ram-users コマンドによって作成されるディレクトリーを指定します。
    <path_to_installation_dir>
    インストールプログラムがファイルを作成するディレクトリーを指定します。
4.4.4.4. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

4.4.4.4.1. 必須設定パラメーター

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

Expand
表4.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

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}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"
      }
   }
}
4.4.4.4.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

Expand
表4.2 ネットワークパラメーター
パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

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 です。

OpenShift SDN および 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 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

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

例: 10.0.0.0/16

注記

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

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

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

Expand
表4.3 オプションのパラメーター
パラメーター説明

additionalTrustBundle

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

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

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

MachinePool オブジェクトの配列。

compute.architecture

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

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。

controlPlane.architecture

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

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

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

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

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

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

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

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 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

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

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

imageContentSources.source

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

文字列

imageContentSources.mirrors

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

文字列の配列。

publish

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

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

このフィールドを Internal に設定することは、クラウド以外のプラットフォームおよび IBM Cloud ではサポートされていません。

重要

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

sshKey

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

注記

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

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

4.4.4.4.4. 追加の Alibaba Cloud 設定パラメーター

Alibaba Cloud の追加の設定パラメーターは、以下の表で説明されています。alibabacloud パラメーターは、Alibaba Cloud にインストールするときに使用される設定です。defaultMachinePlatform パラメーターは、独自のプラットフォーム設定を定義しないマシンプール用に Alibaba Cloud にインストールするときに使用されるデフォルト設定です。

これらのパラメーターは、指定されているコンピュートマシンとコントロールプレーンマシンの両方に適用されます。

注記

定義されている場合、パラメーターcompute.platform.alibabacloud および controlPlane.platform.alibabacloud は、コンピュートマシンおよびコントロールプレーンマシンの platform.alibabacloud.defaultMachinePlatform 設定をそれぞれ上書きします。

Expand
表4.4 オプションの Alibaba Cloud パラメーター
パラメーター説明

compute.platform.alibabacloud.imageID

ECS インスタンスの作成に使用される imageID。ImageID はクラスターと同じリージョンに属している必要があります。

文字列。

compute.platform.alibabacloud.instanceType

InstanceType は、ECS インスタンスタイプを定義します。例: ecs.g6.large

文字列。

compute.platform.alibabacloud.systemDiskCategory

システムディスクのカテゴリーを定義します。例: cloud_efficiencycloud_essd

文字列。

compute.platform.alibabacloud.systemDisksize

システムディスクのサイズをギビバイト (GiB) 単位で定義します。

integer

compute.platform.alibabacloud.zones

使用できるアベイラビリティーゾーンのリスト。例: cn-hangzhou-hcn-hangzhou-j

文字列リスト。

controlPlane.platform.alibabacloud.imageID

ECS インスタンスの作成に使用される imageID。ImageID はクラスターと同じリージョンに属している必要があります。

文字列。

controlPlane.platform.alibabacloud.instanceType

InstanceType は、ECS インスタンスタイプを定義します。例: ecs.g6.xlarge

文字列。

controlPlane.platform.alibabacloud.systemDiskCategory

システムディスクのカテゴリーを定義します。例: cloud_efficiencycloud_essd

文字列。

controlPlane.platform.alibabacloud.systemDisksize

システムディスクのサイズをギビバイト (GiB) 単位で定義します。

integer

controlPlane.platform.alibabacloud.zones

使用できるアベイラビリティーゾーンのリスト。例: cn-hangzhou-hcn-hangzhou-j

文字列リスト。

platform.alibabacloud.region

必須。クラスターが作成される Alibaba Cloud リージョン。

文字列。

platform.alibabacloud.resourceGroupID

クラスターがインストールされる既存のリソースグループの ID。空の場合、インストーラーはクラスターの新しいリソースグループを作成します。

文字列。

platform.alibabacloud.tags

クラスター用に作成されたすべての Alibaba Cloud リソースに適用する追加のキーと値。

オブジェクト。

platform.alibabacloud.vpcID

クラスターをインストールする必要がある既存の VPC の ID。空の場合、インストーラーはクラスターの新しい VPC を作成します。

文字列。

platform.alibabacloud.vswitchIDs

クラスターリソースが作成される既存の VSwitch の ID リスト。既存の VSwitch は、既存の VPC も使用している場合にのみ使用できます。空の場合、インストーラーはクラスター用の新しい VSwitch を作成します。

文字列リスト。

platform.alibabacloud.defaultMachinePlatform.imageID

コンピュートマシンとコントロールプレーンマシンの両方で、ECS インスタンスの作成に使用する必要があるイメージ ID。設定されている場合、イメージ ID はクラスターと同じリージョンに属している必要があります。

文字列。

platform.alibabacloud.defaultMachinePlatform.instanceType

コンピュートマシンとコントロールプレーンマシンの両方で、ECS インスタンスの作成に使用される ECS インスタンスタイプ。例: ecs.g6.xlarge

文字列。

platform.alibabacloud.defaultMachinePlatform.systemDiskCategory

コンピュートマシンとコントロールプレーンマシンの両方におけるシステムディスクのカテゴリー。例: cloud_efficiencycloud_essd

文字列、たとえば ""、cloud_efficiencycloud_essd

platform.alibabacloud.defaultMachinePlatform.systemDiskSize

コンピュートマシンとコントロールプレーンマシンの両方で、ギビバイト (GiB) 単位のシステムディスクのサイズ。最小値は 120 です。

integer

platform.alibabacloud.defaultMachinePlatform.zones

コンピュートマシンとコントロールプレーンマシンの両方で、使用可能なアベイラビリティーゾーンのリスト。例: cn-hangzhou-hcn-hangzhou-j

文字列リスト。

platform.alibabacloud.privateZoneID

クラスターの内部 API の DNS レコードを追加する既存のプライベートゾーンの ID。既存のプライベートゾーンは、既存の VPC も使用している場合にのみ使用できます。プライベートゾーンは、サブネットを含む VPC に関連付ける必要があります。プライベートゾーンを未設定のままにして、インストーラーがユーザーに代わってプライベートゾーンを作成すするようにします。

文字列。

4.4.4.5. Alibaba Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル

インストール設定ファイル (install-config.yaml) をカスタマイズして、クラスターのプラットフォームに関する詳細を指定したり、必要なパラメーターの値を変更したりできます。

apiVersion: v1
baseDomain: alicloud-dev.devcluster.openshift.com
credentialsMode: Manual
compute:
- architecture: amd64
  hyperthreading: Enabled
  name: worker
  platform: {}
  replicas: 3
controlPlane:
  architecture: amd64
  hyperthreading: Enabled
  name: master
  platform: {}
  replicas: 3
metadata:
  creationTimestamp: null
  name: test-cluster 
1

 networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN 
2

  serviceNetwork:
  - 172.30.0.0/16
platform:
  alibabacloud:
    defaultMachinePlatform: 
3

      instanceType: ecs.g6.xlarge
      systemDiskCategory: cloud_efficiency
      systemDiskSize: 200
    region: ap-southeast-1 
4

    resourceGroupID: rg-acfnw6j3hyai 
5

    vpcID: vpc-0xifdjerdibmaqvtjob2b
    vswitchIDs: 
6

    - vsw-0xi8ycgwc8wv5rhviwdq5
    - vsw-0xiy6v3z2tedv009b4pz2
publish: External
pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }' 
7

sshKey: |
  ssh-rsa AAAA... 
8
1
必須。インストールプログラムにより、クラスター名の入力を求められます。
2
インストールするクラスターネットワークプラグイン。サポートされている値は OVNKubernetesOpenShiftSDN です。デフォルトの値は OVNkubernetes です。
3
オプション。独自のプラットフォーム設定を定義しないマシンプールのパラメーターを指定します。
4
必須。インストールプログラムにより、クラスターをデプロイするリージョンの入力を求められます。
5
オプション。クラスターをインストールする必要がある既存のリソースグループを指定します。
7
必須。インストールプログラムは、プルシークレットの入力を求めます。
8
オプション。インストールプログラムは、クラスター内のマシンへのアクセスに使用する SSH キー値の入力を求めます。
6
オプション。これらは vswitchID 値の例です。
4.4.4.6. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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-----
    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 信頼バンドルからの認証局によって署名されない限り必要になります。
    注記

    インストールプログラムは、プロキシーの 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.4.5. クラスターのデプロイ

互換性のあるクラウドプラットフォームに 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.4.6. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

4.4.8. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

4.4.9. OpenShift Container Platform の Telemetry アクセス

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

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

4.4.10. 次のステップ

4.5. ネットワークをカスタマイズして Alibaba Cloud にクラスターをインストールする

OpenShift Container Platform 4.11 では、カスタマイズされたネットワーク設定オプションを使用して、Alibaba Cloud にクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。

大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy 設定パラメーターのみになります。

重要

OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

4.5.1. 前提条件

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

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

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

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

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

4.5.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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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.5.4. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

4.5.5. ネットワーク設定フェーズ

OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。

フェーズ 1

マニフェストファイルを作成する前に、install-config.yaml ファイルで以下のネットワーク関連のフィールドをカスタマイズできます。

  • networking.networkType
  • networking.clusterNetwork
  • networking.serviceNetwork
  • networking.machineNetwork

    これらのフィールドの詳細は、インストール設定パラメーター を参照してください。

    注記

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

    重要

    CIDR 範囲 172.17.0.0/16 は libVirt によって予約されています。この範囲、またはこの範囲と重複する範囲をクラスター内のネットワークに使用することはできません。

フェーズ 2
openshift-install create manifests を実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。

フェーズ 2 で、install-config.yaml ファイルのフェーズ 1 で指定した値を上書きすることはできません。ただし、フェーズ 2 ではクラスターネットワークプロバイダーをさらにカスタマイズできます。

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

インストールする 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 からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

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

        注記

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

      2. クラスターの記述名を入力します。
      3. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、インストール設定パラメーターのセクションを参照してください。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

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

4.5.5.2. 必要なインストールマニフェストの生成

クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

手順

  1. インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。

    $ openshift-install create manifests --dir <installation_directory>

    ここで、

    <installation_directory>
    インストールプログラムがファイルを作成するディレクトリーを指定します。
注記

デフォルトで、ccoctl はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir フラグを使用します。この手順では、<path_to_ccoctl_output_dir> を使用してこの場所を参照します。

前提条件

以下が必要になります。

  • ccoctl バイナリーを抽出して準備している。

手順

  1. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    <1> `credrequests` is the directory where the list of `CredentialsRequest` objects is stored. This command creates the directory if it does not exist.
    注記

    このコマンドの実行には少し時間がかかる場合があります。

4.5.5.3. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

4.5.5.3.1. 必須設定パラメーター

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

Expand
表4.5 必須パラメーター
パラメーター説明

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

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}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"
      }
   }
}
4.5.5.3.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

Expand
表4.6 ネットワークパラメーター
パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

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 です。

OpenShift SDN および 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 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

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

例: 10.0.0.0/16

注記

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

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

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

Expand
表4.7 オプションのパラメーター
パラメーター説明

additionalTrustBundle

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

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

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

MachinePool オブジェクトの配列。

compute.architecture

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

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。

controlPlane.architecture

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

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

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

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

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

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

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

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 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

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

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

imageContentSources.source

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

文字列

imageContentSources.mirrors

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

文字列の配列。

publish

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

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

このフィールドを Internal に設定することは、クラウド以外のプラットフォームおよび IBM Cloud ではサポートされていません。

重要

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

sshKey

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

注記

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

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

4.5.5.4. Alibaba Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル

インストール設定ファイル (install-config.yaml) をカスタマイズして、クラスターのプラットフォームに関する詳細を指定したり、必要なパラメーターの値を変更したりできます。

apiVersion: v1
baseDomain: alicloud-dev.devcluster.openshift.com
credentialsMode: Manual
compute:
- architecture: amd64
  hyperthreading: Enabled
  name: worker
  platform: {}
  replicas: 3
controlPlane:
  architecture: amd64
  hyperthreading: Enabled
  name: master
  platform: {}
  replicas: 3
metadata:
  creationTimestamp: null
  name: test-cluster 
1

 networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN 
2

  serviceNetwork:
  - 172.30.0.0/16
platform:
  alibabacloud:
    defaultMachinePlatform: 
3

      instanceType: ecs.g6.xlarge
      systemDiskCategory: cloud_efficiency
      systemDiskSize: 200
    region: ap-southeast-1 
4

    resourceGroupID: rg-acfnw6j3hyai 
5

    vpcID: vpc-0xifdjerdibmaqvtjob2b
    vswitchIDs: 
6

    - vsw-0xi8ycgwc8wv5rhviwdq5
    - vsw-0xiy6v3z2tedv009b4pz2
publish: External
pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }' 
7

sshKey: |
  ssh-rsa AAAA... 
8
1
必須。インストールプログラムにより、クラスター名の入力を求められます。
2
インストールするクラスターネットワークプラグイン。サポートされている値は OVNKubernetesOpenShiftSDN です。デフォルトの値は OVNkubernetes です。
3
オプション。独自のプラットフォーム設定を定義しないマシンプールのパラメーターを指定します。
4
必須。インストールプログラムにより、クラスターをデプロイするリージョンの入力を求められます。
5
オプション。クラスターをインストールする必要がある既存のリソースグループを指定します。
7
必須。インストールプログラムは、プルシークレットの入力を求めます。
8
オプション。インストールプログラムは、クラスター内のマシンへのアクセスに使用する SSH キー値の入力を求めます。
6
オプション。これらは vswitchID 値の例です。
4.5.5.5. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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-----
    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 信頼バンドルからの認証局によって署名されない限り必要になります。
    注記

    インストールプログラムは、プロキシーの 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.5.6. Cluster Network Operator (CNO) の設定

クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io API グループの Network API のフィールドを指定します。

CNO 設定は、Network.config.openshift.io API グループの Network API からクラスターのインストール時に以下のフィールドを継承し、これらのフィールドは変更できません。

clusterNetwork
Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
サービスの IP アドレスプール。
defaultNetwork.type
OpenShift SDN または OVN-Kubernetes などのクラスターネットワークプロバイダー。

defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプロバイダー設定を指定できます。

4.5.6.1. Cluster Network Operator 設定オブジェクト

Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。

Expand
表4.8 Cluster Network Operator 設定オブジェクト
フィールド説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes Container Network Interface (CNI) ネットワークプロバイダーは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。

spec:
  serviceNetwork:
  - 172.30.0.0/14

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.defaultNetwork

object

クラスターネットワークの Container Network Interface (CNI) ネットワークプロバイダーを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプロバイダーを使用している場合、kube-proxy 設定は機能しません。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

Expand
表4.9 defaultNetwork オブジェクト
フィールド説明

type

string

OpenShiftSDN または OVNKubernetes のいずれか。クラスターネットワークプロバイダーはインストール時に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform はデフォルトで、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーを使用します。

openshiftSDNConfig

object

このオブジェクトは OpenShift SDN クラスターネットワークプロバイダーにのみ有効です。

ovnKubernetesConfig

object

このオブジェクトは OVN-Kubernetes クラスターネットワークプロバイダーにのみ有効です。

OpenShift SDN CNI クラスターネットワークプロバイダーの設定

以下の表は、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーの設定フィールドについて説明しています。

Expand
表4.10 openshiftSDNConfig オブジェクト
フィールド説明

mode

string

OpenShift SDN のネットワーク分離モードを設定します。デフォルト値は NetworkPolicy です。

Multitenant および Subnet の値は、OpenShift Container Platform 3.x との後方互換性を維持するために利用できますが、その使用は推奨されていません。この値は、クラスターのインストール後は変更できません。

mtu

integer

VXLAN オーバーレイネットワークの最大転送単位 (MTU)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 50 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1450 に設定する必要があります。

この値は、クラスターのインストール後は変更できません。

vxlanPort

integer

すべての VXLAN パケットに使用するポート。デフォルト値は 4789 です。この値は、クラスターのインストール後は変更できません。

別の VXLAN ネットワークの一部である既存ノードと共に仮想化環境で実行している場合は、これを変更する必要がある可能性があります。たとえば、OpenShift SDN オーバーレイを VMware NSX-T 上で実行する場合は、両方の SDN が同じデフォルトの VXLAN ポート番号を使用するため、VXLAN の別のポートを選択する必要があります。

Amazon Web Services (AWS) では、VXLAN にポート 9000 とポート 9999 間の代替ポートを選択できます。

OpenShift SDN 設定の例

defaultNetwork:
  type: OpenShiftSDN
  openshiftSDNConfig:
    mode: NetworkPolicy
    mtu: 1450
    vxlanPort: 4789

OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定

以下の表は OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定フィールドについて説明しています。

Expand
表4.11 ovnKubernetesConfig object
フィールド説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 100 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

genevePort

integer

すべての Geneve パケットに使用するポート。デフォルト値は 6081 です。この値は、クラスターのインストール後は変更できません。

ipsecConfig

object

IPsec 暗号化を有効にするために空のオブジェクトを指定します。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。

注記

egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

Expand
表4.12 policyAuditConfig オブジェクト
フィールド説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

destination

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

Expand
表4.13 gatewayConfig オブジェクト
フィールド説明

routingViaHost

boolean

Pod からホストネットワークスタックへの egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを true に設定すると、egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

IPsec が有効な OVN-Kubernetes 設定の例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig: {}

kubeProxyConfig オブジェクト設定

kubeProxyConfig オブジェクトの値は以下の表で定義されます。

Expand
表4.14 kubeProxyConfig オブジェクト
フィールド説明

iptablesSyncPeriod

string

iptables ルールの更新期間。デフォルト値は 30s です。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ ドキュメントで説明されています。

注記

OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。

proxyArguments.iptables-min-sync-period

array

iptables ルールを更新する前の最小期間。このフィールドにより、更新の頻度が高くなり過ぎないようにできます。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ で説明されています。デフォルト値:

kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

4.5.7. 高度なネットワーク設定の指定

クラスターネットワークプロバイダーに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。

重要

インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。

前提条件

  • install-config.yaml ファイルを作成し、これに対する変更を完了している。

手順

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

    $ ./openshift-install create manifests --dir <installation_directory> 
    1
    1
    <installation_directory> は、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
  3. 以下の例のように、cluster-network-03-config.yml ファイルで、クラスターの高度なネットワーク設定を指定します。

    OpenShift SDN ネットワークプロバイダーに異なる VXLAN ポートを指定します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        openshiftSDNConfig:
          vxlanPort: 4800

    OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にします。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          ipsecConfig: {}

  4. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時に manifests/ ディレクトリーを使用します。

4.5.8. OVN-Kubernetes を使用したハイブリッドネットワークの設定

OVN-Kubernetes でハイブリッドネットワークを使用するようにクラスターを設定できます。これにより、異なるノードのネットワーク設定をサポートするハイブリッドクラスターが可能になります。たとえば、これはクラスター内の Linux ノードと Windows ノードの両方を実行するために必要です。

重要

クラスターのインストール時に、OVN-Kubernetes を使用してハイブリッドネットワークを設定する必要があります。インストールプロセス後に、ハイブリッドネットワークに切り替えることはできません。

前提条件

  • install-config.yaml ファイルで networking.networkType パラメーターの OVNKubernetes を定義していること。詳細は、選択したクラウドプロバイダーでの OpenShift Container Platform ネットワークのカスタマイズの設定についてのインストールドキュメントを参照してください。

手順

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

    $ ./openshift-install create manifests --dir <installation_directory>

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    $ cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml
    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
    EOF

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの manifests/ ディレクトリーが含まれるディレクトリー名を指定します。
  3. cluster-network-03-config.yml ファイルをエディターで開き、以下の例のようにハイブリッドネットワークで OVN-Kubernetes を設定します。

    ハイブリッドネットワーク設定の指定

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          hybridOverlayConfig:
            hybridClusterNetwork: 
    1
    
            - cidr: 10.132.0.0/14
              hostPrefix: 23
            hybridOverlayVXLANPort: 9898 
    2

    1
    追加のオーバーレイネットワーク上のノードに使用される CIDR 設定を指定します。hybridClusterNetwork CIDR は clusterNetwork CIDR と重複できません。
    2
    追加のオーバーレイネットワークのカスタム VXLAN ポートを指定します。これは、vSphere にインストールされたクラスターで Windows ノードを実行するために必要であり、その他のクラウドプロバイダー用に設定することはできません。カスタムポートには、デフォルトの 4789 ポートを除くいずれかのオープンポートを使用できます。この要件についての詳細は、Microsoft ドキュメントの Pod-to-pod connectivity between hosts is broken を参照してください。
    注記

    Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019 は、カスタムの VXLAN ポートの選択をサポートしないため、カスタムの hybridOverlayVXLANPort 値を持つクラスターではサポートされません。

  4. cluster-network-03-config.yml ファイルを保存し、テキストエディターを終了します。
  5. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、クラスターの作成時に manifests/ ディレクトリーを削除します。

4.5.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.5.10. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

4.5.12. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

4.5.13. OpenShift Container Platform の Telemetry アクセス

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

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

4.5.14. 次のステップ

4.6. Alibaba Cloud 上のクラスターを既存の VPC にインストールする

OpenShift Container Platform バージョン 4.11 では、Alibaba Cloud Services 上の既存の Alibaba Virtual Private Cloud (VPC) にクラスターをインストールできます。インストールプログラムは必要なインフラストラクチャーをプロビジョニングし、その後カスタマイズできます。VPC インストールをカスタマイズするには、クラスターをインストールする前に 'install-config.yaml' ファイルのパラメーターを変更します。

注記

OpenShift Container Platform インストール設定のスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後にさらに多くの OpenShift Container Platform 設定タスクを実行することができます。

重要

OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

4.6.1. 前提条件

4.6.2. カスタム VPC の使用

OpenShift Container Platform 4.11 では、Alibaba Cloud Platform の既存の Virtual Private Cloud (VPC) 内の既存のサブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の Alibaba VPC にデプロイすることで、新しいアカウントの制限の制約を回避し、所属する組織の運用上の制約をより簡単に順守することができます。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。vSwitch を使用してネットワークを設定する必要があります。

4.6.2.1. VPC を使用するための要件

VPC CIDR ブロックとマシンネットワーク CIDR の組み合わせは、空であってはなりません。vSwitch はマシンネットワーク内にある必要があります。

インストールプログラムでは、次のコンポーネントは作成されません。

  • VPC
  • vSwitch
  • ルートテーブル
  • NAT ゲートウェイ
注記

インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。

4.6.2.2. VPC 検証

指定した vSwitch が適切であることを確認するために、インストールプログラムは次のデータを確認します。

  • 指定するすべての vSwitch が存在する必要があります。
  • コントロールプレーンマシンとコンピュートマシンに 1 つ以上の vSwitch を提供しました。
  • vSwitch の CIDR は、指定したマシン CIDR に属します。
4.6.2.3. パーミッションの区分

一部の個人は、クラウド内に他とは異なるリソースを作成できます。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成できる場合がありますが、VPC や vSwitch などのネットワーク関連のコンポーネントは作成できません。

4.6.2.4. クラスター間の分離

OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離は以下の方法で軽減されます。

  • 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
  • ICMP Ingress はネットワーク全体で許可されます。
  • TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。

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

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

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

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

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

4.6.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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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.6.5. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
4.6.5.1. インストール設定ファイルの作成

Alibaba Cloud にインストールする 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 からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

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

        注記

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

      2. ターゲットとするプラットフォームとして alibabacloud を選択します。
      3. クラスターをデプロイするリージョンを選択します。
      4. クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
      5. クラスターの記述名を指定します。
      6. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. クラスターを Alibaba Cloud にインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。install-config.yaml ファイルを変更して、credentialsMode パラメーターを Manual に設定します。

    credentialsModeManual に設定された install-config.yaml 設定ファイルの例

    apiVersion: v1
    baseDomain: cluster1.example.com
    credentialsMode: Manual 
    1
    
    compute:
    - architecture: amd64
      hyperthreading: Enabled
     ...

    1
    この行を追加して、 credentialsModeManual に設定します。
  3. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、インストール設定パラメーターのセクションを参照してください。
  4. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

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

4.6.5.2. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

4.6.5.2.1. 必須設定パラメーター

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

Expand
表4.15 必須パラメーター
パラメーター説明

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

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}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"
      }
   }
}
4.6.5.2.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

Expand
表4.16 ネットワークパラメーター
パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

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 です。

OpenShift SDN および 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 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

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

例: 10.0.0.0/16

注記

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

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

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

Expand
表4.17 オプションのパラメーター
パラメーター説明

additionalTrustBundle

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

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

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

MachinePool オブジェクトの配列。

compute.architecture

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

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。

controlPlane.architecture

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

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

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

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

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

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

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

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 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

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

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

imageContentSources.source

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

文字列

imageContentSources.mirrors

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

文字列の配列。

publish

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

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

このフィールドを Internal に設定することは、クラウド以外のプラットフォームおよび IBM Cloud ではサポートされていません。

重要

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

sshKey

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

注記

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

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

4.6.5.2.4. 追加の Alibaba Cloud 設定パラメーター

Alibaba Cloud の追加の設定パラメーターは、以下の表で説明されています。alibabacloud パラメーターは、Alibaba Cloud にインストールするときに使用される設定です。defaultMachinePlatform パラメーターは、独自のプラットフォーム設定を定義しないマシンプール用に Alibaba Cloud にインストールするときに使用されるデフォルト設定です。

これらのパラメーターは、指定されているコンピュートマシンとコントロールプレーンマシンの両方に適用されます。

注記

定義されている場合、パラメーターcompute.platform.alibabacloud および controlPlane.platform.alibabacloud は、コンピュートマシンおよびコントロールプレーンマシンの platform.alibabacloud.defaultMachinePlatform 設定をそれぞれ上書きします。

Expand
表4.18 オプションの Alibaba Cloud パラメーター
パラメーター説明

compute.platform.alibabacloud.imageID

ECS インスタンスの作成に使用される imageID。ImageID はクラスターと同じリージョンに属している必要があります。

文字列。

compute.platform.alibabacloud.instanceType

InstanceType は、ECS インスタンスタイプを定義します。例: ecs.g6.large

文字列。

compute.platform.alibabacloud.systemDiskCategory

システムディスクのカテゴリーを定義します。例: cloud_efficiencycloud_essd

文字列。

compute.platform.alibabacloud.systemDisksize

システムディスクのサイズをギビバイト (GiB) 単位で定義します。

integer

compute.platform.alibabacloud.zones

使用できるアベイラビリティーゾーンのリスト。例: cn-hangzhou-hcn-hangzhou-j

文字列リスト。

controlPlane.platform.alibabacloud.imageID

ECS インスタンスの作成に使用される imageID。ImageID はクラスターと同じリージョンに属している必要があります。

文字列。

controlPlane.platform.alibabacloud.instanceType

InstanceType は、ECS インスタンスタイプを定義します。例: ecs.g6.xlarge

文字列。

controlPlane.platform.alibabacloud.systemDiskCategory

システムディスクのカテゴリーを定義します。例: cloud_efficiencycloud_essd

文字列。

controlPlane.platform.alibabacloud.systemDisksize

システムディスクのサイズをギビバイト (GiB) 単位で定義します。

integer

controlPlane.platform.alibabacloud.zones

使用できるアベイラビリティーゾーンのリスト。例: cn-hangzhou-hcn-hangzhou-j

文字列リスト。

platform.alibabacloud.region

必須。クラスターが作成される Alibaba Cloud リージョン。

文字列。

platform.alibabacloud.resourceGroupID

クラスターがインストールされる既存のリソースグループの ID。空の場合、インストーラーはクラスターの新しいリソースグループを作成します。

文字列。

platform.alibabacloud.tags

クラスター用に作成されたすべての Alibaba Cloud リソースに適用する追加のキーと値。

オブジェクト。

platform.alibabacloud.vpcID

クラスターをインストールする必要がある既存の VPC の ID。空の場合、インストーラーはクラスターの新しい VPC を作成します。

文字列。

platform.alibabacloud.vswitchIDs

クラスターリソースが作成される既存の VSwitch の ID リスト。既存の VSwitch は、既存の VPC も使用している場合にのみ使用できます。空の場合、インストーラーはクラスター用の新しい VSwitch を作成します。

文字列リスト。

platform.alibabacloud.defaultMachinePlatform.imageID

コンピュートマシンとコントロールプレーンマシンの両方で、ECS インスタンスの作成に使用する必要があるイメージ ID。設定されている場合、イメージ ID はクラスターと同じリージョンに属している必要があります。

文字列。

platform.alibabacloud.defaultMachinePlatform.instanceType

コンピュートマシンとコントロールプレーンマシンの両方で、ECS インスタンスの作成に使用される ECS インスタンスタイプ。例: ecs.g6.xlarge

文字列。

platform.alibabacloud.defaultMachinePlatform.systemDiskCategory

コンピュートマシンとコントロールプレーンマシンの両方におけるシステムディスクのカテゴリー。例: cloud_efficiencycloud_essd

文字列、たとえば ""、cloud_efficiencycloud_essd

platform.alibabacloud.defaultMachinePlatform.systemDiskSize

コンピュートマシンとコントロールプレーンマシンの両方で、ギビバイト (GiB) 単位のシステムディスクのサイズ。最小値は 120 です。

integer

platform.alibabacloud.defaultMachinePlatform.zones

コンピュートマシンとコントロールプレーンマシンの両方で、使用可能なアベイラビリティーゾーンのリスト。例: cn-hangzhou-hcn-hangzhou-j

文字列リスト。

platform.alibabacloud.privateZoneID

クラスターの内部 API の DNS レコードを追加する既存のプライベートゾーンの ID。既存のプライベートゾーンは、既存の VPC も使用している場合にのみ使用できます。プライベートゾーンは、サブネットを含む VPC に関連付ける必要があります。プライベートゾーンを未設定のままにして、インストーラーがユーザーに代わってプライベートゾーンを作成すするようにします。

文字列。

4.6.5.3. Alibaba Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル

インストール設定ファイル (install-config.yaml) をカスタマイズして、クラスターのプラットフォームに関する詳細を指定したり、必要なパラメーターの値を変更したりできます。

apiVersion: v1
baseDomain: alicloud-dev.devcluster.openshift.com
credentialsMode: Manual
compute:
- architecture: amd64
  hyperthreading: Enabled
  name: worker
  platform: {}
  replicas: 3
controlPlane:
  architecture: amd64
  hyperthreading: Enabled
  name: master
  platform: {}
  replicas: 3
metadata:
  creationTimestamp: null
  name: test-cluster 
1

 networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN 
2

  serviceNetwork:
  - 172.30.0.0/16
platform:
  alibabacloud:
    defaultMachinePlatform: 
3

      instanceType: ecs.g6.xlarge
      systemDiskCategory: cloud_efficiency
      systemDiskSize: 200
    region: ap-southeast-1 
4

    resourceGroupID: rg-acfnw6j3hyai 
5

    vpcID: vpc-0xifdjerdibmaqvtjob2b
    vswitchIDs: 
6

    - vsw-0xi8ycgwc8wv5rhviwdq5
    - vsw-0xiy6v3z2tedv009b4pz2
publish: External
pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }' 
7

sshKey: |
  ssh-rsa AAAA... 
8
1
必須。インストールプログラムにより、クラスター名の入力を求められます。
2
インストールするクラスターネットワークプラグイン。サポートされている値は OVNKubernetesOpenShiftSDN です。デフォルトの値は OVNkubernetes です。
3
オプション。独自のプラットフォーム設定を定義しないマシンプールのパラメーターを指定します。
4
必須。インストールプログラムにより、クラスターをデプロイするリージョンの入力を求められます。
5
オプション。クラスターをインストールする必要がある既存のリソースグループを指定します。
7
必須。インストールプログラムは、プルシークレットの入力を求めます。
8
オプション。インストールプログラムは、クラスター内のマシンへのアクセスに使用する SSH キー値の入力を求めます。
6
オプション。これらは vswitchID 値の例です。
4.6.5.4. 必要なインストールマニフェストの生成

クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

手順

  1. インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。

    $ openshift-install create manifests --dir <installation_directory>

    ここで、

    <installation_directory>
    インストールプログラムがファイルを作成するディレクトリーを指定します。
4.6.5.5. Cloud Credential Operator ユーティリティーの設定

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 を使用する準備ができていることを確認するには、次のコマンドを実行してヘルプファイルを表示します。

    $ ccoctl --help

    ccoctl --help の出力

    OpenShift credentials provisioning tool
    
    Usage:
      ccoctl [command]
    
    Available Commands:
      alibabacloud Manage credentials objects for alibaba cloud
      aws          Manage credentials objects for AWS cloud
      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.

OpenShift Container Platform Cloud Credential Operator (CCO) ユーティリティーを使用して、Alibaba Cloud RAM ユーザーとクラスター内コンポーネントごとのポリシーの作成を自動化できます。

注記

デフォルトで、ccoctl はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir フラグを使用します。この手順では、<path_to_ccoctl_output_dir> を使用してこの場所を参照します。

前提条件

以下が必要になります。

  • ccoctl バイナリーを抽出して準備している。
  • OpenShift Container Platform クラスターを作成するための十分な権限を持つ RAM ユーザーを作成している。
  • その RAM ユーザーの AccessKeyID (access_key_id) と AccessKeySecret (access_key_secret) をローカルコンピューターの ~/.alibabacloud/credentials ファイル に追加しました。

手順

  1. 以下のコマンドを実行して、$RELEASE_IMAGE 変数を設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    $ oc adm release extract \
    --credentials-requests \
    --cloud=alibabacloud \
    --to=<path_to_directory_with_list_of_credentials_requests>/credrequests \ 
    1
    
    $RELEASE_IMAGE
    1
    credrequests は、CredentialsRequest オブジェクトのリストが格納されるディレクトリーです。ディレクトリーが存在しない場合、このコマンドはディレクトリーを作成します。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. クラスターでクラスター機能を使用して 1 つ以上のオプションコンポーネントを無効にする場合は、無効なコンポーネントの CredentialsRequest カスタムリソースを削除します。

    Alibaba Cloud 上の OpenShift Container Platform 4.12 の credrequests ディレクトリーの内容の例

    0000_30_machine-api-operator_00_credentials-request.yaml 
    1
    
    0000_50_cluster-image-registry-operator_01-registry-credentials-request-alibaba.yaml 
    2
    
    0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 
    3
    
    0000_50_cluster-storage-operator_03_credentials_request_alibaba.yaml 
    4

    1
    Machine API Operator CR が必要です。
    2
    Image Registry Operator CR が必要です。
    3
    Ingress Operator CR が必要です。
    4
    Storage Operator CR はオプションのコンポーネントであり、クラスターで無効になっている場合があります。
  4. ccoctl ツールを使用して、credrequests ディレクトリーですべての CredentialsRequest オブジェクトを処理します。

    1. ツールを使用するには、次のコマンドを実行します。

      $ ccoctl alibabacloud create-ram-users \
      --name <name> \
      --region=<alibaba_region> \
      --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests \
      --output-dir=<path_to_ccoctl_output_dir>

      ここで、

      • <name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
      • <alibaba_region> は、クラウドリソースが作成される Alibaba Cloud リージョンです。
      • <path_to_directory_with_list_of_credentials_requests>/credrequests は、コンポーネント CredentialsRequest オブジェクトのファイルを含むディレクトリーです。
      • <path_to_ccoctl_output_dir> は、生成されたコンポーネントクレデンシャルシークレットが配置されるディレクトリーです。
      注記

      クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

      出力例

      2022/02/11 16:18:26 Created RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials
      2022/02/11 16:18:27 Ready for creating new ram policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy
      2022/02/11 16:18:27 RAM policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has created
      2022/02/11 16:18:28 Policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has attached on user user1-alicloud-openshift-machine-api-alibabacloud-credentials
      2022/02/11 16:18:29 Created access keys for RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials
      2022/02/11 16:18:29 Saved credentials configuration to: user1-alicloud/manifests/openshift-machine-api-alibabacloud-credentials-credentials.yaml
      ...

      注記

      RAM ユーザーは、同時に最大 2 つの AccessKey を持つことができます。ccoctl alibabacloud create-ram-users を 3 回以上実行すると、以前に生成されたマニフェストシークレットが古くなり、新しく生成されたシークレットを再適用する必要があります。

    2. OpenShift Container Platform シークレットが作成されていることを確認します。

      $ ls <path_to_ccoctl_output_dir>/manifests

      出力例:

      openshift-cluster-csi-drivers-alibaba-disk-credentials-credentials.yaml
      openshift-image-registry-installer-cloud-credentials-credentials.yaml
      openshift-ingress-operator-cloud-credentials-credentials.yaml
      openshift-machine-api-alibabacloud-credentials-credentials.yaml

      RAM ユーザーとポリシーが Alibaba Cloud にクエリーを実行して作成されていることを確認できます。詳細については、RAM ユーザーとポリシーのリスト表示に関する Alibaba Cloud のドキュメントを参照してください。

  5. 生成されたクレデンシャルファイルをターゲットマニフェストディレクトリーにコピーします。

    $ cp ./<path_to_ccoctl_output_dir>/manifests/*credentials.yaml ./<path_to_installation>dir>/manifests/

    ここで、

    <path_to_ccoctl_output_dir>
    ccoctl alibabacloud create-ram-users コマンドによって作成されるディレクトリーを指定します。
    <path_to_installation_dir>
    インストールプログラムがファイルを作成するディレクトリーを指定します。

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

互換性のあるクラウドプラットフォームに 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.6.7. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

4.6.9. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

4.6.10. OpenShift Container Platform の Telemetry アクセス

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

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

4.6.11. 次のステップ

4.7. Alibaba Cloud でのクラスターのアンインストール

Alibaba Cloud にデプロイしたクラスターを削除できます。

インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターは、クラウドから削除できます。

注記

アンインストール後に、とくにユーザーによってプロビジョニングされるインフラストラクチャー (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 インストールプログラムを削除します。

第5章 AWS へのインストール

5.1. AWS へのインストールの準備

5.1.1. 前提条件

5.1.2. OpenShift Container Platform OpenStack の AWS へのインストールについての要件

OpenShift Container Platform を Amazon Web Services (AWS) にインストールする前に、AWS アカウントを作成する必要があります。アカウント、アカウントの制限、アカウントのパーミッション、IAM ユーザーセットアップ、およびサポートされている AWS リージョンの設定についての詳細は、AWS アカウントの設定 を参照してください。

ご使用の環境でクラウドアイデンティティーおよびアクセス管理 (IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを kube-system namespace に保存することを望まない場合は、Amazon Web Services Security Token Service (AWS STS) を使用するための Cloud Credential Operator (CCO) の設定 を含む、他のオプションについて AWS の IAM の手動作成 を参照してください。

5.1.3. AWS に OpenShift Container Platform をインストールする方法の選択

OpenShift Container Platform をインストーラーまたはユーザーによってプロビジョニングされるインフラストラクチャーにインストールすることができます。デフォルトのインストールタイプは、インストーラーでプロビジョニングされるインフラストラクチャーを使用します。この場合、インストールプログラムがクラスターの基礎となるインフラストラクチャーをプロビジョニングします。OpenShift Container Platform は、ユーザーによってプロビジョニングされるインフラストラクチャーにインストールすることもできます。インストールプログラムがプロビジョニングするインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。

インストーラーおよびユーザーによってプロビジョニングされるインストールプロセスの詳細は、インストールプロセス を参照してください。

以下の方法のいずれかを使用して、OpenShift Container Platform インストールプログラムでプロビジョニングされる AWS インフラストラクチャーに、クラスターをインストールできます。

以下の方法のいずれかを使用して、独自にプロビジョニングする AWS インフラストラクチャーにクラスターをインストールできます。

5.1.4. 次のステップ

5.2. AWS アカウントの設定

OpenShift Container Platform をインストールする前に、Amazon Web Services (AWS) アカウントを設定する必要があります。

5.2.1. Route 53 の設定

OpenShift Container Platform をインストールするには、使用する Amazon Web Services (AWS) アカウントに、Route 53 サービスの専用のパブリックホストゾーンが必要になります。このゾーンはドメインに対する権威を持っている必要があります。Route 53 サービスは、クラスターへの外部接続のためのクラスターの DNS 解決および名前検索を提供します。

手順

  1. ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、AWS または他のソースから新規のものを取得できます。

    注記

    AWS で新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかります。AWS 経由でドメインを購入する方法についての詳細は、AWS ドキュメントの Registering Domain Names Using Amazon Route 53 を参照してください。

  2. 既存のドメインおよびレジストラーを使用している場合、その DNS を AWS に移行します。AWS ドキュメントの Making Amazon Route 53 the DNS Service for an Existing Domain を参照してください。
  3. ドメインまたはサブドメインのパブリックホストゾーンを作成します。AWS ドキュメントの Creating a Public Hosted Zone を参照してください。

    openshiftcorp.com などのルートドメインや、 clusters.openshiftcorp.com などのサブドメインを使用します。

  4. ホストゾーンレコードから新規の権威ネームサーバーを抽出します。AWS ドキュメントの Getting the Name Servers for a Public Hosted Zone を参照してください。
  5. ドメインが使用する AWS Route 53 ネームサーバーのレジストラーレコードを更新します。たとえば、別のアカウントを使用してドメインを Route 53 サービスに登録している場合は、AWS ドキュメントの Adding or Changing Name Servers or Glue Records のトピックを参照してください。
  6. サブドメインを使用している場合は、その委任レコードを親ドメインに追加します。これにより、サブドメインの Amazon Route 53 の責任が付与されます。親ドメインの DNS プロバイダーによって要約された委任手順に従います。ハイレベルの手順の例については、AWS ドキュメントの Creating a subdomain that uses Amazon Route 53 as the DNS service without migrating the parent domain を参照してください。
5.2.1.1. AWS Route 53 の Ingress Operator エンドポイント設定

Amazon Web Services (AWS) GovCloud (US) US-West または US-East リージョンのいずれかにインストールする場合、Ingress Operator は Route53 およびタグ付けする API クライアントに us-gov-west-1 リージョンを使用します。

Ingress Operator は、タグ付けするエンドポイントが 文字列 'us-gov-east-1' を含むように設定される場合、タグ付けする API エンドポイントとして https://tagging.us-gov-west-1.amazonaws.com を使用します。

AWS GovCloud (US) エンドポイントについての詳細は、GovCloud (US) についての AWS ドキュメントの Service Endpoints を参照してください。

重要

us-gov-east-1 リージョンにインストールする場合、プライベート、非接続インストールは AWS GovCloud ではサポートされません。

Route 53 設定の例

platform:
  aws:
    region: us-gov-west-1
    serviceEndpoints:
    - name: ec2
      url: https://ec2.us-gov-west-1.amazonaws.com
    - name: elasticloadbalancing
      url: https://elasticloadbalancing.us-gov-west-1.amazonaws.com
    - name: route53
      url: https://route53.us-gov.amazonaws.com 
1

    - name: tagging
      url: https://tagging.us-gov-west-1.amazonaws.com 
2

1
Route 53 は、AWS GovCloud (US) リージョンの両方で https://route53.us-gov.amazonaws.com にデフォルト設定されます。
2
US-West リージョンのみにタグ付けするためのエンドポイントがあります。クラスターが別のリージョンにある場合は、このパラメーターを省略します。

5.2.2. AWS アカウントの制限

OpenShift Container Platform クラスターは数多くの Amazon Web Services (AWS) コンポーネントを使用し、デフォルトの サービス制限 は、OpenShift Container Platform クラスターをインストールする機能に影響を与えます。特定のクラスター設定を使用し、クラスターを特定の AWS リージョンにデプロイするか、アカウントを使用して複数のクラスターを実行する場合、AWS アカウントの追加リソースを要求することが必要になる場合があります。

以下の表は、OpenShift Container Platform クラスターのインストールおよび実行機能に影響を与える可能性のある AWS コンポーネントの制限を要約しています。

Expand
コンポーネントデフォルトで利用できるクラスターの数デフォルトの AWS の制限説明

インスタンスの制限

変動あり。

変動あり。

デフォルトで、各クラスターは以下のインスタンスを作成します。

  • 1 つのブートストラップマシン。これはインストール後に削除されます。
  • 3 つのコントロールプレーンノード
  • 3 つのワーカーノード

これらのインスタンスタイプの数は、新規アカウントのデフォルト制限内の値です。追加のワーカーノードをデプロイし、自動スケーリングを有効にし、大規模なワークロードをデプロイするか、異なるインスタンスタイプを使用するには、アカウントの制限を見直し、クラスターが必要なマシンをデプロイできることを確認します。

ほとんどのリージョンでは、ワーカーマシンは m6i.large インスタンスを使用し、ブートストラップおよびコントロールプレーンマシンは m6i.xlarge インスタンスを使用します。これらのインスタンスタイプをサポートしないすべてのリージョンを含む一部のリージョンでは、m5.large および m5.xlarge インスタンスが代わりに使用されます。

Elastic IP (EIP)

0 - 1

アカウントごとに 5 つの EIP

クラスターを高可用性設定でプロビジョニングするために、インストールプログラムはそれぞれの リージョン内のアベイラビリティーゾーン にパブリックおよびプライベートのサブネットを作成します。各プライベートサブネットには NAT ゲートウェイ が必要であり、各 NAT ゲートウェイには別個の Elastic IP が必要です。AWS リージョンマップ を確認して、各リージョンにあるアベイラビリティーゾーンの数を判別します。デフォルトの高可用性を利用するには、少なくとも 3 つのアベイラビリティーゾーンがあるリージョンにクラスターをインストールします。アベイラビリティーゾーンが 6 つ以上あるリージョンにクラスターをインストールするには、EIP 制限を引き上げる必要があります。

重要

us-east-1 リージョンを使用するには、アカウントの EIP 制限を引き上げる必要があります。

Virtual Private Cloud (VPC)

5

リージョンごとに 5 つの VPC

各クラスターは独自の VPC を作成します。

Elastic Load Balancing (ELB/NLB)

3

リージョンごとに 20

デフォルトで、各クラスターは、マスター API サーバーの内部および外部のネットワークロードバランサーおよびルーターの単一の Classic Elastic Load Balancer を作成します。追加の Kubernetes Service オブジェクトをタイプ LoadBalancer を指定してデプロイすると、追加の ロードバランサー が作成されます。

NAT ゲートウェイ

5

アベイラビリティゾーンごとに 5 つ

クラスターは各アベイラビリティーゾーンに 1 つの NAT ゲートウェイをデプロイします。

Elastic Network Interface (ENI)

12 以上

リージョンごとに 350

デフォルトのインストールは 21 の ENI を作成し、リージョンの各アベイラビリティーゾーンに 1 つの ENI を作成します。たとえば、us-east-1 リージョンには 6 つのアベイラビリティーゾーンが含まれるため、そのゾーンにデプロイされるクラスターは 27 の ENI を使用します。AWS リージョンマップ を確認して、各リージョンにあるアベイラビリティーゾーンの数を判別します。

クラスターの使用量やデプロイされたワークロード別に作成された追加のマシンや ELB ロードバランサーに対して、追加の ENI が作成されます。

VPC ゲートウェイ

20

アカウントごとに 20

各クラスターは、S3 アクセス用の単一の VPC ゲートウェイを作成します。

S3 バケット

99

アカウントごとに 100 バケット

インストールプロセスでは 1 つの一時的なバケットを作成し、各クラスターのレジストリーコンポーネントがバケットを作成するため、AWS アカウントごとに 99 の OpenShift Container Platform クラスターのみを作成できます。

セキュリティーグループ

250

アカウントごとに 2,500

各クラスターは、10 の個別のセキュリティーグループを作成します。

5.2.3. IAM ユーザーに必要な AWS パーミッション

注記

ベースクラスターリソースを削除するには、IAM ユーザーが領域 us-east-1 にアクセス許可 tag:GetResources を持っている必要があります。AWS API 要件の一部として、OpenShift Container Platform インストールプログラムはこのリージョンでさまざまなアクションを実行します。

AdministratorAccess ポリシーを、Amazon Web Services (AWS) で作成する IAM ユーザーに割り当てる場合、そのユーザーには必要なパーミッションすべてを付与します。OpenShift Container Platform クラスターのすべてのコンポーネントをデプロイするために、IAM ユーザーに以下のパーミッションが必要になります。

例5.1 インストールに必要な EC2 パーミッション

  • ec2:AuthorizeSecurityGroupEgress
  • ec2:AuthorizeSecurityGroupIngress
  • ec2:CopyImage
  • ec2:CreateNetworkInterface
  • ec2:AttachNetworkInterface
  • ec2:CreateSecurityGroup
  • ec2:CreateTags
  • ec2:CreateVolume
  • ec2:DeleteSecurityGroup
  • ec2:DeleteSnapshot
  • ec2:DeleteTags
  • ec2:DeregisterImage
  • ec2:DescribeAccountAttributes
  • ec2:DescribeAddresses
  • ec2:DescribeAvailabilityZones
  • ec2:DescribeDhcpOptions
  • ec2:DescribeImages
  • ec2:DescribeInstanceAttribute
  • ec2:DescribeInstanceCreditSpecifications
  • ec2:DescribeInstances
  • ec2:DescribeInstanceTypes
  • ec2:DescribeInternetGateways
  • ec2:DescribeKeyPairs
  • ec2:DescribeNatGateways
  • ec2:DescribeNetworkAcls
  • ec2:DescribeNetworkInterfaces
  • ec2:DescribePrefixLists
  • ec2:DescribeRegions
  • ec2:DescribeRouteTables
  • ec2:DescribeSecurityGroups
  • ec2:DescribeSubnets
  • ec2:DescribeTags
  • ec2:DescribeVolumes
  • ec2:DescribeVpcAttribute
  • ec2:DescribeVpcClassicLink
  • ec2:DescribeVpcClassicLinkDnsSupport
  • ec2:DescribeVpcEndpoints
  • ec2:DescribeVpcs
  • ec2:GetEbsDefaultKmsKeyId
  • ec2:ModifyInstanceAttribute
  • ec2:ModifyNetworkInterfaceAttribute
  • ec2:RevokeSecurityGroupEgress
  • ec2:RevokeSecurityGroupIngress
  • ec2:RunInstances
  • ec2:TerminateInstances

例5.2 インストール時のネットワークリソースの作成に必要なパーミッション

  • ec2:AllocateAddress
  • ec2:AssociateAddress
  • ec2:AssociateDhcpOptions
  • ec2:AssociateRouteTable
  • ec2:AttachInternetGateway
  • ec2:CreateDhcpOptions
  • ec2:CreateInternetGateway
  • ec2:CreateNatGateway
  • ec2:CreateRoute
  • ec2:CreateRouteTable
  • ec2:CreateSubnet
  • ec2:CreateVpc
  • ec2:CreateVpcEndpoint
  • ec2:ModifySubnetAttribute
  • ec2:ModifyVpcAttribute
注記

既存の VPC を使用する場合、アカウントではネットワークリソースの作成にこれらのパーミッションを必要としません。

例5.3 インストールに必要な Elastic Load Balancing (ELB) のパーミッション

  • elasticloadbalancing:AddTags
  • elasticloadbalancing:ApplySecurityGroupsToLoadBalancer
  • elasticloadbalancing:AttachLoadBalancerToSubnets
  • elasticloadbalancing:ConfigureHealthCheck
  • elasticloadbalancing:CreateLoadBalancer
  • elasticloadbalancing:CreateLoadBalancerListeners
  • elasticloadbalancing:DeleteLoadBalancer
  • elasticloadbalancing:DeregisterInstancesFromLoadBalancer
  • elasticloadbalancing:DescribeInstanceHealth
  • elasticloadbalancing:DescribeLoadBalancerAttributes
  • elasticloadbalancing:DescribeLoadBalancers
  • elasticloadbalancing:DescribeTags
  • elasticloadbalancing:ModifyLoadBalancerAttributes
  • elasticloadbalancing:RegisterInstancesWithLoadBalancer
  • elasticloadbalancing:SetLoadBalancerPoliciesOfListener

例5.4 インストールに必要な Elastic Load Balancing (ELBv2) のパーミッション

  • elasticloadbalancing:AddTags
  • elasticloadbalancing:CreateListener
  • elasticloadbalancing:CreateLoadBalancer
  • elasticloadbalancing:CreateTargetGroup
  • elasticloadbalancing:DeleteLoadBalancer
  • elasticloadbalancing:DeregisterTargets
  • elasticloadbalancing:DescribeListeners
  • elasticloadbalancing:DescribeLoadBalancerAttributes
  • elasticloadbalancing:DescribeLoadBalancers
  • elasticloadbalancing:DescribeTargetGroupAttributes
  • elasticloadbalancing:DescribeTargetHealth
  • elasticloadbalancing:ModifyLoadBalancerAttributes
  • elasticloadbalancing:ModifyTargetGroup
  • elasticloadbalancing:ModifyTargetGroupAttributes
  • elasticloadbalancing:RegisterTargets

例5.5 インストールに必要な IAM パーミッション

  • iam:AddRoleToInstanceProfile
  • iam:CreateInstanceProfile
  • iam:CreateRole
  • iam:DeleteInstanceProfile
  • iam:DeleteRole
  • iam:DeleteRolePolicy
  • iam:GetInstanceProfile
  • iam:GetRole
  • iam:GetRolePolicy
  • iam:GetUser
  • iam:ListInstanceProfilesForRole
  • iam:ListRoles
  • iam:ListUsers
  • iam:PassRole
  • iam:PutRolePolicy
  • iam:RemoveRoleFromInstanceProfile
  • iam:SimulatePrincipalPolicy
  • iam:TagRole
注記

AWS アカウントに Elastic Load Balancer (ELB) を作成していない場合、IAM ユーザーには iam:CreateServiceLinkedRole パーミッションも必要です。

例5.6 インストールに必要な Route 53 パーミッション

  • route53:ChangeResourceRecordSets
  • route53:ChangeTagsForResource
  • route53:CreateHostedZone
  • route53:DeleteHostedZone
  • route53:GetChange
  • route53:GetHostedZone
  • route53:ListHostedZones
  • route53:ListHostedZonesByName
  • route53:ListResourceRecordSets
  • route53:ListTagsForResource
  • route53:UpdateHostedZoneComment

例5.7 インストールに必要な S3 パーミッション

  • s3:CreateBucket
  • s3:DeleteBucket
  • s3:GetAccelerateConfiguration
  • s3:GetBucketAcl
  • s3:GetBucketCors
  • s3:GetBucketLocation
  • s3:GetBucketLogging
  • s3:GetBucketPolicy
  • s3:GetBucketObjectLockConfiguration
  • s3:GetBucketReplication
  • s3:GetBucketRequestPayment
  • s3:GetBucketTagging
  • s3:GetBucketVersioning
  • s3:GetBucketWebsite
  • s3:GetEncryptionConfiguration
  • s3:GetLifecycleConfiguration
  • s3:GetReplicationConfiguration
  • s3:ListBucket
  • s3:PutBucketAcl
  • s3:PutBucketTagging
  • s3:PutEncryptionConfiguration

例5.8 クラスター Operator が必要とする S3 パーミッション

  • s3:DeleteObject
  • s3:GetObject
  • s3:GetObjectAcl
  • s3:GetObjectTagging
  • s3:GetObjectVersion
  • s3:PutObject
  • s3:PutObjectAcl
  • s3:PutObjectTagging

例5.9 ベースクラスターリソースの削除に必要なパーミッション

  • autoscaling:DescribeAutoScalingGroups
  • ec2:DeletePlacementGroup
  • ec2:DeleteNetworkInterface
  • ec2:DeleteVolume
  • elasticloadbalancing:DeleteTargetGroup
  • elasticloadbalancing:DescribeTargetGroups
  • iam:DeleteAccessKey
  • iam:DeleteUser
  • iam:ListAttachedRolePolicies
  • iam:ListInstanceProfiles
  • iam:ListRolePolicies
  • iam:ListUserPolicies
  • s3:DeleteObject
  • s3:ListBucketVersions
  • tag:GetResources

例5.10 ネットワークリソースの削除に必要なパーミッション

  • ec2:DeleteDhcpOptions
  • ec2:DeleteInternetGateway
  • ec2:DeleteNatGateway
  • ec2:DeleteRoute
  • ec2:DeleteRouteTable
  • ec2:DeleteSubnet
  • ec2:DeleteVpc
  • ec2:DeleteVpcEndpoints
  • ec2:DetachInternetGateway
  • ec2:DisassociateRouteTable
  • ec2:ReleaseAddress
  • ec2:ReplaceRouteTableAssociation
注記

既存の VPC を使用する場合、アカウントではネットワークリソースの削除にこれらのパーミッションを必要としません。代わりに、アカウントではネットワークリソースの削除に tag:UntagResources パーミッションのみが必要になります。

例5.11 共有インスタンスロールが割り当てられたクラスターを削除するために必要なパーミッション

  • iam:UntagRole

例5.12 マニフェストの作成に必要な追加の IAM および S3 パーミッション

  • iam:DeleteAccessKey
  • iam:DeleteUser
  • iam:DeleteUserPolicy
  • iam:GetUserPolicy
  • iam:ListAccessKeys
  • iam:PutUserPolicy
  • iam:TagUser
  • s3:PutBucketPublicAccessBlock
  • s3:GetBucketPublicAccessBlock
  • s3:PutLifecycleConfiguration
  • s3:HeadBucket
  • s3:ListBucketMultipartUploads
  • s3:AbortMultipartUpload
注記

クラウドプロバイダーのクレデンシャルをミントモードで管理している場合に、IAM ユーザーには iam:CreateAccessKeyiam:CreateUser 権限も必要です。

例5.13 インスタンスのオプションのパーミッションおよびインストールのクォータチェック

  • ec2:DescribeInstanceTypeOfferings
  • servicequotas:ListAWSDefaultServiceQuotas

5.2.4. IAM ユーザーの作成

各 Amazon Web Services (AWS) アカウントには、アカウントの作成に使用するメールアドレスに基づく root ユーザーアカウントが含まれます。これは高度な権限が付与されたアカウントであり、初期アカウントにのみ使用し、請求設定また初期のユーザーセットの作成およびアカウントのセキュリティー保護のために使用することが推奨されています。

OpenShift Container Platform をインストールする前に、セカンダリー IAM 管理ユーザーを作成します。AWS ドキュメントの Creating an IAM User in Your AWS Account 手順を実行する際に、以下のオプションを設定します。

手順

  1. IAM ユーザー名を指定し、Programmatic access を選択します。
  2. AdministratorAccess ポリシーを割り当て、アカウントにクラスターを作成するために十分なパーミッションがあることを確認します。このポリシーはクラスターに対し、各 OpenShift Container Platform コンポーネントに認証情報を付与する機能を提供します。クラスターはコンポーネントに対し、それらが必要とする認証情報のみを付与します。

    注記

    必要なすべての AWS パーミッションを付与し、これをユーザーに割り当てるポリシーを作成することは可能ですが、これは優先されるオプションではありません。クラスターには追加の認証情報を個別コンポーネントに付与する機能がないため、同じ認証情報がすべてのコンポーネントによって使用されます。

  3. オプション: タグを割り当て、メタデータをユーザーに追加します。
  4. 指定したユーザー名に AdministratorAccess ポリシーが付与されていることを確認します。
  5. アクセスキー ID およびシークレットアクセスキーの値を記録します。ローカルマシンをインストールプログラムを実行するように設定する際にこれらの値を使用する必要があります。

    重要

    クラスターのデプロイ時に、マルチファクター認証デバイスの使用中に生成した一時的なセッショントークンを使用して AWS に対する認証を行うことはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。

5.2.5. IAM ポリシーと AWS 認証

デフォルトでは、インストールプログラムは、ブートストラップ、コントロールプレーン、およびコンピュートインスタンスのインスタンスプロファイルを作成し、クラスターの動作に必要な権限を付与します。

ただし、独自の IAM ロールを作成して、インストールプロセスの一部として指定できます。クラスターをデプロイするため、またはインストール後にクラスターを管理するために、独自のロールを指定する必要がある場合があります。以下に例を示します。

  • 組織のセキュリティーポリシーでは、より制限的なアクセス許可セットを使用してクラスターをインストールする必要があります。
  • インストール後、クラスターは、追加サービスへのアクセスを必要とする Operator で設定されます。

独自の IAM ロールを指定する場合は、次の手順を実行できます。

  • デフォルトのポリシーから始めて、必要に応じて調整します。詳細については、「IAM インスタンスプロファイルのデフォルトのアクセス許可」を参照してください。
  • AWS IAM Access Analyzer (Identity and Access Management Access Analyzer) を使用して、クラスターのアクティビティーに基づくポリシーテンプレートを作成します。詳細は、「AWS IAM Analyzer を使用してポリシーテンプレートの作成」を参照してください。
5.2.5.1. IAM インスタンスプロファイルのデフォルトのアクセス許可

デフォルトでは、インストールプログラムは、ブートストラップ、コントロールプレーン、およびワーカーインスタンスの IAM インスタンスプロファイルを作成し、クラスターの動作に必要な権限を付与します。

次のリストでは、コントロールプレーンとコンピュートマシンのデフォルトのアクセス許可を指定します。

例5.14 コントロールプレーンインスタンスのプロファイル向けデフォルト IAM ロールのパーミッション

  • ec2:AttachVolume
  • ec2:AuthorizeSecurityGroupIngress
  • ec2:CreateSecurityGroup
  • ec2:CreateTags
  • ec2:CreateVolume
  • ec2:DeleteSecurityGroup
  • ec2:DeleteVolume
  • ec2:Describe*
  • ec2:DetachVolume
  • ec2:ModifyInstanceAttribute
  • ec2:ModifyVolume
  • ec2:RevokeSecurityGroupIngress
  • elasticloadbalancing:AddTags
  • elasticloadbalancing:AttachLoadBalancerToSubnets
  • elasticloadbalancing:ApplySecurityGroupsToLoadBalancer
  • elasticloadbalancing:CreateListener
  • elasticloadbalancing:CreateLoadBalancer
  • elasticloadbalancing:CreateLoadBalancerPolicy
  • elasticloadbalancing:CreateLoadBalancerListeners
  • elasticloadbalancing:CreateTargetGroup
  • elasticloadbalancing:ConfigureHealthCheck
  • elasticloadbalancing:DeleteListener
  • elasticloadbalancing:DeleteLoadBalancer
  • elasticloadbalancing:DeleteLoadBalancerListeners
  • elasticloadbalancing:DeleteTargetGroup
  • elasticloadbalancing:DeregisterInstancesFromLoadBalancer
  • elasticloadbalancing:DeregisterTargets
  • elasticloadbalancing:Describe*
  • elasticloadbalancing:DetachLoadBalancerFromSubnets
  • elasticloadbalancing:ModifyListener
  • elasticloadbalancing:ModifyLoadBalancerAttributes
  • elasticloadbalancing:ModifyTargetGroup
  • elasticloadbalancing:ModifyTargetGroupAttributes
  • elasticloadbalancing:RegisterInstancesWithLoadBalancer
  • elasticloadbalancing:RegisterTargets
  • elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer
  • elasticloadbalancing:SetLoadBalancerPoliciesOfListener
  • kms:DescribeKey

例5.15 コンピュートインスタンスプロファイル向けデフォルト IAM ロールのパーミッション

  • ec2:DescribeInstances
  • ec2:DescribeRegions
5.2.5.2. 既存の IAM ロールの指定

インストールプログラムがデフォルトのアクセス許可で IAM インスタンスプロファイルを作成できるようにする代わりに、install-config.yaml ファイルを使用して、コントロールプレーンとコンピュートインスタンスの既存の IAM ロールを指定できます。

前提条件

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

手順

  1. コントロールプレーンマシンの既存のロールで compute.platform.aws.iamRole を更新します。

    コンピュートインスタンスの IAM ロールを含む install-config.yaml ファイルのサンプル

    compute:
    - hyperthreading: Enabled
      name: worker
      platform:
        aws:
          iamRole: ExampleRole

  2. コンピュートマシンの既存のロールで controlPlane.platform.aws.iamRole を更新します。

    コントロールプレーンインスタンスの IAM ロールを含む install-config.yaml ファイルのサンプル

    controlPlane:
      hyperthreading: Enabled
      name: master
      platform:
        aws:
          iamRole: ExampleRole

  3. ファイルを保存し、OpenShift Container Platform クラスターのインストール時に参照します。
5.2.5.3. AWS IAM Analyzer を使用してポリシーテンプレートの作成

コントロールプレーンとコンピュートインスタンスプロファイルに必要な最小限のアクセス許可セットは、クラスターが日常の運用のためにどのように設定されているかによって異なります。

クラスターインスタンスに必要なアクセス許可を決定する 1 つの方法は、IAM Access Analyzer (AWS Identity and Access Management Access Analyzer) を使用してポリシーテンプレートを作成することです。

  • ポリシーテンプレートには、クラスターが指定された期間に使用したアクセス許可が含まれています。
  • その後、テンプレートを使用して、きめ細かい権限を持つポリシーを作成できます。

手順

全体的なプロセスは次のようになります。

  1. CloudTrail が有効になっていることを確認します。CloudTrail は、ポリシーテンプレートの作成に必要な API 呼び出しを含め、AWS アカウントのすべてのアクションとイベントを記録します。詳細は、CloudTrail の操作 に関する AWS ドキュメントを参照してください。
  2. コントロールプレーンインスタンスのインスタンスプロファイルとコンピューティングインスタンスのインスタンスプロファイルを作成します。PowerUserAccess などの寛容なポリシーを各ロールに割り当ててください。詳細は、インスタンスプロファイルロールの作成 に関する AWS ドキュメントを参照してください。
  3. クラスターを開発環境にインストールし、必要に応じて設定します。クラスターが本番環境でホストするすべてのアプリケーションを必ずデプロイしてください。
  4. クラスターを徹底的にテストします。クラスターをテストすると、必要なすべての API 呼び出しがログに記録されることが保証されます。
  5. IAM Access Analyzer を使用して、各インスタンスプロファイルのポリシーテンプレートを作成します。詳細は、CloudTrail ログに基づいてポリシーを生成する ための AWS ドキュメントを参照してください。
  6. きめ細かいポリシーを作成し、各インスタンスプロファイルに追加します。
  7. 各インスタンスプロファイルから許容ポリシーを削除します。
  8. 新しいポリシーで既存のインスタンスプロファイルを使用して実稼働クラスターをデプロイします。
注記

ポリシーに IAM 条件 を追加して、ポリシーをより制限し、組織のセキュリティー要件に準拠させることができます。

5.2.6. サポートされている AWS Marketplace リージョン

北米でオファーを購入したお客様は、AWS Marketplace イメージを使用して、OpenShift Container Platform クラスターをインストールすることができます。

このオファーは北米で購入する必要がありますが、以下のサポートされているパーティションのいずれかにクラスターをデプロイできます。

  • 公開
  • GovCloud
注記

AWS Marketplace イメージを使用した OpenShift Container Platform クラスターのデプロイは、AWS シークレットリージョンまたは中国リージョンではサポートされていません。

5.2.7. サポートされている AWS リージョン

OpenShift Container Platform クラスターを以下のリージョンにデプロイできます。

注記

ベースクラスターリソースを削除するには、IAM ユーザーが領域 us-east-1 にアクセス許可 tag:GetResources を持っている必要があります。AWS API 要件の一部として、OpenShift Container Platform インストールプログラムはこのリージョンでさまざまなアクションを実行します。

5.2.7.1. AWS パブリックリージョン

以下の AWS パブリックリージョンがサポートされます。

  • af-south-1 (Cape Town)
  • ap-east-1 (Hong Kong)
  • ap-northeast-1 (Tokyo)
  • ap-northeast-2 (Seoul)
  • ap-northeast-3 (Osaka)
  • ap-south-1 (Mumbai)
  • ap-south-2 (Hyderabad)
  • ap-southeast-1 (Singapore)
  • ap-southeast-2 (Sydney)
  • ap-southeast-3 (Jakarta)
  • ap-southeast-4 (Melbourne)
  • ca-central-1 (Central)
  • eu-central-1 (Frankfurt)
  • eu-central-2 (Zurich)
  • eu-north-1 (Stockholm)
  • eu-south-1 (Milan)
  • eu-south-2 (Spain)
  • eu-west-1 (Ireland)
  • eu-west-2 (London)
  • eu-west-3 (Paris)
  • me-central-1 (UAE)
  • me-south-1 (Bahrain)
  • sa-east-1 (São Paulo)
  • us-east-1 (N. Virginia)
  • us-east-2 (Ohio)
  • us-west-1 (N. California)
  • us-west-2 (Oregon)
5.2.7.2. AWS GovCloud リージョン

以下の AWS GovCloud リージョンがサポートされます。

  • us-gov-west-1
  • us-gov-east-1
5.2.7.3. AWS SC2S および C2S シークレットリージョン

以下の AWS シークレットリージョンがサポートされています。

  • us-isob-east-1 Secret Commercial Cloud Services (SC2S)
  • us-iso-east-1 Commercial Cloud Services (C2S)
5.2.7.4. AWS China リージョン

以下の AWS China リージョンがサポートされます。

  • cn-north-1 (Beijing)
  • cn-northwest-1 (Ningxia)

5.2.8. 次のステップ

5.3. AWS の IAM の手動作成

クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境や、管理者がクラスター kube-system namespace に管理者レベルの認証情報シークレットを保存する選択をしない場合に、クラスターのインストール前に Cloud Credential Operator (CCO) を手動モードにすることができます。

5.3.1. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法

Cloud Credential Operator (CCO) は、クラウドプロバイダーの認証情報を Kubernetes カスタムリソース定義 (CRD) として管理します。credentialsMode パラメーターの異なる値を install-config.yaml ファイルに設定し、組織のセキュリティー要件に応じて CCO を設定できます。

管理者レベルの認証情報シークレットをクラスターの kube-system プロジェクトに保存する選択をしない場合、OpenShift Container Platform をインストールする際に以下のいずれかのオプションを選択できます。

  • Amazon Web Services Security Token Service:

    CCO ユーティリティー (ccoctl) を使用して、Amazon Web Services Security Token Service (AWS STS) を設定できるようになりました。CCO ユーティリティーを使用して STS のクラスターを設定する場合、短期の権限に制限のあるセキュリティー認証情報を提供する IAM ロールをコンポーネントに割り当てます。

    注記

    このクレデンシャルストラテジーは、新しい OpenShift Container Platform クラスターでのみサポートされており、インストール中に設定する必要があります。この機能を使用するために、既存のクラスターが別のクレデンシャルストラテジーを使用するように再設定することはできません。

  • クラウド認証情報を手動で管理 します。

    CCO の credentialsMode パラメーターを Manual に設定し、クラウド認証情報を手動で管理できます。手動モードを使用すると、クラスターに管理者レベルの認証情報を保存する必要なく、各クラスターコンポーネントに必要なパーミッションのみを指定できます。お使いの環境でクラウドプロバイダーのパブリック IAM エンドポイントへの接続がない場合も、このモードを使用できます。ただし、各アップグレードについて、パーミッションを新規リリースイメージを使用して手動で調整する必要があります。また、それらを要求するすべてのコンポーネントについて認証情報を手動で指定する必要があります。

  • OpenShift Container Platform を mint モードでインストールした後に、管理者レベルの認証情報シークレットを削除 します。

    credentialsMode パラメーターが Mint に設定された状態で CCO を使用している場合、OpenShift Container Platform のインストール後に管理者レベルの認証情報を削除したり、ローテーションしたりできます。Mint モードは、CCO のデフォルト設定です。このオプションには、インストール時に管理者レベルの認証情報が必要になります。管理者レベルの認証情報はインストール時に、付与された一部のパーミッションと共に他の認証情報を生成するために使用されます。元の認証情報シークレットはクラスターに永続的に保存されません。

注記

z-stream 以外のアップグレードの前に、認証情報のシークレットを管理者レベルの認証情報と共に元に戻す必要があります。認証情報が存在しない場合は、アップグレードがブロックされる可能性があります。

5.3.2. IAM の手動作成

Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system namespace に管理者レベルの認証情報シークレットを保存しないようにします。

手順

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

    $ openshift-install create install-config --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  2. install-config.yaml 設定ファイルを編集し、credentialsMode パラメーターが Manual に設定されるようにします。

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

    apiVersion: v1
    baseDomain: cluster1.example.com
    credentialsMode: Manual 
    1
    
    compute:
    - architecture: amd64
      hyperthreading: Enabled
    ...

    1
    この行は、credentialsMode パラメーターを Manual に設定するために追加されます。
  3. インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。

    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  4. インストールプログラムが含まれるディレクトリーから、以下のコマンドを実行して、openshift-install バイナリーがビルドされている OpenShift Container Platform リリースイメージの詳細を取得します。

    $ openshift-install version

    出力例

    release image quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64

  5. 以下のコマンドを実行して、デプロイするクラウドをターゲットとするリリースイメージですべての CredentialsRequest オブジェクトを見つけます。

    $ oc adm release extract quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64 \
      --credentials-requests \
      --cloud=aws

    このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component-credentials-request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - iam:GetUser
          - iam:GetUserPolicy
          - iam:ListAccessKeys
          resource: "*"
      ...

  6. 以前に生成した openshift-install マニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、それぞれの CredentialsRequest オブジェクトについて spec.secretRef に定義される namespace およびシークレット名を使用して保存する必要があります。

    シークレットを含む CredentialsRequest オブジェクトのサンプル

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component-credentials-request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - s3:CreateBucket
          - s3:DeleteBucket
          resource: "*"
          ...
      secretRef:
        name: <component-secret>
        namespace: <component-namespace>
      ...

    サンプル Secret オブジェクト

    apiVersion: v1
    kind: Secret
    metadata:
      name: <component-secret>
      namespace: <component-namespace>
    data:
      aws_access_key_id: <base64_encoded_aws_access_key_id>
      aws_secret_access_key: <base64_encoded_aws_secret_access_key>

    重要

    リリースイメージには、TechPreviewNoUpgrade 機能セットによって有効になるテクノロジープレビュー機能の CredentialsRequest オブジェクトが含まれています。これらのオブジェクトは、release.openshift.io/feature-gate: TechPreviewNoUpgrade アノテーションを使用して識別できます。

    • これらの機能を使用していない場合は、これらのオブジェクトのシークレットを作成しないでください。使用していないテクノロジープレビュー機能のシークレットを作成すると、インストールが失敗する可能性があります。
    • これらの機能のいずれかを使用している場合は、対応するオブジェクトのシークレットを作成する必要があります。
    • TechPreviewNoUpgrade アノテーションを持つ CredentialsRequest オブジェクトを見つけるには、次のコマンドを実行します。

      $ grep "release.openshift.io/feature-gate" *

      出力例

      0000_30_capi-operator_00_credentials-request.yaml:  release.openshift.io/feature-gate: TechPreviewNoUpgrade

  7. インストールプログラムが含まれるディレクトリーから、クラスターの作成に進みます。

    $ openshift-install create cluster --dir <installation_directory>
    重要

    手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。

5.3.3. mint モード

mint モードは、OpenShift Container Platform をサポートするプラットフォーム上の OpenShift Container Platform のデフォルトの Cloud Credential Operator (CCO) クレデンシャルモードです。このモードでは、CCO は提供される管理者レベルのクラウド認証情報を使用してクラスターを実行します。Mint モードは AWS と GCP でサポートされています。

mint モードでは、admin 認証情報は kube-system namespace に保存され、次に CCO によってクラスターの CredentialsRequest オブジェクトを処理し、特定のパーミッションでそれぞれのユーザーを作成するために使用されます。

mint モードには以下の利点があります。

  • 各クラスターコンポーネントにはそれぞれが必要なパーミッションのみがあります。
  • クラウド認証情報の自動の継続的な調整が行われます。これには、アップグレードに必要になる可能性のある追加の認証情報またはパーミッションが含まれます。

1 つの不利な点として、mint モードでは、admin 認証情報がクラスターの kube-system シークレットに保存される必要があります。

5.3.4. 管理者レベルの認証情報の削除またはローテーション機能を持つ mint モード

現時点で、このモードは AWS および GCP でのみサポートされます。

このモードでは、ユーザーは通常の mint モードと同様に管理者レベルの認証情報を使用して OpenShift Container Platform をインストールします。ただし、このプロセスはクラスターのインストール後の管理者レベルの認証情報シークレットを削除します。

管理者は、Cloud Credential Operator に読み取り専用の認証情報について独自の要求を行わせることができます。これにより、すべての CredentialsRequest オブジェクトに必要なパーミッションがあることの確認が可能になります。そのため、いずれかの変更が必要にならない限り、管理者レベルの認証情報は必要になりません。関連付けられた認証情報が削除された後に、必要な場合は、これは基礎となるクラウドで破棄するか、非アクティブにできます。

注記

z-stream 以外のアップグレードの前に、認証情報のシークレットを管理者レベルの認証情報と共に元に戻す必要があります。認証情報が存在しない場合は、アップグレードがブロックされる可能性があります。

管理者レベルの認証情報はクラスターに永続的に保存されません。

これらの手順を実行するには、短い期間にクラスターでの管理者レベルの認証情報が必要になります。また、アップグレードごとに管理者レベルの認証情報を使用してシークレットを手動で再インストールする必要があります。

5.3.5. 次のステップ

5.4. クラスターの AWS へのクイックインストール

OpenShift Container Platform バージョン 4.11 では、デフォルトの設定オプションを使用する Amazon Web Services (AWS) にクラスターをインストールできます。

5.4.1. 前提条件

  • OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
  • クラスターインストール方法の選択およびそのユーザー向けの準備 のドキュメント内容を確認している。
  • クラスターをホストするために AWS アカウントを設定 している。

    重要

    AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。

  • ファイアウォールを使用する場合は、クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 する必要がある。
  • お使いの環境でクラウドアイデンティティーおよびアクセス管理 (IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを kube-system namespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 することができる。手動モードは、クラウド IAM API に到達できない環境でも使用できます。

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

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

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

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

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

5.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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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 パブリックキーをインストールプログラムに指定します。

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

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

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

重要

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

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定します。
  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。

手順

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

    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

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

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

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

      注記

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

    2. ターゲットに設定するプラットフォームとして aws を選択します。
    3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。

      注記

      AWS アクセスキー ID およびシークレットアクセスキーは、インストールホストの現行ユーザーのホームディレクトリーの ~/.aws/credentials に保存されます。エクスポートされたプロファイルの認証情報がファイルにない場合は、インストールプログラムにより認証情報の入力が求めるプロンプトが出されます。インストールプログラムに指定する認証情報は、ファイルに保存されます。

    4. クラスターのデプロイ先とする AWS リージョンを選択します。
    5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
    6. クラスターの記述名を入力します。
    7. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
    注記

    ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。

  3. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、または無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

5.4.6. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

5.4.8. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

5.4.9. OpenShift Container Platform の Telemetry アクセス

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

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

5.4.10. 次のステップ

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

OpenShift Container Platform バージョン 4.11 では、インストールプログラムが Amazon Web Services (AWS) でプロビジョニングするインフラストラクチャーにカスタマイズされたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

注記

OpenShift Container Platform インストール設定のスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後にさらに多くの OpenShift Container Platform 設定タスクを実行することができます。

5.5.1. 前提条件

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

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

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

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

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

5.5.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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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 パブリックキーをインストールプログラムに指定します。

5.5.4. AWS Marketplace イメージの取得

AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがワーカーノードのデプロイに使用する AMI ID が提供されます。

前提条件

  • オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。

手順

  1. AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
  2. 使用する特定のリージョンの AMI ID を記録します。インストールプロセスの一環として、クラスターをデプロイする前に、この値で install-config.yaml ファイルを更新する必要があります。

AWS Marketplace ワーカーノードを含む install-config.yaml ファイルのサンプル

apiVersion: v1
baseDomain: example.com
compute:
- hyperthreading: Enabled
  name: worker
  platform:
    aws:
      amiID: ami-06c4d345f7c207239 
1

      type: m5.4xlarge
  replicas: 3
metadata:
  name: test-cluster
platform:
  aws:
    region: us-east-2 
2

sshKey: ssh-ed25519 AAAA...
pullSecret: '{"auths": ...}'

1
AWS Marketplace サブスクリプションの AMI ID。
2
AMI ID は特定の AWS リージョンに関連付けられています。インストール設定ファイルを作成するときは、サブスクリプションの設定時に指定したものと同じ AWS リージョンを選択してください。

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

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

Amazon Web Services (AWS) での 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 からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

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

        注記

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

      2. ターゲットに設定するプラットフォームとして AWS を選択します。
      3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
      7. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、インストール設定パラメーターのセクションを参照してください。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

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

5.5.6.1. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

5.5.6.1.1. 必須設定パラメーター

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

Expand
表5.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

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}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"
      }
   }
}
5.5.6.1.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

Expand
表5.2 ネットワークパラメーター
パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

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 です。

OpenShift SDN および 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 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

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

例: 10.0.0.0/16

注記

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

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

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

Expand
表5.3 オプションのパラメーター
パラメーター説明

additionalTrustBundle

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

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

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

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

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

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

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

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

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

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 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

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

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

imageContentSources.source

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

文字列

imageContentSources.mirrors

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

文字列の配列。

publish

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

Internal または External。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。

sshKey

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

注記

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

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

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

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

Expand
表5.4 オプションの AWS パラメーター
パラメーター説明

compute.platform.aws.amiID

クラスターのコンピュートマシンの起動に使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

compute.platform.aws.iamRole

コンピュートマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

compute.platform.aws.rootVolume.iops

ルートボリュームに予約される 1 秒あたりの入出力操作 (IOPS)。

整数 (例: 4000)。

compute.platform.aws.rootVolume.size

ルートボリュームのサイズ (GiB)。

整数 (例: 500)。

compute.platform.aws.rootVolume.type

root ボリュームのタイプです。

有効な AWS EBS ボリュームタイプ (例: io1)。

compute.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、ワーカーノードの OS ボリュームを特定の KMS キーで暗号化するために必要です。

有効な キー ID またはキー ARN

compute.platform.aws.type

コンピュートマシンの EC2 インスタンスタイプ。

有効な AWS インスタンスタイプ (例: m4.2xlarge)。次の サポートされている AWS マシンタイプの 表を参照してください。

compute.platform.aws.zones

インストールプログラムがコンピュートマシンプールのマシンを作成するアベイラビリティーゾーン。独自の VPC を指定する場合は、そのアベイラビリティーゾーンにサブネットを指定する必要があります。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

compute.aws.region

インストールプログラムがコンピュートリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。AWS CLI を使用して、選択したインスタンスタイプに基づいて利用可能なリージョンにアクセスできます。以下に例を示します。

aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=c7g.xlarge
重要

ARM ベースの AWS インスタンスで実行する場合は、AWS Graviton プロセッサーが利用可能なリージョンを入力するようにしてください。AWS ドキュメントの グローバルアベイラビリティー マップを参照してください。現在、AWS Graviton3 プロセッサーは一部のリージョンでのみ利用できます。

controlPlane.platform.aws.amiID

クラスターのコントロールプレーンマシンを起動するために使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

controlPlane.platform.aws.iamRole

コントロールプレーンマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

controlPlane.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、特定の KMS キーを使用してコントロールプレーンノードの OS ボリュームを暗号化するために必要です。

有効な キー ID とキー ARN

controlPlane.platform.aws.type

コントロールプレーンマシンの EC2 インスタンスタイプ。

m6i.xlarge などの有効な AWS インスタンスタイプ。次の サポートされている AWS マシンタイプの 表を参照してください。

controlPlane.platform.aws.zones

インストールプログラムがコントロールプレーンマシンプールのマシンを作成するアベイラビリティーゾーン。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

controlPlane.aws.region

インストールプログラムがコントロールプレーンのリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。

platform.aws.amiID

クラスターのすべてのマシンを起動するために使用される AWS AMI。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

platform.aws.hostedZone

クラスターの既存の Route 53 プライベートホストゾーン。独自の VPC を指定する場合も、既存のホストゾーンのみを使用できます。ホストゾーンは、インストール前にユーザーによって提供される VPC に関連付けられている必要があります。また、ホストゾーンのドメインはクラスタードメインまたはクラスタードメインの親である必要があります。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。

文字列 (例: Z3URY6TWQ91KVV)

platform.aws.serviceEndpoints.name

AWS サービスエンドポイント名。カスタムエンドポイントは、FIPS などの AWS の代替エンドポイントを使用しなければならない場合にのみ必要です。カスタム API エンドポイントは、EC2、S3、IAM、Elastic Load Balancing、Tagging、Route 53、および STS AWS サービスに指定できます。

有効な AWS サービスエンドポイント 名。

platform.aws.serviceEndpoints.url

AWS サービスエンドポイント URL。URL には https プロトコルを使用し、ホストは証明書を信頼する必要があります。

有効な AWS サービスエンドポイント URL。

platform.aws.userTags

インストールプログラムが、作成するすべてのリソースに対するタグとして追加するキーと値のマップ。

<key>: <value> 形式のキー値ペアなどの有効な YAML マップ。AWS タグについての詳細は、AWS ドキュメントの Tagging Your Amazon EC2 Resources を参照してください。

platform.aws.subnets

インストールプログラムによる VPC の作成を許可する代わりに VPC を指定する場合は、使用するクラスターのサブネットを指定します。サブネットは、指定する同じ machineNetwork[].cidr 範囲の一部である必要があります。標準クラスターの場合は、各アベイラビリティーゾーンのパブリックおよびプライベートサブネットを指定します。プライベートクラスターについては、各アベイラビリティーゾーンのプライベートサブネットを指定します。

有効なサブネット ID。

5.5.6.2. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

Expand
表5.5 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージIOPS [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. ユーザーによってプロビジョニングされるすべてのインストールと同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

5.5.6.3. AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services(AWS)インスタンスタイプは OpenShift Container Platform でテストされています。

注記

以下のチャートに含まれるマシンタイプを AWS インスタンスに使用します。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。

例5.16 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*
5.5.6.4. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services (AWS) ARM64 インスタンスタイプは OpenShift Container Platform でテストされています。

注記

AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。

例5.17 64 ビット ARM アーキテクチャーに基づくマシンタイプ

  • c6g.*
  • m6g.*
5.5.6.5. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。

apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 
13

    userTags:
      adminContact: jdoe
      costCenter: 7536
    amiID: ami-96c6f8f7 
14

    serviceEndpoints: 
15

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
fips: false 
16

sshKey: ssh-ed25519 AAAA... 
17

pullSecret: '{"auths": ...}' 
18
1 12 13 18
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2
オプション: このパラメーターを追加して、Cloud Credential Operator (CCO) に認証情報の機能を動的に判別させようとするのではなく、CCO が指定されたモードを使用するように強制します。CCO モードの詳細は、Red Hat Operatorクラウド認証情報 Operatorを参照してください。
3 8
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、 compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して m4.2xlarge または m5.2xlarge などの大規模なインスタンスタイプを使用します。

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、マシンセットを使用して変更できます。

14
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
15
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
16
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。プロセス暗号化ライブラリーでの FIPS 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

17
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

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

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

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<region>.amazonaws.com,elasticloadbalancing.<region>.amazonaws.com,s3.<region>.amazonaws.com 
    3
    
    additionalTrustBundle: | 
    4
    
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic Load Balancing、および S3 VPC エンドポイントを VPC に追加した場合は、これらのエンドポイントを noProxy フィールドに追加する必要があります。
    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 信頼バンドルからの認証局によって署名されない限り必要になります。
    注記

    インストールプログラムは、プロキシーの 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 オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

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

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

重要

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

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定します。
  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。

手順

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

    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。

  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、または無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

5.5.8. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

5.5.10. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

5.5.11. OpenShift Container Platform の Telemetry アクセス

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

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

5.5.12. 次のステップ

5.6. ネットワークのカスタマイズによる AWS へのクラスターのインストール

OpenShift Container Platform バージョン 4.11 では、カスタマイズされたネットワーク設定オプションを使用して、Amazon Web Services (AWS) にクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。

大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy 設定パラメーターのみになります。

5.6.1. 前提条件

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

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

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

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

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

5.6.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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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 パブリックキーをインストールプログラムに指定します。

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

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

5.6.5. ネットワーク設定フェーズ

OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。

フェーズ 1

マニフェストファイルを作成する前に、install-config.yaml ファイルで以下のネットワーク関連のフィールドをカスタマイズできます。

  • networking.networkType
  • networking.clusterNetwork
  • networking.serviceNetwork
  • networking.machineNetwork

    これらのフィールドの詳細は、インストール設定パラメーター を参照してください。

    注記

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

    重要

    CIDR 範囲 172.17.0.0/16 は libVirt によって予約されています。この範囲、またはこの範囲と重複する範囲をクラスター内のネットワークに使用することはできません。

フェーズ 2
openshift-install create manifests を実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。

フェーズ 2 で、install-config.yaml ファイルのフェーズ 1 で指定した値を上書きすることはできません。ただし、フェーズ 2 ではクラスターネットワークプロバイダーをさらにカスタマイズできます。

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

Amazon Web Services (AWS) での 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 からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

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

        注記

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

      2. ターゲットに設定するプラットフォームとして AWS を選択します。
      3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
      7. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、インストール設定パラメーターのセクションを参照してください。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

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

5.6.6.1. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

5.6.6.1.1. 必須設定パラメーター

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

Expand
表5.6 必須パラメーター
パラメーター説明

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

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}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"
      }
   }
}
5.6.6.1.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

Expand
表5.7 ネットワークパラメーター
パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

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 です。

OpenShift SDN および 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 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

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

例: 10.0.0.0/16

注記

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

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

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

Expand
表5.8 オプションのパラメーター
パラメーター説明

additionalTrustBundle

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

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

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

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

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

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

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

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

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

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 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

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

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

imageContentSources.source

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

文字列

imageContentSources.mirrors

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

文字列の配列。

publish

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

Internal または External。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。

sshKey

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

注記

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

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

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

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

Expand
表5.9 オプションの AWS パラメーター
パラメーター説明

compute.platform.aws.amiID

クラスターのコンピュートマシンの起動に使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

compute.platform.aws.iamRole

コンピュートマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

compute.platform.aws.rootVolume.iops

ルートボリュームに予約される 1 秒あたりの入出力操作 (IOPS)。

整数 (例: 4000)。

compute.platform.aws.rootVolume.size

ルートボリュームのサイズ (GiB)。

整数 (例: 500)。

compute.platform.aws.rootVolume.type

root ボリュームのタイプです。

有効な AWS EBS ボリュームタイプ (例: io1)。

compute.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、ワーカーノードの OS ボリュームを特定の KMS キーで暗号化するために必要です。

有効な キー ID またはキー ARN

compute.platform.aws.type

コンピュートマシンの EC2 インスタンスタイプ。

有効な AWS インスタンスタイプ (例: m4.2xlarge)。次の サポートされている AWS マシンタイプの 表を参照してください。

compute.platform.aws.zones

インストールプログラムがコンピュートマシンプールのマシンを作成するアベイラビリティーゾーン。独自の VPC を指定する場合は、そのアベイラビリティーゾーンにサブネットを指定する必要があります。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

compute.aws.region

インストールプログラムがコンピュートリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。AWS CLI を使用して、選択したインスタンスタイプに基づいて利用可能なリージョンにアクセスできます。以下に例を示します。

aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=c7g.xlarge
重要

ARM ベースの AWS インスタンスで実行する場合は、AWS Graviton プロセッサーが利用可能なリージョンを入力するようにしてください。AWS ドキュメントの グローバルアベイラビリティー マップを参照してください。現在、AWS Graviton3 プロセッサーは一部のリージョンでのみ利用できます。

controlPlane.platform.aws.amiID

クラスターのコントロールプレーンマシンを起動するために使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

controlPlane.platform.aws.iamRole

コントロールプレーンマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

controlPlane.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、特定の KMS キーを使用してコントロールプレーンノードの OS ボリュームを暗号化するために必要です。

有効な キー ID とキー ARN

controlPlane.platform.aws.type

コントロールプレーンマシンの EC2 インスタンスタイプ。

m6i.xlarge などの有効な AWS インスタンスタイプ。次の サポートされている AWS マシンタイプの 表を参照してください。

controlPlane.platform.aws.zones

インストールプログラムがコントロールプレーンマシンプールのマシンを作成するアベイラビリティーゾーン。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

controlPlane.aws.region

インストールプログラムがコントロールプレーンのリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。

platform.aws.amiID

クラスターのすべてのマシンを起動するために使用される AWS AMI。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

platform.aws.hostedZone

クラスターの既存の Route 53 プライベートホストゾーン。独自の VPC を指定する場合も、既存のホストゾーンのみを使用できます。ホストゾーンは、インストール前にユーザーによって提供される VPC に関連付けられている必要があります。また、ホストゾーンのドメインはクラスタードメインまたはクラスタードメインの親である必要があります。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。

文字列 (例: Z3URY6TWQ91KVV)

platform.aws.serviceEndpoints.name

AWS サービスエンドポイント名。カスタムエンドポイントは、FIPS などの AWS の代替エンドポイントを使用しなければならない場合にのみ必要です。カスタム API エンドポイントは、EC2、S3、IAM、Elastic Load Balancing、Tagging、Route 53、および STS AWS サービスに指定できます。

有効な AWS サービスエンドポイント 名。

platform.aws.serviceEndpoints.url

AWS サービスエンドポイント URL。URL には https プロトコルを使用し、ホストは証明書を信頼する必要があります。

有効な AWS サービスエンドポイント URL。

platform.aws.userTags

インストールプログラムが、作成するすべてのリソースに対するタグとして追加するキーと値のマップ。

<key>: <value> 形式のキー値ペアなどの有効な YAML マップ。AWS タグについての詳細は、AWS ドキュメントの Tagging Your Amazon EC2 Resources を参照してください。

platform.aws.subnets

インストールプログラムによる VPC の作成を許可する代わりに VPC を指定する場合は、使用するクラスターのサブネットを指定します。サブネットは、指定する同じ machineNetwork[].cidr 範囲の一部である必要があります。標準クラスターの場合は、各アベイラビリティーゾーンのパブリックおよびプライベートサブネットを指定します。プライベートクラスターについては、各アベイラビリティーゾーンのプライベートサブネットを指定します。

有効なサブネット ID。

5.6.6.2. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

Expand
表5.10 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージIOPS [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. ユーザーによってプロビジョニングされるすべてのインストールと同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

5.6.6.3. AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services(AWS)インスタンスタイプは OpenShift Container Platform でテストされています。

注記

以下のチャートに含まれるマシンタイプを AWS インスタンスに使用します。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。

例5.18 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*
5.6.6.4. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services (AWS) ARM64 インスタンスタイプは OpenShift Container Platform でテストされています。

注記

AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。

例5.19 64 ビット ARM アーキテクチャーに基づくマシンタイプ

  • c6g.*
  • m6g.*
5.6.6.5. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。

apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 
12

networking: 
13

  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 
14

    userTags:
      adminContact: jdoe
      costCenter: 7536
    amiID: ami-96c6f8f7 
15

    serviceEndpoints: 
16

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
fips: false 
17

sshKey: ssh-ed25519 AAAA... 
18

pullSecret: '{"auths": ...}' 
19
1 12 14 19
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2
オプション: このパラメーターを追加して、Cloud Credential Operator (CCO) に認証情報の機能を動的に判別させようとするのではなく、CCO が指定されたモードを使用するように強制します。CCO モードの詳細は、Red Hat Operatorクラウド認証情報 Operatorを参照してください。
3 8 13
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、 compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して m4.2xlarge または m5.2xlarge などの大規模なインスタンスタイプを使用します。

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、マシンセットを使用して変更できます。

15
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
16
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
17
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。プロセス暗号化ライブラリーでの FIPS 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

18
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

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

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

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<region>.amazonaws.com,elasticloadbalancing.<region>.amazonaws.com,s3.<region>.amazonaws.com 
    3
    
    additionalTrustBundle: | 
    4
    
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic Load Balancing、および S3 VPC エンドポイントを VPC に追加した場合は、これらのエンドポイントを noProxy フィールドに追加する必要があります。
    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 信頼バンドルからの認証局によって署名されない限り必要になります。
    注記

    インストールプログラムは、プロキシーの 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 オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

5.6.7. Cluster Network Operator (CNO) の設定

クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io API グループの Network API のフィールドを指定します。

CNO 設定は、Network.config.openshift.io API グループの Network API からクラスターのインストール時に以下のフィールドを継承し、これらのフィールドは変更できません。

clusterNetwork
Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
サービスの IP アドレスプール。
defaultNetwork.type
OpenShift SDN または OVN-Kubernetes などのクラスターネットワークプロバイダー。

defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプロバイダー設定を指定できます。

5.6.7.1. Cluster Network Operator 設定オブジェクト

Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。

Expand
表5.11 Cluster Network Operator 設定オブジェクト
フィールド説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes Container Network Interface (CNI) ネットワークプロバイダーは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。

spec:
  serviceNetwork:
  - 172.30.0.0/14

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.defaultNetwork

object

クラスターネットワークの Container Network Interface (CNI) ネットワークプロバイダーを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプロバイダーを使用している場合、kube-proxy 設定は機能しません。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

Expand
表5.12 defaultNetwork オブジェクト
フィールド説明

type

string

OpenShiftSDN または OVNKubernetes のいずれか。クラスターネットワークプロバイダーはインストール時に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform はデフォルトで、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーを使用します。

openshiftSDNConfig

object

このオブジェクトは OpenShift SDN クラスターネットワークプロバイダーにのみ有効です。

ovnKubernetesConfig

object

このオブジェクトは OVN-Kubernetes クラスターネットワークプロバイダーにのみ有効です。

OpenShift SDN CNI クラスターネットワークプロバイダーの設定

以下の表は、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーの設定フィールドについて説明しています。

Expand
表5.13 openshiftSDNConfig オブジェクト
フィールド説明

mode

string

OpenShift SDN のネットワーク分離モードを設定します。デフォルト値は NetworkPolicy です。

Multitenant および Subnet の値は、OpenShift Container Platform 3.x との後方互換性を維持するために利用できますが、その使用は推奨されていません。この値は、クラスターのインストール後は変更できません。

mtu

integer

VXLAN オーバーレイネットワークの最大転送単位 (MTU)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 50 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1450 に設定する必要があります。

この値は、クラスターのインストール後は変更できません。

vxlanPort

integer

すべての VXLAN パケットに使用するポート。デフォルト値は 4789 です。この値は、クラスターのインストール後は変更できません。

別の VXLAN ネットワークの一部である既存ノードと共に仮想化環境で実行している場合は、これを変更する必要がある可能性があります。たとえば、OpenShift SDN オーバーレイを VMware NSX-T 上で実行する場合は、両方の SDN が同じデフォルトの VXLAN ポート番号を使用するため、VXLAN の別のポートを選択する必要があります。

Amazon Web Services (AWS) では、VXLAN にポート 9000 とポート 9999 間の代替ポートを選択できます。

OpenShift SDN 設定の例

defaultNetwork:
  type: OpenShiftSDN
  openshiftSDNConfig:
    mode: NetworkPolicy
    mtu: 1450
    vxlanPort: 4789

OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定

以下の表は OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定フィールドについて説明しています。

Expand
表5.14 ovnKubernetesConfig object
フィールド説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 100 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

genevePort

integer

すべての Geneve パケットに使用するポート。デフォルト値は 6081 です。この値は、クラスターのインストール後は変更できません。

ipsecConfig

object

IPsec 暗号化を有効にするために空のオブジェクトを指定します。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。

注記

egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

Expand
表5.15 policyAuditConfig オブジェクト
フィールド説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

destination

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

Expand
表5.16 gatewayConfig オブジェクト
フィールド説明

routingViaHost

boolean

Pod からホストネットワークスタックへの egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを true に設定すると、egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

IPsec が有効な OVN-Kubernetes 設定の例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig: {}

kubeProxyConfig オブジェクト設定

kubeProxyConfig オブジェクトの値は以下の表で定義されます。

Expand
表5.17 kubeProxyConfig オブジェクト
フィールド説明

iptablesSyncPeriod

string

iptables ルールの更新期間。デフォルト値は 30s です。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ ドキュメントで説明されています。

注記

OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。

proxyArguments.iptables-min-sync-period

array

iptables ルールを更新する前の最小期間。このフィールドにより、更新の頻度が高くなり過ぎないようにできます。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ で説明されています。デフォルト値:

kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

5.6.8. 高度なネットワーク設定の指定

クラスターネットワークプロバイダーに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。

重要

インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。

前提条件

  • install-config.yaml ファイルを作成し、これに対する変更を完了している。

手順

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

    $ ./openshift-install create manifests --dir <installation_directory> 
    1
    1
    <installation_directory> は、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
  3. 以下の例のように、cluster-network-03-config.yml ファイルで、クラスターの高度なネットワーク設定を指定します。

    OpenShift SDN ネットワークプロバイダーに異なる VXLAN ポートを指定します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        openshiftSDNConfig:
          vxlanPort: 4800

    OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にします。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          ipsecConfig: {}

  4. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時に manifests/ ディレクトリーを使用します。
注記

AWS で Network Load Balancer (NLB) を使用する方法についての詳細は、ネットワークロードバランサーを使用した AWS での ingress クラスタートラフィックの設定 を参照してください。

5.6.9. 新規 AWS クラスターでの Ingress コントローラーネットワークロードバランサーの設定

新規クラスターに AWS Network Load Balancer (NLB) がサポートする Ingress Controller を作成できます。

前提条件

  • install-config.yaml ファイルを作成し、これに対する変更を完了します。

手順

新規クラスターの AWS NLB がサポートする Ingress Controller を作成します。

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

    $ ./openshift-install create manifests --dir <installation_directory> 
    1
    1
    <installation_directory> については、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-ingress-default-ingresscontroller.yaml という名前のファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    $ touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml 
    1
    1
    <installation_directory> については、クラスターの manifests/ ディレクトリーが含まれるディレクトリー名を指定します。

    ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが manifests/ ディレクトリーに置かれます。

    $ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml

    出力例

    cluster-ingress-default-ingresscontroller.yaml

  3. エディターで cluster-ingress-default-ingresscontroller.yaml ファイルを開き、必要な Operator 設定を記述するカスタムリソース (CR) を入力します。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: null
      name: default
      namespace: openshift-ingress-operator
    spec:
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
        type: LoadBalancerService
  4. cluster-ingress-default-ingresscontroller.yaml ファイルを保存し、テキストエディターを終了します。
  5. オプション: manifests/cluster-ingress-default-ingresscontroller.yaml ファイルをバックアップします。インストールプログラムは、クラスターの作成時に manifests/ ディレクトリーを削除します。

5.6.10. OVN-Kubernetes を使用したハイブリッドネットワークの設定

OVN-Kubernetes でハイブリッドネットワークを使用するようにクラスターを設定できます。これにより、異なるノードのネットワーク設定をサポートするハイブリッドクラスターが可能になります。たとえば、これはクラスター内の Linux ノードと Windows ノードの両方を実行するために必要です。

重要

クラスターのインストール時に、OVN-Kubernetes を使用してハイブリッドネットワークを設定する必要があります。インストールプロセス後に、ハイブリッドネットワークに切り替えることはできません。

前提条件

  • install-config.yaml ファイルで networking.networkType パラメーターの OVNKubernetes を定義していること。詳細は、選択したクラウドプロバイダーでの OpenShift Container Platform ネットワークのカスタマイズの設定についてのインストールドキュメントを参照してください。

手順

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

    $ ./openshift-install create manifests --dir <installation_directory>

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    $ cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml
    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
    EOF

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの manifests/ ディレクトリーが含まれるディレクトリー名を指定します。
  3. cluster-network-03-config.yml ファイルをエディターで開き、以下の例のようにハイブリッドネットワークで OVN-Kubernetes を設定します。

    ハイブリッドネットワーク設定の指定

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          hybridOverlayConfig:
            hybridClusterNetwork: 
    1
    
            - cidr: 10.132.0.0/14
              hostPrefix: 23
            hybridOverlayVXLANPort: 9898 
    2

    1
    追加のオーバーレイネットワーク上のノードに使用される CIDR 設定を指定します。hybridClusterNetwork CIDR は clusterNetwork CIDR と重複できません。
    2
    追加のオーバーレイネットワークのカスタム VXLAN ポートを指定します。これは、vSphere にインストールされたクラスターで Windows ノードを実行するために必要であり、その他のクラウドプロバイダー用に設定することはできません。カスタムポートには、デフォルトの 4789 ポートを除くいずれかのオープンポートを使用できます。この要件についての詳細は、Microsoft ドキュメントの Pod-to-pod connectivity between hosts is broken を参照してください。
    注記

    Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019 は、カスタムの VXLAN ポートの選択をサポートしないため、カスタムの hybridOverlayVXLANPort 値を持つクラスターではサポートされません。

  4. cluster-network-03-config.yml ファイルを保存し、テキストエディターを終了します。
  5. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、クラスターの作成時に manifests/ ディレクトリーを削除します。
注記

同じクラスターで Linux および Windows ノードを使用する方法についての詳細は、Understanding Windows container workloads を参照してください。

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

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

重要

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

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定します。
  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。

手順

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

    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。

  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、または無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

5.6.12. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

5.6.14. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

5.6.15. OpenShift Container Platform の Telemetry アクセス

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

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

5.6.16. 次のステップ

5.7. ネットワークが制限された環境での AWS へのクラスターのインストール

OpenShift Container Platform バージョン 4.11 では、既存の Amazon Virtual Private Cloud (VPC) にインストールリリースコンテンツの内部ミラーを作成することにより、制限付きネットワークの Amazon Web Services (AWS) にクラスターをインストールできます。

5.7.1. 前提条件

  • OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
  • クラスターインストール方法の選択およびそのユーザー向けの準備 のドキュメント内容を確認している。
  • 非接続インストールのイメージのミラーリング をレジストリーに対して行っており、使用しているバージョンの OpenShift Container Platform の imageContentSources データを取得している。

    重要

    インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。

  • AWS に既存の VPC が必要です。インストーラーでプロビジョニングされるインフラストラクチャーを使用してネットワークが制限された環境にインストールする場合は、インストーラーでプロビジョニングされる VPC を使用することはできません。以下の要件のいずれかを満たすユーザーによってプロビジョニングされる VPC を使用する必要があります。

    • ミラーレジストリーが含まれる。
    • 別の場所でホストされるミラーレジストリーにアクセスするためのファイアウォールルールまたはピアリング接続がある。
  • クラスターをホストするために AWS アカウントを設定 している。

    重要

    AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。

  • AWS CLI をダウンロードし、これをコンピューターにインストールしている。AWS ドキュメントの Install the AWS CLI Using the Bundled Installer (Linux, macOS, or Unix) を参照してください。
  • クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 している (ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。

    注記

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

  • お使いの環境でクラウドアイデンティティーおよびアクセス管理 (IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを kube-system namespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 することができる。

5.7.2. ネットワークが制限された環境でのインストールについて

OpenShift Container Platform 4.11 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、インストーラーでプロビジョニングされるインフラストラクチャーまたはユーザーによってプロビジョニングされるインフラストラクチャーを使用して実行できます。

クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェアまたは VMware vSphere へのインストールには、インターネットアクセスが必要になる場合があります。

ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。

5.7.2.1. その他の制限

ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。

  • ClusterVersion ステータスには Unable to retrieve available updates エラーが含まれます。
  • デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。

5.7.3. カスタム VPC の使用について

OpenShift Container Platform 4.11 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) の既存のサブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。

インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。

5.7.3.1. VPC を使用するための要件

インストールプログラムは、以下のコンポーネントを作成しなくなりました。

  • インターネットゲートウェイ
  • NAT ゲートウェイ
  • サブネット
  • ルートテーブル
  • VPC
  • VPC DHCP オプション
  • VPC エンドポイント
注記

インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。

カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC の作成と管理の詳細は、AWS ドキュメントの Amazon VPC コンソールウィザードの設定VPC とサブネットの操作 を参照してください。

インストールプログラムには、以下の機能はありません。

  • 使用するクラスターのネットワーク範囲を細分化する。
  • サブネットのルートテーブルを設定する。
  • DHCP などの VPC オプションを設定する。

クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、 VPC ネットワーキングコンポーネントVPC のルートテーブル を参照してください。

VPC は以下の特性を満たす必要があります。

  • VPC は kubernetes.io/cluster/.*: ownedNameopenshift.io/cluster タグを使用できません。

    インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。

  • VPC で enableDnsSupport および enableDnsHostnames 属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。

    独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。ホストゾーンは、install-config.yaml ファイルの platform.aws.hostedZone フィールドを使用して定義できます。

非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。

オプション 1: VPC エンドポイントを作成する

VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<region>.amazonaws.com
  • elasticloadbalancing.<region>.amazonaws.com
  • s3.<region>.amazonaws.com

このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。

オプション 2: VPC エンドポイントなしでプロキシーを作成する

インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。

オプション 3: VPC エンドポイントでプロキシーを作成する

インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<region>.amazonaws.com
  • elasticloadbalancing.<region>.amazonaws.com
  • s3.<region>.amazonaws.com

install-config.yaml ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。

必要な VPC コンポーネント

お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。

Expand
コンポーネントAWS タイプ説明

VPC

  • AWS::EC2::VPC
  • AWS::EC2::VPCEndpoint

使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。

パブリックサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::SubnetNetworkAclAssociation

VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。

インターネットゲートウェイ

  • AWS::EC2::InternetGateway
  • AWS::EC2::VPCGatewayAttachment
  • AWS::EC2::RouteTable
  • AWS::EC2::Route
  • AWS::EC2::SubnetRouteTableAssociation
  • AWS::EC2::NatGateway
  • AWS::EC2::EIP

VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。

ネットワークアクセス制御

  • AWS::EC2::NetworkAcl
  • AWS::EC2::NetworkAclEntry

VPC が以下のポートにアクセスできるようにする必要があります。

ポート

理由

80

インバウンド HTTP トラフィック

443

インバウンド HTTPS トラフィック

22

インバウンド SSH トラフィック

1024 - 65535

インバウンド一時 (ephemeral) トラフィック

0 - 65535

アウトバウンド一時 (ephemeral) トラフィック

プライベートサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::RouteTable
  • AWS::EC2::SubnetRouteTableAssociation

VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

5.7.3.2. VPC 検証

指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。

  • 指定したサブネットすべてが存在します。
  • プライベートサブネットを指定します。
  • サブネットの CIDR は指定されたマシン CIDR に属します。
  • 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
  • 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。

既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、 kubernetes.io/cluster/.*: shared タグは、それが使用したサブネットから削除されます。

5.7.3.3. パーミッションの区分

OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。

クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。

5.7.3.4. クラスター間の分離

OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。

  • 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
  • ICMP Ingress はネットワーク全体から許可されます。
  • TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。

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

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

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

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

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

5.7.5. クラスターノードの 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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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 パブリックキーをインストールプログラムに指定します。

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

Amazon Web Services (AWS) での OpenShift Container Platform のインストールをカスタマイズできます。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
  • ミラーレジストリーの作成時に生成された imageContentSources 値を使用します。
  • ミラーレジストリーの証明書の内容を取得する。
  • サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。

手順

  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. ターゲットに設定するプラットフォームとして AWS を選択します。
      3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
      7. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. 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. クラスターをインストールする VPC のサブネットを定義します。

      subnets:
      - subnet-1
      - subnet-2
      - subnet-3
    4. 次の 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

      これらの値には、ミラーレジストリーの作成時に記録された imageContentSources を使用します。

  3. 必要な install-config.yaml ファイルに他の変更を加えます。利用可能なパラメーターの詳細については、インストール設定パラメーターセクションを参照してください。
  4. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

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

5.7.6.1. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

5.7.6.1.1. 必須設定パラメーター

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

Expand
表5.18 必須パラメーター
パラメーター説明

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

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}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"
      }
   }
}
5.7.6.1.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

Expand
表5.19 ネットワークパラメーター
パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

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 です。

OpenShift SDN および 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 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

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

例: 10.0.0.0/16

注記

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

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

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

Expand
表5.20 オプションのパラメーター
パラメーター説明

additionalTrustBundle

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

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

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

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

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

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

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

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

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

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 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

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

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

imageContentSources.source

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

文字列

imageContentSources.mirrors

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

文字列の配列。

publish

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

Internal または External。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。

sshKey

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

注記

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

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

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

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

Expand
表5.21 オプションの AWS パラメーター
パラメーター説明

compute.platform.aws.amiID

クラスターのコンピュートマシンの起動に使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

compute.platform.aws.iamRole

コンピュートマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

compute.platform.aws.rootVolume.iops

ルートボリュームに予約される 1 秒あたりの入出力操作 (IOPS)。

整数 (例: 4000)。

compute.platform.aws.rootVolume.size

ルートボリュームのサイズ (GiB)。

整数 (例: 500)。

compute.platform.aws.rootVolume.type

root ボリュームのタイプです。

有効な AWS EBS ボリュームタイプ (例: io1)。

compute.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、ワーカーノードの OS ボリュームを特定の KMS キーで暗号化するために必要です。

有効な キー ID またはキー ARN

compute.platform.aws.type

コンピュートマシンの EC2 インスタンスタイプ。

有効な AWS インスタンスタイプ (例: m4.2xlarge)。次の サポートされている AWS マシンタイプの 表を参照してください。

compute.platform.aws.zones

インストールプログラムがコンピュートマシンプールのマシンを作成するアベイラビリティーゾーン。独自の VPC を指定する場合は、そのアベイラビリティーゾーンにサブネットを指定する必要があります。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

compute.aws.region

インストールプログラムがコンピュートリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。AWS CLI を使用して、選択したインスタンスタイプに基づいて利用可能なリージョンにアクセスできます。以下に例を示します。

aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=c7g.xlarge
重要

ARM ベースの AWS インスタンスで実行する場合は、AWS Graviton プロセッサーが利用可能なリージョンを入力するようにしてください。AWS ドキュメントの グローバルアベイラビリティー マップを参照してください。現在、AWS Graviton3 プロセッサーは一部のリージョンでのみ利用できます。

controlPlane.platform.aws.amiID

クラスターのコントロールプレーンマシンを起動するために使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

controlPlane.platform.aws.iamRole

コントロールプレーンマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

controlPlane.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、特定の KMS キーを使用してコントロールプレーンノードの OS ボリュームを暗号化するために必要です。

有効な キー ID とキー ARN

controlPlane.platform.aws.type

コントロールプレーンマシンの EC2 インスタンスタイプ。

m6i.xlarge などの有効な AWS インスタンスタイプ。次の サポートされている AWS マシンタイプの 表を参照してください。

controlPlane.platform.aws.zones

インストールプログラムがコントロールプレーンマシンプールのマシンを作成するアベイラビリティーゾーン。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

controlPlane.aws.region

インストールプログラムがコントロールプレーンのリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。

platform.aws.amiID

クラスターのすべてのマシンを起動するために使用される AWS AMI。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

platform.aws.hostedZone

クラスターの既存の Route 53 プライベートホストゾーン。独自の VPC を指定する場合も、既存のホストゾーンのみを使用できます。ホストゾーンは、インストール前にユーザーによって提供される VPC に関連付けられている必要があります。また、ホストゾーンのドメインはクラスタードメインまたはクラスタードメインの親である必要があります。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。

文字列 (例: Z3URY6TWQ91KVV)

platform.aws.serviceEndpoints.name

AWS サービスエンドポイント名。カスタムエンドポイントは、FIPS などの AWS の代替エンドポイントを使用しなければならない場合にのみ必要です。カスタム API エンドポイントは、EC2、S3、IAM、Elastic Load Balancing、Tagging、Route 53、および STS AWS サービスに指定できます。

有効な AWS サービスエンドポイント 名。

platform.aws.serviceEndpoints.url

AWS サービスエンドポイント URL。URL には https プロトコルを使用し、ホストは証明書を信頼する必要があります。

有効な AWS サービスエンドポイント URL。

platform.aws.userTags

インストールプログラムが、作成するすべてのリソースに対するタグとして追加するキーと値のマップ。

<key>: <value> 形式のキー値ペアなどの有効な YAML マップ。AWS タグについての詳細は、AWS ドキュメントの Tagging Your Amazon EC2 Resources を参照してください。

platform.aws.subnets

インストールプログラムによる VPC の作成を許可する代わりに VPC を指定する場合は、使用するクラスターのサブネットを指定します。サブネットは、指定する同じ machineNetwork[].cidr 範囲の一部である必要があります。標準クラスターの場合は、各アベイラビリティーゾーンのパブリックおよびプライベートサブネットを指定します。プライベートクラスターについては、各アベイラビリティーゾーンのプライベートサブネットを指定します。

有効なサブネット ID。

5.7.6.2. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

Expand
表5.22 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージIOPS [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. ユーザーによってプロビジョニングされるすべてのインストールと同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

5.7.6.3. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。

apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 
13

    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 
14

    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-96c6f8f7 
15

    serviceEndpoints: 
16

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 
17

fips: false 
18

sshKey: ssh-ed25519 AAAA... 
19

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

additionalTrustBundle: | 
21

    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
imageContentSources: 
22

- 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 12 13
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2
オプション: このパラメーターを追加して、Cloud Credential Operator (CCO) に認証情報の機能を動的に判別させようとするのではなく、CCO が指定されたモードを使用するように強制します。CCO モードの詳細は、Red Hat Operatorクラウド認証情報 Operatorを参照してください。
3 8
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、 compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して m4.2xlarge または m5.2xlarge などの大規模なインスタンスタイプを使用します。

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、マシンセットを使用して変更できます。

14
独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
15
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
16
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
17
既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
18
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。プロセス暗号化ライブラリーでの FIPS 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

19
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

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

20
<local_registry> については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:5000<credentials> について、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。
21
ミラーレジストリーに使用した証明書ファイルの内容を指定します。
22
リポジトリーのミラーリングに使用するコマンドの出力の imageContentSources セクションを指定します。
5.7.6.4. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<region>.amazonaws.com,elasticloadbalancing.<region>.amazonaws.com,s3.<region>.amazonaws.com 
    3
    
    additionalTrustBundle: | 
    4
    
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic Load Balancing、および S3 VPC エンドポイントを VPC に追加した場合は、これらのエンドポイントを noProxy フィールドに追加する必要があります。
    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 信頼バンドルからの認証局によって署名されない限り必要になります。
    注記

    インストールプログラムは、プロキシーの 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 オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

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

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

重要

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

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定します。
  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。

手順

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

    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。

  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、または無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

5.7.8. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

5.7.10. デフォルトの 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 タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。

5.7.11. OpenShift Container Platform の Telemetry アクセス

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

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

5.7.12. 次のステップ

5.8. AWS のクラスターの既存 VPC へのインストール

OpenShift Container Platform バージョン 4.11 では、Amazon Web Services (AWS) 上の既存の Amazon Virtual Private Cloud (VPC) にクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

5.8.1. 前提条件

5.8.2. カスタム VPC の使用について

OpenShift Container Platform 4.11 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) の既存のサブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。

インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。

5.8.2.1. VPC を使用するための要件

インストールプログラムは、以下のコンポーネントを作成しなくなりました。

  • インターネットゲートウェイ
  • NAT ゲートウェイ
  • サブネット
  • ルートテーブル
  • VPC
  • VPC DHCP オプション
  • VPC エンドポイント
注記

インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。

カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC の作成と管理の詳細は、AWS ドキュメントの Amazon VPC コンソールウィザードの設定VPC とサブネットの操作 を参照してください。

インストールプログラムには、以下の機能はありません。

  • 使用するクラスターのネットワーク範囲を細分化する。
  • サブネットのルートテーブルを設定する。
  • DHCP などの VPC オプションを設定する。

クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、 VPC ネットワーキングコンポーネントVPC のルートテーブル を参照してください。

VPC は以下の特性を満たす必要があります。

  • クラスターが使用するアベイラビリティーゾーンごとにパブリックサブネットとプライベートサブネットを作成します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。このタイプの設定の例は、AWS ドキュメントの パブリックサブネットとプライベートサブネット (NAT) を使用した VPC を参照してください。

    各サブネット ID を記録します。インストールを完了するには、 install-config.yaml ファイルの プラットフォーム セクションにこれらの値を入力する必要があります。AWS ドキュメントの サブネット ID の検索 を参照してください。

  • VPC の CIDR ブロックには、クラスターマシンの IP アドレスプールである Networking.MachineCIDR 範囲が含まれている必要があります。サブネット CIDR ブロックは、指定したマシン CIDR に属している必要があります。
  • VPC には、パブリックインターネットゲートウェイが接続されている必要があります。アベイラビリティーゾーンごとに以下が必要です。

    • パブリックサブネットには、インターネットゲートウェイへのルートが必要です。
    • パブリックサブネットには、EIP アドレスが割り当てられた NAT ゲートウェイが必要です。
    • プライベートサブネットには、パブリックサブネットの NAT ゲートウェイへのルートが必要です。
  • VPC は kubernetes.io/cluster/.*: ownedNameopenshift.io/cluster タグを使用できません。

    インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。

  • VPC で enableDnsSupport および enableDnsHostnames 属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。

    独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。ホストゾーンは、install-config.yaml ファイルの platform.aws.hostedZone フィールドを使用して定義できます。

非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。

オプション 1: VPC エンドポイントを作成する

VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<region>.amazonaws.com
  • elasticloadbalancing.<region>.amazonaws.com
  • s3.<region>.amazonaws.com

このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。

オプション 2: VPC エンドポイントなしでプロキシーを作成する

インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。

オプション 3: VPC エンドポイントでプロキシーを作成する

インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<region>.amazonaws.com
  • elasticloadbalancing.<region>.amazonaws.com
  • s3.<region>.amazonaws.com

install-config.yaml ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。

必要な VPC コンポーネント

お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。

Expand
コンポーネントAWS タイプ説明

VPC

  • AWS::EC2::VPC
  • AWS::EC2::VPCEndpoint

使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。

パブリックサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::SubnetNetworkAclAssociation

VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。

インターネットゲートウェイ

  • AWS::EC2::InternetGateway
  • AWS::EC2::VPCGatewayAttachment
  • AWS::EC2::RouteTable
  • AWS::EC2::Route
  • AWS::EC2::SubnetRouteTableAssociation
  • AWS::EC2::NatGateway
  • AWS::EC2::EIP

VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。

ネットワークアクセス制御

  • AWS::EC2::NetworkAcl
  • AWS::EC2::NetworkAclEntry

VPC が以下のポートにアクセスできるようにする必要があります。

ポート

理由

80

インバウンド HTTP トラフィック

443

インバウンド HTTPS トラフィック

22

インバウンド SSH トラフィック

1024 - 65535

インバウンド一時 (ephemeral) トラフィック

0 - 65535

アウトバウンド一時 (ephemeral) トラフィック

プライベートサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::RouteTable
  • AWS::EC2::SubnetRouteTableAssociation

VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

5.8.2.2. VPC 検証

指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。

  • 指定したサブネットすべてが存在します。
  • プライベートサブネットを指定します。
  • サブネットの CIDR は指定されたマシン CIDR に属します。
  • 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
  • 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。

既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、 kubernetes.io/cluster/.*: shared タグは、それが使用したサブネットから削除されます。

5.8.2.3. パーミッションの区分

OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。

クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。

5.8.2.4. クラスター間の分離

OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。

  • 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
  • ICMP Ingress はネットワーク全体から許可されます。
  • TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。

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

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

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

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

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

5.8.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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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 パブリックキーをインストールプログラムに指定します。

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

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

Amazon Web Services (AWS) での 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 からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

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

        注記

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

      2. ターゲットに設定するプラットフォームとして AWS を選択します。
      3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
      7. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、インストール設定パラメーターのセクションを参照してください。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

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

5.8.6.1. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

5.8.6.1.1. 必須設定パラメーター

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

Expand
表5.23 必須パラメーター
パラメーター説明

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

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}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"
      }
   }
}
5.8.6.1.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

Expand
表5.24 ネットワークパラメーター
パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

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 です。

OpenShift SDN および 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 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

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

例: 10.0.0.0/16

注記

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

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

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

Expand
表5.25 オプションのパラメーター
パラメーター説明

additionalTrustBundle

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

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

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

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

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

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

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

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

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

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 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

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

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

imageContentSources.source

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

文字列

imageContentSources.mirrors

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

文字列の配列。

publish

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

Internal または External。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。

sshKey

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

注記

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

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

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

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

Expand
表5.26 オプションの AWS パラメーター
パラメーター説明

compute.platform.aws.amiID

クラスターのコンピュートマシンの起動に使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

compute.platform.aws.iamRole

コンピュートマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

compute.platform.aws.rootVolume.iops

ルートボリュームに予約される 1 秒あたりの入出力操作 (IOPS)。

整数 (例: 4000)。

compute.platform.aws.rootVolume.size

ルートボリュームのサイズ (GiB)。

整数 (例: 500)。

compute.platform.aws.rootVolume.type

root ボリュームのタイプです。

有効な AWS EBS ボリュームタイプ (例: io1)。

compute.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、ワーカーノードの OS ボリュームを特定の KMS キーで暗号化するために必要です。

有効な キー ID またはキー ARN

compute.platform.aws.type

コンピュートマシンの EC2 インスタンスタイプ。

有効な AWS インスタンスタイプ (例: m4.2xlarge)。次の サポートされている AWS マシンタイプの 表を参照してください。

compute.platform.aws.zones

インストールプログラムがコンピュートマシンプールのマシンを作成するアベイラビリティーゾーン。独自の VPC を指定する場合は、そのアベイラビリティーゾーンにサブネットを指定する必要があります。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

compute.aws.region

インストールプログラムがコンピュートリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。AWS CLI を使用して、選択したインスタンスタイプに基づいて利用可能なリージョンにアクセスできます。以下に例を示します。

aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=c7g.xlarge
重要

ARM ベースの AWS インスタンスで実行する場合は、AWS Graviton プロセッサーが利用可能なリージョンを入力するようにしてください。AWS ドキュメントの グローバルアベイラビリティー マップを参照してください。現在、AWS Graviton3 プロセッサーは一部のリージョンでのみ利用できます。

controlPlane.platform.aws.amiID

クラスターのコントロールプレーンマシンを起動するために使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

controlPlane.platform.aws.iamRole

コントロールプレーンマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

controlPlane.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、特定の KMS キーを使用してコントロールプレーンノードの OS ボリュームを暗号化するために必要です。

有効な キー ID とキー ARN

controlPlane.platform.aws.type

コントロールプレーンマシンの EC2 インスタンスタイプ。

m6i.xlarge などの有効な AWS インスタンスタイプ。次の サポートされている AWS マシンタイプの 表を参照してください。

controlPlane.platform.aws.zones

インストールプログラムがコントロールプレーンマシンプールのマシンを作成するアベイラビリティーゾーン。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

controlPlane.aws.region

インストールプログラムがコントロールプレーンのリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。

platform.aws.amiID

クラスターのすべてのマシンを起動するために使用される AWS AMI。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

platform.aws.hostedZone

クラスターの既存の Route 53 プライベートホストゾーン。独自の VPC を指定する場合も、既存のホストゾーンのみを使用できます。ホストゾーンは、インストール前にユーザーによって提供される VPC に関連付けられている必要があります。また、ホストゾーンのドメインはクラスタードメインまたはクラスタードメインの親である必要があります。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。

文字列 (例: Z3URY6TWQ91KVV)

platform.aws.serviceEndpoints.name

AWS サービスエンドポイント名。カスタムエンドポイントは、FIPS などの AWS の代替エンドポイントを使用しなければならない場合にのみ必要です。カスタム API エンドポイントは、EC2、S3、IAM、Elastic Load Balancing、Tagging、Route 53、および STS AWS サービスに指定できます。

有効な AWS サービスエンドポイント 名。

platform.aws.serviceEndpoints.url

AWS サービスエンドポイント URL。URL には https プロトコルを使用し、ホストは証明書を信頼する必要があります。

有効な AWS サービスエンドポイント URL。

platform.aws.userTags

インストールプログラムが、作成するすべてのリソースに対するタグとして追加するキーと値のマップ。

<key>: <value> 形式のキー値ペアなどの有効な YAML マップ。AWS タグについての詳細は、AWS ドキュメントの Tagging Your Amazon EC2 Resources を参照してください。

platform.aws.subnets

インストールプログラムによる VPC の作成を許可する代わりに VPC を指定する場合は、使用するクラスターのサブネットを指定します。サブネットは、指定する同じ machineNetwork[].cidr 範囲の一部である必要があります。標準クラスターの場合は、各アベイラビリティーゾーンのパブリックおよびプライベートサブネットを指定します。プライベートクラスターについては、各アベイラビリティーゾーンのプライベートサブネットを指定します。

有効なサブネット ID。

5.8.6.2. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

Expand
表5.27 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージIOPS [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. ユーザーによってプロビジョニングされるすべてのインストールと同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

5.8.6.3. AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services(AWS)インスタンスタイプは OpenShift Container Platform でテストされています。

注記

以下のチャートに含まれるマシンタイプを AWS インスタンスに使用します。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。

例5.20 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*
5.8.6.4. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services (AWS) ARM64 インスタンスタイプは OpenShift Container Platform でテストされています。

注記

AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。

例5.21 64 ビット ARM アーキテクチャーに基づくマシンタイプ

  • c6g.*
  • m6g.*
5.8.6.5. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。

apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 
13

    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 
14

    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-96c6f8f7 
15

    serviceEndpoints: 
16

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 
17

fips: false 
18

sshKey: ssh-ed25519 AAAA... 
19

pullSecret: '{"auths": ...}' 
20
1 12 13 20
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2
オプション: このパラメーターを追加して、Cloud Credential Operator (CCO) に認証情報の機能を動的に判別させようとするのではなく、CCO が指定されたモードを使用するように強制します。CCO モードの詳細は、Red Hat Operatorクラウド認証情報 Operatorを参照してください。
3 8
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、 compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して m4.2xlarge または m5.2xlarge などの大規模なインスタンスタイプを使用します。

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、マシンセットを使用して変更できます。

14
独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
15
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
16
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
17
既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
18
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。プロセス暗号化ライブラリーでの FIPS 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

19
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

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

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

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<region>.amazonaws.com,elasticloadbalancing.<region>.amazonaws.com,s3.<region>.amazonaws.com 
    3
    
    additionalTrustBundle: | 
    4
    
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic Load Balancing、および S3 VPC エンドポイントを VPC に追加した場合は、これらのエンドポイントを noProxy フィールドに追加する必要があります。
    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 信頼バンドルからの認証局によって署名されない限り必要になります。
    注記

    インストールプログラムは、プロキシーの 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 オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

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

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

重要

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

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定します。
  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。

手順

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

    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。

  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、または無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

5.8.8. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

5.8.10. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

5.8.11. OpenShift Container Platform の Telemetry アクセス

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

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

5.8.12. 次のステップ

5.9. プライベートクラスターの AWS へのインストール

OpenShift Container Platform バージョン 4.11 では、Amazon Web Services (AWS) 上の既存の VPC にプライベートクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

5.9.1. 前提条件

5.9.2. プライベートクラスター

外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。

デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。

重要

クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。

プライベートクラスターをデプロイするには、以下を行う必要があります。

  • 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
  • 以下にアクセスできるマシンからデプロイ。

    • プロビジョニングするクラウドの API サービス。
    • プロビジョニングするネットワーク上のホスト。
    • インストールメディアを取得するインターネット。

これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。

5.9.2.1. AWS のプライベートクラスター

Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。

クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。

以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。

  • パブリックサブネット
  • パブリック Ingress をサポートするパブリックロードバランサー
  • クラスターの baseDomain に一致するパブリック Route 53 ゾーン

インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。

5.9.2.1.1. 制限事項

プライベートクラスターにパブリック機能を追加する機能には制限があります。

  • Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
  • パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに kubernetes.io/cluster/<cluster-infra-id>: shared のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。

5.9.3. カスタム VPC の使用について

OpenShift Container Platform 4.11 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) の既存のサブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。

インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。

5.9.3.1. VPC を使用するための要件

インストールプログラムは、以下のコンポーネントを作成しなくなりました。

  • インターネットゲートウェイ
  • NAT ゲートウェイ
  • サブネット
  • ルートテーブル
  • VPC
  • VPC DHCP オプション
  • VPC エンドポイント
注記

インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。

カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC の作成と管理の詳細は、AWS ドキュメントの Amazon VPC コンソールウィザードの設定VPC とサブネットの操作 を参照してください。

インストールプログラムには、以下の機能はありません。

  • 使用するクラスターのネットワーク範囲を細分化する。
  • サブネットのルートテーブルを設定する。
  • DHCP などの VPC オプションを設定する。

クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、 VPC ネットワーキングコンポーネントVPC のルートテーブル を参照してください。

VPC は以下の特性を満たす必要があります。

  • VPC は kubernetes.io/cluster/.*: ownedNameopenshift.io/cluster タグを使用できません。

    インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。

  • VPC で enableDnsSupport および enableDnsHostnames 属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。

    独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。ホストゾーンは、install-config.yaml ファイルの platform.aws.hostedZone フィールドを使用して定義できます。

非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。

オプション 1: VPC エンドポイントを作成する

VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<region>.amazonaws.com
  • elasticloadbalancing.<region>.amazonaws.com
  • s3.<region>.amazonaws.com

このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。

オプション 2: VPC エンドポイントなしでプロキシーを作成する

インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。

オプション 3: VPC エンドポイントでプロキシーを作成する

インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<region>.amazonaws.com
  • elasticloadbalancing.<region>.amazonaws.com
  • s3.<region>.amazonaws.com

install-config.yaml ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。

必要な VPC コンポーネント

お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。

Expand
コンポーネントAWS タイプ説明

VPC

  • AWS::EC2::VPC
  • AWS::EC2::VPCEndpoint

使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。

パブリックサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::SubnetNetworkAclAssociation

VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。

インターネットゲートウェイ

  • AWS::EC2::InternetGateway
  • AWS::EC2::VPCGatewayAttachment
  • AWS::EC2::RouteTable
  • AWS::EC2::Route
  • AWS::EC2::SubnetRouteTableAssociation
  • AWS::EC2::NatGateway
  • AWS::EC2::EIP

VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。

ネットワークアクセス制御

  • AWS::EC2::NetworkAcl
  • AWS::EC2::NetworkAclEntry

VPC が以下のポートにアクセスできるようにする必要があります。

ポート

理由

80

インバウンド HTTP トラフィック

443

インバウンド HTTPS トラフィック

22

インバウンド SSH トラフィック

1024 - 65535

インバウンド一時 (ephemeral) トラフィック

0 - 65535

アウトバウンド一時 (ephemeral) トラフィック

プライベートサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::RouteTable
  • AWS::EC2::SubnetRouteTableAssociation

VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

5.9.3.2. VPC 検証

指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。

  • 指定したサブネットすべてが存在します。
  • プライベートサブネットを指定します。
  • サブネットの CIDR は指定されたマシン CIDR に属します。
  • 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
  • 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。

既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、 kubernetes.io/cluster/.*: shared タグは、それが使用したサブネットから削除されます。

5.9.3.3. パーミッションの区分

OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。

クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。

5.9.3.4. クラスター間の分離

OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。

  • 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
  • ICMP Ingress はネットワーク全体から許可されます。
  • TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。

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

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

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

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

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

5.9.5. クラスターノードの 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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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 パブリックキーをインストールプログラムに指定します。

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

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

内部ネットワークからのみアクセスでき、インターネット上に表示されないプライベート OpenShift Container Platform クラスターのインストールの場合、インストール設定ファイルを手動で生成する必要があります。

前提条件

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

手順

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

    $ mkdir <installation_directory>
    重要

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

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

    注記

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

    注記

    一部のプラットフォームタイプでは、代わりに ./openshift-install create install-config --dir <installation_directory> を実行して install-config.yaml ファイルを生成することができます。プロンプト時にクラスター設定の詳細を指定できます。

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

    重要

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

5.9.7.1. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

5.9.7.1.1. 必須設定パラメーター

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

Expand
表5.28 必須パラメーター
パラメーター説明

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

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}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"
      }
   }
}
5.9.7.1.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

Expand
表5.29 ネットワークパラメーター
パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

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 です。

OpenShift SDN および 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 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

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

例: 10.0.0.0/16

注記

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

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

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

Expand
表5.30 オプションのパラメーター
パラメーター説明

additionalTrustBundle

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

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

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

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

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

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

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

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

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

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 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

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

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

imageContentSources.source

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

文字列

imageContentSources.mirrors

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

文字列の配列。

publish

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

Internal または External。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。

sshKey

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

注記

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

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

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

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

Expand
表5.31 オプションの AWS パラメーター
パラメーター説明

compute.platform.aws.amiID

クラスターのコンピュートマシンの起動に使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

compute.platform.aws.iamRole

コンピュートマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

compute.platform.aws.rootVolume.iops

ルートボリュームに予約される 1 秒あたりの入出力操作 (IOPS)。

整数 (例: 4000)。

compute.platform.aws.rootVolume.size

ルートボリュームのサイズ (GiB)。

整数 (例: 500)。

compute.platform.aws.rootVolume.type

root ボリュームのタイプです。

有効な AWS EBS ボリュームタイプ (例: io1)。

compute.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、ワーカーノードの OS ボリュームを特定の KMS キーで暗号化するために必要です。

有効な キー ID またはキー ARN

compute.platform.aws.type

コンピュートマシンの EC2 インスタンスタイプ。

有効な AWS インスタンスタイプ (例: m4.2xlarge)。次の サポートされている AWS マシンタイプの 表を参照してください。

compute.platform.aws.zones

インストールプログラムがコンピュートマシンプールのマシンを作成するアベイラビリティーゾーン。独自の VPC を指定する場合は、そのアベイラビリティーゾーンにサブネットを指定する必要があります。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

compute.aws.region

インストールプログラムがコンピュートリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。AWS CLI を使用して、選択したインスタンスタイプに基づいて利用可能なリージョンにアクセスできます。以下に例を示します。

aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=c7g.xlarge
重要

ARM ベースの AWS インスタンスで実行する場合は、AWS Graviton プロセッサーが利用可能なリージョンを入力するようにしてください。AWS ドキュメントの グローバルアベイラビリティー マップを参照してください。現在、AWS Graviton3 プロセッサーは一部のリージョンでのみ利用できます。

controlPlane.platform.aws.amiID

クラスターのコントロールプレーンマシンを起動するために使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

controlPlane.platform.aws.iamRole

コントロールプレーンマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

controlPlane.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、特定の KMS キーを使用してコントロールプレーンノードの OS ボリュームを暗号化するために必要です。

有効な キー ID とキー ARN

controlPlane.platform.aws.type

コントロールプレーンマシンの EC2 インスタンスタイプ。

m6i.xlarge などの有効な AWS インスタンスタイプ。次の サポートされている AWS マシンタイプの 表を参照してください。

controlPlane.platform.aws.zones

インストールプログラムがコントロールプレーンマシンプールのマシンを作成するアベイラビリティーゾーン。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

controlPlane.aws.region

インストールプログラムがコントロールプレーンのリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。

platform.aws.amiID

クラスターのすべてのマシンを起動するために使用される AWS AMI。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

platform.aws.hostedZone

クラスターの既存の Route 53 プライベートホストゾーン。独自の VPC を指定する場合も、既存のホストゾーンのみを使用できます。ホストゾーンは、インストール前にユーザーによって提供される VPC に関連付けられている必要があります。また、ホストゾーンのドメインはクラスタードメインまたはクラスタードメインの親である必要があります。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。

文字列 (例: Z3URY6TWQ91KVV)

platform.aws.serviceEndpoints.name

AWS サービスエンドポイント名。カスタムエンドポイントは、FIPS などの AWS の代替エンドポイントを使用しなければならない場合にのみ必要です。カスタム API エンドポイントは、EC2、S3、IAM、Elastic Load Balancing、Tagging、Route 53、および STS AWS サービスに指定できます。

有効な AWS サービスエンドポイント 名。

platform.aws.serviceEndpoints.url

AWS サービスエンドポイント URL。URL には https プロトコルを使用し、ホストは証明書を信頼する必要があります。

有効な AWS サービスエンドポイント URL。

platform.aws.userTags

インストールプログラムが、作成するすべてのリソースに対するタグとして追加するキーと値のマップ。

<key>: <value> 形式のキー値ペアなどの有効な YAML マップ。AWS タグについての詳細は、AWS ドキュメントの Tagging Your Amazon EC2 Resources を参照してください。

platform.aws.subnets

インストールプログラムによる VPC の作成を許可する代わりに VPC を指定する場合は、使用するクラスターのサブネットを指定します。サブネットは、指定する同じ machineNetwork[].cidr 範囲の一部である必要があります。標準クラスターの場合は、各アベイラビリティーゾーンのパブリックおよびプライベートサブネットを指定します。プライベートクラスターについては、各アベイラビリティーゾーンのプライベートサブネットを指定します。

有効なサブネット ID。

5.9.7.2. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

Expand
表5.32 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージIOPS [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. ユーザーによってプロビジョニングされるすべてのインストールと同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

5.9.7.3. AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services(AWS)インスタンスタイプは OpenShift Container Platform でテストされています。

注記

以下のチャートに含まれるマシンタイプを AWS インスタンスに使用します。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。

例5.22 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*
5.9.7.4. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services (AWS) ARM64 インスタンスタイプは OpenShift Container Platform でテストされています。

注記

AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。

例5.23 64 ビット ARM アーキテクチャーに基づくマシンタイプ

  • c6g.*
  • m6g.*
5.9.7.5. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。

apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 
13

    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 
14

    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-96c6f8f7 
15

    serviceEndpoints: 
16

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 
17

fips: false 
18

sshKey: ssh-ed25519 AAAA... 
19

publish: Internal 
20

pullSecret: '{"auths": ...}' 
21
1 12 13 21
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2
オプション: このパラメーターを追加して、Cloud Credential Operator (CCO) に認証情報の機能を動的に判別させようとするのではなく、CCO が指定されたモードを使用するように強制します。CCO モードの詳細は、Red Hat Operatorクラウド認証情報 Operatorを参照してください。
3 8
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、 compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して m4.2xlarge または m5.2xlarge などの大規模なインスタンスタイプを使用します。

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、マシンセットを使用して変更できます。

14
独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
15
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
16
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
17
既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
18
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。プロセス暗号化ライブラリーでの FIPS 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

19
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

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

20
クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。
5.9.7.6. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<region>.amazonaws.com,elasticloadbalancing.<region>.amazonaws.com,s3.<region>.amazonaws.com 
    3
    
    additionalTrustBundle: | 
    4
    
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic Load Balancing、および S3 VPC エンドポイントを VPC に追加した場合は、これらのエンドポイントを noProxy フィールドに追加する必要があります。
    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 信頼バンドルからの認証局によって署名されない限り必要になります。
    注記

    インストールプログラムは、プロキシーの 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 オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

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

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

重要

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

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定します。
  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。

手順

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

    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。

  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、または無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

5.9.9. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

5.9.11. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

5.9.12. OpenShift Container Platform の Telemetry アクセス

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

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

5.9.13. 次のステップ

5.10. AWS の government リージョンへのクラスターのインストール

OpenShift Container Platform バージョン 4.11 では、Amazon Web Services (AWS) のクラスターを government リージョンにインストールできます。リージョンを設定するには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

5.10.1. 前提条件

5.10.2. AWS government リージョン

OpenShift Container Platform は、AWS Gov Cloud (US) リージョンへのクラスターのデプロイをサポートします。

以下の AWS GovCloud パーティションがサポートされます。

  • us-gov-east-1
  • us-gov-west-1

5.10.3. インストール要件

クラスターをインストールする前に、以下を行う必要があります。

  • クラスターをホストするために、既存のプライベート AWS VPC とサブネットを提供します。

    パブリックゾーンは、AWS GovCloud の Route 53 ではサポートされません。その結果、AWS government リージョンにデプロイする場合、クラスターはプライベートである必要があります。

  • インストール設定ファイル (install-config.yaml) を手動で作成します。

5.10.4. プライベートクラスター

外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。

注記

パブリックゾーンは、AWS GovCloud リージョンの Route 53 ではサポートされていません。したがって、クラスターを AWS GovCloud リージョンにデプロイする場合は、クラスターをプライベートにする必要があります。

デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。

重要

クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。

プライベートクラスターをデプロイするには、以下を行う必要があります。

  • 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
  • 以下にアクセスできるマシンからデプロイ。

    • プロビジョニングするクラウドの API サービス。
    • プロビジョニングするネットワーク上のホスト。
    • インストールメディアを取得するインターネット。

これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。

5.10.4.1. AWS のプライベートクラスター

Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。

クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。

以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。

  • パブリックサブネット
  • パブリック Ingress をサポートするパブリックロードバランサー
  • クラスターの baseDomain に一致するパブリック Route 53 ゾーン

インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。

5.10.4.1.1. 制限事項

プライベートクラスターにパブリック機能を追加する機能には制限があります。

  • Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
  • パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに kubernetes.io/cluster/<cluster-infra-id>: shared のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。

5.10.5. カスタム VPC の使用について

OpenShift Container Platform 4.11 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) の既存のサブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。

インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。

5.10.5.1. VPC を使用するための要件

インストールプログラムは、以下のコンポーネントを作成しなくなりました。

  • インターネットゲートウェイ
  • NAT ゲートウェイ
  • サブネット
  • ルートテーブル
  • VPC
  • VPC DHCP オプション
  • VPC エンドポイント
注記

インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。

カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC の作成と管理の詳細は、AWS ドキュメントの Amazon VPC コンソールウィザードの設定VPC とサブネットの操作 を参照してください。

インストールプログラムには、以下の機能はありません。

  • 使用するクラスターのネットワーク範囲を細分化する。
  • サブネットのルートテーブルを設定する。
  • DHCP などの VPC オプションを設定する。

クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、 VPC ネットワーキングコンポーネントVPC のルートテーブル を参照してください。

VPC は以下の特性を満たす必要があります。

  • VPC は kubernetes.io/cluster/.*: ownedNameopenshift.io/cluster タグを使用できません。

    インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。

  • VPC で enableDnsSupport および enableDnsHostnames 属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。

    独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。ホストゾーンは、install-config.yaml ファイルの platform.aws.hostedZone フィールドを使用して定義できます。

非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。

オプション 1: VPC エンドポイントを作成する

VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<region>.amazonaws.com
  • elasticloadbalancing.<region>.amazonaws.com
  • s3.<region>.amazonaws.com

このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。

オプション 2: VPC エンドポイントなしでプロキシーを作成する

インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。

オプション 3: VPC エンドポイントでプロキシーを作成する

インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<region>.amazonaws.com
  • elasticloadbalancing.<region>.amazonaws.com
  • s3.<region>.amazonaws.com

install-config.yaml ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。

必要な VPC コンポーネント

お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。

Expand
コンポーネントAWS タイプ説明

VPC

  • AWS::EC2::VPC
  • AWS::EC2::VPCEndpoint

使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。

パブリックサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::SubnetNetworkAclAssociation

VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。

インターネットゲートウェイ

  • AWS::EC2::InternetGateway
  • AWS::EC2::VPCGatewayAttachment
  • AWS::EC2::RouteTable
  • AWS::EC2::Route
  • AWS::EC2::SubnetRouteTableAssociation
  • AWS::EC2::NatGateway
  • AWS::EC2::EIP

VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。

ネットワークアクセス制御

  • AWS::EC2::NetworkAcl
  • AWS::EC2::NetworkAclEntry

VPC が以下のポートにアクセスできるようにする必要があります。

ポート

理由

80

インバウンド HTTP トラフィック

443

インバウンド HTTPS トラフィック

22

インバウンド SSH トラフィック

1024 - 65535

インバウンド一時 (ephemeral) トラフィック

0 - 65535

アウトバウンド一時 (ephemeral) トラフィック

プライベートサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::RouteTable
  • AWS::EC2::SubnetRouteTableAssociation

VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

5.10.5.2. VPC 検証

指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。

  • 指定したサブネットすべてが存在します。
  • プライベートサブネットを指定します。
  • サブネットの CIDR は指定されたマシン CIDR に属します。
  • 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
  • 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。

既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、 kubernetes.io/cluster/.*: shared タグは、それが使用したサブネットから削除されます。

5.10.5.3. パーミッションの区分

OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。

クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。

5.10.5.4. クラスター間の分離

OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。

  • 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
  • ICMP Ingress はネットワーク全体から許可されます。
  • TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。

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

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

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

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

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

5.10.7. クラスターノードの 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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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 パブリックキーをインストールプログラムに指定します。

5.10.8. AWS Marketplace イメージの取得

AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがワーカーノードのデプロイに使用する AMI ID が提供されます。

前提条件

  • オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。

手順

  1. AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
  2. 使用する特定のリージョンの AMI ID を記録します。インストールプロセスの一環として、クラスターをデプロイする前に、この値で install-config.yaml ファイルを更新する必要があります。

AWS Marketplace ワーカーノードを含む install-config.yaml ファイルのサンプル

apiVersion: v1
baseDomain: example.com
compute:
- hyperthreading: Enabled
  name: worker
  platform:
    aws:
      amiID: ami-06c4d345f7c207239 
1

      type: m5.4xlarge
  replicas: 3
metadata:
  name: test-cluster
platform:
  aws:
    region: us-east-2 
2

sshKey: ssh-ed25519 AAAA...
pullSecret: '{"auths": ...}'

1
AWS Marketplace サブスクリプションの AMI ID。
2
AMI ID は特定の AWS リージョンに関連付けられています。インストール設定ファイルを作成するときは、サブスクリプションの設定時に指定したものと同じ AWS リージョンを選択してください。

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

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

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

前提条件

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

手順

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

    $ mkdir <installation_directory>
    重要

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

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

    注記

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

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

    重要

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

5.10.10.1. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

5.10.10.1.1. 必須設定パラメーター

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

Expand
表5.33 必須パラメーター
パラメーター説明

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

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}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"
      }
   }
}
5.10.10.1.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

Expand
表5.34 ネットワークパラメーター
パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

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 です。

OpenShift SDN および 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 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

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

例: 10.0.0.0/16

注記

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

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

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

Expand
表5.35 オプションのパラメーター
パラメーター説明

additionalTrustBundle

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

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

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

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

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

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

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

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

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

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 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

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

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

imageContentSources.source

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

文字列

imageContentSources.mirrors

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

文字列の配列。

publish

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

Internal または External。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。

sshKey

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

注記

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

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

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

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

Expand
表5.36 オプションの AWS パラメーター
パラメーター説明

compute.platform.aws.amiID

クラスターのコンピュートマシンの起動に使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

compute.platform.aws.iamRole

コンピュートマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

compute.platform.aws.rootVolume.iops

ルートボリュームに予約される 1 秒あたりの入出力操作 (IOPS)。

整数 (例: 4000)。

compute.platform.aws.rootVolume.size

ルートボリュームのサイズ (GiB)。

整数 (例: 500)。

compute.platform.aws.rootVolume.type

root ボリュームのタイプです。

有効な AWS EBS ボリュームタイプ (例: io1)。

compute.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、ワーカーノードの OS ボリュームを特定の KMS キーで暗号化するために必要です。

有効な キー ID またはキー ARN

compute.platform.aws.type

コンピュートマシンの EC2 インスタンスタイプ。

有効な AWS インスタンスタイプ (例: m4.2xlarge)。次の サポートされている AWS マシンタイプの 表を参照してください。

compute.platform.aws.zones

インストールプログラムがコンピュートマシンプールのマシンを作成するアベイラビリティーゾーン。独自の VPC を指定する場合は、そのアベイラビリティーゾーンにサブネットを指定する必要があります。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

compute.aws.region

インストールプログラムがコンピュートリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。AWS CLI を使用して、選択したインスタンスタイプに基づいて利用可能なリージョンにアクセスできます。以下に例を示します。

aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=c7g.xlarge
重要

ARM ベースの AWS インスタンスで実行する場合は、AWS Graviton プロセッサーが利用可能なリージョンを入力するようにしてください。AWS ドキュメントの グローバルアベイラビリティー マップを参照してください。現在、AWS Graviton3 プロセッサーは一部のリージョンでのみ利用できます。

controlPlane.platform.aws.amiID

クラスターのコントロールプレーンマシンを起動するために使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

controlPlane.platform.aws.iamRole

コントロールプレーンマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

controlPlane.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、特定の KMS キーを使用してコントロールプレーンノードの OS ボリュームを暗号化するために必要です。

有効な キー ID とキー ARN

controlPlane.platform.aws.type

コントロールプレーンマシンの EC2 インスタンスタイプ。

m6i.xlarge などの有効な AWS インスタンスタイプ。次の サポートされている AWS マシンタイプの 表を参照してください。

controlPlane.platform.aws.zones

インストールプログラムがコントロールプレーンマシンプールのマシンを作成するアベイラビリティーゾーン。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

controlPlane.aws.region

インストールプログラムがコントロールプレーンのリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。

platform.aws.amiID

クラスターのすべてのマシンを起動するために使用される AWS AMI。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

platform.aws.hostedZone

クラスターの既存の Route 53 プライベートホストゾーン。独自の VPC を指定する場合も、既存のホストゾーンのみを使用できます。ホストゾーンは、インストール前にユーザーによって提供される VPC に関連付けられている必要があります。また、ホストゾーンのドメインはクラスタードメインまたはクラスタードメインの親である必要があります。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。

文字列 (例: Z3URY6TWQ91KVV)

platform.aws.serviceEndpoints.name

AWS サービスエンドポイント名。カスタムエンドポイントは、FIPS などの AWS の代替エンドポイントを使用しなければならない場合にのみ必要です。カスタム API エンドポイントは、EC2、S3、IAM、Elastic Load Balancing、Tagging、Route 53、および STS AWS サービスに指定できます。

有効な AWS サービスエンドポイント 名。

platform.aws.serviceEndpoints.url

AWS サービスエンドポイント URL。URL には https プロトコルを使用し、ホストは証明書を信頼する必要があります。

有効な AWS サービスエンドポイント URL。

platform.aws.userTags

インストールプログラムが、作成するすべてのリソースに対するタグとして追加するキーと値のマップ。

<key>: <value> 形式のキー値ペアなどの有効な YAML マップ。AWS タグについての詳細は、AWS ドキュメントの Tagging Your Amazon EC2 Resources を参照してください。

platform.aws.subnets

インストールプログラムによる VPC の作成を許可する代わりに VPC を指定する場合は、使用するクラスターのサブネットを指定します。サブネットは、指定する同じ machineNetwork[].cidr 範囲の一部である必要があります。標準クラスターの場合は、各アベイラビリティーゾーンのパブリックおよびプライベートサブネットを指定します。プライベートクラスターについては、各アベイラビリティーゾーンのプライベートサブネットを指定します。

有効なサブネット ID。

5.10.10.2. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

Expand
表5.37 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージIOPS [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. ユーザーによってプロビジョニングされるすべてのインストールと同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

5.10.10.3. AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services(AWS)インスタンスタイプは OpenShift Container Platform でテストされています。

注記

以下のチャートに含まれるマシンタイプを AWS インスタンスに使用します。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。

例5.24 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*
5.10.10.4. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services (AWS) ARM64 インスタンスタイプは OpenShift Container Platform でテストされています。

注記

AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。

例5.25 64 ビット ARM アーキテクチャーに基づくマシンタイプ

  • c6g.*
  • m6g.*
5.10.10.5. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。

apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-gov-west-1a
      - us-gov-west-1b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-gov-west-1c
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-gov-west-1 
13

    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 
14

    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-96c6f8f7 
15

    serviceEndpoints: 
16

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 
17

fips: false 
18

sshKey: ssh-ed25519 AAAA... 
19

publish: Internal 
20

pullSecret: '{"auths": ...}' 
21
1 12 13 21
必須。
2
オプション: このパラメーターを追加して、Cloud Credential Operator (CCO) に認証情報の機能を動的に判別させようとするのではなく、CCO が指定されたモードを使用するように強制します。CCO モードの詳細は、Red Hat Operatorクラウド認証情報 Operatorを参照してください。
3 8
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、 compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して m4.2xlarge または m5.2xlarge などの大規模なインスタンスタイプを使用します。

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、マシンセットを使用して変更できます。

14
独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
15
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
16
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
17
既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
18
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。プロセス暗号化ライブラリーでの FIPS 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

19
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

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

20
クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。
5.10.10.6. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<region>.amazonaws.com,elasticloadbalancing.<region>.amazonaws.com,s3.<region>.amazonaws.com 
    3
    
    additionalTrustBundle: | 
    4
    
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic Load Balancing、および S3 VPC エンドポイントを VPC に追加した場合は、これらのエンドポイントを noProxy フィールドに追加する必要があります。
    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 信頼バンドルからの認証局によって署名されない限り必要になります。
    注記

    インストールプログラムは、プロキシーの 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 オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

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

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

重要

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

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定します。
  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。

手順

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

    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。

  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、または無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

5.10.12. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

5.10.14. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

5.10.15. OpenShift Container Platform の Telemetry アクセス

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

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

5.10.16. 次のステップ

OpenShift Container Platform バージョン 4.11 では、Amazon Web Services (AWS) 上のクラスターを以下のシークレットリージョンにインストールすることができます。

  • シークレット Commercial Cloud Services (SC2S)
  • Commercial Cloud Services (C2S)

いずれかのリージョンでクラスターを設定するには、クラスターをインストールする前に、install config.yaml ファイルのパラメーターを変更します。

5.11.1. 前提条件

5.11.2. AWS シークレットリージョン

次の AWS シークレットパーティションがサポートされています。

  • us-isob-east-1 (SC2S)
  • us-iso-east-1 (C2S)
注記

AWS SC2S および C2S リージョンでサポートされる最大 MTU は、AWS コマーシャルと同じではありません。インストール中の MTU の設定の詳細については、ネットワークをカスタマイズした AWS へのクラスターのインストールクラスターネットワークオペレーターの設定オブジェクト セクションを参照してください。

5.11.3. インストール要件

Red Hat は、AWS Secret およびトップシークレットリージョン用の Red Hat Enterprise Linux CoreOS (RHCOS) Amzaon Machine Image を公開していません。

クラスターをインストールする前に、以下を行う必要があります。

  • カスタム RHCOS AMI をアップロードします。
  • インストール設定ファイル (install-config.yaml) を手動で作成します。
  • インストール設定ファイルで、AWS リージョンおよび付随するカスタム AMI を指定します。

OpenShift Container Platform インストールプログラムを使用してインストール設定ファイルを作成することはできません。インストーラーは RHCOS AMI のネイティブサポートのない AWS リージョンをリスト表示しません。

重要

AWS API にはカスタム CA 信頼バンドルが必要なため、install-config.yaml ファイルの additionalTrustBundle フィールドで、カスタム CA 証明書も定義する必要があります。インストールプログラムが AWS API にアクセスできるようにするには、インストールプログラムを実行するマシンに CA 証明書を定義する必要もあります。CA バンドルをマシンの信頼ストアに追加し、AWS_CA_BUNDLE 環境変数を使用するか、AWS 設定ファイルの ca_bundle フィールドに CA バンドルを定義する必要があります。

5.11.4. プライベートクラスター

外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。

注記

パブリックゾーンは、AWS トップシークレットリージョンの Route 53 ではサポートされていません。したがって、クラスターを AWS トップシークレットリージョンにデプロイする場合は、クラスターをプライベートにする必要があります。

デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。

重要

クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。

プライベートクラスターをデプロイするには、以下を行う必要があります。

  • 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
  • 以下にアクセスできるマシンからデプロイ。

    • プロビジョニングするクラウドの API サービス。
    • プロビジョニングするネットワーク上のホスト。
    • インストールメディアを取得するインターネット。

これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。

5.11.4.1. AWS のプライベートクラスター

Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。

クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。

以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。

  • パブリックサブネット
  • パブリック Ingress をサポートするパブリックロードバランサー
  • クラスターの baseDomain に一致するパブリック Route 53 ゾーン

インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。

5.11.4.1.1. 制限事項

プライベートクラスターにパブリック機能を追加する機能には制限があります。

  • Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
  • パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに kubernetes.io/cluster/<cluster-infra-id>: shared のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。

5.11.5. カスタム VPC の使用について

OpenShift Container Platform 4.11 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) の既存のサブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。

インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。

5.11.5.1. VPC を使用するための要件

インストールプログラムは、以下のコンポーネントを作成しなくなりました。

  • インターネットゲートウェイ
  • NAT ゲートウェイ
  • サブネット
  • ルートテーブル
  • VPC
  • VPC DHCP オプション
  • VPC エンドポイント
注記

インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。

カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC の作成と管理の詳細は、AWS ドキュメントの Amazon VPC コンソールウィザードの設定VPC とサブネットの操作 を参照してください。

インストールプログラムには、以下の機能はありません。

  • 使用するクラスターのネットワーク範囲を細分化する。
  • サブネットのルートテーブルを設定する。
  • DHCP などの VPC オプションを設定する。

クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、 VPC ネットワーキングコンポーネントVPC のルートテーブル を参照してください。

VPC は以下の特性を満たす必要があります。

  • VPC は kubernetes.io/cluster/.*: ownedNameopenshift.io/cluster タグを使用できません。

    インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。

  • VPC で enableDnsSupport および enableDnsHostnames 属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。

    独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。ホストゾーンは、install-config.yaml ファイルの platform.aws.hostedZone フィールドを使用して定義できます。

SC2S または C2S リージョンのクラスターは、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達できません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。

オプション 1: VPC エンドポイントを作成する

VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

SC2S
  • elasticloadbalancing.<region>.sc2s.sgov.gov
  • ec2.<region>.sc2s.sgov.gov
  • s3.<region>.sc2s.sgov.gov
C2S
  • elasticloadbalancing.<region>.c2s.ic.gov
  • ec2.<region>.c2s.ic.gov
  • s3.<region>.c2s.ic.gov

このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。

オプション 2: VPC エンドポイントなしでプロキシーを作成する

インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。

オプション 3: VPC エンドポイントでプロキシーを作成する

インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

SC2S
  • elasticloadbalancing.<region>.sc2s.sgov.gov
  • ec2.<region>.sc2s.sgov.gov
  • s3.<region>.sc2s.sgov.gov
C2S
  • elasticloadbalancing.<region>.c2s.ic.gov
  • ec2.<region>.c2s.ic.gov
  • s3.<region>.c2s.ic.gov

install-config.yaml ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。

必要な VPC コンポーネント

お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。

Expand
コンポーネントAWS タイプ説明

VPC

  • AWS::EC2::VPC
  • AWS::EC2::VPCEndpoint

使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。

パブリックサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::SubnetNetworkAclAssociation

VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。

インターネットゲートウェイ

  • AWS::EC2::InternetGateway
  • AWS::EC2::VPCGatewayAttachment
  • AWS::EC2::RouteTable
  • AWS::EC2::Route
  • AWS::EC2::SubnetRouteTableAssociation
  • AWS::EC2::NatGateway
  • AWS::EC2::EIP

VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。

ネットワークアクセス制御

  • AWS::EC2::NetworkAcl
  • AWS::EC2::NetworkAclEntry

VPC が以下のポートにアクセスできるようにする必要があります。

ポート

理由

80

インバウンド HTTP トラフィック

443

インバウンド HTTPS トラフィック

22

インバウンド SSH トラフィック

1024 - 65535

インバウンド一時 (ephemeral) トラフィック

0 - 65535

アウトバウンド一時 (ephemeral) トラフィック

プライベートサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::RouteTable
  • AWS::EC2::SubnetRouteTableAssociation

VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

5.11.5.2. VPC 検証

指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。

  • 指定したサブネットすべてが存在します。
  • プライベートサブネットを指定します。
  • サブネットの CIDR は指定されたマシン CIDR に属します。
  • 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
  • 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。

既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、 kubernetes.io/cluster/.*: shared タグは、それが使用したサブネットから削除されます。

5.11.5.3. パーミッションの区分

OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。

クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。

5.11.5.4. クラスター間の分離

OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。

  • 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
  • ICMP Ingress はネットワーク全体から許可されます。
  • TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。

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

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

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

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

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

5.11.7. AWS でのカスタム RHCOS AMI のアップロード

カスタム Amazon Web Services (AWS) リージョンにデプロイする場合、そのリージョンに属するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) をアップロードする必要があります。

前提条件

  • AWS アカウントを設定している。
  • 必要な IAM サービスロール で、Amazon S3 バケットを作成している。
  • RHCOS VMDK ファイルを Amazon S3 にアップロードしている。RHCOS VMDK ファイルは、インストールする OpenShift Container Platform のバージョンと同じか、それ以下のバージョンである必要があります。
  • AWS CLI をダウンロードし、これをコンピューターにインストールしている。Install the AWS CLI Using the Bundled Installer を参照してください。

手順

  1. AWS プロファイルを環境変数としてエクスポートします。

    $ export AWS_PROFILE=<aws_profile> 
    1
  2. カスタム AMI に関連付けるリージョンを環境変数としてエクスポートします。

    $ export AWS_DEFAULT_REGION=<aws_region> 
    1
  3. 環境変数として Amazon S3 にアップロードした RHCOS のバージョンをエクスポートします。

    $ export RHCOS_VERSION=<version> 
    1
    1 1 1
    4.11.0 などの RHCOS VMDK バージョン。
  4. Amazon S3 バケット名を環境変数としてエクスポートします。

    $ export VMIMPORT_BUCKET_NAME=<s3_bucket_name>
  5. containers.json ファイルを作成し、RHCOS VMDK ファイルを定義します。

    $ cat <<EOF > containers.json
    {
       "Description": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64",
       "Format": "vmdk",
       "UserBucket": {
          "S3Bucket": "${VMIMPORT_BUCKET_NAME}",
          "S3Key": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64.vmdk"
       }
    }
    EOF
  6. RHCOS ディスクを Amazon EBS スナップショットとしてインポートします。

    $ aws ec2 import-snapshot --region ${AWS_DEFAULT_REGION} \
         --description "<description>" \ 
    1
    
         --disk-container "file://<file_path>/containers.json" 
    2
    1
    rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64 などの RHCOS ディスクがインポートされていることの説明。
    2
    RHCOS ディスクを説明する JSON ファイルへのファイルパス。JSON ファイルには、Amazon S3 バケット名とキーが含まれている必要があります。
  7. イメージインポートのステータスを確認します。

    $ watch -n 5 aws ec2 describe-import-snapshot-tasks --region ${AWS_DEFAULT_REGION}

    出力例

    {
        "ImportSnapshotTasks": [
            {
                "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                "ImportTaskId": "import-snap-fh6i8uil",
                "SnapshotTaskDetail": {
                    "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                    "DiskImageSize": 819056640.0,
                    "Format": "VMDK",
                    "SnapshotId": "snap-06331325870076318",
                    "Status": "completed",
                    "UserBucket": {
                        "S3Bucket": "external-images",
                        "S3Key": "rhcos-4.7.0-x86_64-aws.x86_64.vmdk"
                    }
                }
            }
        ]
    }

    SnapshotId をコピーして、イメージを登録します。

  8. RHCOS スナップショットからカスタム RHCOS AMI を作成します。

    $ aws ec2 register-image \
       --region ${AWS_DEFAULT_REGION} \
       --architecture x86_64 \ 
    1
    
       --description "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ 
    2
    
       --ena-support \
       --name "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ 
    3
    
       --virtualization-type hvm \
       --root-device-name '/dev/xvda' \
       --block-device-mappings 'DeviceName=/dev/xvda,Ebs={DeleteOnTermination=true,SnapshotId=<snapshot_ID>}' 
    4
    1
    x86_64aarch64s390x、または ppc64le などの RHCOS VMDK アーキテクチャータイプ。
    2
    インポートされたスナップショットの Description
    3
    RHCOS AMI の名前。
    4
    インポートされたスナップショットからの SnapshotID

これらの API の詳細は、AWS ドキュメントの Importing a Disk as a Snapshot Using VM Import/Export および Creating a Linux AMI from a snapshot を参照してください。

5.11.8. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。 /openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

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

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

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、ed25519 アルゴリズムを使用するキーは作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  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 パブリックキーをインストールプログラムに指定します。

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

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

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

前提条件

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

手順

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

    $ mkdir <installation_directory>
    重要

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

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

    注記

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

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

    重要

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

5.11.10.1. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

5.11.10.1.1. 必須設定パラメーター

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

Expand
表5.38 必須パラメーター
パラメーター説明

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

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}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"
      }
   }
}
5.11.10.1.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

Expand
表5.39 ネットワークパラメーター
パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

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 です。

OpenShift SDN および 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 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

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

例: 10.0.0.0/16

注記

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

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

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

Expand
表5.40 オプションのパラメーター
パラメーター説明

additionalTrustBundle

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

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

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

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

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

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

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

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

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

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 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

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

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

imageContentSources.source

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

文字列

imageContentSources.mirrors

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

文字列の配列。

publish

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

Internal または External。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。

sshKey

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

注記

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

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

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

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

Expand
表5.41 オプションの AWS パラメーター
パラメーター説明

compute.platform.aws.amiID

クラスターのコンピュートマシンの起動に使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

compute.platform.aws.iamRole

コンピュートマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

compute.platform.aws.rootVolume.iops

ルートボリュームに予約される 1 秒あたりの入出力操作 (IOPS)。

整数 (例: 4000)。

compute.platform.aws.rootVolume.size

ルートボリュームのサイズ (GiB)。

整数 (例: 500)。

compute.platform.aws.rootVolume.type

root ボリュームのタイプです。

有効な AWS EBS ボリュームタイプ (例: io1)。

compute.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、ワーカーノードの OS ボリュームを特定の KMS キーで暗号化するために必要です。

有効な キー ID またはキー ARN

compute.platform.aws.type

コンピュートマシンの EC2 インスタンスタイプ。

有効な AWS インスタンスタイプ (例: m4.2xlarge)。次の サポートされている AWS マシンタイプの 表を参照してください。

compute.platform.aws.zones

インストールプログラムがコンピュートマシンプールのマシンを作成するアベイラビリティーゾーン。独自の VPC を指定する場合は、そのアベイラビリティーゾーンにサブネットを指定する必要があります。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

compute.aws.region

インストールプログラムがコンピュートリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。AWS CLI を使用して、選択したインスタンスタイプに基づいて利用可能なリージョンにアクセスできます。以下に例を示します。

aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=c7g.xlarge
重要

ARM ベースの AWS インスタンスで実行する場合は、AWS Graviton プロセッサーが利用可能なリージョンを入力するようにしてください。AWS ドキュメントの グローバルアベイラビリティー マップを参照してください。現在、AWS Graviton3 プロセッサーは一部のリージョンでのみ利用できます。

controlPlane.platform.aws.amiID

クラスターのコントロールプレーンマシンを起動するために使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

controlPlane.platform.aws.iamRole

コントロールプレーンマシンプールインスタンスのプロファイルに適用される既存の AWS IAM ロール。これらのフィールドを使用して命名スキームに一致させ、IAM ロール用に事前に定義されたパーミッション境界を含めることができます。定義されていない場合は、インストールプログラムは新規の IAM ロールを作成します。

有効な AWS IAM ロール名。

controlPlane.platform.aws.rootVolume.kmsKeyARN

KMS キーの Amazon リソース名 (キー ARN)。これは、特定の KMS キーを使用してコントロールプレーンノードの OS ボリュームを暗号化するために必要です。

有効な キー ID とキー ARN

controlPlane.platform.aws.type

コントロールプレーンマシンの EC2 インスタンスタイプ。

m6i.xlarge などの有効な AWS インスタンスタイプ。次の サポートされている AWS マシンタイプの 表を参照してください。

controlPlane.platform.aws.zones

インストールプログラムがコントロールプレーンマシンプールのマシンを作成するアベイラビリティーゾーン。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

controlPlane.aws.region

インストールプログラムがコントロールプレーンのリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。

platform.aws.amiID

クラスターのすべてのマシンを起動するために使用される AWS AMI。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID については、AWS インフラストラクチャーの RHCOS AMI を参照してください。

platform.aws.hostedZone

クラスターの既存の Route 53 プライベートホストゾーン。独自の VPC を指定する場合も、既存のホストゾーンのみを使用できます。ホストゾーンは、インストール前にユーザーによって提供される VPC に関連付けられている必要があります。また、ホストゾーンのドメインはクラスタードメインまたはクラスタードメインの親である必要があります。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。

文字列 (例: Z3URY6TWQ91KVV)

platform.aws.serviceEndpoints.name

AWS サービスエンドポイント名。カスタムエンドポイントは、FIPS などの AWS の代替エンドポイントを使用しなければならない場合にのみ必要です。カスタム API エンドポイントは、EC2、S3、IAM、Elastic Load Balancing、Tagging、Route 53、および STS AWS サービスに指定できます。

有効な AWS サービスエンドポイント 名。

platform.aws.serviceEndpoints.url

AWS サービスエンドポイント URL。URL には https プロトコルを使用し、ホストは証明書を信頼する必要があります。

有効な AWS サービスエンドポイント URL。

platform.aws.userTags

インストールプログラムが、作成するすべてのリソースに対するタグとして追加するキーと値のマップ。

<key>: <value> 形式のキー値ペアなどの有効な YAML マップ。AWS タグについての詳細は、AWS ドキュメントの Tagging Your Amazon EC2 Resources を参照してください。

platform.aws.subnets

インストールプログラムによる VPC の作成を許可する代わりに VPC を指定する場合は、使用するクラスターのサブネットを指定します。サブネットは、指定する同じ machineNetwork[].cidr 範囲の一部である必要があります。標準クラスターの場合は、各アベイラビリティーゾーンのパブリックおよびプライベートサブネットを指定します。プライベートクラスターについては、各アベイラビリティーゾーンのプライベートサブネットを指定します。

有効なサブネット ID。

5.11.10.2. AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services(AWS)インスタンスタイプは OpenShift Container Platform でテストされています。

注記

以下のチャートに含まれるマシンタイプを AWS インスタンスに使用します。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。

例5.26 シークレット領域の 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • c4.*
  • c5.*
  • i3.*
  • m4.*
  • m5.*
  • r4.*
  • r5.*
  • t3.*
5.11.10.3. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。

apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-iso-east-1a
      - us-iso-east-1b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-iso-east-1a
      - us-iso-east-1b
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-iso-east-1 
13

    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 
14

    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-96c6f8f7 
15
 
16

    serviceEndpoints: 
17

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 
18

fips: false 
19

sshKey: ssh-ed25519 AAAA... 
20

publish: Internal 
21

pullSecret: '{"auths": ...}' 
22

additionalTrustBundle: | 
23

    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
1 12 13 15 22
必須。
2
オプション: このパラメーターを追加して、Cloud Credential Operator (CCO) に認証情報の機能を動的に判別させようとするのではなく、CCO が指定されたモードを使用するように強制します。CCO モードの詳細は、Red Hat Operatorクラウド認証情報 Operatorを参照してください。
3 8
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、 compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して m4.2xlarge または m5.2xlarge などの大規模なインスタンスタイプを使用します。

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、マシンセットを使用して変更できます。

14
独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
16
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
17
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
18
既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
19
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。プロセス暗号化ライブラリーでの FIPS 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

20
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

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

21
クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。
23
カスタム CA 証明書。これは、SC2S または C2S リージョンにデプロイするときに必要です。これは、AWS API がカスタム CA 信頼バンドルを必要とするためです。
5.11.10.4. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<region>.amazonaws.com,elasticloadbalancing.<region>.amazonaws.com,s3.<region>.amazonaws.com 
    3
    
    additionalTrustBundle: | 
    4
    
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic Load Balancing、および S3 VPC エンドポイントを VPC に追加した場合は、これらのエンドポイントを noProxy フィールドに追加する必要があります。
    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 信頼バンドルからの認証局によって署名されない限り必要になります。
    注記

    インストールプログラムは、プロキシーの 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 オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

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

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

重要

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

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定します。
  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。

手順

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

    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。

  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、または無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

5.11.12. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.11 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンメニューでアーキテクチャーを選択します。
  3. Version ドロップダウンメニューで適切なバージョンを選択します。
  4. OpenShift v4.11 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. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.11 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

5.11.14. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

5.11.15. OpenShift Container Platform の Telemetry アクセス

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

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

5.11.16. 次のステップ

5.12. AWS China でのクラスターのアンインストール

OpenShift Container Platform バージョン 4.11 では、クラスターを以下の Amazon Web Services (AWS) 中国リージョンにインストールできます。

  • cn-north-1 (Beijing)
  • cn-northwest-1 (Ningxia)

5.12.1. 前提条件

重要

AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。

5.12.2. インストール要件

Red Hat は、AWS China リージョンの Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) を公開しません。

クラスターをインストールする前に、以下を行う必要があります。

  • カスタム RHCOS AMI をアップロードします。
  • インストール設定ファイル (install-config.yaml) を手動で作成します。
  • インストール設定ファイルで、AWS リージョンおよび付随するカスタム AMI を指定します。

OpenShift Container Platform インストールプログラムを使用してインストール設定ファイルを作成することはできません。インストーラーは RHCOS AMI のネイティブサポートのない AWS リージョンをリスト表示しません。

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

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

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

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

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

5.12.4. プライベートクラスター

外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。

デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。

重要

クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。

プライベートクラスターをデプロイするには、以下を行う必要があります。

  • 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
  • 以下にアクセスできるマシンからデプロイ。

    • プロビジョニングするクラウドの API サービス。
    • プロビジョニングするネットワーク上のホスト。
    • インストールメディアを取得するインターネット。

これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホストを使用できます。

注記

AWS China は、VPC とネットワーク間の VPN 接続をサポートしません。Beijing および Ningxia リージョンの Amazon VPC サービスの詳細は、AWS China ドキュメントの Amazon Virtual Private Cloud を参照してください。

5.12.4.1. AWS のプライベートクラスター

Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。

クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。

以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。

  • パブリックサブネット
  • パブリック Ingress をサポートするパブリックロードバランサー
  • クラスターの baseDomain に一致するパブリック Route 53 ゾーン

インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。

5.12.4.1.1. 制限事項

プライベートクラスターにパブリック機能を追加する機能には制限があります。

  • Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
  • パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに kubernetes.io/cluster/<cluster-infra-id>: shared のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。

5.12.5. カスタム VPC の使用について

OpenShift Container Platform 4.11 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) の既存のサブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。

インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。

5.12.5.1. VPC を使用するための要件

インストールプログラムは、以下のコンポーネントを作成しなくなりました。

  • インターネットゲートウェイ
  • NAT ゲートウェイ
  • サブネット
  • ルートテーブル
  • VPC
  • VPC DHCP オプション
  • VPC エンドポイント
注記

インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。

カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC の作成と管理の詳細は、AWS ドキュメントの Amazon VPC コンソールウィザードの設定VPC とサブネットの操作 を参照してください。

インストールプログラムには、以下の機能はありません。

  • 使用するクラスターのネットワーク範囲を細分化する。
  • サブネットのルートテーブルを設定する。
  • DHCP などの VPC オプションを設定する。

クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、 VPC ネットワーキングコンポーネントVPC のルートテーブル を参照してください。

VPC は以下の特性を満たす必要があります。

  • VPC は kubernetes.io/cluster/.*: ownedNameopenshift.io/cluster タグを使用できません。

    インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。

  • VPC で enableDnsSupport および enableDnsHostnames 属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。

    独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。ホストゾーンは、install-config.yaml ファイルの platform.aws.hostedZone フィールドを使用して定義できます。

非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。

オプション 1: VPC エンドポイントを作成する

VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<region>.amazonaws.com.cn
  • elasticloadbalancing.<region>.amazonaws.com
  • s3.<region>.amazonaws.com

このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。

オプション 2: VPC エンドポイントなしでプロキシーを作成する

インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。

オプション 3: VPC エンドポイントでプロキシーを作成する

インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<region>.amazonaws.com.cn
  • elasticloadbalancing.<region>.amazonaws.com
  • s3.<region>.amazonaws.com

install-config.yaml ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。

必要な VPC コンポーネント

お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。

Expand
コンポーネントAWS タイプ説明

VPC

  • AWS::EC2::VPC
  • AWS::EC2::VPCEndpoint

使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。

パブリックサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::SubnetNetworkAclAssociation

VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。

インターネットゲートウェイ

  • AWS::EC2::InternetGateway
  • AWS::EC2::VPCGatewayAttachment
  • AWS::EC2::RouteTable
  • AWS::EC2::Route
  • AWS::EC2::SubnetRouteTableAssociation
  • AWS::EC2::NatGateway
  • AWS::EC2::EIP

VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。

ネットワークアクセス制御

  • AWS::EC2::NetworkAcl
  • AWS::EC2::NetworkAclEntry

VPC が以下のポートにアクセスできるようにする必要があります。

ポート

理由

80

インバウンド HTTP トラフィック

443

インバウンド HTTPS トラフィック

22

インバウンド SSH トラフィック

1024 - 65535

インバウンド一時 (ephemeral) トラフィック

0 - 65535

アウトバウンド一時 (ephemeral) トラフィック

プライベートサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::RouteTable
  • AWS::EC2::SubnetRouteTableAssociation

VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

5.12.5.2. VPC 検証

指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。

  • 指定したサブネットすべてが存在します。
  • プライベートサブネットを指定します。
  • サブネットの CIDR は指定されたマシン CIDR に属します。
  • 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
  • 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。

既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、 kubernetes.io/cluster/.*: shared タグは、それが使用したサブネットから削除されます。

5.12.5.3. パーミッションの区分

OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。

クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。

5.12.5.4. クラスター間の分離

OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。

  • 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
  • ICMP Ingress はネットワーク全体から許可されます。
  • TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。

5.12.6. クラスターノードの 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 ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、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 パブリックキーをインストールプログラムに指定します。

5.12.7. AWS でのカスタム RHCOS AMI のアップロード

カスタム Amazon Web Services (AWS) リージョンにデプロイする場合、そのリージョンに属するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) をアップロードする必要があります。

前提条件

  • AWS アカウントを設定している。
  • 必要な IAM サービスロール で、Amazon S3 バケットを作成している。
  • RHCOS VMDK ファイルを Amazon S3 にアップロードしている。RHCOS VMDK ファイルは、インストールする OpenShift Container Platform のバージョンと同じか、それ以下のバージョンである必要があります。
  • AWS CLI をダウンロードし、これをコンピューターにインストールしている。Install the AWS CLI Using the Bundled Installer を参照してください。

手順

  1. AWS プロファイルを環境変数としてエクスポートします。

    $ export AWS_PROFILE=<aws_profile> 
    1
    1
    beijingadmin などの AWS 認証情報を保持する AWS プロファイル名。
  2. カスタム AMI に関連付けるリージョンを環境変数としてエクスポートします。

    $ export AWS_DEFAULT_REGION=<aws_region> 
    1
    1
    cn-north-1 などの AWS リージョン
  3. 環境変数として Amazon S3 にアップロードした RHCOS のバージョンをエクスポートします。

    $ export RHCOS_VERSION=<version> 
    1
    1
    4.11.0 などの RHCOS VMDK バージョン。
  4. Amazon S3 バケット名を環境変数としてエクスポートします。

    $ export VMIMPORT_BUCKET_NAME=<s3_bucket_name>
  5. containers.json ファイルを作成し、RHCOS VMDK ファイルを定義します。

    $ cat <<EOF > containers.json
    {
       "Description": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64",
       "Format": "vmdk",
       "UserBucket": {
          "S3Bucket": "${VMIMPORT_BUCKET_NAME}",
          "S3Key": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64.vmdk"
       }
    }
    EOF
  6. RHCOS ディスクを Amazon EBS スナップショットとしてインポートします。

    $ aws ec2 import-snapshot --region ${AWS_DEFAULT_REGION} \
         --description "<description>" \ 
    1
    
         --disk-container "file://<file_path>/containers.json" 
    2
    1
    rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64 などの RHCOS ディスクがインポートされていることの説明。
    2
    RHCOS ディスクを説明する JSON ファイルへのファイルパス。JSON ファイルには、Amazon S3 バケット名とキーが含まれている必要があります。
  7. イメージインポートのステータスを確認します。

    $ watch -n 5 aws ec2 describe-import-snapshot-tasks --region ${AWS_DEFAULT_REGION}

    出力例

    {
        "ImportSnapshotTasks": [
            {
                "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                "ImportTaskId": "import-snap-fh6i8uil",
                "SnapshotTaskDetail": {
                    "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                    "DiskImageSize": 819056640.0,
                    "Format": "VMDK",
                    "SnapshotId": "snap-06331325870076318",
                    "Status": "completed",
                    "UserBucket": {
                        "S3Bucket": "external-images",
                        "S3Key": "rhcos-4.7.0-x86_64-aws.x86_64.vmdk"
                    }
                }
            }
        ]
    }

    SnapshotId をコピーして、イメージを登録します。

  8. RHCOS スナップショットからカスタム RHCOS AMI を作成します。

    $ aws ec2 register-image \
       --region ${AWS_DEFAULT_REGION} \
       --architecture x86_64 \ 
    1
    
       --description "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ 
    2
    
       --ena-support \
       --name "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ 
    3
    
       --virtualization-type hvm \
       --root-device-name '/dev/xvda' \
       --block-device-mappings 'DeviceName=/dev/xvda,Ebs={DeleteOnTermination=true,SnapshotId=<snapshot_ID>}' 
    4
    1
    x86_64aarch64s390x、または ppc64le などの RHCOS VMDK アーキテクチャータイプ。
    2
    インポートされたスナップショットの Description
    3
    RHCOS AMI の名前。
    4
    インポートされたスナップショットからの SnapshotID

これらの API の詳細は、AWS ドキュメントの Importing a Disk as a Snapshot Using VM Import/Export および Creating a Linux AMI from a snapshot を参照してください。

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

OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムをデプロイメントします。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

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

前提条件

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

手順

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

    $ mkdir <installation_directory>
    重要

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

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

    注記

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

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

    重要

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

5.12.9.1. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

5.12.9.1.1. 必須設定パラメーター

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

Expand
表5.42 必須パラメーター
パラメーター説明

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

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}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"
      }
   }
}
5.12.9.1.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

Expand
表5.43 ネットワークパラメーター
パラメーター説明

networking

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

オブジェクト

注記

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

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

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 です。

OpenShift SDN および 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 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

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

例: 10.0.0.0/16

注記

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

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

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

Expand
表5.44 オプションのパラメーター
パラメーター説明

additionalTrustBundle

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

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

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

MachinePool オブジェクトの配列。

compute.architecture

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

文字列

compute.hyperthreading

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

重要

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

Enabled または Disabled

compute.name

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

worker

compute.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

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

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

controlPlane

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

MachinePool オブジェクトの配列。

controlPlane.architecture

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

文字列

controlPlane.hyperthreading

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

重要

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

Enabled または Disabled

controlPlane.name

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

master

controlPlane.platform

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

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

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

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

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

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

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

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 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

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

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

imageContentSources.source

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

文字列

imageContentSources.mirrors

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

文字列の配列。

publish

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

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

このフィールドを Internal に設定することは、クラウド以外のプラットフォームおよび IBM Cloud ではサポートされていません。

重要

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

sshKey

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

注記

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

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

5.12.9.2. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。

apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - cn-north-1a
      - cn-north-1b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - cn-north-1a
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: cn-north-1 
13

    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 
14

    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-96c6f8f7 
15
 
16

    serviceEndpoints: 
17

      - name: ec2
        url: https://vpce-id.ec2.cn-north-1.vpce.amazonaws.com.cn
    hostedZone: Z3URY6TWQ91KVV 
18

fips: false 
19

sshKey: ssh-ed25519 AAAA... 
20

publish: Internal 
21

pullSecret: '{"auths": ...}' 
22
1 12 13 15 22
必須。
2
オプション: このパラメーターを追加して、Cloud Credential Operator (CCO) に認証情報の機能を動的に判別させようとするのではなく、CCO が指定されたモードを使用するように強制します。CCO モードの詳細は、Red Hat Operator