14.2. AWS Local Zones とエッジコンピュートプールについて
AWS Local Zones 環境でのインフラストラクチャーの動作とクラスターの制限を理解するには、以降のセクションをお読みください。
14.2.1. AWS Local Zones でのクラスターの制限 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのインストール設定で Amazon Web Services (AWS) の Local Zones にクラスターをデプロイする場合、いくつかの制限があります。
次のリストは、事前設定された 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タイプのボリュームがノードボリュームのデフォルトであり、ストレージクラスのデフォルトです。このボリュームタイプは、ゾーンの場所ではグローバルに使用できません。デフォルトでは、ゾーン内で実行されるノードは、gp2EBS ボリュームを使用してデプロイされます。ゾーンのノードにワークロードを作成する場合は、gp2-csiStorageClassパラメーターを設定する必要があります。
インストールプログラムで 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 サブネットに対してのみ有効です。
14.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 Zones の場所間で共通です。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 を定義している場合にのみユーザーワークロードを実行できます。