5.5. カスタマイズによる Azure へのクラスターのインストール
OpenShift Container Platform バージョン 4.16 では、インストールプログラムが Microsoft Azure 上にプロビジョニングするインフラストラクチャーに、カスタマイズしたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。
5.5.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- クラスターをホストするように Azure アカウントを設定 し、クラスターをデプロイするテスト済みおよび検証済みのリージョンを決定している。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
- 暗号化のために Azure 環境を準備 した (顧客管理の暗号化キーを使用する場合)。
5.5.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.16 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、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 キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1- 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519など) を指定します。既存のキーペアがある場合は、公開鍵が~/.sshディレクトリーにあることを確認します。
注記x86_64、ppc64le、およびs390xアーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519アルゴリズムを使用するキーを作成しないでください。代わりに、rsaアルゴリズムまたはecdsaアルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub公開鍵を表示します。$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gatherコマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsaおよび~/.ssh/id_dsaなどのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agentプロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)"
出力例
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agentに追加します。$ ssh-add <path>/<file_name> 1- 1
~/.ssh/id_ed25519などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
5.5.4. Azure Marketplace オファリングの使用
Azure Marketplace を使用すると、OpenShift Container Platform クラスターをデプロイできます。これは、Azure を通じて従量課金制 (時間単位、コア単位) で請求され、Red Hat の直接サポートも受けることができます。
Azure Marketplace オファリングを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に Azure Marketplace イメージを取得する必要があります。インストールプログラムは、このイメージを使用してワーカーノードまたはコントロールプレーンノードをデプロイします。イメージを取得するときは、次の点を考慮してください。
-
イメージは同じですが、Azure Marketplace のパブリシャーは地域によって異なります。北米にお住まいの場合は、
redhatをパブリッシャーとして指定してください。EMEA にお住まいの場合は、redhat-limitedをパブリッシャーとして指定してください。 -
このオファーには、
rh-ocp-workerSKU とrh-ocp-worker-gen1SKU が含まれています。rh-ocp-workerSKU は、Hyper-V 世代のバージョン 2 VM イメージを表します。OpenShift Container Platform で使用されるデフォルトのインスタンスタイプは、バージョン 2 と互換性があります。バージョン 1 のみと互換性のあるインスタンスタイプを使用する場合は、rh-ocp-worker-gen1SKU に関連付けられたイメージを使用します。rh-ocp-worker-gen1SKU は、Hyper-V バージョン 1 VM イメージを表します。
Azure マーケットプレイスを使用したイメージのインストールは、64 ビット ARM インスタンスを備えたクラスターではサポートされていません。
前提条件
-
Azure CLI クライアント
(az)をインストールしている。 - お客様の Azure アカウントにはオファーのエンタイトルメントがあり、Azure CLI クライアントを使用してこのアカウントにログインしている。
手順
以下のいずれかのコマンドを実行して、利用可能なすべての OpenShift Container Platform イメージを表示します。
北米:
$ az vm image list --all --offer rh-ocp-worker --publisher redhat -o table
出力例
Offer Publisher Sku Urn Version ------------- -------------- ------------------ -------------------------------------------------------------- ----------------- rh-ocp-worker RedHat rh-ocp-worker RedHat:rh-ocp-worker:rh-ocp-worker:4.15.2024072409 4.15.2024072409 rh-ocp-worker RedHat rh-ocp-worker-gen1 RedHat:rh-ocp-worker:rh-ocp-worker-gen1:4.15.2024072409 4.15.2024072409
EMEA:
$ az vm image list --all --offer rh-ocp-worker --publisher redhat-limited -o table
出力例
Offer Publisher Sku Urn Version ------------- -------------- ------------------ -------------------------------------------------------------- ----------------- rh-ocp-worker redhat-limited rh-ocp-worker redhat-limited:rh-ocp-worker:rh-ocp-worker:4.15.2024072409 4.15.2024072409 rh-ocp-worker redhat-limited rh-ocp-worker-gen1 redhat-limited:rh-ocp-worker:rh-ocp-worker-gen1:4.15.2024072409 4.15.2024072409
注記コンピュートおよびコントロールプレーンノードで利用可能な最新のイメージを使用します。必要に応じて、VM はインストールプロセスの一部として自動的にアップグレードされます。
次のいずれかのコマンドを実行して、オファーのイメージを調べます。
北米:
$ az vm image show --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
EMEA:
$ az vm image show --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
次のコマンドのいずれかを実行して、オファーの条件を確認します。
北米:
$ az vm image terms show --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
EMEA:
$ az vm image terms show --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
次のコマンドのいずれかを実行して、オファリングの条件に同意します。
北米:
$ az vm image terms accept --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
EMEA:
$ az vm image terms accept --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
-
オファーのイメージの詳細を記録します。クラスターをデプロイする前に、
install-config.yamlファイルのcomputeセクションを、publisher、offer、sku、およびversionの値で更新する必要があります。また、controlPlaneセクションを更新して、指定されたイメージの詳細を持つコントロールプレーンマシンをデプロイしたり、defaultMachinePlatformセクションを更新して、指定されたイメージの詳細を持つコントロールプレーンとコンピュートマシンの両方をデプロイしたりすることもできます。コントロールプレーンとコンピュートノードには、利用可能な最新のイメージを使用します。
Azure Marketplace コンピュートノードが含まれるサンプル install-config.yaml ファイル
apiVersion: v1
baseDomain: example.com
compute:
- hyperthreading: Enabled
name: worker
platform:
azure:
type: Standard_D4s_v5
osImage:
publisher: redhat
offer: rh-ocp-worker
sku: rh-ocp-worker
version: 413.92.2023101700
replicas: 3
5.5.5. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
5.5.6. インストール設定ファイルの作成
Microsoft Azure にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- Azure サブスクリプション ID とテナント ID がある。
- サービスプリンシパルを使用してクラスターをインストールしている場合は、そのアプリケーション ID とパスワードが必要です。
- システムが割り当てたマネージド ID を使用してクラスターをインストールしている場合は、インストールプログラムを実行する仮想マシン上でそれが有効になっています。
ユーザーが割り当てたマネージド ID を使用してクラスターをインストールしている場合は、次の前提条件を満たしている必要があります。
- そのクライアント ID がある。
- これは、インストールプログラムを実行する仮想マシンに割り当てられている。
手順
オプション: 以前にこのコンピューターでインストールプログラムを実行したことがあり、代替のサービスプリンシパルまたはマネージド ID を使用する場合は、
~/.azure/ディレクトリーに移動して、osServicePrincipal.json設定ファイルを削除します。このファイルを削除すると、インストールプログラムが以前のインストールのサブスクリプション値と認証値を自動的に再利用できなくなります。
install-config.yamlファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1- 1
<installation_directory>の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。ターゲットに設定するプラットフォームとして azure を選択します。
インストールプログラムが以前のインストールの
osServicePrincipal.json設定ファイルを見つけることができない場合は、Azure サブスクリプションと認証の値の入力を求められます。サブスクリプションの次の Azure パラメーター値を入力します。
- azure subscription id: クラスターに使用するサブスクリプション ID を入力します。
- azure tenant id: テナント ID を入力します。
クラスターのデプロイに使用している Azure ID に応じて、azure サービスプリンシパルのクライアント ID の入力を求められたら、次のいずれかを行います。
- サービスプリンシパルを使用している場合は、そのアプリケーション ID を入力します。
- システム割り当てのマネージド ID を使用している場合は、この値を空白のままにします。
- ユーザー割り当てのマネージド ID を使用している場合は、そのクライアント ID を指定します。
クラスターのデプロイに使用している Azure ID に応じて、azure サービスプリンシパルのクライアントシークレット の入力を求められたら、次のいずれかを実行します。
- サービスプリンシパルを使用している場合は、そのパスワードを入力します。
- システム割り当てのマネージド ID を使用している場合は、この値を空白のままにします。
- ユーザー割り当てのマネージド ID を使用している場合は、この値を空白のままにします。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成した Azure DNS ゾーンに対応します。
クラスターの記述名を入力します。
重要パブリックエンドポイントで利用可能なすべての Azure リソースはリソース名の制限を受けるため、特定の用語を使用するリソースを作成することはできません。Azure が制限する用語のリストは、Azure ドキュメントの 予約されたリソース名のエラーを解決する を参照してください。
install-config.yamlファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。注記3 ノードクラスターをインストールする場合は、必ず
compute.replicasパラメーターを0に設定してください。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細は、「Azure に 3 ノードクラスターをインストールする」を参照してください。install-config.yamlファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yamlファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
以前に検出されなかった場合は、インストールプログラムが osServicePrincipal.json 設定ファイルを作成し、このファイルをコンピューターの ~/.azure/ ディレクトリーに保存します。これにより、インストールプログラムがターゲットプラットフォーム上で OpenShift Container Platform クラスターを作成するときにプロファイルをロードできるようになります。
5.5.6.1. クラスターインストールの最小リソース要件
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (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 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
OpenShift Container Platform バージョン 4.13 の時点で、RHCOS は RHEL バージョン 9.2 に基づいており、マイクロアーキテクチャーの要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。
- x86-64 アーキテクチャーには x86-64-v2 ISA が必要
- ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
- IBM Power アーキテクチャーには Power 9 ISA が必要
- s390x アーキテクチャーには z14 ISA が必要
詳細は、RHEL アーキテクチャー を参照してください。
premiumIO パラメーターが true に設定されている Azure 仮想マシンを使用する必要があります。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
関連情報
5.5.6.2. Azure のテスト済みインスタンスタイプ
以下の Microsoft Azure インスタンスタイプは OpenShift Container Platform でテストされています。
例5.24 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.* -
c5.* -
c5a.* -
i3.* -
m4.* -
m5.* -
m5a.* -
m6a.* -
m6i.* -
r4.* -
r5.* -
r5a.* -
r6i.* -
t3.* -
t3a.*
5.5.6.3. 64 ビット ARM インフラストラクチャー上の Azure のテスト済みインスタンスタイプ
以下の Microsoft Azure Azure64 インスタンスタイプは OpenShift Container Platform でテストされています。
例5.25 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.* -
c7g.* -
m6g.* -
m7g.* -
r8g.*
5.5.6.4. Azure VM の信頼された起動の有効化
Azure にクラスターをインストールするときに、セキュアブート と 仮想化された信頼できるプラットフォームモジュール という 2 つの信頼された起動機能を有効にできます。
これらの機能をサポートする 仮想マシンのサイズ については、仮想マシンのサイズに関する Azure のドキュメントを参照してください。
信頼できる起動はテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
-
install-config.yamlファイルを作成しました。
手順
クラスターをデプロイする前に、テキストエディターを使用して
install-config.yamlファイルを編集し、次のスタンザを追加します。controlPlane: 1 platform: azure: settings: securityType: TrustedLaunch 2 trustedLaunch: uefiSettings: secureBoot: Enabled 3 virtualizedTrustedPlatformModule: Enabled 4
- 1
controlPlane.platform.azureまたはcompute.platform.azureを指定すると、それぞれコントロールプレーンまたはコンピュートノードのみで信頼された起動が有効になります。すべてのノードで信頼できる起動を有効にするには、platform.azure.defaultMachinePlatformを指定します。- 2
- 信頼できる起動機能を有効にします。
- 3
- Secure Boot を有効にします。詳細は、セキュアブート に関する Azure ドキュメントを参照してください。
- 4
- 仮想化された Trusted Platform Module を有効にします。詳細は、仮想化された Trusted Platform Module に関する Azure のドキュメントを参照してください。
5.5.6.5. Confidential VM の有効化
クラスターをインストールするときに、Confidential VM を有効にできます。コンピューティングノード、コンピュートノード、またはすべてのノードに対して Confidential VM を有効にできます。
Confidential VM の使用はテクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
次の仮想マシンサイズの Confidential VM を使用できます。
- DCasv5 シリーズ
- DCadsv5 シリーズ
- ECasv5 シリーズ
- ECadsv5 シリーズ
現在、Confidential VM は 64 ビット ARM アーキテクチャーではサポートされていません。
前提条件
-
install-config.yamlファイルを作成しました。
手順
クラスターをデプロイする前に、テキストエディターを使用して
install-config.yamlファイルを編集し、次のスタンザを追加します。controlPlane: 1 platform: azure: settings: securityType: ConfidentialVM 2 confidentialVM: uefiSettings: secureBoot: Enabled 3 virtualizedTrustedPlatformModule: Enabled 4 osDisk: securityProfile: securityEncryptionType: VMGuestStateOnly 5
- 1
controlPlane.platform.azureまたはcompute.platform.azureを指定して、それぞれコントロールプレーンまたはコンピュートノードのみに Confidential VM をデプロイします。すべてのノードに Confidential VM をデプロイするには、platform.azure.defaultMachinePlatformを指定します。- 2
- Confidential VM を有効にします。
- 3
- Secure Boot を有効にします。詳細は、セキュアブート に関する Azure ドキュメントを参照してください。
- 4
- 仮想化された Trusted Platform Module を有効にします。詳細は、仮想化された Trusted Platform Module に関する Azure のドキュメントを参照してください。
- 5
- 仮想マシンゲストの状態を暗号化するには、
VMGuestStateOnlyを指定します。
5.5.6.6. Azure のカスタマイズされた install-config.yaml ファイルのサンプル
install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com 1 controlPlane: 2 hyperthreading: Enabled 3 4 name: master platform: azure: encryptionAtHost: true ultraSSDCapability: Enabled osDisk: diskSizeGB: 1024 5 diskType: Premium_LRS diskEncryptionSet: resourceGroup: disk_encryption_set_resource_group name: disk_encryption_set_name subscriptionId: secondary_subscription_id osImage: publisher: example_publisher_name offer: example_image_offer sku: example_offer_sku version: example_image_version type: Standard_D8s_v3 replicas: 3 compute: 6 - hyperthreading: Enabled 7 name: worker platform: azure: ultraSSDCapability: Enabled type: Standard_D2s_v3 encryptionAtHost: true osDisk: diskSizeGB: 512 8 diskType: Standard_LRS diskEncryptionSet: resourceGroup: disk_encryption_set_resource_group name: disk_encryption_set_name subscriptionId: secondary_subscription_id osImage: publisher: example_publisher_name offer: example_image_offer sku: example_offer_sku version: example_image_version zones: 9 - "1" - "2" - "3" replicas: 5 metadata: name: test-cluster 10 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes 11 serviceNetwork: - 172.30.0.0/16 platform: azure: defaultMachinePlatform: osImage: 12 publisher: example_publisher_name offer: example_image_offer sku: example_offer_sku version: example_image_version ultraSSDCapability: Enabled baseDomainResourceGroupName: resource_group 13 region: centralus 14 resourceGroupName: existing_resource_group 15 outboundType: Loadbalancer cloudName: AzurePublicCloud pullSecret: '{"auths": ...}' 16 fips: false 17 sshKey: ssh-ed25519 AAAA... 18
- 1 10 14 16
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 6
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 7
controlPlaneセクションは単一マッピングですが、computeセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、computeセクションの最初の行はハイフン-で始め、controlPlaneセクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 4
- 同時マルチスレッドまたは
hyperthreadingを有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabledに設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
Standard_D8s_v3などの大規模な仮想マシンタイプを使用します。 - 5 8
- 使用するディスクのサイズは、GB 単位で指定できます。コントロールプレーンノードの最小推奨値は 1024 GB です。
- 9
- マシンをデプロイするゾーンのリストを指定します。高可用性を確保するには、少なくとも 2 つのゾーンを指定します。
- 11
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetesのみです。 - 12
- オプション: コントロールプレーンとコンピュートマシンを起動するために使用するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) イメージ。
platform.azure.defaultMachinePlatform.osImageの下のpublisher、offer、sku、およびversionパラメーターは、コントロールプレーンとコンピュートマシンの両方に適用されます。controlPlane.platform.azure.osImageまたはcompute.platform.azure.osImageの下のパラメーターが設定されている場合、それらはplatform.azure.defaultMachinePlatform.osImageパラメーターをオーバーライドします。 - 13
- ベースドメインの DNS ゾーンが含まれるリソースグループの名前を指定します。
- 15
- クラスターをインストールする既存のリソースグループの名前を指定します。定義されていない場合は、クラスターに新しいリソースグループが作成されます。
- 17
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
- 18
- クラスター内のマシンにアクセスするために使用する
sshKey値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。
5.5.6.7. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yamlファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: example.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージするtrusted-ca-bundle設定マップを作成し、この設定マップはProxyオブジェクトのtrustedCAフィールドで参照されます。additionalTrustBundleフィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。 - 5
- オプション：
trustedCAフィールドのuser-ca-bundle設定マップを参照するProxyオブジェクトの設定を決定するポリシー。許可される値はProxyonlyおよびAlwaysです。Proxyonlyを使用して、http/httpsプロキシーが設定されている場合にのみuser-ca-bundle設定マップを参照します。Alwaysを使用して、常にuser-ca-bundle設定マップを参照します。デフォルト値はProxyonlyです。
注記インストールプログラムは、プロキシーの
readinessEndpointsフィールドをサポートしません。注記インストーラーがタイムアウトした場合は、インストーラーの
wait-forコマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。$ ./openshift-install wait-for install-complete --log-level debug
- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
関連情報
- 高速ネットワークの詳細は、Accelerated Networking for Microsoft Azure VMs を参照してください。
5.5.7. Azure のユーザー定義タグを設定する
OpenShift Container Platform では、タグを使用して、リソースをグループ化し、リソースへのアクセスとコストを管理できます。install-config.yaml ファイルで Azure リソースのタグを定義できるのは、OpenShift Container Platform クラスターの作成時のみです。クラスターの作成後は、ユーザー定義タグを変更することはできません。
ユーザー定義タグのサポートは、Azure Public Cloud で作成されたリソースでのみ利用できます。ユーザー定義タグは、OpenShift Container Platform 4.16 にアップグレードされた OpenShift Container Platform クラスターではサポートされていません。
ユーザー定義および OpenShift Container Platform 固有タグは、OpenShift Container Platform インストーラーとそのコアオペレーター (マシン API プロバイダーの Azure Operator、Cluster Ingress Operator、Cluster Image Registry Operator など) によって作成されたリソースのみに適用されます。
デフォルトでは、OpenShift Container Platform インストーラーは、OpenShift Container Platform タグを Azure リソースにアタッチします。ユーザーは、これらの OpenShift Container Platform タグにアクセスできません。
次の install-config.yaml ファイルに示すように、install-config.yaml ファイルの .platform.azure.userTags フィールドを使用して、ユーザー定義タグのリストを定義できます。
install-config.yaml ファイルのサンプル
additionalTrustBundlePolicy: Proxyonly 1 apiVersion: v1 baseDomain: catchall.azure.devcluster.openshift.com 2 compute: 3 - architecture: amd64 hyperthreading: Enabled 4 name: worker platform: {} replicas: 3 controlPlane: 5 architecture: amd64 hyperthreading: Enabled 6 name: master platform: {} replicas: 3 metadata: creationTimestamp: null name: user 7 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes 8 serviceNetwork: - 172.30.0.0/16 platform: azure: baseDomainResourceGroupName: os4-common 9 cloudName: AzurePublicCloud 10 outboundType: Loadbalancer region: southindia 11 userTags: 12 createdBy: user environment: dev
- 1
- 信頼バンドルポリシーを定義します。
- 2
- 必須。
baseDomainパラメーターは、クラウドプロバイダーのベースドメインを指定します。インストールプログラムはこの値の入力を求めるプロンプトを出します。 - 3
- コンピュートを構成するマシンの設定。
computeセクションはマッピングのシーケンスです。異なるデータ構造の要件を満たすには、computeセクションの最初の行がハイフン-で始まる必要があります。これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。 - 4
- 同時マルチスレッドまたは
hyperthreadingを有効または無効にします。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabledに設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。 - 5
- コントロールプレーンを構成するマシンの設定。
controlPlaneセクションは単一のマッピングです。controlPlaneセクションの最初の行は、ハイフン-を使用しないでください。1 つのコントロールプレーンプールのみを使用できます。これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。 - 6
- 同時マルチスレッドまたは
hyperthreadingを有効または無効にします。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabledに設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。 - 7
- インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 8
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetesのみです。 - 9
- Azure DNS ゾーンのベースドメインのリソースグループを指定します。
- 10
- Azure クラウド環境の名前を指定します。
cloudNameフィールドを使用して、Azure API エンドポイントで Azure SDK を設定できます。値を指定しない場合、デフォルト値は、Azure Public Cloud です。 - 11
- 必須。クラスターをホストする Azure リージョンの名前を指定します。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 12
- インストールプログラムが作成するすべての Azure リソースにタグとして追加する追加のキーと値を定義します。
ユーザー定義タグには、次の制限があります。
- タグキーは最大 128 文字です。
- タグキーは文字で始まり、文字、数字、またはアンダースコアで終わる必要があり、文字、数字、アンダースコア、ピリオド、およびハイフンのみを含めることができます。
- タグキーは大文字と小文字を区別しません。
-
タグキーを
nameにすることはできません。kubernetes.io、openshift.io、microsoft、azure、およびwindowsなどの接頭辞を付けることはできません。 - タグ値は最大 256 文字です。
- リソースグループとリソースに最大 10 個のタグを設定できます。
Azure タグの詳細は、Azure のユーザー定義タグ を参照してください。
5.5.8. Azure のユーザー定義タグのクエリー
OpenShift Container Platform クラスターを作成したら、Azure リソース用に定義されたタグのリストにアクセスできます。OpenShift Container Platform タグの形式は、kubernetes.io_cluster.<cluster_id>:owned です。cluster_id パラメーターは、config.openshift.io/Infrastructure にある .status.infrastructureName の値です。
次のコマンドを実行して、Azure リソース用に定義されたタグをクエリーします。
$ oc get infrastructures.config.openshift.io cluster -o=jsonpath-as-json='{.status.platformStatus.azure.resourceTags}'出力例
[ [ { "key": "createdBy", "value": "user" }, { "key": "environment", "value": "dev" } ] ]
5.5.9. OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために OpenShift CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.16 のすべてのコマンドを実行することはできません。新しいバージョンの oc をダウンロードしてインストールしてください。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.16 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvf <file>
ocバイナリーを、PATHにあるディレクトリーに配置します。PATHを確認するには、以下のコマンドを実行します。$ echo $PATH
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.16 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
ocバイナリーを、PATHにあるディレクトリーに移動します。PATHを確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.16 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.16 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
ocバイナリーをパスにあるディレクトリーに移動します。PATHを確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
検証
ocコマンドを使用してインストールを確認します。$ oc <command>
5.5.10. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system プロジェクトに保存されます。install-config.yaml ファイルの credentialsMode パラメーターを Manual に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように Azure クラスターを設定する の手順に従ってください。
5.5.10.1. 長期認証情報を手動で作成する
Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system namespace に管理者レベルの認証情報シークレットを保存しないようにします。
手順
install-config.yaml設定ファイルのcredentialsModeパラメーターをManualに設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
apiVersion: v1 baseDomain: example.com credentialsMode: Manual # ...
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ openshift-install create manifests --dir <installation_directory>
ここで、
<installation_directory>は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE変数に設定します。$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequestカスタムリソース (CR) のリストを抽出します。$ oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \1 --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2 --to=<path_to_directory_for_credentials_requests> 3
このコマンドにより、それぞれの
CredentialsRequestオブジェクトに 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: AzureProviderSpec roleBindings: - role: Contributor ...以前に生成した
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: AzureProviderSpec roleBindings: - role: Contributor ... secretRef: name: <component_secret> namespace: <component_namespace> ...サンプル
SecretオブジェクトapiVersion: v1 kind: Secret metadata: name: <component_secret> namespace: <component_namespace> data: azure_subscription_id: <base64_encoded_azure_subscription_id> azure_client_id: <base64_encoded_azure_client_id> azure_client_secret: <base64_encoded_azure_client_secret> azure_tenant_id: <base64_encoded_azure_tenant_id> azure_resource_prefix: <base64_encoded_azure_resource_prefix> azure_resourcegroup: <base64_encoded_azure_resourcegroup> azure_region: <base64_encoded_azure_region>
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
5.5.10.2. 短期認証情報を使用するように Azure クラスターを設定する
Microsoft Entra Workload ID を使用するクラスターをインストールするには、Cloud Credential Operator ユーティリティーを設定し、クラスターに必要な Azure リソースを作成する必要があります。
5.5.10.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl) バイナリーを抽出して準備します。
ccoctl ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc) がインストールされている。
次の権限で使用する
ccoctlユーティリティー用のグローバル Microsoft Azure アカウントが作成されました。例5.26 必要な Azure 権限
- Microsoft.Resources/subscriptions/resourceGroups/read
- Microsoft.Resources/subscriptions/resourceGroups/write
- Microsoft.Resources/subscriptions/resourceGroups/delete
- Microsoft.Authorization/roleAssignments/read
- Microsoft.Authorization/roleAssignments/delete
- Microsoft.Authorization/roleAssignments/write
- Microsoft.Authorization/roleDefinitions/read
- Microsoft.Authorization/roleDefinitions/write
- Microsoft.Authorization/roleDefinitions/delete
- Microsoft.Storage/storageAccounts/listkeys/action
- Microsoft.Storage/storageAccounts/delete
- Microsoft.Storage/storageAccounts/read
- Microsoft.Storage/storageAccounts/write
- Microsoft.Storage/storageAccounts/blobServices/containers/write
- Microsoft.Storage/storageAccounts/blobServices/containers/delete
- Microsoft.Storage/storageAccounts/blobServices/containers/read
- Microsoft.ManagedIdentity/userAssignedIdentities/delete
- Microsoft.ManagedIdentity/userAssignedIdentities/read
- Microsoft.ManagedIdentity/userAssignedIdentities/write
- Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/read
- Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write
- Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/delete
- Microsoft.Storage/register/action
- Microsoft.ManagedIdentity/register/action
手順
次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
$ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
注記$RELEASE_IMAGEのアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctlバイナリーを抽出します。$ oc image extract $CCO_IMAGE \ --file="/usr/bin/ccoctl.<rhel_version>" \1 -a ~/.pull-secret- 1
<rhel_version>には、ホストが使用する Red Hat Enterprise Linux (RHEL) のバージョンに対応する値を指定します。値が指定されていない場合は、デフォルトでccoctl.rhel8が使用されます。次の値が有効です。-
rhel8: RHEL 8 を使用するホストの場合はこの値を指定します。 -
rhel9: RHEL 9 を使用するホストの場合はこの値を指定します。
-
次のコマンドを実行して、権限を変更して
ccoctlを実行可能にします。$ chmod 775 ccoctl.<rhel_version>
検証
ccoctlが使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。$ ./ccoctl.rhel9
出力例
OpenShift credentials provisioning tool Usage: ccoctl [command] Available Commands: aws Manage credentials objects for AWS cloud azure Manage credentials objects for Azure gcp Manage credentials objects for Google cloud help Help about any command ibmcloud Manage credentials objects for IBM Cloud nutanix Manage credentials objects for Nutanix Flags: -h, --help help for ccoctl Use "ccoctl [command] --help" for more information about a command.
5.5.10.2.2. Cloud Credential Operator ユーティリティーを使用した Azure リソースの作成
ccoctl azure create-all コマンドを使用して、Azure リソースの作成を自動化できます。
デフォルトで、ccoctl はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir フラグを使用します。この手順では、<path_to_ccoctl_output_dir> を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctlバイナリーを抽出して準備している。 - Azure CLI を使用して Microsoft Azure アカウントにアクセスします。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE変数に設定します。$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequestオブジェクトのリストを抽出します。$ oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \1 --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2 --to=<path_to_directory_for_credentials_requests> 3
注記このコマンドの実行には少し時間がかかる場合があります。
ccoctlユーティリティーが Azure 認証情報を自動的に検出できるようにするには、次のコマンドを実行して Azure CLI にログインします。$ az login
次のコマンドを実行し、
ccoctlツールを使用してCredentialsRequestオブジェクトをすべて処理します。$ ccoctl azure create-all \ --name=<azure_infra_name> \1 --output-dir=<ccoctl_output_dir> \2 --region=<azure_region> \3 --subscription-id=<azure_subscription_id> \4 --credentials-requests-dir=<path_to_credentials_requests_directory> \5 --dnszone-resource-group-name=<azure_dns_zone_resource_group_name> \6 --tenant-id=<azure_tenant_id> 7
- 1
- トラッキングに使用される、作成されたすべての Azure リソースのユーザー定義名を指定します。
- 2
- オプション:
ccoctlユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。 - 3
- クラウドリソースが作成される Azure リージョンです。
- 4
- 使用する Azure サブスクリプション ID を指定します。
- 5
- コンポーネント
CredentialsRequestオブジェクトのファイルを含むディレクトリーを指定します。 - 6
- クラスターのベースドメイン Azure DNS ゾーンを含むリソースグループの名前を指定します。
- 7
- 使用する Azure テナント ID を指定します。
注記クラスターで
TechPreviewNoUpgrade機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-previewパラメーターを含める必要があります。追加のオプションパラメーターとその使用方法の説明を表示するには、
azure create-all --helpコマンドを実行します。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifestsディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
azure-ad-pod-identity-webhook-config.yaml cluster-authentication-02-config.yaml openshift-cloud-controller-manager-azure-cloud-credentials-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capz-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-azure-disk-credentials-credentials.yaml openshift-cluster-csi-drivers-azure-file-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-azure-cloud-credentials-credentials.yaml
Azure をクエリーすることで、Microsoft Entra ID サービスアカウントが作成されていることを確認できます。詳細は、Entra ID サービスアカウントのリストに関する Azure ドキュメントを参照してください。
5.5.10.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み
個々のコンポーネントに対してクラスターの外部で管理される短期セキュリティー認証情報を実装するには、Cloud Credential Operator ユーティリティー (ccoctl) が作成したマニフェストファイルを、インストールプログラムの正しいディレクトリーに移動する必要があります。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
-
Cloud Credential Operator ユーティリティー (
ccoctl) が設定されている。 -
ccoctlユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。
手順
install-config.yaml設定ファイルのcredentialsModeパラメーターをManualに設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
apiVersion: v1 baseDomain: example.com credentialsMode: Manual # ...
既存のリソースグループを使用する代わりに、
ccoctlユーティリティーを使用して新しい Azure リソースグループを作成した場合は、次のようにinstall-config.yamlのresourceGroupNameパラメーターを変更します。設定ファイルのサンプルスニペット
apiVersion: v1 baseDomain: example.com # ... platform: azure: resourceGroupName: <azure_infra_name> 1 # ...- 1
- この値は、
ccoctl azure create-allコマンドの--name引数で指定された Azure リソースのユーザー定義名と一致する必要があります。
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ openshift-install create manifests --dir <installation_directory>
ここで、
<installation_directory>は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、
ccoctlユーティリティーが生成したマニフェストを、インストールプログラムが作成したmanifestsディレクトリーにコピーします。$ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
秘密鍵を含む
tlsディレクトリーをインストールディレクトリーにコピーします。$ cp -a /<path_to_ccoctl_output_dir>/tls .
5.5.11. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- Azure サブスクリプション ID とテナント ID がある。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadminユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.logにも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com INFO Login to the console with user: "kubeadmin", and password: "password" INFO Time elapsed: 36m22s
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
5.5.12. CLI の使用によるクラスターへのログイン
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
ocCLI をインストールしていること。
手順
kubeadmin認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1- 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
ocコマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
5.5.13. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.16 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニタリング を参照してください。
5.5.14. 次のステップ
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
