4.3. installer-provisioned infrastructure
4.3.1. AWS にクラスターをインストールする準備
以下の手順を実行して、AWS に OpenShift Container Platform クラスターをインストールする準備をします。
- クラスターのインターネット接続を検証します。
- AWS アカウントを設定します。
インストールプログラムをダウンロードします。
注記非接続環境にインストールする場合は、ミラーリングしたコンテンツからインストールプログラムを抽出します。詳細は、非接続インストール用のイメージのミラーリング を参照してください。
OpenShift CLI (
oc
) をインストールします。注記非接続環境にインストールする場合は、ミラーホストに
oc
をインストールします。- SSH キーペアを生成します。OpenShift Container Platform クラスターのデプロイ後にこのキーペアを使用して、クラスターのノードに対する認証を行うことができます。
-
クラウドアイデンティティーおよびアクセス管理 (IAM) API が環境内でアクセスできない場合、または管理者レベルの認証情報シークレットを
kube-system
namespace に保存しない場合は、AWS の長期認証情報を手動で作成 するか、Amazon Web Services Security Token Service (AWS STS) で 短期認証情報を使用するように AWS クラスターを設定 します。
4.3.1.1. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.16 では、クラスターのインストールに必要なイメージを取得するために、インターネットにアクセスする必要があります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
4.3.1.2. インストールプログラムの取得
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 など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
4.3.1.3. OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために OpenShift CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.16 のすべてのコマンドを実行することはできません。新しいバージョンの oc
をダウンロードしてインストールしてください。非接続環境でのクラスターを更新する場合は、更新する予定の 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>
4.3.1.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 キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の 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 パブリックキーをインストールプログラムに指定します。
4.3.1.5. 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 サービスの詳細は、リモートヘルスモニタリング を参照してください。
4.3.2. AWS へのクラスターのインストール
OpenShift Container Platform バージョン 4.16 では、デフォルトの設定オプションを使用するクラスターを Amazon Web Services (AWS) にインストールできます。
4.3.2.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.3.2.2. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
-
ディレクトリーに
プロンプト時に値を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして aws を選択します。
Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
注記AWS アクセスキー ID およびシークレットアクセスキーは、インストールホストの現行ユーザーのホームディレクトリーの
~/.aws/credentials
に保存されます。エクスポートされたプロファイルの認証情報がファイルにない場合は、インストールプログラムにより認証情報の入力が求めるプロンプトが出されます。インストールプログラムに指定する認証情報は、ファイルに保存されます。- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
オプション: クラスターのインストールに使用した 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
関連情報
- AWS プロファイルおよび認証情報の設定の詳細は、AWS ドキュメントの Configuration and credential file settings を参照してください。
4.3.2.3. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
4.3.2.4. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。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
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.3.2.5. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
4.3.3. カスタマイズによる AWS へのクラスターのインストール
OpenShift Container Platform バージョン 4.16 では、インストールプログラムが Amazon Web Services (AWS) 上にプロビジョニングするインフラストラクチャーにカスタマイズしたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
OpenShift Container Platform インストール設定のスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後にさらに多くの OpenShift Container Platform 設定タスクを実行することができます。
4.3.3.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.3.3.2. AWS Marketplace イメージの取得
AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがコンピュートノードのデプロイに使用する AMI ID が提供されます。
前提条件
- オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。
手順
- AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
ご使用の AWS リージョンの 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": ...}'
4.3.3.3. インストール設定ファイルの作成
Amazon Web Services (AWS) での OpenShift Container Platform のインストールをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
-
ミラーレジストリーの作成時に生成された
imageContentSources
値がある。 - ミラーレジストリーの証明書の内容を取得している。
手順
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 キーを指定します。- ターゲットに設定するプラットフォームとして AWS を選択します。
- Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
クラスターの記述名を入力します。
注記3 ノードクラスターをインストールする場合は、必ず
compute.replicas
パラメーターを0
に設定してください。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細は、「AWS に 3 ノードクラスターをインストールする」を参照してください。
install-config.yaml
ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。pullSecret
の値を更新して、レジストリーの認証情報を追加します。pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'
<mirror_host_name>
の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials>
の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。additionalTrustBundle
パラメーターおよび値を追加します。additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----
この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。
クラスターをインストールする VPC のサブネットを定義します。
subnets: - subnet-1 - subnet-2 - subnet-3
次の YAML の抜粋のようなイメージコンテンツリソースを追加します。
imageContentSources: - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: quay.io/openshift-release-dev/ocp-release - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: registry.redhat.io/ocp/release
これらの値には、ミラーレジストリーの作成時に記録された
imageContentSources
を使用します。オプション: パブリッシュストラテジーを
Internal
に設定します。publish: Internal
このオプションを設定すると、内部 Ingress コントローラーおよびプライベートロードバランサーを作成します。
必要な
install-config.yaml
ファイルに他の変更を加えます。パラメーターの詳細は、「インストール設定パラメーター」を参照してください。
install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
関連情報
4.3.3.3.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 アーキテクチャー を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
関連情報
4.3.3.3.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.18 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
4.3.3.3.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例4.19 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
4.3.3.3.4. 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: OVNKubernetes 13 serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-west-2 14 propagateUserTags: true 15 userTags: adminContact: jdoe costCenter: 7536 subnets: 16 - subnet-1 - subnet-2 - subnet-3 amiID: ami-0c5d3e03c0ab9b19a 17 serviceEndpoints: 18 - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV 19 fips: false 20 sshKey: ssh-ed25519 AAAA... 21 pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' 22 additionalTrustBundle: | 23 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- imageContentSources: 24 - 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 14
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2
- オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は
kube-system
namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。 - 3 8 15
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 5 9
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
m4.2xlarge
またはm5.2xlarge
などの大規模なインスタンスタイプを使用します。 - 6 10
- 大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを
io1
として設定し、iops
を2000
に設定します。 - 7 11
- Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を
Required
に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値をOptional
に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。注記クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。
- 13
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 16
- 独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
- 17
- クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
- 18
- AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は
https
プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。 - 19
- 既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
- 20
- 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 暗号化ライブラリーを使用します。
- 21
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 22
<local_registry>
については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例:registry.example.com
またはregistry.example.com:5000
<credentials>
について、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。- 23
- ミラーレジストリーに使用した証明書ファイルの内容を指定します。
- 24
- リポジトリーのミラーリングに使用するコマンドの出力の
imageContentSources
セクションを指定します。
4.3.3.3.5. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.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
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。AmazonEC2
、Elastic 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 信頼バンドルからの認証局によって署名されない限り必要になります。 - 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.3.3.4. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.3.3.4.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: AWSProviderSpec statementEntries: - effect: Allow action: - iam:GetUser - iam:GetUserPolicy - iam:ListAccessKeys resource: "*" ...
以前に生成した
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>
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
4.3.3.4.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.3.3.4.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.20 必要な AWS パーミッション
必要な
iam
権限-
iam:CreateOpenIDConnectProvider
-
iam:CreateRole
-
iam:DeleteOpenIDConnectProvider
-
iam:DeleteRole
-
iam:DeleteRolePolicy
-
iam:GetOpenIDConnectProvider
-
iam:GetRole
-
iam:GetUser
-
iam:ListOpenIDConnectProviders
-
iam:ListRolePolicies
-
iam:ListRoles
-
iam:PutRolePolicy
-
iam:TagOpenIDConnectProvider
-
iam:TagRole
必要な
s3
権限-
s3:CreateBucket
-
s3:DeleteBucket
-
s3:DeleteObject
-
s3:GetBucketAcl
-
s3:GetBucketTagging
-
s3:GetObject
-
s3:GetObjectAcl
-
s3:GetObjectTagging
-
s3:ListBucket
-
s3:PutBucketAcl
-
s3:PutBucketPolicy
-
s3:PutBucketPublicAccessBlock
-
s3:PutBucketTagging
-
s3:PutObject
-
s3:PutObjectAcl
-
s3:PutObjectTagging
必要な
cloudfront
権限-
cloudfront:ListCloudFrontOriginAccessIdentities
-
cloudfront:ListDistributions
-
cloudfront:ListTagsForResource
OIDC 設定を、パブリック CloudFront ディストリビューション URL 経由で IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに保存する予定の場合、
ccoctl
ユーティリティーを実行する AWS アカウントには次の追加パーミッションが必要です。例4.21 CloudFront を使用したプライベート S3 バケットに対する追加の権限
-
cloudfront:CreateCloudFrontOriginAccessIdentity
-
cloudfront:CreateDistribution
-
cloudfront:DeleteCloudFrontOriginAccessIdentity
-
cloudfront:DeleteDistribution
-
cloudfront:GetCloudFrontOriginAccessIdentity
-
cloudfront:GetCloudFrontOriginAccessIdentityConfig
-
cloudfront:GetDistribution
-
cloudfront:TagResource
-
cloudfront:UpdateDistribution
注記これらの追加のパーミッションは、
ccoctl aws create-all
コマンドで認証情報要求を処理する際の--create-private-s3-bucket
オプションの使用をサポートします。-
手順
次のコマンドを実行して、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.
4.3.3.4.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.3.3.4.2.2.1. 単一コマンドでの AWS リソースの作成
ccoctl
ツールが AWS リソースの作成に使用するプロセスが組織の要件を自動的に満たす場合は、ccoctl aws create-all
コマンドを使用して AWS リソースの作成を自動化できます。
それ以外の場合は、AWS リソースを個別に作成できます。詳細は、「AWS リソースの個別の作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-all \ --name=<name> \1 --region=<aws_region> \2 --credentials-requests-dir=<path_to_credentials_requests_directory> \3 --output-dir=<path_to_ccoctl_output_dir> \4 --create-private-s3-bucket 5
- 1
- 追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
- 2
- クラウドリソースが作成される AWS リージョンです。
- 3
- コンポーネント
CredentialsRequest
オブジェクトのファイルを含むディレクトリーを指定します。 - 4
- オプション:
ccoctl
ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。 - 5
- オプション: デフォルトでは、
ccoctl
ユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucket
パラメーターを使用します。
注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.3.4.2.2.2. AWS リソースの個別の作成
ccoctl
ツールを使用して、AWS リソースを個別に作成できます。このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。
それ以外の場合は、ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。詳細は、「単一コマンドによる AWS リソースの作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
一部の ccoctl
コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run
フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json
パラメーターを使用して適用できます。
前提条件
-
ccoctl
バイナリーを展開して準備しておく。
手順
次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。
$ ccoctl aws create-key-pair
出力例
2021/04/13 11:01:02 Generating RSA keypair 2021/04/13 11:01:03 Writing private key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.private 2021/04/13 11:01:03 Writing public key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.public 2021/04/13 11:01:03 Copying signing key for use by installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
$ ccoctl aws create-identity-provider \ --name=<name> \1 --region=<aws_region> \2 --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 3
出力例
2021/04/13 11:16:09 Bucket <name>-oidc created 2021/04/13 11:16:10 OpenID Connect discovery document in the S3 bucket <name>-oidc at .well-known/openid-configuration updated 2021/04/13 11:16:10 Reading public key 2021/04/13 11:16:10 JSON web key set (JWKS) in the S3 bucket <name>-oidc at keys.json updated 2021/04/13 11:16:18 Identity Provider created with ARN: arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
openid-configuration
は検出ドキュメントであり、keys.json
は JSON Web キーセットファイルです。このコマンドは、YAML 設定ファイルを
/<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yaml
にも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。クラスターの各コンポーネントについて IAM ロールを作成します。
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-iam-roles \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
注記GovCloud などの代替の IAM API エンドポイントを使用する AWS 環境では、
--region
パラメーターでリージョンを指定する必要もあります。クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。それぞれの
CredentialsRequest
オブジェクトについて、ccoctl
は指定された OIDC アイデンティティープロバイダーに関連付けられた信頼ポリシーと、OpenShift Container Platform リリースイメージの各CredentialsRequest
オブジェクトに定義されるパーミッションポリシーを使用して IAM ロールを作成します。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.3.4.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 # ...
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ 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 .
4.3.3.5. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.3.3.6. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
4.3.3.7. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。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
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.3.3.8. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
4.3.4. ネットワークのカスタマイズによる AWS へのクラスターのインストール
OpenShift Container Platform バージョン 4.16 では、カスタマイズしたネットワーク設定オプションを使用して、Amazon Web Services (AWS) にクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。
大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy
設定パラメーターのみになります。
4.3.4.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.3.4.2. ネットワーク設定フェーズ
OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。
- フェーズ 1
マニフェストファイルを作成する前に、
install-config.yaml
ファイルで以下のネットワーク関連のフィールドをカスタマイズできます。-
networking.networkType
-
networking.clusterNetwork
-
networking.serviceNetwork
networking.machineNetwork
詳細は、「インストール設定パラメーター」を参照してください。
注記優先されるサブネットが配置されている Classless Inter-Domain Routing (CIDR) と一致するように
networking.machineNetwork
を設定します。重要CIDR 範囲
172.17.0.0/16
はlibVirt
によって予約されています。クラスター内のネットワークに172.17.0.0/16
CIDR 範囲と重複する他の CIDR 範囲を使用することはできません。
-
- フェーズ 2
-
openshift-install create manifests
を実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。
フェーズ 2 では、install-config.yaml
ファイルのフェーズ 1 で指定した値をオーバーライドすることはできません。ただし、フェーズ 2 でネットワークプラグインをカスタマイズできます。
4.3.4.3. インストール設定ファイルの作成
Amazon Web Services (AWS) での OpenShift Container Platform のインストールをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
-
ミラーレジストリーの作成時に生成された
imageContentSources
値がある。 - ミラーレジストリーの証明書の内容を取得している。
手順
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 キーを指定します。- ターゲットに設定するプラットフォームとして AWS を選択します。
- Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
install-config.yaml
ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。pullSecret
の値を更新して、レジストリーの認証情報を追加します。pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'
<mirror_host_name>
の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials>
の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。additionalTrustBundle
パラメーターおよび値を追加します。additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----
この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。
クラスターをインストールする VPC のサブネットを定義します。
subnets: - subnet-1 - subnet-2 - subnet-3
次の YAML の抜粋のようなイメージコンテンツリソースを追加します。
imageContentSources: - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: quay.io/openshift-release-dev/ocp-release - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: registry.redhat.io/ocp/release
これらの値には、ミラーレジストリーの作成時に記録された
imageContentSources
を使用します。オプション: パブリッシュストラテジーを
Internal
に設定します。publish: Internal
このオプションを設定すると、内部 Ingress コントローラーおよびプライベートロードバランサーを作成します。
必要な
install-config.yaml
ファイルに他の変更を加えます。パラメーターの詳細は、「インストール設定パラメーター」を参照してください。
install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
関連情報
4.3.4.3.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 アーキテクチャー を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
関連情報
4.3.4.3.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.22 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
4.3.4.3.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例4.23 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
4.3.4.3.4. 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: OVNKubernetes 14 serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-west-2 15 propagateUserTags: true 16 userTags: adminContact: jdoe costCenter: 7536 subnets: 17 - subnet-1 - subnet-2 - subnet-3 amiID: ami-0c5d3e03c0ab9b19a 18 serviceEndpoints: 19 - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV 20 fips: false 21 sshKey: ssh-ed25519 AAAA... 22 pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' 23 additionalTrustBundle: | 24 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- imageContentSources: 25 - mirrors: - <local_registry>/<local_repository_name>/release source: quay.io/openshift-release-dev/ocp-release - mirrors: - <local_registry>/<local_repository_name>/release source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
- 1 12 15
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2
- オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は
kube-system
namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。 - 3 8 13 16
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 5 9
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
m4.2xlarge
またはm5.2xlarge
などの大規模なインスタンスタイプを使用します。 - 6 10
- 大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを
io1
として設定し、iops
を2000
に設定します。 - 7 11
- Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を
Required
に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値をOptional
に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。注記クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。
- 14
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 17
- 独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
- 18
- クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
- 19
- AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は
https
プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。 - 20
- 既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
- 21
- 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 暗号化ライブラリーを使用します。
- 22
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 23
<local_registry>
については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例:registry.example.com
またはregistry.example.com:5000
<credentials>
について、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。- 24
- ミラーレジストリーに使用した証明書ファイルの内容を指定します。
- 25
- リポジトリーのミラーリングに使用するコマンドの出力の
imageContentSources
セクションを指定します。
4.3.4.3.5. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.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
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。AmazonEC2
、Elastic 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 信頼バンドルからの認証局によって署名されない限り必要になります。 - 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.3.4.4. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.3.4.4.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: AWSProviderSpec statementEntries: - effect: Allow action: - iam:GetUser - iam:GetUserPolicy - iam:ListAccessKeys resource: "*" ...
以前に生成した
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>
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
4.3.4.4.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.3.4.4.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.24 必要な AWS パーミッション
必要な
iam
権限-
iam:CreateOpenIDConnectProvider
-
iam:CreateRole
-
iam:DeleteOpenIDConnectProvider
-
iam:DeleteRole
-
iam:DeleteRolePolicy
-
iam:GetOpenIDConnectProvider
-
iam:GetRole
-
iam:GetUser
-
iam:ListOpenIDConnectProviders
-
iam:ListRolePolicies
-
iam:ListRoles
-
iam:PutRolePolicy
-
iam:TagOpenIDConnectProvider
-
iam:TagRole
必要な
s3
権限-
s3:CreateBucket
-
s3:DeleteBucket
-
s3:DeleteObject
-
s3:GetBucketAcl
-
s3:GetBucketTagging
-
s3:GetObject
-
s3:GetObjectAcl
-
s3:GetObjectTagging
-
s3:ListBucket
-
s3:PutBucketAcl
-
s3:PutBucketPolicy
-
s3:PutBucketPublicAccessBlock
-
s3:PutBucketTagging
-
s3:PutObject
-
s3:PutObjectAcl
-
s3:PutObjectTagging
必要な
cloudfront
権限-
cloudfront:ListCloudFrontOriginAccessIdentities
-
cloudfront:ListDistributions
-
cloudfront:ListTagsForResource
OIDC 設定を、パブリック CloudFront ディストリビューション URL 経由で IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに保存する予定の場合、
ccoctl
ユーティリティーを実行する AWS アカウントには次の追加パーミッションが必要です。例4.25 CloudFront を使用したプライベート S3 バケットに対する追加の権限
-
cloudfront:CreateCloudFrontOriginAccessIdentity
-
cloudfront:CreateDistribution
-
cloudfront:DeleteCloudFrontOriginAccessIdentity
-
cloudfront:DeleteDistribution
-
cloudfront:GetCloudFrontOriginAccessIdentity
-
cloudfront:GetCloudFrontOriginAccessIdentityConfig
-
cloudfront:GetDistribution
-
cloudfront:TagResource
-
cloudfront:UpdateDistribution
注記これらの追加のパーミッションは、
ccoctl aws create-all
コマンドで認証情報要求を処理する際の--create-private-s3-bucket
オプションの使用をサポートします。-
手順
次のコマンドを実行して、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.
4.3.4.4.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.3.4.4.2.2.1. 単一コマンドでの AWS リソースの作成
ccoctl
ツールが AWS リソースの作成に使用するプロセスが組織の要件を自動的に満たす場合は、ccoctl aws create-all
コマンドを使用して AWS リソースの作成を自動化できます。
それ以外の場合は、AWS リソースを個別に作成できます。詳細は、「AWS リソースの個別の作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-all \ --name=<name> \1 --region=<aws_region> \2 --credentials-requests-dir=<path_to_credentials_requests_directory> \3 --output-dir=<path_to_ccoctl_output_dir> \4 --create-private-s3-bucket 5
- 1
- 追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
- 2
- クラウドリソースが作成される AWS リージョンです。
- 3
- コンポーネント
CredentialsRequest
オブジェクトのファイルを含むディレクトリーを指定します。 - 4
- オプション:
ccoctl
ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。 - 5
- オプション: デフォルトでは、
ccoctl
ユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucket
パラメーターを使用します。
注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.4.4.2.2.2. AWS リソースの個別の作成
ccoctl
ツールを使用して、AWS リソースを個別に作成できます。このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。
それ以外の場合は、ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。詳細は、「単一コマンドによる AWS リソースの作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
一部の ccoctl
コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run
フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json
パラメーターを使用して適用できます。
前提条件
-
ccoctl
バイナリーを展開して準備しておく。
手順
次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。
$ ccoctl aws create-key-pair
出力例
2021/04/13 11:01:02 Generating RSA keypair 2021/04/13 11:01:03 Writing private key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.private 2021/04/13 11:01:03 Writing public key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.public 2021/04/13 11:01:03 Copying signing key for use by installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
$ ccoctl aws create-identity-provider \ --name=<name> \1 --region=<aws_region> \2 --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 3
出力例
2021/04/13 11:16:09 Bucket <name>-oidc created 2021/04/13 11:16:10 OpenID Connect discovery document in the S3 bucket <name>-oidc at .well-known/openid-configuration updated 2021/04/13 11:16:10 Reading public key 2021/04/13 11:16:10 JSON web key set (JWKS) in the S3 bucket <name>-oidc at keys.json updated 2021/04/13 11:16:18 Identity Provider created with ARN: arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
openid-configuration
は検出ドキュメントであり、keys.json
は JSON Web キーセットファイルです。このコマンドは、YAML 設定ファイルを
/<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yaml
にも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。クラスターの各コンポーネントについて IAM ロールを作成します。
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-iam-roles \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
注記GovCloud などの代替の IAM API エンドポイントを使用する AWS 環境では、
--region
パラメーターでリージョンを指定する必要もあります。クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。それぞれの
CredentialsRequest
オブジェクトについて、ccoctl
は指定された OIDC アイデンティティープロバイダーに関連付けられた信頼ポリシーと、OpenShift Container Platform リリースイメージの各CredentialsRequest
オブジェクトに定義されるパーミッションポリシーを使用して IAM ロールを作成します。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.4.4.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 # ...
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ 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 .
4.3.4.5. 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
-
クラスターネットワークプラグイン。
OVNKubernetes
は、インストール時にサポートされる唯一のプラグインです。
defaultNetwork
オブジェクトのフィールドを cluster
という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。
4.3.4.5.1. Cluster Network Operator 設定オブジェクト
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNO オブジェクトの名前。この名前は常に |
|
| Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。 spec: clusterNetwork: - cidr: 10.128.0.0/19 hostPrefix: 23 - cidr: 10.128.32.0/19 hostPrefix: 23 |
|
| サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。 spec: serviceNetwork: - 172.30.0.0/14
マニフェストを作成する前に、このフィールドを |
|
| クラスターネットワークのネットワークプラグインを設定します。 |
|
| このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。 |
defaultNetwork オブジェクト設定
defaultNetwork
オブジェクトの値は、以下の表で定義されます。
フィールド | 型 | 説明 |
---|---|---|
|
|
注記 OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。 |
|
| このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。 |
OVN-Kubernetes ネットワークプラグインの設定
次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。
フィールド | 型 | 説明 |
---|---|---|
|
| Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも |
|
|
すべての Geneve パケットに使用するポート。デフォルト値は |
|
| IPsec 設定をカスタマイズするための設定オブジェクトを指定します。 |
|
| IPv4 設定の設定オブジェクトを指定します。 |
|
| IPv6 設定の設定オブジェクトを指定します。 |
|
| ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。 |
|
| オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。 注記 Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。 |
フィールド | 型 | 説明 |
---|---|---|
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
フィールド | 型 | 説明 |
---|---|---|
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
フィールド | 型 | 説明 |
---|---|---|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
| integer | 保持されるログファイルの最大数。 |
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
| string |
RFC5424 で定義される |
フィールド | 型 | 説明 |
---|---|---|
|
|
Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを
このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを |
|
|
|
|
| オプション: IPv4 アドレスのホストからサービスへのトラフィック用の内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。 |
|
| オプション: IPv6 アドレスのホストからサービスへのトラフィックの内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。 |
フィールド | 型 | 説明 |
---|---|---|
|
|
ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv4 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は |
フィールド | 型 | 説明 |
---|---|---|
|
|
ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は |
フィールド | 型 | 説明 |
---|---|---|
|
| IPsec 実装の動作を指定します。次の値のいずれかである必要があります。
|
IPsec が有効な OVN-Kubernetes 設定の例
defaultNetwork: type: OVNKubernetes ovnKubernetesConfig: mtu: 1400 genevePort: 6081 ipsecConfig: mode: Full
OVNKubernetes を使用すると、IBM Power® でスタック枯渇の問題が発生する可能性があります。
kubeProxyConfig オブジェクト設定 (OpenShiftSDN コンテナーネットワークインターフェイスのみ)
kubeProxyConfig
オブジェクトの値は以下の表で定義されます。
フィールド | 型 | 説明 |
---|---|---|
|
|
注記
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、 |
|
|
kubeProxyConfig: proxyArguments: iptables-min-sync-period: - 0s |
4.3.4.6. 高度なネットワーク設定の指定
ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。
高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。
インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。
前提条件
-
install-config.yaml
ファイルを作成し、これに対する変更を完了している。
手順
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
$ ./openshift-install create manifests --dir <installation_directory> 1
- 1
<installation_directory>
は、クラスターのinstall-config.yaml
ファイルが含まれるディレクトリーの名前を指定します。
cluster-network-03-config.yml
という名前の、高度なネットワーク設定用のスタブマニフェストファイルを<installation_directory>/manifests/
ディレクトリーに作成します。apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec:
次の例のように、
cluster-network-03-config.yml
ファイルでクラスターの高度なネットワーク設定を指定します。OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にする
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: ipsecConfig: mode: Full
-
オプション:
manifests/cluster-network-03-config.yml
ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時にmanifests/
ディレクトリーを使用します。
AWS で Network Load Balancer (NLB) を使用する方法の詳細は、Network Load Balancer を使用した AWS での Ingress クラスタートラフィックの設定 を参照してください。
4.3.4.7. 新規 AWS クラスターでの Ingress コントローラーネットワークロードバランサーの設定
新規クラスターに AWS Network Load Balancer (NLB) がサポートする Ingress Controller を作成できます。
前提条件
-
install-config.yaml
ファイルを作成し、これに対する変更を完了します。
手順
新規クラスターの AWS NLB がサポートする Ingress Controller を作成します。
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
$ ./openshift-install create manifests --dir <installation_directory> 1
- 1
<installation_directory>
については、クラスターのinstall-config.yaml
ファイルが含まれるディレクトリーの名前を指定します。
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
エディターで
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
-
cluster-ingress-default-ingresscontroller.yaml
ファイルを保存し、テキストエディターを終了します。 -
オプション:
manifests/cluster-ingress-default-ingresscontroller.yaml
ファイルをバックアップします。インストールプログラムは、クラスターの作成時にmanifests/
ディレクトリーを削除します。
4.3.4.8. OVN-Kubernetes を使用したハイブリッドネットワークの設定
OVN-Kubernetes ネットワークプラグインを使用してハイブリッドネットワークを使用するようにクラスターを設定できます。これにより、異なるノードのネットワーク設定をサポートするハイブリッドクラスターが可能になります。
この設定は、同じクラスター内で Linux ノードと Windows ノードの両方を実行するために必要です。
前提条件
-
install-config.yaml
ファイルでnetworking.networkType
パラメーターのOVNKubernetes
を定義していること。詳細は、選択したクラウドプロバイダーでの OpenShift Container Platform ネットワークのカスタマイズの設定に関するインストールドキュメントを参照してください。
手順
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
$ ./openshift-install create manifests --dir <installation_directory>
ここでは、以下のようになります。
<installation_directory>
-
クラスターの
install-config.yaml
ファイルが含まれるディレクトリーの名前を指定します。
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/
ディレクトリーが含まれるディレクトリー名を指定します。
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
値を持つクラスターではサポートされません。
同じクラスターで Linux ノードと Windows ノードを使用する方法の詳細は、Windows コンテナーワークロードについて を参照してください。
4.3.4.9. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.3.4.10. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
4.3.4.11. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。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
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.3.4.12. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
4.3.5. ネットワークが制限された環境での AWS へのクラスターのインストール
OpenShift Container Platform バージョン 4.16 では、既存の Amazon Virtual Private Cloud (VPC) にインストールリリースコンテンツの内部ミラーを作成することにより、制限付きネットワーク内の Amazon Web Services (AWS) にクラスターをインストールできます。
4.3.5.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
非接続インストールのイメージのミラーリング をレジストリーに対して行っており、使用しているバージョンの OpenShift Container Platform の
imageContentSources
データを取得している。重要インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。
AWS に既存の VPC が必要です。installer-provisioned infrastructure を使用してネットワークが制限された環境にインストールする場合は、installer-provisioned VPC を使用することはできません。以下の要件のいずれかを満たす user-provisioned 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 サービスを使用する予定の場合)。
注記プロキシーを設定する場合は、このサイトリストも確認してください。
4.3.5.2. ネットワークが制限された環境でのインストールについて
OpenShift Container Platform 4.16 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、installer-provisioned infrastructure または user-provisioned infrastructure を使用して実行できます。
クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。
ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。
4.3.5.2.1. その他の制限
ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。
-
ClusterVersion
ステータスにはUnable to retrieve available updates
エラーが含まれます。 - デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。
4.3.5.3. カスタム VPC の使用について
OpenShift Container Platform 4.16 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
4.3.5.3.1. VPC を使用するための要件
インストールプログラムは、以下のコンポーネントを作成しなくなりました。
- インターネットゲートウェイ
- NAT ゲートウェイ
- サブネット
- ルートテーブル
- VPC
- VPC DHCP オプション
- VPC エンドポイント
インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。
カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC コンソールウィザードの設定と AWS VPC の作成および管理の詳細は、Amazon Web Services ドキュメントの VPC の作成 を参照してください。
インストールプログラムには、以下の機能はありません。
- 使用するクラスターのネットワーク範囲を細分化する。
- サブネットのルートテーブルを設定する。
- DHCP などの VPC オプションを設定する。
クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、VPC ネットワーキングコンポーネント と VPC のルートテーブル を参照してください。
VPC は以下の特性を満たす必要があります。
VPC は
kubernetes.io/cluster/.*: owned
、Name
、openshift.io/cluster
タグを使用できません。インストールプログラムは
kubernetes.io/cluster/.*: shared
タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name
タグは EC2Name
フィールドと重複し、その結果インストールが失敗するため、使用できません。-
OpenShift Container Platform クラスターを AWS Outpost に拡張し、既存の Outpost サブネットを使用する場合、既存のサブネットで
kubernetes.io/cluster/unmanaged: true
タグを使用する必要があります。このタグを適用しないと、Cloud Controller Manager が Outpost サブネットにサービスロードバランサーを作成するため、インストールが失敗する可能性があります。これはサポートされていない設定です。 VPC で
enableDnsSupport
およびenableDnsHostnames
属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。
install-config.yaml
ファイルのplatform.aws.hostedZone
フィールドとplatform.aws.hostedZoneRole
フィールドを使用して、ホストゾーンを定義できます。クラスターをインストールするアカウントとプライベートホストゾーンを共有することで、別のアカウントからプライベートホストゾーンを使用できます。別のアカウントからプライベートホストゾーンを使用する場合は、Passthrough
またはManual
認証情報モードを使用する必要があります。
非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。
オプション 1: VPC エンドポイントを作成する
VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
-
ec2.<aws_region>.amazonaws.com
-
elasticloadbalancing.<aws_region>.amazonaws.com
-
s3.<aws_region>.amazonaws.com
このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。
オプション 2: VPC エンドポイントなしでプロキシーを作成する
インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。
オプション 3: VPC エンドポイントでプロキシーを作成する
インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
-
ec2.<aws_region>.amazonaws.com
-
elasticloadbalancing.<aws_region>.amazonaws.com
-
s3.<aws_region>.amazonaws.com
install-config.yaml
ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy
フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。
必要な VPC コンポーネント
お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。
コンポーネント | AWS タイプ | 説明 | |
---|---|---|---|
VPC |
| 使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。 | |
パブリックサブネット |
| VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。 | |
インターネットゲートウェイ |
| VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。 | |
ネットワークアクセス制御 |
| VPC が以下のポートにアクセスできるようにする必要があります。 | |
ポート | 理由 | ||
| インバウンド HTTP トラフィック | ||
| インバウンド HTTPS トラフィック | ||
| インバウンド SSH トラフィック | ||
| インバウンド一時 (ephemeral) トラフィック | ||
| アウトバウンド一時 (ephemeral) トラフィック | ||
プライベートサブネット |
| VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 |
4.3.5.3.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared
タグは、それが使用したサブネットから削除されます。
4.3.5.3.3. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
4.3.5.3.4. クラスター間の分離
OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。
- 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
- ICMP Ingress はネットワーク全体から許可されます。
- TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
4.3.5.4. インストール設定ファイルの作成
Amazon Web Services (AWS) での OpenShift Container Platform のインストールをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
-
ミラーレジストリーの作成時に生成された
imageContentSources
値がある。 - ミラーレジストリーの証明書の内容を取得している。
手順
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 キーを指定します。- ターゲットに設定するプラットフォームとして AWS を選択します。
- Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
install-config.yaml
ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。pullSecret
の値を更新して、レジストリーの認証情報を追加します。pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'
<mirror_host_name>
の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials>
の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。additionalTrustBundle
パラメーターおよび値を追加します。additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----
この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。
クラスターをインストールする VPC のサブネットを定義します。
subnets: - subnet-1 - subnet-2 - subnet-3
次の YAML の抜粋のようなイメージコンテンツリソースを追加します。
imageContentSources: - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: quay.io/openshift-release-dev/ocp-release - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: registry.redhat.io/ocp/release
これらの値には、ミラーレジストリーの作成時に記録された
imageContentSources
を使用します。オプション: パブリッシュストラテジーを
Internal
に設定します。publish: Internal
このオプションを設定すると、内部 Ingress コントローラーおよびプライベートロードバランサーを作成します。
必要な
install-config.yaml
ファイルに他の変更を加えます。パラメーターの詳細は、「インストール設定パラメーター」を参照してください。
install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
関連情報
4.3.5.4.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 アーキテクチャー を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
関連情報
4.3.5.4.2. 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: OVNKubernetes 13 serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-west-2 14 propagateUserTags: true 15 userTags: adminContact: jdoe costCenter: 7536 subnets: 16 - subnet-1 - subnet-2 - subnet-3 amiID: ami-0c5d3e03c0ab9b19a 17 serviceEndpoints: 18 - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV 19 fips: false 20 sshKey: ssh-ed25519 AAAA... 21 pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' 22 additionalTrustBundle: | 23 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- imageContentSources: 24 - 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 14
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2
- オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は
kube-system
namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。 - 3 8 15
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 5 9
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
m4.2xlarge
またはm5.2xlarge
などの大規模なインスタンスタイプを使用します。 - 6 10
- 大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを
io1
として設定し、iops
を2000
に設定します。 - 7 11
- Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を
Required
に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値をOptional
に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。注記クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。
- 13
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 16
- 独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
- 17
- クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
- 18
- AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は
https
プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。 - 19
- 既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
- 20
- 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 暗号化ライブラリーを使用します。
- 21
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 22
<local_registry>
については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例:registry.example.com
またはregistry.example.com:5000
<credentials>
について、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。- 23
- ミラーレジストリーに使用した証明書ファイルの内容を指定します。
- 24
- リポジトリーのミラーリングに使用するコマンドの出力の
imageContentSources
セクションを指定します。
4.3.5.4.3. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.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
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。AmazonEC2
、Elastic 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 信頼バンドルからの認証局によって署名されない限り必要になります。 - 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.3.5.5. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.3.5.5.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: AWSProviderSpec statementEntries: - effect: Allow action: - iam:GetUser - iam:GetUserPolicy - iam:ListAccessKeys resource: "*" ...
以前に生成した
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>
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
4.3.5.5.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.3.5.5.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.26 必要な AWS パーミッション
必要な
iam
権限-
iam:CreateOpenIDConnectProvider
-
iam:CreateRole
-
iam:DeleteOpenIDConnectProvider
-
iam:DeleteRole
-
iam:DeleteRolePolicy
-
iam:GetOpenIDConnectProvider
-
iam:GetRole
-
iam:GetUser
-
iam:ListOpenIDConnectProviders
-
iam:ListRolePolicies
-
iam:ListRoles
-
iam:PutRolePolicy
-
iam:TagOpenIDConnectProvider
-
iam:TagRole
必要な
s3
権限-
s3:CreateBucket
-
s3:DeleteBucket
-
s3:DeleteObject
-
s3:GetBucketAcl
-
s3:GetBucketTagging
-
s3:GetObject
-
s3:GetObjectAcl
-
s3:GetObjectTagging
-
s3:ListBucket
-
s3:PutBucketAcl
-
s3:PutBucketPolicy
-
s3:PutBucketPublicAccessBlock
-
s3:PutBucketTagging
-
s3:PutObject
-
s3:PutObjectAcl
-
s3:PutObjectTagging
必要な
cloudfront
権限-
cloudfront:ListCloudFrontOriginAccessIdentities
-
cloudfront:ListDistributions
-
cloudfront:ListTagsForResource
OIDC 設定を、パブリック CloudFront ディストリビューション URL 経由で IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに保存する予定の場合、
ccoctl
ユーティリティーを実行する AWS アカウントには次の追加パーミッションが必要です。例4.27 CloudFront を使用したプライベート S3 バケットに対する追加の権限
-
cloudfront:CreateCloudFrontOriginAccessIdentity
-
cloudfront:CreateDistribution
-
cloudfront:DeleteCloudFrontOriginAccessIdentity
-
cloudfront:DeleteDistribution
-
cloudfront:GetCloudFrontOriginAccessIdentity
-
cloudfront:GetCloudFrontOriginAccessIdentityConfig
-
cloudfront:GetDistribution
-
cloudfront:TagResource
-
cloudfront:UpdateDistribution
注記これらの追加のパーミッションは、
ccoctl aws create-all
コマンドで認証情報要求を処理する際の--create-private-s3-bucket
オプションの使用をサポートします。-
手順
次のコマンドを実行して、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.
4.3.5.5.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.3.5.5.2.2.1. 単一コマンドでの AWS リソースの作成
ccoctl
ツールが AWS リソースの作成に使用するプロセスが組織の要件を自動的に満たす場合は、ccoctl aws create-all
コマンドを使用して AWS リソースの作成を自動化できます。
それ以外の場合は、AWS リソースを個別に作成できます。詳細は、「AWS リソースの個別の作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-all \ --name=<name> \1 --region=<aws_region> \2 --credentials-requests-dir=<path_to_credentials_requests_directory> \3 --output-dir=<path_to_ccoctl_output_dir> \4 --create-private-s3-bucket 5
- 1
- 追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
- 2
- クラウドリソースが作成される AWS リージョンです。
- 3
- コンポーネント
CredentialsRequest
オブジェクトのファイルを含むディレクトリーを指定します。 - 4
- オプション:
ccoctl
ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。 - 5
- オプション: デフォルトでは、
ccoctl
ユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucket
パラメーターを使用します。
注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.5.5.2.2.2. AWS リソースの個別の作成
ccoctl
ツールを使用して、AWS リソースを個別に作成できます。このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。
それ以外の場合は、ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。詳細は、「単一コマンドによる AWS リソースの作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
一部の ccoctl
コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run
フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json
パラメーターを使用して適用できます。
前提条件
-
ccoctl
バイナリーを展開して準備しておく。
手順
次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。
$ ccoctl aws create-key-pair
出力例
2021/04/13 11:01:02 Generating RSA keypair 2021/04/13 11:01:03 Writing private key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.private 2021/04/13 11:01:03 Writing public key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.public 2021/04/13 11:01:03 Copying signing key for use by installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
$ ccoctl aws create-identity-provider \ --name=<name> \1 --region=<aws_region> \2 --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 3
出力例
2021/04/13 11:16:09 Bucket <name>-oidc created 2021/04/13 11:16:10 OpenID Connect discovery document in the S3 bucket <name>-oidc at .well-known/openid-configuration updated 2021/04/13 11:16:10 Reading public key 2021/04/13 11:16:10 JSON web key set (JWKS) in the S3 bucket <name>-oidc at keys.json updated 2021/04/13 11:16:18 Identity Provider created with ARN: arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
openid-configuration
は検出ドキュメントであり、keys.json
は JSON Web キーセットファイルです。このコマンドは、YAML 設定ファイルを
/<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yaml
にも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。クラスターの各コンポーネントについて IAM ロールを作成します。
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-iam-roles \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
注記GovCloud などの代替の IAM API エンドポイントを使用する AWS 環境では、
--region
パラメーターでリージョンを指定する必要もあります。クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。それぞれの
CredentialsRequest
オブジェクトについて、ccoctl
は指定された OIDC アイデンティティープロバイダーに関連付けられた信頼ポリシーと、OpenShift Container Platform リリースイメージの各CredentialsRequest
オブジェクトに定義されるパーミッションポリシーを使用して IAM ロールを作成します。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.5.5.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 # ...
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ 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 .
4.3.5.6. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.3.5.7. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
4.3.5.8. デフォルトの OperatorHub カタログソースの無効化
Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。
手順
disableAllDefaultSources: true
をOperatorHub
オブジェクトに追加して、デフォルトカタログのソースを無効にします。$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
または、Web コンソールを使用してカタログソースを管理できます。Administration
4.3.5.9. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
-
Cluster Samples Operator および
must-gather
ツールの イメージストリームを設定 します。 - ネットワークが制限された環境での Operator Lifecycle Manager (OLM) の使用 方法について参照します。
- クラスターのインストールに使用したミラーレジストリーに信頼された CA がある場合は、追加のトラストストアを設定 してクラスターに追加します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
4.3.6. AWS のクラスターの既存 VPC へのインストール
OpenShift Container Platform バージョン 4.16 では、Amazon Web Services (AWS) 上の既存の Amazon Virtual Private Cloud (VPC) にクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
4.3.6.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- クラスターをホストするために AWS アカウントを設定 している。
既存の VPC がクラスターとは異なるアカウントによって所有されている場合は、アカウント間で VPC を共有 しています。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.3.6.2. カスタム VPC の使用について
OpenShift Container Platform 4.16 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
4.3.6.2.1. VPC を使用するための要件
インストールプログラムは、以下のコンポーネントを作成しなくなりました。
- インターネットゲートウェイ
- NAT ゲートウェイ
- サブネット
- ルートテーブル
- VPC
- VPC DHCP オプション
- VPC エンドポイント
インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。
カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC コンソールウィザードの設定と AWS VPC の作成および管理の詳細は、Amazon Web Services ドキュメントの 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/.*: owned
、Name
、openshift.io/cluster
タグを使用できません。インストールプログラムは
kubernetes.io/cluster/.*: shared
タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name
タグは EC2Name
フィールドと重複し、その結果インストールが失敗するため、使用できません。-
OpenShift Container Platform クラスターを AWS Outpost に拡張し、既存の Outpost サブネットを使用する場合、既存のサブネットで
kubernetes.io/cluster/unmanaged: true
タグを使用する必要があります。このタグを適用しないと、Cloud Controller Manager が Outpost サブネットにサービスロードバランサーを作成するため、インストールが失敗する可能性があります。これはサポートされていない設定です。 VPC で
enableDnsSupport
およびenableDnsHostnames
属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。
install-config.yaml
ファイルのplatform.aws.hostedZone
フィールドとplatform.aws.hostedZoneRole
フィールドを使用して、ホストゾーンを定義できます。クラスターをインストールするアカウントとプライベートホストゾーンを共有することで、別のアカウントからプライベートホストゾーンを使用できます。別のアカウントからプライベートホストゾーンを使用する場合は、Passthrough
またはManual
認証情報モードを使用する必要があります。
非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。
オプション 1: VPC エンドポイントを作成する
VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
-
ec2.<aws_region>.amazonaws.com
-
elasticloadbalancing.<aws_region>.amazonaws.com
-
s3.<aws_region>.amazonaws.com
このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。
オプション 2: VPC エンドポイントなしでプロキシーを作成する
インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。
オプション 3: VPC エンドポイントでプロキシーを作成する
インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
-
ec2.<aws_region>.amazonaws.com
-
elasticloadbalancing.<aws_region>.amazonaws.com
-
s3.<aws_region>.amazonaws.com
install-config.yaml
ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy
フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。
必要な VPC コンポーネント
お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。
コンポーネント | AWS タイプ | 説明 | |
---|---|---|---|
VPC |
| 使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。 | |
パブリックサブネット |
| VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。 | |
インターネットゲートウェイ |
| VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。 | |
ネットワークアクセス制御 |
| VPC が以下のポートにアクセスできるようにする必要があります。 | |
ポート | 理由 | ||
| インバウンド HTTP トラフィック | ||
| インバウンド HTTPS トラフィック | ||
| インバウンド SSH トラフィック | ||
| インバウンド一時 (ephemeral) トラフィック | ||
| アウトバウンド一時 (ephemeral) トラフィック | ||
プライベートサブネット |
| VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 |
4.3.6.2.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared
タグは、それが使用したサブネットから削除されます。
4.3.6.2.3. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
4.3.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.3.6.2.5. オプション: AWS セキュリティーグループ
デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。
ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml
ファイルを変更してカスタムセキュリティーグループを適用します。
詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。
4.3.6.3. インストール設定ファイルの作成
Amazon Web Services (AWS) での OpenShift Container Platform のインストールをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
手順
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 キーを指定します。- ターゲットに設定するプラットフォームとして AWS を選択します。
- Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
関連情報
4.3.6.3.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 アーキテクチャー を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
関連情報
4.3.6.3.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.29 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
4.3.6.3.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例4.30 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
4.3.6.3.4. 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: OVNKubernetes 13 serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-west-2 14 propagateUserTags: true 15 userTags: adminContact: jdoe costCenter: 7536 subnets: 16 - subnet-1 - subnet-2 - subnet-3 amiID: ami-0c5d3e03c0ab9b19a 17 serviceEndpoints: 18 - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV 19 fips: false 20 sshKey: ssh-ed25519 AAAA... 21 pullSecret: '{"auths": ...}' 22
- 1 12 14 22
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2
- オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は
kube-system
namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。 - 3 8 15
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 5 9
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
m4.2xlarge
またはm5.2xlarge
などの大規模なインスタンスタイプを使用します。 - 6 10
- 大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを
io1
として設定し、iops
を2000
に設定します。 - 7 11
- Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を
Required
に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値をOptional
に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。注記クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。
- 13
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 16
- 独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
- 17
- クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
- 18
- AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は
https
プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。 - 19
- 既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
- 20
- 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 暗号化ライブラリーを使用します。
- 21
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。
4.3.6.3.5. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.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
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。AmazonEC2
、Elastic 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 信頼バンドルからの認証局によって署名されない限り必要になります。 - 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.3.6.3.6. 既存の AWS セキュリティーグループをクラスターに適用する
既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
前提条件
- AWS でセキュリティーグループを作成している。詳細は、セキュリティーグループ の操作に関する AWS ドキュメントを参照してください。
- セキュリティーグループは、クラスターをデプロイする既存の VPC に関連付ける必要があります。セキュリティーグループを別の VPC に関連付けることはできません。
-
既存の
install-config.yaml
ファイルがある。
手順
-
install-config.yaml
ファイルで、compute.platform.aws.additionalSecurityGroupIDs
パラメーターを編集して、コンピュートマシンに 1 つ以上のカスタムセキュリティーグループを指定します。 -
controlPlane.platform.aws.additionalSecurityGroupIDs
パラメーターを編集して、コントロールプレーンマシンに 1 つ以上のカスタムセキュリティーグループを指定します。 - ファイルを保存し、クラスターをデプロイする際に参照します。
カスタムセキュリティーグループを指定するサンプル install-config.yaml
ファイル
# ... compute: - hyperthreading: Enabled name: worker platform: aws: additionalSecurityGroupIDs: - sg-1 1 - sg-2 replicas: 3 controlPlane: hyperthreading: Enabled name: master platform: aws: additionalSecurityGroupIDs: - sg-3 - sg-4 replicas: 3 platform: aws: region: us-east-1 subnets: 2 - subnet-1 - subnet-2 - subnet-3
4.3.6.4. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.3.6.4.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: AWSProviderSpec statementEntries: - effect: Allow action: - iam:GetUser - iam:GetUserPolicy - iam:ListAccessKeys resource: "*" ...
以前に生成した
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>
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
4.3.6.4.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.3.6.4.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.31 必要な AWS パーミッション
必要な
iam
権限-
iam:CreateOpenIDConnectProvider
-
iam:CreateRole
-
iam:DeleteOpenIDConnectProvider
-
iam:DeleteRole
-
iam:DeleteRolePolicy
-
iam:GetOpenIDConnectProvider
-
iam:GetRole
-
iam:GetUser
-
iam:ListOpenIDConnectProviders
-
iam:ListRolePolicies
-
iam:ListRoles
-
iam:PutRolePolicy
-
iam:TagOpenIDConnectProvider
-
iam:TagRole
必要な
s3
権限-
s3:CreateBucket
-
s3:DeleteBucket
-
s3:DeleteObject
-
s3:GetBucketAcl
-
s3:GetBucketTagging
-
s3:GetObject
-
s3:GetObjectAcl
-
s3:GetObjectTagging
-
s3:ListBucket
-
s3:PutBucketAcl
-
s3:PutBucketPolicy
-
s3:PutBucketPublicAccessBlock
-
s3:PutBucketTagging
-
s3:PutObject
-
s3:PutObjectAcl
-
s3:PutObjectTagging
必要な
cloudfront
権限-
cloudfront:ListCloudFrontOriginAccessIdentities
-
cloudfront:ListDistributions
-
cloudfront:ListTagsForResource
OIDC 設定を、パブリック CloudFront ディストリビューション URL 経由で IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに保存する予定の場合、
ccoctl
ユーティリティーを実行する AWS アカウントには次の追加パーミッションが必要です。例4.32 CloudFront を使用したプライベート S3 バケットに対する追加の権限
-
cloudfront:CreateCloudFrontOriginAccessIdentity
-
cloudfront:CreateDistribution
-
cloudfront:DeleteCloudFrontOriginAccessIdentity
-
cloudfront:DeleteDistribution
-
cloudfront:GetCloudFrontOriginAccessIdentity
-
cloudfront:GetCloudFrontOriginAccessIdentityConfig
-
cloudfront:GetDistribution
-
cloudfront:TagResource
-
cloudfront:UpdateDistribution
注記これらの追加のパーミッションは、
ccoctl aws create-all
コマンドで認証情報要求を処理する際の--create-private-s3-bucket
オプションの使用をサポートします。-
手順
次のコマンドを実行して、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.
4.3.6.4.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.3.6.4.2.2.1. 単一コマンドでの AWS リソースの作成
ccoctl
ツールが AWS リソースの作成に使用するプロセスが組織の要件を自動的に満たす場合は、ccoctl aws create-all
コマンドを使用して AWS リソースの作成を自動化できます。
それ以外の場合は、AWS リソースを個別に作成できます。詳細は、「AWS リソースの個別の作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-all \ --name=<name> \1 --region=<aws_region> \2 --credentials-requests-dir=<path_to_credentials_requests_directory> \3 --output-dir=<path_to_ccoctl_output_dir> \4 --create-private-s3-bucket 5
- 1
- 追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
- 2
- クラウドリソースが作成される AWS リージョンです。
- 3
- コンポーネント
CredentialsRequest
オブジェクトのファイルを含むディレクトリーを指定します。 - 4
- オプション:
ccoctl
ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。 - 5
- オプション: デフォルトでは、
ccoctl
ユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucket
パラメーターを使用します。
注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.6.4.2.2.2. AWS リソースの個別の作成
ccoctl
ツールを使用して、AWS リソースを個別に作成できます。このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。
それ以外の場合は、ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。詳細は、「単一コマンドによる AWS リソースの作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
一部の ccoctl
コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run
フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json
パラメーターを使用して適用できます。
前提条件
-
ccoctl
バイナリーを展開して準備しておく。
手順
次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。
$ ccoctl aws create-key-pair
出力例
2021/04/13 11:01:02 Generating RSA keypair 2021/04/13 11:01:03 Writing private key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.private 2021/04/13 11:01:03 Writing public key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.public 2021/04/13 11:01:03 Copying signing key for use by installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
$ ccoctl aws create-identity-provider \ --name=<name> \1 --region=<aws_region> \2 --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 3
出力例
2021/04/13 11:16:09 Bucket <name>-oidc created 2021/04/13 11:16:10 OpenID Connect discovery document in the S3 bucket <name>-oidc at .well-known/openid-configuration updated 2021/04/13 11:16:10 Reading public key 2021/04/13 11:16:10 JSON web key set (JWKS) in the S3 bucket <name>-oidc at keys.json updated 2021/04/13 11:16:18 Identity Provider created with ARN: arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
openid-configuration
は検出ドキュメントであり、keys.json
は JSON Web キーセットファイルです。このコマンドは、YAML 設定ファイルを
/<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yaml
にも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。クラスターの各コンポーネントについて IAM ロールを作成します。
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-iam-roles \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
注記GovCloud などの代替の IAM API エンドポイントを使用する AWS 環境では、
--region
パラメーターでリージョンを指定する必要もあります。クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。それぞれの
CredentialsRequest
オブジェクトについて、ccoctl
は指定された OIDC アイデンティティープロバイダーに関連付けられた信頼ポリシーと、OpenShift Container Platform リリースイメージの各CredentialsRequest
オブジェクトに定義されるパーミッションポリシーを使用して IAM ロールを作成します。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.6.4.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 # ...
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ 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 .
4.3.6.5. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.3.6.6. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
4.3.6.7. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。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
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.3.6.8. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
- AWS 上の既存の VPC にクラスターをインストールした後、AWS VPC クラスターを AWS Outpost に拡張 できます。
4.3.7. プライベートクラスターの AWS へのインストール
OpenShift Container Platform バージョン 4.16 では、Amazon Web Services (AWS) 上の既存の VPC にプライベートクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
4.3.7.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.3.7.2. プライベートクラスター
外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。
プライベートクラスターをデプロイするには、以下を行う必要があります。
- 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
以下にアクセスできるマシンからデプロイ。
- プロビジョニングするクラウドの API サービス。
- プロビジョニングするネットワーク上のホスト。
- インストールメディアを取得するインターネット。
これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。
4.3.7.2.1. AWS のプライベートクラスター
Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。
クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。
以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。
- パブリックサブネット
- パブリック Ingress をサポートするパブリックロードバランサー
-
クラスターの
baseDomain
に一致するパブリック Route 53 ゾーン
インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain
とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。
4.3.7.2.1.1. 制限事項
プライベートクラスターにパブリック機能を追加する機能には制限があります。
- Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
-
パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに
kubernetes.io/cluster/<cluster-infra-id>: shared
のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。
4.3.7.3. カスタム VPC の使用について
OpenShift Container Platform 4.16 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
4.3.7.3.1. VPC を使用するための要件
インストールプログラムは、以下のコンポーネントを作成しなくなりました。
- インターネットゲートウェイ
- NAT ゲートウェイ
- サブネット
- ルートテーブル
- VPC
- VPC DHCP オプション
- VPC エンドポイント
インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。
カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC コンソールウィザードの設定と AWS VPC の作成および管理の詳細は、Amazon Web Services ドキュメントの VPC の作成 を参照してください。
インストールプログラムには、以下の機能はありません。
- 使用するクラスターのネットワーク範囲を細分化する。
- サブネットのルートテーブルを設定する。
- DHCP などの VPC オプションを設定する。
クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、VPC ネットワーキングコンポーネント と VPC のルートテーブル を参照してください。
VPC は以下の特性を満たす必要があります。
VPC は
kubernetes.io/cluster/.*: owned
、Name
、openshift.io/cluster
タグを使用できません。インストールプログラムは
kubernetes.io/cluster/.*: shared
タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name
タグは EC2Name
フィールドと重複し、その結果インストールが失敗するため、使用できません。-
OpenShift Container Platform クラスターを AWS Outpost に拡張し、既存の Outpost サブネットを使用する場合、既存のサブネットで
kubernetes.io/cluster/unmanaged: true
タグを使用する必要があります。このタグを適用しないと、Cloud Controller Manager が Outpost サブネットにサービスロードバランサーを作成するため、インストールが失敗する可能性があります。これはサポートされていない設定です。 VPC で
enableDnsSupport
およびenableDnsHostnames
属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。
install-config.yaml
ファイルのplatform.aws.hostedZone
フィールドとplatform.aws.hostedZoneRole
フィールドを使用して、ホストゾーンを定義できます。クラスターをインストールするアカウントとプライベートホストゾーンを共有することで、別のアカウントからプライベートホストゾーンを使用できます。別のアカウントからプライベートホストゾーンを使用する場合は、Passthrough
またはManual
認証情報モードを使用する必要があります。
非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。
オプション 1: VPC エンドポイントを作成する
VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
-
ec2.<aws_region>.amazonaws.com
-
elasticloadbalancing.<aws_region>.amazonaws.com
-
s3.<aws_region>.amazonaws.com
このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。
オプション 2: VPC エンドポイントなしでプロキシーを作成する
インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。
オプション 3: VPC エンドポイントでプロキシーを作成する
インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
-
ec2.<aws_region>.amazonaws.com
-
elasticloadbalancing.<aws_region>.amazonaws.com
-
s3.<aws_region>.amazonaws.com
install-config.yaml
ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy
フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。
必要な VPC コンポーネント
お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。
コンポーネント | AWS タイプ | 説明 | |
---|---|---|---|
VPC |
| 使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。 | |
パブリックサブネット |
| VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。 | |
インターネットゲートウェイ |
| VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。 | |
ネットワークアクセス制御 |
| VPC が以下のポートにアクセスできるようにする必要があります。 | |
ポート | 理由 | ||
| インバウンド HTTP トラフィック | ||
| インバウンド HTTPS トラフィック | ||
| インバウンド SSH トラフィック | ||
| インバウンド一時 (ephemeral) トラフィック | ||
| アウトバウンド一時 (ephemeral) トラフィック | ||
プライベートサブネット |
| VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 |
4.3.7.3.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared
タグは、それが使用したサブネットから削除されます。
4.3.7.3.3. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
4.3.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) はネットワーク全体に対して許可されます。
4.3.7.3.5. オプション: AWS セキュリティーグループ
デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。
ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml
ファイルを変更してカスタムセキュリティーグループを適用します。
詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。
4.3.7.4. インストール設定ファイルの手動作成
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
$ mkdir <installation_directory>
重要ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
提供されるサンプルの
install-config.yaml
ファイルテンプレートをカスタマイズし、これを<installation_directory>
に保存します。注記この設定ファイルの名前を
install-config.yaml
と付ける必要があります。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。
関連情報
4.3.7.4.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 アーキテクチャー を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
関連情報
4.3.7.4.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.33 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
4.3.7.4.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例4.34 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
4.3.7.4.4. 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: OVNKubernetes 13 serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-west-2 14 propagateUserTags: true 15 userTags: adminContact: jdoe costCenter: 7536 subnets: 16 - subnet-1 - subnet-2 - subnet-3 amiID: ami-0c5d3e03c0ab9b19a 17 serviceEndpoints: 18 - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV 19 fips: false 20 sshKey: ssh-ed25519 AAAA... 21 publish: Internal 22 pullSecret: '{"auths": ...}' 23
- 1 12 14 23
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2
- オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は
kube-system
namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。 - 3 8 15
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 5 9
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
m4.2xlarge
またはm5.2xlarge
などの大規模なインスタンスタイプを使用します。 - 6 10
- 大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを
io1
として設定し、iops
を2000
に設定します。 - 7 11
- Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を
Required
に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値をOptional
に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。注記クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。
- 13
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 16
- 独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
- 17
- クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
- 18
- AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は
https
プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。 - 19
- 既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
- 20
- 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 暗号化ライブラリーを使用します。
- 21
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 22
- クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、
publish
をInternal
に設定します。これはインターネットからアクセスできません。デフォルト値はExternal
です。
4.3.7.4.5. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.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
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。AmazonEC2
、Elastic 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 信頼バンドルからの認証局によって署名されない限り必要になります。 - 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.3.7.4.6. 既存の AWS セキュリティーグループをクラスターに適用する
既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
前提条件
- AWS でセキュリティーグループを作成している。詳細は、セキュリティーグループ の操作に関する AWS ドキュメントを参照してください。
- セキュリティーグループは、クラスターをデプロイする既存の VPC に関連付ける必要があります。セキュリティーグループを別の VPC に関連付けることはできません。
-
既存の
install-config.yaml
ファイルがある。
手順
-
install-config.yaml
ファイルで、compute.platform.aws.additionalSecurityGroupIDs
パラメーターを編集して、コンピュートマシンに 1 つ以上のカスタムセキュリティーグループを指定します。 -
controlPlane.platform.aws.additionalSecurityGroupIDs
パラメーターを編集して、コントロールプレーンマシンに 1 つ以上のカスタムセキュリティーグループを指定します。 - ファイルを保存し、クラスターをデプロイする際に参照します。
カスタムセキュリティーグループを指定するサンプル install-config.yaml
ファイル
# ... compute: - hyperthreading: Enabled name: worker platform: aws: additionalSecurityGroupIDs: - sg-1 1 - sg-2 replicas: 3 controlPlane: hyperthreading: Enabled name: master platform: aws: additionalSecurityGroupIDs: - sg-3 - sg-4 replicas: 3 platform: aws: region: us-east-1 subnets: 2 - subnet-1 - subnet-2 - subnet-3
4.3.7.5. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.3.7.5.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: AWSProviderSpec statementEntries: - effect: Allow action: - iam:GetUser - iam:GetUserPolicy - iam:ListAccessKeys resource: "*" ...
以前に生成した
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>
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
4.3.7.5.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.3.7.5.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.35 必要な AWS パーミッション
必要な
iam
権限-
iam:CreateOpenIDConnectProvider
-
iam:CreateRole
-
iam:DeleteOpenIDConnectProvider
-
iam:DeleteRole
-
iam:DeleteRolePolicy
-
iam:GetOpenIDConnectProvider
-
iam:GetRole
-
iam:GetUser
-
iam:ListOpenIDConnectProviders
-
iam:ListRolePolicies
-
iam:ListRoles
-
iam:PutRolePolicy
-
iam:TagOpenIDConnectProvider
-
iam:TagRole
必要な
s3
権限-
s3:CreateBucket
-
s3:DeleteBucket
-
s3:DeleteObject
-
s3:GetBucketAcl
-
s3:GetBucketTagging
-
s3:GetObject
-
s3:GetObjectAcl
-
s3:GetObjectTagging
-
s3:ListBucket
-
s3:PutBucketAcl
-
s3:PutBucketPolicy
-
s3:PutBucketPublicAccessBlock
-
s3:PutBucketTagging
-
s3:PutObject
-
s3:PutObjectAcl
-
s3:PutObjectTagging
必要な
cloudfront
権限-
cloudfront:ListCloudFrontOriginAccessIdentities
-
cloudfront:ListDistributions
-
cloudfront:ListTagsForResource
OIDC 設定を、パブリック CloudFront ディストリビューション URL 経由で IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに保存する予定の場合、
ccoctl
ユーティリティーを実行する AWS アカウントには次の追加パーミッションが必要です。例4.36 CloudFront を使用したプライベート S3 バケットに対する追加の権限
-
cloudfront:CreateCloudFrontOriginAccessIdentity
-
cloudfront:CreateDistribution
-
cloudfront:DeleteCloudFrontOriginAccessIdentity
-
cloudfront:DeleteDistribution
-
cloudfront:GetCloudFrontOriginAccessIdentity
-
cloudfront:GetCloudFrontOriginAccessIdentityConfig
-
cloudfront:GetDistribution
-
cloudfront:TagResource
-
cloudfront:UpdateDistribution
注記これらの追加のパーミッションは、
ccoctl aws create-all
コマンドで認証情報要求を処理する際の--create-private-s3-bucket
オプションの使用をサポートします。-
手順
次のコマンドを実行して、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.
4.3.7.5.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.3.7.5.2.2.1. 単一コマンドでの AWS リソースの作成
ccoctl
ツールが AWS リソースの作成に使用するプロセスが組織の要件を自動的に満たす場合は、ccoctl aws create-all
コマンドを使用して AWS リソースの作成を自動化できます。
それ以外の場合は、AWS リソースを個別に作成できます。詳細は、「AWS リソースの個別の作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-all \ --name=<name> \1 --region=<aws_region> \2 --credentials-requests-dir=<path_to_credentials_requests_directory> \3 --output-dir=<path_to_ccoctl_output_dir> \4 --create-private-s3-bucket 5
- 1
- 追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
- 2
- クラウドリソースが作成される AWS リージョンです。
- 3
- コンポーネント
CredentialsRequest
オブジェクトのファイルを含むディレクトリーを指定します。 - 4
- オプション:
ccoctl
ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。 - 5
- オプション: デフォルトでは、
ccoctl
ユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucket
パラメーターを使用します。
注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.7.5.2.2.2. AWS リソースの個別の作成
ccoctl
ツールを使用して、AWS リソースを個別に作成できます。このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。
それ以外の場合は、ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。詳細は、「単一コマンドによる AWS リソースの作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
一部の ccoctl
コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run
フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json
パラメーターを使用して適用できます。
前提条件
-
ccoctl
バイナリーを展開して準備しておく。
手順
次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。
$ ccoctl aws create-key-pair
出力例
2021/04/13 11:01:02 Generating RSA keypair 2021/04/13 11:01:03 Writing private key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.private 2021/04/13 11:01:03 Writing public key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.public 2021/04/13 11:01:03 Copying signing key for use by installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
$ ccoctl aws create-identity-provider \ --name=<name> \1 --region=<aws_region> \2 --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 3
出力例
2021/04/13 11:16:09 Bucket <name>-oidc created 2021/04/13 11:16:10 OpenID Connect discovery document in the S3 bucket <name>-oidc at .well-known/openid-configuration updated 2021/04/13 11:16:10 Reading public key 2021/04/13 11:16:10 JSON web key set (JWKS) in the S3 bucket <name>-oidc at keys.json updated 2021/04/13 11:16:18 Identity Provider created with ARN: arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
openid-configuration
は検出ドキュメントであり、keys.json
は JSON Web キーセットファイルです。このコマンドは、YAML 設定ファイルを
/<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yaml
にも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。クラスターの各コンポーネントについて IAM ロールを作成します。
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-iam-roles \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
注記GovCloud などの代替の IAM API エンドポイントを使用する AWS 環境では、
--region
パラメーターでリージョンを指定する必要もあります。クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。それぞれの
CredentialsRequest
オブジェクトについて、ccoctl
は指定された OIDC アイデンティティープロバイダーに関連付けられた信頼ポリシーと、OpenShift Container Platform リリースイメージの各CredentialsRequest
オブジェクトに定義されるパーミッションポリシーを使用して IAM ロールを作成します。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.7.5.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 # ...
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ 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 .
4.3.7.6. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.3.7.7. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
4.3.7.8. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。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
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.3.7.9. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
4.3.8. AWS の government リージョンへのクラスターのインストール
OpenShift Container Platform バージョン 4.16 では、Amazon Web Services (AWS) 上のクラスターを government リージョンにインストールできます。リージョンを設定するには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
4.3.8.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.3.8.2. AWS government リージョン
OpenShift Container Platform は、AWS GovCloud (US) リージョンへのクラスターのデプロイをサポートします。
以下の AWS GovCloud パーティションがサポートされます。
-
us-gov-east-1
-
us-gov-west-1
4.3.8.3. インストール要件
クラスターをインストールする前に、以下を行う必要があります。
クラスターをホストするために、既存のプライベート AWS VPC とサブネットを提供します。
パブリックゾーンは、AWS GovCloud の Route 53 ではサポートされません。その結果、AWS government リージョンにデプロイする場合、クラスターはプライベートである必要があります。
-
インストール設定ファイル (
install-config.yaml
) を手動で作成します。
4.3.8.4. プライベートクラスター
外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
パブリックゾーンは、AWS GovCloud リージョンの Route 53 ではサポートされていません。したがって、クラスターを AWS GovCloud リージョンにデプロイする場合は、クラスターをプライベートにする必要があります。
デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。
プライベートクラスターをデプロイするには、以下を行う必要があります。
- 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
以下にアクセスできるマシンからデプロイ。
- プロビジョニングするクラウドの API サービス。
- プロビジョニングするネットワーク上のホスト。
- インストールメディアを取得するインターネット。
これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。
4.3.8.4.1. AWS のプライベートクラスター
Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。
クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。
以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。
- パブリックサブネット
- パブリック Ingress をサポートするパブリックロードバランサー
-
クラスターの
baseDomain
に一致するパブリック Route 53 ゾーン
インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain
とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。
4.3.8.4.1.1. 制限事項
プライベートクラスターにパブリック機能を追加する機能には制限があります。
- Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
-
パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに
kubernetes.io/cluster/<cluster-infra-id>: shared
のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。
4.3.8.5. カスタム VPC の使用について
OpenShift Container Platform 4.16 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
4.3.8.5.1. VPC を使用するための要件
インストールプログラムは、以下のコンポーネントを作成しなくなりました。
- インターネットゲートウェイ
- NAT ゲートウェイ
- サブネット
- ルートテーブル
- VPC
- VPC DHCP オプション
- VPC エンドポイント
インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。
カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC コンソールウィザードの設定と AWS VPC の作成および管理の詳細は、Amazon Web Services ドキュメントの VPC の作成 を参照してください。
インストールプログラムには、以下の機能はありません。
- 使用するクラスターのネットワーク範囲を細分化する。
- サブネットのルートテーブルを設定する。
- DHCP などの VPC オプションを設定する。
クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、VPC ネットワーキングコンポーネント と VPC のルートテーブル を参照してください。
VPC は以下の特性を満たす必要があります。
VPC は
kubernetes.io/cluster/.*: owned
、Name
、openshift.io/cluster
タグを使用できません。インストールプログラムは
kubernetes.io/cluster/.*: shared
タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name
タグは EC2Name
フィールドと重複し、その結果インストールが失敗するため、使用できません。-
OpenShift Container Platform クラスターを AWS Outpost に拡張し、既存の Outpost サブネットを使用する場合、既存のサブネットで
kubernetes.io/cluster/unmanaged: true
タグを使用する必要があります。このタグを適用しないと、Cloud Controller Manager が Outpost サブネットにサービスロードバランサーを作成するため、インストールが失敗する可能性があります。これはサポートされていない設定です。 VPC で
enableDnsSupport
およびenableDnsHostnames
属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。
install-config.yaml
ファイルのplatform.aws.hostedZone
フィールドとplatform.aws.hostedZoneRole
フィールドを使用して、ホストゾーンを定義できます。クラスターをインストールするアカウントとプライベートホストゾーンを共有することで、別のアカウントからプライベートホストゾーンを使用できます。別のアカウントからプライベートホストゾーンを使用する場合は、Passthrough
またはManual
認証情報モードを使用する必要があります。
非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。
オプション 1: VPC エンドポイントを作成する
VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
-
ec2.<aws_region>.amazonaws.com
-
elasticloadbalancing.<aws_region>.amazonaws.com
-
s3.<aws_region>.amazonaws.com
このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。
オプション 2: VPC エンドポイントなしでプロキシーを作成する
インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。
オプション 3: VPC エンドポイントでプロキシーを作成する
インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
-
ec2.<aws_region>.amazonaws.com
-
elasticloadbalancing.<aws_region>.amazonaws.com
-
s3.<aws_region>.amazonaws.com
install-config.yaml
ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy
フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。
必要な VPC コンポーネント
お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。
コンポーネント | AWS タイプ | 説明 | |
---|---|---|---|
VPC |
| 使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。 | |
パブリックサブネット |
| VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。 | |
インターネットゲートウェイ |
| VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。 | |
ネットワークアクセス制御 |
| VPC が以下のポートにアクセスできるようにする必要があります。 | |
ポート | 理由 | ||
| インバウンド HTTP トラフィック | ||
| インバウンド HTTPS トラフィック | ||
| インバウンド SSH トラフィック | ||
| インバウンド一時 (ephemeral) トラフィック | ||
| アウトバウンド一時 (ephemeral) トラフィック | ||
プライベートサブネット |
| VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 |
4.3.8.5.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared
タグは、それが使用したサブネットから削除されます。
4.3.8.5.3. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
4.3.8.5.4. クラスター間の分離
OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。
- 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
- ICMP Ingress はネットワーク全体から許可されます。
- TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
4.3.8.5.5. オプション: AWS セキュリティーグループ
デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。
ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml
ファイルを変更してカスタムセキュリティーグループを適用します。
詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。
4.3.8.6. AWS Marketplace イメージの取得
AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがコンピュートノードのデプロイに使用する AMI ID が提供されます。
前提条件
- オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。
手順
- AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
ご使用の AWS リージョンの 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": ...}'
4.3.8.7. インストール設定ファイルの手動作成
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
$ mkdir <installation_directory>
重要ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
提供されるサンプルの
install-config.yaml
ファイルテンプレートをカスタマイズし、これを<installation_directory>
に保存します。注記この設定ファイルの名前を
install-config.yaml
と付ける必要があります。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。
関連情報
4.3.8.7.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 アーキテクチャー を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
関連情報
4.3.8.7.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.37 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
4.3.8.7.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例4.38 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
4.3.8.7.4. 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: OVNKubernetes 13 serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-gov-west-1 14 propagateUserTags: true 15 userTags: adminContact: jdoe costCenter: 7536 subnets: 16 - subnet-1 - subnet-2 - subnet-3 amiID: ami-0c5d3e03c0ab9b19a 17 serviceEndpoints: 18 - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV 19 fips: false 20 sshKey: ssh-ed25519 AAAA... 21 publish: Internal 22 pullSecret: '{"auths": ...}' 23
- 1 12 14 23
- 必須。
- 2
- オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は
kube-system
namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。 - 3 8 15
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 5 9
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
m4.2xlarge
またはm5.2xlarge
などの大規模なインスタンスタイプを使用します。 - 6 10
- 大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを
io1
として設定し、iops
を2000
に設定します。 - 7 11
- Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を
Required
に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値をOptional
に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。注記クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。
- 13
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 16
- 独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
- 17
- クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
- 18
- AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は
https
プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。 - 19
- 既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
- 20
- 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 暗号化ライブラリーを使用します。
- 21
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 22
- クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、
publish
をInternal
に設定します。これはインターネットからアクセスできません。デフォルト値はExternal
です。
4.3.8.7.5. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.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
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。AmazonEC2
、Elastic 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 信頼バンドルからの認証局によって署名されない限り必要になります。 - 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.3.8.7.6. 既存の AWS セキュリティーグループをクラスターに適用する
既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
前提条件
- AWS でセキュリティーグループを作成している。詳細は、セキュリティーグループ の操作に関する AWS ドキュメントを参照してください。
- セキュリティーグループは、クラスターをデプロイする既存の VPC に関連付ける必要があります。セキュリティーグループを別の VPC に関連付けることはできません。
-
既存の
install-config.yaml
ファイルがある。
手順
-
install-config.yaml
ファイルで、compute.platform.aws.additionalSecurityGroupIDs
パラメーターを編集して、コンピュートマシンに 1 つ以上のカスタムセキュリティーグループを指定します。 -
controlPlane.platform.aws.additionalSecurityGroupIDs
パラメーターを編集して、コントロールプレーンマシンに 1 つ以上のカスタムセキュリティーグループを指定します。 - ファイルを保存し、クラスターをデプロイする際に参照します。
カスタムセキュリティーグループを指定するサンプル install-config.yaml
ファイル
# ... compute: - hyperthreading: Enabled name: worker platform: aws: additionalSecurityGroupIDs: - sg-1 1 - sg-2 replicas: 3 controlPlane: hyperthreading: Enabled name: master platform: aws: additionalSecurityGroupIDs: - sg-3 - sg-4 replicas: 3 platform: aws: region: us-east-1 subnets: 2 - subnet-1 - subnet-2 - subnet-3
4.3.8.8. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- 個々のコンポーネントのクラスター外部で管理される短期認証情報を実装するには、Cloud Credential Operator ユーティリティーマニフェストの組み込み に記載された手順に従います。
4.3.8.8.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: AWSProviderSpec statementEntries: - effect: Allow action: - iam:GetUser - iam:GetUserPolicy - iam:ListAccessKeys resource: "*" ...
以前に生成した
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>
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
4.3.8.8.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.3.8.8.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.39 必要な AWS パーミッション
必要な
iam
権限-
iam:CreateOpenIDConnectProvider
-
iam:CreateRole
-
iam:DeleteOpenIDConnectProvider
-
iam:DeleteRole
-
iam:DeleteRolePolicy
-
iam:GetOpenIDConnectProvider
-
iam:GetRole
-
iam:GetUser
-
iam:ListOpenIDConnectProviders
-
iam:ListRolePolicies
-
iam:ListRoles
-
iam:PutRolePolicy
-
iam:TagOpenIDConnectProvider
-
iam:TagRole
必要な
s3
権限-
s3:CreateBucket
-
s3:DeleteBucket
-
s3:DeleteObject
-
s3:GetBucketAcl
-
s3:GetBucketTagging
-
s3:GetObject
-
s3:GetObjectAcl
-
s3:GetObjectTagging
-
s3:ListBucket
-
s3:PutBucketAcl
-
s3:PutBucketPolicy
-
s3:PutBucketPublicAccessBlock
-
s3:PutBucketTagging
-
s3:PutObject
-
s3:PutObjectAcl
-
s3:PutObjectTagging
必要な
cloudfront
権限-
cloudfront:ListCloudFrontOriginAccessIdentities
-
cloudfront:ListDistributions
-
cloudfront:ListTagsForResource
OIDC 設定を、パブリック CloudFront ディストリビューション URL 経由で IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに保存する予定の場合、
ccoctl
ユーティリティーを実行する AWS アカウントには次の追加パーミッションが必要です。例4.40 CloudFront を使用したプライベート S3 バケットに対する追加の権限
-
cloudfront:CreateCloudFrontOriginAccessIdentity
-
cloudfront:CreateDistribution
-
cloudfront:DeleteCloudFrontOriginAccessIdentity
-
cloudfront:DeleteDistribution
-
cloudfront:GetCloudFrontOriginAccessIdentity
-
cloudfront:GetCloudFrontOriginAccessIdentityConfig
-
cloudfront:GetDistribution
-
cloudfront:TagResource
-
cloudfront:UpdateDistribution
注記これらの追加のパーミッションは、
ccoctl aws create-all
コマンドで認証情報要求を処理する際の--create-private-s3-bucket
オプションの使用をサポートします。-
手順
次のコマンドを実行して、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.
4.3.8.8.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.3.8.8.2.2.1. 単一コマンドでの AWS リソースの作成
ccoctl
ツールが AWS リソースの作成に使用するプロセスが組織の要件を自動的に満たす場合は、ccoctl aws create-all
コマンドを使用して AWS リソースの作成を自動化できます。
それ以外の場合は、AWS リソースを個別に作成できます。詳細は、「AWS リソースの個別の作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-all \ --name=<name> \1 --region=<aws_region> \2 --credentials-requests-dir=<path_to_credentials_requests_directory> \3 --output-dir=<path_to_ccoctl_output_dir> \4 --create-private-s3-bucket 5
- 1
- 追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
- 2
- クラウドリソースが作成される AWS リージョンです。
- 3
- コンポーネント
CredentialsRequest
オブジェクトのファイルを含むディレクトリーを指定します。 - 4
- オプション:
ccoctl
ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。 - 5
- オプション: デフォルトでは、
ccoctl
ユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucket
パラメーターを使用します。
注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.8.8.2.2.2. AWS リソースの個別の作成
ccoctl
ツールを使用して、AWS リソースを個別に作成できます。このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。
それ以外の場合は、ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。詳細は、「単一コマンドによる AWS リソースの作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
一部の ccoctl
コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run
フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json
パラメーターを使用して適用できます。
前提条件
-
ccoctl
バイナリーを展開して準備しておく。
手順
次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。
$ ccoctl aws create-key-pair
出力例
2021/04/13 11:01:02 Generating RSA keypair 2021/04/13 11:01:03 Writing private key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.private 2021/04/13 11:01:03 Writing public key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.public 2021/04/13 11:01:03 Copying signing key for use by installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
$ ccoctl aws create-identity-provider \ --name=<name> \1 --region=<aws_region> \2 --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 3
出力例
2021/04/13 11:16:09 Bucket <name>-oidc created 2021/04/13 11:16:10 OpenID Connect discovery document in the S3 bucket <name>-oidc at .well-known/openid-configuration updated 2021/04/13 11:16:10 Reading public key 2021/04/13 11:16:10 JSON web key set (JWKS) in the S3 bucket <name>-oidc at keys.json updated 2021/04/13 11:16:18 Identity Provider created with ARN: arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
openid-configuration
は検出ドキュメントであり、keys.json
は JSON Web キーセットファイルです。このコマンドは、YAML 設定ファイルを
/<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yaml
にも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。クラスターの各コンポーネントについて IAM ロールを作成します。
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-iam-roles \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
注記GovCloud などの代替の IAM API エンドポイントを使用する AWS 環境では、
--region
パラメーターでリージョンを指定する必要もあります。クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。それぞれの
CredentialsRequest
オブジェクトについて、ccoctl
は指定された OIDC アイデンティティープロバイダーに関連付けられた信頼ポリシーと、OpenShift Container Platform リリースイメージの各CredentialsRequest
オブジェクトに定義されるパーミッションポリシーを使用して IAM ロールを作成します。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.8.8.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 # ...
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ 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 .
4.3.8.9. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.3.8.10. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
4.3.8.11. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。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
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.3.8.12. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
4.3.9. AWS 上のクラスターをシークレットまたはトップシークレットリージョンにインストールする
OpenShift Container Platform バージョン 4.16 では、Amazon Web Services (AWS) 上のクラスターを以下のシークレットリージョンにインストールできます。
- シークレット Commercial Cloud Services (SC2S)
- Commercial Cloud Services (C2S)
いずれかのリージョンでクラスターを設定するには、クラスターをインストールする前に、install config.yaml
ファイルのパラメーターを変更します。
OpenShift Container Platform 4.16 では、インストールプログラムは Terraform の代わりに Cluster API を使用して、AWS へのインストール中にクラスターインフラストラクチャーをプロビジョニングします。Cluster API 実装を使用した AWS のクラスターをシークレットまたはトップシークレットリージョンにインストールすることは、OpenShift Container Platform 4.16 のリリース時点ではテストされていません。このドキュメントは、シークレットリージョンへのインストールがテストされたときに更新されます。
Network Load Balancer のシークレットまたはトップシークレットリージョンのセキュリティーグループのサポートには既知の問題があり、これらのリージョンのインストールが失敗します。詳細は、OCPBUGS-33311 を参照してください。
4.3.9.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要コンピューターに AWS プロファイルが保存されている場合は、多要素認証デバイスの使用中に生成した一時的なセッショントークンを使用しないでください。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.3.9.2. AWS シークレットリージョン
次の AWS シークレットパーティションがサポートされています。
-
us-isob-east-1
(SC2S) -
us-iso-east-1
(C2S)
AWS SC2S および C2S リージョンでサポートされる最大 MTU は、AWS コマーシャルと同じではありません。インストール中の MTU の設定に関する詳細は、ネットワークをカスタマイズした AWS へのクラスターのインストール の クラスターネットワークオペレーターの設定オブジェクト セクションを参照してください。
4.3.9.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 バンドルを定義する必要があります。
4.3.9.4. プライベートクラスター
外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
パブリックゾーンは、AWS トップシークレットリージョンの Route 53 ではサポートされていません。したがって、クラスターを AWS トップシークレットリージョンにデプロイする場合は、クラスターをプライベートにする必要があります。
デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。
プライベートクラスターをデプロイするには、以下を行う必要があります。
- 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
以下にアクセスできるマシンからデプロイ。
- プロビジョニングするクラウドの API サービス。
- プロビジョニングするネットワーク上のホスト。
- インストールメディアを取得するインターネット。
これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。
4.3.9.4.1. AWS のプライベートクラスター
Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。
クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。
以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。
- パブリックサブネット
- パブリック Ingress をサポートするパブリックロードバランサー
-
クラスターの
baseDomain
に一致するパブリック Route 53 ゾーン
インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain
とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。
4.3.9.4.1.1. 制限事項
プライベートクラスターにパブリック機能を追加する機能には制限があります。
- Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
-
パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに
kubernetes.io/cluster/<cluster-infra-id>: shared
のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。
4.3.9.5. カスタム VPC の使用について
OpenShift Container Platform 4.16 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
4.3.9.5.1. VPC を使用するための要件
インストールプログラムは、以下のコンポーネントを作成しなくなりました。
- インターネットゲートウェイ
- NAT ゲートウェイ
- サブネット
- ルートテーブル
- VPC
- VPC DHCP オプション
- VPC エンドポイント
インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。
カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC コンソールウィザードの設定と AWS VPC の作成および管理の詳細は、Amazon Web Services ドキュメントの VPC の作成 を参照してください。
インストールプログラムには、以下の機能はありません。
- 使用するクラスターのネットワーク範囲を細分化する。
- サブネットのルートテーブルを設定する。
- DHCP などの VPC オプションを設定する。
クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、VPC ネットワーキングコンポーネント と VPC のルートテーブル を参照してください。
VPC は以下の特性を満たす必要があります。
VPC は
kubernetes.io/cluster/.*: owned
、Name
、openshift.io/cluster
タグを使用できません。インストールプログラムは
kubernetes.io/cluster/.*: shared
タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name
タグは EC2Name
フィールドと重複し、その結果インストールが失敗するため、使用できません。-
OpenShift Container Platform クラスターを AWS Outpost に拡張し、既存の Outpost サブネットを使用する場合、既存のサブネットで
kubernetes.io/cluster/unmanaged: true
タグを使用する必要があります。このタグを適用しないと、Cloud Controller Manager が Outpost サブネットにサービスロードバランサーを作成するため、インストールが失敗する可能性があります。これはサポートされていない設定です。 VPC で
enableDnsSupport
およびenableDnsHostnames
属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。
install-config.yaml
ファイルのplatform.aws.hostedZone
フィールドとplatform.aws.hostedZoneRole
フィールドを使用して、ホストゾーンを定義できます。クラスターをインストールするアカウントとプライベートホストゾーンを共有することで、別のアカウントからプライベートホストゾーンを使用できます。別のアカウントからプライベートホストゾーンを使用する場合は、Passthrough
またはManual
認証情報モードを使用する必要があります。
SC2S または C2S リージョンのクラスターは、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達できません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。
オプション 1: VPC エンドポイントを作成する
VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
- SC2S
-
elasticloadbalancing.<aws_region>.sc2s.sgov.gov
-
ec2.<aws_region>.sc2s.sgov.gov
-
s3.<aws_region>.sc2s.sgov.gov
-
- C2S
-
elasticloadbalancing.<aws_region>.c2s.ic.gov
-
ec2.<aws_region>.c2s.ic.gov
-
s3.<aws_region>.c2s.ic.gov
-
このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。
オプション 2: VPC エンドポイントなしでプロキシーを作成する
インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。
オプション 3: VPC エンドポイントでプロキシーを作成する
インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
- SC2S
-
elasticloadbalancing.<aws_region>.sc2s.sgov.gov
-
ec2.<aws_region>.sc2s.sgov.gov
-
s3.<aws_region>.sc2s.sgov.gov
-
- C2S
-
elasticloadbalancing.<aws_region>.c2s.ic.gov
-
ec2.<aws_region>.c2s.ic.gov
-
s3.<aws_region>.c2s.ic.gov
-
install-config.yaml
ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy
フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。
必要な VPC コンポーネント
お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。
コンポーネント | AWS タイプ | 説明 | |
---|---|---|---|
VPC |
| 使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。 | |
パブリックサブネット |
| VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。 | |
インターネットゲートウェイ |
| VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。 | |
ネットワークアクセス制御 |
| VPC が以下のポートにアクセスできるようにする必要があります。 | |
ポート | 理由 | ||
| インバウンド HTTP トラフィック | ||
| インバウンド HTTPS トラフィック | ||
| インバウンド SSH トラフィック | ||
| インバウンド一時 (ephemeral) トラフィック | ||
| アウトバウンド一時 (ephemeral) トラフィック | ||
プライベートサブネット |
| VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 |
4.3.9.5.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared
タグは、それが使用したサブネットから削除されます。
4.3.9.5.3. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
4.3.9.5.4. クラスター間の分離
OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。
- 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
- ICMP Ingress はネットワーク全体から許可されます。
- TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
4.3.9.5.5. オプション: AWS セキュリティーグループ
デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。
ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml
ファイルを変更してカスタムセキュリティーグループを適用します。
詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。
4.3.9.6. 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 を参照してください。
手順
AWS プロファイルを環境変数としてエクスポートします。
$ export AWS_PROFILE=<aws_profile> 1
カスタム AMI に関連付けるリージョンを環境変数としてエクスポートします。
$ export AWS_DEFAULT_REGION=<aws_region> 1
環境変数として Amazon S3 にアップロードした RHCOS のバージョンをエクスポートします。
$ export RHCOS_VERSION=<version> 1
Amazon S3 バケット名を環境変数としてエクスポートします。
$ export VMIMPORT_BUCKET_NAME=<s3_bucket_name>
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
RHCOS ディスクを Amazon EBS スナップショットとしてインポートします。
$ aws ec2 import-snapshot --region ${AWS_DEFAULT_REGION} \ --description "<description>" \ 1 --disk-container "file://<file_path>/containers.json" 2
イメージインポートのステータスを確認します。
$ 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
をコピーして、イメージを登録します。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
これらの API の詳細は、AWS ドキュメントの importing snapshots および creating EBS-backed AMIs を参照してください。
4.3.9.7. インストール設定ファイルの手動作成
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- カスタムの RHCOS AMI をアップロードしている。
- ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
$ mkdir <installation_directory>
重要ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
提供されるサンプルの
install-config.yaml
ファイルテンプレートをカスタマイズし、これを<installation_directory>
に保存します。注記この設定ファイルの名前を
install-config.yaml
と付ける必要があります。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。
関連情報
4.3.9.7.1. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.41 シークレット領域の 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
i3.*
-
m4.*
-
m5.*
-
r4.*
-
r5.*
-
t3.*
4.3.9.7.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: - 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: OVNKubernetes 13 serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-iso-east-1 14 propagateUserTags: true 15 userTags: adminContact: jdoe costCenter: 7536 subnets: 16 - subnet-1 - subnet-2 - subnet-3 amiID: ami-96c6f8f7 17 18 serviceEndpoints: 19 - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV 20 fips: false 21 sshKey: ssh-ed25519 AAAA... 22 publish: Internal 23 pullSecret: '{"auths": ...}' 24 additionalTrustBundle: | 25 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE-----
- 1 12 14 17 24
- 必須。
- 2
- オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は
kube-system
namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。 - 3 8 15
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 5 9
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
m4.2xlarge
またはm5.2xlarge
などの大規模なインスタンスタイプを使用します。 - 6 10
- 大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを
io1
として設定し、iops
を2000
に設定します。 - 7 11
- Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を
Required
に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値をOptional
に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。注記クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。
- 13
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 16
- 独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
- 18
- クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
- 19
- AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は
https
プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。 - 20
- 既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
- 21
- 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 暗号化ライブラリーを使用します。
- 22
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 23
- クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、
publish
をInternal
に設定します。これはインターネットからアクセスできません。デフォルト値はExternal
です。 - 25
- カスタム CA 証明書。これは、SC2S または C2S リージョンにデプロイするときに必要です。これは、AWS API がカスタム CA 信頼バンドルを必要とするためです。
4.3.9.7.3. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.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
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。AmazonEC2
、Elastic 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 信頼バンドルからの認証局によって署名されない限り必要になります。 - 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.3.9.7.4. 既存の AWS セキュリティーグループをクラスターに適用する
既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
前提条件
- AWS でセキュリティーグループを作成している。詳細は、セキュリティーグループ の操作に関する AWS ドキュメントを参照してください。
- セキュリティーグループは、クラスターをデプロイする既存の VPC に関連付ける必要があります。セキュリティーグループを別の VPC に関連付けることはできません。
-
既存の
install-config.yaml
ファイルがある。
手順
-
install-config.yaml
ファイルで、compute.platform.aws.additionalSecurityGroupIDs
パラメーターを編集して、コンピュートマシンに 1 つ以上のカスタムセキュリティーグループを指定します。 -
controlPlane.platform.aws.additionalSecurityGroupIDs
パラメーターを編集して、コントロールプレーンマシンに 1 つ以上のカスタムセキュリティーグループを指定します。 - ファイルを保存し、クラスターをデプロイする際に参照します。
カスタムセキュリティーグループを指定するサンプル install-config.yaml
ファイル
# ... compute: - hyperthreading: Enabled name: worker platform: aws: additionalSecurityGroupIDs: - sg-1 1 - sg-2 replicas: 3 controlPlane: hyperthreading: Enabled name: master platform: aws: additionalSecurityGroupIDs: - sg-3 - sg-4 replicas: 3 platform: aws: region: us-east-1 subnets: 2 - subnet-1 - subnet-2 - subnet-3
4.3.9.8. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.3.9.8.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: AWSProviderSpec statementEntries: - effect: Allow action: - iam:GetUser - iam:GetUserPolicy - iam:ListAccessKeys resource: "*" ...
以前に生成した
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>
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
4.3.9.8.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.3.9.8.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.42 必要な AWS パーミッション
必要な
iam
権限-
iam:CreateOpenIDConnectProvider
-
iam:CreateRole
-
iam:DeleteOpenIDConnectProvider
-
iam:DeleteRole
-
iam:DeleteRolePolicy
-
iam:GetOpenIDConnectProvider
-
iam:GetRole
-
iam:GetUser
-
iam:ListOpenIDConnectProviders
-
iam:ListRolePolicies
-
iam:ListRoles
-
iam:PutRolePolicy
-
iam:TagOpenIDConnectProvider
-
iam:TagRole
必要な
s3
権限-
s3:CreateBucket
-
s3:DeleteBucket
-
s3:DeleteObject
-
s3:GetBucketAcl
-
s3:GetBucketTagging
-
s3:GetObject
-
s3:GetObjectAcl
-
s3:GetObjectTagging
-
s3:ListBucket
-
s3:PutBucketAcl
-
s3:PutBucketPolicy
-
s3:PutBucketPublicAccessBlock
-
s3:PutBucketTagging
-
s3:PutObject
-
s3:PutObjectAcl
-
s3:PutObjectTagging
必要な
cloudfront
権限-
cloudfront:ListCloudFrontOriginAccessIdentities
-
cloudfront:ListDistributions
-
cloudfront:ListTagsForResource
OIDC 設定を、パブリック CloudFront ディストリビューション URL 経由で IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに保存する予定の場合、
ccoctl
ユーティリティーを実行する AWS アカウントには次の追加パーミッションが必要です。例4.43 CloudFront を使用したプライベート S3 バケットに対する追加の権限
-
cloudfront:CreateCloudFrontOriginAccessIdentity
-
cloudfront:CreateDistribution
-
cloudfront:DeleteCloudFrontOriginAccessIdentity
-
cloudfront:DeleteDistribution
-
cloudfront:GetCloudFrontOriginAccessIdentity
-
cloudfront:GetCloudFrontOriginAccessIdentityConfig
-
cloudfront:GetDistribution
-
cloudfront:TagResource
-
cloudfront:UpdateDistribution
注記これらの追加のパーミッションは、
ccoctl aws create-all
コマンドで認証情報要求を処理する際の--create-private-s3-bucket
オプションの使用をサポートします。-
手順
次のコマンドを実行して、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.
4.3.9.8.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.3.9.8.2.2.1. 単一コマンドでの AWS リソースの作成
ccoctl
ツールが AWS リソースの作成に使用するプロセスが組織の要件を自動的に満たす場合は、ccoctl aws create-all
コマンドを使用して AWS リソースの作成を自動化できます。
それ以外の場合は、AWS リソースを個別に作成できます。詳細は、「AWS リソースの個別の作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-all \ --name=<name> \1 --region=<aws_region> \2 --credentials-requests-dir=<path_to_credentials_requests_directory> \3 --output-dir=<path_to_ccoctl_output_dir> \4 --create-private-s3-bucket 5
- 1
- 追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
- 2
- クラウドリソースが作成される AWS リージョンです。
- 3
- コンポーネント
CredentialsRequest
オブジェクトのファイルを含むディレクトリーを指定します。 - 4
- オプション:
ccoctl
ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。 - 5
- オプション: デフォルトでは、
ccoctl
ユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucket
パラメーターを使用します。
注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.9.8.2.2.2. AWS リソースの個別の作成
ccoctl
ツールを使用して、AWS リソースを個別に作成できます。このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。
それ以外の場合は、ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。詳細は、「単一コマンドによる AWS リソースの作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
一部の ccoctl
コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run
フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json
パラメーターを使用して適用できます。
前提条件
-
ccoctl
バイナリーを展開して準備しておく。
手順
次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。
$ ccoctl aws create-key-pair
出力例
2021/04/13 11:01:02 Generating RSA keypair 2021/04/13 11:01:03 Writing private key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.private 2021/04/13 11:01:03 Writing public key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.public 2021/04/13 11:01:03 Copying signing key for use by installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
$ ccoctl aws create-identity-provider \ --name=<name> \1 --region=<aws_region> \2 --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 3
出力例
2021/04/13 11:16:09 Bucket <name>-oidc created 2021/04/13 11:16:10 OpenID Connect discovery document in the S3 bucket <name>-oidc at .well-known/openid-configuration updated 2021/04/13 11:16:10 Reading public key 2021/04/13 11:16:10 JSON web key set (JWKS) in the S3 bucket <name>-oidc at keys.json updated 2021/04/13 11:16:18 Identity Provider created with ARN: arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
openid-configuration
は検出ドキュメントであり、keys.json
は JSON Web キーセットファイルです。このコマンドは、YAML 設定ファイルを
/<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yaml
にも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。クラスターの各コンポーネントについて IAM ロールを作成します。
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-iam-roles \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
注記GovCloud などの代替の IAM API エンドポイントを使用する AWS 環境では、
--region
パラメーターでリージョンを指定する必要もあります。クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。それぞれの
CredentialsRequest
オブジェクトについて、ccoctl
は指定された OIDC アイデンティティープロバイダーに関連付けられた信頼ポリシーと、OpenShift Container Platform リリースイメージの各CredentialsRequest
オブジェクトに定義されるパーミッションポリシーを使用して IAM ロールを作成します。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.9.8.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 # ...
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ 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 .
4.3.9.9. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.3.9.10. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
4.3.9.11. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。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
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
4.3.9.12. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
4.3.10. AWS China でのクラスターのアンインストール
OpenShift Container Platform バージョン 4.16 では、クラスターを以下の Amazon Web Services (AWS) China リージョンにインストールできます。
-
cn-north-1
(Beijing) -
cn-northwest-1
(Ningxia)
4.3.10.1. 前提条件
- インターネットコンテンツプロバイダー (ICP) ライセンスがある。
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- クラスターをホストするために AWS アカウントを設定 している。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
4.3.10.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 リージョンをリスト表示しません。
4.3.10.3. プライベートクラスター
外部エンドポイントを公開しないプライベート 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 を参照してください。
4.3.10.3.1. AWS のプライベートクラスター
Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。
クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。
以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。
- パブリックサブネット
- パブリック Ingress をサポートするパブリックロードバランサー
-
クラスターの
baseDomain
に一致するパブリック Route 53 ゾーン
インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain
とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。
4.3.10.3.1.1. 制限事項
プライベートクラスターにパブリック機能を追加する機能には制限があります。
- Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
-
パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに
kubernetes.io/cluster/<cluster-infra-id>: shared
のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。
4.3.10.4. カスタム VPC の使用について
OpenShift Container Platform 4.16 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
4.3.10.4.1. VPC を使用するための要件
インストールプログラムは、以下のコンポーネントを作成しなくなりました。
- インターネットゲートウェイ
- NAT ゲートウェイ
- サブネット
- ルートテーブル
- VPC
- VPC DHCP オプション
- VPC エンドポイント
インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。
カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC コンソールウィザードの設定と AWS VPC の作成および管理の詳細は、Amazon Web Services ドキュメントの VPC の作成 を参照してください。
インストールプログラムには、以下の機能はありません。
- 使用するクラスターのネットワーク範囲を細分化する。
- サブネットのルートテーブルを設定する。
- DHCP などの VPC オプションを設定する。
クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、VPC ネットワーキングコンポーネント と VPC のルートテーブル を参照してください。
VPC は以下の特性を満たす必要があります。
VPC は
kubernetes.io/cluster/.*: owned
、Name
、openshift.io/cluster
タグを使用できません。インストールプログラムは
kubernetes.io/cluster/.*: shared
タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name
タグは EC2Name
フィールドと重複し、その結果インストールが失敗するため、使用できません。-
OpenShift Container Platform クラスターを AWS Outpost に拡張し、既存の Outpost サブネットを使用する場合、既存のサブネットで
kubernetes.io/cluster/unmanaged: true
タグを使用する必要があります。このタグを適用しないと、Cloud Controller Manager が Outpost サブネットにサービスロードバランサーを作成するため、インストールが失敗する可能性があります。これはサポートされていない設定です。 VPC で
enableDnsSupport
およびenableDnsHostnames
属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。
install-config.yaml
ファイルのplatform.aws.hostedZone
フィールドとplatform.aws.hostedZoneRole
フィールドを使用して、ホストゾーンを定義できます。クラスターをインストールするアカウントとプライベートホストゾーンを共有することで、別のアカウントからプライベートホストゾーンを使用できます。別のアカウントからプライベートホストゾーンを使用する場合は、Passthrough
またはManual
認証情報モードを使用する必要があります。
非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。
オプション 1: VPC エンドポイントを作成する
VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
-
ec2.<aws_region>.amazonaws.com.cn
-
elasticloadbalancing.<aws_region>.amazonaws.com
-
s3.<aws_region>.amazonaws.com
このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。
オプション 2: VPC エンドポイントなしでプロキシーを作成する
インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。
オプション 3: VPC エンドポイントでプロキシーを作成する
インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
-
ec2.<aws_region>.amazonaws.com.cn
-
elasticloadbalancing.<aws_region>.amazonaws.com
-
s3.<aws_region>.amazonaws.com
install-config.yaml
ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy
フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。
必要な VPC コンポーネント
お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。
コンポーネント | AWS タイプ | 説明 | |
---|---|---|---|
VPC |
| 使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。 | |
パブリックサブネット |
| VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。 | |
インターネットゲートウェイ |
| VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。 | |
ネットワークアクセス制御 |
| VPC が以下のポートにアクセスできるようにする必要があります。 | |
ポート | 理由 | ||
| インバウンド HTTP トラフィック | ||
| インバウンド HTTPS トラフィック | ||
| インバウンド SSH トラフィック | ||
| インバウンド一時 (ephemeral) トラフィック | ||
| アウトバウンド一時 (ephemeral) トラフィック | ||
プライベートサブネット |
| VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 |
4.3.10.4.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared
タグは、それが使用したサブネットから削除されます。
4.3.10.4.3. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
4.3.10.4.4. クラスター間の分離
OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。
- 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
- ICMP Ingress はネットワーク全体から許可されます。
- TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
4.3.10.4.5. オプション: AWS セキュリティーグループ
デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。
ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml
ファイルを変更してカスタムセキュリティーグループを適用します。
詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。
4.3.10.5. 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 を参照してください。
手順
AWS プロファイルを環境変数としてエクスポートします。
$ export AWS_PROFILE=<aws_profile> 1
- 1
beijingadmin
などの AWS 認証情報を保持する AWS プロファイル名。
カスタム AMI に関連付けるリージョンを環境変数としてエクスポートします。
$ export AWS_DEFAULT_REGION=<aws_region> 1
- 1
cn-north-1
などの AWS リージョン
環境変数として Amazon S3 にアップロードした RHCOS のバージョンをエクスポートします。
$ export RHCOS_VERSION=<version> 1
- 1
4.16.0
などの RHCOS VMDK バージョン。
Amazon S3 バケット名を環境変数としてエクスポートします。
$ export VMIMPORT_BUCKET_NAME=<s3_bucket_name>
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
RHCOS ディスクを Amazon EBS スナップショットとしてインポートします。
$ aws ec2 import-snapshot --region ${AWS_DEFAULT_REGION} \ --description "<description>" \ 1 --disk-container "file://<file_path>/containers.json" 2
イメージインポートのステータスを確認します。
$ 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
をコピーして、イメージを登録します。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
これらの API の詳細は、AWS ドキュメントの importing snapshots および creating EBS-backed AMIs を参照してください。
4.3.10.6. インストール設定ファイルの手動作成
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- カスタムの RHCOS AMI をアップロードしている。
- ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
$ mkdir <installation_directory>
重要ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
提供されるサンプルの
install-config.yaml
ファイルテンプレートをカスタマイズし、これを<installation_directory>
に保存します。注記この設定ファイルの名前を
install-config.yaml
と付ける必要があります。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。
関連情報
4.3.10.6.1. 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: OVNKubernetes 13 serviceNetwork: - 172.30.0.0/16 platform: aws: region: cn-north-1 14 propagateUserTags: true 15 userTags: adminContact: jdoe costCenter: 7536 subnets: 16 - subnet-1 - subnet-2 - subnet-3 amiID: ami-96c6f8f7 17 18 serviceEndpoints: 19 - name: ec2 url: https://vpce-id.ec2.cn-north-1.vpce.amazonaws.com.cn hostedZone: Z3URY6TWQ91KVV 20 fips: false 21 sshKey: ssh-ed25519 AAAA... 22 publish: Internal 23 pullSecret: '{"auths": ...}' 24
- 1 12 14 17 24
- 必須。
- 2
- オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は
kube-system
namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。 - 3 8 15
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 5 9
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
m4.2xlarge
またはm5.2xlarge
などの大規模なインスタンスタイプを使用します。 - 6 10
- 大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを
io1
として設定し、iops
を2000
に設定します。 - 7 11
- Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を
Required
に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値をOptional
に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。注記クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。
- 13
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 16
- 独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
- 18
- クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
- 19
- AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は
https
プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。 - 20
- 既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
- 21
- 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 暗号化ライブラリーを使用します。
- 22
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 23
- クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、
publish
をInternal
に設定します。これはインターネットからアクセスできません。デフォルト値はExternal
です。
4.3.10.6.2. クラスターインストールの最小リソース要件
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
マシン | オペレーティングシステム | 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 アーキテクチャー を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
関連情報
4.3.10.6.3. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.44 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
4.3.10.6.4. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例4.45 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
4.3.10.6.5. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.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
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。AmazonEC2
、Elastic 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 信頼バンドルからの認証局によって署名されない限り必要になります。 - 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.3.10.6.6. 既存の AWS セキュリティーグループをクラスターに適用する
既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
前提条件
- AWS でセキュリティーグループを作成している。詳細は、セキュリティーグループ の操作に関する AWS ドキュメントを参照してください。
- セキュリティーグループは、クラスターをデプロイする既存の VPC に関連付ける必要があります。セキュリティーグループを別の VPC に関連付けることはできません。
-
既存の
install-config.yaml
ファイルがある。
手順
-
install-config.yaml
ファイルで、compute.platform.aws.additionalSecurityGroupIDs
パラメーターを編集して、コンピュートマシンに 1 つ以上のカスタムセキュリティーグループを指定します。 -
controlPlane.platform.aws.additionalSecurityGroupIDs
パラメーターを編集して、コントロールプレーンマシンに 1 つ以上のカスタムセキュリティーグループを指定します。 - ファイルを保存し、クラスターをデプロイする際に参照します。
カスタムセキュリティーグループを指定するサンプル install-config.yaml
ファイル
# ... compute: - hyperthreading: Enabled name: worker platform: aws: additionalSecurityGroupIDs: - sg-1 1 - sg-2 replicas: 3 controlPlane: hyperthreading: Enabled name: master platform: aws: additionalSecurityGroupIDs: - sg-3 - sg-4 replicas: 3 platform: aws: region: us-east-1 subnets: 2 - subnet-1 - subnet-2 - subnet-3
4.3.10.7. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.3.10.7.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: AWSProviderSpec statementEntries: - effect: Allow action: - iam:GetUser - iam:GetUserPolicy - iam:ListAccessKeys resource: "*" ...
以前に生成した
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>
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
4.3.10.7.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.3.10.7.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.46 必要な AWS パーミッション
必要な
iam
権限-
iam:CreateOpenIDConnectProvider
-
iam:CreateRole
-
iam:DeleteOpenIDConnectProvider
-
iam:DeleteRole
-
iam:DeleteRolePolicy
-
iam:GetOpenIDConnectProvider
-
iam:GetRole
-
iam:GetUser
-
iam:ListOpenIDConnectProviders
-
iam:ListRolePolicies
-
iam:ListRoles
-
iam:PutRolePolicy
-
iam:TagOpenIDConnectProvider
-
iam:TagRole
必要な
s3
権限-
s3:CreateBucket
-
s3:DeleteBucket
-
s3:DeleteObject
-
s3:GetBucketAcl
-
s3:GetBucketTagging
-
s3:GetObject
-
s3:GetObjectAcl
-
s3:GetObjectTagging
-
s3:ListBucket
-
s3:PutBucketAcl
-
s3:PutBucketPolicy
-
s3:PutBucketPublicAccessBlock
-
s3:PutBucketTagging
-
s3:PutObject
-
s3:PutObjectAcl
-
s3:PutObjectTagging
必要な
cloudfront
権限-
cloudfront:ListCloudFrontOriginAccessIdentities
-
cloudfront:ListDistributions
-
cloudfront:ListTagsForResource
OIDC 設定を、パブリック CloudFront ディストリビューション URL 経由で IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに保存する予定の場合、
ccoctl
ユーティリティーを実行する AWS アカウントには次の追加パーミッションが必要です。例4.47 CloudFront を使用したプライベート S3 バケットに対する追加の権限
-
cloudfront:CreateCloudFrontOriginAccessIdentity
-
cloudfront:CreateDistribution
-
cloudfront:DeleteCloudFrontOriginAccessIdentity
-
cloudfront:DeleteDistribution
-
cloudfront:GetCloudFrontOriginAccessIdentity
-
cloudfront:GetCloudFrontOriginAccessIdentityConfig
-
cloudfront:GetDistribution
-
cloudfront:TagResource
-
cloudfront:UpdateDistribution
注記これらの追加のパーミッションは、
ccoctl aws create-all
コマンドで認証情報要求を処理する際の--create-private-s3-bucket
オプションの使用をサポートします。-
手順
次のコマンドを実行して、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.
4.3.10.7.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.3.10.7.2.2.1. 単一コマンドでの AWS リソースの作成
ccoctl
ツールが AWS リソースの作成に使用するプロセスが組織の要件を自動的に満たす場合は、ccoctl aws create-all
コマンドを使用して AWS リソースの作成を自動化できます。
それ以外の場合は、AWS リソースを個別に作成できます。詳細は、「AWS リソースの個別の作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-all \ --name=<name> \1 --region=<aws_region> \2 --credentials-requests-dir=<path_to_credentials_requests_directory> \3 --output-dir=<path_to_ccoctl_output_dir> \4 --create-private-s3-bucket 5
- 1
- 追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
- 2
- クラウドリソースが作成される AWS リージョンです。
- 3
- コンポーネント
CredentialsRequest
オブジェクトのファイルを含むディレクトリーを指定します。 - 4
- オプション:
ccoctl
ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。 - 5
- オプション: デフォルトでは、
ccoctl
ユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucket
パラメーターを使用します。
注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.10.7.2.2.2. AWS リソースの個別の作成
ccoctl
ツールを使用して、AWS リソースを個別に作成できます。このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。
それ以外の場合は、ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。詳細は、「単一コマンドによる AWS リソースの作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
一部の ccoctl
コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run
フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json
パラメーターを使用して適用できます。
前提条件
-
ccoctl
バイナリーを展開して準備しておく。
手順
次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。
$ ccoctl aws create-key-pair
出力例
2021/04/13 11:01:02 Generating RSA keypair 2021/04/13 11:01:03 Writing private key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.private 2021/04/13 11:01:03 Writing public key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.public 2021/04/13 11:01:03 Copying signing key for use by installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
$ ccoctl aws create-identity-provider \ --name=<name> \1 --region=<aws_region> \2 --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 3
出力例
2021/04/13 11:16:09 Bucket <name>-oidc created 2021/04/13 11:16:10 OpenID Connect discovery document in the S3 bucket <name>-oidc at .well-known/openid-configuration updated 2021/04/13 11:16:10 Reading public key 2021/04/13 11:16:10 JSON web key set (JWKS) in the S3 bucket <name>-oidc at keys.json updated 2021/04/13 11:16:18 Identity Provider created with ARN: arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
openid-configuration
は検出ドキュメントであり、keys.json
は JSON Web キーセットファイルです。このコマンドは、YAML 設定ファイルを
/<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yaml
にも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。クラスターの各コンポーネントについて IAM ロールを作成します。
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl aws create-iam-roles \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
注記GovCloud などの代替の IAM API エンドポイントを使用する AWS 環境では、
--region
パラメーターでリージョンを指定する必要もあります。クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。それぞれの
CredentialsRequest
オブジェクトについて、ccoctl
は指定された OIDC アイデンティティープロバイダーに関連付けられた信頼ポリシーと、OpenShift Container Platform リリースイメージの各CredentialsRequest
オブジェクトに定義されるパーミッションポリシーを使用して IAM ロールを作成します。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
cluster-authentication-02-config.yaml openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-aws-cloud-credentials-credentials.yaml
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。
4.3.10.7.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 # ...
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ 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 .
4.3.10.8. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.3.10.9. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
4.3.10.10. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。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
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.3.10.11. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
4.3.11. AWS Local Zones 上のコンピュートノードを使用してクラスターをインストールする
install-config.yaml
ファイルのエッジコンピュートプールにゾーン名を設定することで、OpenShift Container Platform クラスターを Amazon Web Services (AWS) Local Zones にすばやくインストールできます。または、Local Zone サブネットを持つ既存の Amazon Virtual Private Cloud (VPC) にクラスターをインストールすることもできます。
AWS Local Zones は、クラウドリソースを大都市圏の近くに配置するインフラストラクチャーです。詳細は、AWS Local Zones Documentation を参照してください。
4.3.11.1. インフラストラクチャーの前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択とユーザー用にクラスターを準備する方法 を理解している。
クラスターをホストするために 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) を参照してください。
- ファイアウォールを使用している場合は、クラスターがアクセスする必要がある サイトを許可するようにファイアウォールを設定 している。
- ネットワークリソースを作成するために、リージョンとサポートされている AWS ローカルゾーンの場所 を書き留めている。
- AWS ドキュメントの AWS Local Zones features を確認している。
AWS Local Zones をサポートするネットワークリソースを作成する権限を、アイデンティティーおよびアクセス管理 (IAM) ユーザーまたはロールに追加している。次の例では、AWS Local Zones をサポートするネットワークリソースを作成するためのユーザーまたはロールアクセスを提供できるゾーングループを有効にします。
IAM ユーザーまたはロールに割り当てられた
ec2:ModifyAvailabilityZoneGroup
権限を持つ追加の IAM ポリシーの例{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:ModifyAvailabilityZoneGroup" ], "Effect": "Allow", "Resource": "*" } ] }
4.3.11.2. AWS Local Zones とエッジコンピュートプールについて
AWS Local Zones 環境でのインフラストラクチャーの動作とクラスターの制限を理解するには、以降のセクションをお読みください。
4.3.11.2.1. AWS Local Zone でのクラスターの制限
デフォルトのインストール設定で Amazon Web Services (AWS) の Local Zone にクラスターをデプロイする場合、いくつかの制限があります。
次のリストは、事前設定された AWS ゾーンにクラスターをデプロイする場合の制限の詳細を示しています。
-
ゾーン内の Amazon EC2 インスタンスとリージョン内の Amazon EC2 インスタンス間の最大伝送単位 (MTU) は
1300
です。これにより、デプロイメントで使用されるネットワークプラグインに応じて、クラスター全体のネットワーク MTU が変わります。 - Network Load Balancer (NLB)、Classic Load Balancer、Network Address Translation (NAT) ゲートウェイなどのネットワークリソースは、グローバルにサポートされていません。
-
AWS 上の OpenShift Container Platform クラスターの場合、AWS Elastic Block Storage (EBS)
gp3
タイプのボリュームがノードボリュームのデフォルトであり、ストレージクラスのデフォルトです。このボリュームタイプは、ゾーンの場所ではグローバルに使用できません。デフォルトでは、ゾーン内で実行されるノードは、gp2
EBS ボリュームを使用してデプロイされます。ゾーンのノードにワークロードを作成する場合は、gp2-csi
StorageClass
パラメーターを設定する必要があります。
インストールプログラムで OpenShift Container Platform クラスターの Local Zone サブネットを自動的に作成する場合、この方法に伴う固有の設定制限が適用されます。
OpenShift Container Platform クラスターのサブネットを自動的に作成するようにインストールプログラムを設定する場合は、次の設定制限が適用されます。
- インストールプログラムは、AWS Local Zones にプライベートサブネットを作成するときに、各サブネットをその親ゾーンのルートテーブルに関連付けます。この操作により、各プライベートサブネットが AWS リージョンの NAT ゲートウェイ経由で Egress トラフィックをインターネットにルーティングできるようになります。
- クラスターのインストール時に親ゾーンのルートテーブルが存在しない場合、インストールプログラムは、プライベートサブネットを Amazon Virtual Private Cloud (VPC) 内の最初に使用可能なプライベートルートテーブルに関連付けます。このアプローチは、OpenShift Container Platform クラスター内の AWS Local Zones サブネットに対してのみ有効です。
4.3.11.2.2. エッジコンピュートプールについて
エッジコンピュートノードは、AWS Local Zones の場所で実行される taint されたコンピュートノードです。
Local Zones を使用するクラスターをデプロイする場合は、次の点を考慮してください。
- Local Zone の Amazon EC2 インスタンスは、アベイラビリティゾーンの Amazon EC2 インスタンスよりも高価です。
- AWS Local Zones で実行されているアプリケーションとエンドユーザーの間の遅延は低くなります。たとえば、ローカルゾーンとアベイラビリティゾーンの間で受信トラフィックが混在している場合は、一部のワークロードに遅延の影響が発生します。
通常、Local Zones 内の Amazon EC2 インスタンスとリージョン内の Amazon EC2 インスタンス間の最大伝送単位 (MTU) は 1300 です。クラスターネットワークの MTU は、オーバーヘッドを考慮して、常に EC2 の MTU よりも小さくする必要があります。具体的なオーバーヘッドは、ネットワークプラグインによって決まります。たとえば、OVN-Kubernetes のオーバーヘッドは 100 bytes
です。
ネットワークプラグインは、IPsec などの追加機能を提供できます。MTU のサイズには、このような追加機能も影響します。
詳細は、AWS ドキュメントの ローカルゾーンの仕組み を参照してください。
OpenShift Container Platform 4.12 で、リモートゾーンで使用するために設計された新しいコンピュートプールの エッジ が導入されました。エッジコンピュートプール設定は、AWS Local Zone の場所間で共通です。Local Zones リソース上の EC2 や EBS などのリソースのタイプとサイズの制限により、デフォルトのインスタンスタイプが従来のコンピュートプールと異なる場合があります。
Local Zones の場所のデフォルト Elastic Block Store (EBS) は gp2
であり、非エッジコンピュートプールとは異なります。各 Local Zones に使用される、エッジコンピュートプールのインスタンスタイプも、ゾーンのインスタンスオファリングに応じて、他のコンピュートプールと異なる場合があります。
エッジコンピュートプールは、開発者が AWS Local Zones ノードにアプリケーションをデプロイするために使用できる新しいラベルを作成します。新しいラベルは次のとおりです。
-
node-role.kubernetes.io/edge=''
-
machine.openshift.io/zone-type=local-zone
-
machine.openshift.io/zone-group=$ZONE_GROUP_NAME
デフォルトでは、エッジコンピュートプールのマシンセットは NoSchedule
taint を定義して、Local Zones インスタンスに他のワークロードが拡散するのを防ぎます。ユーザーは、Pod 仕様で toleration を定義している場合にのみユーザーワークロードを実行できます。
4.3.11.3. インストールの要件
AWS Local Zones 環境にクラスターをインストールする前に、Local Zone 機能を導入できるようにインフラストラクチャーを設定する必要があります。
4.3.11.3.1. AWS Local Zones へのオプトイン
AWS Local Zones にサブネットを作成する予定がある場合は、各ゾーングループに個別にオプトインする必要があります。
前提条件
- AWS CLI をインストールしている。
- OpenShift Container Platform クラスターをデプロイする AWS リージョンを決定しました。
- ゾーングループにオプトインするユーザーまたはロールアカウントに、寛容な IAM ポリシーをアタッチしました。
手順
次のコマンドを実行して、AWS リージョンで利用可能なゾーンをリスト表示します。
AWS リージョンで利用可能な AWS Local Zones をリスト表示するコマンドの例
$ aws --region "<value_of_AWS_Region>" ec2 describe-availability-zones \ --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \ --filters Name=zone-type,Values=local-zone \ --all-availability-zones
AWS リージョンによっては、利用可能なゾーンのリストが長くなる場合があります。このコマンドは次のフィールドを返します。
ZoneName
- Local Zones の名前。
GroupName
- ゾーンで構成されるグループ。リージョンにオプトインするには、この名前を保存しておきます。
Status
-
Local Zones グループのステータス。ステータスが
not-opted-in
の場合は、次の手順で説明するようにGroupName
をオプトインする必要があります。
次のコマンドを実行して、AWS アカウントのゾーングループにオプトインします。
$ aws ec2 modify-availability-zone-group \ --group-name "<value_of_GroupName>" \1 --opt-in-status opted-in
- 1
<value_of_GroupName>
は、サブネットを作成する Local Zones のグループの名前に置き換えます。たとえば、ゾーンus-east-1-nyc-1a
(米国東部 (ニューヨーク)) を使用するにはus-east-1-nyc-1
と指定します。
4.3.11.3.2. AWS Marketplace イメージの取得
AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがコンピュートノードのデプロイに使用する AMI ID が提供されます。
前提条件
- オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。
手順
- AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
ご使用の AWS リージョンの 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": ...}'
4.3.11.4. インストールの準備
ノードを Local Zone に拡張する前に、クラスターのインストール環境用に特定のリソースを準備する必要があります。
4.3.11.4.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 アーキテクチャー を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
4.3.11.4.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは、AWS Local Zones で使用するために OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.48 AWS Local Zones の 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c5.*
-
c5d.*
-
m6i.*
-
m5.*
-
r5.*
-
t3.*
関連情報
- AWS ドキュメントの AWS Local Zones features を参照してください。
4.3.11.4.3. インストール設定ファイルの作成
インストールプログラムがクラスターをデプロイするために必要なインストール設定ファイルを生成し、カスタマイズします。
前提条件
- user-provisioned infrastructure 用の OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
-
Red Hat が公開している付属の Red Hat Enterprise Linux CoreOS (RHCOS) AMI のある AWS リージョンにクラスターをデプロイしようとしている。カスタム AMI が必要な AWS リージョン (AWS GovCloud リージョンなど) にデプロイする場合は、
install-config.yaml
ファイルを手動で作成する必要があります。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして aws を選択します。
AWS プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
注記AWS アクセスキー ID およびシークレットアクセスキーは、インストールホストの現行ユーザーのホームディレクトリーの
~/.aws/credentials
に保存されます。エクスポートされたプロファイルの認証情報がファイルにない場合は、インストールプログラムにより認証情報の入力が求めるプロンプトが出されます。インストールプログラムに指定する認証情報は、ファイルに保存されます。- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
オプション:
install-config.yaml
ファイルをバックアップします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
4.3.11.4.4. エッジコンピュートプールを含むインストール設定ファイルの例
次の例は、エッジマシンプール設定を含む install-config.yaml
ファイルを示しています。
カスタムインスタンスタイプのエッジプールを使用する設定
apiVersion: v1 baseDomain: devcluster.openshift.com metadata: name: ipi-edgezone compute: - name: edge platform: aws: type: r5.2xlarge platform: aws: region: us-west-2 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA...
インスタンスのタイプは場所によって異なります。クラスターを実行する Local Zones で利用可能かどうかを確認するには、AWS のドキュメントを参照してください。
カスタム Amazon Elastic Block Store (EBS) タイプのエッジプールを使用する設定
apiVersion: v1 baseDomain: devcluster.openshift.com metadata: name: ipi-edgezone compute: - name: edge platform: aws: zones: - us-west-2-lax-1a - us-west-2-lax-1b - us-west-2-phx-2a rootVolume: type: gp3 size: 120 platform: aws: region: us-west-2 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA...
Elastic Block Storage (EBS) タイプは場所によって異なります。クラスターを実行する Local Zones で利用可能かどうかを確認するには、AWS のドキュメントを参照してください。
カスタムセキュリティーグループを持つエッジプールを使用する設定
apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
name: ipi-edgezone
compute:
- name: edge
platform:
aws:
additionalSecurityGroupIDs:
- sg-1 1
- sg-2
platform:
aws:
region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...
- 1
- Amazon EC2 コンソールに表示されるセキュリティーグループの名前を指定します。必ず
sg
接頭辞を含めてください。
4.3.11.4.5. クラスターネットワークの MTU のカスタマイズ
AWS にクラスターをデプロイする前に、インフラストラクチャーのニーズに合わせて、クラスターネットワークの最大伝送単位 (MTU) をカスタマイズできます。
デフォルトでは、サポートされている Local Zones 機能を使用してクラスターをインストールすると、クラスターネットワークの MTU 値が、ネットワークプラグインによって許可される最低値に自動的に調整されます。
サポートされていない MTU 値を Local Zones インフラストラクチャーで動作する EC2 インスタンスに設定すると、OpenShift Container Platform クラスターに問題が発生する可能性があります。
Local Zone と AWS リージョンの EC2 インスタンス間の MTU 値を引き上げることが可能な場合は、より高い値を手動で設定して、クラスターネットワークのネットワークパフォーマンスを向上できます。
install-config.yaml
設定ファイルで networking.clusterNetworkMTU
パラメーターを指定することにより、クラスターの MTU をカスタマイズできます。
Local Zones 内のすべてのサブネットは、そのゾーン内の各ノードが AWS リージョン内のサービスと正常に通信してワークロードをデプロイできるように、より高い MTU 値をサポートしている必要があります。
デフォルトの MTU 値を上書きする例
apiVersion: v1 baseDomain: devcluster.openshift.com metadata: name: edge-zone networking: clusterNetworkMTU: 8901 compute: - name: edge platform: aws: zones: - us-west-2-lax-1a - us-west-2-lax-1b platform: aws: region: us-west-2 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA...
関連情報
- サポートされている最大伝送単位 (MTU) 値の詳細は、AWS ドキュメントの AWS resources supported in Local Zones を参照してください。
4.3.11.5. AWS Local Zones 環境のクラスターインストールオプション
以下のいずれかのインストール方法を選択して、Local Zones に定義されたエッジコンピュートノードを使用して OpenShift Container Platform クラスターを AWS にインストールします。
- 完全に自動化された方法: クラスターをインストールして、コンピュートノードをエッジコンピュートプールに迅速に拡張します。インストールプログラムが、OpenShift Container Platform クラスター用のインフラストラクチャーリソースを自動的に作成します。
-
既存の VPC を使用する方法: AWS 上のクラスターを既存の VPC にインストールします。この場合、Local Zones サブネットを
install-config.yaml
ファイルに指定します。
次のステップ
次のいずれかの方法を選択して、OpenShift Container Platform クラスターを AWS Local Zones 環境にインストールします。
4.3.11.6. AWS Local Zones にクラスターを迅速にインストールする
OpenShift Container Platform 4.16 では、Amazon Web Services (AWS) にクラスターをすばやくインストールして、コンピュートノードを Local Zones の場所に拡張できます。このインストール方法を使用すると、設定ファイルで定義した各ゾーンのネットワークリソースと Local Zones サブネットが、インストールプログラムによって自動的に作成されます。インストールをカスタマイズするには、クラスターをデプロイする前に、install-config.yaml
ファイル内のパラメーターを変更する必要があります。
4.3.11.6.1. AWS Local Zones を使用するためのインストール設定ファイルの変更
install-config.yaml
ファイルを変更して、AWS Local Zones を含めます。
前提条件
- AWS アカウントが設定されている。
-
aws configure
を実行して、AWS キーと AWS リージョンをローカル AWS プロファイルに追加している。 - OpenShift Container Platform クラスターのサブネットを自動的に作成するようにインストールプログラムを指定する際に適用される設定上の制限を理解している。
- 各ゾーンの Local Zones グループにオプトインしている。
-
「インストール設定ファイルの作成」手順を使用して、
install-config.yaml
ファイルを作成している。
手順
install-config.yaml
ファイルを変更して、エッジコンピュートプールのplatform.aws.zones
プロパティーで Local Zones 名を指定します。# ... platform: aws: region: <region_name> 1 compute: - name: edge platform: aws: zones: 2 - <local_zone_name> #...
エッジノードを
Los Angeles
とLas Vegas
の Local Zones に拡張するus-west-2
AWS リージョンにクラスターをインストールする設定の例apiVersion: v1 baseDomain: example.com metadata: name: cluster-name platform: aws: region: us-west-2 compute: - name: edge platform: aws: zones: - us-west-2-lax-1a - us-west-2-lax-1b - us-west-2-las-1a pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' #...
- クラスターをデプロイします。
次のステップ
4.3.11.7. Local Zone のサブネットを持つ既存の VPC へのクラスターのインストール
クラスターを Amazon Web Services (AWS) 上の既存の Amazon Virtual Private Cloud (VPC) にインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
AWS 上のクラスターを既存の VPC にインストールするには、AWS Local Zones を使用してコンピュートノードをクラウドインフラストラクチャーのエッジまで拡張する必要があります。
Local Zone のサブネットは、通常のコンピュートノードをエッジネットワークに拡張します。各エッジコンピュートノードは、ユーザーワークロードを実行します。Amazon Web Services (AWS) の Local Zone 環境を作成し、クラスターをデプロイした後、エッジコンピュートノードを使用して Local Zone のサブネットにユーザーワークロードを作成できます。
プライベートサブネットを作成する場合は、提供されている CloudFormation テンプレートを変更するか、独自のテンプレートを作成する必要があります。
このドキュメントの CloudFormation テンプレートを使用して、ネットワークリソースを作成できます。さらに、テンプレートを変更してインフラストラクチャーをカスタマイズしたり、テンプレートに含まれる情報を使用して会社のポリシーに基づいて AWS リソースを作成したりできます。
installer-provisioned infrastructure のインストールを実行する手順は、例としてのみ提供されています。既存の VPC にクラスターをインストールするには、クラウドプロバイダーと OpenShift Container Platform のインストールプロセスに関する知識が必要です。CloudFormation テンプレートを使用すると、これらの手順の完了を支援したり、独自のクラスターのインストールをモデル化したりできます。CloudFormation テンプレートを使用してリソースを作成する代わりに、これらのリソースを生成するために他の方法を使用することを決定できます。
4.3.11.7.1. AWS での VPC の作成
OpenShift Container Platform クラスター用の Amazon Web Services (AWS) で、Virtual Private Cloud (VPC) を作成し、Local Zones のすべての場所にサブネットを作成すると、コンピュートノードをエッジロケーションに拡張できます。VPC は、VPN やルートテーブルなどの要件に合わせてさらにカスタマイズできます。初期デプロイメントに含まれていない新しい Local Zones サブネットを追加することもできます。
提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、VPC を表す AWS リソースのスタックを作成できます。
このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- AWS アカウントを設定している。
-
aws configure
を実行して、AWS キーと AWS リージョンをローカル AWS プロファイルに追加している。 - AWS アカウントで AWS Local Zones にオプトインしている。
手順
CloudFormation テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。
[ { "ParameterKey": "VpcCidr", 1 "ParameterValue": "10.0.0.0/16" 2 }, { "ParameterKey": "AvailabilityZoneCount", 3 "ParameterValue": "3" 4 }, { "ParameterKey": "SubnetBits", 5 "ParameterValue": "12" 6 } ]
- このドキュメントの「VPC の CloudFormation テンプレート」セクションに移動し、記載されているテンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC について記述しています。
次のコマンドを実行して、CloudFormation テンプレートを起動し、VPC を表す AWS リソースのスタックを作成します。
重要単一行にコマンドを入力してください。
$ aws cloudformation create-stack --stack-name <name> \1 --template-body file://<template>.yaml \2 --parameters file://<parameters>.json 3
出力例
arn:aws:cloudformation:us-east-1:123456789012:stack/cluster-vpc/dbedae40-2fd3-11eb-820e-12a48460849f
次のコマンドを実行して、テンプレートコンポーネントが存在することを確認します。
$ aws cloudformation describe-stacks --stack-name <name>
StackStatus
がCREATE_COMPLETE
を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。VpcId
VPC の ID。
PublicSubnetIds
新規パブリックサブネットの ID。
PrivateSubnetIds
新規プライベートサブネットの ID。
PublicRouteTableId
新しいパブリックルートテーブル ID の ID。
4.3.11.7.2. VPC の CloudFormation テンプレート
以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。
例4.49 VPC の CloudFormation テンプレート
AWSTemplateFormatVersion: 2010-09-09 Description: Template for Best Practice VPC with 1-3 AZs Parameters: VpcCidr: AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$ ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24. Default: 10.0.0.0/16 Description: CIDR block for VPC. Type: String AvailabilityZoneCount: ConstraintDescription: "The number of availability zones. (Min: 1, Max: 3)" MinValue: 1 MaxValue: 3 Default: 1 Description: "How many AZs to create VPC subnets for. (Min: 1, Max: 3)" Type: Number SubnetBits: ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/19-27. MinValue: 5 MaxValue: 13 Default: 12 Description: "Size of each subnet to create within the availability zones. (Min: 5 = /27, Max: 13 = /19)" Type: Number Metadata: AWS::CloudFormation::Interface: ParameterGroups: - Label: default: "Network Configuration" Parameters: - VpcCidr - SubnetBits - Label: default: "Availability Zones" Parameters: - AvailabilityZoneCount ParameterLabels: AvailabilityZoneCount: default: "Availability Zone Count" VpcCidr: default: "VPC CIDR" SubnetBits: default: "Bits Per Subnet" Conditions: DoAz3: !Equals [3, !Ref AvailabilityZoneCount] DoAz2: !Or [!Equals [2, !Ref AvailabilityZoneCount], Condition: DoAz3] Resources: VPC: Type: "AWS::EC2::VPC" Properties: EnableDnsSupport: "true" EnableDnsHostnames: "true" CidrBlock: !Ref VpcCidr PublicSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VPC CidrBlock: !Select [0, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref "AWS::Region" PublicSubnet2: Type: "AWS::EC2::Subnet" Condition: DoAz2 Properties: VpcId: !Ref VPC CidrBlock: !Select [1, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 1 - Fn::GetAZs: !Ref "AWS::Region" PublicSubnet3: Type: "AWS::EC2::Subnet" Condition: DoAz3 Properties: VpcId: !Ref VPC CidrBlock: !Select [2, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 2 - Fn::GetAZs: !Ref "AWS::Region" InternetGateway: Type: "AWS::EC2::InternetGateway" GatewayToInternet: Type: "AWS::EC2::VPCGatewayAttachment" Properties: VpcId: !Ref VPC InternetGatewayId: !Ref InternetGateway PublicRouteTable: Type: "AWS::EC2::RouteTable" Properties: VpcId: !Ref VPC PublicRoute: Type: "AWS::EC2::Route" DependsOn: GatewayToInternet Properties: RouteTableId: !Ref PublicRouteTable DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway PublicSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PublicSubnet RouteTableId: !Ref PublicRouteTable PublicSubnetRouteTableAssociation2: Type: "AWS::EC2::SubnetRouteTableAssociation" Condition: DoAz2 Properties: SubnetId: !Ref PublicSubnet2 RouteTableId: !Ref PublicRouteTable PublicSubnetRouteTableAssociation3: Condition: DoAz3 Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PublicSubnet3 RouteTableId: !Ref PublicRouteTable PrivateSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VPC CidrBlock: !Select [3, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref "AWS::Region" PrivateRouteTable: Type: "AWS::EC2::RouteTable" Properties: VpcId: !Ref VPC PrivateSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PrivateSubnet RouteTableId: !Ref PrivateRouteTable NAT: DependsOn: - GatewayToInternet Type: "AWS::EC2::NatGateway" Properties: AllocationId: "Fn::GetAtt": - EIP - AllocationId SubnetId: !Ref PublicSubnet EIP: Type: "AWS::EC2::EIP" Properties: Domain: vpc Route: Type: "AWS::EC2::Route" Properties: RouteTableId: Ref: PrivateRouteTable DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: Ref: NAT PrivateSubnet2: Type: "AWS::EC2::Subnet" Condition: DoAz2 Properties: VpcId: !Ref VPC CidrBlock: !Select [4, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 1 - Fn::GetAZs: !Ref "AWS::Region" PrivateRouteTable2: Type: "AWS::EC2::RouteTable" Condition: DoAz2 Properties: VpcId: !Ref VPC PrivateSubnetRouteTableAssociation2: Type: "AWS::EC2::SubnetRouteTableAssociation" Condition: DoAz2 Properties: SubnetId: !Ref PrivateSubnet2 RouteTableId: !Ref PrivateRouteTable2 NAT2: DependsOn: - GatewayToInternet Type: "AWS::EC2::NatGateway" Condition: DoAz2 Properties: AllocationId: "Fn::GetAtt": - EIP2 - AllocationId SubnetId: !Ref PublicSubnet2 EIP2: Type: "AWS::EC2::EIP" Condition: DoAz2 Properties: Domain: vpc Route2: Type: "AWS::EC2::Route" Condition: DoAz2 Properties: RouteTableId: Ref: PrivateRouteTable2 DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: Ref: NAT2 PrivateSubnet3: Type: "AWS::EC2::Subnet" Condition: DoAz3 Properties: VpcId: !Ref VPC CidrBlock: !Select [5, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 2 - Fn::GetAZs: !Ref "AWS::Region" PrivateRouteTable3: Type: "AWS::EC2::RouteTable" Condition: DoAz3 Properties: VpcId: !Ref VPC PrivateSubnetRouteTableAssociation3: Type: "AWS::EC2::SubnetRouteTableAssociation" Condition: DoAz3 Properties: SubnetId: !Ref PrivateSubnet3 RouteTableId: !Ref PrivateRouteTable3 NAT3: DependsOn: - GatewayToInternet Type: "AWS::EC2::NatGateway" Condition: DoAz3 Properties: AllocationId: "Fn::GetAtt": - EIP3 - AllocationId SubnetId: !Ref PublicSubnet3 EIP3: Type: "AWS::EC2::EIP" Condition: DoAz3 Properties: Domain: vpc Route3: Type: "AWS::EC2::Route" Condition: DoAz3 Properties: RouteTableId: Ref: PrivateRouteTable3 DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: Ref: NAT3 S3Endpoint: Type: AWS::EC2::VPCEndpoint Properties: PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: '*' Action: - '*' Resource: - '*' RouteTableIds: - !Ref PublicRouteTable - !Ref PrivateRouteTable - !If [DoAz2, !Ref PrivateRouteTable2, !Ref "AWS::NoValue"] - !If [DoAz3, !Ref PrivateRouteTable3, !Ref "AWS::NoValue"] ServiceName: !Join - '' - - com.amazonaws. - !Ref 'AWS::Region' - .s3 VpcId: !Ref VPC Outputs: VpcId: Description: ID of the new VPC. Value: !Ref VPC PublicSubnetIds: Description: Subnet IDs of the public subnets. Value: !Join [ ",", [!Ref PublicSubnet, !If [DoAz2, !Ref PublicSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PublicSubnet3, !Ref "AWS::NoValue"]] ] PrivateSubnetIds: Description: Subnet IDs of the private subnets. Value: !Join [ ",", [!Ref PrivateSubnet, !If [DoAz2, !Ref PrivateSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PrivateSubnet3, !Ref "AWS::NoValue"]] ] PublicRouteTableId: Description: Public Route table ID Value: !Ref PublicRouteTable PrivateRouteTableIds: Description: Private Route table IDs Value: !Join [ ",", [ !Join ["=", [ !Select [0, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable ]], !If [DoAz2, !Join ["=", [!Select [1, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable2]], !Ref "AWS::NoValue" ], !If [DoAz3, !Join ["=", [!Select [2, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable3]], !Ref "AWS::NoValue" ] ] ]
4.3.11.7.3. Local Zones のサブネットの作成
OpenShift Container Platform クラスターのエッジコンピュートノードのマシンセットを設定する前に、Local Zones にサブネットを作成する必要があります。コンピュートノードをデプロイする Local Zone ごとに次の手順を実行してください。
このドキュメントの CloudFormation テンプレートを使用して、CloudFormation スタックを作成できます。その後、このスタックを使用してサブネットをカスタムプロビジョニングできます。
このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- AWS アカウントを設定している。
-
aws configure
を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。 - Local Zones グループにオプトインしている。
手順
- このドキュメントの「VPC サブネット用の CloudFormation テンプレート」セクションに移動し、テンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC について記述しています。
次のコマンドを実行して CloudFormation テンプレートをデプロイします。これにより、VPC を表す AWS リソースのスタックが作成されます。
$ aws cloudformation create-stack --stack-name <stack_name> \1 --region ${CLUSTER_REGION} \ --template-body file://<template>.yaml \2 --parameters \ ParameterKey=VpcId,ParameterValue="${VPC_ID}" \3 ParameterKey=ClusterName,ParameterValue="${CLUSTER_NAME}" \4 ParameterKey=ZoneName,ParameterValue="${ZONE_NAME}" \5 ParameterKey=PublicRouteTableId,ParameterValue="${ROUTE_TABLE_PUB}" \6 ParameterKey=PublicSubnetCidr,ParameterValue="${SUBNET_CIDR_PUB}" \7 ParameterKey=PrivateRouteTableId,ParameterValue="${ROUTE_TABLE_PVT}" \8 ParameterKey=PrivateSubnetCidr,ParameterValue="${SUBNET_CIDR_PVT}" 9
- 1
<stack_name>
は、CloudFormation スタックの名前です (cluster-wl-<local_zone_shortname>
など)。クラスターを削除する場合に、このスタックの名前が必要になります。- 2
<template>
は、保存した CloudFormation テンプレート YAML ファイルの相対パスと名前です。- 3
${VPC_ID}
は VPC ID であり、VPC 用の CloudFormation テンプレートの出力に含まれる値VpcID
です。- 4
${ZONE_NAME}
は、サブネットを作成する Local Zones 名の値です。- 5
${CLUSTER_NAME}
は、新しい AWS リソース名の接頭辞として使用する ClusterName の値です。- 6
${SUBNET_CIDR_PUB}
は、パブリックサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロックVpcCidr
の一部である必要があります。- 7
${ROUTE_TABLE_PVT}
は、VPC の CloudFormation スタックの出力から抽出した PrivateRouteTableId です。- 8
${SUBNET_CIDR_PVT}
は、プライベートサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロックVpcCidr
の一部である必要があります。
出力例
arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-820e-11eb-2fd3-12a48460849f
検証
次のコマンドを実行して、テンプレートコンポーネントが存在することを確認します。
$ aws cloudformation describe-stacks --stack-name <stack_name>
StackStatus
がCREATE_COMPLETE
を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。PublicSubnetId
CloudFormation スタックによって作成されたパブリックサブネットの ID。
PrivateSubnetId
CloudFormation スタックによって作成されたプライベートサブネットの ID。
4.3.11.7.4. VPC サブネット用の CloudFormation テンプレート
次の CloudFormation テンプレートを使用して、Local Zones インフラストラクチャー上のゾーンにプライベートサブネットとパブリックサブネットをデプロイできます。
例4.50 VPC サブネット用の CloudFormation テンプレート
AWSTemplateFormatVersion: 2010-09-09 Description: Template for Best Practice Subnets (Public and Private) Parameters: VpcId: Description: VPC ID that comprises all the target subnets. Type: String AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$ ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*. ClusterName: Description: Cluster name or prefix name to prepend the Name tag for each subnet. Type: String AllowedPattern: ".+" ConstraintDescription: ClusterName parameter must be specified. ZoneName: Description: Zone Name to create the subnets, such as us-west-2-lax-1a. Type: String AllowedPattern: ".+" ConstraintDescription: ZoneName parameter must be specified. PublicRouteTableId: Description: Public Route Table ID to associate the public subnet. Type: String AllowedPattern: ".+" ConstraintDescription: PublicRouteTableId parameter must be specified. PublicSubnetCidr: AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$ ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24. Default: 10.0.128.0/20 Description: CIDR block for public subnet. Type: String PrivateRouteTableId: Description: Private Route Table ID to associate the private subnet. Type: String AllowedPattern: ".+" ConstraintDescription: PrivateRouteTableId parameter must be specified. PrivateSubnetCidr: AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$ ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24. Default: 10.0.128.0/20 Description: CIDR block for private subnet. Type: String Resources: PublicSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VpcId CidrBlock: !Ref PublicSubnetCidr AvailabilityZone: !Ref ZoneName Tags: - Key: Name Value: !Join ['-', [!Ref ClusterName, "public", !Ref ZoneName]] PublicSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PublicSubnet RouteTableId: !Ref PublicRouteTableId PrivateSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VpcId CidrBlock: !Ref PrivateSubnetCidr AvailabilityZone: !Ref ZoneName Tags: - Key: Name Value: !Join ['-', [!Ref ClusterName, "private", !Ref ZoneName]] PrivateSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PrivateSubnet RouteTableId: !Ref PrivateRouteTableId Outputs: PublicSubnetId: Description: Subnet ID of the public subnets. Value: !Join ["", [!Ref PublicSubnet]] PrivateSubnetId: Description: Subnet ID of the private subnets. Value: !Join ["", [!Ref PrivateSubnet]]
関連情報
- AWS CloudFormation コンソール に移動し、作成する CloudFormation スタックの詳細を表示できます。
4.3.11.7.5. AWS Local Zones サブネットを使用するためのインストール設定ファイルの変更
install-config.yaml
ファイルを変更して、Local Zones のサブネットを含めます。
前提条件
- 「Local Zone のサブネットの作成」手順を使用して、サブネットを作成している。
-
「インストール設定ファイルの作成」手順を使用して、
install-config.yaml
ファイルを作成している。
手順
install-config.yaml
設定ファイルを変更して、platform.aws.subnets
パラメーターで Local Zones のサブネットを指定します。Local Zones のサブネットを含むインストール設定ファイルの例
# ... platform: aws: region: us-west-2 subnets: 1 - publicSubnetId-1 - publicSubnetId-2 - publicSubnetId-3 - privateSubnetId-1 - privateSubnetId-2 - privateSubnetId-3 - publicSubnetId-LocalZone-1 # ...
- 1
- ゾーン (アベイラビリティーゾーンと Local Zones) 内に作成したサブネット ID のリスト。
関連情報
- 作成した CloudFormation スタックを表示する方法の詳細は、AWS CloudFormation コンソール を参照してください。
- AWS プロファイルと認証情報を設定する方法の詳細は、AWS ドキュメントの Configuration and credential file settings を参照してください。
次のステップ
4.3.11.8. オプション: AWS セキュリティーグループ
デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。
ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml
ファイルを変更してカスタムセキュリティーグループを適用します。
詳細は、「エッジコンピュートプールと AWS Local Zones」を参照してください。
4.3.11.9. オプション: パブリック IP アドレスをエッジコンピュートノードに割り当てます。
ワークロードによっては、Local Zones インフラストラクチャー上のパブリックサブネットにエッジコンピュートノードをデプロイすることが必要になります。その場合は、クラスターのインストール時にマシンセットマニフェストを設定できます。
AWS Local Zones インフラストラクチャーは、指定されたゾーン内のネットワークトラフィックにアクセスします。そのため、そのゾーンに近いエンドユーザーにサービスを提供する際に、アプリケーションで低遅延を利用できます。
デフォルト設定は、プライベートサブネットにコンピュートノードをデプロイする設定であり、お客様のニーズに合わない可能性があります。そのため、インフラストラクチャーにさらにカスタマイズを適用する必要がある場合は、パブリックサブネットにエッジコンピュートノードを作成することを検討してください。
デフォルトでは、OpenShift Container Platform はプライベートサブネットにコンピュートノードをデプロイします。最高のパフォーマンスを得るには、パブリック IP アドレスがサブネットに接続されているサブネットにコンピュートノードを配置することを検討してください。
追加のセキュリティーグループを作成する必要があります。ただし、インターネット経由でグループのルールを開くのは、本当に必要な場合だけに留めてください。
手順
インストールプログラムが含まれるディレクトリーに移動し、マニフェストファイルを生成します。インストールマニフェストが
openshift
およびmanifests
ディレクトリーレベルに作成されていることを確認します。$ ./openshift-install create manifests --dir <installation_directory>
インストールプログラムが Local Zones 用に生成するマシンセットマニフェストを編集して、マニフェストがパブリックサブネットにデプロイされるようにします。
spec.template.spec.providerSpec.value.publicIP
パラメーターにtrue
を指定します。クラスターを Local Zones に迅速にインストールするためのマシンセットマニフェスト設定の例
spec: template: spec: providerSpec: value: publicIp: true subnet: filters: - name: tag:Name values: - ${INFRA_ID}-public-${ZONE_NAME}
Local Zones サブネットを持つ既存の VPC にクラスターをインストールするためのマシンセットマニフェスト設定の例
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: name: <infrastructure_id>-edge-<zone> namespace: openshift-machine-api spec: template: spec: providerSpec: value: publicIp: true
4.3.11.10. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.3.11.11. デプロイしたクラスターのステータスの確認
OpenShift Container Platform が AWS Local Zones に正常にデプロイされたことを確認します。
4.3.11.11.1. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
4.3.11.11.2. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。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
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
4.3.11.11.3. エッジコンピューティングプールで作成されたノードの検証
AWS Local Zones インフラストラクチャーを使用するクラスターをインストールしたら、インストール時に作成したマシンセットマニフェストによって作成されたマシンのステータスを確認します。
install-config.yaml
ファイルに追加したサブネットから作成されたマシンセットを確認するには、次のコマンドを実行します。$ oc get machineset -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE cluster-7xw5g-edge-us-east-1-nyc-1a 1 1 1 1 3h4m cluster-7xw5g-worker-us-east-1a 1 1 1 1 3h4m cluster-7xw5g-worker-us-east-1b 1 1 1 1 3h4m cluster-7xw5g-worker-us-east-1c 1 1 1 1 3h4m
マシンセットから作成されたマシンを確認するには、次のコマンドを実行します。
$ oc get machines -n openshift-machine-api
出力例
NAME PHASE TYPE REGION ZONE AGE cluster-7xw5g-edge-us-east-1-nyc-1a-wbclh Running c5d.2xlarge us-east-1 us-east-1-nyc-1a 3h cluster-7xw5g-master-0 Running m6i.xlarge us-east-1 us-east-1a 3h4m cluster-7xw5g-master-1 Running m6i.xlarge us-east-1 us-east-1b 3h4m cluster-7xw5g-master-2 Running m6i.xlarge us-east-1 us-east-1c 3h4m cluster-7xw5g-worker-us-east-1a-rtp45 Running m6i.xlarge us-east-1 us-east-1a 3h cluster-7xw5g-worker-us-east-1b-glm7c Running m6i.xlarge us-east-1 us-east-1b 3h cluster-7xw5g-worker-us-east-1c-qfvz4 Running m6i.xlarge us-east-1 us-east-1c 3h
エッジロールを持つノードを確認するには、次のコマンドを実行します。
$ oc get nodes -l node-role.kubernetes.io/edge
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-207-188.ec2.internal Ready edge,worker 172m v1.25.2+d2e245f
次のステップ
- インストールを検証 します。
- 必要に応じて、リモートヘルスをオプトアウト できます。
4.3.12. AWS Wavelength Zones 上のコンピュートノードを使用してクラスターをインストールする
install-config.yaml
ファイルのエッジコンピュートプールにゾーン名を設定することで、OpenShift Container Platform クラスターを Amazon Web Services (AWS) Wavelength Zones にすばやくインストールできます。または、Wavelength Zone サブネットを持つ既存の Amazon Virtual Private Cloud (VPC) にクラスターをインストールすることもできます。
AWS Wavelength Zones は、AWS がモバイルエッジコンピューティング (MEC) アプリケーション用に構成したインフラストラクチャーです。
Wavelength Zone は、通信サービスプロバイダー (CSP) の 5G ネットワーク内に AWS のコンピュートサービスとストレージサービスを組み込みます。アプリケーションサーバーを Wavelength Zone に配置することで、5G デバイスからのアプリケーショントラフィックを 5G ネットワーク内に留めることができます。デバイスのアプリケーショントラフィックがターゲットサーバーに直接到達するため、遅延が問題になりません。
関連情報
- AWS ドキュメントの Wavelength Zones を参照してください。
4.3.12.1. インフラストラクチャーの前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択とユーザー用にクラスターを準備する方法 を理解している。
クラスターをホストするために 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) を参照してください。
- ファイアウォールを使用している場合は、クラスターがアクセスする必要がある サイトを許可するようにファイアウォールを設定 している。
- ネットワークリソースを作成するために、リージョンとサポートされている AWS Wavelength Zone の場所 を書き留めている。
- AWS ドキュメントの AWS Wavelength features を確認している。
- AWS ドキュメントの Quotas and considerations for Wavelength Zones を確認している。
AWS Wavelength Zones をサポートするネットワークリソースを作成する権限を、アイデンティティーおよびアクセス管理 (IAM) ユーザーまたはロールに追加している。以下に例を示します。
ユーザーまたはロールに
ec2:ModifyAvailabilityZoneGroup
、ec2:CreateCarrierGateway
、およびec2:DeleteCarrierGateway
権限を割り当てた追加の IAM ポリシーの例{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DeleteCarrierGateway", "ec2:CreateCarrierGateway" ], "Resource": "*" }, { "Action": [ "ec2:ModifyAvailabilityZoneGroup" ], "Effect": "Allow", "Resource": "*" } ] }
4.3.12.2. AWS Wavelength Zones とエッジコンピュートプールについて
AWS Wavelength Zones 環境でのインフラストラクチャーの動作とクラスターの制限を理解するには、以降のセクションをお読みください。
4.3.12.2.1. AWS Wavelength Zones のクラスターの制限
デフォルトのインストール設定で Amazon Web Services (AWS) の Local Zone にクラスターをデプロイする場合、いくつかの制限があります。
次のリストは、事前設定された AWS ゾーンにクラスターをデプロイする場合の制限の詳細を示しています。
-
ゾーン内の Amazon EC2 インスタンスとリージョン内の Amazon EC2 インスタンス間の最大伝送単位 (MTU) は
1300
です。これにより、デプロイメントで使用されるネットワークプラグインに応じて、クラスター全体のネットワーク MTU が変わります。 - Network Load Balancer (NLB)、Classic Load Balancer、Network Address Translation (NAT) ゲートウェイなどのネットワークリソースは、グローバルにサポートされていません。
-
AWS 上の OpenShift Container Platform クラスターの場合、AWS Elastic Block Storage (EBS)
gp3
タイプのボリュームがノードボリュームのデフォルトであり、ストレージクラスのデフォルトです。このボリュームタイプは、ゾーンの場所ではグローバルに使用できません。デフォルトでは、ゾーン内で実行されるノードは、gp2
EBS ボリュームを使用してデプロイされます。ゾーンのノードにワークロードを作成する場合は、gp2-csi
StorageClass
パラメーターを設定する必要があります。
インストールプログラムで OpenShift Container Platform クラスターの Wavelength Zone サブネットを自動的に作成する場合、この方法に伴う固有の設定制限が適用されます。次の注記で、これらの制限の一部について詳しく説明します。その他の制限については、「インフラストラクチャーの前提条件」セクションに記載されている「Quotas and considerations for Wavelength Zones」ドキュメントをお読みください。
OpenShift Container Platform クラスターのサブネットを自動的に作成するようにインストールプログラムを設定する場合は、次の設定制限が適用されます。
- インストールプログラムは、AWS Wavelength Zones にプライベートサブネットを作成するときに、各サブネットをその親ゾーンのルートテーブルに関連付けます。この操作により、各プライベートサブネットが AWS リージョンの NAT ゲートウェイ経由で Egress トラフィックをインターネットにルーティングできるようになります。
- クラスターのインストール時に親ゾーンのルートテーブルが存在しない場合、インストールプログラムは、プライベートサブネットを Amazon Virtual Private Cloud (VPC) 内の最初に使用可能なプライベートルートテーブルに関連付けます。このアプローチは、OpenShift Container Platform クラスター内の AWS Wavelength Zones サブネットに対してのみ有効です。
4.3.12.2.2. エッジコンピュートプールについて
エッジコンピュートノードは、AWS Wavelength Zones の場所で実行される taint されたコンピュートノードです。
Wavelength Zones を使用するクラスターをデプロイする場合は、次の点を考慮してください。
- Wavelength Zones 内の Amazon EC2 インスタンスは、アベイラビリティーゾーン内の Amazon EC2 インスタンスよりも高コストです。
- AWS Wavelength Zones で実行されているアプリケーションとエンドユーザーの間の遅延は低くなります。一部のワークロードでは、遅延の影響が発生します。たとえば、Wavelength Zones とアベイラビリティーゾーンの間で Ingress トラフィックが混在している場合などです。
通常、Wavelength Zones 内の Amazon EC2 インスタンスとリージョン内の Amazon EC2 インスタンス間の最大伝送単位 (MTU) は 1300 です。クラスターネットワークの MTU は、オーバーヘッドを考慮して、常に EC2 の MTU よりも小さくする必要があります。具体的なオーバーヘッドは、ネットワークプラグインによって決まります。たとえば、OVN-Kubernetes のオーバーヘッドは 100 bytes
です。
ネットワークプラグインは、IPsec などの追加機能を提供できます。MTU のサイズには、このような追加機能も影響します。
詳細は、AWS ドキュメントの How AWS Wavelength work を参照してください。
OpenShift Container Platform 4.12 で、リモートゾーンで使用するために設計された新しいコンピュートプールの エッジ が導入されました。エッジコンピュートプールの設定は、Wavelength Zones の場所間で共通です。Wavelength Zones リソース上の EC2 や EBS などのリソースのタイプとサイズの制限により、デフォルトのインスタンスタイプが従来のコンピュートプールと異なる場合があります。
Wavelength Zones の場所のデフォルト Elastic Block Store (EBS) は gp2
であり、非エッジコンピュートプールとは異なります。各 Wavelength Zones に使用される、エッジコンピュートプールのインスタンスタイプも、ゾーンのインスタンスオファリングに応じて、他のコンピュートプールと異なる場合があります。
エッジコンピュートプールは、開発者が AWS Wavelength Zones ノードにアプリケーションをデプロイするために使用できる新しいラベルを作成します。新しいラベルは次のとおりです。
-
node-role.kubernetes.io/edge=''
-
machine.openshift.io/zone-type=wavelength-zone
-
machine.openshift.io/zone-group=$ZONE_GROUP_NAME
デフォルトでは、エッジコンピュートプールのマシンセットは NoSchedule
taint を定義して、Wavelength Zones インスタンスに他のワークロードが拡散するのを防ぎます。ユーザーは、Pod 仕様で toleration を定義している場合にのみユーザーワークロードを実行できます。
4.3.12.3. インストールの要件
AWS Wavelength Zones 環境にクラスターをインストールする前に、Wavelength Zone 機能を導入できるようにインフラストラクチャーを設定する必要があります。
4.3.12.3.1. AWS Wavelength Zones へのオプトイン
AWS Wavelength Zones でサブネットを作成する予定がある場合は、各ゾーングループに個別にオプトインする必要があります。
前提条件
- AWS CLI をインストールしている。
- OpenShift Container Platform クラスターをデプロイする AWS リージョンを決定しました。
- ゾーングループにオプトインするユーザーまたはロールアカウントに、寛容な IAM ポリシーをアタッチしました。
手順
次のコマンドを実行して、AWS リージョンで利用可能なゾーンをリスト表示します。
AWS リージョンで利用可能な AWS Wavelength Zones をリストするコマンドの例
$ aws --region "<value_of_AWS_Region>" ec2 describe-availability-zones \ --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \ --filters Name=zone-type,Values=wavelength-zone \ --all-availability-zones
AWS リージョンによっては、利用可能なゾーンのリストが長くなる場合があります。このコマンドは次のフィールドを返します。
ZoneName
- Wavelength Zones の名前。
GroupName
- ゾーンで構成されるグループ。リージョンにオプトインするには、この名前を保存しておきます。
Status
-
Wavelength Zones グループのステータス。ステータスが
not-opted-in
の場合は、次の手順で説明するようにGroupName
をオプトインする必要があります。
次のコマンドを実行して、AWS アカウントのゾーングループにオプトインします。
$ aws ec2 modify-availability-zone-group \ --group-name "<value_of_GroupName>" \1 --opt-in-status opted-in
- 1
<value_of_GroupName>
は、サブネットを作成する Wavelength Zones のグループの名前に置き換えます。たとえば、Wavelength Zones としてゾーンus-east-1-wl1-nyc-wlz-1
(米国東部ニューヨーク) を使用するには、us-east-1-wl1
を指定します。
4.3.12.3.2. AWS Marketplace イメージの取得
AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがコンピュートノードのデプロイに使用する AMI ID が提供されます。
前提条件
- オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。
手順
- AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
ご使用の AWS リージョンの 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": ...}'
4.3.12.4. インストールの準備
ノードを Wavelength Zone に拡張する前に、クラスターのインストール環境用に特定のリソースを準備する必要があります。
4.3.12.4.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 アーキテクチャー を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
4.3.12.4.2. AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) インスタンスタイプは、AWS Wavelength Zones で使用できることを OpenShift Container Platform でテスト済みです。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.51 AWS Wavelength Zones で使用できる 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
r5.*
-
t3.*
関連情報
- AWS ドキュメントの AWS Wavelength features を参照してください。
4.3.12.4.3. インストール設定ファイルの作成
インストールプログラムがクラスターをデプロイするために必要なインストール設定ファイルを生成し、カスタマイズします。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
-
Red Hat が公開している付属の Red Hat Enterprise Linux CoreOS (RHCOS) AMI のある AWS リージョンにクラスターをデプロイしようとしている。カスタム AMI が必要な AWS リージョン (AWS GovCloud リージョンなど) にデプロイする場合は、
install-config.yaml
ファイルを手動で作成する必要があります。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして aws を選択します。
AWS プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
注記AWS アクセスキー ID およびシークレットアクセスキーは、インストールホストの現行ユーザーのホームディレクトリーの
~/.aws/credentials
に保存されます。エクスポートされたプロファイルの認証情報がファイルにない場合は、インストールプログラムにより認証情報の入力が求めるプロンプトが出されます。インストールプログラムに指定する認証情報は、ファイルに保存されます。- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
オプション:
install-config.yaml
ファイルをバックアップします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
4.3.12.4.4. エッジコンピュートプールを含むインストール設定ファイルの例
次の例は、エッジマシンプール設定を含む install-config.yaml
ファイルを示しています。
カスタムインスタンスタイプのエッジプールを使用する設定
apiVersion: v1 baseDomain: devcluster.openshift.com metadata: name: ipi-edgezone compute: - name: edge platform: aws: type: r5.2xlarge platform: aws: region: us-west-2 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA...
インスタンスのタイプは場所によって異なります。クラスターを実行する Wavelength Zones で利用可能かどうかを確認するには、AWS のドキュメントを参照してください。
カスタムセキュリティーグループを持つエッジプールを使用する設定
apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
name: ipi-edgezone
compute:
- name: edge
platform:
aws:
additionalSecurityGroupIDs:
- sg-1 1
- sg-2
platform:
aws:
region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...
- 1
- Amazon EC2 コンソールに表示されるセキュリティーグループの名前を指定します。必ず
sg
接頭辞を含めてください。
4.3.12.5. AWS Wavelength Zones 環境のクラスターインストール方法
以下のいずれかのインストール方法を選択して、Wavelength Zones に定義されたエッジコンピュートノードを使用して OpenShift Container Platform クラスターを AWS にインストールします。
- 完全に自動化された方法: クラスターをインストールして、コンピュートノードをエッジコンピュートプールに迅速に拡張します。インストールプログラムが、OpenShift Container Platform クラスター用のインフラストラクチャーリソースを自動的に作成します。
-
既存の VPC を使用する方法: AWS 上のクラスターを既存の VPC にインストールします。この場合、Wavelength Zones サブネットを
install-config.yaml
ファイルに指定します。
次のステップ
次のいずれかの方法を選択して、OpenShift Container Platform クラスターを AWS Wavelength Zones 環境にインストールします。
4.3.12.6. クラスターの AWS Wavelength Zones へのクイックインストール
OpenShift Container Platform 4.16 では、Amazon Web Services (AWS) にクラスターをすばやくインストールして、コンピュートノードを Wavelength Zones の場所に拡張できます。このインストール方法を使用すると、設定ファイルで定義した各ゾーンのネットワークリソースと Wavelength Zones サブネットが、インストールプログラムによって自動的に作成されます。インストールをカスタマイズするには、クラスターをデプロイする前に、install-config.yaml
ファイル内のパラメーターを変更する必要があります。
4.3.12.6.1. AWS Wavelength Zones を使用するためのインストール設定ファイルの変更
install-config.yaml
ファイルを変更して、AWS Wavelength Zones を含めます。
前提条件
- AWS アカウントが設定されている。
-
aws configure
を実行して、AWS キーと AWS リージョンをローカル AWS プロファイルに追加している。 - OpenShift Container Platform クラスターのサブネットを自動的に作成するようにインストールプログラムを指定する際に適用される設定上の制限を理解している。
- 各ゾーンの Wavelength Zones グループにオプトインしている。
-
「インストール設定ファイルの作成」手順を使用して、
install-config.yaml
ファイルを作成している。
手順
install-config.yaml
ファイルを変更して、エッジコンピュートプールのplatform.aws.zones
プロパティーで Wavelength Zones 名を指定します。# ... platform: aws: region: <region_name> 1 compute: - name: edge platform: aws: zones: 2 - <wavelength_zone_name> #...
エッジノードを
Los Angeles
とLas Vegas
の Wavelength Zones に拡張するus-west-2
AWS リージョンにクラスターをインストールする設定の例apiVersion: v1 baseDomain: example.com metadata: name: cluster-name platform: aws: region: us-west-2 compute: - name: edge platform: aws: zones: - us-west-2-wl1-lax-wlz-1 - us-west-2-wl1-las-wlz-1 pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' #...
- クラスターをデプロイします。
次のステップ
4.3.12.7. Wavelength Zone のサブネットを持つ既存の VPC へのクラスターのインストール
クラスターを Amazon Web Services (AWS) 上の既存の Amazon Virtual Private Cloud (VPC) にインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
AWS 上のクラスターを既存の VPC にインストールするには、AWS Wavelength Zones を使用してコンピュートノードをクラウドインフラストラクチャーのエッジまで拡張する必要があります。
このドキュメントの CloudFormation テンプレートを使用して、ネットワークリソースを作成できます。さらに、テンプレートを変更してインフラストラクチャーをカスタマイズしたり、テンプレートに含まれる情報を使用して会社のポリシーに基づいて AWS リソースを作成したりできます。
installer-provisioned infrastructure のインストールを実行する手順は、例としてのみ提供されています。既存の VPC にクラスターをインストールするには、クラウドプロバイダーと OpenShift Container Platform のインストールプロセスに関する知識が必要です。CloudFormation テンプレートを使用すると、これらの手順の完了を支援したり、独自のクラスターのインストールをモデル化したりできます。CloudFormation テンプレートを使用してリソースを作成する代わりに、これらのリソースを生成するために他の方法を使用することを決定できます。
4.3.12.7.1. AWS での VPC の作成
OpenShift Container Platform クラスター用の Amazon Web Services (AWS) で、Virtual Private Cloud (VPC) を作成し、Wavelength Zones のすべての場所にサブネットを作成すると、コンピュートノードをエッジロケーションに拡張できます。VPC は、VPN やルートテーブルなどの要件に合わせてさらにカスタマイズできます。初期デプロイメントに含まれていない新しい Wavelength Zones サブネットを追加することもできます。
提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、VPC を表す AWS リソースのスタックを作成できます。
このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- AWS アカウントを設定している。
-
aws configure
を実行して、AWS キーと AWS リージョンをローカル AWS プロファイルに追加している。 - AWS アカウントで AWS Wavelength Zones にオプトインしている。
手順
CloudFormation テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。
[ { "ParameterKey": "VpcCidr", 1 "ParameterValue": "10.0.0.0/16" 2 }, { "ParameterKey": "AvailabilityZoneCount", 3 "ParameterValue": "3" 4 }, { "ParameterKey": "SubnetBits", 5 "ParameterValue": "12" 6 } ]
- このドキュメントの「VPC の CloudFormation テンプレート」セクションに移動し、記載されているテンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC について記述しています。
次のコマンドを実行して、CloudFormation テンプレートを起動し、VPC を表す AWS リソースのスタックを作成します。
重要単一行にコマンドを入力してください。
$ aws cloudformation create-stack --stack-name <name> \1 --template-body file://<template>.yaml \2 --parameters file://<parameters>.json 3
出力例
arn:aws:cloudformation:us-east-1:123456789012:stack/cluster-vpc/dbedae40-2fd3-11eb-820e-12a48460849f
次のコマンドを実行して、テンプレートコンポーネントが存在することを確認します。
$ aws cloudformation describe-stacks --stack-name <name>
StackStatus
がCREATE_COMPLETE
を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。VpcId
VPC の ID。
PublicSubnetIds
新規パブリックサブネットの ID。
PrivateSubnetIds
新規プライベートサブネットの ID。
PublicRouteTableId
新しいパブリックルートテーブル ID の ID。
4.3.12.7.2. VPC の CloudFormation テンプレート
以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。
例4.52 VPC の CloudFormation テンプレート
AWSTemplateFormatVersion: 2010-09-09 Description: Template for Best Practice VPC with 1-3 AZs Parameters: VpcCidr: AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$ ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24. Default: 10.0.0.0/16 Description: CIDR block for VPC. Type: String AvailabilityZoneCount: ConstraintDescription: "The number of availability zones. (Min: 1, Max: 3)" MinValue: 1 MaxValue: 3 Default: 1 Description: "How many AZs to create VPC subnets for. (Min: 1, Max: 3)" Type: Number SubnetBits: ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/19-27. MinValue: 5 MaxValue: 13 Default: 12 Description: "Size of each subnet to create within the availability zones. (Min: 5 = /27, Max: 13 = /19)" Type: Number Metadata: AWS::CloudFormation::Interface: ParameterGroups: - Label: default: "Network Configuration" Parameters: - VpcCidr - SubnetBits - Label: default: "Availability Zones" Parameters: - AvailabilityZoneCount ParameterLabels: AvailabilityZoneCount: default: "Availability Zone Count" VpcCidr: default: "VPC CIDR" SubnetBits: default: "Bits Per Subnet" Conditions: DoAz3: !Equals [3, !Ref AvailabilityZoneCount] DoAz2: !Or [!Equals [2, !Ref AvailabilityZoneCount], Condition: DoAz3] Resources: VPC: Type: "AWS::EC2::VPC" Properties: EnableDnsSupport: "true" EnableDnsHostnames: "true" CidrBlock: !Ref VpcCidr PublicSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VPC CidrBlock: !Select [0, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref "AWS::Region" PublicSubnet2: Type: "AWS::EC2::Subnet" Condition: DoAz2 Properties: VpcId: !Ref VPC CidrBlock: !Select [1, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 1 - Fn::GetAZs: !Ref "AWS::Region" PublicSubnet3: Type: "AWS::EC2::Subnet" Condition: DoAz3 Properties: VpcId: !Ref VPC CidrBlock: !Select [2, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 2 - Fn::GetAZs: !Ref "AWS::Region" InternetGateway: Type: "AWS::EC2::InternetGateway" GatewayToInternet: Type: "AWS::EC2::VPCGatewayAttachment" Properties: VpcId: !Ref VPC InternetGatewayId: !Ref InternetGateway PublicRouteTable: Type: "AWS::EC2::RouteTable" Properties: VpcId: !Ref VPC PublicRoute: Type: "AWS::EC2::Route" DependsOn: GatewayToInternet Properties: RouteTableId: !Ref PublicRouteTable DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway PublicSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PublicSubnet RouteTableId: !Ref PublicRouteTable PublicSubnetRouteTableAssociation2: Type: "AWS::EC2::SubnetRouteTableAssociation" Condition: DoAz2 Properties: SubnetId: !Ref PublicSubnet2 RouteTableId: !Ref PublicRouteTable PublicSubnetRouteTableAssociation3: Condition: DoAz3 Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PublicSubnet3 RouteTableId: !Ref PublicRouteTable PrivateSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VPC CidrBlock: !Select [3, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref "AWS::Region" PrivateRouteTable: Type: "AWS::EC2::RouteTable" Properties: VpcId: !Ref VPC PrivateSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PrivateSubnet RouteTableId: !Ref PrivateRouteTable NAT: DependsOn: - GatewayToInternet Type: "AWS::EC2::NatGateway" Properties: AllocationId: "Fn::GetAtt": - EIP - AllocationId SubnetId: !Ref PublicSubnet EIP: Type: "AWS::EC2::EIP" Properties: Domain: vpc Route: Type: "AWS::EC2::Route" Properties: RouteTableId: Ref: PrivateRouteTable DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: Ref: NAT PrivateSubnet2: Type: "AWS::EC2::Subnet" Condition: DoAz2 Properties: VpcId: !Ref VPC CidrBlock: !Select [4, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 1 - Fn::GetAZs: !Ref "AWS::Region" PrivateRouteTable2: Type: "AWS::EC2::RouteTable" Condition: DoAz2 Properties: VpcId: !Ref VPC PrivateSubnetRouteTableAssociation2: Type: "AWS::EC2::SubnetRouteTableAssociation" Condition: DoAz2 Properties: SubnetId: !Ref PrivateSubnet2 RouteTableId: !Ref PrivateRouteTable2 NAT2: DependsOn: - GatewayToInternet Type: "AWS::EC2::NatGateway" Condition: DoAz2 Properties: AllocationId: "Fn::GetAtt": - EIP2 - AllocationId SubnetId: !Ref PublicSubnet2 EIP2: Type: "AWS::EC2::EIP" Condition: DoAz2 Properties: Domain: vpc Route2: Type: "AWS::EC2::Route" Condition: DoAz2 Properties: RouteTableId: Ref: PrivateRouteTable2 DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: Ref: NAT2 PrivateSubnet3: Type: "AWS::EC2::Subnet" Condition: DoAz3 Properties: VpcId: !Ref VPC CidrBlock: !Select [5, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 2 - Fn::GetAZs: !Ref "AWS::Region" PrivateRouteTable3: Type: "AWS::EC2::RouteTable" Condition: DoAz3 Properties: VpcId: !Ref VPC PrivateSubnetRouteTableAssociation3: Type: "AWS::EC2::SubnetRouteTableAssociation" Condition: DoAz3 Properties: SubnetId: !Ref PrivateSubnet3 RouteTableId: !Ref PrivateRouteTable3 NAT3: DependsOn: - GatewayToInternet Type: "AWS::EC2::NatGateway" Condition: DoAz3 Properties: AllocationId: "Fn::GetAtt": - EIP3 - AllocationId SubnetId: !Ref PublicSubnet3 EIP3: Type: "AWS::EC2::EIP" Condition: DoAz3 Properties: Domain: vpc Route3: Type: "AWS::EC2::Route" Condition: DoAz3 Properties: RouteTableId: Ref: PrivateRouteTable3 DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: Ref: NAT3 S3Endpoint: Type: AWS::EC2::VPCEndpoint Properties: PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: '*' Action: - '*' Resource: - '*' RouteTableIds: - !Ref PublicRouteTable - !Ref PrivateRouteTable - !If [DoAz2, !Ref PrivateRouteTable2, !Ref "AWS::NoValue"] - !If [DoAz3, !Ref PrivateRouteTable3, !Ref "AWS::NoValue"] ServiceName: !Join - '' - - com.amazonaws. - !Ref 'AWS::Region' - .s3 VpcId: !Ref VPC Outputs: VpcId: Description: ID of the new VPC. Value: !Ref VPC PublicSubnetIds: Description: Subnet IDs of the public subnets. Value: !Join [ ",", [!Ref PublicSubnet, !If [DoAz2, !Ref PublicSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PublicSubnet3, !Ref "AWS::NoValue"]] ] PrivateSubnetIds: Description: Subnet IDs of the private subnets. Value: !Join [ ",", [!Ref PrivateSubnet, !If [DoAz2, !Ref PrivateSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PrivateSubnet3, !Ref "AWS::NoValue"]] ] PublicRouteTableId: Description: Public Route table ID Value: !Ref PublicRouteTable PrivateRouteTableIds: Description: Private Route table IDs Value: !Join [ ",", [ !Join ["=", [ !Select [0, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable ]], !If [DoAz2, !Join ["=", [!Select [1, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable2]], !Ref "AWS::NoValue" ], !If [DoAz3, !Join ["=", [!Select [2, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable3]], !Ref "AWS::NoValue" ] ] ]
4.3.12.7.3. VPC キャリアーゲートウェイの作成
Wavelength Zones で実行される OpenShift Container Platform クラスターでパブリックサブネットを使用するには、キャリアーゲートウェイを作成し、キャリアーゲートウェイを VPC に関連付ける必要があります。サブネットは、ロードバランサーまたはエッジコンピュートノードをデプロイするのに役立ちます。
OpenShift Container Platform クラスター用の Wavelength Zones の場所に、エッジノードやインターネットに接続されたロードバランサーを作成するには、以下の必要なネットワークコンポーネントを作成する必要があります。
- 既存の VPC に関連付けるキャリアーゲートウェイ
- ルートエントリーをリストするキャリールートテーブル
- キャリアールートテーブルに関連付けるサブネット
キャリアーゲートウェイは、Wavelength Zone 内のサブネットのみを含む VPC に存在します。
以下では、AWS Wavelength Zones の場所に関連するキャリアーゲートウェイの機能を説明します。
- Wavelength Zone とキャリアーネットワーク (キャリアーネットワークから利用可能なデバイスを含む) の間の接続を提供します。
- ネットワークボーダーグループに格納されているパブリック IP アドレスである IP アドレスを Wavelength Zones からキャリアー IP アドレスに変換するなど、ネットワークアドレス変換 (NAT) 機能を実行します。このような変換機能は、受信トラフィックと送信トラフィックに適用されます。
- 特定の場所にあるキャリアーネットワークからの受信トラフィックを許可します。
- キャリアーネットワークとインターネットへの送信トラフィックを許可します。
インターネットからキャリアーゲートウェイを経由した Wavelength Zone への受信接続設定は存在しません。
このドキュメントの CloudFormation テンプレートを使用して、次の AWS リソースのスタックを作成できます。
- テンプレート内の VPC ID に関連付ける 1 つのキャリアーゲートウェイ
-
<ClusterName>-public-carrier
という名前の Wavelength Zone の 1 つのパブリックルートテーブル - キャリアーゲートウェイをターゲットとする新しいルートテーブルのデフォルトの IPv4 ルートエントリー
- AWS Simple Storage Service (S3) の VPC ゲートウェイエンドポイント
このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- AWS アカウントを設定している。
-
aws configure
を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
手順
- ドキュメントの次のセクション「VPC キャリアーゲートウェイ用の CloudFormation テンプレート」に移動し、VPC キャリアーゲートウェイ用の CloudFormation テンプレート から構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC について記述しています。
次のコマンドを実行して CloudFormation テンプレートをデプロイします。これにより、VPC を表す AWS リソースのスタックが作成されます。
$ aws cloudformation create-stack --stack-name <stack_name> \1 --region ${CLUSTER_REGION} \ --template-body file://<template>.yaml \2 --parameters \// ParameterKey=VpcId,ParameterValue="${VpcId}" \3 ParameterKey=ClusterName,ParameterValue="${ClusterName}" 4
- 1
<stack_name>
は CloudFormation スタックの名前です (例:clusterName-vpc-carrier-gw
)。クラスターを削除する場合に、このスタックの名前が必要になります。- 2
<template>
は、保存した CloudFormation テンプレート YAML ファイルの相対パスと名前です。- 3
<VpcId>
は、「AWS での VPC の作成」セクションで作成した CloudFormation スタックの出力から抽出した VPC ID です。- 4
<ClusterName>
は、CloudFormation スタックによって作成されるリソースに接頭辞として付加するカスタム値です。install-config.yaml
設定ファイルのmetadata.name
セクションで定義されているのと同じ名前を使用できます。
出力例
arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-2fd3-11eb-820e-12a48460849f
検証
次のコマンドを実行して、CloudFormation テンプレートコンポーネントが存在することを確認します。
$ aws cloudformation describe-stacks --stack-name <stack_name>
StackStatus
にCREATE_COMPLETE
が表示されると、出力に次のパラメーターの値が表示されます。このパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。PublicRouteTableId
キャリアーインフラストラクチャーのルートテーブルの ID。
関連情報
- AWS ドキュメントの Amazon S3 を参照してください。
4.3.12.7.4. VPC キャリアーゲートウェイ用の CloudFormation テンプレート
次の CloudFormation テンプレートを使用して、AWS Wavelength インフラストラクチャーにキャリアーゲートウェイをデプロイできます。
例4.53 VPC キャリアーゲートウェイ用の CloudFormation テンプレート
AWSTemplateFormatVersion: 2010-09-09 Description: Template for Creating Wavelength Zone Gateway (Carrier Gateway). Parameters: VpcId: Description: VPC ID to associate the Carrier Gateway. Type: String AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$ ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*. ClusterName: Description: Cluster Name or Prefix name to prepend the tag Name for each subnet. Type: String AllowedPattern: ".+" ConstraintDescription: ClusterName parameter must be specified. Resources: CarrierGateway: Type: "AWS::EC2::CarrierGateway" Properties: VpcId: !Ref VpcId Tags: - Key: Name Value: !Join ['-', [!Ref ClusterName, "cagw"]] PublicRouteTable: Type: "AWS::EC2::RouteTable" Properties: VpcId: !Ref VpcId Tags: - Key: Name Value: !Join ['-', [!Ref ClusterName, "public-carrier"]] PublicRoute: Type: "AWS::EC2::Route" DependsOn: CarrierGateway Properties: RouteTableId: !Ref PublicRouteTable DestinationCidrBlock: 0.0.0.0/0 CarrierGatewayId: !Ref CarrierGateway S3Endpoint: Type: AWS::EC2::VPCEndpoint Properties: PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: '*' Action: - '*' Resource: - '*' RouteTableIds: - !Ref PublicRouteTable ServiceName: !Join - '' - - com.amazonaws. - !Ref 'AWS::Region' - .s3 VpcId: !Ref VpcId Outputs: PublicRouteTableId: Description: Public Route table ID Value: !Ref PublicRouteTable
4.3.12.7.5. Wavelength Zones のサブネットの作成
OpenShift Container Platform クラスターのエッジコンピュートノードのマシンセットを設定する前に、Wavelength Zones にサブネットを作成する必要があります。コンピュートノードをデプロイする Wavelength Zone ごとに次の手順を実行してください。
このドキュメントの CloudFormation テンプレートを使用して、CloudFormation スタックを作成できます。その後、このスタックを使用してサブネットをカスタムプロビジョニングできます。
このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- AWS アカウントを設定している。
-
aws configure
を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。 - Wavelength Zones グループにオプトインしている。
手順
- このドキュメントの「VPC サブネット用の CloudFormation テンプレート」セクションに移動し、テンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC について記述しています。
次のコマンドを実行して CloudFormation テンプレートをデプロイします。これにより、VPC を表す AWS リソースのスタックが作成されます。
$ aws cloudformation create-stack --stack-name <stack_name> \ 1 --region ${CLUSTER_REGION} \ --template-body file://<template>.yaml \ 2 --parameters \ ParameterKey=VpcId,ParameterValue="${VPC_ID}" \ 3 ParameterKey=ClusterName,ParameterValue="${CLUSTER_NAME}" \ 4 ParameterKey=ZoneName,ParameterValue="${ZONE_NAME}" \ 5 ParameterKey=PublicRouteTableId,ParameterValue="${ROUTE_TABLE_PUB}" \ 6 ParameterKey=PublicSubnetCidr,ParameterValue="${SUBNET_CIDR_PUB}" \ 7 ParameterKey=PrivateRouteTableId,ParameterValue="${ROUTE_TABLE_PVT}" \ 8 ParameterKey=PrivateSubnetCidr,ParameterValue="${SUBNET_CIDR_PVT}" 9
- 1
<stack_name>
は、CloudFormation スタックの名前です (cluster-wl-<wavelength_zone_shortname>
など)。クラスターを削除する場合に、このスタックの名前が必要になります。- 2
<template>
は、保存した CloudFormation テンプレート YAML ファイルの相対パスと名前です。- 3
${VPC_ID}
は VPC ID であり、VPC 用の CloudFormation テンプレートの出力に含まれる値VpcID
です。- 4
${ZONE_NAME}
は、サブネットを作成する Wavelength Zones 名の値です。- 5
${CLUSTER_NAME}
は、新しい AWS リソース名の接頭辞として使用する ClusterName の値です。- 6
${ROUTE_TABLE_PUB}
は、VPC のキャリアーゲートウェイ CloudFormation スタックの出力から抽出した PublicRouteTableId です。- 7
${SUBNET_CIDR_PUB}
は、パブリックサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロックVpcCidr
の一部である必要があります。- 8
${ROUTE_TABLE_PVT}
は、VPC の CloudFormation スタックの出力から抽出した PrivateRouteTableId です。- 9
${SUBNET_CIDR_PVT}
は、プライベートサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロックVpcCidr
の一部である必要があります。
出力例
arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-820e-11eb-2fd3-12a48460849f
検証
次のコマンドを実行して、テンプレートコンポーネントが存在することを確認します。
$ aws cloudformation describe-stacks --stack-name <stack_name>
StackStatus
がCREATE_COMPLETE
を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。PublicSubnetId
CloudFormation スタックによって作成されたパブリックサブネットの ID。
PrivateSubnetId
CloudFormation スタックによって作成されたプライベートサブネットの ID。
4.3.12.7.6. VPC サブネット用の CloudFormation テンプレート
次の CloudFormation テンプレートを使用して、Wavelength Zones インフラストラクチャー上のゾーンにプライベートサブネットとパブリックサブネットをデプロイできます。
例4.54 VPC サブネット用の CloudFormation テンプレート
AWSTemplateFormatVersion: 2010-09-09 Description: Template for Best Practice Subnets (Public and Private) Parameters: VpcId: Description: VPC ID that comprises all the target subnets. Type: String AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$ ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*. ClusterName: Description: Cluster name or prefix name to prepend the Name tag for each subnet. Type: String AllowedPattern: ".+" ConstraintDescription: ClusterName parameter must be specified. ZoneName: Description: Zone Name to create the subnets, such as us-west-2-lax-1a. Type: String AllowedPattern: ".+" ConstraintDescription: ZoneName parameter must be specified. PublicRouteTableId: Description: Public Route Table ID to associate the public subnet. Type: String AllowedPattern: ".+" ConstraintDescription: PublicRouteTableId parameter must be specified. PublicSubnetCidr: AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$ ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24. Default: 10.0.128.0/20 Description: CIDR block for public subnet. Type: String PrivateRouteTableId: Description: Private Route Table ID to associate the private subnet. Type: String AllowedPattern: ".+" ConstraintDescription: PrivateRouteTableId parameter must be specified. PrivateSubnetCidr: AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$ ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24. Default: 10.0.128.0/20 Description: CIDR block for private subnet. Type: String Resources: PublicSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VpcId CidrBlock: !Ref PublicSubnetCidr AvailabilityZone: !Ref ZoneName Tags: - Key: Name Value: !Join ['-', [!Ref ClusterName, "public", !Ref ZoneName]] PublicSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PublicSubnet RouteTableId: !Ref PublicRouteTableId PrivateSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VpcId CidrBlock: !Ref PrivateSubnetCidr AvailabilityZone: !Ref ZoneName Tags: - Key: Name Value: !Join ['-', [!Ref ClusterName, "private", !Ref ZoneName]] PrivateSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PrivateSubnet RouteTableId: !Ref PrivateRouteTableId Outputs: PublicSubnetId: Description: Subnet ID of the public subnets. Value: !Join ["", [!Ref PublicSubnet]] PrivateSubnetId: Description: Subnet ID of the private subnets. Value: !Join ["", [!Ref PrivateSubnet]]
4.3.12.7.7. AWS Wavelength Zones サブネットを使用するためのインストール設定ファイルの変更
install-config.yaml
ファイルを変更して、Wavelength Zones のサブネットを含めます。
前提条件
- 「Wavelength Zone のサブネットの作成」手順を使用して、サブネットを作成している。
-
「インストール設定ファイルの作成」手順を使用して、
install-config.yaml
ファイルを作成している。
手順
install-config.yaml
設定ファイルを変更して、platform.aws.subnets
パラメーターで Wavelength Zones のサブネットを指定します。Wavelength Zones のサブネットを含むインストール設定ファイルの例
# ... platform: aws: region: us-west-2 subnets: 1 - publicSubnetId-1 - publicSubnetId-2 - publicSubnetId-3 - privateSubnetId-1 - privateSubnetId-2 - privateSubnetId-3 - publicOrPrivateSubnetID-Wavelength-1 # ...
- 1
- ゾーン (アベイラビリティーゾーンと Wavelength Zones) 内に作成したサブネット ID のリスト。
関連情報
- 作成した CloudFormation スタックを表示する方法の詳細は、AWS CloudFormation コンソール を参照してください。
- AWS プロファイルと認証情報を設定する方法の詳細は、AWS ドキュメントの Configuration and credential file settings を参照してください。
次のステップ
4.3.12.8. オプション: パブリック IP アドレスをエッジコンピュートノードに割り当てます。
ワークロードによっては、Wavelength Zones インフラストラクチャー上のパブリックサブネットにエッジコンピュートノードをデプロイすることが必要になります。その場合は、クラスターのインストール時にマシンセットマニフェストを設定できます。
AWS Wavelength Zones インフラストラクチャーは、指定されたゾーン内のネットワークトラフィックにアクセスします。そのため、そのゾーンに近いエンドユーザーにサービスを提供する際に、アプリケーションで低遅延を利用できます。
デフォルト設定は、プライベートサブネットにコンピュートノードをデプロイする設定であり、お客様のニーズに合わない可能性があります。そのため、インフラストラクチャーにさらにカスタマイズを適用する必要がある場合は、パブリックサブネットにエッジコンピュートノードを作成することを検討してください。
デフォルトでは、OpenShift Container Platform はプライベートサブネットにコンピュートノードをデプロイします。最高のパフォーマンスを得るには、パブリック IP アドレスがサブネットに接続されているサブネットにコンピュートノードを配置することを検討してください。
追加のセキュリティーグループを作成する必要があります。ただし、インターネット経由でグループのルールを開くのは、本当に必要な場合だけに留めてください。
手順
インストールプログラムが含まれるディレクトリーに移動し、マニフェストファイルを生成します。インストールマニフェストが
openshift
およびmanifests
ディレクトリーレベルに作成されていることを確認します。$ ./openshift-install create manifests --dir <installation_directory>
インストールプログラムが Wavelength Zones 用に生成するマシンセットマニフェストを編集して、マニフェストがパブリックサブネットにデプロイされるようにします。
spec.template.spec.providerSpec.value.publicIP
パラメーターにtrue
を指定します。クラスターを Wavelength Zones に迅速にインストールするためのマシンセットマニフェスト設定の例
spec: template: spec: providerSpec: value: publicIp: true subnet: filters: - name: tag:Name values: - ${INFRA_ID}-public-${ZONE_NAME}
Wavelength Zones サブネットを持つ既存の VPC にクラスターをインストールするためのマシンセットマニフェスト設定の例
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: name: <infrastructure_id>-edge-<zone> namespace: openshift-machine-api spec: template: spec: providerSpec: value: publicIp: true
4.3.12.9. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.3.12.10. デプロイしたクラスターのステータスの確認
OpenShift Container Platform が AWS Wavelength Zones に正常にデプロイされたことを確認します。
4.3.12.10.1. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
4.3.12.10.2. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。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
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
4.3.12.10.3. エッジコンピューティングプールで作成されたノードの検証
AWS Wavelength Zones インフラストラクチャーを使用するクラスターをインストールしたら、インストール時に作成したマシンセットマニフェストによって作成されたマシンのステータスを確認します。
install-config.yaml
ファイルに追加したサブネットから作成されたマシンセットを確認するには、次のコマンドを実行します。$ oc get machineset -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE cluster-7xw5g-edge-us-east-1-wl1-nyc-wlz-1 1 1 1 1 3h4m cluster-7xw5g-worker-us-east-1a 1 1 1 1 3h4m cluster-7xw5g-worker-us-east-1b 1 1 1 1 3h4m cluster-7xw5g-worker-us-east-1c 1 1 1 1 3h4m
マシンセットから作成されたマシンを確認するには、次のコマンドを実行します。
$ oc get machines -n openshift-machine-api
出力例
NAME PHASE TYPE REGION ZONE AGE cluster-7xw5g-edge-us-east-1-wl1-nyc-wlz-1-wbclh Running c5d.2xlarge us-east-1 us-east-1-wl1-nyc-wlz-1 3h cluster-7xw5g-master-0 Running m6i.xlarge us-east-1 us-east-1a 3h4m cluster-7xw5g-master-1 Running m6i.xlarge us-east-1 us-east-1b 3h4m cluster-7xw5g-master-2 Running m6i.xlarge us-east-1 us-east-1c 3h4m cluster-7xw5g-worker-us-east-1a-rtp45 Running m6i.xlarge us-east-1 us-east-1a 3h cluster-7xw5g-worker-us-east-1b-glm7c Running m6i.xlarge us-east-1 us-east-1b 3h cluster-7xw5g-worker-us-east-1c-qfvz4 Running m6i.xlarge us-east-1 us-east-1c 3h
エッジロールを持つノードを確認するには、次のコマンドを実行します。
$ oc get nodes -l node-role.kubernetes.io/edge
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-207-188.ec2.internal Ready edge,worker 172m v1.25.2+d2e245f
次のステップ
- インストールを検証 します。
- 必要に応じて、リモートヘルスをオプトアウト できます。
4.3.13. AWS VPC クラスターの AWS Outpost への拡張
OpenShift Container Platform バージョン 4.14 では、テクノロジープレビュー機能として、AWS Outposts で実行されているコンピュートノードを使用して、Amazon Web Services (AWS) にクラスターをインストールすることができました。OpenShift Container Platform バージョン 4.15 以降、このインストール方法はサポートされなくなりました。代わりに、AWS 上のクラスターを既存の VPC にインストールし、インストール後の設定タスクとして AWS Outposts にコンピュートノードをプロビジョニングできます。
Amazon Web Services (AWS) 上のクラスターを既存の Amazon Virtual Private Cloud (VPC) にインストール した後、AWS Outposts にコンピュートマシンをデプロイするコンピュートマシンセットを作成できます。AWS Outposts は、低遅延のオンプレミス環境とともに、クラウドベースの AWS デプロイメントの多くの機能を使用できるようにする AWS エッジコンピュートサービスです。詳細は、AWS Outposts のドキュメント を参照してください。
4.3.13.1. OpenShift Container Platform 上の AWS Outposts の要件と制限
以下の要件と制限に対応するように OpenShift Container Platform クラスターを設定すると、クラウドベースの AWS クラスター上のリソースと同様に AWS Outpost 上のリソースを管理できます。
- AWS 上の OpenShift Container Platform クラスターを Outpost に拡張するには、クラスターを既存の Amazon Virtual Private Cloud (VPC) にインストールしておく必要があります。
- Outpost のインフラストラクチャーは、AWS リージョンのアベイラビリティーゾーンに関連付けられており、専用のサブネットを使用します。Outpost にデプロイされた Edge コンピュートマシンは、Outpost のサブネットと、Outpost が関連付けられているアベイラビリティーゾーンを使用する必要があります。
-
AWS Kubernetes クラウドコントローラーマネージャーは、Outpost サブネットを検出すると、Outpost サブネット内にサービスロードバランサーを作成しようとします。AWS Outposts は、サービスロードバランサーの実行をサポートしていません。クラウドコントローラーマネージャーが Outpost サブネットでサポート対象外のサービスを作成しないようにするには、Outpost サブネット設定に
kubernetes.io/cluster/unmanaged
タグを含める必要があります。この要件は、OpenShift Container Platform バージョン 4.16 における回避策です。詳細は、OCPBUGS-30041 を参照してください。 -
AWS 上の OpenShift Container Platform クラスターには、
gp3-csi
およびgp2-csi
ストレージクラスがあります。これらのクラスは、Amazon Elastic Block Store (EBS) の gp3 および gp2 ボリュームに対応します。OpenShift Container Platform クラスターはデフォルトでgp3-csi
ストレージクラスを使用しますが、AWS Outposts は EBS gp3 ボリュームをサポートしません。 -
この実装では、
node-role.kubernetes.io/outposts
taint を使用して、通常のクラスターのワークロードが Outpost ノードに分散するのを防ぎます。Outpost でユーザーのワークロードをスケジュールするには、アプリケーションのDeployment
リソースで対応する toleration を指定する必要があります。ユーザーのワークロード用に AWS Outpost インフラストラクチャーを予約すると、互換性を保つためにデフォルトの CSI をgp2-csi
に更新するなど、追加の設定要件が回避されます。 -
Outpost にボリュームを作成するには、CSI ドライバーに Outpost の Amazon Resource Name (ARN) が必要です。ドライバーは、
CSINode
オブジェクトに保存されているトポロジーキーを使用して、Outpost の ARN を特定します。ドライバーが正しいトポロジー値を使用するようにするには、ボリュームバインドモードをWaitForConsumer
に設定した上で、作成する新しいストレージクラスに、許可されるトポロジーを設定しないようにする必要があります。 AWS VPC クラスターを Outpost に拡張すると、2 種類のコンピューティングリソースが得られます。Outpost にはエッジコンピュートノードがあり、VPC にはクラウドベースのコンピュートノードがあります。クラウドベースの AWS Elastic Block ボリュームは、Outpost エッジコンピュートノードに接続できません。また、Outpost ボリュームはクラウドベースのコンピュートノードに接続できません。
そのため、CSI スナップショットを使用して、永続ストレージを使用するアプリケーションをクラウドベースのコンピュートノードからエッジコンピュートノードに移行したり、元の永続ボリュームを直接使用したりすることはできません。アプリケーションの永続ストレージデータを移行するには、手動でバックアップおよび復元操作を実行する必要があります。
AWS Outposts は、AWS Network Load Balancer または AWS Classic Load Balancer をサポートしていません。AWS Outposts 環境でエッジコンピュートリソースの負荷分散を有効にするには、AWS Application Load Balancer を使用する必要があります。
Application Load Balancer をプロビジョニングするには、Ingress リソースを使用し、AWS Load Balancer Operator をインストールする必要があります。クラスターに、ワークロードを共有するエッジベースとクラウドベースの両方のコンピュートインスタンスが含まれている場合は、追加の設定が必要です。
詳細は、「Outpost に拡張された AWS VPC クラスターでの AWS Load Balancer Operator の使用」を参照してください。
4.3.13.2. 環境に関する情報の取得
AWS VPC クラスターを Outpost に拡張するには、OpenShift Container Platform クラスターと Outpost 環境に関する情報を提供する必要があります。この情報を使用して、ネットワーク設定タスクを完了し、Outpost 内にコンピュートマシンを作成するコンピュートマシンセットを設定します。必要な詳細情報は、コマンドラインツールを使用して収集できます。
4.3.13.2.1. OpenShift Container Platform クラスターからの情報の取得
OpenShift CLI (oc
) を使用して、OpenShift Container Platform クラスターから情報を取得できます。
これらの値の一部またはすべてを、export
コマンドを使用して環境変数として保存すると便利な場合があります。
前提条件
- OpenShift Container Platform クラスターを AWS のカスタム VPC にインストールしている。
-
cluster-admin
権限を持つアカウントを使用してクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、クラスターのインフラストラクチャー ID をリスト表示します。この値を保存しておきます。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructures.config.openshift.io cluster
次のコマンドを実行して、インストールプログラムが作成したコンピュートマシンセットに関する詳細を取得します。
クラスター上のコンピュートマシンセットをリスト表示します。
$ oc get machinesets.machine.openshift.io -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE <compute_machine_set_name_1> 1 1 1 1 55m <compute_machine_set_name_2> 1 1 1 1 55m
リストされたコンピュートマシンセットのいずれかの Amazon Machine Image (AMI) ID を表示します。この値を保存しておきます。
$ oc get machinesets.machine.openshift.io <compute_machine_set_name_1> \ -n openshift-machine-api \ -o jsonpath='{.spec.template.spec.providerSpec.value.ami.id}'
AWS VPC クラスターのサブネット ID を表示します。この値を保存しておきます。
$ oc get machinesets.machine.openshift.io <compute_machine_set_name_1> \ -n openshift-machine-api \ -o jsonpath='{.spec.template.spec.providerSpec.value.subnet.id}'
4.3.13.2.2. AWS アカウントからの情報の取得
AWS CLI (aws
) を使用して、AWS アカウントから情報を取得できます。
これらの値の一部またはすべてを、export
コマンドを使用して環境変数として保存すると便利な場合があります。
前提条件
- 必要なハードウェアのセットアップが完了した AWS Outposts サイトがある。
- Outpost が AWS アカウントに接続されている。
-
必要なタスクを実行する権限を持つユーザーとして AWS CLI (
aws
) を使用して、AWS アカウントにアクセスできる。
手順
次のコマンドを実行して、AWS アカウントに接続されている Outpost をリスト表示します。
$ aws outposts list-outposts
aws outposts list-outposts
コマンドの出力の次の値を保存しておきます。- Outpost ID
- Outpost の Amazon Resource Name (ARN)
Outpost のアベイラビリティーゾーン
注記aws outposts list-outposts
コマンドの出力には、アベイラビリティーゾーンに関連する 2 つの値、AvailabilityZone
とAvailabilityZoneId
が含まれています。Outpost 内にコンピュートマシンを作成するコンピュートマシンセットを設定するには、AvailablilityZone
値を使用します。
Outpost ID の値を使用して次のコマンドを実行し、Outpost で利用可能なインスタンスタイプを表示します。利用可能なインスタンスタイプの値を保存しておきます。
$ aws outposts get-outpost-instance-types \ --outpost-id <outpost_id_value>
Outpost ARN の値を使用して次のコマンドを実行し、Outpost のサブネット ID を表示します。この値を保存しておきます。
$ aws ec2 describe-subnets \ --filters Name=outpost-arn,Values=<outpost_arn_value>
4.3.13.3. Outpost のネットワークの設定
VPC クラスターを Outpost に拡張するには、次のネットワーク設定タスクを完了する必要があります。
- クラスターネットワークの MTU を変更します。
- Outpost にサブネットを作成します。
4.3.13.3.1. AWS Outposts をサポートするためのクラスターネットワーク MTU の変更
クラスターネットワークの最大伝送単位 (MTU) は、インストール中に、クラスター内のノードのプライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。場合によっては、AWS Outposts サブネットをサポートするために、クラスターネットワークの MTU 値を減らす必要があります。
移行には中断が伴うため、MTU 更新が有効になると、クラスター内のノードが一時的に使用できなくなる可能性があります。
サービス中断に関する重要な考慮事項など、移行プロセスの詳細は、この手順の関連情報の「クラスターネットワークの MTU 変更」を参照してください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つアカウントを使用してクラスターにアクセスできる。 -
クラスターのターゲット MTU を特定している。OVN-Kubernetes ネットワークプラグインの MTU は、クラスター内の最小のハードウェア MTU 値から
100
を引いた値に設定する必要があります。
手順
クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。
$ oc describe network.config cluster
出力例
... Status: Cluster Network: Cidr: 10.217.0.0/22 Host Prefix: 23 Cluster Network MTU: 1400 Network Type: OVNKubernetes Service Network: 10.217.4.0/23 ...
MTU 移行を開始するには、次のコマンドを入力して移行設定を指定します。Machine Config Operator は、MTU の変更に備えて、クラスター内のノードをローリングリブートします。
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'
ここでは、以下のようになります。
<overlay_from>
- 現在のクラスターネットワークの MTU 値を指定します。
<overlay_to>
-
クラスターネットワークのターゲット MTU を指定します。この値は、
<machine_to>
の値を基準にして設定します。OVN-Kubernetes の場合、この値は<machine_to>
の値から100
を引いた値である必要があります。 <machine_to>
- 基盤となるホストネットワークのプライマリーネットワークインターフェイスの MTU を指定します。
クラスターの MTU を減らす例
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 1000 } , "machine": { "to" : 1100} } } } }'
Machine Config Operator (MCO) は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
$ oc get machineconfigpools
正常に更新されたノードには、
UPDATED=true
、UPDATING=false
、DEGRADED=false
のステータスがあります。注記Machine Config Operator は、デフォルトでプールごとに 1 つずつマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が増加します。
ホスト上の新規マシン設定のステータスを確認します。
マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
$ oc describe node | egrep "hostname|machineconfig"
出力例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
以下のステートメントが true であることを確認します。
-
machineconfiguration.openshift.io/state
フィールドの値はDone
です。 -
machineconfiguration.openshift.io/currentConfig
フィールドの値は、machineconfiguration.openshift.io/desiredConfig
フィールドの値と等しくなります。
-
マシン設定が正しいことを確認するには、以下のコマンドを入力します。
$ oc get machineconfig <config_name> -o yaml | grep ExecStart
ここで、
<config_name>
はmachineconfiguration.openshift.io/currentConfig
フィールドのマシン設定の名前になります。マシン設定には、systemd 設定に以下の更新を含める必要があります。
ExecStart=/usr/local/bin/mtu-migration.sh
MTU の移行を完了するために、OVN-Kubernetes ネットワークプラグインに対して次のコマンドを入力します。
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'
ここでは、以下のようになります。
<mtu>
-
<overlay_to>
で指定した新しいクラスターネットワーク MTU を指定します。
MTU の移行が完了すると、各マシン設定プールノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
$ oc get machineconfigpools
正常に更新されたノードには、
UPDATED=true
、UPDATING=false
、DEGRADED=false
のステータスがあります。
検証
次のコマンドを入力して、クラスター内のノードが指定した MTU を使用していることを確認します。
$ oc describe network.config cluster
関連情報
4.3.13.3.2. AWS エッジコンピュートサービス用のサブネットの作成
OpenShift Container Platform クラスターのエッジコンピュートノードのマシンセットを設定する前に、AWS Outposts にサブネットを作成する必要があります。
このドキュメントの CloudFormation テンプレートを使用して、CloudFormation スタックを作成できます。その後、このスタックを使用してサブネットをカスタムプロビジョニングできます。
このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- AWS アカウントを設定している。
-
aws configure
を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。 - OpenShift Container Platform クラスター、Outpost、および AWS アカウントから環境に関する必要な情報を取得している。
手順
- このドキュメントの「VPC サブネット用の CloudFormation テンプレート」セクションに移動し、テンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC について記述しています。
次のコマンドを実行して CloudFormation テンプレートをデプロイします。これにより、VPC を表す AWS リソースのスタックが作成されます。
$ aws cloudformation create-stack --stack-name <stack_name> \1 --region ${CLUSTER_REGION} \ --template-body file://<template>.yaml \2 --parameters \ ParameterKey=VpcId,ParameterValue="${VPC_ID}" \3 ParameterKey=ClusterName,ParameterValue="${CLUSTER_NAME}" \4 ParameterKey=ZoneName,ParameterValue="${ZONE_NAME}" \5 ParameterKey=PublicRouteTableId,ParameterValue="${ROUTE_TABLE_PUB}" \6 ParameterKey=PublicSubnetCidr,ParameterValue="${SUBNET_CIDR_PUB}" \7 ParameterKey=PrivateRouteTableId,ParameterValue="${ROUTE_TABLE_PVT}" \8 ParameterKey=PrivateSubnetCidr,ParameterValue="${SUBNET_CIDR_PVT}" \9 ParameterKey=PrivateSubnetLabel,ParameterValue="private-outpost" \ ParameterKey=PublicSubnetLabel,ParameterValue="public-outpost" \ ParameterKey=OutpostArn,ParameterValue="${OUTPOST_ARN}" 10
- 1
<stack_name>
は、CloudFormation スタックの名前です (cluster-<outpost_name>
など)。- 2
<template>
は、保存した CloudFormation テンプレート YAML ファイルの相対パスと名前です。- 3
${VPC_ID}
は VPC ID であり、VPC 用の CloudFormation テンプレートの出力に含まれる値VpcID
です。- 4
${CLUSTER_NAME}
は、新しい AWS リソース名の接頭辞として使用する ClusterName の値です。- 5
${ZONE_NAME}
は、サブネットを作成する AWS Outposts 名の値です。- 6
${ROUTE_TABLE_PUB}
は、Outpost 上のパブリックサブネットを関連付けるために使用する、${VPC_ID}
に作成されたパブリックルートテーブル ID です。このスタックによって作成された Outpost サブネットを関連付けるパブリックルートテーブルを指定します。- 7
${SUBNET_CIDR_PUB}
は、パブリックサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロックVpcCidr
の一部である必要があります。- 8
${ROUTE_TABLE_PVT}
は、Outpost 上のプライベートサブネットを関連付けるために使用する、${VPC_ID}
に作成されたプライベートルートテーブル ID です。このスタックによって作成された Outpost サブネットを関連付けるプライベートルートテーブルを指定します。- 9
${SUBNET_CIDR_PVT}
は、プライベートサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロックVpcCidr
の一部である必要があります。- 10
${OUTPOST_ARN}
は、Outpost の Amazon Resource Name (ARN) です。
出力例
arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-820e-11eb-2fd3-12a48460849f
検証
次のコマンドを実行して、テンプレートコンポーネントが存在することを確認します。
$ aws cloudformation describe-stacks --stack-name <stack_name>
StackStatus
にCREATE_COMPLETE
が表示されると、出力に次のパラメーターの値が表示されます。PublicSubnetId
CloudFormation スタックによって作成されたパブリックサブネットの ID。
PrivateSubnetId
CloudFormation スタックによって作成されたプライベートサブネットの ID。
これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。
4.3.13.3.3. VPC サブネット用の CloudFormation テンプレート
次の CloudFormation テンプレートを使用して、Outpost サブネットをデプロイできます。
例4.55 VPC サブネット用の CloudFormation テンプレート
AWSTemplateFormatVersion: 2010-09-09 Description: Template for Best Practice Subnets (Public and Private) Parameters: VpcId: Description: VPC ID that comprises all the target subnets. Type: String AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$ ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*. ClusterName: Description: Cluster name or prefix name to prepend the Name tag for each subnet. Type: String AllowedPattern: ".+" ConstraintDescription: ClusterName parameter must be specified. ZoneName: Description: Zone Name to create the subnets, such as us-west-2-lax-1a. Type: String AllowedPattern: ".+" ConstraintDescription: ZoneName parameter must be specified. PublicRouteTableId: Description: Public Route Table ID to associate the public subnet. Type: String AllowedPattern: ".+" ConstraintDescription: PublicRouteTableId parameter must be specified. PublicSubnetCidr: AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$ ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24. Default: 10.0.128.0/20 Description: CIDR block for public subnet. Type: String PrivateRouteTableId: Description: Private Route Table ID to associate the private subnet. Type: String AllowedPattern: ".+" ConstraintDescription: PrivateRouteTableId parameter must be specified. PrivateSubnetCidr: AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$ ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24. Default: 10.0.128.0/20 Description: CIDR block for private subnet. Type: String PrivateSubnetLabel: Default: "private" Description: Subnet label to be added when building the subnet name. Type: String PublicSubnetLabel: Default: "public" Description: Subnet label to be added when building the subnet name. Type: String OutpostArn: Default: "" Description: OutpostArn when creating subnets on AWS Outpost. Type: String Conditions: OutpostEnabled: !Not [!Equals [!Ref "OutpostArn", ""]] Resources: PublicSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VpcId CidrBlock: !Ref PublicSubnetCidr AvailabilityZone: !Ref ZoneName OutpostArn: !If [ OutpostEnabled, !Ref OutpostArn, !Ref "AWS::NoValue"] Tags: - Key: Name Value: !Join ['-', [ !Ref ClusterName, !Ref PublicSubnetLabel, !Ref ZoneName]] - Key: kubernetes.io/cluster/unmanaged 1 Value: true PublicSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PublicSubnet RouteTableId: !Ref PublicRouteTableId PrivateSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VpcId CidrBlock: !Ref PrivateSubnetCidr AvailabilityZone: !Ref ZoneName OutpostArn: !If [ OutpostEnabled, !Ref OutpostArn, !Ref "AWS::NoValue"] Tags: - Key: Name Value: !Join ['-', [!Ref ClusterName, !Ref PrivateSubnetLabel, !Ref ZoneName]] - Key: kubernetes.io/cluster/unmanaged 2 Value: true PrivateSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PrivateSubnet RouteTableId: !Ref PrivateRouteTableId Outputs: PublicSubnetId: Description: Subnet ID of the public subnets. Value: !Join ["", [!Ref PublicSubnet]] PrivateSubnetId: Description: Subnet ID of the private subnets. Value: !Join ["", [!Ref PrivateSubnet]]
4.3.13.4. Outpost にエッジコンピュートマシンをデプロイするコンピュートマシンセットの作成
AWS Outposts でエッジコンピュートマシンを作成するには、互換性のある設定を使用して新しいコンピュートマシンセットを作成する必要があります。
前提条件
- AWS Outposts サイトがある。
- OpenShift Container Platform クラスターを AWS のカスタム VPC にインストールしている。
-
cluster-admin
権限を持つアカウントを使用してクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
以下のコマンドを実行して、クラスター内のコンピュートマシンセットを一覧表示します。
$ oc get machinesets.machine.openshift.io -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE <original_machine_set_name_1> 1 1 1 1 55m <original_machine_set_name_2> 1 1 1 1 55m
- 既存のコンピュートマシンセットの名前を記録します。
次のいずれかの方法を使用して、新しいコンピュートマシンセットのカスタムリソース (CR) の値を含む YAML ファイルを作成します。
次のコマンドを実行して、既存のコンピュートマシンセット設定を新しいファイルにコピーします。
$ oc get machinesets.machine.openshift.io <original_machine_set_name_1> \ -n openshift-machine-api -o yaml > <new_machine_set_name_1>.yaml
この YAML ファイルは、任意のテキストエディターで編集できます。
任意のテキストエディターを使用して
<new_machine_set_name_1>.yaml
という名前の空の YAML ファイルを作成し、新しいコンピュートマシンセットに必要な値を含めます。特定のフィールドに設定する値がわからない場合は、次のコマンドを実行して、既存のコンピュートマシンセット CR の値を確認できます。
$ oc get machinesets.machine.openshift.io <original_machine_set_name_1> \ -n openshift-machine-api -o yaml
出力例
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 name: <infrastructure_id>-<role>-<availability_zone> 2 namespace: openshift-machine-api spec: replicas: 1 selector: matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<availability_zone> template: metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> machine.openshift.io/cluster-api-machine-role: <role> machine.openshift.io/cluster-api-machine-type: <role> machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<availability_zone> spec: providerSpec: 3 # ...
<new_machine_set_name_1>.yaml
ファイルを編集して、Outpost にエッジコンピュートマシンを作成するように新しいコンピュートマシンセットを設定します。AWS Outposts 用のコンピュートマシンセットの例
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 name: <infrastructure_id>-outposts-<availability_zone> 2 namespace: openshift-machine-api spec: replicas: 1 selector: matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> machine.openshift.io/cluster-api-machineset: <infrastructure_id>-outposts-<availability_zone> template: metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> machine.openshift.io/cluster-api-machine-role: outposts machine.openshift.io/cluster-api-machine-type: outposts machine.openshift.io/cluster-api-machineset: <infrastructure_id>-outposts-<availability_zone> spec: metadata: labels: node-role.kubernetes.io/outposts: "" location: outposts providerSpec: value: ami: id: <ami_id> 3 apiVersion: machine.openshift.io/v1beta1 blockDevices: - ebs: volumeSize: 120 volumeType: gp2 4 credentialsSecret: name: aws-cloud-credentials deviceIndex: 0 iamInstanceProfile: id: <infrastructure_id>-worker-profile instanceType: m5.xlarge 5 kind: AWSMachineProviderConfig placement: availabilityZone: <availability_zone> region: <region> 6 securityGroups: - filters: - name: tag:Name values: - <infrastructure_id>-worker-sg subnet: id: <subnet_id> 7 tags: - name: kubernetes.io/cluster/<infrastructure_id> value: owned userDataSecret: name: worker-user-data taints: 8 - key: node-role.kubernetes.io/outposts effect: NoSchedule
- 1
- クラスターインフラストラクチャー ID を指定します。
- 2
- コンピュートマシンセットの名前を指定します。この名前は、クラスターインフラストラクチャー ID、
outposts
ロール名、および Outpost のアベイラビリティーゾーンで構成されます。 - 3
- Amazon Machine Image (AMI) ID を指定します。
- 4
- EBS ボリュームのタイプを指定します。AWS Outposts には gp2 ボリュームが必要です。
- 5
- AWS インスタンスのタイプを指定します。Outpost で設定されているインスタンスタイプを使用する必要があります。
- 6
- Outpost のアベイラビリティーゾーンが存在する AWS リージョンを指定します。
- 7
- Outpost の専用サブネットを指定します。
- 8
node-role.kubernetes.io/outposts
ラベルを持つノードでワークロードがスケジュールされないように taint を指定します。Outpost でユーザーのワークロードをスケジュールするには、アプリケーションのDeployment
リソースで対応する toleration を指定する必要があります。
- 変更を保存します。
次のコマンドを実行して、コンピュートマシンセット CR を作成します。
$ oc create -f <new_machine_set_name_1>.yaml
検証
コンピュートマシンセットが作成されたことを確認するには、次のコマンドを実行してクラスター内のコンピュートマシンセットをリスト表示します。
$ oc get machinesets.machine.openshift.io -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE <new_machine_set_name_1> 1 1 1 1 4m12s <original_machine_set_name_1> 1 1 1 1 55m <original_machine_set_name_2> 1 1 1 1 55m
新しいコンピュートマシンセットによって管理されるマシンをリスト表示するには、次のコマンドを実行します。
$ oc get -n openshift-machine-api machines.machine.openshift.io \ -l machine.openshift.io/cluster-api-machineset=<new_machine_set_name_1>
出力例
NAME PHASE TYPE REGION ZONE AGE <machine_from_new_1> Provisioned m5.xlarge us-east-1 us-east-1a 25s <machine_from_new_2> Provisioning m5.xlarge us-east-1 us-east-1a 25s
新しいコンピューティングマシンセットによって作成されたマシンの設定が正しいことを確認するには、次のコマンドを実行して、いずれかの新しいマシンの CR に含まれる関連フィールドを調べます。
$ oc describe machine <machine_from_new_1> -n openshift-machine-api
4.3.13.5. Outpost でのユーザーワークロードの作成
AWS VPC クラスター内の OpenShift Container Platform を Outpost に拡張した後、ラベル node-role.kubernetes.io/outposts
を持つエッジコンピュートノードを使用して、Outpost にユーザーワークロードを作成できます。
前提条件
- AWS VPC クラスターを Outpost に拡張した。
-
cluster-admin
権限を持つアカウントを使用してクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。 - Outpost 環境と互換性のあるエッジコンピュートマシンをデプロイするコンピュートマシンセットを作成している。
手順
エッジサブネットのエッジコンピュートノードにデプロイするアプリケーションの
Deployment
リソースファイルを設定します。Deployment
マニフェストの例kind: Namespace apiVersion: v1 metadata: name: <application_name> 1 --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: <application_name> namespace: <application_namespace> 2 spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: gp2-csi 3 volumeMode: Filesystem --- apiVersion: apps/v1 kind: Deployment metadata: name: <application_name> namespace: <application_namespace> spec: selector: matchLabels: app: <application_name> replicas: 1 template: metadata: labels: app: <application_name> location: outposts 4 spec: securityContext: seccompProfile: type: RuntimeDefault nodeSelector: 5 node-role.kubernetes.io/outpost: '' tolerations: 6 - key: "node-role.kubernetes.io/outposts" operator: "Equal" value: "" effect: "NoSchedule" containers: - image: openshift/origin-node command: - "/bin/socat" args: - TCP4-LISTEN:8080,reuseaddr,fork - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"' imagePullPolicy: Always name: <application_name> ports: - containerPort: 8080 volumeMounts: - mountPath: "/mnt/storage" name: data volumes: - name: data persistentVolumeClaim: claimName: <application_name>
- 1
- アプリケーションの名前を指定します。
- 2
- アプリケーションの namespace を指定します。アプリケーションの namespace はアプリケーション名と同じにすることができます。
- 3
- ストレージクラス名を指定します。エッジコンピュート設定の場合は、
gp2-csi
ストレージクラスを使用する必要があります。 - 4
- Outpost にデプロイされるワークロードを識別するラベルを指定します。
- 5
- エッジコンピュートノードをターゲットとするノードセレクターラベルを指定します。
- 6
- エッジコンピュートマシンのコンピュートマシンセット内の
key
およびeffects
taint に一致する toleration を指定します。この例のようにvalue
とoperator
の toleration を設定します。
次のコマンドを実行して、
Deployment
リソースを作成します。$ oc create -f <application_deployment>.yaml
ターゲットのエッジコンピュートノードからエッジネットワーク内で実行されるサービスに Pod を公開する
Service
オブジェクトを設定します。Service
マニフェストの例apiVersion: v1 kind: Service 1 metadata: name: <application_name> namespace: <application_namespace> spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: NodePort selector: 2 app: <application_name>
次のコマンドを実行して
Service
CR を作成します。$ oc create -f <application_service>.yaml
4.3.13.6. エッジおよびクラウドベースの AWS コンピューティングリソースでワークロードをスケジュールする
AWS VPC クラスターを Outpost に拡張すると、Outpost はエッジコンピュートノードを使用し、VPC はクラウドベースのコンピュートノードを使用します。Outpost に拡張された AWS VPC クラスターには、ロードバランサーに関する次の考慮事項が適用されます。
- Outpost は AWS Network Load Balancer または AWS Classic Load Balancer を実行できませんが、Outpost に拡張された VPC クラスターの Classic Load Balancer は Outpost エッジコンピュートノードに接続できます。詳細は、Outpost に拡張された AWS VPC クラスターでの AWS Classic Load Balancer の使用 を参照してください。
- Outpost インスタンスでロードバランサーを実行するには、AWS Application Load Balancer を使用する必要があります。AWS Load Balancer Operator を使用すると、AWS Load Balancer コントローラーのインスタンスをデプロイできます。このコントローラーは、Kubernetes Ingress リソース用の AWS Application Load Balancer をプロビジョニングします。詳細は、Outpost に拡張された AWS VPC クラスターでの AWS Load Balancer Operator の使用 を参照してください。
4.3.13.6.1. Outpost に拡張された AWS VPC クラスターでの AWS Classic Load Balancer の使用
AWS Outposts インフラストラクチャーは、AWS Classic Load Balancer を実行できませんが、AWS VPC クラスターの Classic Load Balancer は、エッジおよびクラウドベースのサブネットが同じアベイラビリティーゾーンにある場合、Outpost のエッジコンピュートノードをターゲットにすることができます。そのため、VPC クラスター上の Classic Load Balancer は、これらのノードタイプのどちらかに Pod をスケジュールする可能性があります。
エッジコンピュートノードおよびクラウドベースのコンピュートノードでワークロードをスケジュールすると、遅延が発生する可能性があります。VPC クラスター内の Classic Load Balancer が Outpost のエッジコンピュートノードをターゲットにするのを防ぐ場合は、クラウドベースのコンピュートノードにラベルを適用し、適用されたラベルを持つノードにのみスケジュールするように Classic Load Balancer を設定できます。
VPC クラスター内の Classic Load Balancer が Outpost エッジコンピュートノードをターゲットにしても問題ない場合、これらの手順を完了する必要はありません。
前提条件
- AWS VPC クラスターを Outpost に拡張した。
-
cluster-admin
権限を持つアカウントを使用してクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。 - エッジコンピュートマシンの taint に一致する toleration を持つユーザーワークロードを Outpost に作成している。
手順
オプション: 次のコマンドを実行し、出力に Outpost 内のエッジコンピュートノードのみが含まれていることを確認して、エッジコンピュートノードに
location=outposts
ラベルがあることを確認します。$ oc get nodes -l location=outposts
次のコマンドを実行して、VPC クラスター内のクラウドベースのコンピュートノードにキーと値のペアのラベルを付けます。
$ for NODE in $(oc get node -l node-role.kubernetes.io/worker --no-headers | grep -v outposts | awk '{print$1}'); do oc label node $NODE <key_name>=<value>; done
<key_name>=<value>
は、クラウドベースのコンピュートノードを識別するために使用するラベルです。出力例
node1.example.com labeled node2.example.com labeled node3.example.com labeled
オプション: 次のコマンドを実行し、出力に VPC クラスター内のすべてのクラウドベースのコンピュートノードが含まれていることを確認して、クラウドベースのコンピュートノードに指定したラベルがあることを確認します。
$ oc get nodes -l <key_name>=<value>
出力例
NAME STATUS ROLES AGE VERSION node1.example.com Ready worker 7h v1.29.4 node2.example.com Ready worker 7h v1.29.4 node3.example.com Ready worker 7h v1.29.4
クラウドベースのサブネットの情報を
Service
マニフェストのannotations
フィールドに追加して、Classic Load Balancer サービスを設定します。サービス設定の例
apiVersion: v1 kind: Service metadata: labels: app: <application_name> name: <application_name> namespace: <application_namespace> annotations: service.beta.kubernetes.io/aws-load-balancer-subnets: <aws_subnet> 1 service.beta.kubernetes.io/aws-load-balancer-target-node-labels: <key_name>=<value> 2 spec: ports: - name: http port: 80 protocol: TCP targetPort: 8080 selector: app: <application_name> type: LoadBalancer
次のコマンドを実行して
Service
CR を作成します。$ oc create -f <file_name>.yaml
検証
次のコマンドを実行して、
service
リソースのステータスを確認して、プロビジョニングされた Classic Load Balancer のホストを表示します。$ HOST=$(oc get service <application_name> -n <application_namespace> --template='{{(index .status.loadBalancer.ingress 0).hostname}}')
次のコマンドを実行して、プロビジョニングされた Classic Load Balancer ホストのステータスを確認します。
$ curl $HOST
- AWS コンソールで、ラベル付きインスタンスのみがロードバランサーのターゲットインスタンスとして表示されることを確認します。
4.3.13.6.2. Outpost に拡張された AWS VPC クラスターでの AWS Load Balancer Operator の使用
Outpost に拡張された AWS VPC クラスター内で AWS Application Load Balancer をプロビジョニングするように AWS Load Balancer Operator を設定できます。AWS Outposts は AWS Network Load Balancer をサポートしていません。そのため、AWS Load Balancer Operator は Outpost に Network Load Balancer をプロビジョニングできません。
AWS Application Load Balancer は、クラウドサブネットか Outpost サブネットのどちらかに作成できます。クラウドの Application Load Balancer はクラウドベースのコンピュートノードに接続でき、Outpost の Application Load Balancer はエッジコンピュートノードに接続できます。Ingress リソースには Outpost サブネットまたは VPC サブネットのアノテーションを付ける必要がありますが、両方を付けることはできません。
前提条件
- AWS VPC クラスターを Outpost に拡張した。
-
OpenShift CLI (
oc
) がインストールされている。 - AWS Load Balancer Operator をインストールし、AWS Load Balancer Controller を作成した。
手順
指定のサブネットを使用するように
Ingress
リソースを設定します。Ingress
リソース設定の例apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: <application_name> annotations: alb.ingress.kubernetes.io/subnets: <subnet_id> 1 spec: ingressClassName: alb rules: - http: paths: - path: / pathType: Exact backend: service: name: <application_name> port: number: 80
- 1
- 使用するサブネットを指定します。
- Outpost で Application Load Balancer を使用するには、Outpost のサブネット ID を指定します。
- クラウドで Application Load Balancer を使用するには、別々のアベイラビリティーゾーンに少なくとも 2 つのサブネットを指定する必要があります。