第8章 AWS Local Zone または Wavelength Zone 関連のタスク
OpenShift Container Platform を Amazon Web Services (AWS) にインストールした後、AWS Local Zones または Wavelength Zones とエッジコンピュートプールをさらに設定できます。
8.1. 既存のクラスターを拡張して AWS Local Zones または Wavelength Zones を使用する
インストール後のタスクとして、Amazon Web Services (AWS) 上の既存の OpenShift Container Platform クラスターを拡張して、AWS Local Zones または Wavelength Zones を使用できます。
ノードを Local Zones または Wavelength Zones の場所に拡張するには、次の手順を実行します。
- クラスターネットワークの最大伝送単位 (MTU) を調整します。
- Local Zones または Wavelength Zones グループを AWS Local Zones または Wavelength Zones にオプトインします。
Local Zones または Wavelength Zones の場所の既存 VPC にサブネットを作成します。
重要AWS 上の既存の OpenShift Container Platform クラスターを拡張して Local Zones または Wavelength Zones を使用する前に、既存の VPC に使用可能な Classless Inter-Domain Routing (CIDR) ブロックが含まれていることを確認してください。これらのブロックはサブネットの作成に必要です。
- マシンセットマニフェストを作成し、Local Zone または Wavelength Zone の各場所にノードを作成します。
Local Zones のみ:
ec2:ModifyAvailabilityZoneGroup
権限を Identity and Access Management (IAM) ユーザーまたはロールに追加して、必要なネットワークリソースを作成できるようにします。以下に例を示します。AWS Local Zones デプロイメントの追加 IAM ポリシーの例
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:ModifyAvailabilityZoneGroup" ], "Effect": "Allow", "Resource": "*" } ] }
Wavelength Zone のみ:
ec2:ModifyAvailabilityZoneGroup
、ec2:CreateCarrierGateway
、およびec2:DeleteCarrierGateway
権限を Identity and Access Management (IAM) ユーザーまたはロールに追加して、必要なネットワークリソースを作成できるようにします。以下に例を示します。AWS Wavelength Zones デプロイメント用の追加 IAM ポリシーの例
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DeleteCarrierGateway", "ec2:CreateCarrierGateway" ], "Resource": "*" }, { "Action": [ "ec2:ModifyAvailabilityZoneGroup" ], "Effect": "Allow", "Resource": "*" } ] }
関連情報
- AWS Local Zones、サポートされているインスタンスタイプ、およびサービスの詳細は、AWS ドキュメントの AWS Local Zones features を参照してください。
- AWS Local Zones、サポートされているインスタンスタイプ、およびサービスの詳細は、AWS ドキュメントの AWS Wavelength features を参照してください。
8.1.1. エッジコンピュートプールについて
エッジコンピュートノードは、AWS Local Zones または Wavelength Zone の場所で実行される taint されたコンピュートノードです。
Local Zones または Wavelength Zones を使用するクラスターをデプロイする場合は、次の点を考慮してください。
- Local Zones または Wavelength Zones 内の Amazon EC2 インスタンスは、アベイラビリティーゾーン内の Amazon EC2 インスタンスよりも高コストです。
- AWS Local Zones または Wavelength Zones で実行されているアプリケーションとエンドユーザーの間の遅延は低くなります。一部のワークロードでは、遅延の影響が発生します。たとえば、Local Zones または Wavelength Zones とアベイラビリティーゾーンの間で Ingress トラフィックが混在している場合などです。
通常、Local Zones または Wavelength Zones 内の Amazon EC2 インスタンスとリージョン内の Amazon EC2 インスタンス間の最大伝送単位 (MTU) は 1300 です。クラスターネットワークの MTU は、オーバーヘッドを考慮して、常に EC2 の MTU よりも小さくする必要があります。具体的なオーバーヘッドは、ネットワークプラグインによって決まります。たとえば、OVN-Kubernetes のオーバーヘッドは 100 bytes
です。
ネットワークプラグインは、IPsec などの追加機能を提供できます。MTU のサイズには、このような追加機能も影響します。
それぞれのゾーンタイプの詳細は、次のリソースにアクセスしてください。
- AWS ドキュメントの How Local Zones work を参照してください。
- AWS ドキュメントの How AWS Wavelength work を参照してください。
OpenShift Container Platform 4.12 で、リモートゾーンで使用するために設計された新しいコンピュートプールの エッジ が導入されました。エッジコンピュートプールの設定は、AWS Local Zones または Wavelength Zones の場所間で共通です。Local Zones または Wavelength Zones リソース上の EC2 や EBS などのリソースのタイプとサイズの制限により、デフォルトのインスタンスタイプが従来のコンピュートプールと異なる場合があります。
Local Zones または Wavelength Zone の場所のデフォルト Elastic Block Store (EBS) は gp2
であり、非エッジコンピュートプールとは異なります。各 Local Zones または Wavelength Zones に使用される、エッジコンピュートプールのインスタンスタイプも、ゾーンのインスタンスオファリングに応じて、他のコンピュートプールと異なる場合があります。
エッジコンピュートプールは、開発者が AWS Local Zones または Wavelength Zones ノードにアプリケーションをデプロイするために使用できる新しいラベルを作成します。新しいラベルは次のとおりです。
-
node-role.kubernetes.io/edge=''
-
Local Zones のみ:
machine.openshift.io/zone-type=local-zone
-
Wavelength Zones のみ:
machine.openshift.io/zone-type=wavelength-zone
-
machine.openshift.io/zone-group=$ZONE_GROUP_NAME
デフォルトでは、エッジコンピュートプールのマシンセットは NoSchedule
taint を定義して、Local Zones または Wavelength Zones のインスタンスに他のワークロードが拡散するのを防ぎます。ユーザーは、Pod 仕様で toleration を定義している場合にのみユーザーワークロードを実行できます。