Red Hat Summit14.10. AWS のインストールファイルの作成
OpenShift Container Platform を Amazon Web Services (AWS) にインストールして AWS Local Zones を使用するには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml ファイルを生成してカスタマイズし、それにローカルゾーンのサブネットを追加するように設定します。
14.10.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 で使用することがサポートされます。
関連情報
14.10.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは、AWS Local Zones で使用するために OpenShift Container Platform でテストされています。
以下のチャートに含まれるマシンタイプを AWS インスタンスに使用します。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、クラスターインストールの最小リソース要件に記載されている最小リソース要件と一致していることを確認してください。
例14.3 AWS Local Zones の 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c5.* -
c5d.* -
m6i.* -
m5.* -
r5.* -
t3.*
14.10.3. インストール設定ファイルの作成
インストールプログラムがクラスターをデプロイするために必要なインストール設定ファイルを生成し、カスタマイズします。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
-
Red Hat が公開している付随の Red Hat Enterprise Linux CoreOS (RHCOS) AMI のあるリージョンにクラスターをデプロイしていることを確認済みである。AWS GovCloud リージョンなどのカスタム AMI を必要とするリージョンにデプロイする場合は、
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 リージョンを選択します。指定するリージョンは、AWS アカウント用にオプトインした Local Zone を含むリージョンと同じである必要があります。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
オプション:
install-config.yamlファイルをバックアップします。重要install-config.yamlファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
14.10.4. AWS Local Zones のエッジコンピューティングプール
OpenShift Container Platform 4.12 では、リモートゾーンで使用するために設計された新しいコンピューティングプール Edge が導入されました。エッジコンピュートプール設定は、AWS Local Zone の場所間で共通です。ただし、Local Zone リソース上の EC2 や EBS などのリソースのタイプとサイズの制限により、作成されるデフォルトのインスタンスタイプは従来のワーカープールとは異なる場合があります。
Local Zone の場所のデフォルトの Elastic Block Store (EBS) は gp2 であり、通常のワーカープールとは異なります。エッジコンピュートプールの各 Local Zone に使用されるインスタンスタイプも、ゾーンのインスタンスオファリングによってワーカープールとは異なる場合があります。
エッジコンピュートプールは、開発者が AWS Local Zone ノードにアプリケーションをデプロイするために使用できる新しいラベルを作成します。新しいラベルは次のとおりです。
-
node-role.kubernetes.io/edge='' -
machine.openshift.io/zone-type=local-zone -
machine.openshift.io/zone-group=$ZONE_GROUP_NAME
デフォルトでは、ユーザーが AWS Local Zone のサブネット ID をリスト platform.aws.subnets に追加した場合にのみ、システムはエッジコンピューティングプールマニフェストを作成します。
エッジコンピューティングプールのマシンセットには、通常のワークロードがそれらのマシンに分散されるのを防ぐために、デフォルトで NoSchedule テイントが 設定されています。ユーザーは、許容範囲が Pod 仕様で定義されている場合にのみユーザーワークロードを実行できます。
次の例は、エッジマシンプールを使用する install-config.yaml ファイルを示しています。
デフォルト設定のエッジプールを使用する設定
apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
name: ipi-localzone
platform:
aws:
region: us-west-2
subnets:
- publicSubnetId-1
- publicSubnetId-2
- publicSubnetId-3
- privateSubnetId-1
- privateSubnetId-2
- privateSubnetId-3
- publicSubnetId-LocalZone-1
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...
カスタムインスタンスタイプのエッジプールを使用する設定
apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
name: ipi-localzone
compute:
- name: edge
platform:
aws:
type: m5.4xlarge
platform:
aws:
region: us-west-2
subnets:
- publicSubnetId-1
- publicSubnetId-2
- publicSubnetId-3
- privateSubnetId-1
- privateSubnetId-2
- privateSubnetId-3
- publicSubnetId-LocalZone-1
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...
インスタンスのタイプは場所によって異なります。クラスターが実行される Local Zone での可用性を確認するには、AWS のドキュメントを参照してください。
カスタム EBS タイプのエッジプールを使用する設定
apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
name: ipi-localzone
compute:
- name: edge
platform:
aws:
rootVolume:
type: gp3
size: 120
platform:
aws:
region: us-west-2
subnets:
- publicSubnetId-1
- publicSubnetId-2
- publicSubnetId-3
- privateSubnetId-1
- privateSubnetId-2
- privateSubnetId-3
- publicSubnetId-LocalZone-1
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...
EBS タイプは場所によって異なります。AWS のドキュメントを参照して、クラスターが実行されるローカルゾーンでの可用性を確認してください。
14.10.4.1. エッジコンピュートプールおよび AWS Local Zones
エッジワーカーノードは、AWS Local Zones の場所で実行されるテイントされたワーカーノードです。
Local Zone を使用するクラスターをデプロイメントする場合:
- Local Zone の Amazon EC2 インスタンスは、アベイラビリティゾーンの Amazon EC2 インスタンスよりも高価です。
- アプリケーションとエンドユーザー間の遅延は、Local Zone では低くなりますが、場所によって異なる場合があります。たとえば、ルーターが Local Zones と Availability Zones の間で混在している場合、一部のワークロードにはレイテンシーの影響があります。
-
クラスターネットワークの最大伝送単位 (MTU) は、Local Zone のサブネットが
install-config.yamlで検出されると、ネットワークプラグインに従って AWS によって制限される下限に自動的に調整されます。たとえば、調整された値は、OVN-Kubernetes の場合は 1200、OpenShift SDN の場合は 1250 です。追加機能が有効になっている場合は、手動による MTU 調整が必要になる場合があります。
通常、ローカルゾーンの Amazon EC2 インスタンスとリージョンの Amazon EC2 インスタンス間の最大転送単位 (MTU) は 1300 です。詳細は、AWS ドキュメントの ローカルゾーンの仕組み を参照してください。オーバーヘッドを考慮して、クラスターネットワーク MTU は常に EC2 MTU より小さくなければなりません。特定のオーバーヘッドは、ネットワークプラグインによって決定されます。以下に例を示します。
-
OVN-Kubernetes:
100 bytes -
OpenShift SDN:
50 bytes
ネットワークプラグインは、MTU を減らす必要がある IPsec などの追加機能を提供できます。追加情報は、ドキュメントを参照してください。
14.10.5. AWS Local Zones サブネットを使用するためのインストール設定ファイルの変更
install-config.yaml ファイルを変更して、AWS Local Zones サブネットを含めます。
前提条件
- AWS Local Zones でのサブネットの作成の手順を使用してサブネットを作成しました。
-
インストール設定ファイルの作成の手順を使用して、
install-config.yamlファイルを作成しました。
手順
VPC および Local Zone のサブネットを
platform.aws.subnetsプロパティーの値として追加します。たとえば、以下のようになります。... platform: aws: region: us-west-2 subnets: 1 - publicSubnetId-1 - publicSubnetId-2 - publicSubnetId-3 - privateSubnetId-1 - privateSubnetId-2 - privateSubnetId-3 - publicSubnetId-LocalZone-1 ...- 1
- Availability Zone と Local Zone で作成されたサブネットのリスト。
関連情報
- AWS プロファイルおよび認証情報の設定についての詳細は、AWS ドキュメントの Configuration and credential file settings を参照してください。
